OpenWrt Forum Archive

Topic: Mixed tagged untagged packets in VLAN trunk

The content of this topic has been archived on 25 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello,

I would like to set up a native VLAN plus a tagged VLAN on same port. I tried following setup:

insmod switch_core
insmod switch_adm

echo "1t 5t" > /proc/switch/eth0/vlan/10/ports

After that I found out that packets on vlan0 are also tagged on port 1. Is that a bug or a feature ?

An

echo "1*       2       3       4       5t*" > /proc/switch/eth0/vlan/0/ports

yielded in nasty situation that no packets are tagged and after

echo "1t*       2       3       4       5t*" > /proc/switch/eth0/vlan/0/ports
echo "1t        5t" > /proc/switch/eth0/vlan/10/ports

I got all packets tagged again :-(

Is there a method to get VLAN0 packets untagged and VLAN 10 packets tagged on port 1 ?

robocfg does not find any configurable port and seems to be outdated.

Depending on the hardware platform you'll either have an ADM or Robo switch. The new /proc/switch interface will handle either, eliminating (most of) the need for admcfg or robocfg.

The tag/untag is done on a per port basis, not per vlan.

'*' = pvid; if ports are in multiple vlans, untagged packets will be added to this vlan
't' = tagged port; all packets sent out this port will be tagged (default for port 5)
'u' = untagged port; all packets sent out this port will be untagged

bitkocher wrote:

Is there a method to get VLAN0 packets untagged and VLAN 10 packets tagged on port 1 ?

I am doing this with no problem. See the example in this thread where I am trunking vlan 3 (untagged) and vlan 10 (tagged) on the wan port.

mbm wrote:

The tag/untag is done on a per port basis, not per vlan.

Actually, it's per port, per vlan.

- DL

dl wrote:
mbm wrote:

The tag/untag is done on a per port basis, not per vlan.

Actually, it's per port, per vlan.

- DL

Please, don't try to correct me. We're talking about the ADM6996 -- see table 4.3.2 in http://downloads.openwrt.org/people/mbm … pril04.pdf

mbm wrote:

Please, don't try to correct me. We're talking about the ADM6996

My mistake. At least future readers will now understand your unqualified statement applies only to the ADM.

- DL

I just checked the IEEE specs and conformance requires allowing at least one untagged vlan to be configured for tagged ports. Allowing multiples is optional (doesn't make sense anyway?). So either the ADM is not 802.1q conformant or else the chip is not being setup properly. As I said earlier this works fine on a BCM5335. I don't have an old unit with the ADM chip to test, but Infineon does claim 802.1q "support" and a quick google didn't turn up any issues of non-conformance.

- DL

Hmm, so I would expect that

echo "1*       2       3       4       5t*" > /proc/switch/eth0/vlan/0/ports
echo "1t        5t" > /proc/switch/eth0/vlan/10/ports

would:

1. send all packets to vlan 1 w/o tag on port 1
2. send all packets to vlan 10 w tag on port 1

but I experienced a problem: If I issue
echo "1t        5t > /proc/switch/eth0/vlan/10/ports
I would expect that packets to vlan10 would be tagged on port 1 and packets regarding other vlans are handled as before issuing command above, that means if vlan0 was untagged it remains still untagged after issuing that command. A cat /proc/switch/eth0/vlan/0/ports resulted in a unexpected behaviour, packets for vlan0 are also tagged after issuing echo "1t        5t > /proc/switch/eth0/vlan/10/ports. What was my mistake ?

I do not like to change nvram, because thay may kill my Linksys.

bitkocher, have you tried this via admcfg rather than new /proc/switch method? If I get a chance I'll try the new method with the BCM (rather than robocfg) to see if it still works.

Also, you shouldn't need the * after 1 ("1*") although I doubt this is a problem.

ps: I understand why you put the "1*" as this should be the default vlan for untagged packets received on port 1 so is the "proper" config - it's just that my working example on the BCM chip doesn't require this although this may just be sheer luck.

- DL

(Last edited by dl on 4 Apr 2006, 09:16)

Hmm, which package contains "admcfg" ?

admcfg is obsolete.

Use kmod-switch package which contains switch-core, switch-adm, swtich-robo kernel modules.

I tried /proc/switch... with a Linksys54g and got expected results.

insmod switch-core
insmod switch-robo
echo "1t 5t" > /proc/switch/eth0/vlan/10/ports
echo "1* 2 3 4 5t*" > /proc/switch/eth0/vlan/0/ports

made packets to vlan10 tagged and packets to vlan0 untagged. I do not understand, why wrt54gs has a differnt behaviour. Only difference to wrt54gs was module switch-adm, because wrt54gs does not link switch-robo.

mbm wrote:
dl wrote:
mbm wrote:

The tag/untag is done on a per port basis, not per vlan.

Actually, it's per port, per vlan.

- DL

Please, don't try to correct me. We're talking about the ADM6996 -- see table 4.3.2 in http://downloads.openwrt.org/people/mbm … pril04.pdf

I read the specs in the above reference guide of the adm6996.
I think this switch has very limited 802.1q capabilities.

Note that _full_ 802.1q compliance is 12bits for VLAN0-4092 - adm6996 only uses 4bits!
Also the concept of a "native VLAN" (Cisco-speaking) is not implemented,
a port can either be tagged or untagged - and all packets send out of the port
will correspondingly tagged or untagged. The '*' PVID concept of tagging untagged
packets coming into the switch on a "tagged" port is very confusing, because it
implements only one half of the "native VLAN" functionality. Packets going out
on this VLAN/port will be tagged - so this VLAN is not usable at all on this port (IMHO).

So far i only could get the VLAN-stuff working with strictly tagged/untagged ports -
both with ADM and ROBO switches - but this has been working fine with RC4 and
the adm6996.o-module and robocfg - no experience with RC5's b44 due to lack of
documentation.

BTW: 801.1q implementations vary among switches - for example Cisco's cannot tag VLAN0 at all.

freakout wrote:

I read the specs in the above reference guide of the adm6996.
I think this switch has very limited 802.1q capabilities.

Note that _full_ 802.1q compliance is 12bits for VLAN0-4092 - adm6996 only uses 4bits!

I don't think the specs (not in front of me at the moment) require that all 4094 VIDs be supported simultaneously. Even my Procurve switches don't do this, and the robo switch also only uses 4 bits iirc. Note that the ADM has other configuration registers that appear to allow support for tags > 15.

Also the concept of a "native VLAN" (Cisco-speaking) is not implemented,
a port can either be tagged or untagged - and all packets send out of the port
will correspondingly tagged or untagged.

Then why does ADM provide for a PVID? The fact that ADM has a config bit setting a port as either tagged or untagged is irrelevant - the spec call for allowing one untagged vlan on a tagged port. The problem in figuring this out is that the datasheet is so poorly written. For instance, what does "vlan mode select, 0:bypass mode with port-base VLAN (default) versus 1: 802.1Q base VLAN" do? It's not explained anywhere.

The '*' PVID concept of tagging untagged
packets coming into the switch on a "tagged" port is very confusing, because it
implements only one half of the "native VLAN" functionality. Packets going out
on this VLAN/port will be tagged - so this VLAN is not usable at all on this port (IMHO).

Exactly, which is why you'd expect that behind the scenes the chip would output untagged packets for a VID if a (matching) PVID was specified for the port without any further configuration required. To not do this is extremely lame as this is a very common requirement. I've got a dozens of VLAN devices deployed and use this functionality on all of them and they all support it with no problem.

BTW: 801.1q implementations vary among switches - for example Cisco's cannot tag VLAN0 at all.

This is true but many or most of these variances are in the "optional" or "vendor extension" category, not in a core feature requirement.

- DL

(Last edited by dl on 4 Apr 2006, 21:02)

For what it's worth, my buffalo whr-g54s seems to behave the same as bitkocher's wrt54gs.

The discussion might have continued from here.