We had an interesting issue last week while replacing a Cisco Catalyst 4510R with a Juniper EX4300 Stack. The second switch in the Virtual Chassis stack appeared to have a bad PoE controller since none of the PoE ports on that switch were working. So we had to replace the switch with a spare.
First we had to upgrade the JunOS code on the switch to match the software on the existing stack. After we downgraded the software we powered off the switch, connected the stacking cables or VCP ports then powered the switch back on… it was initially detected as the 4th switch in the virtual chassis stack. Next all we did was replace the serial-number for switch 1 with the new switch (switch 4) and commit.
{master:0}[edit]
root@TEST-SW01# set virtual-chassis member 1 serial-number PD37XXXXXXX
{master:0}[edit]
root@TEST-SW01# commit
configuration check succeeds
fpc2:
commit complete
fpc3:
commit complete
commit complete
That was all I needed to do. After the commit everything started working on the replaced switch. I eventually rebooted the stack just to be sure nothing broke or stopped working but everything was fine.
If you read through the JunOS libraries, you’ll find a very drawn out process documented here.
Is all that really required?
Deleting the member, and then reprogramming the switch?
Any Juniper switching gods here to confirm or deny?
Cheers!
We’ve been using that method for ex4200 replacements for years, and it’s never given us any major headaches. There are a few potential gotchas, mostly documented in the longer page you referenced.
– If you’re using any scripts, those will still have to be copied over separately.
– The mixed mode flag (ie, ex4200 and ex4500 stacked together) must be set appropriately on the new switch prior to joining the stack.
– Using fixed membership via serial number, as opposed to letting the stack auto-assign IDs, makes things a lot simpler. I highly recommend it! A lot of the extra work on that Juniper page is dealing with the auto assigned numbers on stack replacement.
Thanks for the insight Frank!
We Also use auto assign. When adding a new linecard we set the junos to match then purge out the configs on the member being added that sometimes persist. we do a “delete interface”, “delete protocols”, and “delete virtual-chassis” to make sure there is nothing that will interfere with joining the stack.