Problem with VLAN trunking using unmanaged switch

I extended my wi-fi coverage in my house with VLANs. There are two wireless networks: the first is a private and the second is a guest network. The main router and the dump AP connected with trunk link in order to handle the traffic of both networks (VLANs).

It works perfectly, but I have an issue reaching the server. PC can reach server, just like Laptop A. However Laptop B cannot reach it. I assume the problem caused by the unmanaged switch. I know that using unmanaged switch with trunk link is not recommended because of its undefined behaviour, however in my cause it would be essential to use it.

Is there any workaround to solve this problem (e.g. forward packets to main router which will send them to server through switch)?

I don't know any way you can use an unmanaged switch to carry both trunk and individual VLAN traffic. Since the dumb AP is already set up to know about the two VLANs, I would connect the server to a port on the dumb AP, and have that port set up to carry only the private VLAN.

You should not use an unmanaged switch with VLANs.

  1. The behavior of an unmanaged switch is undefined for 802.1q tagged frames. Therefore, some switches may pass them without issue, others may not pass the tags, and still others may choke entirely and cause major network issues. The behavior can vary considerably from one switch brand/model/version to another.

  2. An unmanaged switch will, at best (i.e. assuming all works okay based on the comments above), pass all tagged networks through transparently. In that case, all physical ports will be trunk ports. You will be unable to set the VLAN membership of each individual port, and you won't be able to configure any ports as access ports (i.e. a single untagged network suitable for direct connection to a normal computer or other endpoint that expects untagged frames (i.e. normal ethernet connections for standard devices).

1 Like

try adding a virtual nic on the server with a vlan tag such as nic2.1 (2.1 being tagged for vlan 1). Your server effectively will become multi-homed. If your server is a windows machine this may not be possible depending on the nic driver (Windows itself cannot do 802.11q but some windows drivers support it and can be configured in the device manager). If it's linux/bsd then it is straightforward to create a vlan interface using the IP command.

In this case that would explain why Laptop B cannot reach server. But what about PC and Laptop A? They can reach it without any problem despite we assume all physical ports are trunk ports. They sould not handle tagged frames.

It would be useful to mention when I created VLANs and extended my wi-fi network, I followed @onemarcfifty's video. I applied his solution (mixing tagged and untagged) in order to use unmanaged switch.

Here are my switch configuration on both routers:

Main router:

Dump AP:

If I misunderstood something from the video and did it wrong please feel free to tell me.

It would be a great idea. Unfortunately my Dump AP has no gigabit ports, so it would decrease bandwidth.

because you're mixing up tagged and untagged traffic and you have not specified enough information about your server and clients either about how they can handle tagged and untagged traffic.

You're right. It works like a charm. I switched from mixed taffic to tagged-only trunk link. The switch pass tagged frames transparently and now every physical ports are trunk ports. Consequently the server could not reach the internet so I created a sub-interface with an appropriate VLAN ID.

Note 1: I had to reboot my main router after I created a sub-interface on server. Without reboot, the server could not reach the internet despite it had access to LAN network (it could ping local hosts).

Note 2: If you create a static sub-interface, you might get DNS errors as in my case. I had to replace it with a DHCP capable sub-interface.

Thank you for your advice :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.