Overview of Problem

Recently there was a post on Linkedin about port aggregation and the use of negotiation. It’s really disturbing seeing how many people recommend not using LACP or PaGP to configure aggregated ports (port-channels|etherchannels). Seems to be common misconception that if two switches are back-to-back configuring an on mode is acceptable. In the Cisco world, it’s not even quicker to configure on over the other negotiating protocols. So why do it when you can have fail-safe method of configuring them. The only option I would see is a server/device that does not support LACP, which is hard to find now a days (new anyways).

Mistake in Practice

What happens if even “back-to-back” switches get mistakenly cabled? Everyone assumes that they’re always in the same closet or near by. But in the real world this is hardly the case, and there’s usually hundreds of feet between direct cable runs. Some ideal environments have patch-panels and such, but that still constitutes as a back-to-back connection; doesn’t it?

So what’s the situation when, lets say you’re troubleshooting a completely separate problem. Yet, trying to get to the root, maybe cables are moved, reconnected; not everyone labels things correctly, or keeps track of all things in their mind. Sometimes in heat of the issue you’re trying to solve, you over look certain aspects of what you’ve already done.

The situation below happened recently, where someone was troubleshooting a completely mundane problem. Just some phones not receiving IP addresses via DHCP. Not completely understanding the problem, or where to begin, the approach was, rip and well see what happens. When I arrived at the place, the situation had already escalated to something much worse; Like the entire network going down and no one being able to work.

Diagram

Description

The two access switches are in the same wiring closet and connect via a port-channel to a “core” switch. Yes, it’s a smaller environment, simple two story office building with about 200 or so users. The part on the left is the way it was configured when the initial problem arose. The part on the right is what happened after some cables had been disconnected and put back into place; or not the right place. There were more switches in here, but not part of the root cause but definitely affected. The sample configuration of the port-channel was something like;

int range gx/x - x/x
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan x-xxx
 channel-group xx mode on
!
interface port-channel x
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan x-xxx
!

This was the same on both ends, and there was no root-guard, loop-guard*, udld or any other loop prevention technique applied. So what happens to an unknown unicast in this case? Well, as we all learned back in the CCNA days, it gets flooded out all ports in the same VLAN and all trunk ports that carry that VLAN. With the port-channel being in mode on all that needs to happen for the port-channel to come up, is, well the link to come up.

The obvious disaster here is well, very freaking obvious and needless to say, that, the ensuing problem was more than just certain phones not getting DHCP.

Summary

Very simple, if you’re configuring port-channels (port aggregation, or trunk ports on some vendors). Do yourself a favor, use LACP, if you must, then use PaGP. Leave mode on for lab testing, or occasions where you really have no choice. Even things that may seem simple can easily get complicated when things go wrong. Use UDLD where ever possible, as well ass root-guard, loop-guard, bpdu-guard, bridge assurance and all those other tools we have.