Community discussions

 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:02 am

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 and Trunk 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 printer. 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 will be covered separately.

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.

vlanlogo.png

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 are not expected to have tags and thus will get a tag applied. The egress (outgoing) packets, that are replying back to whatever was plugged in, get their tags stripped off. An optional security feature can remove malicious tags on incoming packets.

Trunk Ports:
These ports are what carry everything you care about between VLANs. If Access ports represent groups of things, you could 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. Configuring a Trunk port means ingress packets should have tags and egress packets will have tags.

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 to show others. When you have that understood, at least idealistically, you are ready to move on to IP Addressing & Routing.

IP Addressing & Routing:
To get your VLAN going you have to start somewhere and that's usually something termed the Native VLAN. As soon as we start working with network equipment, the base network, that base IP address scheme (that you used to initiate a connection to the router or switch) becomes the Native VLAN. This is mainly to distinguish it from VLANs you will create in the future. Note that a Native VLAN is not a requirement but rather something that continues to exist if you allow it. Since every VLAN you create should have a different IP addressing scheme, you'll use something different for each VLAN. If Native was 192.168.0.x, your VLAN Blue could 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 address scheme in mind, your core equipment will get manual assignments. So, a router might be 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 for your VLAN and any separate switches and devices. Using IP Services, you'll make this information available to the rest of the network.

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.

It is now that your VLAN has been born. If you have created more than one, then at this point 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 inter VLAN 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 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.
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Tue Jan 22, 2019 6:00 am, edited 9 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:02 am

Switch with a separate router

Overview:
This is the most recommended configuration for a business. 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, router-on-a-stick) will facilitate those requests. Otherwise, only devices on the same VLAN can communicate with each other.

Switch Configuration at a glance:
switch.png

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. What about malicious incoming packets that have been tagged? That will be covered under the security section.

Trunk Ports:
In this switch example, we show purple fiber sfp inputs as being Trunk ports. It does not matter the type of Trunk port you have. Use ether1, or even WiFi 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. However, you can use any combination and our examples will work the same. 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.

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 we can serve IP Services on the different VLANs, the switch and router need to be on their own VLAN, or the Native VLAN. The router's IP address is 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.

Which interface do we set 192.168.0.2 on? That’s a good question. Recall that we only have one bridge configured for this switch. You could set that bridge to be 192.168.0.2 but that would enable an entire network scheme access to the switch itself from any port. With a cautious configuration, not a big deal. In the security section we'll discuss using one port or even VLAN to be management access. For now, don’t worry about the complexity.

Router Configuration at a glance:
router.png

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 the request for a Blue DHCP request and spins up a Blue DHCP server running on a configured Blue VLAN interface. It responds to the request, sending the packet back out its Trunk port.

Meanwhile, a PC plugged into the Green VLAN tries to ping a Blue VLAN device. The ping reply goes out the switch's Trunk port to the router's Trunk port. The router tries to send the reply on to the Blue VLAN except that a firewall rule tells it to drop inter VLAN access.

Show Me The Code!
Enough theory, let’s see how to implement this using RouterOS commands.


Switch Config File:
switch.rsc

Router Config File:
router.rsc
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Tue Jan 22, 2019 5:24 am, edited 18 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:03 am

WiFi Router

Overview:
This is a configuration for home or a micro business. Everything lives on a single hardware unit with PCs, laptops, NAS servers, printers, and phones all on the Home (Native) VLAN. The Home network is supplied from local ethernet ports and a home SSID. When Guests come over, you give them the Guest SSID name and password to keep them off your network.

Unit Configuration at a glance:
wifi_router.png

Access Ports:
Since most ports are on the Blue Native VLAN, they will not have ingress and egress behavior assigned. You trust your PC, laptop, NAS, and printer to live on Blue. All your IoT devices are probably on a separate 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, instead we opt for a Green VLAN. If whatever is plugged into the single Green ethernet port is VLAN aware, it does not really matter. Once it hits our router/switch, its Green to us. This also means we will set ingress filtering to ensure no malicious tag is ever present. It might be tempting to simply setup a separate bridge for your Guest network. For tiny all-in-one networks like this that is certainly a valid option.

But you wanted to learn VLAN so let's give you a better reason. Let's say that you do care about the VLAN aware device(s) on Green. If so, you turn it into a Purple Trunk port. There is an IP Camera that should have more Internet bandwidth compared to Green. So, now you have at least three networks you are managing: your Blue home, Green guests, and Red for IoT devices and such. When they all come into the router, you can QoS them differently because you have three VLAN interfaces to work with.

IP Addressing & Routing:
There is only one bridge, the Native Bridge, we set its IP address to 192.168.0.1. That will be your default gateway for all devices on Blue. Everything goes out the Yellow WAN interface for Internet access.

IP Services:
The Green VLAN interface supplies the Guest network from a Green DHCP server.

How it all works:
Firewall rules keep everyone separate.
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Thu Jan 10, 2019 6:57 am, edited 4 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:04 am

Guest WiFi

Overview:
Aren't these little guys cute? Early when WiFi was coming out, I refused to use them, instead preferring to run a cable to my laptop. "How in the world can these things be secure!", I would protest. I kept seeing my data being thrown miles around. The best approach today is to embrace them because these are the network. Thankfully we can control the area they cover and limit harm they might otherwise do.

Unit Configuration at a glance:
guest_wifi.png

Access Ports:
Do these have Access ports? Yes, the invisible kind! It's best to 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 would 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, the Native Bridge, we set its IP address to 192.168.0.10. We set 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:
The Purple Trunk port places us on the physical network the same as other devices entering the router. VLAN interfaces running there respond to the ethernet protocol.

How it all works:
Firewall rules keep everyone separate.
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Fri Jan 11, 2019 11:06 pm, edited 3 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:07 am

Public 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 in which all VLANs need to be able to access. This can become 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 inter VLAN routing to allow access to this shared or public VLAN.

Unit Configuration at a glance:
switch.png

Access Ports:
Here we still segment the network across three different VLANs as shown before. However, this time we make Red VLAN 30 to be the public VLAN. From a configuration point of view, there are only small changes to accommodate logical reasoning for what you plug into the Red VLAN.

Trunk Ports:
Same as before.

IP Addressing & Routing:
Handled by the Router as before, with some inter VLAN changes made. Will go over those when we look at the Router configuration.

IP Services:
Same as before.

Router Configuration at a glance:
router.png

How it all works:
A simple change is made on the router to allow Red VLAN to access other VLANs. It is easy enough to allow or deny Internet access as well.
You do not have the required permissions to view the files attached to this post.
Last edited by pcunite on Wed Jan 16, 2019 6:55 pm, edited 2 times in total.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:08 am

Reserved
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 1:10 am

Reserved
 
mkx
Forum Guru
Forum Guru
Posts: 1338
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 2:26 pm

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.
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Sat Jan 05, 2019 3:52 pm

Nice start ... keep tutorial compact and simple ...

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.
 
sindy
Forum Guru
Forum Guru
Posts: 2608
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to VLAN your network

Sun Jan 06, 2019 12:50 pm

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 749
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to VLAN your network

Mon Jan 07, 2019 12:05 am

... Now some criticism: I'm confused by your mentioning of "port-based VLAN" and "trunk port" in the same sentence ...

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.

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.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8166
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: Using RouterOS to VLAN your network

Tue Jan 08, 2019 10:22 am

Allow me to finish up what I've got, and then we can edit that down. Will take me a few weeks.
So, it's too early to make this topic sticky? :)

Impressive start, btw
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.

Who is online

Users browsing this forum: No registered users and 20 guests