Consider the following output.
How is this possible, when no AAA or Privilege Profiles are configured? Have a look at the interface configuration:
Is this a bug/feature/annoyance. Depending on the platform, this is a feature. This test-interface is part of a port-channel. This is a common operational mistake. How many times has it happened in one of your data centers, where an engineer accidentally made a change to an interface which was a member of a port-channel, only to bring the port-channel and possibly any customer data that traversed the link down?
This is one of the most common switch configuration mistakes I see. To make it worse, using AAA or Privilege profiles to block specific changes to port-channel member interfaces are almost impossible in dense data centers. The problem here is that the configuration on a member interface and that of the port-channel interface have little relation and that there are no semantic checks in place.
Consider how a port-channel is typically configured on a Cisco Catalyst switch:
3750(config)#int range GigabitEthernet1/0/10 3750(config-if-range)#switchport trunk encap dot 3750(config-if-range)#sw mode trunk 3750(config-if-range)#switchport trunk allowed vlan 10 3750(config-if-range)#no shut 3750(config-if-range)#channel-group 11 mode active Creating a port-channel interface Port-channel 11
Observe that the member interface interface was configured and tied to the port-channel interface, yet the port-channel did not inherit any configuration. This requires the port-channel interface to be configured separately to be the same as the member interface.
3750(config-if-range)#do sh run int GigabitEthernet1/0/10 Building configuration... Current configuration : 190 bytes ! interface GigabitEthernet1/0/10 description test-on-3750 switchport trunk encapsulation dot1q switchport trunk allowed vlan 10 switchport mode trunk channel-group 11 mode active end 3750(config-if-range)#do sh run int port 11 Building configuration... Current configuration : 32 bytes ! interface Port-channel11 end
Port-channels
To most it’s a swear word, to some it’s just a nasty means to mitigate the STP footprint, to others it’s a easy method to increase uplink bandwidth without changing a device. Love it or hate it, it’s used often.
The problem depicted in the first picture and as described on catalyst switches is not a problem on the Cisco Nexus series switches. Cisco finally build some intelligence into the the one of the most basic and commonly used technologies in data-centers.
- Firstly a port-channel on a Nexus inherits the config of the member interfaces.
- Secondly there are semantic checks. If the port-channel already exists and the imported config does not match, an error will be produced. Optionally there is a ‘force’ keyword available to overwrite the config on the already existing port-channel interface.
- Thirdly build-in security checks, to prevent accidental configuration changes on member interfaces.
It is the third point that is illustrated in the first picture above. This feature is enabled by default. Another small thing on the Nexus switches I have come to appreciate greatly.
Follow @routingbits
Routing-Bits 
I got caught out with a different port-channel issue last week. It truly had me stumped for a good hour. See if you can spot the issue. It goes as follows:
1 x 6509 core switch
5 x access switches
Customer required that each switch have 2Gb/s bandwidth to the core 6500 by means of an Etherchannel on dual fibre uplinks. So I’m in front of the 6500 to begin this and I configure all the Etherchannels on the core first, with the intention to walk to each access switch and do the Etherchannels switch by switch via console. To begin with, all the dual physical uplinks are connected and ‘up up’. Then I couldn’t figure out why the Etherchannels wouldn’t come up.
It’s not code related…
what was the problem in the end
just wanted to share, L2 port channel, need to configure the port-channel first, then on the physical interface, enter the channel-group (id) mode on. The physical interfaces will inherit the configurations from the port-channel interface. Followed Cisco steps where we configure the channel-group after the vlan allowed command, totally didn’t work. This was done on N7010 version 5.2.1 (10Gb interfaces).
Correct, the port-channel configuration is slightly different on the Nexus.
A different method to what you mentioned is by using the “force” keyword to force the PO to inherit the member config.
:)
nope, even the force keyword did not work, all because it detects the vlan allowed config, but at the end it inherited from the po config anyway.