Strategies for migrating lots of customers into L3VPN / route-leaking [x-post from j-nsp]

Thu Oct 9 20:57:45 UTC 2014

[apologies for the x-post-- I didn't get any responses from the j-nsp list,
so I thought I'd try a larger audience- edited to remove some juniper
jargon]

Hi all,

I'm working on virtualizing a regional network with about 500 customer
sites into an L3VPN. All of my customer routes (plus our internet routes)
currently exist in the global table on our routers. The end-state I’d like
to achieve is to have our provider's Internet routes isolated into a VRF
and our customers isolated into their own VRF with vrf-import policies
leaking the routes between the two.

Before someone asks “why?” I’ll just stop that and say that it’s likely
that in the near future I’ll have different customer classes demanding
different upstream providers on the same physical gear but still wanting
the same path/latency to the other customer classes we provide today.

So- I’d like to move our customer routes piecemeal into a VRF in as
controlled a way as possible without causing network segmentation or having
to constrain traffic through specific paths. That way we could move
reasonable sections of the network into the L3VPN over a period of a few
weeks. My first thought was to set up route leaking between the VRFs and
the global table, but looking back at listserv threads as well as Juniper
docs, I realize it's not possible to export MP-BGP learned routes into the
global table using Juniper rib groups.

I'm currently looking into using BGP between logical tunnel interfaces
on the global table and a vrf to accomplish the route sharing, and that
seems like a good possibility, but I’m curious about a few things:

1) Does anyone run production traffic through logical tunnel interfaces
between the global table and routing instances? (we’re using fairly
lightly-loaded MX480s)

2) Does any one have a smarter strategy that I could borrow to accomplish
this transition? It all feels so kludge-y and brittle.

-Dan