[c-nsp] VRF RD/RT... your preferences?

[Christian MacNevin]

For a long time I've preferred unique RDs per VRF per PE. The reason  
is that the Route Reflector
operates as a standard BGP router and will make a single best path  
decision then propogate
that to all its clients. If there is a single RD per VRF per PE,  
however, then the RR stores each of
these as an individual vpnv4 table, and forwards the whole lot to the  
clients. With this you're able
to let each PE make its own best path decision and you can play with  
anycast (aka 'routing')
in your network. You get faster convergence as the PEs are all aware  
of multiple paths and if they
lose an exit point on their own global table (ie a PE goes down) then  
they'll have potential backup
routes already there to choose from rather than waiting for BGP to  
converge.

As for the RTs, I'd organise those based on your topology. Hub and  
spoke and full mesh are the two normal
site-to-site paradigms, but most enterprise networks are (I believe)  
using overlaid multiregional hub and spoke
service models which you can control with secondary sets of RTs if you  
want to - again - play with
anycast for stuff like DNS redundancy. So anyway, uniqueness isn't as  
important, and should be based
on customer/function.

All IMO obviously :)




On Sep 24, 2008, at 7:37 AM, Jeff Kell wrote:

The recent discussion of VRFs, RDs, RTs, VPNv4 labels, etc was
interesting, and starting to sink in.

I've been in early stages of a VRF-lite deployment for some time.
Admittedly, from a VRF-lite perspective, a lot of the configuration is
essentially cut-and-paste, and most of the values you can just make up
as you go along as long as you're consistent.  I'm guilty as charged
:-)  We have essentially one PE, multiple CEs, and no real MPLS going on
anywhere; just VRF-lite and dot1q trunks/dedicated vlans to connect them
together.

However... one never knows what the future holds, and if the current
economic crisis doesn't get us all, we might actually have multiple PEs
and/or real MPLS one of these days.

If that happens, I would prefer not to have to renumber/relabel/etc
everything in a fit of  "If I had only known better..." musings under my
breath.

With that said... what should REALLY be used for RDs / RTs?

I'm currently using "ASN:vlan-id" for RTs, this identifies our ASN and
the vlan ID used in the VRF-lite trunk mesh to carry the VRF into the  
CEs.

I am using the same label for RD at the moment, but I noticed in an
earlier discussion that the RD should be unique across the net (where in
my case it's common).

Should the RD reference the router IP?  The global VRF loopback, or an
interface address within the VRF?

If I get a request to run an MPLS link out to a new research station
halfway across the country, will this numbering scheme fit into an MPLS
carrier's scheme?

Jeff
_______________________________________________
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/