I've got a rather odd problem with a port-channel configuration on my 6509 (IOS 12.2(33)SXI4a) with redundant Sup720s. Before I go much further with trying to remedy it through experimentation I wanted to get some input from others in case anyone else has seen this behavior. I think I may know why it's happened, but I'd prefer to better understand the reasons and also the best way to resolve it.
We have many servers in our environment configured with dual copper 1Gb interfaces running in a bundled Etherchannel config to our 6509 core switch. We're using LACP (active) to support the bundling between switch and servers
We started off with a few WS-X6148A-GE-TX line-cards installed to support the lower throughput of our servers at the time and save some money. These line cards are oversubscribed at about an 8-to-1 ratio as far as bandwidth goes, and we were getting by with this for quite a while. It became apparent over the last year that we had a few heavy-hitting servers that were getting a lot of dropped frames because the switch interfaces weren't able to keep up, so we purchased a WS-X6748-GE-TX line card which is nearly full line-speed capable per port.
Because we wanted to migrate these servers to the new line-card with minimal downtime I figured the easy way to do this was the following:
1) Put two interfaces on the new line-card into the same port-channel group as the currently in-use ports for that server.
2) Move one cable to one of the new ports and wait for that port to come online in the bundle.
3) Move the remaining cable to the other new port and confirm it bundled.
4) Remove the two old ports on the slow line-card from the port-channel config.
Using this method with two servers so far has worked pretty flawlessly without breaking communication to the servers. However I seem to have some odd leftover information in my config that's bothering me. Following is an example:
den-sw35aa#sh etherchan 36 sum
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 N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, no aggregation due to minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
d - default port
w - waiting to be aggregated
Number of channel-groups in use: 35
Number of aggregators: 37
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
36 Po36(SD) LACP
36 Po36A(SU) LACP Gi2/9(P) Gi2/19(P)
Last applied Hash Distribution Algorithm: Fixed
As you can see, I now have two port-channel groups under this etherchannel config. No ports are assigned to the original Po36, and the new Po36A contains the two new ports.
It also shows that I have 37 aggregators and only 35 channel-groups actually in use. I'm wondering if this is going to happen with every server that I do this for, and, in the end, reduce the total port-channel groups I can configure and have in use.
My thought of why this might have happened go back to fundamental differences in the line-cards themselves. Going from a non-fabric enabled card to a fabric enabled one was probably a little too much to expect a full four way bundle to occur when I put all four ports in the group.
As far as getting rid of it, I'm thinking of shutting down the port-channel interface itself, then the physical ports, then bringing everything back up in reverse order. I'm hoping it wouldn't come down to shutting ports down and deconfiguring the whole port-channel config, then reconfiguring. At the very worst a switch reboot, but that is absolutely a last resort, and only if I were to find that this was having some kind of negative performance impact.
Any input or previous exprience would be appreciated. I've been unable to find anyone in the forum relating a similar story and documentation hasn't gotten me anywhere.
Best Regards,
Ty
