[j-nsp] "set routing-options protect core" breaks local-preference

[Gustav Ulander]

Hello. 

One question reagrding this and Junipers offerings in the virtual appliance field. Even though I agree with the statement, when looking at Ciscos offering in virtual appliances for lab and testing purposes I find that a lot of the functionality isn't there especially when we are looking at different encapsulations. For instance NX-OS appliance running in VIRL (or stand alone for that part) couldn't run VXLAN  at all. I think it had something to do with the Broadcom chipset and the software interfacing with Broadcom firmware and not the ASICS themselves. 
In this situation it is pretty hard to  test things out in your virtual lab. 
Is Juniper better in this regard? Do the virtual appliances have feature parity with the hardware ones? 

//Gustav

-----Ursprungligt meddelande-----
Från: juniper-nsp <juniper-nsp-bounces at puck.nether.net> För adamv0025 at netconsultings.com
Skickat: den 11 september 2018 14:55
Till: 'Karl Gerhard' <karl_gerh at gmx.at>; juniper-nsp at puck.nether.net
Ämne: Re: [j-nsp] "set routing-options protect core" breaks local-preference

> From: Karl Gerhard [mailto:karl_gerh at gmx.at]
> Sent: Tuesday, September 11, 2018 10:48 AM
> 
> One of the worst things about running Juniper hardware is the software 
> updates. I feel like every time I upgrade Junos bits and pieces of 
> previously working stuff break in miraculous ways and it steals you 
> hours or days of your time.
> 

There are some bigger changes going on in BGP code which is good, we just need to hold tight till it's all over. 
One way to withstand the situation is through rigorous testing so there are no surprises in production.

With regards to Gert's caveat "we're too small to build a lab..."
There are two kinds of testing that can be done,
1) concept testing
2) performance and scale testing

Virtual lab is perfect for concept testing -concept testing -to test various routing concepts -like what happens to my core routing if I enable "set routing-options protect core".  
In fact it is much easier to simulate the network in its entirety in a virtual environment than trying to simulate small sections of the network using a handful of physical devices.
Building a virtual environment is very cost effective too, it's just a fraction of the cost compared to physical lab.
And working in virtual environment speed things up significantly, as you can create new connections and new nodes on the fly in minutes -no need to perform any racking/cabling.     
You can even have multiple instances of the virtual lab, one to closely simulate status quo -used to simulate small changes, and one to simulate significant changes to the core topology and study their effects on the overall routing -e.g. merger of two backbones.
For some large scale impact changes it is impossible to simulate those in physical lab -as you'd literally need a full copy of the physical network just for playing in order to do that.  
  
Physical lab is essential only for performance and scale testing -performance testing  -to tests various performance metrics of:
 a) data-plane: pps, bps, failover times from primary to backup path, what happens when you overload any subsystem of the router, etc...
 b) control-plane: how long it takes to tx/rx BGP routes, how long does bgp path selection take with x routes and y VRFs, how long does it take to tx routes to FIB, etc...   
-scale testing
- in contrary to unidimensional scale testing done by vendors it's aimed for multidimensional scale testing in a particular deployment
- e.g to find out when will I run out of CP/DP resources, i.e. how many BGP + RSVP + VRRP + BFD sessions can I have along with this number of VRFs and BGP routes in each VRF, till I run out of CP resources, etc...

adam

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


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp