internet routing table in a vrf

Fri Mar 8 04:50:15 UTC 2013

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 at 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
>
>