Reviewed: https://review.openstack.org/468846
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=0f076cfc2d59605bdb5e66241a98ed5fa1fdddeb
Submitter: Jenkins
Branch: master
commit 0f076cfc2d59605bdb5e66241a98ed5fa1fdddeb
Author: Sean Redmond <sean.redmo...@gmail.com>
Date: Mon May 29 10:50:27 2017 +0100
Do not respond to ARP on IPv6-only interfaces
When using dual stack, the IPv6 router interface responds
to ARP requests that only the IPv4 interface should.
This results in ARP flux and can cause a guest to address
packets to the wrong layer-2 address when sending traffic
to the IPv4 gateway.
Change arp_ignore and arp_announce sysctl options on interfaces
in the router namespace to be more strict in how we respond.
Closes-bug: 1692007
Change-Id: Ic3c2370995abb027a3412b473ce6bc63790c1105
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1692007
Title:
Dual Stack IPV4/6 ARP bleed
Status in neutron:
Fix Released
Bug description:
Version = newton (2:9.2.0-0ubuntu1~cloud0)
DVR (HA mode) with ipv4 and ipv6
l2_population = True
arp_responder = True
I noticed when using dual stack ipv4 and ipv6 Linux guests are working
fine but windows guests seemed to have a problem with their ipv4
connectivity. Upon investigation I found an ARP issue in that both the
ipv4 and ipv6 interface of the virtual router are responding to arp
requests the below shows a capture from the tap interface of the guest
when the arp table in the guest is flushed.
12:04:58.273446 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1
tell 10.0.0.23, length 28
12:04:58.273776 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.1 is-at
fa:16:3e:43:9d:58, length 28
12:04:58.273790 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.1 is-at
fa:16:3e:19:96:e6, length 28
If I look at the active router interfaxces I can see mac ending 9d:58
is the ipv4 interface and mac ending 96:e6 is the ipv6 interfaces as
shown below:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: qr-12e41bc2-68@if1021: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc
noqueue state UP group default qlen 1000
link/ether fa:16:3e:43:9d:58 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.0.1/8 brd 10.255.255.255 scope global qr-12e41bc2-68
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe43:9d58/64 scope link
valid_lft forever preferred_lft forever
6: qr-bd91567c-81@if1143: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc
noqueue state UP group default qlen 1000
link/ether fa:16:3e:19:96:e6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 <prefix_hidden>:9:1::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe19:96e6/64 scope link
valid_lft forever preferred_lft forever
7: qr-03c27e46-4b@if1159: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc
noqueue state UP group default qlen 1000
link/ether fa:16:3e:8e:f7:bd brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 <prefix_hidden>:9:2::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe8e:f7bd/64 scope link
valid_lft forever preferred_lft forever
We should not see two arp responses here, we should only see one from
fa:16:3e:43:9d:58. Turns out that Linux guests populates the arp table
based upon the first response and windows guests based upon the latest
response, this explains to me why windows guests are failing and Linux
are working as the first arp response is valid and the second one is
invalid - but I think we have a bigger issue here as I should not be
getting an arp response for the ipv6 interface.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1692007/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
