Re: internet routing table in a vrf

[PC <paul4004 () gmail com>]

I've done this on multiple vendor platforms, including full routes, and
haven't had any issues.  Resource consumption varies on vendor and
implementation, but I've observed that its not as punitive as I thought it
would be due to various optimizations.  Granted, in most of my cases, it
was in a VRF, but I was not running MPLS.


On Thu, Mar 7, 2013 at 2:23 PM, Dan White <dwhite () olp net> wrote:

> On 03/07/13 22:22 +0200, beavis daniels wrote:
>
> > hi
> >
> > I would to enquire about the cons/pros of running a full internet routing
> > table 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
> > draft to check prefixs within the VPN"
> > 6) Vendor specifics
>
> We decided against deploying our internet routes via vpnvX. Two major
> holdups for us were:
>
> Each route inside a vpnv4 table will consume more cam (96 bits versus
> 32), which adds up when taking full routes.
>
> Brocade XMR does not support distributing routes via vpnv6, or it did not
> when we were designing our MPLS network.
>
> One of the benefits of distributing internet routes inside a VRF is that it
> logically separates those routes from your IGP routing tables (your P
> routers don't see internet routes). Keeping internet routes inside your
> default VRF may lead to unexpectedly leaking IGP routes out to your BGP
> sessions, so BGP filters are important, as well as using unique (RIR)
> addresses inside your MPLS mesh.
>
> --
> Dan White