<div dir="auto">You dont need a stretched provisioning network when you setup a DHCP relay :)</div><div dir="auto"><br></div><div dir="auto">IMO the L2 external network in Neutron is a major issue in OpenStack scaling. I’d love to see a BGP support in OVN and OVN neutron plugin.</div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Oct 2021 at 21:28 Francois <<a href="mailto:rigault.francois@gmail.com">rigault.francois@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">(yes we are using distributed fips) Well we don't want stretched<br>
VLANs. However... if we followed the doc we would end up with 3<br>
controllers in the same rack which would not be resilient. Since we<br>
have just 3 controllers plugged on specific, identified ports, we<br>
afford to have a stretched VLAN on these few ports only. For the<br>
provisioning network, I am taking a shortcut since this network should<br>
basically only be needed once in a while for stack upgrades and<br>
nothing interesting (like mac addresses moving) happens there. The<br>
data plane traffic, that needs scalability and resiliency, is not<br>
going through these VLANs. I think stretched VLANs on leaf spine<br>
networks are forbidden in general for these reasons (large L2<br>
networks? STP reducing the bandwidth? broadcast storm? larger failure<br>
domain? I don't know specifically, I would need help from a network<br>
engineer to explain the reason).<br>
<br>
 <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/spine_leaf_networking/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/spine_leaf_networking/index</a><br>
<br>
<br>
On Tue, 12 Oct 2021 at 18:04, Tony Liu <<a href="mailto:tonyliu0592@hotmail.com" target="_blank">tonyliu0592@hotmail.com</a>> wrote:<br>
><br>
> I wonder, since there is already VXLAN based L2 across multiple racks<br>
> (which means you are not looking for pure L3 solution),<br>
> while keep tenant network multi-subnet on L3 for EW traffic,<br>
> why not have external network also on L2 and stretched on multiple racks<br>
> for NS traffic, assuming you are using distributed FIP?<br>
><br>
> Thanks!<br>
> Tony<br>
> ________________________________________<br>
> From: Francois <<a href="mailto:rigault.francois@gmail.com" target="_blank">rigault.francois@gmail.com</a>><br>
> Sent: October 12, 2021 07:03 AM<br>
> To: openstack-discuss<br>
> Subject: [neutron] OVN and dynamic routing<br>
><br>
> Hello Neutron!<br>
> I am looking into running stacks with OVN on a leaf-spine network, and<br>
> have some floating IPs routed between racks.<br>
><br>
> Basically each rack is assigned its own set of subnets.<br>
> Some VLANs are stretched across all racks: the provisioning VLAN used<br>
> by tripleo to deploy the stack, and the VLANs for the controllers API<br>
> IPs. However, each tenant subnet is local to a rack: for example each<br>
> OVN chassis has a ovn-encap-ip with an IP of the tenant subnet of its<br>
> own rack. Traffic between 2 racks is sent to a spine, and leaves and<br>
> spines run some eVPN-like thing: each pair of ToR is a vtep, traffic<br>
> is encapsulated as VXLAN, and routes between vteps are exchanged with<br>
> BGP.<br>
><br>
> I am looking into supporting floating IPs in there: I expect floating<br>
> IPs to be able to move between racks, as such I am looking into<br>
> publishing the route for a FIP towards an hypervisor, through BGP.<br>
> Each fip is a /32 subnet with an hypervisor tenant's IP as next hop.<br>
><br>
> It seems there are several ideas to achieve this (it was discussed<br>
> [before][1] in ovs conference)<br>
> - using [neutron-dynamic-routing][2] - that seems to have some gaps<br>
> for OVN. It uses os-ken to talk to switches and exchange routes<br>
> - using [OVN BGP agent][3] that uses FRR, it seems there is a related<br>
> [RFE][4] for integration in tripleo<br>
><br>
> There is btw also a [BGPVPN][5] project (it does not match my usecase<br>
> as far as I tried to understand it) that also has some code that talks<br>
> BGP to switches, already integrated in tripleo.<br>
><br>
> For my tests, I was able to use the neutron-dynamic-routing project<br>
> (almost) as documented, with a few changes:<br>
> - for traffic going from VMs to outside the stack, the hypervisor was<br>
> trying to resolve the "gateway of fIPs" with ARP request which does<br>
> not make any sense. I created a dummy port with the mac address of the<br>
> virtual router of the switches:<br>
> ```<br>
> $ openstack port list --mac-address 00:1c:73:00:00:11 -f yaml<br>
> - Fixed IP Addresses:<br>
> - ip_address: 10.64.254.1<br>
> subnet_id: 8f37<br>
> ID: 4028<br>
> MAC Address: 00:1c:73:00:00:11<br>
> Name: lagw<br>
> Status: DOWN<br>
> ```<br>
> this prevent the hypervisor to send ARP requests to a non existent gateway<br>
> - for traffic coming back, we start the neutron-bgp-dragent agent on<br>
> the controllers. We create the right bgp speaker, peers, etc.<br>
> - neutron-bgp-dragent seems to work primarily with ovs ml2 plugin, it<br>
> selects fips and join with ports owned by a "floatingip_agent_gateway"<br>
> which does not exist on OVN. We can define ourselves some ports so<br>
> that the dragent is able to find the tenant IP of a host:<br>
> ```<br>
> openstack port create --network provider --device-owner<br>
> network:floatingip_agent_gateway --host cpu35d.cloud --fixed-ip<br>
> ip-address=10.64.245.102 ag2<br>
> ```<br>
> - when creating a floating IP and assigning a port to it, Neutron<br>
> reads changes from OVN SB and fills the binding information into the<br>
> port:<br>
> ```<br>
> $ openstack port show -c binding_host_id `openstack floating ip show<br>
> 10.64.254.177 -f value -c port_id`<br>
> +-----------------+----------------------------------------+<br>
> | Field | Value |<br>
> +-----------------+----------------------------------------+<br>
> | binding_host_id | cpu35d.cloud |<br>
> +-----------------+----------------------------------------+<br>
> ```<br>
> this allows the dragent to publish the route for the fip<br>
> ```<br>
> $ openstack bgp speaker list advertised routes bgpspeaker<br>
> +------------------+---------------+<br>
> | Destination | Nexthop |<br>
> +------------------+---------------+<br>
> | <a href="http://10.64.254.177/32" rel="noreferrer" target="_blank">10.64.254.177/32</a> | 10.64.245.102 |<br>
> +------------------+---------------+<br>
> ```<br>
> - traffic reaches the hypervisor but (for reason I don't understand) I<br>
> had to add a rule<br>
> ```<br>
> $ ip rule<br>
> 0: from all lookup local<br>
> 32765: from all iif vlan1234 lookup ovn<br>
> 32766: from all lookup main<br>
> 32767: from all lookup default<br>
> $ ip route show table ovn<br>
> 10.64.254.177 dev vlan1234 scope link<br>
> ```<br>
> so that the traffic coming for the fip is not immediately discarded by<br>
> the hypervisor (it's not an ideal solution but it is a workaround that<br>
> makes my one fIP work!)<br>
><br>
> So all in all it seems it would be possible to use the<br>
> neutron-dynamic-routing agent, with some minor modifications (eg: to<br>
> also publish the fip of the OVN L3 gateway router).<br>
><br>
> I am wondering whether I have overlooked anything, and if such kind of<br>
> deployment (OVN + neutron dynamic routing or similar) is already in<br>
> use somewhere. Does it make sense to have a RFE for better integration<br>
> between OVN and neutron-dynamic-routing?<br>
><br>
> Thanks<br>
> Francois<br>
><br>
><br>
><br>
><br>
> [1]: <a href="https://www.openvswitch.org/support/ovscon2020/slides/OVS-CONF-2020-OVN-WITH-DYNAMIC-ROUTING.pdf" rel="noreferrer" target="_blank">https://www.openvswitch.org/support/ovscon2020/slides/OVS-CONF-2020-OVN-WITH-DYNAMIC-ROUTING.pdf</a><br>
> [2]: <a href="https://docs.openstack.org/neutron/latest/admin/config-bgp-dynamic-routing.html" rel="noreferrer" target="_blank">https://docs.openstack.org/neutron/latest/admin/config-bgp-dynamic-routing.html</a><br>
> [3]: <a href="https://ltomasbo.wordpress.com/2021/02/04/openstack-networking-with-bgp/" rel="noreferrer" target="_blank">https://ltomasbo.wordpress.com/2021/02/04/openstack-networking-with-bgp/</a><br>
> [4]: <a href="https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/triplo-bgp-frrouter.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/triplo-bgp-frrouter.html</a><br>
> [5]: <a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/neutron-bgpvpn.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/neutron-bgpvpn.yaml</a><br>
><br>
<br>
</blockquote></div></div>