Tagged VLANs not needing Untagged interfaces

PrimeYeti · Wed Apr 12, 2023 1:02 am

Having a bit of a brain fart here. I have a WAN connection that the ISP insists needs to have a VLAN tag of 100 in order to function which is fair enough and it is all working.

The reason I feel that I am having a brain fart is because none of my LAN interfaces are untagging VLAN 100 but surely all traffic coming in from the WAN is going to have VLAN 100. This is proved when I run a Torch on my WAN interface which shows all incoming traffic with a VLAN of 100. Surely if this is the case my LAN shouldn't be functioning all since the incoming traffic is going to have an 802.1Q tag that isn't being removed, and therefore my LAN devices shouldn't be able to read it.

Buckeye · Wed Apr 12, 2023 1:27 am

The vlan 100 tag is stripped before the router deals with it.

Why do you thing the tag would be coming out the other side of the router?

This is true for mac addresses on the frame as well.

Or maybe I am misunderstanding what you are stating/asking?

Buckeye · Wed Apr 12, 2023 1:48 am

See Virtual Local Area Networks (VLANs) and pay attention to the Tagged Ports and Untagged Ports section.

anav · Wed Apr 12, 2023 2:11 am

It is common for some fiber ISPs and PPPOE ISPs to have vlan traffic designated.
Dont despair, this has nothing to do with the LAN or Bridge.

Ex. 1
/interface ethernet
set [ find default-name=ether1 ] name=ether1-ISP

/interface vlan
add comment=YOURISP interface=ether1-ISP name=vlanISP vlan-id=25

/ip dhcp client
add add-default-route=no disabled=no interface=vlanISP use-peer-dns=no use-peer-ntp=no

Ex. 2
/interface ethernet
set [ find default-name=ether1 ] name=ether1-ISP

/interface vlan
add comment=YOURISP interface=ether1-ISP name=vlanISP vlan-id=10

/interface pppoe-client
add add-default-route=yes interface=VLAN10 name=pppoe-out1 \
use-peer-dns=yes user=*******

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In both cases the VLAN associated with the ISP stops at the appropriate client ending.
After that, traffic from the LAN utilizing the WAN connection is predicated on
a. firewall rules allowing traffic through the router (and out the WAN) Forward Chain
b. Routes, telling the router where to send traffic.

Buckeye · Wed Apr 12, 2023 4:57 am

This is a complex section with busy diagrams, but it does describe what happens. Packet Flow in RouterOS

Frederick88 · Wed Apr 12, 2023 5:15 am

LAN and WAN are separate networks, regardless if they're on different VLAN / no VLAN.

Even if both WAN and LAN are no NO VLAN (native, untagged), that's still not the reason why LAN can send and receive traffic out of WAN... The routing table is what does this, see IP Routes.. this is based on IP network and next-hop gateway, not VLAN.

most of VLAN'ing is done when data enters or exists the router.. as long as the router understands the VLAN and network within the VLAN, it then comes down to routing rules between the two networks.

PrimeYeti · Wed Apr 12, 2023 11:43 am

In both cases the VLAN associated with the ISP stops at the appropriate client ending.
After that, traffic from the LAN utilizing the WAN connection is predicated on
a. firewall rules allowing traffic through the router (and out the WAN) Forward Chain
b. Routes, telling the router where to send traffic.

Oh interesting! So even though I've tagged the VLAN at my router's WAN interface it still gets stripped? I thought this would only happen if the interface were untagged for VLAN 100. Secondly if it was stripped, how come I can see VLAN 100 on the torch for my WAN interface? I would presume the interface is what strips it which is why I can't see the VLAN in a torch for my LAN bridge.

mkx · Wed Apr 12, 2023 3:16 pm

There are a few layers between physical ethernet port and router's IP layer (e.g. firewall, NAT, routing). In your case they are:

ethernet protocol
It can carry different payloads, nowdays most often it's IP packets, but can be VLAN frames or numerous other payload types
VLAN
It's an encapsulation of additional header, most often it's IEEE 802.1Q. This header includes VLAN ID, QoS bits.
IP packet
It also encapsulates different protocols (TCP, UDP, ...), but not the point in this exercise

So when your WAN is "plain", without VLAN tags, IP layer of router uses "ether1" as WAN interface. Ethernet driver then adds / removes ethernet headers around those IP packets.

When your WAN is VLAN-tagged, then you have to add special interface of type vlan (e.g.: /interface vlan add name=wan_vlan interface=ether1 vlan-id=1000), which does encapsulation/decapsulation of frames, mentioned in bullet #2. For IP layer of your router uses wan_vlan interface as WAN interface. VLAN interface then addsVLAN header and passes frame to ethernet (bullet #1) to do its job. When packet is being received, the path is opposite.

When oyu torch your WAN interface (e.g. ether1), you'll see tagged frames in case your ISP requires VLAN tags. But router's WAN interface will present to router's IP layer untagged frames (e.g. torch the VLAN interface).

And this mechanism of VLAN tagging can be selective for any of physical (and some logical) interfaces, so it's perfectly normal to see e.g. WAN tagged and LAN untagged. Or the other way around (which is often as well): several LANs, all tagged, and WAN untagged.

PrimeYeti · Wed Apr 12, 2023 4:13 pm

Hi MKX,

I understand the theory behind encapsulation and decapsulation, the part that I am not fully getting in this scenario is how traffic tagged with VLAN 100 isn't passed on traffic received on my WAN to my LAN. I'm not fully understanding this because there is no untagged port to necessarily remove the VLAN tag, so is this just part of the decapsulation process in this situation?

For example, when frames are received on my WAN, the router will decapsulate it to get to the IP packet to see where it needs to be sent and in doing this it removes the VLAN header? If so then that opens a whole new can of worms for me :,D

k6ccc · Wed Apr 12, 2023 6:22 pm

For example, when frames are received on my WAN, the router will decapsulate it to get to the IP packet to see where it needs to be sent and in doing this it removes the VLAN header? If so then that opens a whole new can of worms for me :,D

That's it. Just to avoid confusion (or maybe create it), if you are performing switch functionality in the router (normally with a bridge), packets coming in on one interface that is VLAN tagged will leave on other interfaces and still be VLAN tagged. BTW, that's about as far as I can get with using a bridge in RouterOS as I do not perform switch functionality in any of my routers - that is all handled with VLAN aware switches.

Buckeye · Wed Apr 12, 2023 7:39 pm

I understand the theory behind encapsulation and decapsulation, the part that I am not fully getting in this scenario is how traffic tagged with VLAN 100 isn't passed on traffic received on my WAN to my LAN. I'm not fully understanding this because there is no untagged port to necessarily remove the VLAN tag, so is this just part of the decapsulation process in this situation?

The
/interface vlan
add interface=ether1 name=ether1.100 vlan-id=100

Does two things:

Creates a new interface that an ip address can be applied to. In the above example, ether1 is the base interface, and the created interface named ether1.100 and it is associated with vlan 100 tagged traffic on ether1.

Removes tag in ingress into the routing engine and adds it to packets egressing the routing engine. This allows the routing engine to only need to understand how to process packets in a standard format. This is also true for things like pppoe interfaces.

The routing engine knows nothing about vlans, it just knows about interfaces and ip addresses.

PrimeYeti · Wed Apr 12, 2023 9:41 pm

Does two things:
Creates a new interface that an ip address can be applied to. In the above example, ether1 is the base interface, and the created interface named ether1.100 and it is associated with vlan 100 tagged traffic on ether1.

Removes tag in ingress into the routing engine and adds it to packets egressing the routing engine. This allows the routing engine to only need to understand how to process packets in a standard format. This is also true for things like pppoe interfaces.
The routing engine knows nothing about vlans, it just knows about interfaces and ip addresses.

Is this just a similar process followed if I were to do ROAS for InterVLAN routing for example except taking out the WAN and having it all internal to the LAN? Just trying to relate it to something I know a bit more about. Since VLAN-A would need to ingress the routing engine to reach VLAN-B which would be tagged with a new VLAN upon egress.

Let me know if I’m overthinking :,)

Buckeye · Thu Apr 13, 2023 12:11 am

Is this just a similar process followed if I were to do ROAS for InterVLAN routing for example except taking out the WAN and having it all internal to the LAN? Just trying to relate it to something I know a bit more about. Since VLAN-A would need to ingress the routing engine to reach VLAN-B which would be tagged with a new VLAN upon egress.

Assume the following:

Base interface ether2 on Router, with no ip address.
VLAN-A vlan 100 ip address 192.168.100.1/24 on router using ether2 as parent/base interface
VLAN-B vlan 200 ip address 192.168.200.1/24 on router using ether2 as parent/base interface

Here you could use this
/interface vlan
add interface=ether2 name="VLAN-A" vlan-id=100
add interface=ether2 name="VLAN-B" vlan-id=200

Then you would add ip addresses to VLAN-A and VLAN-B and create dhcp servers for each vlan.

To have a router on a stick (ROAS), you need a vlan aware switch. Assuming you have a vlan aware switch configured with port 1 with vlan 100 (VLAN-A) and 200 (VLAN-B) both tagged (and pvid 1 unused) and that port was connected to a single port on the router, (say ether2).

In addition on the vlan aware switch, you would create "access ports" for vlan 100 for VLAN-A devices and access ports for vlan 200 for VLAN-B devices. An access port is a port that has only one vlan defined, it is the pvid, and the port is set for untagged traffic.

Then non-vlan-aware devices could be attached to the access ports, and they would get an ip address from the correct dhcp server.

In this case if PC on VLAN-A sent a packet to a PC on VLAN-B the packet would start with no tag, be received by the access port on the switch, classified into the vlan specified by the pvid, exit on the port 1 with a vlan 100 tag, be received on ether2 of the router, it would notice the tag, and deliver to vlan 100 interface that would remove the tag and ethernet header, deliver to the router via the VLAN-A interface, the router would see it was destined for an address in the 192.168.200.0/24 network, would see it had a connected route for 192.168.200.0/24 via VLAN-B (192.168.200.1) and forward the packet to VLAN-B (the vlan interface would then add a tag for vlan 200, and send out ether2. The switch would receive the ethernet frame with vlan tag 200, (classify into vlan 200) and send to the access port with the mac address of the VLAN-B PC associated with it and because it is an untagged port, for pvid 200, it would send the packet without a tag. The PC would receive it just as if it was a direct connection from a non-vlan-aware device on the same wire.

Did you look the article (and youtube video it references) that I posted in post #3 ? It would be worth your time if you want to understand.

PrimeYeti · Thu Apr 13, 2023 12:34 pm

moderator action - removed unnecessary quote

I did read the article and watch the video both of which were very helpful, so thanks for that. Although it didn't seem to help in answering my original query regarding frames tagged with a VLAN coming in on the WAN not being seen on the LAN. The reason I mentioned ROAS is because it's a scenario where a frame would be received on a VLAN, need to be decapsulated, and then routed elsewhere which is also what I believe would happen in my original scenario (e.g. come in via WAN tagged VLAN 100, go to Eth interface and then to routing engine, told to go to LAN).

mkx · Thu Apr 13, 2023 3:04 pm

I'm not sure I properly understand what exactly is it you're having problems with.

If I reference to my previous post #8 above ... and try to explain it a bit higher level:

when router is routing, then all packets will pass router's IP layer. Which means that data will travel independently all the lower layers for both legs (if we constrain ourselves to two legs: WAN and LAN). In case you described in first post this means:

WAN (tagged)
  ↑→ physical ethernet port (ether1)
           ↑→ vlan interface (which strips/adds VLAN tag with VID 100)
                  ↑→ router's WAN IP interface   (untagged end of VLAN interface)
                             ↑
                             + → routing / firewalling process
                             ↓
                  ↓→ router's LAN IP interface   (possibly bridge)
  ↓→ physical ethernet port (bridge member, e.g. ether2)
LAN (untagged)

So ISP's tagged packets get capsulated/decapsulated from VLAN envelope and L3 processed by router. LAN packets are treated separately (and can be similarly capsulated/decapsulated if VLANs are used on LAN side of router). But the crucial thing is: these processes are independent from each other.

Another possibility is "switch scenario", where device is only switching between ports and none of L3 processing is done. For example: ISP requires VLAN tags but actual router can not deal with VLAN tags. So you introduce a simple VLAN-enabled switch to deal with VLAN tags. (ISP is connected to switch port1 and router is connected to switch port2). In this case (poor) drawing would be like this:

WAN (tagged)
  ↑→ port1 (set as tagged member of VLAN 100 meaning that only frames with VLAN tag with ID 100 can pass in either direction)
                             ↑
                             + → switch chip (which internally works with all frames VLAN tagged)
                             ↓
                  ↓→ switch port untagging/tagging process [*]
  ↓→ port2 (set as access port of VLAN 100 meaning that only untagged frames can pass between wire and port
router (untagged)

[*] when switch (or bridge) port is set as access/utagged member of certain VLAN, there are two (in principle independent) tasks which switch chip (bridge) will perform:

on ingress, VLAN tag will be added to untagged frames and VLAN ID will be set to value of PVID (default vlan id)
on egress, VLAN tag will be removed from frames if VLAN ID corresponds to the value of VLAN of which port is untagged member

As I wrote, these are in principle independent and ROS allows one to set certain port as untagged member of multiple VLANs. However, port can be only set with single PVID (because tehre's no simple logic which would tell switch chip which of multiple VLAN IDs should be applied to a certain ingress frame). In case of using vlan-enabled bridge in ROS, when port has pvid property set (and is set to allow untagged frames on ingress), it's automatically added to the list of untagged ports of that VLAN ... so it's not necessary to set it manually. I guess some switch/router OSes only support this kind of setup (and others allow to set things the way ROS allows and they offer it as special feature, some call it "asymmetrical VLAN").

If the description above doesn't clear things for you, please explain more clearly what is bothering you ... possibly explaining packet path through different layers of ROS and indicate where "you get lost".

Buckeye · Thu Apr 13, 2023 8:53 pm

I did read the article and watch the video both of which were very helpful, so thanks for that. Although it didn't seem to help in answering my original query regarding frames tagged with a VLAN coming in on the WAN not being seen on the LAN. The reason I mentioned ROAS is because it's a scenario where a frame would be received on a VLAN, need to be decapsulated, and then routed elsewhere which is also what I believe would happen in my original scenario (e.g. come in via WAN tagged VLAN 100, go to Eth interface and then to routing engine, told to go to LAN).

First principle: L2 headers (ethernet in this case) are stripped when received by a router. A new set of L2 headers is applied when the ip packet is sent out the next interface.
Second principle: vlan headers are part of L2 (although some refer to them as layer 2.5)

If they were not removed, the packet received would have all the l2 headers from all the networks it passed though, and that is not the case.

This video doesn't discuss vlans, or explain how host obtain addresses and routing info via dhcp, but it does discuss traffic within networks (L2 switching/bridging) and traffic between networks (L3 ip routing). It's long, but if you pay attention, it goes into details many videos do not. It covers three tables: 1: mac address table used by switches to tie switch-ports to/from mac addresses. 2: arp cache used to tie mac addresses to/from ip addresses. 3: routing table to tie ip addresses to/from interfaces.

You need to understand these 3 tables to understand networking fundamentals. The video is the summary of the Networking Fundamentals videos. So if something doesn't make sense, you can go to a previous video for more information. Here is the link to the final summary video of the series: How Data moves through the Internet - Networking Fundamentals

p.s. when quoting a post, you can edit out the parts that are not related. quoting is primarily so you can indicate what you are responding to, especially when there are other posts between the new post and what you are responding to, so the correct context is clear.

Tagged VLANs not needing Untagged interfaces

Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Re: Tagged VLANs not needing Untagged interfaces

Who is online