[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