Public bug reported: 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. ** 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/2098621 Title: ports can attempt to bind to the wrong segment Status in neutron: New 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
