02-25-2017 09:29 PM - edited 03-05-2019 08:06 AM
I have a customer with a Nexus 5500 (N5K-C5548UP) running 5.2(1)N1(8a), which is old, I know. It has two 2000s (N2K-C2248TP-1GE) connected to it.
I wanted to convert the following interface to a trunk, but leaving the other side of the connection (a firewall) unchanged, so I can add sub-interfaces to that side without modifying the primary active untrunked interface. I have done this many times of the years and it generally works great. Here is the configuration before being modified:
interface Ethernet102/1/28
switchport access vlan 17
spanning-tree port type edge
Here are my initial changes:
switchport trunk native vlan 17
switchport trunk allowed vlan 17,517
spanning-tree port type edge trunk
Since the trunking mode is still access, nothing has changed from a practical standpoint yet, and traffic continues fine. But the thing that really makes the change go into effect is:
switchport mode trunk
For some reason at this point, I lose communication to the device plugged into Eth102/1/28, which is untagged on Vlan17. I don't know if it's a code issue, a FEX issue, or what. Any thoughts?
(of course, as cleanup I would remove the "switchport access vlan 17" but that is a mere remnant once the port is set to trunking).
02-25-2017 11:53 PM
Hello,
try and configure the trunk port as 'spanning-tree port type normal', as 'edge trunk' immediately moves the port to the forwarding state...
02-26-2017 02:38 PM
I know that's what "edge trunk" does, which is why I used it. Since it's plugging into a firewall with a layer-3 interface/sub-interfaces, not another switch, there is no chance of a loop. Also, I don't think FEX supports "type normal."
02-26-2017 04:00 PM
I think I read somewhere that if you leave the native VLAN out of the list of allowed VLANs on the trunk it works properly. Otherwise the native VLAN is actually tagged in the trunk
02-26-2017 07:08 PM
I found the solution to my own problem (well, at least the reason behind it). Somebody else long before me had enabled the global command:
vlan dot1Q tag native
... which tags every VLAN that's part of a trunk, including the native VLAN. Since it expecting an untagged native VLAN on the other side of the connection, it broke communication.
Ah, the fun of troubleshooting something somebody else put in place in a way that you never would have done yourself...
08-05-2023 10:43 PM
Hi M.Glosson,
Thanks for sharing.
It was very useful.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: