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
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