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 <dwh...@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 > >
