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 What I was talking aboutwhere 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 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 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 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 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 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/
