[j-nsp] More than 2000 VRFs on MX960

[Mike Simkins]

Not sure I have seen the learning/import delay issue, our issue was the fact that BGP default-only customers 'lost' connectivity, as we saw the BGP default route being withdrawn, and then re-appearing at the next (30 second ) update, we worked around that by creating another routing instance that just contained the default routes for ipv4/6 nexthopping to inet.0/inet6.0, and then importing that into the VRF. That seemed to fix that particular  problem, we never found out why it worked, and Juniper could not comment on why it happened.

I have heard (anecdotally) some bad things about both the 15.x and 16.x trains, I am considering going to the 17.x train, as I want to get support for the large BGP communities in 17.3, as we are using both 16 bit and 32 bit AS Numbers around the world, but that will depend on how the regression testing goes.

Also I hope the change from 14.x to 17.x will help with our commit times, which on a big device can take 5+ minutes, and we can then take full advantage of the RE hardware.

Mike
-----Original Message-----
From: adamv0025 at netconsultings.com [mailto:adamv0025 at netconsultings.com] 
Sent: 12 January 2018 17:33
To: Mike Simkins <mike.simkins at sungardas.com>; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] More than 2000 VRFs on MX960

Thank you for the response I'm glad we're not the only one out there.

Hmm interesting,
The problem related to BGP route refresh after addition of new VRF was that it took as much as 10 minutes for routes to appear in the newly configured VRF (on 12.3). 
 -these were routes already being imported by other VRFs on the box so already present in bgp.l3vpn.0. 
Workaround was to remove full internet table from those nodes (or even better stop advertising full internet routes from RRs). And the move to 15.1 improved things a bit further but then VRRP switch on commit appeared -that in turn was fixed by moving VRRP to line-cards. 
But still the import times are couple of minutes.

adam

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

> -----Original Message-----
> From: Mike Simkins [mailto:mike.simkins at sungardas.com]
> Sent: Friday, January 12, 2018 10:15 AM
> To: adamv0025 at netconsultings.com; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] More than 2000 VRFs on MX960
> 
> Yes, on 14.2, and before on 12.3
> 
> Slow commit times certainly, and we have an odd issue (which may be 
> our legacy configurations as we seem to have found a work around) 
> where we see the default route 'refresh', which caused some issues on 
> a BGP downstream
> 
> Mike Simkins
> 
> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On 
> Behalf Of adamv0025 at netconsultings.com
> Sent: 12 January 2018 10:07
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] More than 2000 VRFs on MX960
> 
> Hi folks,
> 
> Are you using more than 2000 VRFs on MX960 (in production)?
> If yes on what code base; and any issues you experienced?
> 
> Thanks
> 
> adam
> 
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=gYbc-
> GKV5BQa9zrq1GFCVg&r=S1PZn0PYDDYtiCW2fix2C1ZHo8KzLAckyehxqI4wl20
> &m=433XbbH1_ydHlyDUJGmuf0Qd5zTYCtH1TOAz9MgchwM&s=rgPx12nDe4
> JAbgA2uHom42jlqHVIPI5XzWvLVBJ-QYo&e=