[c-nsp] Internet routes, Global Routing table or VRF

Mike Butash der.mikus at gmail.com
Tue Apr 11 03:44:22 EDT 2006


I'm kinda curious what the opinion on this is as well from the 
community, actually...

    We currently do all internet routing table entries in the global 
table, with little need to carry these inside a vrf, and this seems to 
be the most popular method from speaking to people within cisco.  This 
allows for the global table to be the melding pot for everything inside 
and out, and use vrf's for internal transit use when private networks 
are required for transit outside of the common backbone (via igp 
generally speaking).  BGP works as bgp in the global, and you don't have 
to worry too much about label stacking or redistributions vrf bleeds for 
mutual relationships that come about.  You get to avoid the bugs that 
come with those import/export redistributions too (i reloaded a 6500 on 
12.2SXE3 in a lab 3 times just playing with vrf bleeds over the span of 
an hour or so).

    There are of course possible circumstances where you'd want to dump 
inet routes into a vrf for customers use potentially, but when you're 
talking about vrf connectivity, it's for a pe handoff to ce generally, 
where it's going to be igp or static anyways.  As an isp or carrier, it 
might be beneficial if you wanted to use route map matching based on the 
ext-community to influence things a certain way, but that's easy enough 
to do without vrf's.  Transit purposes even perhaps, but you're 
duplicating those routes in memory as well I believe at that point, and 
you just need to make sure the device has the memory.  Our use of vrf 
features generally is for enterprise use, and isn't required to put the 
internet into our office cores.

    Now, in cisco's reality, their management teams seem to see fit to 
ignore the fact that staple platforms like a cat6500 still do not have 
vrf-aware management functionality for almost anything, so you end up 
dumping management stuff into a global table, back though a firewall to 
your internal management servers, but that just feels dirty, even though 
I know it's still my pipes.   That's what sshv2 and snmpv3 (at least in 
theory, shrugs) for these things.  I initially looked at global vs vrf 
from a management perspective, and began thinking put the global on 
private nets, and route everything in vrf's for hierarchal order to work 
around the management issue.  This seemed problematic, and what I'd 
worked though presented some interesting challenges I didn't have time 
to worry about scaling.  Doing so seemed to go against the grain of what 
cisco devs probably intended, which is where you find your most 
interesting bugs.  In the end, it makes the most sense to do it this 
way, at least from what my experience says, at least until some real 
interesting business case tells me to do otherwise...

    Now, one interesting caveat i found interesting when the need 
actually arose recently to do some interesting things with multi-site 
anomaly guards, is that it is not easy (or not at all) to import global 
routes into a vrf *dynamically*.  I know I can force with static routes, 
but this scales about as well as maintaining a global table in static 
routes in a big environment.  I found a spankin new feature for vrf's 
that allows you to import routes from the ipv4 table via a route-map to 
do whatever you have to and modify the attributes.  I wanted to use this 
to bleed certain igp prefixes from the global table into a vrf 
dynamically based on their next-hop for getting some backend traffic 
automagically home while overriding global /32's back to the guards.  I 
could maintain these with static injections or such into the vrf, but 
that requires constant provisioning where normal routing could suffice.  
Then I found this was only a 12.4 feature, and isn't slated for back 
porting into 12.2SX for my cat6500's usage, which we tend to make bend 
over backward for mpls duty.  I could do some trickery to accomplish 
this, but most of them being an offboard router, and I lose port density 
and backplane capacity for large bandwidth on a 6500 acting as a pe for 
numerous guards.  I'd really like to see this make it into the 12.2SX 
(hint hint).  BGP table-map's can allow for this kind of thing between 
vrf's and ext-communities as well?  I'd appreciate hearing some theories 
on this on or off line.

    What is the right answer?  Whatever your environment dictates, what 
you can afford for hardware, and what caveats or bugs will allow you to 
do within your smartnet support contract.

-mb


Danielsen.Peter Christian PED wrote:

>Best practice, Is that you place all internet peering / transit into
>Global Routing table or into a MPLS VPN..
>
>What is the benefits / disadvantages of both scenarios
>
>/Peter
>
>
>
>
>_______________________________________________________________________________________
>www.kmd.dk   www.kundenet.kmd.dk   www.eboks.dk   www.civitas.dk   www.netborger.dk www.organisator.dk
>
>Hvis du har modtaget denne mail ved en fejl vil jeg gerne, at du informerer mig og sletter den.
>KMD skaber it-services, der fremmer effektivitet hos det offentlige, erhvervslivet og borgerne.
>
>If you received this e-mail by mistake, please notify me and delete it. Thank you.
>Our mission is to enhance the efficiency of the public sector and improve its service of the general public. 
>
>
>_______________________________________________
>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/
>
>  
>



More information about the cisco-nsp mailing list