[c-nsp] Juniper MX240 & MX480

[Mark Tinka]

On 31/Oct/17 15:30, adamv0025 at netconsultings.com wrote:

> But I actually do mind the fact that,
>  
> 1)BGP tables (e.g. bgp.l3vpn.0)  are created only at the instance when PE needs to store received MP-BGP routes in them.
> -this is very confusing when coming from vendor where all tables are always used in a "full-duplex" mode. 
> -these BGP tables are only used for routes received over MP-BGP -but just not sure why local VPN routes are dumped to these (seems like a waste of resources and source of confusion)
>  
> 2)VRFs are not using BGP tables to advertise routes to RRs/Other-PEs or to each other.
> -that's why you need to apply MP-BGP export policies only at each individual VRF as vrf-export policy -or if you want to do it at a global level MP-BGP session level you have to use the “vpn-apply-export” knob -which places the policy configured at global level at the end of each VRF's export policy.
> -and yes you guessed it, the “advertise-from-main-vpn-tables” does not do the trick -even it is supposed to move all MP-BGP sessions to their respective common rib out which resets sessions -see point 3) below. 
> -and for some reason it's still not the same rib out as used by RRs -cause on RRs/ASBRs you actually can use export policies directly on MP-BGP sessions.    
>  

Assuming you're using this for Internet in a VRF, I wouldn't know. I've
done my best to stay away from this topology.

If you're talking about classic MPLS/VPN's (l3vpn's), we do a lot more
stuff in Global than in VRF's for it matter for us. But I do see you
concern.

> 3) BGP session is reset each time peer moves to a different update group(rib out) -not minding the inefficiency where 

This has annoyed everyone for some time now.

As you know, there are inelegant workarounds, but perhaps if it bothers
you this much, perhaps start talking about an ER with your AM.


>
> 4) BGP creates multiple identical copies of rib out -just based on configured peer groups. 

Same as above.


>  
> All this suggests to me that this was somehow cobbled together over the years with no master plan. Yes it routes, somehow, but because it's so complex troubleshooting what's going on under the hood (e.g. why it takes 5min to import route from bgp.l3vpn.0 to newly added VRF.inet.0) is a nightmare.
> Does not seem like "carrier grade" to me.  

You're probably right, but we pick our battles. In the grand scheme of
things, after all is said and done, this isn't fundamentally one of them
that will determine whether we go MX or ASR.

Mark.