CCNP SWITCH Etherchannel Course: The Negotiations
In the first part of this CCNP SWITCH course on Etherchannels, we reviewed the fundamentals of Etherchannel success using this two-switch network. Multilayer switches, that is. Each switch is trunking via their Fast 0/21, 0/22, 0/23, and 0/24 ports, with Fast 0/21 on SW2 connected to SW3’s Fast 0/21, and so forth.
Now we’ll dig into the nuts and bolts of an Etherchannel, beginning with the negotiation. The industry standard is the Link Aggregation Control Protocol (LACP) and the Cisco-proprietary option is the Port Aggregation Protocol (PAgP).
I hate how hard it is to type “PAgP”, but I love one thing about this protocol, and that’s how the protocol dynamically changes all of the other ports in an EC when you change a property of one of them statically (speed, duplex, etc.)
Defined in 802.3ad (the IEEE standard, not the year), LACP assigns a priority value to each port with Etherchannel capability. You can assign up to 16 ports to an LACP-negotiated Etherchannel, but only the eight ports with the lowest port priority will actually be part of the EC. The remaining ports will be bundled only if one or more of the already-bundled ports fails.
PAgP and LACP use different terminology to express the same modes. (Surprise!) We actually saw those in the channel-group command in the previous lab:
SW3(config)#int fast 0/24 SW3(config-if)#channel-group 5 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected
With PAgP, a port in desirable mode will initiate bundling with a remote port, while a port in auto mode waits for the port on the other end of the trunk to start the process. If the ports at each endpoint are in auto, you know you’ll be waiting a long time.
With LACP, a port in active mode initiates bundling while passive ports will not initiate anything. If the ports at each endpoint are passive, you will again be waiting a very long time for the EC to form. At least one endpoint must be in active mode.
I’ll put all four available trunks into a PAgP Etherchannel, verifying with show pagp neighbor.
SW2(config)#int range fast 0/21 - 24 SW2(config-if-range)#channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected SW2(config-if-range)#channel-group 1 mode desirable
SW3(config)#int range fast 0/21 - 24 SW3(config-if-range)#channel-group 5 mode desir SW3#show pagp neighbor Flags: S - Device is sending Slow hello. C - Device is in Consistent state. A - Device is in Auto mode. P - Device learns on physical port. Channel group 5 neighbors Partner Partner Partner Partner Group Port Name Device ID Port Age Flags Cap. Fa0/21 SW2 0017.9466.f780 Fa0/21 14s SC 10001 Fa0/22 SW2 0017.9466.f780 Fa0/22 2s SC 10001 Fa0/23 SW2 0017.9466.f780 Fa0/23 5s SC 10001 Fa0/24 SW2 0017.9466.f780 Fa0/24 11s SC 10001
We’re not going to get into every field of this output, but I’m sure you can see having a command that gives you the name, device ID, and port of the partner in the group can be very helpful for verification and/or troubleshooting.
After removing the PAgP EC, I created one with LACP, verified with show lacp neighbor.
SW2(config)#int range fast 0/21 - 24 SW2(config-if-range)#channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected SW2(config-if-range)#channel-group 1 mode active
SW3(config)#int range fast 0/21 - 24 SW3(config-if-range)#channel-group 5 mode active SW3#show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 5 neighbors Partner's information: Port Flags Priority Dev ID Age key Key Number State Fa0/21 SA 32768 0017.9466.f780 20s 0x0 0x1 0x118 0x3D Fa0/22 SA 32768 0017.9466.f780 19s 0x0 0x1 0x119 0x3D Fa0/23 SA 32768 0017.9466.f780 21s 0x0 0x1 0x11A 0x3D Fa0/24 SA 32768 0017.9466.f780 23s 0x0 0x1 0x11B 0x3D
The output is different, but matching up the Device ID – Port information can be very helpful in troubleshooting. I’ve also used show etherchannel brief in troubleshooting, but that command’s on the way out:
SW3#show etherchannel brief % Command accepted but obsolete, unreleased or unsupported; see documentation. Channel-group listing: ---------------------- Group: 5 ---------- Group state = L2 Ports: 4 Maxports = 16 Port-channels: 1 Max Port-channels = 16 Protocol: LACP Minimum Links: 0
No such message with show etherchannel summary.
SW3#show etherchannel summary Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port
Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+--------------------------------- 5 Po5(SU) LACP Fa0/21(P) Fa0/22(P) Fa0/23(P) Fa0/24(P)
That’s more like it! All four ports are marked with the “P” flag, meaning they’re part of a port-channel, and that’s just what we wanted to see. Note the flags next to Po5, “SU”. The “U” indicates the channel is in use (good) and the “S” means it’s a Layer 2 Etherchannel.
Coming up next, we’ll take a very detailed look at how a Cisco switch decides which active Etherchannel link should be used to carry a particular data flow – and when the XOR operation gets involved and when it does not.