View Only
last person joined: yesterday 

Ask questions and share experiences about EX and QFX portfolios and all switching solutions across your data center, campus, and branch locations.
  • 1.  EX4600 best practice/design

    Posted 12-28-2016 09:49


    I have been reviewing the documentation for the Junos upgrade process of the EX4600 and to be honest it gets less clear each time I read it.  Specifically, I am looking at the nonstop-upgrade versus the in-service-upgrade process.  


    Setup: in my situation the EX4600 will sit in a three member virtual chassis as our network core.  Two in the main server room, and one in a secondary location for redundancy.  Right now, the two in the main server room are RE and BK because they are directly attached via 40GB cable.  The third "LC" is connected via 2x10GB fiber to each to complete the loop.  Nearly all remote locations are connected via link aggreagation so I can lose one member at a time without issue.


    My concern is that we are a small hospital and I need maximum uptime but also need to keep things current.  Which of the two upgrade options is best for this setup?  Also, if you see a problem with this setup feel free to voice it.  I would rather plan for problems now than react to them during an outage.


    Thank you,


  • 2.  RE: EX4600 best practice/design
    Best Answer

    Posted 12-28-2016 10:06

    You are looking for the nonstop software upgrade (NSSU) process, as the ISSU upgrade process is only doable on standalone EX4600/QFX5100 switches. Agreed that this is not very obvious in the documentation.


    As long as you have all remote locations connected to at least two members in the virtual chassis, NSSU should be just fine 🙂




  • 3.  RE: EX4600 best practice/design

    Posted 12-28-2016 10:09

    Well that makes the choice real simple.  Thank you

  • 4.  RE: EX4600 best practice/design

    Posted 12-29-2016 07:21

    @Twinkle - with NSSU (default settings) what should happen is that the BK RE gets code upgrade 1st, and is then re-booted.  LC is next, and Master RE last.  When Master RE re-boots, the former BK RE will now become Master.  Now for NSSU you must also turn off things like GRES and NSB (you need to do this before you start the NSSU process) so when when switch-over from former BK to become new Master there will be a HIT!  Former BK RE needs to perform some re-learning/etc.  Exact time for hit depends on network but I would suspect 30 seconds to a few minutes might be normal.


    You will probably want to have you server admins check their applications after the upgrade to make sure none are down or stuck due to network interuption.  I believe things like EPIC/etc. maybe affected.  If you remote WLAN AP switches are split or dual connected to different core EX4600s, then there should be no interruption for these.


    Remember to turn back-on GRES/NSB after the upgrade, and then if you wish to switch back Master ownership of RE, you should be able to do this without any hit.  Since these are core switches, I assume you also have some form of NSR enabled.


    I would also assume you are upgrading to 14.1X53-D40. I would NOT recommend considering a move to 16.2 for this platform.  Next move forward after 14.1X53 for EX4600/QFX5100 would be something in 17.x train.


    Hope this helps.