Overlapping VLANs
Recently we were asked an interesting question from a customer. They were in the middle of commissioning a very large project and below is a simplified version of the particular situation in question; I’ve removed a lot of additional devices on the network to focus in on the particular area of interest. Put simply, the customer wanted to know if there was a way to limit the communications from the Server (and the rest of the network outside of the DLR Ring) to ONLY the Micro850 PLC such that it could not communicate to the VFDs; however the PLC still needed to be able to communicate to the VFDs. This PLC did not have an option for a second network card and the customer did not want to add a NAT device or re-IP anything, but replacing the unmanaged switch with a managed switch was on the table.
So, could we throw any managed switch in and solve this? In most industrial managed switches VLAN configuration is very simple. For each port you select either
Mode: Access port. Then you specify for what VLAN.
or
Mode: Trunk port. Then you set a native VLAN and list the VLANs that will be traverse the segment as tagged.
More specifically on an Access port, you typically are only allowed to make a port a member of a single VLAN. For 99% of applications this makes complete sense and this simple configuration is wholly appropriate.
Have you ever used a switch though where the VLAN configuration looked more complicated? Take for example the screenshots below from a Hirschmann Classic OS switch. VLAN configuration is broken into two separate pages.
First we have the Port page below which is responsible for ingress. [If a frame comes into this port untagged, what VLAN should I interpret it as being a member of?]
Next we have the Static page which is responsible for egress [Is a port a member of any given VLAN, and if so, when a frame exits should I send it out Untaggged (U) or Tagged (T)?]
In those 99% of applications you end up having columns in the Static page above as
Access Ports - a single U (member, untagged) and all the rest “-” (not a member)
or
Trunk Ports - a single U (member, untagged) and several T (member, tagged)
But, and this is a big BUT, this switch will let you assign multiple Us in a single column making a single port a member/untagged of multiple VLANs concurrently. Why is this useful?
Enter “Overlapping VLANs” which is not so much a feature as a concept that can be enabled by advanced VLAN configurability. Given that original scenario we were presented with I could replace the unmanaged switch with one that supports this more granular VLAN configuration and setup as shown in the picture below.
The results of all above configuration is exactly what the customer asked for: the Server can communicate to the Micro850, the Micro850 can communicate to the VFDs, but the Server and VFDs cannot communicate. Note as defined above VLAN 4 overlaps all the physical ports. From a broadcast domain perspective the PLC is in the broadcast domain of VLAN 1 (original network) and VLAN 3 (VFD network) but VLAN 1 and VLAN 3 are broadcast-isolated from each other.
So are Overlapping VLANs something you will use every day? Probably not. Is it a nice additional tool to have in the belt when you don’t have a firewall or ACLs to help - YES! If you’ve got a need like the original one presented here and would like to talk through options on how to tackle it, give us a shout. Until next time…
***IMPORTANT POST UPDATE***
A LinkedIn commenter (Thanks Sever!) reminded of one more setting beyond above that needs to be available and potentially toggled from default for proper operation of the Overlapping VLAN concept. The switch also needs to support Shared VLAN Learning mode. Below is a screenshot from the Hirschmann RS20 pictured demonstrating the default setting is Independent VLAN Learning. Make sure and toggle this to Shared VLAN Learning when implementing Overlapping VLANs.
As the help file below details, failure to toggle to this setting would lead to undesired unicast flooding.
