Question about Balance 20 behavior given VLAN settings

Product Discussion Peplink Balance
#1

I’m struggling with getting a VLAN setup to work between my Peplink Balance 20 router and my VLAN-aware switch and VLAN-aware WiFi access points. To help me understand what expectations I should have, and hence guide me towards correct settings on the switch and WAPs, I think I need answers to some basic questions. I’m hoping folks here can give me some definitive and reliable answers. :slight_smile:

In the Balance 20 Web Admin portal, if I go to Network > LAN > Network Settings, there is a list of defined LANs in a table which shows the VLAN and Network (IP address & mask). Say I have defined a LAN called “ExtNet44” with VLAN=44. Then, in Network > LAN > Port Settings, for LAN Port 4, I set port type to “Access” and VLAN to “ExtNet44”. With this configuration, what is the router behavior for each of the following scenarios:

  1. Outbound Frame (leaving the router on Port 4) – is it TAGGED with VLAN=44, or is it untagged?
  2. Inbound Frame (coming into router at Port 4), when frame is tagged with VLAN=44
  3. Inbound Frame, when frame is tagged with VLAN != 44
  4. Inbound Frame, when frame is untagged

Next, if I set Port Type to “Trunk” for Port 4 instead of “Access”, do any of the answers to these questions change? If so, what is different?

#2

You raise a good question about outbound packets, I assume that it would be tagged on the way out so it doesn’t get dropped by the downstream switch. With the port set as an Access port, it will tag ALL packets on its way in.

Access - traffic is tagged on the way in

  1. I assume it will be tagged as VLan 44 (someone smarter than me will chime in)
  2. it will be tagged with VLan 44
  3. it will be tagged with VLan 44
  4. it will be tagged with VLan 44

Trunk - traffic is tagged prior to coming in to this link (by a downstream device)

  1. If the VLan tag is in the trunk configuration it will be allowed to traverse down the link, else it will be dropped.
  2. frame will be passed along (VLan tag allowed in Trunk)
  3. If the VLan tag is in the trunk config, it will be allowed; else it will be dropped.
  4. If the untagged VLan is in the trunk config, it will be allowed; else it will be dropped.

A trunk can allow multiple VLans to traverse. If you have a wireless access point that offers two SSIDs that map to separate VLans (one for guest, one for admin) - you would want to use a Trunk with both VLans allowed on the port that the access point connects to. A good rule of thumb is - “If a downstream device is tagging packets use a trunk. If no traffic is tagged by a downstream system, use Access”.

Just remember what a VLan is trying to be. Before VLans, if you wanted network layer separation - you would need to build two physical LANs. Independent switches and cabling. VLans allow you to use a common infrastructure (same switches and cabling) and keep the networks separated.

If you give us your goal with VLans and a brief description of your cabling/connectivity – we can give you some suggestions.

#3

Thanks @jmjones! Just in the last while, I’ve solved my problem, and with a bit more experimentation, I think I understand what to expect – it’s a little different than what you suggested, though:

“Access” mode is used for a VLAN port when the thing connected to the port is an endpoint device (desktop PC, webcam, printer, etc.) which is not VLAN-aware. So in access mode:

  • Outbound frames will NOT be tagged – in fact, tags will be stripped. This makes sense, given that the endpoint device doesn’t understand VLANs. A tagged frame would likely not be understood by your printer anyway, so keeping the tag would be counterproductive.
  • Inbound frames that are tagged with the target VLAN would be accepted; however, it’s probably not expected that any inbound frames would be tagged, given the endpoint device is presumed not to understand VLANs.
  • Inbound frames tagged with some other VLAN ought to be dropped (accepting them an retagging them would undermine the point of having VLANs); however, as in the previous answer, it’s unlikely any tagged frames would be seen on an access port anyway.
  • Inbound frames that are untagged would be accepted, and would be tagged with the target VLAN internally, before forwarding to other ports in the same VLAN.

In “Trunk” mode, the assumption is the opposite – we expect to have a VLAN-aware device on the other end of that port (e.g., a switch, WAP, another router, etc…). So, in Trunk mode:

  • Every outbound frame is tagged. If the frame was originally tagged, the original VLAN tag will be maintained when forwarding (assuming this port belongs to that VLAN, whatever it is). If the frame was originally untagged, then a VLAN tag is added.
  • Inbound frames that are tagged with the expected VLAN will be accepted, and the tag will not be stripped internally.
  • Inbound frames that are tagged with a different VLAN would be accepted, I think.
  • Inbound frames that are untagged are probably accepted (I’m not sure on this point)-- if they are accepted, then they are tagged with the VLAN for that port.

Does this seem correct? Any experts care to refine this definition?

#4

Your summary is correct for the most part. When I said “tagged”, I was meaning “the act of tagging” - not that the tagging had already been performed.

PC sends packet (no VLAN tag), packet arrives at switch interface (Access), the switch adds the VLAN tag on the way in (ingress), then forwards the packet on its way.

Wifi Client sends packet to access point (no VLAN tag), access point tags packet with appropriate VLAN (ingress), access point sends packet to switch interface (Trunk), switch forwards packet on its way.

In a nutshell, ACCESS will always apply the VLAN tag to every packet that comes into the interface. TRUNK expects to read VLAN tags and drop anything that doesn’t match what is expected in the trunk configuration.

I am glad that you were able to get your stuff working as expected. VLans are not an easy concept to teach yourself. Kudos.

1 Like