NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. Simple router-on-a-stick: /interface vlan add name=vlan10 vlan-id=10 interface=ether1 then /ip address add address=192.168.10.1/24 interface=vlan10
2. GUI: Interfaces → VLAN → + → *Name*, *VLAN ID*, *Interface*.
3. On a switch/bridge, use bridge VLAN filtering instead: /interface bridge set bridge1 vlan-filtering=yes, /interface bridge vlan add bridge=bridge1 vlan-ids=10 tagged=bridge1,ether1 untagged=ether3, and set /interface bridge port set [find interface=ether3] pvid=10.
4. Verify: /interface bridge vlan print

Gotchas & notes

• Enable vlan-filtering=yes last, after the tagged/untagged lists are correct. Turning it on first is the classic way to lock yourself out of a MikroTik, because your management VLAN stops being carried the instant filtering starts.
• If you put an IP on the bridge and use VLAN filtering, the bridge itself must be in the tagged= list for that VLAN, otherwise the router cannot talk on it.
• Do not mix the two models on the same ports: a /interface vlan sub-interface on top of a VLAN-filtering bridge behaves in ways that are hard to reason about. Pick per-port switching (bridge VLAN) or router-on-a-stick.
• On CRS switches, hardware offload of bridge VLAN filtering depends on the switch chip; certain combinations silently fall back to CPU switching and destroy throughput. Check /interface bridge port print for the H (hardware offload) flag.
• Have a serial console or a second path before touching VLAN filtering on a remote device.

Steps

1. GUI: Network → Interfaces → Create New → Interface → *Type* VLAN, *Interface* = parent port, *VLAN ID* 10, then set the IP and Administrative Access.
2. CLI: config system interface → edit "vlan10" → set type vlan → set interface "port2" → set vlanid 10 → set ip 192.168.10.1 255.255.255.0 → set allowaccess ping → next → end
3. Verify: get system interface physical

Gotchas & notes

• The parent interface can still have its own IP for untagged traffic, but mixing tagged and untagged on the same port is a frequent source of confusion — prefer a dedicated parent with no address.
• Each VLAN interface is a separate interface for policy purposes: new VLAN means new firewall policies, and (unless you use a zone) no traffic flows at all.
• Group VLANs into a Zone (Network → Zones) to write one policy for many VLANs. Enable *Block intra-zone traffic* deliberately — the default allows VLANs in a zone to talk freely.
• Do not forget outbound NAT: the new VLAN needs a policy with the NAT toggle enabled to reach the internet.

Steps

1. Settings → Networks → Create New Network → *Name*, set VLAN ID 10, *Gateway IP/Subnet* 192.168.10.1/24, DHCP settings.
2. Tag it on switch ports: Devices → <switch> → Ports → <port> → set the *Native VLAN / Network* and the *Tagged VLANs* (or apply a Port Profile).
3. For Wi-Fi, attach the network to an SSID under Settings → WiFi.
4. Save; devices reprovision.

Gotchas & notes

• UniFi does the VLAN in one place and propagates it — genuinely the easiest of the six, provided every switch in the path is UniFi.
• The All/Allow All port profile trunks every VLAN, which is convenient and also means new VLANs appear on ports you did not intend. Build explicit port profiles for anything sensitive.
• A non-UniFi switch in the middle must be configured manually to trunk the VLAN; the controller has no visibility and the network simply does not work on the far side.
• Changing a port profile reprovisions the switch and can bounce the port — including the one carrying your management traffic.

Steps

1. On a switch: vlan 10 → name USERS → exit, then interface Vlan10 → ip address 192.168.10.1 255.255.255.0 → no shutdown
2. Trunk the uplink: interface Gi1/0/24 → switchport mode trunk → switchport trunk allowed vlan 10,20,30
3. Router-on-a-stick sub-interface: interface Gi0/0.10 → encapsulation dot1Q 10 → ip address 192.168.10.1 255.255.255.0
4. Verify: show vlan brief, show interfaces trunk

Gotchas & notes

• encapsulation dot1Q <id> must come before the IP address on a sub-interface, and the parent physical interface must be no shutdown — the sub-interface inherits its state.
• switchport trunk allowed vlan 10 replaces the allowed list. Use switchport trunk allowed vlan add 10 to append, or you will cut every other VLAN off that trunk in one command. This is a genuine outage-causer.
• Creating an SVI does not create the VLAN — vlan 10 in the database is a separate step, and show vlan brief is the check.
• The native VLAN must match on both ends of a trunk or untagged traffic lands in the wrong VLAN; show interfaces trunk shows the native VLAN per port.
• On a router (not switch), Gi0/0.10 sub-interfaces are the way; switchport commands do not exist there.

Steps

1. Network → Interfaces → Ethernet → set the parent (e.g. ethernet1/2) to *Layer3*.
2. Click Add Subinterface → set the *Interface Name* suffix and the Tag to 10.
3. Assign the sub-interface its own Virtual Router, Security Zone, and IPv4 address.
4. Commit.
5. Verify: show interface ethernet1/2.10

Gotchas & notes

• The Tag field and the sub-interface number are separate values and PAN-OS does not require them to match — but making them match (ethernet1/2.10 with tag 10) saves enormous confusion later.
• Each sub-interface needs its own zone and VR assignment; inheriting from the parent does not happen.
• The parent Layer3 interface handles untagged traffic. If it has no zone, untagged frames are dropped silently, which is usually what you want.
• New zone means new security policies — and remember the default interzone-deny applies, so nothing flows until you write them.

Steps

1. Interfaces → VLANs → Add → *Parent Interface*, *VLAN Tag* 10, *Description*.
2. Interfaces → Interface Assignments → Add → select the new VLAN 10 on em0 entry to create e.g. OPT1.
3. Interfaces → OPT1 → Enable, name it, set the static IPv4 address.
4. Add firewall rules on the new interface tab, and a DHCP server if needed.
5. Apply Changes.

Gotchas & notes

• It is a strict three-step sequence: create the VLAN, assign it as an interface, then configure it. People stop after step one and cannot find the VLAN anywhere else in the GUI.
• The new interface starts with no firewall rules, so it blocks everything including DNS to the firewall. Copy the rules you need from LAN.
• The parent NIC does not need an IP and generally should not have one when it is a pure trunk.
• Some cheap NICs mishandle VLAN tags with hardware offload enabled — if tagged traffic misbehaves, disable hardware VLAN tagging in System → Advanced → Networking.
• Outbound NAT in Automatic mode picks up the new subnet on its own; in Manual mode you must add the rule.

Steps

1. GUI: Network → Interfaces → Add Interface → *Interface Type* VLAN → *VLAN Tag* 10 → *Parent Interface* = the physical port carrying the tag (e.g. X0) → set *Zone*, *IP Assignment* Static, and the IP/mask → OK.
2. CLI: configure → interface X0.10 → zone LAN → ip assignment static → ip address 192.168.10.1 → ip subnet-mask 255.255.255.0 → exit → commit. (VLAN sub-interfaces are addressed as <parent>.<vlan-id>, e.g. X0.10.)
3. Verify: Network → Interfaces lists the new VLAN interface nested under its parent port; CLI show interface X0.10.

Gotchas & notes

• The parent physical port cannot be a member of a PortShield group when you add a VLAN sub-interface to it — PortShield-grouped ports are treated as one flat, untagged interface. You must remove the port from PortShield first, which is easy to miss if you started from a TZ appliance's default PortShield config.
• A new VLAN interface gets no Access Rules automatically, even between it and its own parent zone — you'll add the interface, confirm it's up, and then wonder why nothing routes until you write rules.
• SonicWall's own admin guides show VLAN creation almost exclusively via the GUI; the CLI path works for straightforward cases but is far less exercised in practice, so double-check behavior on your exact 7.3.x build rather than assuming full parity.
• Unlike RouterOS's bridge-VLAN-filtering model, there's no separate 'VLAN table' to maintain — each tagged VLAN is just its own interface object, closer to the Cisco/Fortinet sub-interface style.

Steps

1. GUI (Insight, centralized): Insight portal → Organization → Network → VLAN (or the Location's network tab) → define VLAN ID + name once, then push it to member switches/APs/routers via each device's port/SSID profile.
2. GUI (local switch, standalone or advanced config): VLAN → 802.1Q VLAN → Advanced → VLAN Configuration → add the VLAN ID, then VLAN Membership to mark ports Tagged/Untagged and set PVID.
3. CLI, Smart Switch Lite CLI: vlan database → vlan 10 → exit → interface gi1/0/1 → vlan pvid 10 → vlan tagging 10.
4. CLI, fully-managed M4200/M4300 (Cisco-IOS-like): vlan database → vlan 10 → exit → interface vlan 10 (creates the routed VLAN interface) or, on a trunk port, interface gi1/0/1 → switchport mode trunk → switchport trunk allowed vlan add 10.

Gotchas & notes

• Insight-managed routers and Orbi Pro APs have no CLI at all — VLAN tagging on a router's WAN/LAN side, or mapping an SSID to a VLAN on an AP, can only be done inside the Insight app; there is no fallback if the portal is down.
• Insight's central VLAN object is the closest thing NETGEAR has to 'define once, push everywhere,' but it only reaches devices actually claimed into that Insight network — a switch left in standalone mode needs the VLAN created locally too, and the two VLAN databases don't sync.
• There's no RouterOS-style bridge-VLAN-filtering table here — VLANs behave as ordinary IEEE 802.1Q port tagging, closer to the Cisco/Fortinet mental model than MikroTik's.
• Lite CLI's VLAN command set is intentionally stripped down — voice-VLAN auto-assignment, private VLANs, and L3 VLAN interfaces are either GUI/Insight-only or simply unavailable on Smart Switches.