VSAN 30 Mismatch Suspends a Four-Member SAN Port Channel
An MDS 9396S edge switch is connected to an MDS 9710 core with a 4-member 32G SAN port channel (port-channel 10). The edge carries VSANs 10 and 20. A new VSAN 30 is created for a host migration. On fc1/3, the trunk allowed list is updated to 10,20,30; the other three members still allow only 10,20. The port channel goes into suspended state, and VSAN 30 hosts cannot log in. VSANs 10 and 20 remain up on the remaining links, but the design requires all four links for bandwidth. The core has no VSAN 30 yet. show port-channel database reports the port channel as suspended, and show interface trunk shows different allowed VSAN lists on the members. The change window is active, and the team wants to restore the port channel without rebuilding it.
1. Why did adding VSAN 30 suspend the port channel, and what consistency rule applies to SAN port channels?
Read the worked answer
A SAN port channel is treated as one logical link, so its member ports must have compatible configuration. The allowed VSAN list is part of that compatibility. When fc1/3 was changed to allow 10,20,30 while fc1/1, fc1/2, and fc1/4 still allowed only 10,20, the members no longer matched and the port channel was suspended rather than forwarding with inconsistent trunking.
The rule is that all members must have the same trunk mode, allowed VSAN list, speed/rate mode, administrative state, and relevant VSAN-level parameters. Check show port-channel database, show interface fc1/1-4 trunk, show running-config interface fc1/1-4, and show interface port-channel 10. Do not assume the port channel will use the first member's configuration automatically; a mismatch is a configuration error to correct.
2. Give the corrective sequence on the edge and core, and state how you verify recovery.
Read the worked answer
First decide the intended end state: VSAN 30 must exist on the core, and the core port-channel 10 plus its member links must allow VSAN 30. Create VSAN 30 on the core and add it to the core port-channel trunk allowed list before expecting end-to-end VSAN 30 service.
On the edge, make all four members consistent. Either add VSAN 30 to fc1/1, fc1/2, and fc1/4 so all members allow 10,20,30, or temporarily remove VSAN 30 from fc1/3 to restore the original state and schedule the full change. Because the design requires all four links and VSAN 30 is being migrated, the consistent add is the correct final action. Apply the change to the member interfaces, then confirm the port channel is up rather than suspended.
Verify with show port-channel database, show interface port-channel 10, show interface trunk, show flogi database vsan 30, and name-server/zone checks. Confirm that VSANs 10 and 20 are still trunking and that all four members are forwarding.
3. What pre-change check would prevent this when adding a VSAN to an existing SAN port channel?
Read the worked answer
Before changing any member, build the full end-to-end allowed-VSAN matrix for both sides of the port channel. Create the VSAN on both switches, then update every member of the port channel and the port-channel interface itself as required. Use configuration templates or a scripted pre-check that compares show interface trunk and show port-channel database across all members before and after the change. Avoid mixing one-off switchport trunk allowed vsan commands with switchport trunk allowed vsan add in a way that produces different lists; the exact allowed list must be identical on every member.
During the change, verify after each step that the port channel remains up and that the new VSAN appears in show interface trunk. If a member deviates, stop and correct it before proceeding. Document the intended VSAN list in the change record so the next engineer does not have to infer it from a suspended port channel.