Using RouterOS to VLAN your network

RouterOS Useful user articles
1

Title:
Using RouterOS to VLAN your network

Welcome:
This article is for system integrators, network administrators, and product enthusiasts looking for the definitive guide on how to design and setup VLAN networks using MikroTik. Follow along the light reading material and diagrams that make learning about VLAN an enjoyable topic. See the theory and then deep dive into the actual commands to implement it all. We’ll discuss Access, Trunk and Hybrid ports, switching and routing, and guest access into our networks.

Why VLAN?
If you have a need to partition and isolate networks and devices from each other using the same physical hardware, you maybe a good candidate for VLAN. If you have IoT devices, IP cameras, guests who need to use your WiFi, and a need to QoS who gets what, VLAN can make your network simpler to reason about. In micro-sized networks, it is possible to use other methods besides VLAN, but VLAN is never a wrong choice. This should give you the confidence to learn the VLAN concept knowing it will scale as your network and the number of devices grow.

VLAN Types:
Sometimes you see other terms alongside VLAN, such as Port Based VLAN, MAC Based VLAN, Native VLAN, and Voice VLAN. Some of these are really just names for what all is really the same thing. Maybe they use a different approach (automated vs manual) to get there, but ultimately, network devices are segmented. This document will focus on a manual Tag Based VLAN approach. Dynamic VLAN assignment using Radius examples can come if we have knowledgeable feedback in those areas.

VLAN Examples:
I focus on the most commonly requested scenarios: switch with separate router, WiFi router combo, guest WiFi, and public VLAN and printers. Basically hardware and scenarios that mirror MikroTik’s product lineup. From these examples you’ll be able to create any custom configuration on your own. Security topics are covered later under a separate section.

VLAN Terminology Overview:
Before discussing the various examples, we need to establish some common terminology and concepts about VLAN. In Tag Based VLAN, you’ll be working with Access and Trunk ports, configuring IP Addressing & Routing, and setting up IP Services on VLAN interfaces. These elements combine to create a managed VLAN network. This virtual network can be as big or as little as you like. You’ll be thinking about what to allow and what to block. Read each of these VLAN concepts below before using our configuration examples to understand how we use them on the command line.





Access Ports:
These ports define the entry into your VLAN. They represent groups of devices that need access to each other but not other networks. You will group them by ID. In this documentation we use colors like Blue, Green, and Red to help us to visualize the ID numbers. Access ports are configured in a way that means ingress (incoming) packets must not have tags and thus will get a tag applied. The egress (outgoing) packets (that are replying back to whatever was plugged in) get tags removed.

Trunk Ports:
These ports are what carry everything you care about between VLANs. If Access ports represent groups of things, think of Trunk ports as what enables these groups to get to places they need to go, like other areas of the switch or network. Trunk ports are configured such that ingress packets must have tags and egress packets will have tags.

Hybrid Ports:
These ports are for special situations and requirements. They share qualities and behaviors of Access and Trunk ports. Basically, they function as an Access port for ingress traffic without tags. When incoming traffic is tagged, and the tag is on the allowed list, it will then function as a Trunk port.

When designing your VLAN, you’ll have reached your first step when you can logically think about Access port grouping and Trunk port interconnections. How many VLANs and devices will you need to work with? Who gets access to what? Don’t rush this step. Take time to diagram your VLAN.

Native, Base, & MGMT (management) VLAN:
As you create your VLANs and pick VLAN IDs for each one, understand that the base network that you used to initiate your first connection to a router or switch is often termed the Native VLAN. In our examples, we do not use this default network. Instead we implement a Base VLAN (our name for the management VLAN) with an ID of 99. Over this network will be device to device traffic (routing, etc.). We also default Winbox availability here as well.

A word of caution if you are thinking of using VLAN 1 in your network design. Most vendors use VLAN 1 as the native VLAN for their hardware. MikroTik uses VLAN 0. If you try to create a VLAN 1 scenario with MikroTik, and expecting tagged frames, it will be incompatible with other vendors who default VLAN 1 as untagged. Therefore, unless you are prepared to change the default behavior in MikroTik and/or other vendors, it is simpler to use VLAN 2 and higher.

IP Addressing & Routing:
Since every VLAN you create should have a different IP Addressing scheme, you’ll use something different for each VLAN. If you set the Base VLAN to 192.168.0.x, your Blue VLAN might be 10.0.10.x, Green is 10.0.20.x, and Red set to 10.0.30.x. Just make sure that all VLANs are unique.

With an IP addressing scheme in mind, you’ll set your core equipment with manual assignments. So, a router might be set to 192.168.0.1, a core switch 192.168.0.2, a WiFi AP 192.168.0.3, and so on. The router can now become the default gateway routing your VLAN, switches, and connected devices. Using IP Services, you will make information available in an automated way.

IP Services:
The most well known is probably DHCP. Generally, every VLAN has its own DHCP server ensuring devices know about gateways and DNS servers they should use. When everything in the VLAN has an IP address, they’ll talk to each other over the ethernet protocol making broadcasts and generating other network traffic between each other.

When you have more than one VLAN, you have a truly segmented set of networks. If you plug a PC into a Blue VLAN, it can see and communicate only with other devices on Blue but not anything on Green or Red. If a printer is plugged into Green VLAN, only devices on the Green network could access it. You can share resources across VLANs while still not allowing interVLAN access. Just one of the benefits you’ll be reading about in this document.


Disclaimer:
What follows is my best understanding of how to implement the stated goals in RouterOS v6.43.12 based on the documentation available. Feedback from MikroTik as well as fellow forum members is required to make this an accurate document. Please suggest changes that should be made. Let’s make this issue a commonly understood one. Thank you.

2

Switch with a separate router (RoaS)

Overview:
This is the most recommended configuration for a business and forms the basis for all other examples. Everything lives on a switch until it needs to access the Internet or another specific VLAN or network resource. When that happens, a router (RoaS) will facilitate those requests. Otherwise, only devices on the same VLAN can communicate with each other.

Switch Configuration at a glance:




Access Ports:
Here we segment the network across three different VLANs. Blue is VLAN 10, Green is VLAN 20, and Red is VLAN 30. All of these will be configured as Access ports. These are ports in which end users may have physical access.

Trunk Ports:
In this switch example, we show purple fiber sfp inputs as being Trunk ports. Use ethernet interfaces if you prefer. We also show two ports to illustrate a switch linking itself to a router on sfp1 and another switch on sfp2. Use the number and combination you need. In the real world, most enterprises will have traffic coming into a switch, interacting with devices there, and then replying back out the same port or going out another port to hit additional networks. Imagine a Blue network spread across three physical switches and you get the idea.

Hybrid Ports:
These types of ports are shown in a separate configuration file linked below because their behavior and descriptions have not been illustrated in the diagrams. Here we change Blue VLAN ports Hybrid by setting a Green egress behavior on them. When traffic does not have a tag, it will be placed on the Blue VLAN. If arriving packets do have tags, and the VLAN ID is Green, those packets are allowed to ingress, placed on the Green VLAN, and the correct egress behavior is honored for both types of packets. If any other VLAD ID tries to ingress, it will be dropped.

IP Addressing & Routing:
While it is possible with RouterOS to do everything on the switch, that is not something you would truly do in practice unless you never want anything to leave the switch (full hardware isolation). Our example will show the router handling the creation and management of IP Services instead of the switch. First, we need to setup the switch’s IP address.

Switch IP Address:
Before the router can serve IP Services on the different VLANs, the switch and router should be on their own VLAN, which we call the Base VLAN. Others might term it the Management VLAN. The router’s IP address will be 192.168.0.1, so we’ll make our switch 192.168.0.2. Set the switch’s default route (gateway) to be the router, and anything else you might want, like NTP, DNS, etc.

Router Configuration at a glance:




IP Services:
With the switch complete, time to setup the router to provide IP Services. On the router we create three different IP Service interfaces: Blue, Green, and Red. Each one of these correspond to the VLANs it will be serving. For each one of these service groups, we turn on at least one item, a DHCP server. You can add or point to more as necessary.

Now, when we connect the Purple Trunk port on the router to the Purple Trunk port on the switch, anything following Ethernet protocol begins to function.

How it all works:
A PC plugged into the Blue VLAN starts broadcasting for a DHCP address. The switch keeps this from all other VLANs. The incoming packets from this PC get tagged with a Blue ID, and since the Purple Trunk port can pass Blue, it sends the packet out that port which goes to the router. The router’s Purple Trunk port sees a Blue DHCP request and allows a Blue DHCP server, running on a configured Blue VLAN interface, to respond to the request, sending the packet back out its Trunk port.

Meanwhile, a PC plugged into the Red VLAN tries to ping a Blue VLAN device. The ping reply goes out the switch’s Purple Trunk port to the router’s Purple Trunk port. The router would have sent the reply on to the Blue VLAN device except that a firewall rule drops interVLAN access.


Switch Config File:
switch.rsc (7.04 KB)
Switch with Hybrid Ports:
switch_hybrid.rsc (7.3 KB)
Router Config File:
router.rsc (7.18 KB)

3

Router-Switch-AP (all in one)

Overview:
This is a configuration for a home or even a micro business. Everything lives on a single hardware unit with PCs, laptops, NAS servers, printers, and phones all on the Blue VLAN. The Blue network is considered the home LAN making use of local ethernet ports and a home SSID. When friends come over, you give them a Guest SSID to keep them off your network.

Unit Configuration at a glance:




Access Ports:
Since most ports are on the Blue VLAN, you trust your PC, laptop, NAS, and printer to live there together. All your IoT devices are probably on a separate simple switch connected to Green via the one local ethernet port or WiFi. You can create as many VLANs on WiFi as you need, although three is probably a good limit to minimize WiFi inefficiency.

Trunk Ports:
There are no Purple Trunk ports. The Green VLAN is our other network. Whatever is plugged into the Green ethernet port may or may not be VLAN aware. However, it does not really matter. Once it hits our router/switch, its Green to us. Create more VLAN interfaces if you need more organization.

IP Addressing & Routing:
There is only one hardware device, of which we create one bridge to manage all LAN side devices. We set this IP address to 192.168.0.1. Everything gets routed out the Yellow WAN interface for Internet access.

IP Services:
The Blue interface supplies the home network with the services it needs. A Green VLAN interface supplies the Guest network with Green IP Services.

How it all works:
Firewall rules keep everyone separate.


Config File:
RouterSwitchAP.rsc (7.24 KB)

4

Access Point

Overview:
In the business environment and increasingly in homes, multiple wifi Access Points are used to provide coverage over wide areas and between building floors. Today, these devices are the network. So, learning how to control them and limit the physical areas they cover is of upmost importance. In this document, we only focus on implementing VLAN techniques across them.

Unit Configuration at a glance:




Access Ports:
Do these have Access ports? Yes, the invisible kind! Think of each SSID as playing the same role as an ethernet port would. In our example we show three: Blue, Green, and Red. Blue is for clients that will be accessing the corporate (or home) network, Green could be for guests, and Red would be for things you really want to limit, maybe not even allow them Internet access.

Trunk Ports:
There should always be at least one Purple Trunk per AP connecting back to another Purple Trunk on a switch or router. Our AP will have very minimal configuration, instead the connected clients will be managed by upstream hardware. To us, these hockey pucks are radios and that’s about all.

IP Addressing & Routing:
There is only one bridge managing all the configured VLANs. We set the Base VLAN’s IP address to 192.168.0.3 and the default gateway to our router. If you have very many APs you’ll want to use an Access Point Manager. For now, we hard code in the SSID names and passwords. VLAN ids are assigned to each WiFi interface.

IP Services:
IP Services are managed by our example router. The Purple Trunk port places us on the same network as other devices entering the router. VLAN interfaces running there respond to the ethernet protocol.

How it all works:
Firewall rules keep everyone separate.


AP Config File:
AccessPoint.rsc (4.7 KB)

5

Public VLAN, Printer & Server

Overview:
After configuring VLAN for your network, traffic is neatly categorized and segmented. However, you may develop a need for a LAN side resource to be accessible by some or all VLANs. This could be a group of printers or servers. You can make this as granular as you would like it to be. Here we illustrate the idea of simply using the Red VLAN for this purpose and then using interVLAN routing to allow access to this Public VLAN of shared resources.

We will use the router and switch from our first example. Only very small changes to the Firewall section allow for what we need.

Router Configuration at a glance:




How it all works:
Firewall rules allow visibility for entire VLANs or resources within a VLAN. Customize to suit your needs.


Firewall Customizations:
FirewallCustom.rsc (2.83 KB)

6

Security


Overview
To properly configure VLAN networks, or any form of a network, we must think about packet identity, direction, flow, permissions, and utilization. Deep diving into these concepts may make you feel like you’re learning more than you ever thought you needed to. Depending on the amount of value your network has to you, you only need to learn up to that level.





Security Utopia
There is no such thing as perfect security. The best security uses reporting and notifications alongside virtual and physical barriers. A steel door and a glass window each have something in common. Both can be broken into! However, if you have certain features in place, you can rewind to see what happened before and after an intrusion, maybe even respond in real time if you have the infrastructure.

This document, while highlighting a security utopia, does not actually implement it all for you. Instead we offer concepts you will need to research and think about. It is up to you to implement them in your environment. Understand that switching, routing, and security is not about controlling people. Rather, its about protecting and ensuring uptime across the section of digital highway you maintain. Make it a good experience and usable by everyone you’re responsible for. Be a good steward. That is the goal of this document and the purpose behind why we maintain networks.

VLAN Concerns
Access ports do not have physical security because end users need to manually plug things into them. Thus they should always be untrusted. They will also be the source of packets coming from an intruder in your network who may have found a way to have the same credentials as a staff member. As a network manager, it is probably not your concern to stop credential theft. Instead, be aware and plan for when a staff id does go rogue. There are also several other Layer 2 related security behaviors you need to know about because they will be coming in through these ports. On Access ports, always drop ingress packets that do have tags.

Trunk ports require physical security. Do not place switch hardware, or network Trunk drops anywhere near the public. Do not run switch-to-switch network cabling in easy to get to areas. Otherwise, the cable can be cut and spliced into and if the packet streams are not encrypted, then its game over. You could detect the downtime but then must be capable of locating the tap. Do not utilize automated Trunk port configuration, without also notifying yourself when such events occur. On Trunk ports, always drop ingress packets that do not have tags.

Hybrid ports are merely Access ports with all the same security challenges. They are a consideration for scenarios where you have limited network drops and still want assumed control over traffic type and behavior. They are most commonly used when a PC is connected to a mini-switch located in a VoIP phone. The phone is then connected to an Access port with Hybrid behavior. The phone marks its packets with a specific VLAN ID while the PC sends untagged packets. A Hybrid port therefore passes packets without a tag and also packets with this known VLAN ID. Always drop all other tags. The allowed VLAN ID tag should not have security permissions or too much priority over the untagged traffic occurring in the area.

Document
Take time to understand and document the types of VLAN interfaces you are managing. You should always have at least one VLAN per department, or per building, or even per floor, even if you don’t plan to segment the traffic. This is a personal decision you will make to be as granular as you need to be. Just don’t lump everything together. Otherwise, you won’t be able to QoS, secure, document, and prepare for needed downtime and upgrades.

More VLANs, along with good descriptions, can make everything easier to reason about. You probably allow every VLAN to access the Internet. That’s fine. But what about when Building 2, floor 3 has a virus outbreak sending all your data encrypted over port 80 to who knows where? You get the call, “shutdown access to that floor!”. How will you do that? If you’ve read this document, it will be easy. You could even hand them a report of the total packet count reassuring them that the breach was only 1TB in size and from which department.

Routing Concerns
Firewalling will happen at the Router, so you’ll be thinking about three main areas: WAN, LAN, and VLAN and their interactions. Treat LAN as a concept different from VLAN because VLAN can be something coming in from the WAN side of things (VPN, etc). From these three areas you can have at least eight major packet flow combinations. This will only balloon as you get more granular about things.

Keeping the WAN out is a fairly well understood concept. Making sure that the LAN has limited access to different resources, however, can be a daunting task.

7

Reserved

8

Nice start.

You might want to mention in “Native VLAN” that it’s not required to have one. My personal view (but that’s subjective and not everybody agrees) is that it’s actually bad thing to have it when diving into sea of VLAN, it messes the otherwise clean configuration flow (i.e. you have all the L3 configuration neatly packed on corresponding vlan interfaces but not for the “native” VLAN). The same goes to pvid set on bridge (which makes some people believe that that VLAN passes untagged over bridge; my view is that it’s not, rather that setting pvid on bridge “interface” is synonimous to setting pvid on e.g. ether interface so that “outside” part of bridge interface is untaged while “inside” part is tagged which makes it similar to creating vlan interface on bridge and using that one instead). Understanding that bridge is actually two personnalities (a sort of switch and interface) helps to picture things in a cleaner way.

In short: even though some things can be done in ROS, try to omit them from examples (do mention them in text if needed but note that same things can be done in other, cleaner, way) and keep tutorial compact and simple.

Another remark: when talking about router and it’s WAN address … it sounds as if WAN address is something holy and should be kept away from other physical infrastructure at all cost. Actually that’s not the case, it can easily be configured as yet another VLAN. Even more, there are use cases (such as IPTV service delivered via separate VLAN) which requires this approach. Even if it’s not the case, sometimes it’s still benefitial to treat WAN as yet another VLAN to carry it from physical point of presence (could be LTE modem on rooftop) to router itself (might be in basement) without need for separate physical connections.

9

Excellent points in your post, I will really enjoy your feedback. Allow me to finish up what I’ve got, and then we can edit that down. Will take me a few weeks. I’m hoping that we crowdsource this and it makes it into the Wiki. There are a stream of VLAN and configuration questions here and it all boils down to this: the documentation needs to be better. My goal is to walk through concepts, so that people have a mental model, and then show the commands so that pvid (whatever that is!) can actually mean something.

I admit that I will miss the mark too. I like your idea about all VLAN all the way, it’s cleaner. I think people are nervous to commit to it. I won’t get there on my first try. I’m trying to think about people new to networking, but maybe MikroTik’s clientele are an advanced group anyway?

There is real trepidation to go VLAN. Hopefully, if I make it seem simple enough, it won’t be so off putting. VLAN is the only way with IoT coming in like a freight train.

10

Sugar first: conceptually, I like the approach you use in this topic much more than the one used in your QoS one. This one concentrates on how things work rather than on a complete configuration for a single particular target scenario. The QoS one provides a ready-made working solution, however so complex that people just copy-paste it and then wonder why it doesn’t work in their scenario for which it is not appropriate. Worse than that, it lacks the basics which seem obvious but the questions on the forum show that they are not to everyone.

The product manuals (not only the Mikrotik ones) rarely explain the very basics, they concentrate on the particular implementation of these basics in the product and how to use it. This approach makes a lot of sense for seasoned professionals who don’t need to read the same stuff over and over, but they are only a part of the audience - for many people Mikrotik is their first network infrastructure device ever. And for those people, a link to a tutorial on “underlying basics” would be a great help while the professionals would just not click on it and continue reading the main topic.

So again, what I appreciate most on this topic is the explanation of the basics. Once one understands them, the Mikrotik’s official manual is enough to set up what you need, but without the understanding, it is like a cooking recipe telling you how much of white powders A, B, and C to use without telling you which one provides which taste. If you follow the recipe exactly, the result is the same as the author’s one, but if you want it to be more sweet, you can’t find out in the recipe which of the powders to add more of. And whilst try-and-error approach is easy with cooking because all you need to verify the result is your taste, with VLANs you need to use sniffing and Wireshark and, first of all, you need to know what you are looking for and understand what you see in the capture.

Now some criticism: I’m confused by your mentioning of “port-based VLAN” and “trunk port” in the same sentence. What I’ve understood till now was that the term “port-based VLAN” means no more and no less than that all ports of the same device are split into several groups and traffic forwarding is permitted only between ports in the same group, and that this is achieved using some other means than tagging frames with VLAN ID, which implies that trunk ports cannot exist in such scheme because no tags are available on the frames themselves to distinguish those belonging to different VLANs from each other. Internally, some switch chips do use tags also to implement port-based VLANs, but these tags carry the ID of the ingress port, not an ID of the VLAN. And the ingress port ID is only meaningful inside the switch itself, so there is no point in handing it over to another switch as it would be meaningless there (unless you’d add the ID of the source switch as well but it would be an implementation and management nightmare).

So with port-based VLAN, all ports can be just access ports, each to its own VLAN, and that is it. Once you start using some kind of tags carrying a VLAN ID consciously, in my understanding it is not a port-based approach any more, although from the outside perspective the behaviour of the device may be the same if you use only access ports along with VLAN ID tagging.

11

You are correct. I have changed it to be Tag Based VLAN (802.1Q) which is the technically correct term for what is being discussed.

12

So, it’s too early to make this topic sticky? :slight_smile:

Impressive start, btw

13

Great work. Normis, make this topic sticky..

14

Hi pcunite. two questions.
First example, first diagram configs

(1) why are you separating out the different vlans, when there is no value added (or so it seems to me).
For example, add bridge=B1 tagged=sfp1,sfp2 vlan-ids=10,20,30 should suffice!
Similarly, add bridge=B1 tagged=ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=10,20,30
Since there are no differences between the exact number and identification (exact replica) of tagged ports, I fail to see the need to separate the vlans out.

(2) why have you shown the PVID=1 settings. Are they not by default assumed to be PVID1 without any entry??

15

@pcunite
very NICE [excellent] work

Not sure if the following is a typo or otherwise :slight_smile:
the rsc file called switch one comment line has:

Because weird, we “also” add the Bridge

So do you mean wired or actually weird

16

Thank you, no I actually mean weird (using because noun phrasing) because I find it confusing to have bridge access set this way at this point in the syntax. The stated reasons, explain why, but I feel that port vs bridge (the bridge is a virtual switch or container for your ports) should be separate concepts. When setting up individual ports, why have this ungainly bridge thingy thrown in? Nevertheless, without understand this, unexpected behavior is the result. So, we have to document it.

I also feel like that when vlan-filtering=yes is set, it should enforce common understanding of what Access and Trunk ports do (drop any and all packets that don’t comply, why in the world would you not?). I can understand the wiki’s author’s frustration as they try to explain securing the VLAN. I think MikroTik can get it correct and I think we should encourage them to do so. For those that need unsecured VLANs, by all means, have an option for that. The rest of us want Access & Trunk port to behave securely and not require other options. Secure should be the default.

I think my config file comments should probably be rewritten to be more clear:
Because weird, we “also” add the Bridge itself as a tagged member! This is required to control which packets get access to the Bridge itself.

17

OT: funny but in preceeding post by @pcunite I can only see first paragraph of his post (ending with “So we have to document it.”). If I start writing a reply (quoting his post or not,) I can see two more paragraphs.

[edit] After I posted this rant, I can see the whole previous post. This is a sinister business, Watson…

I fully agree that having bridge implicitly act as a port is weird indeed. And causes lots of mis-understandings. Including the dilemma about including bridge a tagged member of itself? Probably most of misunderstandings would be gone if there was a special pseudo-interface (even implicitly created for every bridge) that would actually act as interface. In addition to that, stand-alone versions of the very same type of interface would come handy as loop-back device … now one has to abuse a bridge for this functionality.


I’ll take this opportunity to open a discussion about how to deal with wifi “access ports” to vlans.
There are two ways:

  1. I guess the old (legacy) way is to configure
/interface wireless set [ find name=wlan1 ] vlan-mode=use-tag vlan-id=BLUE

and configure wlan1 interface as tagged member port of bridge
2. probably the new way where we don’t fuss about VLAN in /interface wireless, only deal with it in /interface bridge subtree where wlan1 interface is configured as access port to a VLAN

So what is the better (more understandable/readable) way to configure it? My guess is that way 2. is better as it keeps VLAN config in single config subtree … but what do other forum members think about this?

18

I’ll have a stronger opinion on this when I go to implement it. Off the top, vlan-mode=use-tag is like free candy, which can only mean its bad for you. Not sure yet. Whatever the case, don’t let me be weak!

19

@anav,
I have updated the configuration files. Please reexamine, and then ask your question again. Then, I’ll give you a formal response. Yesterday evening, I had the opportunity to actually implement the config files on real hardware and made some adjustments.

Question 1:
Responding to what you have written, for now I will say that, one reason why I break out commands is to show, conceptually speaking, what is happening. When designing VLANs, the administrator has to think about how Access ports will interact with Trunk Ports, and how all that will eventually work over L3. Naturally, when someone is familiar with the MikroTik command line, they can combine several settings into one liners. But that is confusing when trying to learn it for the first time.

Question 2:
I think MikroTik’s current API is not expressive enough for what is happening. There are times when you must specify PVID, so I feel, personal opinion, that as I’m trying to illustrate the VLAN concept, that the reader understands better by doing it this way. With PVID=1, it is explicitly being shown that a Trunk port is being created.

20

I don’t see vlan-mode=use-tag as candy, it used to be the only way back in ROS<=6.40 … as was the switch-chip VLAN stuff.

But you’re right … you’ve been bad to @anav so no vlan-mode=use-tag for you tonight :laughing: