[j-nsp] "set routing-options protect core" breaks local-preference
adamv0025 at netconsultings.com
adamv0025 at netconsultings.com
Wed Sep 12 16:51:27 EDT 2018
> From: "Rolf Hanßen" [mailto:nsp at rhanssen.de]
> Sent: Tuesday, September 11, 2018 6:14 PM
>
> 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.
>
Well then I guess it's a question for the business whether they accept the
risk with each upgrade or whether they are willing to pay for a lab.
It should be simple mathematics then. How much would it cost the business to
buy at least one of each and how much does it cost the business to
experience these nasty surprises every now and then in terms of business
reputation and lost opportunities and in simple SLA compensations.
adam
netconsultings.com
::carrier-class solutions for the telecommunications industry::
More information about the juniper-nsp
mailing list