[c-nsp] Juniper MX240 & MX480

[adamv0025 at netconsultings.com]

> From: Mark Tinka [mailto:mark.tinka at seacom.mu]
> Sent: Tuesday, October 31, 2017 5:59 AM
> 
> On 26/Oct/17 10:26, adamv0025 at netconsultings.com wrote:
> The selection of tool depends on the job to be done, and you haven't 
> provided any info on what you intend to use the boxes for so I can 
> only generalize.
> If your network is carrying traffic of a single priority level or if 
> it just can't get congested then you'll be fine (well you'll still 
> have to bear the stupid BGP implementation in Junos) If the above is 
> not your case then save yourself a bunch of trouble and go with ASR9k 
> line instead.
> 
> We run BGP on Junos and have no complaints, fundamentally.
> 
Well glad for you,

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.    
 
3) BGP session is reset each time peer moves to a different update group(rib out) -not minding the inefficiency where 

4) BGP creates multiple identical copies of rib out -just based on configured peer groups. 
 
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.  

adam