Switching

We are currently doing some testing on some EX4300 switches before replacing Cisco in our production.

Today I tested uppgrading with NSSU, and then rolling back. This is an importan feature in case the new version contains something that has a negative effect on our environment.

However the solution I came up with did not seem to work as well as I thought.

The current setup is 2 nodes in VC preprovisioned, both are possible RE

The procedure is now:

1. Start NSSU

2. NSSU completed, VC cluster is OK

We now have the current version on the primary slice, and the old on the backup slice.

We need to reboot each member on the backup slice

# Check which member is master and which is backup

show virtual-chassis

(let's pretend Member 0 is backup, and Member 1 is master)

# Request to reboot backup member on alternate slice which contains previous version

request system reboot member 0 slice alternate

(reboot successfull)

Here I get stuck

Member 0 comes back up, but is in Status: Inactive and in Role: Linecard

####

root@SW> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 496a.6dfa.4bea
Virtual Chassis Mode: Enabled
Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Inactive SN ex4300-48t 129 Linecard N VC 1 vcp-255/1/0
1 vcp-255/1/1
1 (FPC 1) Prsnt SN ex4300-48t 129 Master* N VC 0 vcp-255/1/0
0 vcp-255/1/1

{master:1}
root@SW>

####

Since it does not sync with Master I cannot roll back the master.

Does anyone know what I did wrong, and how I can change the procedure for it to work? To be able to rollback is an important step in a production environment.

Inactive state is when you have different software on members or when you have a mixed VC(with ex4500 and EX4200), but the VC is not configured as mixed VC.

You should have done "request system reboot slice alternate all-members" to reboot all members from the alternate slice.

You just rebooted only FPC0. You could either reboot FPC1 from the alternate slice(considering that it has the same release as FPC0), or you can connect to FPC0(request session member 0) and reboot it one more time, this time from the slice that has the same release as FPC1.

=====

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it.

Thanks for a quick reply.

Correct me if i'm wrong, but running "request system reboot slice alternate all-members" would have rebooted both members at the same time, right?

This would mean downtime, and that is something that we cannot have later when we put them into production.

As you write, this state of one Master and one inactive linecard is as it should be, so the question is, are they still syncing, and would there be downtime if I reboot the Master to alternate slice?

The goal is to get both switches from the new version to the previous version while always keeping at least one switch operational and withouth noticable failovers. So like NSSU but the reverse.

Yes, this means reboot in the same time.

Right now, the inactive member is part of the VC, but an active member(aka forwarding traffic). Rebooting the master, will cause you total service impact.

So the short answer is no, you cannot have a 'reversed' NSSU.

=====

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it.

Hmm, annoying. The VC cluster works with different versions during an NSSU, so why it cannot do it the other way seems strange. Also strange that there is no rollback options other than rebooting the entire VC at once.