NetNotes

Port-channel note

We have the following setup of a port-channel between to Catalyst 3750s - SW1 Gi0/1 and Gi0/2, bundled in a port-channel are connected to Gi0/1 and Gi0/2 on SW2:

SW1:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

SW2:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

In order for the port-channel to form successfully, all port members need to have identical:

• duplex;
• Speed;
• trunking status - access/trunk;
• when in trunk mode - the same encapsulation type;
• when in trunk mode - native vlan;
• when in trunk mode - allowed vlans;
• when in access mode - access vlan;

It is not necessary the list of allowed vlans to be the same on both ends of the port-channel interface, for the port-channel to work but of course vlans that are only allowed on one side of the port-channel will not be reachable.

Catalyst 3750 support the following types of load-balancing between member ports in a portchannel (an important side note regarding load-balancing is that traffic between the same two endpoints always traverses the same member interface in the port-channel):

• src-mac (default) - traffic from different source MAC addresses traverses different member ports in the port-channel;
• dst-mac - traffic to different destination MAC addresses traverses different prots in the port-channel;
• src-dst-mac - based on the low-order bits in the source and destination MAC addresses of different frames, a hash is formed on the basis of which the member port to carry the traffic is determined;
• src-ip - traffic from different source IP addresses is carried over different member ports;
• dst-ip - traffic to different destination IP addresses is carried over different member ports;
• src-dst-ip - a hash is formed based on the low-order bits in the source and destination IP addresses in the IP packets, and traffic distribution across the member ports is based on this hash value;

The selection of a load-balancing algorithm to configure os made by the network operator and should be based on the traffic pattern ot be carried over the port-channel and mostly on the diversity of source and destination MAC/IP addresses in this traffic pattern.

When a change in a port-channel parameter is needed, it is always better for the change to be done starting with the access layer and above, starting from the lowest switch. In this way, any eventual downtime will affect the least number of devices and will be easier to correct.

Changing the list of allowed vlans on a port-channel is an ecample of such a situation. In theory, there are a few possible ways of adding a vlan ot the list of allowed vlans of port-channel1:

1. Adding the new Vlan to the allowed vlans on one of the member ports, then the other, and then the port-channel interface;
2. Adding the new vlan to the allowed vlans on one of the port-channel members, then the port-channel, then the other port-channel member;
3. Adding the new vlan to the allowed vlans on the port-channel interface directly;

Of course the first two ways are not correct in this case, and the correct way of doing this is the third one.

In the first scenario, when we add a vlan to one of the member ports, it will be automatically suspended and unbundled from the port-channel, due to the differences in its vlan-mask, making it incompatible with the other member port.

Due to the load-balancin method specifics, this could lead to some connectivity issues for some or all hosts connected to SW2. If this happens, and we add the new vlan also to Gi0/2 on SW1 quickly enough, the two member ports will get compatible again, so the connecitivty downtime will be short, but of course present.

A problem like this could get a little bit nastier in case the port-channel is used with an Ethernet hand-off for a MAN or a similar scenario. A problem somewhere in the middle between the two hand-offs, or a port unbundling on the remote side will lead to the aforementioned connectivity issues due to the load-balancing algorithm. Such problems could hardly be localized to the port-channel, and in some cases CDP can be of great help for this, as it wil report just one neighbor instead of two, as it would in case both port-channel members were operating correctly.  In a similar scenario, in case the port compatibility and the unbundling issue cannot be resolved immediately, the better solution is to simply remove the corresponding member port from the port-channel on the near side as well, in order to retain full connectivity albeit on half the bandwidth.

In the second approach to add the vlan, the situation is practically the same, with the difference being that after the vlan is added to the port-channel interface, the change will automatically be propagated on all member ports.

It is because of this immediate propagation of al changes on the port-channel interface to all member ports, that the right way of doing this change is to do it on the port-channel interface directly, instead of each of the member ports. Doing it this way will preserve any connectivuty flaps and/or interface status changes for the member ports, and they will receive the updated allowed vlans list without disrupting the functionality of the port-channel interface.

Tags: port-channel, Switching

No comments yet.

Leave a comment