Hello Robert, I believe I understand what you mean and I see that without the bgp-ipv4+label sessions RRs don't need to encapsulate the ip packet with a label on the first hop towards the core and thus there's no need to enable mpls on the interfaces towards the core So the sessions between the inter-as-rrs in different ASNs can be built over the pure ip And in case the P-core routers have the routes for remote AS RRs than a default route from Inter-AS-RRs toward the P-core routers is sufficient
However I'm not sure about the unnecessity to advertise the PE loopbacks as the NHs for VPNv4 routes between the ASNs Let's say you are not changing the VPNv4 route's next hops anywhere throughout the control-plane path (option C) -so that the RRs stays off the data-path PEs will announce them selves as the next-hops for the VPNv4 routes -these will be advertised to Intra-AS-RRs from there they are advertised to local AS PEs and Inter-AS-RRs - next-hop unchanged >From the local AS Inter-AS-RRs the VPNv4 routes are than advertised via eBGP >sessions to other Inter-AS-RRs in different ASNs - next-hop unchanged Than within the remote ASNs Inter-AS-RRs would advertise the VPNv4 routes to PEs within that particular AS - next-hop unchanged Now the PEs have the VPNv4 prefixes with a next hop of the PE from a remote AS -that's for the control plane Now the data packet needs to be forwarded from the local AS PE to the remote AS PE But since the NH for the VPNv4 route can't be found in the local RIB I believe the route would most likely not even make it from the VPNv4-BGP-table to the ipv4-VRF-table on the PE so the data-plane forwarding fails adam -----Original Message----- From: Robert Raszuk [mailto:[email protected]] Sent: Wednesday, August 31, 2011 5:15 PM To: Vitkovsky, Adam Cc: [email protected]; Mack McBride; [email protected] Subject: Re: [c-nsp] ASR opinions.. Hello Adam, Please see inline ... > Hi Robert, > > Yes please I was referring to pure control plane RRs and bgp-free > core > > For Intra-AS-RRs to create sessions with PEs other Intra-AS-RRs and > Inter-AS-RRs within the AS -the RRs would advertise their loopbacks > via isis or ospf -and set the overload bit or maximum-metric > respectively -so that they are not on the datapath(NH-unchaged by > default) -as you mentioned static-routes and NH-tracking in favour of > IGP works For VPNv4 -RIB is not populated as there are no vrfs > configured on RRs For IPv4 -we can use the table-map filter Ok this is clear. > What I was talking about where sessions between Inter-AS-RRs in > different ASNs Long storry short -to establish ebgp session with one > another over the bgp-free core within each AS -there has to exist an > end-to-end LSP between the Inter-AS-RRs It's like you always need a > sort of data-plane to carry the control-plane sessions I disagree you need an LSP to establish an eBGP sessions. eBGP multihop session will get establish just fine between loopbacks of RRs in different ASes over pure IP routing. So from RR point of view single default to a core box which given RR is attached is sufficient. Carrying as many /32s in your IGP as your Inter-AS Option C RR peers is never an issue. Also RR loopback address has to be known in the local AS IGP but I guess this is obvious as all clients will need to peer with it anyway. So that means that IGP will have also those few extra loopbacks for remote RRs. > In Inter-AS-MPLS-VPNs option C For Inter-AS-RRs to create sessions > with Inter-AS-RRs in other ASNs as well as to keep the Inter-AS-RRs > off the datapath (NH-unchanged) -the local AS has to have a knowledge > of the PE loopbacks(as NHs) and Inter-AS-RR loopbacks(as eBGP session > src/dst) from the remote ASNs > > You can exchange this loopbacks/NHs via BGP-ipv4 + lables between > ASNs at the ASBRs And at the ASBRs -you can either redistribute this > information to the local AS IGP -and let the IGP/LDP to distribute > this information to all routers within the local AS including > P-cores Exactly - that would be my recommendation. But only to RR loopbacks. PEs loopbacks (which are vpnv4 next hops) would still not be redistributed into the IGP and carried with labeled BGP. > Or you can use BGP-ipv4 + label + NH-self sessions -to distribute the > remote AS loopbacks from ASBRs only to where it's necessary over the > bgp-free core That is from/to PEs -so they can route the data-trafic > towards the PEs in remote ASNs And from/to Inter-AS-RRs so they can > establish VPNv4 sessions to Inter-AS-RRs in differnet ASNs I understand now what you are describing. That's doable but a bit fragile as now for your ebgp sessions to external RRs you depend on two components .. 3107 in BGP as well as LDP/IGP. I really see no need to run LDP on the control plane RRs for only saving injection of few /32s into your IGP. Only few as you do not need to inject PEs from other ASes .. you only need to inject RRs from other ASes with is at most a few hosts routes. > In either case you need the LSP to exist between the Inter-AS-RRs So > tht they can establish the eBGP sessions with one another Not in the former pure IP case. > Inter-AS-RRs----------------------VPNv4-------------------------Inter-AS-RRs > > Inter-AS-RRs--ipv4+label--ASBR--ipv4+label--ASBR--ipv4+label--Inter-AS-RRs > I-AS-RRs-igp+ldp-P-igp+ldp-ASBR ASBR-igp+ldp-P- > igp+ldp-I-AS-RRs > > -of course you can utilise your Intra-AS-RRs to distribute the > loopbacks + lables from ASBRs to all the PEs and Inter-AS-RRs within > the local AS So to summarize what you are doing will work however IMHO I would not establish ebgp sessions between Inter-AS option C RRs the way you are proposing. I would keep the eBGP RR multihop sessions running over pure IP, I would not even enable LDP on control plane RRs and would carry few extra loopback addresses in my IGP. Cheers, R. > adam -----Original Message----- From: Robert Raszuk > [mailto:[email protected]] Sent: Wednesday, August 31, 2011 2:15 PM > To: Vitkovsky, Adam Cc: [email protected]; Mack McBride; > [email protected] Subject: Re: [c-nsp] ASR opinions.. > > Hi Adam, > > The discussion is about control plane RRs. > > Therefor in control plane RRs you do not need to have any LSP on > those nor populate 3107 to RIB/LFIB. A default will work equally well > for Next Hop Tracking to consider your BGP next hops as valid in any > address family (if that is your concern). > > Of course if you would set next hop self on such RRs and start/end > LSP there making it to be a dataplane box of course you better feed > the LFIB but not otherwise. > > Cheers, R. > > >> Right the default route would work nicely with bgp free core and no >> IGP on the Intra-AS-RRs But it won't work for Inter-AS-RRs Because >> you don't wan the local AS IGP to be "polluted" with the remote >> ASNs PEs and Inter-AS-RRs loopbacks so you rather want to carry >> those in bgp-afi-ipv4 + labels In this case you need the >> bgp-ipv4-afi to feed the FIB and LFIB on the Inter-AS-RRs As you >> need the end to end LSPs in order to setup sessions between >> Inter-AS-RRs in different ASNs >> >> >> adam >> >> -----Original Message----- From: [email protected] >> [mailto:[email protected]] On Behalf Of Mark Tinka >> Sent: Tuesday, August 30, 2011 6:33 AM To: Mack McBride Cc: >> [email protected] Subject: Re: [c-nsp] ASR opinions.. >> >> On Tuesday, August 30, 2011 03:08:17 AM Mack McBride wrote: >> >>> I would recommend a default to the core from the device to >>> achieve ping/traceroute. >> >> Not necessary - the majority of troubleshooting cases will be for >> customers in the network. We run a BGP-free core, but the route >> reflectors have direct access to the edge, so IP forwarding would >> suffice. >> >> Mark. >> >> _______________________________________________ cisco-nsp mailing >> list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at >> http://puck.nether.net/pipermail/cisco-nsp/ >> >> > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
