[j-nsp] EX4200 JunOS Recommendation

Richard A Steenbergen ras at e-gerbil.net
Mon Nov 8 17:37:31 EST 2010


On Tue, Nov 09, 2010 at 08:46:54AM +1100, Chris Kawchuk wrote:
> 
> We've now settled on 10.2R3 on our EX4200s, and EX2200s. When I tried 
> to do "upgrades" to the "JTAC recommended releases" I managed to 
> almost brick my EX2200's in the process. (i.e. when booting, they 
> simply waited 15 mins for mgd to settle, amongst other nasty 
> deadlocking situations in the boot process. Had to Ctrl-C the boot 
> process a few times on a few different EX2200s and EX4200s on the 
> "Juniper's Recommended Releases".

I haven't seen that one, but there ARE some serious issues with EX 
config compatibility between versions to watch out for.

For example, on EX in 10.1 doing a "then log" in a firewall filter was 
completely unsupported, so the command would be automatically commented 
out in the config. As of 10.2 it became supported, but only in a filter 
applied on the ingress of a physical port. If you attempt to apply this 
filter on egress, or on the lo0 interface, it causes a hard error and 
fails the commit.

So say for example you had copied over a firewall config from another 
platform, and still had a "then log" in your lo0 control plane filter, 
which was being automatically commented out in 10.1. When you go to 
upgrade the box to 10.2, it will cause a hard error during the loading 
of the initial config, causing the box to come up with no config at all 
(or a rescue config if you have one), possibly requiring console access 
to recover from. The upgrade validation process doesn't check for this 
at all, and there is really no way for an end user to know about it, 
short of trying the upgrade and having the box not come back.

And this is far from the only example where this happens... It'll get 
you on other platforms too, for example somewhere between 9.6 and 10.1 
they removed the "hold-time" config option from ae# physical interfaces, 
and the config validation process doesn't catch this one either. Moral 
of the story, if you have dual RE's always test the config with the new 
code on the backup RE first, and make sure you have working OOB and 
console access when working w/junos.

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


More information about the juniper-nsp mailing list