[c-nsp] Internet in VRF

Nathan Ward cisco-nsp at daork.net
Sun May 3 20:21:54 EDT 2015


On 4 May 2015 at 09:08:38, Pshem Kowalczyk (pshem.k at gmail.com(mailto:pshem.k at gmail.com)) wrote:
> +1 for Internet in a VRF.
>  
> I've deployed this sort of setup for a number of operators. Definitely
> allows for much greater flexibility when it comes to services - everyone
> had to run something more then just 'internet' to the sites (management,
> corporate network, sometimes private VPNs). Not to mention the fact that
> the global table only has to contain the links and loopbacks. It also
> allows for easy separation of peerings in multi-lateral exchanges (when the
> IX has own RRs to peer with) - separating those into VRFs makes sure no
> ones can just use the network for transit. I always kept one 'Internet'
> table that contained all transit providers and customers which required a

If you can afford the RAM and CPU, it’s nice to be able to do a VRF per transit provider, which makes your whole border architecture in to VRF per 3rd party. It can be useful to have full visibility on all your other PEs, so that you can, for example, prefer a certain transit provider at a certain PE, even if the AS_PATH is longer - perhaps you have a network where sending it through the shorter AS_PATH provider may actually mean much higher latency for that particular PE. This is very much a corner case.

> full table. Peering exchanges - VRF per exchange, customers that only
> require a default route - into another (single) VRF. On top of that VRFs
> for things like cache clusters, CDNs etc. A lot of that could be done using
> 'classical' methods, but I think using L3VPN makes this much easier to
> manage. This internet could easily be provided out of low spec boxes (7200,
> ME3600X, ASR903) using exactly the same method, even in unified-MPLS
> topologies.

> If the number of labels is a problem - most platforms can do label per vrf
> or label per CE - that helps greatly.

Per-VRF labelling also lets you advertise a default to your lower-specced edge boxes, and have your higher specced boxes nearer your border choose where to send stuff. You need per-VRF, so that you can put a null default in, and advertise that, and not have your traffic label switched to null - per-VRF does a route lookup when the VPN label is popped.

--
Nathan Ward



More information about the cisco-nsp mailing list