| 2012-08-31 10:59:05 |
dan wendlandt |
bug |
|
|
added bug |
| 2012-08-31 10:59:15 |
dan wendlandt |
quantum: milestone |
|
folsom-rc1 |
|
| 2012-08-31 10:59:20 |
dan wendlandt |
quantum: assignee |
|
dan wendlandt (danwent) |
|
| 2012-08-31 10:59:23 |
dan wendlandt |
quantum: importance |
Undecided |
High |
|
| 2012-08-31 10:59:25 |
dan wendlandt |
quantum: status |
New |
Confirmed |
|
| 2012-09-01 00:13:12 |
David Medberry |
bug task added |
|
openvswitch (Ubuntu) |
|
| 2012-09-03 08:05:22 |
James Page |
openvswitch (Ubuntu): importance |
Undecided |
Medium |
|
| 2012-09-03 09:57:11 |
dan wendlandt |
quantum: milestone |
folsom-rc1 |
|
|
| 2012-09-07 19:20:29 |
Launchpad Janitor |
branch linked |
|
lp:~gandelman-a/ubuntu/quantal/openvswitch/lp1044318 |
|
| 2012-09-07 20:17:43 |
Adam Gandelman |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2012-09-07 20:45:11 |
Launchpad Janitor |
openvswitch (Ubuntu): status |
New |
Fix Released |
|
| 2012-09-07 21:12:35 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/openvswitch |
|
| 2012-09-07 22:16:42 |
Adam Gandelman |
description |
Note: OVS from before 1.5, which includes the default versions shipped with 12.04 and Fedora 17, has a bug that causes it not to work correctly with floating IPs when the person contacting the floating IP is on the same box as quantum-l3-agent.
While not very likely to happen in a production setup, this is fairly common in simple development environments. For example, let's say you create an external network 40.0.0.0/24 for floating IPs. If you then assign br-ex the IP 40.0.0.1, you should be able to reach all of your VMs with floating IPs, but it won't work because of this bug. Oddly, it will often appear to work if you use ping, but in reality you are pining the IP address in the router namespace, not the VM.
We believe the following OVS commit it required for this to work properly:
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=53e6421bc83918ac2d00ba5516f205fa7e394140
We are looking at creating a new stable release on the 1.4.x branch to include this change and plan to work with distros to get it pulled into their packages. |
Note: OVS from before 1.5, which includes the default versions shipped with 12.04 and Fedora 17, has a bug that causes it not to work correctly with floating IPs when the person contacting the floating IP is on the same box as quantum-l3-agent.
While not very likely to happen in a production setup, this is fairly common in simple development environments. For example, let's say you create an external network 40.0.0.0/24 for floating IPs. If you then assign br-ex the IP 40.0.0.1, you should be able to reach all of your VMs with floating IPs, but it won't work because of this bug. Oddly, it will often appear to work if you use ping, but in reality you are pining the IP address in the router namespace, not the VM.
We believe the following OVS commit it required for this to work properly:
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=53e6421bc83918ac2d00ba5516f205fa7e394140
We are looking at creating a new stable release on the 1.4.x branch to include this change and plan to work with distros to get it pulled into their packages.
[IMPACT]
The connection tracking logic using by IPtables gets confused if a packet passes through multiple linux network namespaces on the same host. The reason for this confusion is that OVS is not properly clearing some of the fields in the skb header, meaning the connection tracking ignores this packet, so iptables functionality that relies on this (in particular DNAT and SNAT) do not work.
In particular, the use of OVS by OpenStack Quantum is critically affected by this bug.
[FIX]
The issue has been fixed upstream as of 1.4.3. A minimal 5-liner that clears the appropriate metadata from the skb header. The patch has been cherry-picked and fix released in the current Ubuntu dev. release (12.10).
[REGRESSION POTENTIAL]
Minimal. Simple patch that has been cherry-picked from the currentl upstream stable release of Openvswitch (1.4.3). |
|
| 2012-09-07 22:16:48 |
Adam Gandelman |
summary |
pre-1.5 OVS has trouble with floating ips when pinging from the same box |
[SRU] pre-1.5 OVS has trouble with floating ips when pinging from the same box |
|
| 2012-09-07 22:16:56 |
Adam Gandelman |
nominated for series |
|
Ubuntu Precise |
|
| 2012-09-07 22:40:31 |
Launchpad Janitor |
branch linked |
|
lp:~gandelman-a/ubuntu/precise/openvswitch/lp1044318 |
|
| 2012-09-07 22:45:38 |
Adam Gandelman |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-09-07 23:33:32 |
Chuck Short |
bug task added |
|
openvswitch (Ubuntu Precise) |
|
| 2012-09-07 23:46:59 |
Adam Gandelman |
openvswitch (Ubuntu Precise): status |
New |
Confirmed |
|
| 2012-09-11 00:14:48 |
dan wendlandt |
bug task deleted |
quantum |
|
|
| 2012-09-13 21:12:51 |
Bryce Harrington |
description |
Note: OVS from before 1.5, which includes the default versions shipped with 12.04 and Fedora 17, has a bug that causes it not to work correctly with floating IPs when the person contacting the floating IP is on the same box as quantum-l3-agent.
While not very likely to happen in a production setup, this is fairly common in simple development environments. For example, let's say you create an external network 40.0.0.0/24 for floating IPs. If you then assign br-ex the IP 40.0.0.1, you should be able to reach all of your VMs with floating IPs, but it won't work because of this bug. Oddly, it will often appear to work if you use ping, but in reality you are pining the IP address in the router namespace, not the VM.
We believe the following OVS commit it required for this to work properly:
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=53e6421bc83918ac2d00ba5516f205fa7e394140
We are looking at creating a new stable release on the 1.4.x branch to include this change and plan to work with distros to get it pulled into their packages.
[IMPACT]
The connection tracking logic using by IPtables gets confused if a packet passes through multiple linux network namespaces on the same host. The reason for this confusion is that OVS is not properly clearing some of the fields in the skb header, meaning the connection tracking ignores this packet, so iptables functionality that relies on this (in particular DNAT and SNAT) do not work.
In particular, the use of OVS by OpenStack Quantum is critically affected by this bug.
[FIX]
The issue has been fixed upstream as of 1.4.3. A minimal 5-liner that clears the appropriate metadata from the skb header. The patch has been cherry-picked and fix released in the current Ubuntu dev. release (12.10).
[REGRESSION POTENTIAL]
Minimal. Simple patch that has been cherry-picked from the currentl upstream stable release of Openvswitch (1.4.3). |
[Impact]
The connection tracking logic using by IPtables gets confused if a packet passes through multiple linux network namespaces on the same host. The reason for this confusion is that OVS is not properly clearing some of the fields in the skb header, meaning the connection tracking ignores this packet, so iptables functionality that relies on this (in particular DNAT and SNAT) do not work.
In particular, the use of OVS by OpenStack Quantum is critically affected by this bug.
[Fix]
The issue has been fixed upstream as of 1.4.3. A minimal 5-liner that clears the appropriate metadata from the skb header. The patch has been cherry-picked and fix released in the current Ubuntu dev. release (12.10).
[Test Case]
1. Create external network 40.0.0.0/24 for floating IPs
2. Assign br-ex the IP 40.0.0.1
3. Pinging 40.0.0.1 appears to work, but you're pinging the router, not the VM
4. Network connectivity to the VM with the floating IP does not work, as expected.
[Regression Potential]
Minimal. Simple patch that has been cherry-picked from the current upstream stable release of Openvswitch (1.4.3).
[Original Report]
Note: OVS from before 1.5, which includes the default versions shipped with 12.04 and Fedora 17, has a bug that causes it not to work correctly with floating IPs when the person contacting the floating IP is on the same box as quantum-l3-agent.
While not very likely to happen in a production setup, this is fairly common in simple development environments. For example, let's say you create an external network 40.0.0.0/24 for floating IPs. If you then assign br-ex the IP 40.0.0.1, you should be able to reach all of your VMs with floating IPs, but it won't work because of this bug. Oddly, it will often appear to work if you use ping, but in reality you are pinging the IP address in the router namespace, not the VM.
We believe the following OVS commit it required for this to work properly:
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=53e6421bc83918ac2d00ba5516f205fa7e394140
We are looking at creating a new stable release on the 1.4.x branch to include this change and plan to work with distros to get it pulled into their packages. |
|
| 2012-09-13 21:13:02 |
Bryce Harrington |
openvswitch (Ubuntu Precise): status |
Confirmed |
Triaged |
|
| 2012-09-13 21:13:05 |
Bryce Harrington |
openvswitch (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2012-09-26 03:13:47 |
Chris Halse Rogers |
openvswitch (Ubuntu Precise): status |
Triaged |
Fix Committed |
|
| 2012-09-26 03:13:51 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
| 2012-09-26 03:13:59 |
Chris Halse Rogers |
tags |
|
verification-needed |
|
| 2012-09-26 03:43:39 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/openvswitch |
|
| 2012-09-28 21:38:23 |
Dimitri John Ledkov |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2012-10-02 21:03:39 |
dan wendlandt |
tags |
verification-needed |
verification-done |
|
| 2012-10-03 08:36:40 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2012-10-03 08:37:18 |
Launchpad Janitor |
openvswitch (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
