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. :-)
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
