Skip to content


a few words about EtherChannel

Originally, this technology was meant to protect a host against a failure of its network adapter and/or switch (network switch). Additionally, some unscrupulous salesmen claimed a fantastic increase in throughput aka two adapters tied together will double, three adapters tied together will triple throughput of the associated with them EtherChannel adapter – yes, in a salesman pure land of fantasy.

In reality you may get a few percent higher (max. at about 20%) – you do not EtherChannel for a volume increase but for a good night sleep! There is a big difference between EtherChannel and (Link) Aggregation these terms have different meaning! Check with your switch documentation as to which term they use to what AIX (IBM) calls EtherChannel to avoid confusion -as in most cases aggregation means a trunk of ports not the EtherChannel. By the way, AIX also supports link aggregation.

As you contemplate EtherChannel for your own use, keep in mind that AIX for a long time (I do not remember the version number) has the future called backup adapter …… and that at certain time (check it against your verion of AIX) an EtherChannel adapter built on top of two physical NIC’s (one being the PRIMARY and the second being the BACKUP) was not really an EtherChannel adapter and it requires no changes to the settings of their switches ports…. Finally, it is a BAD idea to connect EtherChannel adapter and its BACKUP adapter to a single switch, really.

Sometimes, the cables that you are convinced lead to different switches are in reality attached to the same switch – the one which just lost power and as the result the most important application was just killed by the cluster deamon on the node that now has no network connectivity and it was moved to the standby node in the other data center with the understandable few minute delay in the application services. It could not happen in a better moment!

To make the long story short, at the end of the day the cables have to be traced, labeled and the date scheduled for their swap. The question remains the same – how do you verify/check what cable goes to the switch A and what cable goes to switch B? What? Why? Well, as the BACKUP adapter is free from traffic its switch port cannot “see” its MAC address.

Let’s agree that our EtherChannel adapter is ent8 consists of ent0 and its backup adapter is ent4. The following shows how you can produce these details. In the output bellow, the entry adapter_names (plural) is not a mistake. An EtherChannel NIC may employee more than one physical NIC and this set of NIC’s may be protected by yet another physical NIC which role is to assume the role of the all composite adapters if they all fail and die – this is the BACKUP adapter. For as long as a single composite EtherChannel adapter is working the BACKUP adapter does nothing, it springs to live when the last component NIC dies an honorable death.

# lsattr -El ent8 | grep adapter  
adapter_names  ent0 EtherChannel Adapters                      True
backup_adapter ent4 Adapter used when whole channel fails      True

It is easy to validate/verify that each participating adapter is connected do a different switch while you are implementing EtherChannel – just assigned an IP address to each one by one each time asking LAN administrator to validate the connection with the switch (he can see individual adapter MAC address). Later it is not as easy….. To repeat the same procedure you have to destroy the EtherChannel and sometimes you may not be able to do it for reasons that are beyond you. So in this case just flip the roles – let BACKUP become ACTIVE and the MAC should be seen (hopefully on the other switch).

MAC – is it the MAC or is it not the MAC? Well, EtherChannel is really cool as it not only allow to group NIC together to keep the resulting logical adapter alive if its components start to die, additionally it allow you to have a backup adapter just in case all the “primary” components (adapters) are no longer operational. The whole idea of multiple adapters sharing the same IP address raises an immediate question which is – “what about the MAC address associated with this IP address?” Why? The changing MAC address may not be really well accepted neither by the operating system on the receiving end, its application of the intermittent routers or switches as in reality this breaks on of the principals of TCP/IP. I think, it is better to use EtherChannel ability yo assign on MAC to all its component adapters. In my case I create this new MAC replacing the first try characters of the first MAC with the string BADBEEF which consists of all valid hex characters …:-) In this case, it is easy to spot the address of an EtherChannel adapter on a switch.
So consult with your switch/router manual ahead of go-live date. There is one more issue to consider here – are the switches capable of sharing vlans? Can a vlanA on port X of switch A be also assigned to port Y of switch B? Most likely this is not an issue, still ask before the go-live.

Since, the existing EtherChannel adapter could not be destroyed, another way had to be identified to validate its components connectivity. There is such a way! All that needs to be done is to flip the adapter roles! To flip the adapters roles (so ent4 becomes the ACTIVE and ent8 becomes the BACKUP) you would have to execute the next command – ethchan_config.

# /usr/lib/methods/ethchan_config -f ent8

I like to exercise my extremities so I do not have the /usr/lib/methods in my PATH ….. 🙂

So far, it works because the EtherChannel adapter had only one primary adapter (ent8). What if there is more? You could use the -d command line options to remove the components adapters till the EtherChannel has the only on active physical adapter and after testing you could re-add whatever you have removed with the -a option for example:

# /usr/lib/methods/ethchan_config -d entX

Test connectivity, and re-add the adapter to the EtherChannel:

# /usr/lib/methods/ethchan_config -a entX

By the way, the last command is really a cool tool to create and to manipulate EtherChannel devices – highly recommended (of course everything EtherChannel wise can be done via smitty too).

If you can, I recommend you insist that the cables from the EtherChannel adapters are of the different color than the cable used to provide connectivity to its BACKUP adapter, really sometimes it is worth it.

At few earlier posts, I mentioned the fact that computer science is in 2.333% (approx.) based on magic, and as such any procedure provided by manufacturer and/or this posts may fail when YOU are attempting to perform it. This one as any other of your failures as a system administrator may also be result of a combination of operating system and firmware versions, your overall luck and your accumulated karma. With this in mind, make sure you understand what you are about to do, set your expectations appropriately, test your procedure and schedule its date/time to minimize any negative outcome.

Play it safe in a data center be a hero in a pub celebrating your victory over a machine later!

Posted in Real life AIX.


0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.



Some HTML is OK

or, reply to this post via trackback.

WordPress Anti Spam by WP-SpamShield



Copyright © 2016 - 2017 Waldemar Mark Duszyk. All Rights Reserved. Created by Blog Copyright.