Developinggap named

Bridging & Switching (L2)

Nikita Tarikin runs MikroTik RouterOS bridging and VLAN switching in production — bridge VLAN filtering, tagged trunk and untagged access ports, inter-VLAN routing, and switch-chip VLAN offload on Cloud Router Switch hardware — verified by the MikroTik Certified Routing Engineer exam (MTCRE); the switching-engineer frontier above it — port-based access authentication, jumbo frames, and link aggregation — is studied to teaching depth but not yet deployed, ahead of the MikroTik Certified Switching Engineer certification (MTCSWE), which is not yet taken.

VLAN switching ships in production; the switching-engineer layer above it — port authentication, link aggregation, jumbo frames — is mapped a step ahead of where it runs. The map below marks which leaf is which.

4.1
Knowledge K̄: 3.7
Deployment Ē: 46
leaves mapped: 11
studied-ahead: 2
deployed-ahead

Verified by MTCNA 100%MTCRE 94%

The map

Every bridging and switching leaf in the official MikroTik curriculum, placed by what is known against what is run in production. A mark on the diagonal is a leaf where study and deployment reach the same depth; a mark below it is the daylight — studied ahead of production, named rather than hidden — and, on a couple of leaves, the rarer inversion where the bridge has been operated for years a notch ahead of its own textbook internals.

Read left-to-right as knowledge, bottom-to-top as deployment. The dense mass in the upper-right corner is the deployed switching base — bridge VLAN filtering, access and trunk ports, switch-chip offload, PoE, port mirroring, cable diagnostics — run in production. The comb of drop-lines below it is the switching-engineer layer: port authentication, link aggregation, jumbo frames — read closely, run thinly or not at all. Two short up-ticks above the diagonal mark the forwarding leaves deployed ahead of their theory.

The topography

The full leaf-level ledger, grouped by topic — from the L2 forwarding concepts and the RouterOS bridge model through VLANs, the switch chip and SwOS, link aggregation, PoE and the L2 security surface. Each row carries its own two verdicts — what is known and what is deployed — and the field note that earned them, quoted verbatim from the assessment, including the spanning-tree rows that read “never studied RSTP” and “defaults only.”

Leaf	Knowledge	Deployment	Field note
L2 Forwarding Concepts		K̄ 3.3 · Ē 4.3 · 3 leaves · 2 splits
Unicast / Multicast / Broadcast Forwardingdeployed ahead	2Aware	3Confident	Honest don't-know: 'don't know much about IGMP and multicast frames' (without snooping a bridge floods multicast like broadcast). Deployed IGMP-snooping for IPTV ~10yr ago (operational), but multicast theory is soft.
MAC Learningdeployed ahead	3Confident	5Teach	Source-MAC learning + host table = operational Teach (runs bridges expertly). BUT the unknown-unicast FLOODING fundamental isn't crisp — missed it twice (store-and-buffer, then CAM-overflow-redirect via the security lens; real = fail-open flood to all ports). Edge: flood-on-unknown-dest theory + classic CAM-overflow sniffing attack.
Interface Settings	5Teach	5Teach	Bridge port horizon = split-horizon (same-horizon ports don't forward to each other, still reach other-horizon ports).
RouterOS Bridge Overview		K̄ 5.0 · Ē 5.0 · 3 leaves
Bridge Concepts & Settings	5Teach	5Teach	Bridge = one L2 domain; software bridging CPU-bound unless hw-offloaded.
Bridge Port Management	5Teach	5Teach	Same bridge 'horizon' = split-horizon, ports don't forward to each other.
Wireless Bridging & Station Bridge	5Teach	5Teach	Station mode is 3-address; need station-bridge/WDS (4-address) to bridge.
Switch Chip Overview		K̄ 5.0 · Ē 5.0 · 2 leaves
Basic Switch Chips	5Teach	5Teach	A bridge port loses hw-offload when you enable a feature the ASIC can't do (e.g. bridge use-ip-firewall). Consistent with v1 switch-chip Teach.
Advanced CRS Series	5Teach	5Teach	HW VLAN offload CRS-gen-aware + multi-switch-chip gotcha
SwOS		K̄ 5.0 · Ē 3.0 · 3 leaves · 3 splits
Intro & Dual-Bootstudied ahead	5Teach	3Confident	SwOS = lightweight switch-only OS (simple web UI, pure L2); selected via the boot-os toggle/loader on dual-boot CRS — for plain switching without RouterOS overhead. Niche-but-known.
Install & Managementstudied ahead	5Teach	3Confident	SwOS key limitation: no CLI/scripting/API — web UI (+ SNMP) only; none of RouterOS's automation/firewall/routing.
L2 Feature Configurationstudied ahead	5Teach	3Confident	SwOS supports the switch-chip L2 set via web tabs: VLAN (port+tagged), LAG (static/LACP), RSTP, IGMP snooping, port isolation, basic QoS — no L3.
MTU		K̄ 5.0 · Ē 4.0 · 3 leaves · 1 split
MTU Settings	5Teach	5Teach	MTU=L3 payload, L2MTU=full L2 frame; VLAN tags / EoIP grow the frame so L2MTU must accommodate; bridge L2MTU = min of member ports.
Jumbo Frames & L2MTUstudied ahead	5Teach	2Aware	Bridge usable L2MTU = the smallest member's value (raise it on every port). Knowledge Teach; 'never experienced jumbo frames in real production but curious'.
Frame Issues	5Teach	5Teach	Ping+small ok, large transfers stall, no FCS errors = an L2MTU/MTU mismatch (full frames dropped, small pass). Lived troubleshooting.
VLANs		K̄ 4.8 · Ē 4.5 · 6 leaves · 2 splits
802.1Q Tagging	5Teach	5Teach	VLAN-filtering-bridge access-port config (pvid + untagged membership) nailed. Deploys VLANs.
RouterOS VLAN Interfaces	5Teach	5Teach	PVID classifies untagged ingress + the untagged-list strips the tag on egress; knows the management-lockout gotcha and chose a safe dedicated mgmt-port path. His production L2 strength
Port-Based VLAN Bridging	5Teach	5Teach	Access port pvid=10 + ingress-filtering + admit-untagged: untagged frames get VLAN 10, already-tagged frames dropped (access, not trunk).
Inter-VLAN Routing	5Teach	5Teach	Inter-VLAN on a CRS = IPs on the bridge VLAN interfaces, CPU routes between them (unless the chip does L3 HW offload, e.g. some CRS3xx).
Switch-Chip VLANs (Port / MAC / Protocol-Based)studied ahead	5Teach	4Fluent	HW VLAN offload slow-path trigger (non-chip member / hw=no -> CPU) nailed. Deploys CRS switches (confirms MTCSWE switch-chip strength).
QinQ (802.1ad)studied ahead	4Fluent	3Confident	VLAN/QinQ concept Fluent (MTCRE); switch-chip tag-stacking impl thinner (MTCSWE)
Spanning Tree		K̄ 2.0 · Ē 2.0 · 6 leaves
STP / RSTP Concepts	2Aware	2Aware	EDGE: honest don't-know -- 'never studied RSTP, never implemented, know nothing about edge ports'. WISP routed/PtP topologies avoid L2 loops by design
Bridge Priority	2Aware	2Aware	Wrong (picked 0–255 highest-wins; real = 4096 steps, lowest priority+MAC wins) + 'don't understand the real benefit/use-cases on STP port roles and priorities'.
Port Path Cost	2Aware	2Aware	Honest don't-know ('no idea') on the equal-cost tiebreak (lowest sender bridge-ID then port-ID, not hop count).
MSTP (Regions, CST/CIST)	2Aware	2Aware	never configured; doesn't know regions; unstudied edge. Spanning-tree family edge
BPDU	2Aware	2Aware	Recognized the BPDU fields (root/sender bridge-ID, root path cost, port-ID) but flagged 'don't fully understand the theory; my bridges are always on default settings, never touched STP configs'. (runs RSTP on defaults).
Spanning Tree Security	2Aware	2Aware	Part of the spanning-tree edge — its core feature (bpdu-guard) drew 'no idea' (see l2-security/bpdu-guard), and the batch-wide self-report is 'never configure STP, defaults only'. No dedicated question; assessed by inference.
Link Aggregation (Bonding / LAG)		K̄ 4.0 · Ē 3.0 · 3 leaves · 1 split
RouterOS Bondingstudied ahead	5Teach	2Aware	balance-rr reorders TCP segments (fast-retransmit/backoff) vs LACP per-flow hashing keeps a flow in order. Knows the tradeoff (Fluent); 'very low real experience with link aggregations in real'.
Bonding Modes	5Teach	5Teach	Teach-level reasoning: balance-rr is software/CPU-bound, 802.3ad LACP is HW-offloaded + per-flow-hash (not per-packet), saves switch CPU.
Static LAG Compatibility	2Aware	2Aware	Honest don't-know: 'no idea about static LAGs, very low real LAG experience'. The risk (no negotiation → silent black-hole onto a dead member) wasn't known.
Port Isolation		K̄ 4.5 · Ē 4.0 · 2 leaves · 1 split
Bridge Horizonstudied ahead	4Fluent	3Confident	bridge horizon (software) vs port isolation (HW-offloaded on CRS3xx, isolates within a VLAN). Theory-correct, 'never implemented, no real cases' -- vISP isolates at L3/PPP + wireless ACL.
Switch Port Isolation	5Teach	5Teach	Private-VLAN-style guest isolation in hardware = switch-chip port isolation profiles (isolated ports reach the uplink, not each other; ASIC-offloaded).
L2 Security		K̄ 3.6 · Ē 2.9 · 10 leaves · 3 splits
IGMP Snooping	4Fluent	4Fluent	forwards multicast only to joined ports, needs an IGMP querier; DEPLOYED (IPTV for parents on ROS6, ~10yr ago).
DHCP Snooping	3Confident	3Confident	DHCP snooping trusts designated ports vs rogue servers; Option 82 = relay-agent port/switch identity -- knows the concept, 'don't fully understand Opt82 in depth'. Confident
Loop Protectstudied ahead	4Fluent	3Confident	Reasoned correctly ('I guess'): loop-protect sends periodic probe frames; a port hearing its own probe back disables itself — a lightweight loop detector independent of STP.
Traffic Storm Controlstudied ahead	5Teach	3Confident	'Sure' + correct: broadcast-storm limiting = switch-chip ACL rule or bridge filter (RouterOS has no Cisco-style storm-control toggle). Flagged 'never configured the RouterOS switch menu subtree directly, only via bridge'.
L2 Firewall / Bridge Filter (switch-side)	4Fluent	4Fluent	use-ip-firewall=yes routes bridged traffic through the IP firewall -- the exact 'gap' he flagged, isn't one. CPU-path though (see the switch-ACL edge)
Switch ACL	2Aware	2Aware	EDGE: thought bridge filter is HW-accelerated on CRS3xx; actually wire-speed drops need the switch-chip ACL (switch rule), bridge filter runs on the CPU. Over-extended the VLAN-offload fact
BPDU Guard	2Aware	2Aware	Honest don't-know ('no idea') — bpdu-guard disables an edge/access port on receiving any BPDU (unauthorized switch). Part of the spanning-tree edge cluster.
ARP Modes (L2 security)	5Teach	5Teach	arp=reply-only stops dynamic ARP learning — only static IP/MAC pairs are answered, blocking ARP spoofing/rogue hosts. Security-engineer Teach.
Port Security	2Aware	2Aware	EDGE: didn't know the bridge-port learn-limit caps dynamic MAC learning (anti CAM/MAC-flooding port security)
802.1Xstudied ahead	5Teach	1Learning	'Sure' + correct: pre-auth only EAPOL reaches the authenticator/RADIUS, all else blocked until the port authorizes. BUT 'never ever experienced dot1x in real, never lab, never production; curious to lab at home soon, implement next year — already have RADIUS and trusted PKI' — knowledge ahead of deployment, prerequisites in place.
PoE		K̄ 5.0 · Ē 5.0 · 3 leaves
PoE Modes & Compatibility	5Teach	5Teach	Passive PoE has no detection/negotiation — applies voltage unconditionally, can damage a non-PoE device; injector voltage must match (vs negotiated 802.3af/at).
PoE Priority	5Teach	5Teach	When the PSU PoE budget is exceeded, poe-priority decides which ports keep power and which are shed first (lowest dropped first).
PoE Monitoring	5Teach	5Teach	poe-out-status=short_circuit = the controller detected a short on the output pair and cut power to protect the port/PSU — check cable/device.
L2 Diagnostics & Tools		K̄ 5.0 · Ē 5.0 · 2 leaves
L2 Diagnostics	5Teach	5Teach	cable-test 'open at 12m on pair B' = a TDR result locating a break ~12m down the cable (bad crimp/cut/unterminated).
Port Mirroring	5Teach	5Teach	Line-rate 10G capture = switch-chip port mirroring (mirror-source→mirror-target, hardware-cloned); a CPU sniffer would drop.

The edges

The lead edge is the switching engineer’s own syllabus. Port-based access authentication is held to teaching depth — the pre-authentication boundary, the RADIUS and certificate plumbing already standing in the network — yet it has never run in a lab or in production. Beside it sit link aggregation, where the round-robin and LACP trade-off is reasoned cold but the real-world hours are thin, and jumbo frames, understood to the byte yet never carried on a production link. Each of these is studied ahead of where it is deployed. The rarer direction runs the other way, on the two forwarding leaves where the bridges have been operated expertly for years while the unknown-unicast flooding and multicast theory stayed soft. Every gap below is quoted exactly as the assessment recorded it.

Knowledge ahead of deployment

Known deeper than it currently runs — named, not rounded over.

802.1Xknow 5 Teach→run 1 Learning
'Sure' + correct: pre-auth only EAPOL reaches the authenticator/RADIUS, all else blocked until the port authorizes. BUT 'never ever experienced dot1x in real, never lab, never production; curious to lab at home soon, implement next year — already have RADIUS and trusted PKI' — knowledge ahead of deployment, prerequisites in place.
Jumbo Frames & L2MTUknow 5 Teach→run 2 Aware
Bridge usable L2MTU = the smallest member's value (raise it on every port). Knowledge Teach; 'never experienced jumbo frames in real production but curious'.
RouterOS Bondingknow 5 Teach→run 2 Aware
balance-rr reorders TCP segments (fast-retransmit/backoff) vs LACP per-flow hashing keeps a flow in order. Knows the tradeoff (Fluent); 'very low real experience with link aggregations in real'.
Intro & Dual-Bootknow 5 Teach→run 3 Confident
SwOS = lightweight switch-only OS (simple web UI, pure L2); selected via the boot-os toggle/loader on dual-boot CRS — for plain switching without RouterOS overhead. Niche-but-known.
Install & Managementknow 5 Teach→run 3 Confident
SwOS key limitation: no CLI/scripting/API — web UI (+ SNMP) only; none of RouterOS's automation/firewall/routing.
L2 Feature Configurationknow 5 Teach→run 3 Confident
SwOS supports the switch-chip L2 set via web tabs: VLAN (port+tagged), LAG (static/LACP), RSTP, IGMP snooping, port isolation, basic QoS — no L3.
Traffic Storm Controlknow 5 Teach→run 3 Confident
'Sure' + correct: broadcast-storm limiting = switch-chip ACL rule or bridge filter (RouterOS has no Cisco-style storm-control toggle). Flagged 'never configured the RouterOS switch menu subtree directly, only via bridge'.
Switch-Chip VLANs (Port / MAC / Protocol-Based)know 5 Teach→run 4 Fluent
HW VLAN offload slow-path trigger (non-chip member / hw=no -> CPU) nailed. Deploys CRS switches (confirms MTCSWE switch-chip strength).
QinQ (802.1ad)know 4 Fluent→run 3 Confident
VLAN/QinQ concept Fluent (MTCRE); switch-chip tag-stacking impl thinner (MTCSWE)
Bridge Horizonknow 4 Fluent→run 3 Confident
bridge horizon (software) vs port isolation (HW-offloaded on CRS3xx, isolates within a VLAN). Theory-correct, 'never implemented, no real cases' -- vISP isolates at L3/PPP + wireless ACL.
Known
horizon/isolation theory solid
Run
limited production use
Loop Protectknow 4 Fluent→run 3 Confident
Reasoned correctly ('I guess'): loop-protect sends periodic probe frames; a port hearing its own probe back disables itself — a lightweight loop detector independent of STP.

Deployed ahead of the textbook

Run in production a notch beyond the studied internals — the rarer direction.

MAC Learningknow 3 Confident→run 5 Teach
Source-MAC learning + host table = operational Teach (runs bridges expertly). BUT the unknown-unicast FLOODING fundamental isn't crisp — missed it twice (store-and-buffer, then CAM-overflow-redirect via the security lens; real = fail-open flood to all ports). Edge: flood-on-unknown-dest theory + classic CAM-overflow sniffing attack.
Unicast / Multicast / Broadcast Forwardingknow 2 Aware→run 3 Confident
Honest don't-know: 'don't know much about IGMP and multicast frames' (without snooping a bridge floods multicast like broadcast). Deployed IGMP-snooping for IPTV ~10yr ago (operational), but multicast theory is soft.

The warrant

Third-party verification of the bridging and VLAN depth above — and the switching-engineer credential recorded as still ahead of the work, not behind it:

MTCNAVerified — 100%, Network Associate
MTCREVerified — 94%, Routing Engineer
MTCSWESwitching Engineer — in progress / not yet taken

Layer 2 does not end at the bridge. Where switching connects:

The questions

Do you deploy VLAN switching on RouterOS in production?

Yes — bridge VLAN filtering, access and trunk ports, inter-VLAN routing, and switch-chip VLAN offload on Cloud Router Switch (CRS) hardware are daily production ground, verified by MTCRE (MikroTik Certified Routing Engineer). The switching-engineer frontier above it — 802.1X port authentication, jumbo frames, link aggregation — is studied but not yet deployed. The mechanics of what I run, publicly: in RouterOS 7 the modern, recommended way to switch VLANs is bridge VLAN filtering — setting vlan-filtering=yes turns the bridge into a VLAN-aware switch, and the bridge VLAN table declares which ports carry each VLAN tagged versus untagged. An access port takes a pvid that tags untagged ingress; ingress-filtering=yes (the default since v7) drops a frame whose VLAN the ingress port is not a member of. The gotcha I always sequence around: enabling vlan-filtering before adding the CPU/management port as a tagged member of the management VLAN locks you out of the device — so the management path goes in first.

Do you run 802.1X port authentication?

No — this is the lead edge of the map. 802.1X (the IEEE standard for port-based network access control) I hold at teaching depth: I can place the pre-authentication boundary and the design, and the prerequisites — a RADIUS server and a trusted certificate authority — already run in my network, but I have never stood it up in a lab or in production. It is on the build-out roadmap, not in the deployed column. Publicly: RouterOS implements it as /interface dot1x and can act as both authenticator and supplicant (with the User Manager package it can even be the RADIUS server itself). An authenticator port blocks all traffic except EAPOL — EAP over LAN — until the client authenticates, so a rogue device cannot even pull a DHCP lease before proving identity; once authorized the port passes traffic, and a Mikrotik-Switching-Filter RADIUS attribute can pin acceptance to the authenticated MAC address. I lab it before I bill it — that ordering is the point of this page.

Can you build a LACP bond or run jumbo frames?

I can design both; my deployed hours are thin, so I name them as studied-ahead rather than production-proven. The trade-off I hold cold, publicly: RouterOS link aggregation is /interface bonding. The default balance-rr (round-robin) is the only mode that stripes a single TCP connection across several links, which reorders segments and provokes retransmission; 802.3ad — LACP, dynamic link aggregation — instead keeps each flow on one member by hashing the headers (transmit-hash-policy), and only LACP, balance-xor and active-backup are hardware-offloaded — the rest fall to the CPU. For jumbo frames, the usable bridge l2mtu is the smallest member port’s value, so every port along the path must be raised together or large transfers stall silently while pings still pass. I know the mechanics; the production mileage is the part I name as thin.

How well do you know spanning tree — STP, RSTP, MSTP?

This is the thinnest part of my L2 stack, and I say so on the ledger above: I run RSTP on its defaults but have never tuned bridge priority, port path cost, or MSTP regions, and the BPDU internals I know only at recognition level. My production topologies are routed and point-to-point, so they avoid Layer-2 loops by design rather than leaning on a tuned spanning tree. The mechanics I do place, publicly: in RouterOS the bridge protocol-mode selects none, stp, rstp or mstp, defaulting to RSTP; plain STP is considered outdated and slow and is effectively replaced by RSTP, while MSTP is the VLAN-aware variant that can load-balance per VLAN group. Where a design genuinely needs engineered spanning tree, I will say where it sits against my deployed edge and lab it before I bill it.

Bring the switching problem.

If it is bridge VLAN filtering, trunk-and-access port design, inter-VLAN routing, or switch-chip offload on CRS hardware, that is ground I run in production. If it reaches into 802.1X, link aggregation, or engineered spanning tree, I will tell you where it sits against my deployed edge — and lab it before I bill it — before the work starts, not after.

Start the conversation