[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