Native vlan mismatch

[grapevine]

I have two switches A and B connected via a trunk. Switch A has no native vlan configured and switch B has native vlan 16; so the second switch b is nownot reachable
Can I configure native vlan on switch A and then when switch B is reachable, remove the native vlan and then remove the native vlan on switch A will the switch B become reachable
Our goal is we need to remove native vlan

[Joseph W. Doherty]

Switch B should (by default, I believe) accept untagged frames as VLAN 16 and VLAN 16 tagged frames, but it should transmit (by default, I believe) it's VLAN 16 frames untagged, which will be accepted by switch A as its native VLAN (VLAN 1?).  So, there's a VLAN mismatch.

I.e.

if switch A sends to switch B an untagged frame, it should be returned untagged.

if switch A sends to switch B a VLAN 16 tagged frame, it should be returned untagged.

What VLAN, on switch A, have you used to try to communicate with switch B?

If switch B is L2, what VLAN is its management IP assigned to?

If you change switch A's native VLAN, also to VLAN 16, the two switches will be on the same VLAN, but if switch B L2 management isn't on VLAN 16, it might still be unreachable.

[grapevine]

Switch B's management IP is on Vlan 16

[Joseph W. Doherty]

Okay then, if you change switch A native to use VLAN 16, and you use a VLAN 16 source IP from switch A, believe you'll be able to communicate with switch, as you propose.

However, when you change switch B's native, that will break communication with switch A, as you've mismatched native VLANs again.  However, you should be able to change switch A, again, to rematch native VLANs, and then should be good.

[Jens Albrecht]

Hello @grapevine,

the short answer: Your initial idea does work.

In general, it is a good idea to avoid the use of the native vlan.

Looking at this step by step from the current setup:

• Switch A has no native vlan, Switch B uses vlan 16 as native --> no connectivity in vlan 16, native vlan mismatch
• Configure Switch A to use vlan 16 as native as well --> connectivity restored, both use vlan 16 as native
• Remove the native vlan on Switch B --> no connectivity in vlan 16, native vlan mismatch
• Remove the native vlan on Switch A --> connectivity restored, both tag traffic for vlan 16

So things work as you expected and you can go ahead and remove the native vlan.

HTH!

[Elliot Dierksen]

I'll add a point of clarification. There is ALWAYS a native/untagged VLAN. Whether you choose to use it or not is a different issue, but there is no such thing is removing a native VLAN. In Cisco switches, the default is VLAN 1 as it is in all other switching platforms I have seen. The terminology varies by manufacturer, but you can configure the native/untagged VLAN to be something other than 1.

[Joseph W. Doherty]

". . . ALWAYS a native/untagged VLAN."?

What if config command "vlan dot1q tag native" is used?  Of course, I understand control traffic continues to be untagged, but that, I believe, is true too if you change the native VLAN to something other than VLAN 1.  Such traffic, though, isn't really part of any VLAN.

[Elliot Dierksen]

I hadn't thought of the tagging the native VLAN. I guess my point was more that the possibility exists for untagged frames, and two switches disagreeing on that will cause problems. You can even see variations in this within the same manufacturer. I experienced this with the 40G MLOM modules in a UCS. It tags everything. When I had the server connected to a Nexus switch, it dealt with that silently without a problem. A 3850 would not accept the tagged frames for the native VLAN, so I had to make the port a trunk the only allowed that single VLAN.

[Joseph W. Doherty]

You can even see variations in this within the same manufacturer. I experienced this with the 40G MLOM modules in a UCS. It tags everything.

In my experience too, other vendors might not support untagged frames on a .1q link.  (Not positive, but that might actually be expected with .1q.  The native VLAN concept might date back to ISL, and perhaps Cisco just put it into their .1q implementation.)

[Elliot Dierksen]

ISL, there is a way back machine entry! I could certainly be mistaken, but my recollection of ISL was that all VLAN's were tagged. I thought untagged was strictly an 802.1q thing, and there were certainly some challenges with that when it first came out. It seems everyone has settled on a common understanding for how it works nows.

[Joseph W. Doherty]

ISL, there is a way back machine entry!

Laugh, indeed!

. . . my recollection of ISL was that all VLAN's were tagged.

You may be correct!  Just tried to verify which it was.  Didn't find any official documentation, but that appears to be what others believe too.

Honestly, I don't recall specifically which it was, both for how long ago it was, and possibly a non issue for my usage cases.  The only thing I really recall about untagged traffic, is, for better security, don't allow normal traffic on that VLAN as it's used by Cisco control traffic.)

The only thing I recall concerning ISL (way back when I was using it) vs. .1q, for a while Cisco only provided its ISL, while other vendors supported .1q.  Which sort of made trunking VLANs with other vendor equipment just a mite difficult.  (Similar story with Cisco only providing CDP while other vendors provided LLDP.  Of course, if you only used Cisco equipment, these were non issues.  [Also of course, vendors attempting to lock you into being only able to use their equipment, isn't unique to Cisco, or any one hardware provider/industry.])