Cisco Cisco-Catalyst Trunk Port-Channel Aruba – Port Channel to Two Different Switches

arubaciscocisco-catalystport-channeltrunk

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

Diagram

Best Answer

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."

Related Topic