← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #64124

[Bug 1692007] [NEW] Dual Stack IPV4/6 ARP bleed

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

Version = newton (2:9.2.0-0ubuntu1~cloud0)
DVR (HA mode) with ipv4 and ipv6
l2_population = 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.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
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:
  New

Bug description:
  Version = newton (2:9.2.0-0ubuntu1~cloud0)
  DVR (HA mode) with ipv4 and ipv6
  l2_population = 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

Follow ups

  Thread Previous • Date Previous • • Thread Next