I must be googling the wrong key words because I'm having trouble finding the correct information.

Say I have 2 physical ports. I configure VLAN10 on one of them (using vconfig). I also assign an IP address to the virtual VLAN10 interface. Have I now created a tagged port?

What are the rules of the game here:

- Is there a VLAN table?
- How do I enable ingress filtering?
- How do I configure that the 2nd physical port is an untagged (access) port for VLAN10? Where do I, for instance, set the PVID?
- How do I configure a trunk port?

Many thanks for pointing my head in the correct direction

Linux will support tagged and untagged interfaces. The eth0 interface is untagged. All vconfig interfaces (eth0.n) are tagged. Alias interfaces (eth0:n) are untagged.

1 members found this post helpful.

Thank you nini09. How do I tag packets from an untagged interface? Say a tagged interface eth0.10 is connected to a VLAN-capable switch. On this switch there are a number of hosts in VLAN 10. A second network card has a simple plain untagged interface. How do I tag its packets so that they can traverse the trunk (and reach the hosts in VLAN10 on the switch)?

You can configure two routes between eth0.10 and second network interfaces. The TCP/IP stack will take care of tagged and untagged packet between two interfaces.

You don't tag untagged frames. You can set the switch's "native vlan" which means the vlan that the switch places untagged packets. If you set the native vlan to 10 then you will have what you describe, but then what's the point of using vlans? Vlans provide Ethernet (Layer2) traffic segregation. If you don't want this traffic split why use it?

If what you want is to have say three vlan 10, 20 and 30 then have any untagged traffic also assigned to 10 then setting the native vlan is what you need. It may be called default vlan or some other name depending on maufacturer.

If you want to pass traffic between vlans you either need to bridge between them externally, (but again if you do this, why bother in the first place?) or you route between the two, which is more usual. If the router is integral to the switch you have a L3 switch, if the router is external you have, erm .. well, a router and a switch.

2 members found this post helpful.

FYI. The January 2011 edition of Linux Journal magazine had a good article about vlans.
http://www.linuxjournal.com/article/10821

1 members found this post helpful.

I think we aren't on the same page. I was talking about a trunk (tagged link) from a Linux 'router' to a VLAN capable L2 switch. Say the interface used for this is eth0 on the linux router. I'd create the VLANs that need to be trunked on eth0 (so eth0.10, eth0.20 and eth0.30 for instance).
I was then thinking, say I also have an eth1 interface. And I connect a "dumb" unmanaged switch to that. How do I tag the frames with a VLAN id for hosts connected to that switch IF the frames need to travel over a trunk.

The main thing that is (was?) _not_ clear to me is:

1) How does Linux know when to keep the VLAN ID tag intact when frames are travelling over the trunk via eth0. After all, the receiving device, a VLAN switch, needs the tag to decide what to do with the frame.
2) How does it know when to untag frames going to a VLAN unware hosts connected to eth1

In short, how do I tell Linux when it should strip tags eggressing an interface and when it should retain the tag.

Unless I'm even more confused nini09 answered this:

So I understood that Linux does this automatically. And if I want to stop it from doing this I need to set up some firewall rules. What I gather is that I cannot created a tagged interface and connect a device to it that is VLAN unware. Is this assumption correct?

Yes, I understand this. Inter-VLAN routing. I don't really need to route between my VLANs though. I simply need a tagged interface eth0, (because frames are heading to a VLAN switch) and an untagged interface (eth1) in VLAN 10 (because I have a bunch of VLAN unware hosts connected to that interface).

I'll summarize more clearly:

I need 2 interfaces:

1) A tagged interface in VLANs 10,20 and 30 (eth0). This interface is connected to a L2 VLAN switch.
2) An untagged interface (eth1) connected to a dumb L2 switch. Hosts should belong to VLAN 10.

Additional "demands":

- The tagged inferface must NOT accept untagged frames nor may it accept frames with a tag different from 10,20 or 30
- The untagged interface must NOT accept tagged frames (ingress) as the hosts connected to it are VLAN unaware. If it does received tagged frames it must drop them because then someone is trying nasty stuff.

The above is commonly referred to as ingress filtering. How is this configured on Linux? The first part of my post was referring to tagging the frames and egress filtering.

@jschiwal. thank you I'll give it a read.

IMO the dumb switch will have to be connected to an interface on the native vlan.

OK. VLAN tagging is a Layer2 mechanism for separating traffic at layer two.
If you Linux box is routing then layer two terminates at the NICs, you have two separate Layer two processes which happen to be ethernet, but one side could be token-ring or X.25, whatever.

When you generate an IP packet that gets routed via eth0.10 the Linux box sees that the egress interface is ethernet so builds an ethernet frame around the packet, it also sees that the egress interface is tagged and therefore adds the 802.1q tag to the frame and transmits it. The switch looks at the tag when it is received and internally assigns it to whichever vlan the tag indicates.

If a packet is due to be routed out of eth0 rather than eth0.10 etc the Linux box encapsulates the IP packet in an ethernet frame but does not add a tag.

When this untagged packet hits the switch it will be placed into whichever vlan the administrator has configured as native (or default or whatever)

If you send a packet to eth0.10 that is destined to be IP routed out of eth1 the frame as received by eth0.10 is removed and discarded. Once the packet is routed towards eth1 the linux box must then create a new ethernet frame that is consistent with the physical network in question. The tags do not pass the router. None of the L2 frame passes the router. Because eth1 is eth1 all frames sent from it will by definition be untagged, its an untagged interface.


So a vlan unaware host in a member port of a vlan'd switch sends an untagged frame. The switch realising that the frame must be sent via a trunk tags the frame before sending it so that the linux box at the end knows which interface the frame is destined for. The linux box on reception of the frame, de-encapsulates the IP packet from the frame and hands it to the interface indicated by the tag. The frame and tag information have now done their job and are discarded. If the packet gets routed to eth1 the Linux box encapsulates it into a new ethernet frame and transmits it.

You need to remember that a router is a layer 3 device so is a Layer2 boundary.

In the opposite direction a host on the dumb switch encaps IP into ethernet, Linux received and de-encaps the packet and routes it. If the packet is routed to eth0 the packet is encapsulated in a NEW ethernet frame with no tag and sent. The switch places the untagged packet into whichever vlan has been assigned as native.

If the packet gets routed to eth0.10 then it is encapsulated in a NEW ethernet frame and is tagged as 10. The switch on receiving the frame assigns it to the relevant vlan and REMOVES THE TAG. If the frame is destined for a host on a vlan member port the the now untagged frame is sent to the vlan member. If the frame is destined for another trunk it is RETAGGED and sent onto the new trunk. Tags only ever appear on trunk links, never member ports.


No problem here.

A dumb switch does not have VLANs so you can't have hosts assigned to one. Vlans are a L2 mechanism and your Linux router is a L2 boundary, whatever VLAN scheme you use on one side of it is meaningless on the other. Anything connected to a dumb switch on eth1 is just a host, the concept ov VLAN's cannot apply.

The only tags the Linux box will send is what you have configured so this should not be an issue. If you don't want to allow untagged frames you cannot use eth0 only eth0.10 etc. Easiest way to kill these frames is to assign your native vlan as an unused one say 999. If security is a concern I would also assign unused ports to this vlan as well and shut it down. These are Cisco's recommendations BTW.

Someone will have to check me on this. A Cisco router will not accept a tagged frame on an untagged interface, I think this behaviour is expected by the RFC so should be the same on Linux but you need to check it.

As with everything Cisco, it depends. That was my favorite answer when I was in IT: It Depends. Anyway here is an excerpt that I think applies from a doc for a 3750 running IOS 12.


A trunk port configured with IEEE 802.1Q tagging can receive both tagged and untagged traffic. By default, the switch forwards untagged traffic in the native VLAN configured for the port. The native VLAN is VLAN 1 by default.

Hi Pete,

I'll have to reread the top portion of your post to fully follow, however, I think we are still not on the same page).


I agree a dumb switch does not have VLANs (the switch is VLAN unaware). But if eth1 on the linux box is an untagged port in, for instance VLAN 10, a switch connected to eth1 with 5 hosts connected to it will simply have 5 hosts in VLAN 10. I hope you agree on this?


Well, that does sound logical but what about tagged frames received by the eth0 interface from a VLAN aware switch. Say that someone forges frames with ID 35. The linux eth0 interface should drop these frames as it does not have an eth0.35 VLAN interface. Does it do this by default? On a switch with ingress filtering enabled (so not talking about linux) a (tagged) port will discard frames tagged for VLANs with an ID for which this port is not a member. I want that behaviour from the Linux box too.

This is the biggest thing we are not on the same page with. I do not want to allow untagged frames on the trunk port, that is correct. Some switches simply allow you to discard untagged frames on certain ports, and some, as you say, will require you to create a VLAN with no ports in it, and set that VLAN as the native VLAN.

However, I do want to use eth1 (so not eth0) as an untagged port in VLAN 10 (or 20 or 30 for that matter).

How do I tell Linux to accept untagged frames only on eth1, and tag them with an VLAN ID of my choosing if they need to travel over the trunk? Moreover, how do I tell Linux NOT to accept tagged frames on eth1. I have a laptop here that can make virtual interface and make up tags at will. So ingress filtering on eth1 has to be set to enabled in order to prevent this laptop from tagging its frames and reach VLANs it is not supposed to reach.

Mm no, sorry. If a dumb switch is connected to an untagged interface and has 5 untagged hosts on it you can't say that any of those hosts are in VLAN10 because VLAN's are a non-concept on the network device you are working on.


My understanding is that yes the 802.1q standard requires that the Linux box ignore these packets as it has no interface configured with which to handle them. They should be discarded.

OK I may be confused with what you are trying to do here. The way I read it is this -

Host B C and D are in member ports, they are untagged but all traffic is implicitly switched into the correct VLAN
eth0 is a tagged port or "trunk". All traffic is explicitly marked with the vlan to which it belongs.

eth1 is untagged and is connected to a VLAN unaware switch. Host A cannot be said to be in any vlan because on that side of the server VLANS do not exist as a concept.

The point I'm trying to get to which I believe is where the confusion is arising is this -

IP packets from HostA to HostB are de-encapsulated from Ethernet at the eth1 interfaces. As this has no tagging configured it SHOULD discard all tagged frames received, although you should verify this.

The packet is then routed. As the packet is exiting eth0.10, as it must to reach its IP destination, the frame the linux box CREATES to transmit the packet out of physical port eth0 is tagged as 10. The vlan switch strips the tag on reception (likely using some king of internal marking to maintain vlan separation). As the switch knows that HostBs MAC address is on a member port it transmits the frame to HostB untagged.

I think the key point of confusion here is that ethernet frames do not go through the router. The ethernet frame that eth1 receives is discarded, the ethernet frame that eth0 transmits is a newly created one and is marked based on the vlan interface that the ip router chooses as its egress port.

1 members found this post helpful.

Any untagged packets are placed on the default VLAN They are not discarded. If vlan 10 is configured as the default vlan, they will then be switched to any port configured for vlan 10.

To muddy the waters further, a trunk also has a native vlan.

Clause 9 of the 1998 802.1Q standard defines the encapsulation protocol used to multiplex VLANs over a single link, by adding VLAN tags. However, it is possible to send frames either tagged or untagged, so to help explain which frames will be sent with or without tags, some vendors (most notably Cisco) use the concepts of a) trunk ports and b) the native VLAN for that trunk.

The concept of a trunk port is that once a port is designated as a trunk port, it will forward and receive tagged frames.

Frames belonging to the native VLAN do NOT carry VLAN tags when sent over the trunk. Conversely, if an untagged frame is received on a trunk port, the frame is associated with the Native VLAN for this port.

For example, if an 802.1Q port has VLANs 2, 3 and 4 assigned to it with VLAN 2 being the Native VLAN, frames on VLAN 2 that egress (exit) the aforementioned port are not given an 802.1Q header (i.e. they are plain Ethernet frames). Frames which ingress (enter) this port and have no 802.1Q header are put into VLAN 2. Behaviour of traffic relating to VLANs 3 & 4 is as to be expected - frames arriving for VLANs 3 & 4 are expected to be carrying tags that identify them so, and frames leaving the port for VLANs 3 & 4 will carry their respective VLAN tag.

Note that in this case, frames received on the port and tagged with VLAN ID 2 shall still be assigned to VLAN 2, but since the VLAN configuration shall be symmetric between emitting and receiving bridges, the distant bridge may not process the returning frames : it shall expect a tagged VLAN 2 frame, but will receive only untagged frames for it, then either discard them or distribute them in the wrong VLAN (the one defined as the "untagged" one on his side).

Not all vendors use the concept of trunk ports and native VLANs. Annex D to the 1998 802.1Q standard uses the concept of trunk links, but the current (IEEE Std 802.1D- 2004) standard does not use the terms trunk or native. Some use the term "Qtrunk" to avoid confusion with 802.3ad "link aggregation" that is often named a trunk as well.

The default VLAN and the native VLAN are the same thing. Or at least they are the same thing on Cisco switches. And HP switches. And 3Com switches. And Nortel Switches. In fact on any switch I've ever configured.

Not really, according to Cisco. The default vlan applies to switch access ports that aren't assigned to a vlan.

By default, there is only a single VLAN for all ports. This VLAN is called default. You cannot rename or delete VLAN 1.Do not use VLAN 1 for management. All ports in Catalyst switches default to VLAN 1, and any devices that connect to nonconfigured ports are in VLAN 1. The use of VLAN 1 for management can cause potential issues for the management of switches,


The native vlan applies to trunk ports not access ports.

If the port is set up as a trunk, which is a port that can carry more than one VLAN, the switchport trunk native vlan command can be useful. The command is useful if the native VLAN of the interface has been changed or needs to be changed from its defaults. The native VLAN is the VLAN that is used if the interface is to become a Layer 2 interface. If you do not explicitly define a native VLAN, VLAN 1 becomes the native VLAN by default. Be aware that an IEEE 802.1Q header is not added when data are sent on the native VLAN. Ensure that the trunk ports on both of the connected devices have the same native VLAN. A mismatch in native VLANs can cause inter-VLAN routing issues, among other problems.

http://goo.gl/Umvjs
http://goo.gl/vkEVv