Hi Brian, The each gateway router only has a single transit network attached to it, and each gateway router to connected to the common provider/external network as well. We can probably do away with the transit network if we use router pairing (at a later point).
I will change the transit network from /30 to /31 and not allow broadcast. My email client mangled up the earlier email, I have the proposal also written up in etherpad: https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway <https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway>. Amitabha > On Jun 8, 2016, at 7:18 AM, Brian Haley <brian.ha...@hpe.com> wrote: > > On 06/07/2016 04:50 PM, Amitabha Biswas wrote: >> This proposal outlines the modifications needed in networking-ovn (addresses >> https://bugs.launchpad.net/networking-ovn/+bug/1551717 >> <https://bugs.launchpad.net/networking-ovn/+bug/1551717>) to provide >> Floating IP (FIP) and SNAT using the L3 gateway router patches listed below: >> >> http://patchwork.ozlabs.org/patch/624312/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/624313/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/624314/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/624315/ >> <http://patchwork.ozlabs.org/patch/624312/> >> http://patchwork.ozlabs.org/patch/629607/ >> <http://patchwork.ozlabs.org/patch/629607/> >> >> Diagram: >> >> +-------+ +-------+ >> | NET 1 | | NET 2 | >> +-------+ +-------+ >> | | >> | ********* | >> | ** ** | >> | ** * * ** | >> +---RP1 * DR * RP2 --+ >> ** * * ** >> ** ** >> ********* >> DTRP (168.254.128.2) >> | >> | >> | >> +------------------+ >> | Transit Network | >> | 169.254.128.0/30 | >> +------------------+ >> | >> | >> | >> | >> GTRP (169.254.128.1) >> ******* >> ** ** >> ** * * ** +------------------+ >> * GW *-----------------| Provider Network | >> ** * * ** +------------------+ >> ** ** >> ******* >> >> New Entities: >> >> OVN Join/Transit Networks >> One per Neutron Router - /30 address space with only 2 ports for e.g. >> 169.254.128.0/30 >> Created when an external gateway is added to a router. > > Hi Amitabha, > > If this is just a point-to-point link you can use /31, the neutron DVR code > does this for inter-namespace links between elements. You just need to be > careful and not specify a broadcast address when adding the IP. I'm assuming > the GW in this case has multiple transit networks attached? > > -Brian > > >> One extra datapath per router with an External Gateway. >> (Alternate option - One Transit Network in a deployment, IPAM becomes a >> headache - Not discussed here). >> Prevent Neutron from using that /30 address space. Specify in networking-ovn >> con file. >> Create 1 new “Join” neutron network (to represent all Join OVN Networks) in >> the networking-ovn. >> Note that it may be possible to replace the Join/Transit network using >> Router Peering in later versions (not discussed here). >> Allocate 2 ports in the Join network in the networking-ovn plugin. >> Logical Gateway Transit Router Port (gtrp), 169.254.128.1 >> Logical Distributed Transit Router Port (dtrp), 169.254.128.2 >> Note that Neutron only sees 1 Join network with 2 ports; OVN sees a replica >> of this Join network as a new Logical Switch for each Gateway Router. The >> mapping of OVN Logical Switch(es) Join(s) to Gateway Router is discussed in >> OVN (Default) Gateway Routers below. >> Note that the MAC addresses of lgrp and lip will be the same on each OVN >> Join Network, but because they are in different branches of the network >> topology it doesn’t matter. >> OVN (Default) Gateway Routers: >> One per Neutron Router. >> 2 ports >> Logical Gateway Transit Router Port (gtrp), 169.254.128.1 (same for each OVN >> Join network). >> External/Provider Router Port (legwrp), this is allocated by neutron. >> Scheduling - The current OVN gateway proposal relies on the CMS/nbctl to >> decide on which hypervisor (HV) to schedule a particular gateway router. >> A setting on the chassis (new external_id key or a new column) that allows >> the hypervisor admin to specify that a chassis can or cannot be used to host >> a gateway router (similar to a network node in OpenStack). Default - Allow >> (for compatibility purposes). >> The networking-ovn plugin picks up the list of “candidate” chassis from the >> Southbound DB and uses an existing scheduling algorithm >> Use a simple random.choice i.e. ChanceScheduler (Version 1) >> Tap into the neutron’s LeastRouterScheduler - but that requires the >> networking-ovn (or some a hacked up version of the L3 agent) to imitate the >> L3 agent running on various network nodes. >> Populate the SNAT and DNAT columns in the logical router table. This is >> under review in OVS - >> http://openvswitch.org/pipermail/dev/2016-June/072169.html >> <http://openvswitch.org/pipermail/dev/2016-June/072169.html> >> Create static routing entry in the gateway router to route tenant bound >> traffic to the distributed logical router.ar gate >> >> Existing Entities: >> >> Distributed Logical Routers: >> Set the default gateway of the distributed logical router to the IP Address >> of the corresponding Logical Gateway Transit Router Port (169.254.128.1). >> >> It would be good to get some feedback on this strategy. Guru mentioned that >> he saw a need for ARP response across multiple gateway routers, we don’t see >> that requirement in this design/use-case. >> >> Thanks >> Amitabha (azbiswas) and Chandra (chandrav) >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
