I’m working on a configuration where I have a bridge between an EoIP interface, and a VLAN interface. The VLAN interface is related to a master interface at which there is connected a UniFI antenna. The end goal is to have clients connected to the SSID of the UniFI to be tagged with the VLAN ID and to be bridged towards the EoIP interface (which provides its own DHCP server, etc.)
As of now the configuration works half way; indeed, I have a dedicated bridge where only the EoIP and VLAN interface are present. When a device connects to the UniFI, it receives an IP address that belongs to the pool of addresses at the other end of the EoIP. I can ping the outer internet and the devices on the EoIP LAN, however I can’t browse (nor internet, nor connect to devices on the EoIP LAN).
If you can ping even public addresses through the EoIP tunnel, it sounds like an MTU issue (if you haven’t forced the MTU of the EoIP interfaces to 1500, which is what the wireless clients probably expect) or a reassembly issue (if you have forced the MTU of the EoIP interfaces to 1500, so the size of the EoIP packets exceeds the usually available MTU on the underlying path and thus they get fragmented on sending). What MTU do the EoIP interfaces and the bridges they are connected to show?
If so, try attaching a DHCP client with add-default-route set to no to the bridge that joins the EoIP with the Ubnt-facing VLAN interface and try pinging the IP attached to the remote end of the EoIP tunnel with size=1500. Do you get responses?
Even if I add an address manually to the bridge, the interface goes from “RS” into “S” and I can’t ping the other end (by forcing the ping through the bridge itself)
You have posted only the export from the “local” end, so some information is missing; however, what is definitely wrong is that the VLAN interface VLAN20 is hooked to ether2 whilst ether2 is a member port of bridge bridge. Such an arrangement is incorrect and known to cause issues, so you have to set the interface of VLAN20 to bridge.
What IP address did you assign to Bridge_VLAN that made the tunnel fail?
It’s not adding the tagless end of VLAN20 as a member port of the bridge, it’s rooting the tagged end of VLAN20 in the bridge whose member port is ether2. So the frames tagged with VID 20 that ingress via ether2 will get to the tagged end of VLAN20 via bridge bridge and egress there, get untagged, ingress to bridge Bridge_VLAN, and egress via eoip-tunnel1.
They are not untagged by the bridge, they get from ether2 to the tagged end of the VLAN20 pipe still tagged. It’s the passage through VLAN20 that removes the tag. In the opposite direction, the tagless frame that arrives via eoip-tunnel1 passes through Bridge_VLAN to the tagless end of the VLAN20 pipe, gets tagged with VID 20 and emerges on bridge to get forwarder to ether2.
I did the test, but still I can’t browse nor internet websites nor sites hosted on local machines on the remote end.
Interesting info: on the remote side there is a DNS server (PiHole). If I query it using dig, I get the reply back. If I try to open the web interface, it does not work
We have to go step by step. So far I still have no other idea than fragmentation issues (the EoIP transport packets carrying a 1514-byte Ethernet frame are far bigger than 1500 bytes, so they have to be fragmented in order to pass through paths with L3 MTU of 1500, and if something is miscofnigured in your firewalls or somewhere in the ISP network between the two devices talking EoIP, the non-first fragments may get dropped, causing the complete packet to be dropped as it cannot be reassembled at the receiving side).
So first thing I need to see is the export from the remote end and the address you attempted to attach to the Bridge_VLAN. The goal is to understand why the EoIP goes down as you add the address (I suspect it attempts to send the EoIP transport packets as EoIP payload), fix that, and move on to testing the passage of large ping packets through the tunnel, using ping remote.ip.add.ress size=1500 do-not-fragment.
In the end I was able to get it working, after a full reset. I made some changes with respect to the previous try; one major aspect is that in this (working) configuration, the Mikrotik establishing the EoIP connection “lives” in the same subnet of the existing router that provides connectivity to the internet. In the previous config, the Mikrotik was set as a DHCP client (through WiFi bridge).
However, I still have few questions and doubts about the VLAN mechanisms in MikroTik.
I will attach here below the current (and working) configuration, but I wanted to start this post with some questions:
VLAN virtual interfaces
Does a virtual VLAN interface react only to packets tagged with the specific VLAN ID?
What happens when a properly tagged packet reaches a virtual VLAN interface? Does it get “untagged” by the interface, or does it preserve the 4bytes for VLAN identifier?
What happens when a virtual VLAN interface is bridged with another (non VLAN-ified) interface ? If we consider packets flowing from VLAN interface → “regular” port. Are the packets bridged? If yes, is the tag removed?
Still related to the above question: What happens if packets now need to travel from the “regular” port → VLAN virtual interface? Are the packets bridged? If yes, is the tag added?
Bridge VLAN filtering
What is the purpose of a Bridge-based VLAN filtering?
How does it complement / differentiate with respect to using the virtual VLAN interface?
When is better/suggested to use one approach over the other?
A VLAN interface is nothing more than a “pipe” whose one end (“tagless”) acts as an L2 interface itself and the other one (“tagged”) is attached to another L2 interface. When “something” (typically, the IP stack) sends a frame through the “tagless” end of the VLAN interface, the pipe adds a VLAN tag to it and sends it via the underlying interface; if a “properly tagged” frame (i.e. one carrying the VID the “pipe” is set to handle) arrives to the underlying interface, the pipe takes it, removes the tag, and outputs it to the connected IP stack tagless. Other than that, the pipe is dumb - it does not care whether the frame carries an IP packet, and IPv6 packet, or maybe an STP BPDU, or even an already tagged frame on the “tagless” end. So you can indeed bridge the tagless ends of two VLAN interfaces together and create a “short circuit” between two (or more) VLANs that way, or you can stack multiple VLAN tags by connecting the tagged end of one “pipe” to the taggless end of another one. Setups like these are only useful in very specific cases but they are technically possible.
With vlan-filtering set to no, the bridge is VLAN-agnostic; it only works with MAC addresses and ignores any eventual VLAN tags. So if a frame comes tagged on ingress, it stays tagged on egress. Setting vlan-filtering to yes makes the bridge VLAN-aware, which means you can define each port as an access/tagless member of a particular VLAN (so that tagless frames get tagged on ingress and untagged on egress through that port) or as a trunk/tagged member of a VLAN (so that tagged frames stay tagged). A frame can only egress through a port if that port is an access or trunk member of the VLAN the frame is tagged with. With ingress-filtering set to yes on a port, the port will even not accept an ingress frame if the VID in its tag doesn’t match one of the VLANs the port is a member of.
Nowadays, the VLAN interfaces do not serve as a substitution of VLAN filtering on a bridge any more. Normally, you use vlan filtering on a single common bridge, and only if you need the router itself to have access into a given VLAN on the bridge, you must attach a VLAN interface to the bridge. Years ago, when VLAN filtering was not available, you had to attach a VLAN interface to each physical interface you wanted to make a trunk port of the VLAN and bridge the tagless ends of the VLAN interfaces together, so you ended up with a dedicated bridge for each VLAN, but this approach is not compatible with the “normal” switches because if you use such a setup, you end up with a “PVST-”, i.e. a separate spanning tree for each VLAN controlled using the standard RSTP protocol.
Thanks a lot for the explanation! This makes a LOT of sense to me, now!
So, following your comments, the use of the bridge VLAN filtering could allow the creation of 1 bridge only, and- through a combination of PVIDs and VLAN table entries - could achieve the same result as creating different bridges and VLAN interfaces. Is my statement (at high level) correct?