# VLAN question - untagged traffic

## flatmodel

I am making my first nervous steps into the area of VLAN's, and I've hit a bit of a problem, and that is what happens to untagged traffic?

/etc/conf.d/net looks like this:-

```
config_lan1="null"

vlans_lan1="0 1 2 3" ; # These are the VLAN tag numbers

config_lan1_0="192.168.200.1/26"

config_lan1_1="192.168.200.65/26"

config_lan1_2="192.168.200.129/26"

config_lan1_3="192.168.200.193/26"
```

So, clearly this is a fairly straightforward instance of each VLAN being assigned to a small subnet of 62 hosts each. The eventual application of this will be to talk to a wireless access point which is capable of assigning traffic on a number of SSID's to a VLAN number. This allows me to handle [wireless] network traffic differently depending upon which VLAN (and therefore SSID) it arrives on.

Without (so-far) wandering into the matter of ingress and egress, my assumption is that traffic tagged with vlan=0 will end-up on lan1.0 and vlan=1 lan1.1 and so-on. Ideally though, I would like interface lan1.0 to receive untagged traffic, and better yet, untagged traffic and traffic tagged with vlan=0.

Or a better idea altogether?

I only need a shove in the right direction.  :Wink: 

----------

## eyoung100

See Section 3.j:

3. Modular Networking

----------

## flatmodel

 *eyoung100 wrote:*   

> See Section 3.j:
> 
> 3. Modular Networking

 

Um, yes, but this is much the same information as can be found in the net.example file supplied with the sys-apps/openrc package. Dear reader, do bear in mind that I don't properly understand what I'm doing yet - I have never had occasion to use VLANs before.

I've come to revise my initial position a bit though, having thought some more about it. I think that what I want to happen is for the first network...

```
config_lan1_0="192.168.200.1/26"
```

to be untagged, whereas the rest are tagged 1, 2, and 3. I find myself asking, does using VLAN 0 implicitly mean "untagged"?

At present, this is what I've got in /etc/conf.d/net...

config_lan1="null"

vlans_lan1="0 1 2 3" ; # These are the VLAN tag numbers

config_lan1_0="192.168.200.1/26"        ; # VLAN=0 

config_lan1_1="192.168.200.65/26"       ; # VLAN=1

config_lan1_2="192.168.200.129/26"      ; # VLAN=2

config_lan1_3="192.168.200.193/26"      ; # VLAN=3

I have set-up dhcpd to listen on all four interfaces (not the null one though) and it seems "deaf" to the pleas of the access point (with which I'm very well acquainted) for an IP address. I really don't know what to do next. I think I can conclude that VLAN=0 does not mean untagged though?

I suppose this all distils into one question, how does one designate a subnet in the above scenario as untagged?

----------

## flatmodel

I think I've solved this problem now. Thanks to those that helped. Many hours of experimentation has yielded the results I sought!  :Very Happy: 

----------

## khayyam

 *flatmodel wrote:*   

> I think I've solved this problem now. Thanks to those that helped. Many hours of experimentation has yielded the results I sought!

 

flatmodel ... you might provide future readers with your findings, as its a question that no doubt others will ask.

I had decided to 'watch this topic' as it was a question I couldn't answer myself, but I don't think the topic provides an understanding of how exactly it works, and that leaves it as an unsolved question.

best ... khay

----------

## flatmodel

[quote="khayyam"] *flatmodel wrote:*   

> I think I've solved this problem now. Thanks to those that helped. Many hours of experimentation has yielded the results I sought!

 

 *Quote:*   

> flatmodel ... you might provide future readers with your findings, as its a question that no doubt others will ask.

 

Reasonable enough. Here we go then:-

The objective was to create two wireless networks, one being a "residents" network which has access to a full range of services such as file & print (Samba), Proxy (squid), media servers, DNS cache, and then a "guest" network which does nothing other than pass-through hosts' requests to the Internet, and all other server-based services are completely invisible. This is provided by a Linux (gentoo) server which sits between all LAN hosts and the outgoing Internet router. I wanted to do this with a single access point using VLANs (a Netgear WG302).

The key to success, as always, is understanding. Fundamentally, it is important to understand that VLAN's are nothing directly to do with TCP/IP. However, from an IP perspective, it is convenient to think of VLANs as being different IP subnets on the same interface. Indeed, the same network hardware, and the same wiring too.

What I sought to do was to have a wireless access point with VLAN capability serve [at least] two IP subnets. Currently, these ends are met by having two simple access points each connected individually to a separate ethernet card, but it's a blunt instrument approach. The Netgear WG302 access point can serve upto eight apparently separate wireless networks on the same physical wiring, and this is achieved by using VLANs. Perhaps it's worth mentioning that a wireless access point doesn't necessarily know anything about IP either, but most have an http web-based interface which requires an IP network. An access point is rather a media bridge from the wired medium to the wireless medium, and it carries Ethernet traffic which might only incidentally be TCP/IP. This is also the case with hubs, switches and so on, they're Ethernet, not necessarily IP. The 802.1q VLAN tag is a way of teasing apart Ethernet data regardless of what else it is carrying, and this becomes useful when working with managed switches and so-on.

The key to it all is the /etc/conf.d/net file. Here's my final version:-

```
config_lan1="192.168.200.1/26"  ; # Untagged

vlans_lan1="2 3 4" ; # These are the VLAN tag numbers

config_lan1_2="192.168.200.65/26"       ; # VLAN=2

config_lan1_3="192.168.200.129/26"      ; # VLAN=3

config_lan1_4="192.168.200.193/26"      ; # VLAN=4
```

The first line is just like any other Ethernet interface, except that I'm using a slightly unusual netmask which divides 192.168.200.x into four networks (subnets) when fully utilised, as in the subsequent lines. The first subnet (first line) creates an untagged Ethernet interface with a single IP address bound to it. This becomes 192.168.200.1 on the network, and "normal" IP traffic will end-up here. I set-up my DHCP server to listen on this device, and to serve-up IP addresses within this subnet, and crucially, to make sure that 192.168.200.1 is the default gateway for hosts on this network.

Now, notice that VLAN's start at 2. This is because the access point only allows one to assign numbers in the range 1 to 4096 as VLANs, and additionally I have designated VLAN=1 to be untagged - i.e. just like "normal" Ethernet traffic. So, my wireless network assigned to VLAN=1 actually strips off the tag entirely at the access point, thus there is no point in worrying about VLAN=1 as such. So, I assign the second wireless network to VLAN=2, and this now corresponds to the subnet 192.168.200.64/26, so the virtual interface assumes the first valid address in this range, 192.168.200.65, and again the DHCP server listens on this interface and serves-up suitable IP addresses for hosts on that network, again crucially, with the default gateway as 192.168.200.65. This last point about default gateway is important because if you want to ping a host from another network, the reply will get lost.

Here's a snippet from the /etc/dhcp/dhcpd.conf file:-

```
subnet 192.168.200.0 netmask 255.255.255.192 { range 192.168.200.2 192.168.200.61;

                                                option routers 192.168.200.1; }

host Experimental_AP { hardware ethernet 00:14:6c:c6:bb:e0; fixed-address 192.168.200.62; }

###############################################################

subnet 192.168.200.64 netmask 255.255.255.192 {range 192.168.200.66 192.168.200.126;

                                                option routers 192.168.200.65; }
```

Notice that the first network (untagged) in the dhcpd.conf file has a "host Experimental_AP" line, this is so that the http configuration interface on the access point has a known and fixed IP address so that it can be adjusted whenever required.

For completeness, the /etc/conf.d/dhcpd file has this line...

```
DHCPD_IFACE="lan0 lan1 lan1.2 lan1.3 lan1.4"
```

Notice that lan0 is the first interface - it's an existing wired network and has nothing to do with this discussion. Various extra information needs to be added to the dhcpd.conf file to define things like DNS services and so-forth, but that's firmly in the realms of IP rather than Ethernet, so not really germane here. Some firewall surgery would no-doubt be required too!

One could control various characteristics of the access point using a Radius server; but one step at a time, eh?   :Laughing: 

That's it really. I'm still dreadfully ignorant, but it might help someone else with ideas in this direction, so it's worth the effort. Since I don't think it likely I'll be killed in the stampede, get in touch directly if you think that I might be able to help further.

A more academic text can be found here: http://en.wikipedia.org/wiki/IEEE_802.1Q

----------

## khayyam

Richard ...

Thank you for the detailed explanation ... I'd asked purely for the sake of understanding, I'm not currently working on anything that requires vlan's but I can certainly see the knowledge coming in useful at some point.

best ... khay

----------

## flatmodel

 *khayyam wrote:*   

> Richard ...
> 
> Thank you for the detailed explanation ... I'd asked purely for the sake of understanding, I'm not currently working on anything that requires vlan's but I can certainly see the knowledge coming in useful at some point.
> 
> best ... khay

 

It's probably inevitable that one will require this sort of technology at some point. I already have two sites that require the scenario that I described, and possibly a third in the next few months. I'm glad to have been able to contribute - it's ages since I wrote any software (excepting trivial scripts), so it's nice to be able to put something into the open source arena that seems to be rather weak, i.e. documentation/explanations.

----------

