[j-nsp] under the hood of MP-BGP

[Jeff Haas]

Adam,

On Jan 3, 2017, at 10:10 AM, adamv0025 at netconsultings.com<mailto:adamv0025 at 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