NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. Access port (untagged VLAN 10): /interface bridge port set [find interface=ether3] pvid=10 and add ether3 to untagged= for VLAN 10 in /interface bridge vlan.
2. Trunk port: add the port to tagged= for each VLAN — /interface bridge vlan set [find vlan-ids=10] tagged=bridge1,ether1
3. Restrict what a port accepts: /interface bridge port set [find interface=ether3] frame-types=admit-only-untagged-and-priority-tagged
4. Verify: /interface bridge vlan print and /interface bridge port print detail

Gotchas & notes

• MikroTik has no 'access' or 'trunk' mode — you express it with pvid plus the tagged/untagged lists, and consistency between the two is on you. An untagged port that is not in the untagged= list will still tag frames on egress.
• frame-types is the real access/trunk enforcement: admit-only-untagged-and-priority-tagged for access ports, admit-only-vlan-tagged for trunks. Leaving the default admit-all lets a client inject tagged frames — a VLAN-hopping risk.
• Every VLAN you want to switch must be listed in /interface bridge vlan. A VLAN missing from that table is dropped once vlan-filtering=yes is on.
• The management path must be preserved: include the bridge in tagged= for your management VLAN before enabling filtering.

Steps

1. FortiGate itself: ports are routed, not switched — a 'trunk' is just a parent interface carrying VLAN sub-interfaces (see the VLAN task). No access/trunk mode exists.
2. For hardware/software switch ports: Network → Interfaces → the *Hardware Switch* / *Software Switch* member list.
3. For FortiSwitch managed by the FortiGate (FortiLink): WiFi & Switch Controller → FortiSwitch Ports → set *Native VLAN* and *Allowed VLANs* per port.
4. CLI (FortiSwitch): config switch-controller managed-switch → edit <serial> → config ports → edit "port5" → set vlan "users" → set allowed-vlans "voice" → next → end → end

Gotchas & notes

• A bare FortiGate is a router with many ports, not a switch. Expecting switchport-style commands is a category error — you use VLAN sub-interfaces instead.
• With FortiLink-managed FortiSwitches, *Native VLAN* is the untagged VLAN (Cisco's 'native') and *Allowed VLANs* are the tagged ones. The FortiGate owns that config; changing it on the switch directly is overwritten.
• Hardware switch interfaces (internal) on desktop models cannot be split without breaking the switch group, and doing so requires removing all references first.
• Untagged and tagged traffic on the same port works, but the untagged VLAN is handled by the parent interface — verify which zone/policy that lands in.

Steps

1. Devices → <switch> → Ports → <port> → Edit.
2. Set the Native VLAN / Network (the untagged VLAN) and choose the Tagged VLAN Management: Allow All, Block All, or a custom list.
3. For consistency across many ports, build a Port Profile under Settings → Profiles → Port Profiles and apply it.
4. Save; the switch reprovisions the port.

Gotchas & notes

• The default profile is usually All, which is a trunk carrying every VLAN. Ports you think are access ports are frequently trunks with a native VLAN — check before blaming the client.
• 'Native VLAN' here means untagged, matching Cisco's terminology; UniFi does not use PVID language.
• Applying a port profile that omits your management VLAN to the switch's uplink port disconnects the switch from the controller and requires a physical reset. Verify uplink ports are excluded.
• Port Profiles are the right abstraction: editing 24 ports individually is how inconsistencies creep in.

Steps

1. Access port: interface Gi1/0/5 → switchport mode access → switchport access vlan 10 → spanning-tree portfast
2. Trunk port: interface Gi1/0/24 → switchport trunk encapsulation dot1q → switchport mode trunk → switchport trunk allowed vlan 10,20 → switchport trunk native vlan 999
3. Verify: show interfaces trunk, show interfaces Gi1/0/5 switchport
4. Save: copy running-config startup-config

Gotchas & notes

• switchport trunk allowed vlan 10 replaces the whole list — use add/remove to modify it. This one command has caused more accidental outages than any other on this page.
• Leaving switchport mode dynamic auto (the default on some platforms) means DTP decides the port's mode, which can turn a user port into a trunk. Always set the mode explicitly.
• Set the native VLAN to an unused ID (e.g. 999) on trunks and never leave it as VLAN 1 — untagged traffic landing in VLAN 1 is both a security and a troubleshooting problem.
• spanning-tree portfast on access ports avoids a 30-second forwarding delay; never apply it to a port that could connect to another switch (use bpduguard alongside it).
• show interfaces <port> switchport prints the operational mode, which can differ from the configured mode — read that, not the config.

Steps

1. PAN-OS firewalls are not switches. There is no access/trunk port concept.
2. For tagged traffic, create Layer 3 sub-interfaces with a Tag (see the VLAN task).
3. To bridge Layer 2 segments, use *Layer2* interface type plus a VLAN object (Network → VLANs) and optionally a VLAN interface for routing.
4. Commit after any of the above.

Gotchas & notes

• Layer2 mode on PAN-OS exists mainly for transparent/virtual-wire style deployments, not for building an access layer. Do not plan to use a firewall as a switch.
• Virtual Wire is the other L2-ish option: it bumps traffic between two interfaces with inspection but no MAC learning or VLAN switching.
• If you need switching, that is a separate device — put the firewall on a trunk from a real switch.

Steps

1. pfSense is a router/firewall, not a switch — no access/trunk port modes.
2. Tagged VLANs on an interface: Interfaces → VLANs (see the VLAN task).
3. To bridge interfaces at L2: Interfaces → Bridges → Add (performance is CPU-bound and not a substitute for a switch).
4. Some Netgate appliances include an onboard switch chip configurable under Interfaces → Switches.

Gotchas & notes

• Bridging interfaces in pfSense to emulate a switch works but forwards in software; throughput and latency are far worse than a $50 managed switch. Do not design around it.
• On appliances with a switch chip (e.g. some SG models), Interfaces → Switches → VLANs configures the chip and is the only place port VLAN membership exists — it is separate from Interfaces → VLANs, and confusing the two is common.
• For everything else, trunk from a managed switch into a single pfSense NIC and do the VLANs there.

Steps

1. SonicWall has no literal 'switchport mode access/trunk' setting — the equivalent is done through PortShield. Access-style port: GUI Network → Interfaces, edit the parent interface's *PortShield* tab (or edit the member port) and add the physical port to the PortShield group — it now carries one untagged subnet/zone, like an access port.
2. Trunk-style port: leave the physical port OUT of any PortShield group, then stack tagged VLAN sub-interfaces on it (see the VLAN task) for however many VLANs need to ride that uplink to a core switch. There is no separate 'native VLAN' checkbox — if you also want untagged traffic on that same wire, give the physical parent interface itself an IP/zone alongside the tagged VLAN sub-interfaces.
3. CLI (PortShield membership): configure → interface X3 → portshield-to X2 → exit → commit (makes X3 an access-style member of the X2 PortShield group).
4. Verify: Network → Interfaces, PortShield groups show their member ports; a port with VLAN sub-interfaces shows them nested underneath it in the same table.

Gotchas & notes

• This is the biggest terminology trap for anyone coming from Cisco/Fortinet (access/trunk/native VLAN) or the standards camp (untagged/tagged/PVID): SonicWall uses neither vocabulary. Think 'PortShield membership = access', 'standalone port + VLAN sub-interfaces = trunk'.
• You cannot mix an access-style port and a tagged trunk on the *same* PortShield group — PortShield groups are all-or-nothing untagged. To free one port for trunking, remove just that port from the group rather than disbanding it.
• On TZ-series boxes the factory default often has most LAN ports PortShielded together into X0 already, which is convenient for plug-and-play but means your first VLAN trunk uplink usually requires un-PortShielding a port before it will accept tags.
• Full L2 feature depth (per-VLAN spanning tree, storm control, etc.) is limited compared to a dedicated managed switch — SonicWall's PortShield is explicitly a firewall-appliance convenience feature, not a switch fabric.

Steps

1. GUI (Insight): select switch → Ports → choose a port → set *Untagged VLAN* and *Tagged VLAN(s)* — Insight always uses untagged/tagged language, never 'access' or 'trunk.'
2. GUI (local switch): VLAN → 802.1Q VLAN → VLAN Membership shows a per-VLAN grid with U (untagged) / T (tagged) / blank per port; PVID is set separately under VLAN → Port PVID Configuration.
3. CLI (M4200/M4300): interface gi1/0/1 → switchport mode access or switchport mode trunk → switchport access vlan 20 or switchport trunk allowed vlan add 10,20 plus switchport trunk native vlan 1 — this line genuinely uses Cisco's access/trunk/native terms.
4. CLI (Smart Switch Lite CLI): back to untagged/tagged/PVID phrasing, e.g. vlan pvid 20 then vlan tagging 10 on the port.

Gotchas & notes

• NETGEAR straddles both terminology camps within the same product line: the GUI (Insight and local, on every switch) always speaks untagged/tagged/PVID, but the M4200/M4300 CLI speaks Cisco access/trunk/native — so on that one switch you translate GUI-speak to CLI-speak on the same box.
• There's no single 'make this an access port' button in the local GUI — an access port is just a port whose only VLAN membership is one untagged VLAN, configured the same way as any other untagged membership.
• Default PVID on an unconfigured port is VLAN 1, and the port starts as an untagged member of VLAN 1. Add a tagged VLAN without removing the port from VLAN 1's untagged set and you get a silent hybrid port, not a clean trunk — unlike Cisco's switchport mode trunk, nothing here automatically strips the untagged VLAN for you.