[161326] in North American Network Operators' Group
RE: internet routing table in a vrf
daemon@ATHENA.MIT.EDU (Matt Newsom)
Fri Mar 8 11:40:30 2013
From: Matt Newsom <matt.newsom@RACKSPACE.COM>
To: beavis daniels <beavis.daniels@gmail.com>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Fri, 8 Mar 2013 16:40:01 +0000
In-Reply-To: <CA+MOkACrH1LJekpne4dDsrw7d0T13Pnge5FviX8vVOcLS1u+fg@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Internet in a vrf is doable on most platforms and definitely adds a lot of =
flexibility.=20
1) control plane (route reflectors )
This is really dependent on your platform and whether you are doi=
ng multiple RD's or not. If you divide your transit into regions and filter=
based upon RT you can tier your route-reflectors to get plenty of scalabi=
lity.
2) forward plane (recursive lookup issues)
Most platforms program prefix's with associated labels slower so =
your base convergence will suffer. In addition if you want to run PIC you w=
ill likely be left with a bit of custom engineering to make it work. VPN'=
s hide the next hop behind the loopback of the PE so next hop failure aware=
ness of an edge tie will be lost. If you can stomach the double lookup you =
can run per-vrf labels (per prefix isn't feasible on most platforms) and we=
ight up your edge ties and force a bounce back to another PE, otherwise you=
will be stuck with bgp control plane based convergence with per-ce labels.
3) Operational
It's definitely harder to train operation people on how to look in a=
vrf.
4) DDOS
It's actually much easier to design a DDOS filtering system if every=
thing is in VRF's. If you create separate vrf's for transit and subscriptio=
n your can have extreme flexibility in DDOS filtering. The import export fl=
exibility allows for injection of /32 or /128's into your transit vrf and y=
ou can simply hang your DDOS mitigation seems between the transit and subsc=
ription VRF's.
5) BCP and RFC that would break eg "BGP-SEC does not support in todays dra=
ft to check prefixs within the VPN"
We haven't found any significant functionality we would want to use =
other than PIC that it would break, and there was a work around with that.
6) Vendor specifics
You are probably ok with most vendors but a few still have issues with =
table carving, and a few don't support 6VPE.
=20
-----Original Message-----
From: beavis daniels [mailto:beavis.daniels@gmail.com]=20
Sent: Thursday, March 07, 2013 2:23 PM
To: nanog@nanog.org
Subject: internet routing table in a vrf
hi
I would to enquire about the cons/pros of running a full internet routing t=
able in a vrf and the potential challenges of operating it in a VPN cross a=
large network that does peering and provide transit.
I not a fan to support running it in a vrf.
I am looking for a list of operational and technical challenges
specifically around
1) control plane (route reflectors )
2) forward plane (recursive lookup issues)
3) Operational
4) DDOS
5) BCP and RFC that would break eg "BGP-SEC does not support in todays dra=
ft to check prefixs within the VPN"
6) Vendor specifics
