[c-nsp] Central services VRF, how to

[Peter Rathlev]

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. :-)

-- 
Peter