yahoo-eng-team team mailing list archive

[OpenStack Infra <1667756@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/442518
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=676a3ebe2f5b62f0ce7a3f7f434526931d5504a5
Submitter: Jenkins
Branch:    master

commit 676a3ebe2f5b62f0ce7a3f7f434526931d5504a5
Author: Daniel Alvarez <dalvarez@xxxxxxxxxx>
Date:   Sun Jan 22 13:33:07 2017 +0000

    Disable RA and IPv6 forwarding on backup HA routers
    
    Neutron does not disable ipv6 forwarding for HA routers and it's
    enabled by default in all router namespaces. For ipv6, this means
    that it will automatically join the following groups:
    
    * link-local all-routers multicast group (ff02::2)
    * interface-local all routers multicast group (ff01::2)
    * site-local all routers multicast group (ff05::2))
    
    As a side effect it will answer to multicast listener queries, thus
    causing external switch to learn its MAC address and disrupting traffic
    to the master instance.
    
    This patch will enable ipv6 forwarding on the gateway interface only
    for master instances and disable it otherwise to fix the issue.
    
    Also, the accept_ra procfs entry was enabled under certain
    circumstances but it wasn't disabled otherwise. This patch, will
    disable RA on the gateway interface for non master instances.
    
    Closes-Bug: #1667756
    
    Change-Id: I9bc890b43f750cad68fc67f4c79f1426c3506863


** 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/1667756

Title:
  Backup HA router sending traffic, traffic from switch interrupted

Status in neutron:
  Fix Released

Bug description:
  As outlined in https://review.openstack.org/#/c/142843/, backup HA
  routers should not send any traffic.  Any traffic will cause the
  connected switch to learn a new port for the associated src mac
  address since the mac address will be in use on the primary HA router.

  We are observing backup routers sending IPv6 RA and RS messages
  probably in response to incoming IPv6 RA messages.  The subnets
  associated with the HA routers are not intended for IPv6 traffic.

  A typical traffic sequence is:

  Packet from external switch...
  08:81:f4:a6:dc:01 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80:52:0:136c::fe > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56

  Immediately followed by a packet from the backup HA router...
  fa:16:3e:a7:ae:63 > 33:33:ff:a7:ae:63, ethertype IPv6 (0x86dd), length 86: (hlim 1, next-header Options (0) payload length: 32) :: > ff02::1:ffa7:ae63: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ffa7:ae63

  Another pkt...
  fa:16:3e:a7:ae:63 > 33:33:ff:a7:ae:63, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) :: > ff02::1:ffa7:ae63: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2620:52:0:136c:f816:3eff:fea7:ae63

  Another Pkt...
  fa:16:3e:a7:ae:63 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) 

  At this point, the switch has updated its mac table and traffic to the
  fa:16:3e:a7:ae:63 address has been redirected to the backup host.
  SSH/ping traffic resumes at a later time when the primary router node
  sends traffic with the fa:16:3e:a7:ae:63 source address.

  This problem is reproducible in our environment as follows:

  1. Deploy OSP10
  2. Create external network
  3. Create external subnet (IPv4)
  4. Create an internal network and VM
  5. Attach floating ip
  6. ssh into the VM through the FIP or ping the FIP
  7. you will start to see ssh freeze or the ping fail occasionally

  
  Additional info:
  Setting accept_ra=0 on the backup host routers stops the problem from
  happening.  Unfortunately, on a reboot, we loose the setting.  The current
  sysctl files have accept_ra=0.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1667756/+subscriptions