cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3324
Views
1
Helpful
5
Replies

Native VLAN not working as expected

m.glosson
Level 1
Level 1

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

5 Replies 5

Hello,

try and configure the trunk port as 'spanning-tree port type normal', as 'edge trunk' immediately moves the port to the forwarding state...

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

lpassmore
Level 1
Level 1

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

m.glosson
Level 1
Level 1

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

Hi M.Glosson,

Thanks for sharing.

It was very useful.

 

Review Cisco Networking products for a $25 gift card