[c-nsp] Internet inside a VRF?

Dan Armstrong dan at beanfield.com
Tue Mar 13 21:29:11 EDT 2012


Two reasons, the first reason is that the config is extremely simple, clean and difficult for a less trained provisioning guy to make a mistake.  With route maps, it's error prone to harmonize them across many boxes - and it's relatively easy for somebody to muck one up by accident.


The other reason is that we have some older folks around that long for the day when the core of a carrier network was ATM based, and the plethora of hops were basically hidden behind a switched network…   They feel that customers will freak out and feel the service is inferior if a traceroute goes through many dozen hops.  Having this inside a VRF lets us hide the hops inside a POP for instance, and only show the major transit points for clarity.






On 2012-03-13, at 9:17 PM, Jose Madrid wrote:

> I would like to understand why you guys would do this? What is the
> reasoning behind this? Super granular control? Cant this level of
> granularity be achieved with route-maps?
> 
> Sent from my iPhone
> 
> On Mar 13, 2012, at 8:27 PM, Dan Armstrong <dan at beanfield.com> wrote:
> 
>> We have all our Internet peers and customers inside a VRF currently, and our Cisco SE thinks we're stark raving mad, and should redesign and put everything back in the global table.
>> 
>> 
>> This is all on ASR 9Ks and 7600s.
>> 
>> 
>> 
>> 
>> 
>> On 2012-03-13, at 8:12 PM, Pshem Kowalczyk wrote:
>> 
>>> Hi,
>>> 
>>> On 14 March 2012 11:59, Dan Armstrong <dan at beanfield.com> wrote:
>>>> I know this topic has been discussed a million times, but just wanted to get an updated opinion on how people are feeling about this:
>>>> 
>>>> 
>>>> In a service provider network, how do people feel about putting the big Internet routing table, all their peers and customers inside a VRF?  Keep the global table for just infrastructure links…
>>> 
>>> In my previous role we've done just that. One internet VRF for all
>>> transit functions, separate vrfs for peering and customers and
>>> import-export statements to tie them all together. All done on ASR1k
>>> (mainly 1006, but a few of 1002 as well).
>>> 
>>> kind regards
>>> Pshem
>> 
>> 
>> _______________________________________________
>> 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