Using different native VLANs on different ports of a switch configured as trunks

[Nikolaos Milas]

Hello,

The short question:

Is it possible to configure two trunk ports on a Catalyst switch  to use different native VLANs ? I expected the answer to be yes, but in practice it did not work. Why?

The long story:

We have a 3825 router with an Ethernet interface (among others) which is linked to a Catalyst switch over a switch port (G0/1) in trunk mode: native vlan for this trunk is the default (1), and it is also used as an administrative VLAN.

Multiple VLANs (encapsulation dot1q) are 'moving' through this trunk; one of them is VLAN 7.

Is it possible to configure another port of the switch (trunk as well) to use VLAN 7 as native, rather than VLAN 1?

To make it more clear, we would want to configure a particular port of this switch, say int Fa0/20, as a trunk and use VLAN 7 as a native VLAN for it; the native VLAN of the trunk connection to the router would be different from the native VLAN of the trunk defined at int Fa0/20.

The goal is to be able to access from the router-connected LANs (i.e. from the subnets thereof) the devices with addresses in the subnet used at VLAN 7 (which are connected through the Fa0/20 port of the switch) for administration purposes, while at the same time be able to convey other VLANs over this trunk.

I tried this configuration, the switch accepted it, but it did not work: I don't have direct access to the devices on VLAN 7 from router LANs (or from the router itself).
 

Currently the port Fa0/20 is configured as an access port on VLAN 7. This allows access of the associated devices, but does not allow us to 'move' other VLANs through the port.

The problem is that the switch administration VLAN (1) is different than the VLAN used for administration of the network devices connected to port Fa0/20 (wireless devices). In short, the switch configuration (which does not work!) for the ports involved is:

interface GigabitEthernet0/1
 description *** Connection to Router ***
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/20
 description *** WiFi Bridge ***
 speed 100
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 7
 switchport mode trunk

Can you please provide some guidance for this? Why this configuration does not work?

Please help. Thanks in advance for any advice.

Regards,
Nick

[Mike Schultz]

I'm not sure I completely understand your intent, but I'm also not sure you completely understand the function of the native VLAN. You perhaps do. But just in case:

The native VLAN function on a dot1q trunk means that any frame coming from the native vlan and being switched into the dot1q port will not have any dot1q tagging, but will be sent as a traditional ethernet frame with no VLAN tagging. Conversely, any frame received on a dot1q port that has no dot1q tagging (traditional ethernet with no vlan set) will be viewed as part of the VLAN set in the native VLAN. That's all it does. Nothing more.

[Nikolaos Milas]

Thank you for your replies.

The connection diagram (with associated configs) is as follows:

See also this diagram:

When the switch port Fa0/20 config is:

interface FastEthernet0/20
 speed 100
 switchport access vlan 7

then I have connectivity from R1 to all devices.

When the switch port Fa0/20 config is: 

interface FastEthernet0/20
 speed 100
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 7
 switchport mode trunk

then I lose connectivity from R1 to all devices.

I always have successful connectivity from R2 to all devices.

Can you please see what may be going wrong with the above config?

Thanks again,
Nick

[Mike Schultz]

Can you provide the config of G0/1 on the switch?

[Nikolaos Milas]

Of course:

interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk

Also, I don't know if it may be of interest, but I add:

interface VLAN1
 ip address 195.251.xxx.xxx 255.255.255.252
 no ip directed-broadcast
 no ip route-cache

[Jon Marshall]

So you have a trunk running over the wireless ?

If so the wireless device that the switch connects to must also have that port configured as a trunk.

Did you set the same native vlan on the trunk link on that device ?

Jon

[Nikolaos Milas]

The wireless devices have been already configured to support trunk traffic, as described here:

http://community.ubnt.com/t5/airOS-Software-Configuration/VLANs-and-Nanostation-M5/td-p/476513

According to this article, no VLAN should be set on the devices; indeed on the R2 end, no native/admin VLAN has been set on the wireless device (10.201.2.5) and still we do have connectivity (on the R2 end) over native LAN 7.

Nick

[Bilal Nawaz]

Nick, if you want the routers to be able to talk to each other they MUST be on the same VLAN. Without a routed intermediary your setup with different VLANs will not work.

if r1 sub-if is native for VLAN one, tagged or not tagged, the other side must also be in VLAN one.

Unless you have r1's interface with native of one, the switch can have native of vlan 7 on gi0/1, and also native vlan 7 on fa0/20 towards r2, with r2 having native vlan of 7 then I could see it working.

My point is from the switch perspective they must be in the same Vlan, tagged or untagged 

[Jon Marshall · Accepted solution]

Hi Bilal

This is one of those threads where I am going to end up kicking myself but I am not seeing it :-)

On R1 the frames are tagged for vlan 7. They get to the switch and if fa0/20 is in an access port in vlan 7 they are sent untagged on that link and you can get to all the wireless devices.

On R2 the frames are sent untagged in vlan 7 and all the wireless devices are also accessible.

I'm not sure how that works from R2 because it is a trunk link and Nick says nothing was setup on the wireless devices to make vlan 7 the native vlan but still it works.

But if the switch connection to the wireless device is changed to a trunk link with vlan 7 as the native vlan it doesn't work.

But changing vlan 7 to be the native vlan means those frames are untagged which is equivalent to having fa0/20 as an access port in vlan 7.

I have tested this in a lab to make sure I wasn't going crazy. I had -

R1 -> trunk (native 10) -> sw1 -> trunk (native 11) -> sw2 -> trunk native 11-> R2

R1 had a subinterface in vlan 11 and those frames were being tagged.

R2 had a subinterface in vlan 11 and it was the native vlan ie. untagged.

The connectivity between the interfaces was fine, I could ping etc. which is what I would expect because sw1 simply receives tagged frames in vlan 11 from R1 and sends them untagged to sw2 and then R2.

Which I think is what Nick was expecting to happen.

As I say I'm not sure how the wireless devices know vlan 7 is meant to be untagged but that's a different question.

So basically what am I missing because I know you are seeing something I'm not which has happened before in posts we've been involved with :-)

Jon

[Bilal Nawaz]

Oh well maybe it's me not interpreting correctly, which has happened before :)

now that I have seen the diagram and configs again, of both R1 and R2 in my view what needs to happen is have R1 and switch Tagging vlan 7, and the switch to R2 untagging i.e native vlan 7.

if we do what I suggested earlier which was what I thought Nick was trying to do, we'd lose mgmt access to the switch :)

Doh! That's what Nick tried right?!

[Jon Marshall]

Doh! That's what Nick tried right?!

I'm not sure exactly what's been tried to be honest.

I've got a feeling this is something to do with the wireless devices but I'm not sure what to be honest. The fact that you can send untagged frames from R2 to the wireless device and it just knows these frames are meant to be untagged in that vlan without telling it is confusing me a bit.

I'm struggling to work out why this isn't working which is why I was relying on you to point out where I was going wrong :-)

Jon

[Bilal Nawaz]

At least we're on the same page now ;) I also think it's the wireless devices. The link that Nick shared suggests it is possible...

mgmt of the wireless devices is in the Untagged VLAN, that's all I got from the page.

and 'enable vlan' on the wireless device

[Nikolaos Milas]

Thank you both for your time and effort to resolve this issue (yes, you have understood it correctly!). You have been most helpful.

I think I have found useful links regarding wifi device settings in similar situations, and we will test settings along those lines:

http://blog.gowifi.co.nz/2014/01/multiple-networks-over-wireless-link.html

https://community.ubnt.com/t5/airOS-Software-Configuration/How-to-configure-Nanostation-Loco-M5-Link-VLANS-TAG-TRUNK/td-p/923380

So, according to your advice, we are now going to experiment with the wireless devices and I will let you know of the outcome soon.

[Nikolaos Milas]

It worked!

Now both VLANs (7 and 8) between R1 and R2 are working.

As you can see, no native VLANs need to be defined.

Here are the working configs:

Switch (note that this is an old WS-C3524-PWR-XL with IOS Version 12.0(5)WC13):

interface FastEthernet0/20
 speed 100
 switchport trunk encapsulation dot1q
 switchport mode trunk

R2:

interface GigabitEthernet0/1.7
 encapsulation dot1Q 7
 ip address 10.201.2.6 255.255.255.0
 ip nat inside
 no ip virtual-reassembly
 ip policy route-map udp-df0
!
interface GigabitEthernet0/1.8
 encapsulation dot1Q 8
 ip address 172.16.1.18 255.255.255.252
 ip flow ingress
 ipv6 address 2001:648:2011:101::2/64
 ipv6 enable

Wireless devices (UBnt PowerBridge M5) [Network Tab]:

Thank you all for your invaluable help!!

All the best,
Nick

[Nikolaos Milas]

I came across the following info: "If you use 802.1Q trunks, you must ensure that you choose a common native VLAN for each port in the trunk. Failure to do this causes Cisco switches to partially shut down the trunk port because having mismatched native VLANs can result in spanning-tree loops. Native VLAN mismatches are detected via spanning tree and Cisco Discovery Protocol (CDP), not via DTP messages. If spanning tree detects a native VLAN mismatch, spanning tree blocks local native VLAN traffic and the remote switch native VLAN traffic on the trunk; however, the trunk still remains up for other VLANs."

Ref.: https://www.informit.com/library/content.aspx?b=CCNP_Studies_Switching&seqNum=25

Could this have been the source of the problems we faced when using a different native VLAN on a particular trunk switch port?