Search

1 to 10 of 24
Sort by

Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Although it was not the documented expectation, I sort of understand the short traffic impact. When the MM switchover occurs to upgrade to the newer software, the Standby MM needs to finish its full restart to load the new firmware before it can start processing traffic. I suspect the switching...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Exactly! The point is that "it looks like the NonStop Switching redundancy mode's capability of non disrupting normal Layer 2 switching traffic traversing the switch didn't prove to be true in the scenario we're discussing about...I can understand that Layer 3 Routing will be briefly affected ...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Hi , That is the exact procedure that I followed. For confirmation, the exact commands I executed are listed in one of my earlier posts in this thread. As you have stated and what I had read before the upgrade, was that using that procedure should produce no impact to switch operation​ when...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Hi @Azz , not sure the smoking gun was actually that very one...I mean it's pretty strange...giving your explanation, it looks like a "Catch 22" scenario (Tricky)...since - if our assumptions are correct - there will always be a software mismatch​ between the new (once updated) MM - the previous...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Hi , I don't disagree with your understanding and I was expecting the same result of essentially no impact with that upgrade. However, I just took some time to review the logs and I think I have found the smoking gun which would then give a short outage as seen: I 03/09/21 07:26:10 00266 system:...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Hi , these two sentences: " The core VSF runs L3 routing and switching. " and " The upgraded switch purely runs L2 VLANs back to the core switches. " and the fact the ping test you performed had packets traversing (and routed by) the VSF reaching the destination connected on the upgraded 5406R...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Hi @parnassus , Happy to help out, I am always looking for real world examples to understand possible impacts to production networks as well. Ok this network is as follows: 1. Core pair of 5412rRzl2 chassis switches with a single MM in each. They are inter-connected with 2 x 10Gbps VSF (about...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Hello @Azz , your feedback is really appreciated!​ Thanks! Since 15 seconds seem a long time to me...I have just one question more, you wrote the ping was done " ... from another subnet across another 5400 VSF stack which is running as a L3 core with dual 1Gbps fibre uplinks to the 5400 being...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

Thanks for feedback ! -- PowerArubaSW : Powershell Module to use Aruba Switch API for Vlan, VlanPorts, LACP, LLDP... PowerArubaCP: Powershell Module to use ClearPass API (create NAD, Guest...) PowerArubaCX: Powershell Module to use ArubaCX API (get interface/vlan/ports info).. ACEP / ACMX #107 /...


Discussion Reply
RE: 5406Rzl2 upgrades - minimal downtime

​Hi Davide, The ping was from another subnet across another 5400 VSF stack which is running as a L3 core with dual 1Gbps fibre uplinks to the 5400 being upgraded. The ping was just a standard windows ping command that I think has a default 2 sec delay between pings which means around 10-15 secs...