We had a technician move one of two port channel links from an old switch to a new switch before telling anyone. This left the new and old switch both connected to different links of the same channel group on the distribution switch. However, the new switch did not respond to ping or SSH until I removed the link to the old switch from the channel group. This fixed it before I could investigate more.

I understand that this is an incorrect configuration, but what was blocking traffic to the new switch? Is this part of the port channel or spanning tree or something else? What is the risk of a new switch coming up and existing link going down?

EDIT: adding switch info.

Old switch - Cisco Catalyst WS-C3750-48P

Port channel Po2
Gi1/0/1 & Gi1/0/2 members

channel-group 2 mode on  
switchport trunk encapsulation dot1q  
switchport trunk allowed vlan 10,20,30  
switchport mode trunk  
ip dhcp snooping trust

New switch - Aruba 3810M-48G-PoE+
interface Trk2
1/A1, 1/A2 members

dhcp-snooping trust  
tagged vlan 10,20,30  
untagged vlan 1  
spanning-tree priority 4 

Distribution switch - Cisco Catalyst WS-C3750-12S

Port channel Po2 Gi1/0/3, Gi1/0/4 members

switchport trunk encapsulation dot1q  
switchport trunk allowed vlan 10,20,30  
switchport mode trunk  
channel-group 2 mode on

spanning-tree mode rapid-pvst  
spanning-tree portfast bpduguard default  
no spanning-tree optimize bpdu transmission  
spanning-tree etherchannel guard misconfig  
spanning-tree extend system-id  


  • You really have not given us any information. At the very least, we would need the switch models and configurations. We cannot simply guess or speculate, which is off-topic here. See the Network engineering Question Checklist for guidance, then edit your question.
    – Ron Maupin
    Commented Jun 8, 2018 at 4:14
  • I've added some of the relevant config. I have a strong suspicion that this was blocked by spanning-tree etherchannel guard misconfig, but I'm not sure what it is really doing.
    – Yanzzee
    Commented Jun 8, 2018 at 4:57
  • One of the things in the checklist says that you should properly format the configurations, but you have not done that. There is the Preformatted-text option {{}), and you need to use that. Also we really want to see the full configurations (there are other configurations that have an impact, for example, the STP priority that seems to make the new switch the root), and other things like the results from show vlan, show trunk, show port-channel, etc. also, a simple network diagram would go a long way.
    – Ron Maupin
    Commented Jun 8, 2018 at 5:05
  • Sorry, I'm sure I don't have permission to post entire configs to a public site. At best I could redact them, but it will take less time to just recreate the situation in a lab.
    – Yanzzee
    Commented Jun 8, 2018 at 13:39

2 Answers 2


I understand that this is an incorrect configuration, but what was blocking traffic to the new switch? Is this part of the port channel or spanning tree or something else?

Nothing was actually "blocking" the traffic to the new switch, the traffic was simply being forwarded to the wrong switch. This is normal operation of ports that are part of a LAG.

The key principal at work here is that the two physical links that are aggregated together (i.e. LAG, etherchannel, etc) are treated as one logical link between switches. When the switch learns the port from which a MAC address is sourced, this is learned on the LAG link, not the physical link.

Your distribution switch (3750-12S) with the static "on" configuration for the link aggregation believes that both physical links are connected to the same device (your old switch, the 3750-48P in this case) even when one of the connections is moved to the new switch. By default (you didn't provide any configuration to indicate otherwise), a 3750 uses the source-MAC of a incoming packet to determine which of the two links to send a frame on. The source-MAC is hashed, always resulting in the frames from the same interface being sent to the same link.

What likely happened is that all traffic destined for the new switch resulted in a hash that used the link going to the 3750-48P. This may be because there was a L3 transition between the source and destination IP address (i.e. a L3 interface/gateway that was the source-MAC of all traffic), you only used a single host (which happened to hash to the 3750-48P link), or you were unlucky enough to use multiple hosts which all had source-MACs that hashed to the 3750-48P link.

Removing the link to the old switch from the LAG group results in the 3750-12S only having a single choice on which link to send the traffic (i.e. 100% of hashed traffic now goes down the link to the new switch).

What is the risk of a new switch coming up and existing link going down?

Not entirely sure what you mean here, but if another new switch is connected and the link is not part of the LAG group, then there should be no effect due to the LAG group.

You could still have issues with spanning-tree or other loop prevention features depending on how it "comes up."

  • What I meant by the risk of a new switch coming up and existing link going down is, in a similar situation, what are the chances of the symptoms of each side of the port channel to be reversed. Effectively bringing the old switch down and new switch would be up.
    – Yanzzee
    Commented Jun 8, 2018 at 13:41
  • 1
    If another switch is added, as long as the links connecting to it are not part of a LAG group, there will be no effect on the LAG group. If a similar situation reoccurring in the future is of concern to you, then transition your LAGs from static on configurations to LACP on both sides (Cisco side, use "active" instead of "on"). With LACP, if one link of the LAG is moved to a different switch, LACP will fail to negotiate and the link will operate independently of the LAG group.
    – YLearn
    Commented Jun 8, 2018 at 18:05

Based on your diagram, you cannot port channel. A port channel is between two devices. An port channel must start on one device, and terminate on another device. The port channel represents a single link between two devices that is actually comprised of multiple links.

I don't think you really understand what a port channel does. It primarily fools spanning-tree into thinking that multiple interfaces are a single interface so that STP doesn't block one of the interfaces, as it normally would to prevent a layer-2 loop. What your diagram shows is that you could end up with a layer-2 broadcast loop that would crash your entire network.

You can have a single link to each access switch, a port channel to each access switch, or a single link to one access switch and a port channel to the other access switch, but you cannot have a port channel split between switches.

The easiest thing to do right now is to remove the distribution switch interfaces from the channel group.

I would also be concerned about the spanning-tree priority 4 on the new switch. You need the distribution switch to be the root bridge. You have not provided the necessary configurations, as I asked, so I don't have all the information. The default STP priority for a switch is 32768, and the switch with the lowest priority will be the root bridge. You absolutely do not want an access switch as the root bridge. If two switches have the same priority, then the switch MAC address will determine the root bridge.

  • I wouldn’t be too concerned by the “spanning-tree priority 4” command. This is actually an interface priority command that the Aruba switches add by default whenever a port-channel (trunk in Aruba terminology) is created. It just sets the STP port priority rather than the bridge priority.
    – user27899
    Commented Jun 8, 2018 at 6:35
  • I understand that the configuration is incorrect. A technician physically moved the connection before telling anyone. After he did tell me, I removed one of the distribution switch interfaces from the channel group, and that resolved the symptoms.
    – Yanzzee
    Commented Jun 8, 2018 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.