Hi Keshava, I can answer some of your queries. Again, note that the short-term goal is to build on top of the base VRF support introduced into Quagga recently to achieve the following:
a. Ensure 'name' support in configuration and interactions b. Ensure that VRF can work with the VRF device implementation of VRF that has been accepted into the Linux kernel, while not breaking the netns model and paving the way for a hierarchy in future (multiple netns, each implementing multiple VRFs using the VRF-device model). c. Extend VRF support into BGP All these would ensure that the VRF-lite or Multi-VRF implementation in Quagga is complete (of course, without OSPF, RIP etc. yet). Any route leaking across VRFs would initially be possible only through an external device (firewall etc.) Each VRF would be a instance/view in BGP - 'struct bgp' in terms of data structures. The peering towards CEs, whether VRF-lite or full-blown RFC 4364 would be within these instances and the CE-learnt routes would be stored within the corresponding RIBs and installed into Zebra in the corresponding VRF. PEs for RFC 4364 would be configured in the "global" or "default" instance - "address-family vpnvX unicast". Routes to PEs would be advertised from all of the VRF (instance) RIBs in BGP. In the reverse direction, received VPN-IPvX routes would be installed in the VPN-IPvX RIB in the default instance and then "imported" into one or more VRF (instance) RIBs in BGP based on import policies/RTs. Once here, they would get installed into Zebra similar to CE-learnt routes. If the protocol towards the CE is static (or OSPF later on), the routes in the corresponding VRF in Zebra have to be injected into BGP (in corresponding VRF/instance) in order to be advertised to remove PEs. This would follow the model for the default VRF - you have to configure "networks" or perform "redistribute" in the corresponding VRF/instance. Of course, this would be needed for connected routes also. I've glossed over label assignment, nexthop validation etc. in this, but they will all fit in too. Vivek On Wed, Nov 25, 2015 at 10:46 PM, A, Keshava <[email protected]> wrote: > Hi Vipin, > > > > When we say BGPL3 VPN , is it classical RFC 2457biz scenarios of all the > options . > > > > How the below Basic L3 VPN scenario will be handled ? > > Routing facing towards CE (private side) will be multi-instance one ? > > All different VRFs routes will be injected to public-VRF and converted > into L3 VPN routes , will this be done directly Zerba directly ? > > Who Managers these Labels ? Then Public BGP will inject these from > Zerba and updates to remote BGP ? > > > > L3VPN routes received from remote-PE will have relation with MPLS > subsystem ? > > When does BGP makes received routes as active ? Does Quagga/BGP tracks > MPLS-LSP tunnel status between those PE’s ? > > > > How is this multi-VRF is supported ? Each routing protocol will support > multi-instance support ? > > How is the flow of “private VRF routes” getting converted into “ VPN > routes” and visa-versa in Quagga? How will be this architecture ? > > > > This will help to have better common understanding in terms of basic > scale and functionality and overall Quagga L3 VPN architecture. > > > > > > > > > > Regards, > > keshava > > > > *From:* Vipin Kumar [mailto:[email protected]] > *Sent:* Thursday, November 26, 2015 2:56 AM > *To:* Lou Berger; [email protected]; Vivek Venkatraman; Dinesh > Dutt > *Subject:* [quagga-dev 14011] VRF global and protocol specific config > > > > Hi Lou, > > > > Based on what we have in quagga, this is how we seem to be converging on > this: > > (I sent email previously to agree with Paul's suggestion about keeping > view|vrf both) > > > > > > *1. Simple VRF (no lxvpn) case* > > > > *BGP mode config:* > > > > router bgp <asn> vrf <name1> > > > > ! regular peering. > > ! redistribution > > ! import/export of routes between VRFs based on route-targets > > .. > > router bgp <asn> vrf <name2> > > .. > > > > > > *Global VRF mode config:* > > > > (config)# vrf vrf-name > > (config-vrf)# route-target <>:<> ! May be in an address-family specific > way > > (import/export) > > > > *2. L3VPN VRF case* > > > > > > a. BGP as PE-PE, and other IGPs as PE-CE protocols > > > > *BGP mode config:* > > > > router bgp <asn> !default instance with the default-table > > .. > > ! this is where vpn address-family config may belong > > > > router bgp <asn> vrf <name1> > > ! redistribution from IGPs > > ! import/export of routes between VRFs based on route-targets > > .. > > router bgp <asn> vrf <name2> > ! .. > > > > Possibly for OSPF (just like BGP multi-instance per daemon) > > router ospf vrf <name1> > > !adjacency towards CE > > router ospf vrf <name2> > > .. > > > > *Global VRF mode config:* > > > > (config)# vrf vrf-name > > (config-vrf)# route-target <>:<> ! May be in an address-family specific > way > > (import/export) > > > > > > b. BGP as PE-PE, and also as PE-CE protocol > > > > *BGP mode config:* > > > > router bgp <asn> !default instance with the default-table > > .. > ! peering towards other PEs/RR > > ! this is where vpn address-family config may belong > > router bgp <asn> vrf <name1> > > > > ! peering towards CE > > ! import/export of routes between VRFs based on route-targets > > .. > > router bgp <asn> vrf <name2> > ! .. > > > > > > > > *Global VRF mode config:* > > > > (config)# vrf vrf-name > (config-vrf)# route-target <>:<> ! May be in an address-family specific > way > (import/export) > > > > > > BGP l3VPN implementation may work across BGP instances, to work on > import/export of routes. > > > > For static routes import/export between VRFs, can be implemented in Zebra > > > > Do you (or others) see any issue with this config model going forward for > LxVPNs too? > > > > Vipin > > > > > > > > On Sun, Nov 22, 2015 at 6:50 PM, Lou Berger <[email protected]> wrote: > > Vipin, > > So this maps pretty well when talking vrf-lite, but before making this > change I think we should agree upon how tunnel based VRFs are > represented and configured over a core instance so we don't end up with > naming or concept clashes. If not full syntax, I think we should at > least have a direction outlined. > > Have you given any thoughts on how you'd like to handle this? > > Thanks, > Lou > > On 11/22/2015 12:23 AM, Vipin Kumar wrote: > > Hello Quagga-dev, > > > > *Objective of this email: > > * > > > > To see if 'view' keyword can be replaced with 'vrf' > > > > *Why:* > > > > 1. Code and flow to implement VRFs in BGP is turning out to be quite > > similar to how it is for views. VRF in BGP can be considered as a > > super-set of the current views functionality. It should be possible to > > realize views as a special type of VRF, and possibly enable it by a > > config option. > > > > This is to reduce the overhead on implementation (and also on > > usability) to provide both view and vrf options at > > configuration/show/clear/debug commands. > > > > 2. While views may be working for some use-cases, the support in > > 'show commands' is not quite complete yet. > > > > *More Details:* > > > > In a way, this is a follow-up on the VRF discussion we had where we > > suggested we could use the current BGP multi-instance implementation. > > > > Currently, BGP has some support for multiple views. These are > > implemented as separate BGP instances, each with its own set of global > > configuration, neighbors, RIB etc. This effectively makes the mapping > > of a VRF to a view the most logical approach. > > > > bgp multiple-instance > > > > router bgp <asn> view <name1> > > .. > > router bgp <asn> view <name2> > > > > > > For VRFs, one obvious choice is to use similar model with vrf keyword: > > > > router bgp <asn> vrf <name> > > > > If views are currently not being used for any real purpose, they could > > be directly replaced with 'vrf' in the user-interface. A 'type' field > > for the VRF could be introduced later to support other possibilities. > > If views are being used/deployed now, we'd like to know more about how > > they are used. In this case, we will think of a backward compatible > > change to introduce VRFs with views. > > > > Thought to poll the community to see if thinking in this direction > > even makes sense. > > > > Feel free to send unicast responses/or respond to the thread as is. > > > > Regards, > > Vipin > > > > > > > > > > _______________________________________________ > > Quagga-dev mailing list > > [email protected] > > https://lists.quagga.net/mailman/listinfo/quagga-dev > > >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
