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

["Rolf Hanßen"]

Hi Adam,

I do not agree with your praise for the vm lab.
When I think of the last (real) issues in our network or things that
fucked up with Software-Upgrades, in most of the cases testing it with an
virtual device before would not have helped at all.
Some samples:

We had 2x MX960 that failed during SW-Update with single RE-S-X6-64G-BB,
but not on those 2 with dual RE-S-X6-64G-BB.
We hit a QFX bug that did not install STP blocked port information into
hardware and looped.
We had mass of issues with QFX 14 software on 13 host (causing loops in
several situations).
We had issues with EX3400 first releases code (like "Juniper forgot to
code a feature" or "upgrading does not work because the flash is too
small").
We had situations where a QFX simple does not behave the way a EX4550 does.
We ran into a problem that MX104 cannot be updated with "request system
software add ... reboot" if running from RE flash (because it boots from
USB then and takes some old config).

On the other side I do not remember any issue at all that was caused by a
changed software behaviour after updating existing hardware or any other
issue a vm lab would have saved us.

kind regards
Rolf


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