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

[adamv0025 at netconsultings.com]

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