[j-nsp] Code upgrade to 10.4R4.5

[Richard A Steenbergen]

On Wed, May 11, 2011 at 04:11:09PM -0300, Cyn D. wrote:
> Will this be a none (no config loaded at all) and all (if loaded then 
> it is intact) situation? What I don't want to see is configuration 
> loaded partially and the lines that are not compatible are missing. 
> When you go through an intermediate level, does that code "change" the 
> incompatible config for you? If it doesn't, even if you have a backup 
> config, it still won't load properly, right? We've seen this on some 
> non-juniper routers.

Correct. If the config would generate an error if you were just going to 
commit it regularly, it will cause the initial import to fail and the 
RE to come up as Amnesiac. This is the kind of thing the validate 
process is supposed to catch.

There are many different types of config changes between versions, so 
it's hard to generalize. Some changes will continue to work in the old 
config style and just throw warnings about being deprecated, some will 
automatically transition to a new format, and others will cause hard 
errors which fail the commit.

For example, one recent one I saw bite people is when EX enabled support 
for certain firewall operations (like "then log"), but only when applied 
as an ingress filter. Previously this configuration wasn't supported at 
all, so even if you imported a firewall config from another platform the 
entire command was automatically commented out, and nothing bad 
happened. When they moved to implementing partial support for it, they 
made it a hard error depending on the context where the filter was 
applied (a mistake, IMHO), and boom you now have a situation where the 
config could fail to load. Of course to make it even worse, they didn't 
manage to catch this one in the validate process, but that's another 
issue. :)

Unfortunately this kind of thing happens all too often even on classic 
Juniper boxes, and especially if you want to live dangerously and run 
no-validate. If you run anything less than dual-RE with OOB access to 
serial console, eventually you will get screwed by this behavior. It 
turns out that dual-RE support is far more useful at protecting against 
these kind of issues (and minimizing downtime during code upgrades) than 
at handling RE failures. It's a damn shame they couldn't find a way to 
shoehorn dual REs into the MX80 for this reason, it's the biggest 
downside to an otherwise excellent box.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)