How to change a Cisco Nexus interface from mode access to trunk when used in a port-channel group

Written by - 0 comments

Published on - Listed in Network Hardware


Managing network switches is not something I do on a regular basis (there are experts, called network engineers, for this). However it does happen from time to time and some commands (such as conf t, wr and others) still remain in my head.

But recently I ran into a weird "issue", when I wanted to re-configure a switchport/interface on a Cisco Nexus 3000 switch.

Changing interface from mode access to trunk (fails)

The interface was currently set to mode access:

nexus# show run int Ethernet 1/2

!Command: show running-config interface Ethernet1/2
!Time: Sat Jan  6 00:37:20 2001

version 6.0(2)U6(10)

interface Ethernet1/2
  switchport access vlan 10
  channel-group 2 mode active

From the output we can see that the interface is currently a switchport in mode access and with vlan 10 configured. It also shows that this interface is part of a port-channel (channel-group).

According to the Cisco Nexus 3000 documentation, the commands are pretty straightforward:

Pretty standard interface configuration, right? So let's do this:

nexus# conf t
nexus(config)# int Ethernet1/2
nexus(config-if)# switchport trunk allow vlan 10-12
                             ^
% Invalid command at '^' marker.

Huh? What did I do wrong?

Even ChatGPT says this is correct *rofl*

After spending an hour on research and re-reading documentation (and not finding a different config syntax) I decided to ask ChatGPT for a solution. Hey, maybe the AI knows something I don't.

Interestingly the chat bot told me the exact same configuration way, with one minor difference: It suggested to first remove the current mode access (which actually makes sense):

But this failed with another "Invalid command at ^ marker" error, too!

Interface in a channel-group? Use the port-channel interface for changes!

When I was just about to give up and wait for the network engineer, I stumbled on a very interesting networking thread on Reddit, where the OP ran into very similar issues as I did. One of the comments (from user Grockin100) was very intriguing but extremely helpful to me:

You need to make changes on the logical port-channel. And no, you don’t need to remove the port from the port-channel to make change like some people have suggested unless there was some inconsistency on your individual ports.
- Grockin100 on Reddit

Whoah... I did not think of that. Would the change on the port-channel actually be automatically applied on the interfaces being a member of that channel-group? Let's find out:

nexus# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
nexus(config)# int port-channel 2
nexus(config-if)# no switchport access vlan 10
nexus(config-if)# switchport mode trunk
nexus(config-if)# switchport trunk allowed vlan 10-12
nexus(config-if)# end

No error so far...

But how does the running config look now for the modified port-channel and, more importantly, for the interface Ethernet1/2?

nexus# show run

[...]
interface port-channel2
  speed 10000
  switchport mode trunk
  switchport trunk allowed vlan 10-12
  vpc 2
[...]
interface Ethernet1/2
  switchport mode trunk
  switchport trunk allowed vlan 10-12
  channel-group 2 mode active

[...]

It actually worked! YAY!

Handling interface configurations on the port-channel interface is actually easier, but if that important piece of knowledge is not with you, you are stuck on (physical) interface configuration and running into syntax errors as me.

It's a bummer that Cisco does not mention this on their official "Configuring Access and Trunk Interfaces" documentation. A small hint/warning, if the interface is a member of a channel-group, would have been helpful for a network novice.


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   OpenSearch   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder