Sunday, October 10, 2010

An EtherChannel using dissimilar hardware

I had to build a 2x 10Gb/s aggregate link with one member on a 6704 CFC card and the other member on a 6716 DFC3 card. Not ideal, but it was what I had to work with.
I knew going in that I'd need to configure no mls qos channel-consistency on the port channel interface because these cards have different hardware queueing capabilities. Somehow I forgot this detail immediately prior to the implementation.
The etherchannel interface was up with just the 6704, and I was adding the new link to the mix. My plan was to do show run int tengig x/y on the existing member link, and then copy/paste that configuration onto the new member link.
Everything went fine until I got to switchport trunk encapsulation dot1q, which earned me a %Unrecognized command in reply. I've noticed that on some platforms you can't tell a tagging interface what type of encapsulation to use because you don't have multiple encapsulation options anymore: ISL is obsolete, and support for it is drying up. ...What I hadn't noticed until right then is that support for ISL varies on a per-module basis within a platform: The 6704 could do ISL and required the encapsulation type directive, but the 6716 can't do ISL, and wouldn't accept the encapsulation command. Huh. Encapsulation/decapsulation is a hardware feature. It makes perfect sense, but I'd never considered it before.
The next thing I noticed is that the 6716 wasn't joining the aggregation. I puzzled over this for a while, comparing the running configuration of the two intended link members. With the exception of the 'encapsulation' directive, they were identical, but the 6716 wouldn't join the aggregation.
My problem, of course, was the QoS consistency check. EtherChannel doesn't care if the configuration on each interface looks the same. It only matters they are running the same, which they were.
Once I disabled the QoS consistency check, the 6716 link joined the 6704 link, and everything was fine. Of course, I didn't remember to disable the consistency check until immediately after I'd downed the 6716 interface, ripped it out of the channel-group, set the STP port path cost ridiculously high, and brought up the second link as an STP-blocked alternate path.
No change is so simple that it doesn't deserve a detailed execution plan.

1 comment:

  1. Hey Chris,
    If its a 10gig port, then the encapsulation is dot1q by default.
    You can check this by issuing the command "Sh interface trunk"