yahoo-eng-team team mailing list archive

[Mathieu Rohon <mathieu.rohon@xxxxxxxxx>]

Public bug reported:

This bug comes from a split of the bug #1365476 which will now be
dedicated to an OVS fix

There is big difference between OVS and LB when using vxlan tunnels
managed by l2pop :

-In OVS, vxlan tunnels are plugged into the br-tun bridge. L2pop
messages will manage the tunnel creation, and, if configured in the
agent, will add an ARP responding entry. If no ARP entry is matched, ARP
packets will be flooded to every vxlan tunnel, and the correct tunnel
will be learned.

-In LB, when l2pop is activated, vxlan tunnel ports are created with the
"mode proxy" to activate the ARP responder, populated by l2pop. If a ARP
packet doesn't match any entry in the ARP responder table of any of the
vxlan tunnel ports, ARP packets are dropped. There is no fallback mode
which would flood the packet to every vxlan tunnels to learn the correct
tunnel for the following packets, and populate the ARP table.

A possible implementation to fix this issue would be to add a multi-bound flag to fdb entries that correspond to a port which is hosted on several hosts (such as HA routers' ports).
The corresponding fdb message would looks like this : 

{net_id:
  {port:
    {agent_ip1 :
      {mac1, ip1, multi-bound}
    }
    {agent_ip2 :
      {mac1, ip1, multi-bound}
    }
  }
   network_type:
     vxlan,
   segment_id:
     id
 }

When the LB agent will receive this fdb message, it will populate the corresponding ARP responder entry (through the "ip neigh replace" command), but won't populate the fdb entry (through the "bridge fdb add" command).
This will result in having packets to HA router ports flooded to every vxlan tunnels. Once the first response will be received, the vxlan kernel module will learn on which vxlan tunnel the following packets have to be sent.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: l2-pop linuxbridge

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1411752

Title:
  linuxbridge : HA routers interact badly with l2pop

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  This bug comes from a split of the bug #1365476 which will now be
  dedicated to an OVS fix

  There is big difference between OVS and LB when using vxlan tunnels
  managed by l2pop :

  -In OVS, vxlan tunnels are plugged into the br-tun bridge. L2pop
  messages will manage the tunnel creation, and, if configured in the
  agent, will add an ARP responding entry. If no ARP entry is matched,
  ARP packets will be flooded to every vxlan tunnel, and the correct
  tunnel will be learned.

  -In LB, when l2pop is activated, vxlan tunnel ports are created with
  the "mode proxy" to activate the ARP responder, populated by l2pop. If
  a ARP packet doesn't match any entry in the ARP responder table of any
  of the vxlan tunnel ports, ARP packets are dropped. There is no
  fallback mode which would flood the packet to every vxlan tunnels to
  learn the correct tunnel for the following packets, and populate the
  ARP table.

  A possible implementation to fix this issue would be to add a multi-bound flag to fdb entries that correspond to a port which is hosted on several hosts (such as HA routers' ports).
  The corresponding fdb message would looks like this : 

  {net_id:
    {port:
      {agent_ip1 :
        {mac1, ip1, multi-bound}
      }
      {agent_ip2 :
        {mac1, ip1, multi-bound}
      }
    }
     network_type:
       vxlan,
     segment_id:
       id
   }

  When the LB agent will receive this fdb message, it will populate the corresponding ARP responder entry (through the "ip neigh replace" command), but won't populate the fdb entry (through the "bridge fdb add" command).
  This will result in having packets to HA router ports flooded to every vxlan tunnels. Once the first response will be received, the vxlan kernel module will learn on which vxlan tunnel the following packets have to be sent.

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