[c-nsp] ASR opinions..

Vitkovsky, Adam avitkovsky at emea.att.com
Wed Aug 31 10:53:33 EDT 2011


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:robert at raszuk.net] 
Sent: Wednesday, August 31, 2011 2:15 PM
To: Vitkovsky, Adam
Cc: mtinka at globaltransit.net; Mack McBride; cisco-nsp at puck.nether.net
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: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka
> Sent: Tuesday, August 30, 2011 6:33 AM
> To: Mack McBride
> Cc: cisco-nsp at puck.nether.net
> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 




More information about the cisco-nsp mailing list