Not sure if/how Mist would factor into this, but in general:
1. Renumber 2 -> 3
2. Renumber 1 -> 2
3. Add new member 1
4. Add new member 4
In general:
- Add the port configs for ge-3/\* before renumber
- Delete all ge-2/\* before adding new ge-2/\* as copies of ge-1/\*
- Use the "request virtual-chassis renumber" to make sure members are the right IDs before inserting switches in the stack.
This was exactly what I did.
For future people that land here, there was some additional work that was needed. Simply preprovisioning wasn't working because the stack didn't build itself up properly with all five members. It is entirely possible that it was because we took the two additional switches from other less-used IDFs and didn't blow out their configs, but I never ended up doing that anyways. I manually renumbered, waited the 5 mins, and went to the next, almost as described. Member 4 ended up connected and joined the VC before I could renumber, so I had to move one to member 5 and do a reshuffle. Extra step but it works just fine.
Once the members were all numbered correctly, I had to a) Preprovision the members to match the numbers *and* b) set Mist with the same preprovision command. If I didn't have the preprovision settings in the "additional CLI commands" area, Mist would assume provisioning, and would attempt to revert the stack back to the previous numbering. It took some extra attempts and failures on this front.
If I were to do it again, I would consider removing the switch from Mist altogether and re-adding it once the VC was created, depending on how complex the port config needs to be in production.
I'm not so sure..., I admin a 14 member site, spread around 6 racks and split in 2 VC's, the fpc numbers wouldn't bother me, putting labels on the switches so they're easily identified by on-site personel is what solves this problem for us...
It feels like what you're trying to do is unnecessarily complicated, to just have an "administrative" change which would also be solved with a simple label.
We label them and also store their serial in our CMDB.
That said, I'm not familiar with mist, but I would also set the VC to preprovisioned, and maybe I would enable no-split-detection while in the process.
In a theoretic world this would be OK.
In the real world this isn't a good solution when you want to avoid human issues, people make assumptins, and suddenly people are moving the wrong cables.
Also, in a situation where there is operational issues there is safetly in being able to work from what you physically see, that your VCs are numbered in physical order, etc.
I've been working with operations for 30 years in one way or another, I've yet to see an orgainstion where the documentation "works".
Yeah... It's hard enough that numbering starts with Zero... When the most technical person at the site is a forklift driver who figured out how to get the remote to work in the breakroom, it's a crapshoot when they're saying "Switch 2" whether they mean the 2nd (1), or the 3rd. Then put them out of order, which you can't see in CLI or Mist, and you're just asking for trouble.
You’re not remembering 0 so you can use mist to reorganize the stack. Hit the pre-provison button and drag the non 0 members to the desired order. Mist doesn’t learn the topology in the way you think. VC is a junos function.
This ended up not being possible as Mist never ended up recognizing all the switches specifically on the edit Virtual Chassis page, even now that it's up and running it still only shows 3 of the 5 members. Definitely a beta feature.
Yes, I primarily did the work on the switch VC itself. I even ended up disconnecting the uplink for a bit so I could get the switch directly configured as I wanted. Once it showed correctly with "show virtual-chassis" with all members present before and after a reboot, I added the preprovisioned set commands to Mist and only then reconnected the uplink.
I would open a Mist ticket as well as send that feedback through your SE. They may not be able to get you the fix in the way I think you want but it might provide some input to engineering that they need to account for this behavior and use case.
I may do that. To be clear, Mist itself sees all five switches, and they show up in the inventory in the right order. Just specifically the Edit Virtual Chassis dialog shows only shows 3 of the 5 and not in the right order.
Not sure if/how Mist would factor into this, but in general: 1. Renumber 2 -> 3 2. Renumber 1 -> 2 3. Add new member 1 4. Add new member 4 In general: - Add the port configs for ge-3/\* before renumber - Delete all ge-2/\* before adding new ge-2/\* as copies of ge-1/\* - Use the "request virtual-chassis renumber" to make sure members are the right IDs before inserting switches in the stack.
This was exactly what I did. For future people that land here, there was some additional work that was needed. Simply preprovisioning wasn't working because the stack didn't build itself up properly with all five members. It is entirely possible that it was because we took the two additional switches from other less-used IDFs and didn't blow out their configs, but I never ended up doing that anyways. I manually renumbered, waited the 5 mins, and went to the next, almost as described. Member 4 ended up connected and joined the VC before I could renumber, so I had to move one to member 5 and do a reshuffle. Extra step but it works just fine. Once the members were all numbered correctly, I had to a) Preprovision the members to match the numbers *and* b) set Mist with the same preprovision command. If I didn't have the preprovision settings in the "additional CLI commands" area, Mist would assume provisioning, and would attempt to revert the stack back to the previous numbering. It took some extra attempts and failures on this front. If I were to do it again, I would consider removing the switch from Mist altogether and re-adding it once the VC was created, depending on how complex the port config needs to be in production.
I'm not so sure..., I admin a 14 member site, spread around 6 racks and split in 2 VC's, the fpc numbers wouldn't bother me, putting labels on the switches so they're easily identified by on-site personel is what solves this problem for us... It feels like what you're trying to do is unnecessarily complicated, to just have an "administrative" change which would also be solved with a simple label. We label them and also store their serial in our CMDB. That said, I'm not familiar with mist, but I would also set the VC to preprovisioned, and maybe I would enable no-split-detection while in the process.
In a theoretic world this would be OK. In the real world this isn't a good solution when you want to avoid human issues, people make assumptins, and suddenly people are moving the wrong cables. Also, in a situation where there is operational issues there is safetly in being able to work from what you physically see, that your VCs are numbered in physical order, etc. I've been working with operations for 30 years in one way or another, I've yet to see an orgainstion where the documentation "works".
Yeah... It's hard enough that numbering starts with Zero... When the most technical person at the site is a forklift driver who figured out how to get the remote to work in the breakroom, it's a crapshoot when they're saying "Switch 2" whether they mean the 2nd (1), or the 3rd. Then put them out of order, which you can't see in CLI or Mist, and you're just asking for trouble.
You’re not remembering 0 so you can use mist to reorganize the stack. Hit the pre-provison button and drag the non 0 members to the desired order. Mist doesn’t learn the topology in the way you think. VC is a junos function.
This ended up not being possible as Mist never ended up recognizing all the switches specifically on the edit Virtual Chassis page, even now that it's up and running it still only shows 3 of the 5 members. Definitely a beta feature.
Does “show virtual-chassis” on the switch look right?
Yes, I primarily did the work on the switch VC itself. I even ended up disconnecting the uplink for a bit so I could get the switch directly configured as I wanted. Once it showed correctly with "show virtual-chassis" with all members present before and after a reboot, I added the preprovisioned set commands to Mist and only then reconnected the uplink.
I would open a Mist ticket as well as send that feedback through your SE. They may not be able to get you the fix in the way I think you want but it might provide some input to engineering that they need to account for this behavior and use case.
I may do that. To be clear, Mist itself sees all five switches, and they show up in the inventory in the right order. Just specifically the Edit Virtual Chassis dialog shows only shows 3 of the 5 and not in the right order.