Best practice with EtherChannel configs

When configuring EtherChannels, which commands should be set on both the ports in the channel group and the port channel interface? Is there a best practice for this? I would expect replicating the config on each port and the channel interface would be the way to go.

For example:

int port-channel 1
switchport mode trunk
switchport trunk native vlan 10
switchport trunk allowed vlan 1,20,30,40,50

int fa 0/1
switchport mode trunk
switchport trunk native vlan 10
switchport trunk allowed vlan 1,20,30,40,50
channel-protocol lacp
channel-group 1 mode active

int fa 0/2
switchport mode trunk
switchport trunk native vlan 10
switchport trunk allowed vlan 1,20,30,40,50
channel-protocol lacp
channel-group 1 mode passive

The config would function without any of the switchport commands on the individual ports but I would assume you would want to replicate the design on the ports so if the etherchannel were to go down, the individual port remaining would continue to run as intended. Is this a correct assumption? Haven't seen this covered in detail in my SWITCH studies so far.

Find more posts tagged with

Comments

boobobobobob

I only configure the port channel interface. It makes for a shorter config file and if you have 300+ ports with multiple port channels it make a huge difference. The only way a port channel would stop functioning and use the actual commands placed under the interface itself is if you delete the port-channel.

MickQ

Personally I configure the physical ports to be in the etherchannel and then do the etherchannel specifics in the portchannel config.

I see that you've made one side active and the other passive.
Best practice in the CCNP is for both to be active/desirable/on. However, in the Security side of things, it's to make them both on and have "nonegotiate".

powmia

MickQ wrote: »

Personally I configure the physical ports to be in the etherchannel and then do the etherchannel specifics in the portchannel config.

I see that you've made one side active and the other passive.
Best practice in the CCNP is for both to be active/desirable/on. However, in the Security side of things, it's to make them both on and have "nonegotiate".

Until you're connecting to a storage device or blade chassis that will only form a bundle if LACP is used, or you just like the possibility of creating one of the most difficult to troubleshoot scenarios when there is a physical fault or misconfiguration. Part of security... is availability, ie.. eliminating the possibility of a self-induced DoS.

LACP active is what you'll see most often in the wild.

MickQ

powmia wrote: »

LACP active is what you'll see most often in the wild.

Yep. I should clarify, I meant "on" and "no-negotiate" in the Security side of thing as being for Cisco security exams rather than real world.

iamme4eva

powmia wrote: »

or you just like the possibility of creating one of the most difficult to troubleshoot scenarios when there is a physical fault or misconfiguration.

Can you expand on this? Why is on/nonegotiate bad?

powmia

MickQ wrote: »

Yep. I should clarify, I meant "on" and "no-negotiate" in the Security side of thing as being for Cisco security exams rather than real world.

lol, yeah... the book smarts and street smarts difference applies to networking as well.

powmia

iamme4eva wrote: »

Can you expand on this? Why is on/nonegotiate bad?

You don't want to just statically send frames out a member of your etherchannel without verifying that the port on the other side is actually a member of the other switches etherchannel. You might just be sending a portion of your frames to an access port that is in some random vlan.

instant000

iamme4eva wrote: »

Can you expand on this? Why is on/nonegotiate bad?

My take on it is that a negotiating protocol (LACP,PAgP) has certain checks it performs, whereas an unconditional setting (On) does not. It is these checks the negotiating protocols make, which are most aggressive in their respective Active/Active or Desirable/Desirable settings, which helps things be copasetic.

The use of LACP is strongly recommended. Using the "on" mode is dangerous as in certain scenarios when one device is already configured and the other is not, switching loops and/or MAC address flapping can occur. I have seen similar scenarios during my SWITCH course trainings far too often.

https://supportforums.cisco.com/thread/2138446

The recommended settings for switches that you want to form and EtherChannel is to have both switches set to desirable mode. This gives the most robust behavior should one side or the other encounter error situations or be reset.

Troubleshooting LAN Switching Environments - Cisco Systems

^This was for PAgP, but I'm assuming similar mentality for LACP. (and yes, the typo "and" is from Cisco)

EDIT: It seems that powmia said it much more succinctly.

iamme4eva

Fair enough, that makes sense.

Thanks both of you!

aaron0011

Just to clarify, best practice is only configure individual ports with commands required? So if port is going to be part of EtherChannel no need to set port to trunk or it's native vlan, let the etherchannel config handle that for the group of ports?

powmia

It's platform dependent. Some code will copy the configurations from the physical ports to the logical port, some won't. Same in the other direction... some will copy the config from the logical port to the physical ports, some will not.

Regardless of the behavior of the device, or the order in which you configure them, it is best to make sure you have a common configuration on the logical port-channel interface, as well as the underlying physical ports.

aaron0011

powmia wrote: »

It's platform dependent. Some code will copy the configurations from the physical ports to the logical port, some won't. Same in the other direction... some will copy the config from the logical port to the physical ports, some will not.

Regardless of the behavior of the device, or the order in which you configure them, it is best to make sure you have a common configuration on the logical port-channel interface, as well as the underlying physical ports.

Thanks, that was my original thought in my first post.