Adam, On Jan 3, 2017, at 10:10 AM, adamv0...@netconsultings.com<mailto:adamv0...@netconsultings.com> wrote:
But what happens next or in parallel? Does BGP parse through the local MP-BGP table first in attempt to import at least the local routes into the NEW VRF as soon as possible? If there's no local target for l3vpn route and the box is not otherwise a route reflector or ebgp speaker, we'll drop the route from bgp.l3vpn.0. (I.e. the box is a PE-only role.) While we still do the import table scan, the routes in many cases won't be there. This step is actually why I posted the question. We encountered a problem where it takes 5-10 minutes for local routes, that are already installed in other VRFs on the PE, to get installed from L3VPN table into a newly configured VRF table. By this, you mean you have some route that has a route-target that is already installed in VRF A to be installed also in VRF B that has an overlapping target? Since I posted this question we've started testing the behaviour and in the lab it seems that the "local routes parsing/import" is done as the first thing, or at least right after the route refresh is sent out, so the routes are leaked from bgp.l3vpn.0. into the NEW VRF table right away in the lab. The work is done in parallel. Think of it as the same type of work that is done when policy needs to be re-evaluated; we will walk the tables as part of the work until it's done. So it must be something in the production (config) that is slowing things down. That usually implies scale. Remember the work is part of general table re-evaluation, so it's likely the total number of routes in your system. -- Jeff _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp