yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <2098621@xxxxxxxxxxxxxxxxxx>]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

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

Title:
  ports can attempt to bind to the wrong segment

Status in neutron:
  Expired

Bug description:
  First, to define my use case: I am attempting to control the network
  across a large DC footprint. There are many servers and many racks of
  those servers. We are using a L2VNI based fabric, using BGP EVPN, with
  a pair of leaf switches for each rack. Each of the leaf switches
  exposes a VLAN to the server that is mapped to a VNI, and in some of
  those cases, the servers will be trunked with multiple VLAN and
  they’ll have to tag that to each VLAN. For this model, we would like
  to use Neutron, so I am using the VXLAN type with the ML2 plugin and
  my own mechanism because networking-generic-switch doesn’t support
  this today. There is some prior art around this from Juniper and
  Cisco. The reason for this is that we will be running many tenant
  networks. They would exceed 4096 total for each fabric. Since neutron
  cannot configure a neutron network node to participate in BGP EVPN,
  ach leaf that contains a neutron network node has a VLAN segment with
  the physical_network value set to the leaf pair switch name. Future
  additions will be hypervisors which will have segments for those leaf
  pair switches. In this case OVN would be able to have a mapping for
  VLAN and the physical_network that’s appropriate for that neutron
  network node or hypervisor. I believe this is a valid configuration /
  use case based on the routed network spec which contains a section
  about L2 adjacency.

  This setup almost works. OVN unfortunately does not setup the router
  correctly. I’ve had to run “ovn-nbctl lrp-set-gateway-chassis <lrp>
  <chassis>” manually and then everything works.

  https://review.opendev.org/c/openstack/networking-generic-switch/+/939211 led me to 
  https://review.opendev.org/c/openstack/neutron/+/840418

  Which I believe leads me to the reason. The port is not tied to a
  specific segment but instead the segment its part of is looked up
  based on the IP of the port and the subnet that port belongs to. From
  that subnet the segment is found and used. When there is no
  physical_network, as is the case for the VXLAN segment, it is added to
  the list. Then when the actual segment is found by the
  physical_network, it is added to the list. Then only the first entry
  in the list is used for binding. Which results in binding attempting
  to be done for the VXLAN segment, which doesn’t match the mapping for
  my neutron network node and there for its ignored.

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