![]() ![]() ![]() OSPF was in init state and not able to peer with the linked Cisco 6509's, while the links worked, according to LACP+LLDP. A reboot of the overall still working (checked via console) VC fixed this. It is not very relevant to this topic here but similar behavior happened with our QFX5100 where I did the NSSU from the recent 14.1X53-D35 to the latest D40 interim release and after the NSSU OSPF was not working anymore. I cannot tell if this also applies to other models as I only tested NSSU for the 82's. ![]() Plain software add with whole VC reboot works. Just as a note also EX8200 NSSU is broken in the 15.1 code and leaves you with the XREs plus half the SREs updated but an error "access denied" appeares and so the other SREs do not upgrade even if you reboot them manually. As in the past R5 often was considered to be the first "mature" version of a new train I have some hope that things will become better now that the version overall has become recommended. I mentioned it in another thread - we still had the problems when we moved our test equipment from R4 to R5. We have adopted the 15.1 code pretty early due to some policy saying "you must not use firmware that is going to be EoE" - that was before Juniper decided to extend 12.3 support by one year. Hope this will save some of you from problems We've not yet opened a case still. other platforms like the EX3300 work however which I think is just the case as they got more RAM than the 2200 (512MB). I assume this is also happening on other platforms but had no time to verify it until now as well as opening one more JTAC case. The only workaround we found so far is to copy over the upgrade files to /var/tmp and do a reboot before actually installing the upgrade. ![]() We had few switches where the upgrade made it through to the switch reboot after which the device was up with the new software but the majority of 2200's just fail in operation. with 'request system software add reboot' will lead to the same issue. Doing the copy and upgrade in one command e.g. What you can expect at that point is STP loops, unavailability of that switch and every related subnets caused the loop. If you continue and issue the 'request system software add.' for the package the switch is going to consume the remaining memory up to 100% and also 100% CPU load. However that consumed memory is not going to be cleared once the file has been transferred. At that step we did not observe any other problems. When you copy a new software package to the switch you will already see the switches memory jump well over 75-80% consumed. The upgrade from 12.3 to 15.1.R1 worked well and just as expected while each further 15.1 release we upgraded to (also the recent R4 to R5) caused major stability issues with many of the switches. I just wanted to let the community know about issues that occur with EX2200 switches running the 15.1Rx Junos versions. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |