[c-nsp] Central services VRF, how to

[Ivan]

A number of years ago I came across some limitations regarding the 
number of route targets that could be associated with a prefix.  I do 
not recall the details but one could imagine that there is some limit to 
the number or RTs (64 bits) that can be attached to a prefix (exported). 
  I have not been able to find any Cisco documentation but if indeed 
this is the case the solution you propose would only be possible up 
until a certain number of customer VRFs.

Googling found this good reference, although I thought the number I came 
across was much less - perhaps an older softwrae limitaion.

http://blog.ioshints.info/2011/05/scalability-of-common-services-mplsvpn.html

Cheers

Ivan

On 24/Nov/2011 9:35 a.m., Peter Rathlev wrote:
> Before I make a complete fool of myself I thought I'd ask you nerds. :-)
>
> I'm testing setting up a "central services" VRF that's supposed to
> service 30-something other VRFs. The idea is of course to have all the
> other VRFs be able to reach stuff within this VRF and vice versa.
> Overlapping addressing is not a concern here.
>
>> From "school" (642-611) I learned that one would use different "hub" and
> "spoke" route-targets, like described in RFC 4364 4.3.5. Something like
> this:
>
> ip vrf CustA
>   rd 1:1
>   route-target both 1:1    !<-- "own" RT
>   route-target import 2:1  !<-- import from "spoke" RT
>   route-target export 2:2  !<-- export to "hub" RT
> !
> ip vrf CustB
>   rd 1:2
>   route-target both 1:2    !<-- same as above...
>   route-target import 2:1
>   route-target export 2:2
> !
> ip vrf CS
>   description Central Services
>   rd 3:1
>   route-target both 3:1
>   route-target import 2:1  !<-- import from "hub" RT
>   route-target export 2:2  !<-- export to "spoke" RT
> !
>
> What I don't like about this is that I'd have to configure each and
> every PE in each of the "customer" VRFs. Why not just do like this:
>
> ip vrf CustA
>   rd 1:1
>   route-target both 1:1    !<-- Completely plain VRF
> !
> ip vrf CustB
>   rd 1:2
>   route-target both 1:2
> !
> ip vrf CS
>   description Central Services
>   rd 3:1
>   route-target both 3:1
>   route-target both 1:1    !<-- Import&  export CustA
>   route-target both 1:2    !<-- Import&  export CustB
> !
>
> Any gotchas with this compared to the former? What am I missing that the
> school book example would give me? AFAICT I would only need this
> configuration on the PE devices actually hosting CS networks, since I
> export directly to all the relevant VRFs.
>
> This is very simplified. I would of course use an import map on the CS
> VRF and also make sure that only the relevant prefixes are exported from
> it. (The networks I'd like to "CS-ify" would be the only ones in that
> VRF on that PE; external routes (default etc.) would come from another
> PE that wouldn't have this configuration.)
>
> I also tested exporting via a route-map, and though it seems to scale a
> little better on account of not needing the "route-target export"
> statements, I can find no functional differences.
>
> Feel free to refer me to literature, "fine" or otherwise. :-)
>