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

[adamv0025 at netconsultings.com]

Hi Jeff,
I was actually of hoping you'll chime in for this one :-). 
Thank you very much. 

> From: Jeff Haas [mailto:jhaas at juniper.net]
> Sent: Tuesday, January 03, 2017 1:45 PM
> 
> Adam,
> 
> > On Dec 23, 2016, at 4:24 AM, adamv0025 at netconsultings.com wrote:
> > Does anyone know any details about what's going on under the hood of
> > MP-BGP when a new VRF is configured?
> >
> >
> >
> > I'm only clear about this part:
> >
> > When a new RT import is configured or when the RT import is removed, a
> > route refresh is sent from the PE to RRs for the affected address
> > families VPNv4/6.
> >
> > When a new VRF is configured, the PE sends a route-refresh to RRs.
> >
> > In both cases the RRs do send all VPNv4/6 prefixes to the PE.
> >
> > (In case of RT filter RRs will only send the set of routes according
> > to the RT filter advertised by PE).
> 
> All correct so far.  Junos is unfortunately a bit aggressive about route
> refreshes and really should be a bit more selective about which families
it
> does the refresh for.
> 
Aah yes indeed it would be nice if the "route refresh"/"rt filter refresh"
was sent only for the affected AF. 
 

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

So it must be something in the production (config) that is slowing things
down. 



> >
> > With regards to VPN routes coming in from RR,
> >
> > does PE wait till EOR/keepalive from RR in order to start best path
> > selection and then parsing to determine which routes needs to be
> > installed into the NEW VRF?
> 
> It's done inline as Junos receive the routes.
> 
Yes I can see it in the lab now. 

> >
> > Are there any mechanisms in use to speed up parsing through the MP-BGP
> > table and installation of paths into NEW VRF?
> >
> > Are VPN routes grouped based on commonalities in RTs?
> 
> Not at this time.  It's been a feature the BGP group has considered
adding,
> but it has an additional memory cost that scales per-route and that's
always
> scary.  With the advent of 64-bit junos, we've considered making some
> memory-burning features such as these able to be configured using a
> configuration knob but this class of features tends to be tricky and gives
our
> test group hives. :-)
> 
Yeah I can imagine :-). 
Well if Junos is not waiting for EOR/Keepalive (not sure about bootup
though) and parses through updates as they come in, then this might never be
a big problem. 
So If I may suggest please rather focus on dynamic update groups (not just
within the config group) and especially move between configuration/update
groups without session reset please. 


Once again, thank you very much Jeff,


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::