Configuring basic 802.1q VLAN's on ATOP switches

By: Frank Rysanek of FCC prumyslove systemy s.r.o. [ rysanek AT fccps DOT cz ]
Created in December 2022, as of switch FW version 7.70-svn3249
Applicable to the ATOP 75xx/95xx series L2 switches (details differ in the 76xx/96xx series L3 switches)
This is a 3rd-party white paper, not a vendor's official user's guide

Contents

• Foreword
• The 3 basic elements of ATOP VLAN configuration
  
  • 1. 802.1q VLAN declaration - and membership, for egress(-ish)
  • 2. Port VID = VLAN assignment on untagged ingress
  • 3. Forwarding groups = sets of local ports
  • 4. The Management VLAN
• VLAN 1: where the Gremlins are hiding
• Example configurations
  
  • Factory defaults
  • Empty port-based matrix
  • Just port-based groups
  • Default VLAN1 + one custom VLAN: seeping
  • Default VLAN1 + two custom VLAN's: seeping
  • A practical config with a non-default VLAN for management
  • Private VLAN's

In the world of modern Ethernet, Virtual LAN's are something very basic. As ubiquitous as the air to breathe, and as obvious as public transport lines. (In a small town. With only bus lines. Unless you venture into a true city. Er.)

Major brands tend to simplify VLAN configuration by making it very abstract, high level, intuitive. Physical Ethernet ports get categorized as "access" ports vs. "trunk" ports: the former are untagged, the latter are strictly tagged. Then you map VLAN's onto those two categories of ports - as simple as that. Access ports can only be a member of a single VLAN, because you need VLAN tagging to implement a link that transports multiple VLAN's (a trunk).

Major brands tend to mercifully obscure "what's under the hood": that VLAN processing is implemented by a sequence of filtering, tag addition and removal, and various forwarding decisions. Done in distributed silicon, as the management CPU is not nearly strong enough to carry the bulk of the traffic.

There are also vendors, some of them not exactly minor, who prefer to break down the VLAN config into two (or more?) elements. The admin is still not required to learn the actual gory details, but gets a remote idea of how VLAN's actually work under the surface, and maybe gets an opportunity to implement some special solutions (corner cases) if she so desires.

Somewhere in that "Ethernet vendor continuum", there is ATOP. A brand with some neat features and engineering principles. In this paper, let's focus on VLAN configuration. On ideas that don't necessarily shine from the ATOP reference handbooks.

The screenshot already shows a particular custom config.
We'll get back to the purpose of that in a dedicated later chapter.

The key attribute of a dot1q VLAN is its integer VLAN ID. As #1 is already taken, you are free to choose an integer starting from 2, for your own custom VLAN's.
You are invited to give each VLAN a textual local name, for your own orientation.

You need to specify right here, what ports shall belong to a particular VLAN, and among those, which will be tagged.
Note that the "Member Ports" column should contain all the members, untagged and tagged. Then the "Tagged Ports" is what it says on the tin. (If you click a Tagged port and forget to include it in the Members, you get a warning from the user interface.)

To select multiple ports, press and hold CTRL or SHIFT while clicking in the port lists.

To modify a previously defined VLAN, you don't need to remove it. Just specify its Vlan ID again in the "add/modify" section, enter the desired mnemonic name (even if it has not changed) and click the set of ports as desired. You need to specify all the ports exactly what they should look like (e.g. just appending one or two doesn't work).

VLAN1 cannot be removed or modified, and appears to have other special properties, with implications for practical operation. Let's have a dedicated chapter on that, below. In the context of this chapter, suffice to say that all ports are mandatory untagged members of VLAN1. This port membership in VLAN1 cannot be removed and cannot be made tagged.

You need to configure, per port, when an untagged packet arrives (on ingress), what VLAN it should belong to, in the internal forwarding process. The abbreviation PVID here means Port-based VLAN ID.
There's exactly one PVID per port. "None" is not a possible configuration. If you need to disable a port, do it in some other way: you can either exclude it from forwarding, or you can just shut it down administratively altogether.

When configuring a particular PVID on a port, note that a VLAN with that ID must already exist in the dot1q configuration menu, and the port at hand must be its member. Otherwise the admin interface throws a corresponding helpful error.
And vice versa, before you try to remove a VLAN from the dot1q configuration menu, make sure that no per-port PVID's points to that particular VLAN. Otherwise, you get an error, and the VLAN just doesn't get removed.

So... this is how you get a packet into a VLAN: using the PVID.
So that, it can then appear on other member ports of that VLAN - based on destination address type (unicast/multicast/broadcast) and learning (FDB), and the explicit port-to-port forwarding restrictions.
As far as standard payload traffic is concerned, this ingress labeling seems to apply equally to the somewhat special vlan 1. You are allowed to reconfigure the PVID from the factory-default 1 to something different, and after that, ingress packets on this port stop seeping out untagged on all ports, which they otherwise do courtesy of the immortal VLAN1.

Note: do not confuse the "PVID", as described in this chapter for ATOP switches, with other vendors' "Private VLAN's" configuration concept, where the "PVID" means something different.

First of all, you can just leave this "forwarding group matrix" at its default config (just one row, all checked) and focus on dot1q configuration and PVID configuration (= elements 1 and 2 above). And, you should be able to achieve tagged operation. Except, you'll notice that VLAN1 seeps everywhere on egress. That is true. In the Example Configurations section, we will discuss in detail several countermeasures to get rid of this effect. For instance, within this "forwarding group matrix", you can create a disjunct group, none of whose member ports have a PVID in VLAN1. Thus, your custom VLAN's will steer free of undesired VLAN1 traffic on untagged ports.
Yes you can configure a dedicated "forwarding group" for each dot1q VLAN. But, note, you don't really need to! You can put all your custom VLAN's in a common/shared group, and they will work just fine, they'll be separate all right, won't seep through into each other. You just need to keep PVID=1 out of your custom forwarding group, to keep that pesky VLAN 1 at bay.

There's actually one funny config I can think of: you can use forwarding groups to split a custom dot1q VLAN into two isolated "sub-VLANs" :-) that are not allowed to forward traffic to each other.

"Okay, so the groups are starting to dawn on me. But, how come that I can configure a particular port to be a member of multiple groups?
How can the groups overlap?
How does that config get resolved at runtime, per packet?"

Let's explain this "forwarding group matrix" in yet another way. Each row acts as an "n-ary any-to-any permissive filter rule". The default policy is "drop". Every packet traverses the "forwarding group matrix" from top to bottom, testing the "group communication permissivve rules" one by one. Once the algorithm finds a rule that's satisfied, the packet gets forwarded. If no matching rule is found, the packet gets discarded.

Note that this concept of "permissive n-ary rules" allows you to define "rule sets" (configurations) where e.g. ports A,B and C are all in the same dot1q VLAN, and A can communicate with C, B can communicate with C, but A cannot communicate with B.

Because A and C are permitted in one row of the matrix, and so are B and C, but in a different row. A and B are not permitted together by any single row.
This behavior appears to be consistent with the idea of "private VLAN's", as proposed by some other vendors.

"So... one last question: what happens if I remove all the ckeck marks in the matrix? So that it would be empty!"

The answer is simple: no traffic will ever get forwarded between ports!
Note that "local delivery" to/from the management CPU will keep working, i.e. management over IP will still work, on ports that are members of the management VLAN.
(I.e., under the hood, there's a hidden inner port of the L2 switch matrix, plugged into the management CPU core's inner NIC. Forwarding towards this inner port keeps working. Again - filters upon filters.)

As part of factory default config, the management VLAN is identical with VLAN1, which appears to have other special properties, and an exclusive immortal position in the config of dot1q VLAN's.
Note that this union of management and VLAN1's other special quirks is not mandatory. In an ATOP switch, you are allowed to configure a custom VLAN to serve for management, and it won't drag the other baggagge of vlan1 along into the custom VLAN. For all other purposes, VLAN #1 will remain what it is.

In dot1q config (our element #1), VLAN1 cannot be killed. All ports are mandatory untagged members = always viable for VLAN1 egress.

In PVID config (our element #2), VLAN1 is a default PVID on all ports, but this can be reconfigured to another VLAN = nothing really special here, just a sensible default config.

In port-based forwarding groups (our element #3), VLAN1 has no special position whatsoever - except maybe for complicating your understanding of this fact, in its default config in elements 1 and 2.

Our "fourth musketeer" = management VLAN attribute, also happens to default to VLAN1, but allows for re-configuration to a custom VLAN, and that choice has no further strings attached.

To sum up, the one pesky property, that motivates us to avoid VLAN1 in our setups, is the sticky dot1q untagged egress membership, that causes "seeping through" of VLAN1 where not desired.

Is it desired to have a management VLAN seep out of all ports, untagged? No it isn't.

In a broader network, consisting of multiple switches, can VLAN1 be transported through tagged trunks? No it cannot. Well, it can actually - you can keep it as the "native VLAN" on those trunks. The one VLAN that travels untagged, among all the other traffic that's properly tagged.

So how about this: build your network such that VLAN1 is present everywhere, trunked as "the one untagged native VLAN" across your whole backbone. Does that meet our esthetic criteria? Well kind of. Will it prevent seeping of unwanted stuff, out of every untagged port? No it won't ! Exactly because once something enters VLAN1, it has that habit of surfacing on all other ports, including those that we have assigned to other VLAN's, and we'd like to have that assignment exclusive. E.g., we certainly don't want the "ARP who-has and is-at" for our switch management personality to happily jump out of every switch port, into all our custom VLAN segments. And CIFS/SMB broadcasts from any Windows machine in VLAN1, and whatnot.

The only possible conclusion is: to prevent payload stuff from seeping everywhere out of VLAN1, you need to prevent payload stuff from entering VLAN1 in the first place!

• make sure that your untagged ports are either assigned a PVID other than 1, or prevented from forwarding, or disabled altogether (administratively down)
• assign a PVID other than one on your trunk ports. Either use a dummy VLAN for that purpose, or maybe trunk your custom management VLAN in this way
• and yes, move the switch firmware's management interface (L3 personality) into some custom VLAN. You don't want to fuel VLAN1 leaks by your management, and you do need to trunk the management VLAN across your network, which doesn't mix with the VLAN1 seeping.

Ouch. That hurt.
Is there any practical purpose to the VLAN 1 ? Now that we've learned how to turn it into a zombie and lock it away...

Difficult to say without inside knowledge. There may be some internal purpose. On the outside, there are protocols that are dot1q-agnostic. STP and friends, LLDP, LACP, some parts of PTP... generally network management stuff, not directly related to payload. Perhaps the switch matrix needs a VLAN to put all these into, internally, for the management CPU to see them... or some such. It may be burned into silicon, or it may be just the firmware author's early architectural decision.
Or it may be little more than some software development inertia.
Or maybe there are practical "outside" reasons that I have not gleaned yet, within my limited horizon.
In general, VLAN 1 is "special" with many other vendors of Ethernet switches - perhaps it's a tradition of some sort, in this trade. Perhaps I should finally read the IEEE 802 set of norms before bed time.

^^^ All ports in a single "forwarding group" = no limit on forwarding.

Let's include this example for completeness.
Just in case the honored reader has arrived here already halfway immersed in attempts to make VLAN's work.
In despair, it's not difficult to depart from the default config and end up in this situation - "just wipe all config to start over from a clean sheet, right?"

^^^ Assuming that the other config elements are at factory defaults. Or whatever.

With an empty Port-Based matrix, no traffic will flow, ever - among the ports.
Only "local input" for management is accepted by the switch.
(Similar to the Linux IPtables INPUT+OUTPUT vs. FORWARD chains, except that this is solid switch silicon that we're configuring here.)
I.e., even if you wipe the Port-Based matrix clean, the switch will still remain manageable over IP.

To "start over with a clean sheet", your Port-Based matrix should contain at least the default one row permitting forwarding among all ports.

In this example, the port-based forwarding groups are non-overlapping.
This is deliberate. We also have another example, where the groups do overlap - to achieve a particular interesting behavior.