[j-nsp] EX4200 9.4R2.9 process crash on previously valid config
Upon upgrading an EX4200 stack from 9.2R2.15 to 9.4R2.9, I found that
some damned process, chassism or something, was crashing repeatedly and
preventing any interfaces from coming up. I wish I had taken the time
to note which process it was, but the following will reproduce it.
configure any interface as follows
interfaces {
ge-0/0/0 {
ether-options {
speed {
1g;
}
802.3ad ae0;
}
}
JUNOS 9.4 won't let you configure that, but the upgrade validator does
not catch it (and numerous other problems) when you already have it
configured on an older version. So if you have the above in your config
in 9.4R2.9, no interfaces will come up, whatever process (forgot) will
crash repeatedly, and you will have to hunt down the problem and correct
it before any ports on your stack can come up again.
Dearest Juniper, please pay more attention to validating configs in
newer JUNOS vs configs that are allowed on older EX-series software.
It's stupid that things like virtual-chassis { pre-provisioned } still
pass muster and then your whole stack is broken post-upgrade until you
run a commit check and find out what's wrong. The software for EX4200
has come a long way in recent months, but you obviously don't have your
shit together with the upgrade process. A working software rollback
process would be a nice addition, too. Much love -- Jeff ;)
--
Jeff S Wheeler j...@inconcepts.biz +1-212-981-0607
Sr Network Operator / Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
On Thu, Apr 02, 2009 at 01:48:26PM -0400, Jeff S Wheeler wrote: Dearest Juniper, please pay more attention to validating configs in newer JUNOS vs configs that are allowed on older EX-series software. Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. If you want to use EX you should probably just have a lab box that you test your configuration on before deploying, because they certainly aren't making any effort to QA test their code before shipping it. Besides you should consider this progress. In older EX code you could configure MTUs that didn't actually route in hardware (but that routing protocols didn't know about, thus causing you to drop LSAs), or uRPF which wasn't officially supported and caused the box to immediately crash in an endless loop until you disabled it on console. It isn't 1999 any more, and Juniper isn't the same company. Stop expecting superior products, that isn't the business model any more. :( -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
Hi Richard, Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. Excuse me ? Cisco in vast majority of new products is way much better now. Yes historically there was an issue with IOS, but AFAIK that has been also fixed now. * Look at highly dedicated XR team with an excellent and really technical leadership which knows exactly what they are doing (Hint: Just compare Prefix Independent Convergence capability); * Look at top class in the industry ASR family of routers (Hint: ask your Juniper rep about number of bgp routes they can deal with on the top line of the router and then compare with ASR basic capability) * Look at their procket OS based storage product line ... Or at the end look which company offers you no technology religion into which (if any) encapsulation you as the customer want to choose for your services. One company may offer you wide choice of GRE, L2TPv3, IPinIP or MPLS encapsulations all at line rate where all services you want to offer can run equally well on any of them while perhaps the other one may just lock you to the only one 4 letter encap type they are capable to offer. It isn't 1999 any more, and Juniper isn't the same company. Stop expecting superior products, that isn't the business model any more. :( You couldn't say it any better ! Cheers, R. PS: On the topic of the future of EX-series I will at this point refrain from commenting on the public list :). On Thu, Apr 02, 2009 at 01:48:26PM -0400, Jeff S Wheeler wrote: Dearest Juniper, please pay more attention to validating configs in newer JUNOS vs configs that are allowed on older EX-series software. Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. If you want to use EX you should probably just have a lab box that you test your configuration on before deploying, because they certainly aren't making any effort to QA test their code before shipping it. Besides you should consider this progress. In older EX code you could configure MTUs that didn't actually route in hardware (but that routing protocols didn't know about, thus causing you to drop LSAs), or uRPF which wasn't officially supported and caused the box to immediately crash in an endless loop until you disabled it on console. It isn't 1999 any more, and Juniper isn't the same company. Stop expecting superior products, that isn't the business model any more. :( ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
On Thu, Apr 02, 2009 at 04:25:14PM -0700, Robert Raszuk wrote: Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. Excuse me ? Cisco in vast majority of new products is way much better now. Yes historically there was an issue with IOS, but AFAIK that has been also fixed now. Dare I ask who you're defending here? In all honesty, with respect to the quality and time/attention that goes into the software development and QA process of new software, JUNOS has gone massively down hill lately. Anyone who expects that a bug fix R1-R2 build is not likely to introduce some massive new issue in something that was previously working fine clearly hasn't been deploying JUNOS over the last year. My advice to Jeff was that it is absolutely unrealistic to expect to be able to deploy new code without testing it on your configuration in the lab first, especially on the EX (which is still a very immature platform). Maybe this is just the natural result of complexity, as JUNOS tries to cope with being every thing to every one on every platform without forking the code, but the point is that it isn't the same simple and just works JUNOS he's dealt with in the past. And on the subject of config validation, I would feel slightly better about the whole thing if the issue I pointed out 2 years ago (that the duplicate IP check went from an error to a warning, allowing a typo to commit and bring down both interfaces) had ever been addressed, but I just checked 9.4R2 and guess what it hasn't. I also gave several other examples where config validation on the EX let you configure things that weren't supported and which killed the box in the process, so it's clearly something you need to watch out for on this platform. PS: On the topic of the future of EX-series I will at this point refrain from commenting on the public list :). EX makes me sad... I really want to like the thing, but I think Juniper has just completely missed the boat from a product management perspective. Another good idea ruined by trying to focus exclusively on Enterprise. :( The software has gotten significantly less bad over the last year though, I'm still holding out hope that it will be a good box some day. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
I got something for everyone. http://photos-f.ll.facebook.com/photos-ll-snc1/v2439/7/22/80403768/n80403768_31273893_6328.jpg And that's the truth! On 4/2/09 4:25 PM, Robert Raszuk rob...@raszuk.net wrote: Hi Richard, Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. Excuse me ? Cisco in vast majority of new products is way much better now. Yes historically there was an issue with IOS, but AFAIK that has been also fixed now. * Look at highly dedicated XR team with an excellent and really technical leadership which knows exactly what they are doing (Hint: Just compare Prefix Independent Convergence capability); * Look at top class in the industry ASR family of routers (Hint: ask your Juniper rep about number of bgp routes they can deal with on the top line of the router and then compare with ASR basic capability) * Look at their procket OS based storage product line ... Or at the end look which company offers you no technology religion into which (if any) encapsulation you as the customer want to choose for your services. One company may offer you wide choice of GRE, L2TPv3, IPinIP or MPLS encapsulations all at line rate where all services you want to offer can run equally well on any of them while perhaps the other one may just lock you to the only one 4 letter encap type they are capable to offer. It isn't 1999 any more, and Juniper isn't the same company. Stop expecting superior products, that isn't the business model any more. :( You couldn't say it any better ! Cheers, R. PS: On the topic of the future of EX-series I will at this point refrain from commenting on the public list :). On Thu, Apr 02, 2009 at 01:48:26PM -0400, Jeff S Wheeler wrote: Dearest Juniper, please pay more attention to validating configs in newer JUNOS vs configs that are allowed on older EX-series software. Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. If you want to use EX you should probably just have a lab box that you test your configuration on before deploying, because they certainly aren't making any effort to QA test their code before shipping it. Besides you should consider this progress. In older EX code you could configure MTUs that didn't actually route in hardware (but that routing protocols didn't know about, thus causing you to drop LSAs), or uRPF which wasn't officially supported and caused the box to immediately crash in an endless loop until you disabled it on console. It isn't 1999 any more, and Juniper isn't the same company. Stop expecting superior products, that isn't the business model any more. :( ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
On Thu, Apr 02, 2009 at 07:39:16PM -0600, Tommy Perniciaro wrote: I got something for everyone. http://photos-f.ll.facebook.com/photos-ll-snc1/v2439/7/22/80403768/n80403768_31273893_6328.jpg And that's the truth! You forgot to include a URL to where we can get some of those. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
Apparently my Juniper reps are completely different from yours, I've
been recommended by them not to run 9.4 on my ex platform as of yet.
and stick with 9.3R2.8, which I've not run into a bug with yet. (save
a minor annoying missing feature of except in the ACL)
On Apr 2, 2009, at 10:48 AM, Jeff S Wheeler wrote:
Upon upgrading an EX4200 stack from 9.2R2.15 to 9.4R2.9, I found that
some damned process, chassism or something, was crashing repeatedly
and
preventing any interfaces from coming up. I wish I had taken the time
to note which process it was, but the following will reproduce it.
configure any interface as follows
interfaces {
ge-0/0/0 {
ether-options {
speed {
1g;
}
802.3ad ae0;
}
}
JUNOS 9.4 won't let you configure that, but the upgrade validator does
not catch it (and numerous other problems) when you already have it
configured on an older version. So if you have the above in your
config
in 9.4R2.9, no interfaces will come up, whatever process (forgot) will
crash repeatedly, and you will have to hunt down the problem and
correct
it before any ports on your stack can come up again.
Dearest Juniper, please pay more attention to validating configs in
newer JUNOS vs configs that are allowed on older EX-series software.
It's stupid that things like virtual-chassis { pre-provisioned } still
pass muster and then your whole stack is broken post-upgrade until you
run a commit check and find out what's wrong. The software for
EX4200
has come a long way in recent months, but you obviously don't have
your
shit together with the upgrade process. A working software rollback
process would be a nice addition, too. Much love -- Jeff ;)
--
Jeff S Wheeler j...@inconcepts.biz +1-212-981-0607
Sr Network Operator / Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
On Friday 03 April 2009 09:14:28 am Richard A Steenbergen wrote: Dare I ask who you're defending here? In all honesty, with respect to the quality and time/attention that goes into the software development and QA process of new software, JUNOS has gone massively down hill lately. Anyone who expects that a bug fix R1-R2 build is not likely to introduce some massive new issue in something that was previously working fine clearly hasn't been deploying JUNOS over the last year. I realize that Juniper have to make a new release every quarter, and in most (if not all) cases, there is some new feature which has the potential to cause badness to systems that are already working fine. I think what I'd like to see is a fork of the code base which consolidates all new features up until that point, and then enters into a maintenance state - only bug fixes, with no new features. Other iterations of the code would continue to come out with new features every quarter. I realize this is entering Cisco territory, but given that each new release of JunOS has new features that could potentially cause problems, and previous bugs still go unfixed (priorities?), I don't see a better way to have stability if we keep chasing bug fixes in new releases that lead to newer bugs we keep chasing fixes for in even newer releases, e.t.c. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config
On Friday 03 April 2009 09:52:58 am Cord MacLeod wrote: Apparently my Juniper reps are completely different from yours, I've been recommended by them not to run 9.4 on my ex platform as of yet. and stick with 9.3R2.8, which I've not run into a bug with yet. (save a minor annoying missing feature of except in the ACL) 9.3R2.8, for us, has a few nasties we can't afford to have in the network. When you lose a customer link because you changed either a VLAN ID or VLAN name, that's never good. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
