[c-nsp] VRF and STATIC ROUTE to GLOBAL

[Richard N. Ingram]

Jeff Fitzwater wrote:
> This question was posted earlier, before I opened ticket with CISCO.
> 
> Router is 6500 with 720-CXL running SXI code.
> 
> 
> 1.  I have router "A" which is used to connect to our three ISPs ( two 
> I1s and  one I2 connection with full BGP), and also receives all our 
> internal campus traffic via RIP default path.    Router "A" announces 
> default to campus.
> 
> 2. I now need to add a new special ESNET.GOV ISP which cannot be used by 
> the majority of our campus except for two subnets.   These two subnets 
> will still have access to the other three ISPs for normal path selection 
> but have the option of choosing an ESNET route if needed.
> 
> 3. So the original thinking was to create the VRF for ESNET which would 
> have its own ESNET route table and tell the two special subnets (using 
> route-map match subs, set vrf ) to check the ESNET table first and if 
> route is not in table then fall thru to global.
> 
> 4. I can't just have one route table that includes the ESNET routes, 
> because ESNET announces some more specific routes and there may be hosts 
> that normally use the I1 path to these DSTs, but now see a more specific 
> path and try to use it and fail because it is not allowed by ESNET 
> outbound ACL.
> 
> 
> 
> I have BGP peering working in VRF ( can see prefixes from ESNET in VRF 
> table), but cannot announce our two subnet prefixes because they do not 
> show up in VRF route table.  So getting static back to global would fix 
> this and other issue with DEFAULT to global.   When I try to add static 
> routes they never show up because the next hop is not present in VRF 
> table or the command fails stating that...  "Invalid next-hop address 
> (it's this router)".
> 
> 
> 
> I was hoping that just adding a static DEFAULT in VRF pointing to global 
> would do everything I needed, but cannot get it to work even after 
> trying all permutations of the command.  "ip route vrf vrf-esnet 0.0.0.0 
> 0.0.0.0 0.0.0.0 global"
> 
> 
> 
> Also tried "ip route vrf vrf-esnet 0.0.0.0 0.0.0.0 loopback3 10.10.10.10 
> global"   Loopback3 was created with RFC-1918 IP and had "vrf 
> forwarding" added on this loopback.  This also failed.
> 
> 
> Creating an internal path between the VRF router and the global router 
> is stopping all this from working.
> 
> I have a ticket open with CISCO but they are saying I have to add an 
> external link with two physical ports on vrf.   This will not work for us.
> 
> 
> Does anybody know how to get statics working between VRF and global 
> table,  if its even possible.
> 
> 
> Really stuck!
> 
> 
> 
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
> 

Apologies for not answering your question directly.  In your situation, 
something analogous to what we do would be (you've done some of this 
already):

Create a VRF ESNet on your border router.  Create a VRF ESNet on your 
campus routers.  The global table of your campus routers would be 
connected to the global table of your border router (via RIP).  The 
ESNet VRF of your campus routers would be connected to the global table 
of your border router (via RIP) in order to get a default route.  In 
addition, the ESNet VRF of your campus routers would be connected to the 
ESNet VRF of your border router in order to get the ESNet VRF prefixes.

If you run trunks between your border routers and campus routers, this 
can be accomplished with different VLANs for the different VRF-global 
and VRF-VRF connections.

In a poor attempt at ASCII art, this would look like:

   I1   I1   I2                ESNet
    |    |    |                  |
    |    |    |                  |
    |    |    |                  |
Border Global Table     Border ESNet VRF
         |           \           |
         |            \          |
         |             \         |
Campus Global Table     Campus ESNet VRF

So the hosts in the Campus ESNet VRF could use the default to get to I1 
and I2, or the more specific prefixes to get to ESNet.  In general, I 
tend to like this more than route-leaking between VRFs.  I believe 
multicast doesn't like route-leaking as it causes problems with RPF.  I 
can give you details of our setup offline if you're interested.

Hope that helps,
Rich Ingram
===========================================
Richard N. Ingram
Network Design Engineer
Networking and Telecommunications Services
Office of Information Technology
University of Minnesota
2218 University Avenue SE
Minneapolis, Minnesota 55414
Work Phone: 612-626-6626
Cell Phone: 612-802-8859
E-mail: rni at umn.edu
===========================================