When I first started working with network equipment, it wasn’t long before I setup my first trunk network connection. Configuring single port trunk and access ports was a lot of what I did at first. Like an access port, a trunk port is consists of a single physical connection. That connection can be either a copper or fiber connection. An Etherchannel connection is made up of multiple ports, that can either be only copper, only fiber or a combination of both. The main requirement is that all the ports used in an Etherchannel bundle all be the same speed port. That is to say that, if one port in the ports that you will be placing into bundle is a 10/100 port, all of the ports in that bundle will have to be the same speed port.
When I last did an ether channel, you were limited to a maximum number of 8 ports in a bundle. I have one situation where I had both copper and fiber in an ether channel bundle. In this situation, I had initially started out with a single trunk connection but as the number of servers on the remote switch increase, I knew that I needed to add additional capacity to the trunk connection, hence the move the an etherchannel configuration. While it is possible to migrate from a trunk configuration to etherchannel configuration, there is a risk that the connection between switches could go down, so it would probably be best to do this after hours when having a network disruption would present a minimal problem.
A rule of thumb that I have used when deciding on whether to use copper or fiber is based on several things. If the switches are in the same rack row or being fed by the same electrical panel, then using copper is definitely an option. If the available copper port count is limited or the switches involved at each end of the connection are being fed by different electrical panels, then going with fiber is the way you will need to go. One feature that I can’t stress enough that you will need to use when implementing an etherchannel configuration is UDLD which is an abbreviation for Uni Directional Link Detection. This is a switch/router feature that shuts down a physical connection when traffic is sensed to be only going in one direction. I have had this happen for the most part when one part of a fiber or copper GBIC or SFP fails. In one case, I actually had a cabling problem be the cause of the problem.
There are two schools of thought about implementing UDLD – at a port level or global level. Enabling UDLD on a port that is connected to anything other than another switch really won’t get you anything. Part of the process of UDLD is the switch it is running on seeing its own packet coming back from the remote device. I prefer to enable a feature like this on a port level basis, just in case activating it on a global level might induce a problem that could have otherwise been avoided. UDLD will help automatically bring up a link after the failed SFP/GBIS or cable issue has been resolved. in future posts, I will show how I have implemented UDLD and migrated from a trunk to etherchannel configuration.