Output untagged traffic over trunk link

Installing and Using OpenWrt Network and Wireless Configuration
1

I run multiple VLANs on my user's switch. I used to tag everything over the trunk link and it works fine. Today I tried to output 1 of them as untagged. Let's take a look at the configuration. I shall try to simplify my real one.

Topology: Switch 1 -> Switch 2

First, here is what it used to work.

Switch 1 -- /etc/config/network

config interface 'management_vlan'
	option	ifname		'eth0.1'
	option	proto		static
	option	ipaddr		'192.168.1.1'
	option	netmask		'255.255.255.0'
	option	ip6assign	60

config interface 'public_vlan'
	option	ifname		'eth0.2'
	option	proto		static
	option	ipaddr		'192.168.2.1'
	option	netmask		'255.255.255.0'
	option	ip6assign	60

config interface 'private_vlan'
	option	ifname		'eth0.3'
	option	proto		static
	option	ipaddr		'192.168.3.1'
	option	netmask		'255.255.255.0'
	option	ip6assign	60

# Management VLAN
config switch_vlan
	option	device	'switch0'
	option	vlan	1
	option	ports	'4t 6t'

# Public VLAN
config switch_vlan
	option	device	'switch0'
	option	vlan	2
	option	ports	'4t 6t'

# Private VLAN
config switch_vlan
	option	device	'switch0'
	option	vlan	3
	option	ports	'4t 6t'

Switch 2 -- /etc/config/network

config interface 'management_vlan'
	option	ifname	'eth1.1'
	option	proto	dhcp				# Only this interface has an IP address. Users from other VLANs cannot connect to this device.

config interface 'public_vlan'
	option	type	bridge
	option	ifname	'eth1.2'
	option	proto	none

config interface 'private_vlan'
	option	type	bridge
	option	ifname	'eth1.3 eth0'
	option	proto	none

config switch
	option	name		'switch0'
	option	reset		1
	option	enable_vlan	0	# VLAN is disabled, all switch ports facing 'eth0' receive and send untagged traffic.

# 'eth0' is bridged to 'eth1.3'. VLAN tagging/untagging is done on 'eth1'.
# 'eth0' VLAN does not matter, hence the switch VLAN can be turned off.
# All 4 LAN ports which connect to 'eth0' will be bridged to 'eth1.3' anyway.

The Switch 2 is not placed at my home, the user may replace it with any dumb switch in the future, and everything will stop working. I want to output untagged traffic on the private_vlan, so if he ever does that, he is still left with his own VLAN/subnet to use.

Here is how I did, and it made everything on Switch 2 stop working:

Switch 1 -- /etc/config/network

# Private VLAN
config switch_vlan
	option	device	'switch0'
	option	vlan	3
	option	ports	'4 6t'		# His VLAN traffic is now untagged.

Switch 2 -- /etc/config/network

config interface 'private_vlan'
	option	type	bridge
	option	ifname	'eth1 eth0'	# This line is the problem.
	option	proto	none

I've wasted 4 hours because of this. Why bridging eth1 and eth0 made everything stop working? I can even create an interface facing untagged traffic and it works with no problem, like this:

config interface 'untagged_vlan'
	option	ifname	'eth1'	# This works and correctly joins the corresponding subnet. 'eth1.0' does not.
	option	proto	dhcp

config interface 'public_vlan'
	option	type	bridge
	option	ifname	'eth1.2'	# This also works when bridging with `eth0`.
	option	proto	none
2

Tagged and untagged on the same cable is in general a bad idea and may not work with all equipment. It would be better that if the guy at the other end of the cable wants to go untagged, you reconfigure and send him one network conventionally.

If you still want to try, the way to do this would be to use the internal switch in VLAN mode. All the CPU traffic remains tagged and can use one eth port. Set up an external port with one VLAN untagged and the others tagged. Also set a pvid on that port. That option tells the switch to apply a tag to incoming untagged packets so then they go through the switch fabric and out to the CPU to the proper VLAN..

3

This wireless router has 2 physical interfaces, one (eth0) facing the 4-port switch, and the other (eth1) facing the WAN port. I want to make use of all ports, that why I do bridging. It is strange because this works:

config interface 'untagged_vlan'
	option	ifname	'eth1'	# This works and correctly joins the corresponding subnet. 'eth1.0' does not.
	option	proto	dhcp

And this works:

config interface 'private_vlan'
	option	type	bridge
	option	ifname	'eth1.3 eth0'
	option	proto	none

But the combination of the 2 above does not work:

config interface 'private_vlan'
	option	type	bridge
	option	ifname	'eth1 eth0'	# This line is the problem.
	option	proto	none

If there is no other way, I'll try what you suggest, to use 4 ports of the switch only, and output both tagged and untagged traffic to one of the switch ports.

4

In my opinion, there is no problem trunking an untagged network alongside tagged network(s), as long as you can guarantee that there is a smart/managed switch on the other side of the trunk, or end point devices that are either vlan aware or are known to ignore the tagged network(s) if using the untagged interface.

On the other hand, if there is any risk that a dumb/unmanaged switch may be connected to the trunk cable, this may cause unpredictable issues since the behavior of VLANs and tagged networks on unmanaged switches is not defined.

5

Tested on 2 cheap TP-Link router with original firmware and it works fine with a trunk link, as long as there is an untagged VLANs.

Back to the topic. Should I report this as a bug?

6

By further investigation, it seems the problem is very complex. My simplified topology does not show the it clearly. Actually, I have 3 switches connected together. Each with different style of WAN/LAN configuration. When I have time, I'll try to draw and show the problem.

Now even the VLAN features (without bridging) of the switch does not work if there is untagged traffic on the trunk link. :frowning_face: I'll live with tagged for a while, until I have time to discuss more.

7

The only time you should consider tagged and untagged on the same cable is when you have to connect to someone else's network, and they are using that bad practice.

1 Like
8

@mk24 - do you have any links to pages that describe best practices with vlan trunking and the reasoning behind the recommendations?

Although this has since been addressed, it wasn’t long ago (1-2 years) that unifi aps (running the unifi firmware) required the management vlan to be untagged but could set up ssids against untagged and/or tagged VLANs. As a result, my home network is still setup with that in mind. Yes, it is bad practice in general to have the management network untagged (at least assuming you can’t control all physical ports), but I’ve never really known any reasons that an untagged+tagged trunk would be ill advised. And if it is such a bad idea, why does the capability exist to implement the trunk in that way (vs forcing all tagged if using a trunk)?

9

  • The reason is that things get hairy depending on device vendor

  • Such setups are a hacky way to co-exist "universally" and the said vendor likely has higher layer protections to offset the exposure in this topology. The reason it is i'll advised is that any teency misconfiguration, incompatibility or cable plugged in in the wrong place ( on any L2 device )... either breaks your network or renders it exposed ( again... requires multiple upper layer protections and controls ).

1 Like
10

ipq40xx or a different SoC?

(ipq40xx requires some special care in VLAN config)