Mikrotik stuff has plenty of its own quirks, I'll note them down here.
Contents
Bridging and VLANs
Bridging with VLANs is complicated on Mikrotik. I don't really get why there's /interface/vlan and /interface/bridge/vlan and why it matters, but it does. It's also important to note that this stuff can be hardware-offloaded, depending on the switch chip in your particular device. For this reason, you need to know what you've got, what you're doing, and whether you need to care about offload.
Aha, this explanation helps a lot! https://forum.mikrotik.com/viewtopic.php?t=173692&sid=c7f67d4cb39505bd9a25cf61b5dfefe8
The gist is that the bridge can be tagged because that's really the router-facing port on a bridge (a switch), if you had a switch connected to a router. A device hosting a bridge doesn't have to participate in the network above L2, but if you want it to, that's when it matters. So /interface/bridge/vlan ports are just about whether a port is tagged or untagged on the bridge, which affects how traffic floods across the bridge.
If you want the device to participate in the bridge, it has a "port" on the bridge as well - it's "the bridge", which is why you can apply tags to the bridge. In that case you tag it up, but there's nothing "attached to the port yet", it just has tags added/stripped when packets egress/ingress it.
That's when you define an /interface/vlan, and plop it on top of the bridge - much like how in Linux you can have eth0 and eth0.241, the latter is the tagged version of the underlying eth0 interface.
More thinking
Okay I've soooorta figured this out. For better or worse, Mikrotik makes you think much harder about what's actually happening at a per-port level when you start wrangling VLAN tags, particularly questions like "how do we treat incoming tagged/untagged packets?" and stuff like that.
This is a specific example of how I added an extra VLAN and subnet to my network, to act as a "management VLAN" between all the switches. This means that the VLAN is tagged on physical ports, and each switch has an IP address on that VLAN too.
I'm starting with fritia (a CRS304-4XG-IN) as she's a low-stakes device to reconfigure.
I used this for advice too: https://forum.mikrotik.com/t/vlan-passthrough-from-wan-port-to-lan-bridge-specific-port/166097/14
Define our VLAN and subnet
This will be:
- VLAN 11
- 192.168.11.0/24
- Devices will have the same last octet as in the normal (untagged) network, which is 192.168.1.0/24
Configure
Setup the bridge, this is already done because the device is already in use. Enable HW offloading on all the bridge ports too: https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-Example.2
I've configured the physical ethernet ports ahead of time too, as shown here. It's a 10G switch so I want my jumbo frames!
/interface ethernet set [ find default-name=ether1 ] l2mtu=9092 mtu=9014 comment=uplink set [ find default-name=ether2 ] l2mtu=9092 mtu=9014 set [ find default-name=ether3 ] l2mtu=9092 mtu=9014 set [ find default-name=ether4 ] l2mtu=9092 mtu=9014 comment=wa-chan # The admin-mac is copied from ether1, to ensure a consistent and # sensible externally-visible MAC address. # We leave vlan-filtering disabled for now so we don't accidentally lock ourselves out # while configuring things. /interface bridge add admin-mac=F4:1E:57:AB:CD:EF auto-mac=no name=bridge vlan-filtering=no
Slap a VLAN onto the whole bridge, it doesn't do anything yet though. This is like an SVI in Arista EOS, at layer 3:
/interface vlan add name=VLAN11_MGMT vlan-id=11 interface=bridge mtu=9014
A VLAN interface is a tagged version of the underlying interface, so give it an IP address
/ip address add address=192.168.11.4/24 interface=VLAN11_MGMT
Update your bridge ports, you're just assigning PVIDs for ports that are members of a bridge. In this case we don't need to as the PVID specifies what VLAN to assign untagged ingress traffic to, and we'll never have any untagged ports for this VLAN.
/interface bridge port set [ find interface="ether3" ] pvid=11
Finally we define VLAN tagging on bridge-ports, in a somewhat counterintuitive manner. This defines "physical" tagging of the ports. Any untagged ports here will govern what happens on egress.
Generally you want the bridge tagged for a given VLAN ID as well. If you don't want the bridge's mgmt VLAN to be reachable via a particular interface, make sure the mgmt VLAN isn't tagged on that physical interface. Eg: https://help.mikrotik.com/docs/spaces/ROS/pages/122388482/Wireless+VLAN+Trunk
/interface bridge vlan add bridge=bridge vlan-ids=11 tagged=bridge,ether1
Now enable filtering on the bridge so it does something useful, and we've configured things so we don't lose access to the switch immediately.
/interface bridge set bridge vlan-filtering=yes
Explaining it another way
The other way of putting this together inverts the ordering, as on the Mikrotik "Bridging and Switching - InterVLAN Routing by Bridge" example.
- Create the bridge (already done usually)
- Add your bridge ports ("etherN"), defining the pvid and admitted-frame-types from each port
- Add bridge vlan entries to define VLAN IDs and tag them on the bridge itself. In effect we're stretching the (existing pvid) VLANs onto the bridge itself, it'll receive VLAN-tagged packets from the attached ports
- Add interface-VLANs on the bridge, one per VLAN - this is the SVI bit in Arista EOS
- Assign an IP address to each interface-VLAN, now we're able to work at layer 3
- If the bridge is tagged-only, then you can set the bridge itself (this is really the implicit CPU interface on the bridge that you can assign an IP to) to only admit tagged frames
SFPs
If you've got one plugged in you can check it's info/stats.
{
:local iflist [find where default-name~"(sfp|combo|ether)"]
:foreach if in=$iflist do={
:local ifname [get $if name]
:local nicename [:pick "$ifname " 0 13]
:local ifmon [monitor $ifname once as-value]
:local sfppresent ($ifmon->"sfp-module-present")
:local sfpmodel ($ifmon->"sfp-vendor-part-number")
:if ($sfppresent = true) do={:put "$nicename --> $sfpmodel"} else={:put "$nicename --> <empty>" }
}
}You can just run this on the terminal. Here's an example from helena, where I've connected its SFP port to the Unifi switch for a 1G uplink trunk.
[furinkan@helena] > /interface/ethernet/
[furinkan@helena] /interface/ethernet> {
{... :local iflist [find where default-name~"(sfp|combo|ether)"]
{... :foreach if in=$iflist do={
{{... :local ifname [get $if name]
{{... :local nicename [:pick "$ifname " 0 13]
{{... :local ifmon [monitor $ifname once as-value]
{{... :local sfppresent ($ifmon->"sfp-module-present")
{{... :local sfpmodel ($ifmon->"sfp-vendor-part-number")
{{... :if ($sfppresent = true) do={:put "$nicename --> $sfpmodel"} else={:put "$nicename --> <empty>" }
{{... }
{... }
core-uplink --> <empty>
kalina --> <empty>
persica1 --> <empty>
persica2 --> <empty>
persica3 --> <empty>
sfp1 --> SFPP-PC015Also it turns out you can see all this in the Interfaces -> Ethernet list in Winbox, if you enable the Vendor columns for display. Duhhh, way easier. It's mildly annoying that it's not printed on the CLI when you run /interface/ethernet/print detail