By default, the switch will use both the source and destination IP addresses to generate the hash, but there are lots of others.

• src-ip:  Just the source IP
• dst-ip:  Just the destination IP
• src-dst-ip:  Both the source and destination IPs
• src-mac:  Just the source MAC
• dst-mac:  Just the destination MAC
• src-dst-mac:  The source and destination MACs
• src-port:  Just the source TCP/UDP port
• dst-port:  Just the destination TCP/UPD port
• src-dst-port:  The source and destination TCP/UDP ports

You change the method by giving the port-channel load-balance method directive in global config mode.  Notice that this is a system command, so any change affects all channel groups.

To generate the hash, the switch takes the binary representation of the address(es) and does a XOR (that is, are they different? yes/no) on the last few bits of each to get a value.  If you have 8 interfaces, it uses the last 3 bits (2^3 = 8).  If you have 4 interfaces, it uses 2 bits.  Two interfaces means a single bit.

What we wind up with is an index of the interface to use.  If you do a show etherchannel detail on your switch, you’ll see each interface is assigned an index that starts with 0.

Let’s go through an example.  You have a switch that has F0/1(index 0) and F0/2 (index 1) in Po10.  You also have left the load-balancing method to the default of src-dst-ip.  The switch needs to forward a packet that is sourced from 10.0.0.1 and destined to 10.0.0.2 over Po10.  Let’s step through it.

10.0.0.1 = 00001010 00000000 00000000 00000001
10.0.0.2 = 00001010 00000000 00000000 00000010

Since we have two interfaces in the channel group, we look at the last bit of each address and XOR them to get an index of 1 (1 XOR 0 = 1).  That’s F0/2, so that interface will be used to send the frame over.

If we add f0/3 and f0/4 to the channel group, we would calculate a XOR on the last 2 bits of each address, which would give us 11, which is 3 in binary.  The interface with an index of 3 (probably f0/4) would get the traffic.

What if I’m switching IPX packets?  Any non-IP packet will default to using the MAC address.  Can someone answer exactly what method it will be used?

What if we then add f0/5?  That’s a good question, but I’m not exactly sure how the switch handles a number of interfaces not a power of 2.  Can someone help on this, too?

Send any obvious corrections and questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

A switch port on a 2960 comes up with a default configuration on VLAN 1.  What happens from the perspective of spanning-tree?

• First, the port comes up on blocking mode.  This is to make sure that loops aren’t created without first listening to the network to see what’s going on.
• Next, if the port may be a root or designated port, the port is moved to the listening state.  In this state, the port can send and receives BPDUs only.  It can’t send traffic, but it can discover the other switches participating in STP.
• After the forwarding delay, the port goes into the learning state.   In this state, the port can send and receive BPDUs as in listening, but it can now receive traffic.  It can’t yet send any.
• After the forwarding delay again, the port goes into the forwarding state.  The port can now send and receive data.

If the port is configured with spanning-tree portfast, the mode goes from blocking directly to forwarding without going through these steps.  Obviously you don’t want a switch plugged into a port configured for portfast since you may wind up with a loop.

Here’s the debug spanning-tree events output from one of my labs.  F0/3 is configured for portfast.  I shut/no shut it to see what happens.

*Mar  8 18:09:51.163: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
sw01#
*Mar  8 18:09:51.747: set portid: VLAN0007 Fa0/3: new port id 8003
*Mar  8 18:09:51.747: STP: VLAN0007 Fa0/3 ->jump to forwarding from blocking
sw01#
*Mar  8 18:09:53.739: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up
*Mar  8 18:09:54.739: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up

Notice the “jump to forwarding from blocking”.

Here’s the same output when the port is not in portfast mode.  Notice the timestamps.  It takes about 30 seconds (2 x default foward delay) to go from blocking to listening to learning to forwarding.

*Mar  8 18:13:05.313: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
sw01#
*Mar  8 18:13:06.013: set portid: VLAN0007 Fa0/3: new port id 8003
*Mar  8 18:13:06.013: STP: VLAN0007 Fa0/3 -> listening
sw01#
*Mar  8 18:13:06.381: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up
*Mar  8 18:13:07.381: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up
sw01#
*Mar  8 18:13:21.013: STP: VLAN0007 Fa0/3 -> learning
sw01#
*Mar  8 18:13:36.013: STP: VLAN0007 Fa0/3 -> forwarding

Send any obvious corrections and questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts