NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: Bridge → Hosts
2. CLI: /interface bridge host print
3. Find one MAC: /interface bridge host print where mac-address="AA:BB:CC:DD:EE:FF"
4. On switch-chip models also check /interface ethernet switch host print

Gotchas & notes

• There are potentially two tables: the software bridge host table and the switch-chip host table. On CRS/CSS hardware the chip table is the authoritative one for offloaded traffic, and the bridge table may be incomplete.
• Entries have a local flag for the device's own MACs — do not mistake those for a connected client.
• Aging is a few minutes; a silent device disappears from the table while still being plugged in. Ping it first, then look.

Steps

1. For a FortiGate hardware/software switch: diagnose netlink brctl name host <switch-name>
2. For FortiLink-managed FortiSwitches: WiFi & Switch Controller → FortiSwitch Clients, or CLI diagnose switch-controller switch-info mac-table
3. ARP is often the more useful table: diagnose ip arp list

Gotchas & notes

• A routed FortiGate port has no MAC table for the segment beyond its own ARP cache — it only sees the next-hop MAC, not client MACs behind a switch.
• diagnose netlink brctl name host only applies when the ports are in a software/hardware switch interface.
• The FortiSwitch client view is the right tool in a FortiLink deployment and shows port, VLAN, and 802.1X state together.

Steps

1. Clients → search the MAC or IP → the client detail panel shows the uplink device and port.
2. Or Devices → <switch> → Ports → hover a port to see connected clients.
3. Insights → Known Clients for historical association.

Gotchas & notes

• This is UniFi's strongest feature: the controller correlates MAC → switch → port → VLAN → uplink chain and draws it, which no CLI platform does out of the box.
• Accuracy stops at the first non-UniFi switch: everything behind a dumb switch shows on the same port.
• The topology view (Insights → Topology) is the fastest way to answer 'what is plugged in where' for a whole site.

Steps

1. show mac address-table address AABB.CCDD.EEFF
2. By port: show mac address-table interface Gi1/0/5
3. By VLAN: show mac address-table vlan 10
4. Then check whether that port is an uplink: show cdp neighbors / show lldp neighbors

Gotchas & notes

• Cisco MAC format is dotted-triplet (aabb.ccdd.eeff), not colon-separated. Pasting a colon-separated MAC returns nothing and looks like the device is absent.
• The standard hunt is: show ip arp <ip> to get the MAC, then show mac address-table address <mac> to get the port, then show cdp neighbors on that port to see if it is another switch and repeat.
• Default MAC aging is 300 seconds, versus a 4-hour ARP cache. A MAC absent from the table while ARP still has it means the device has been quiet, not gone.
• A MAC appearing on multiple ports or flapping between them indicates a loop or a duplicate MAC — check show spanning-tree before anything else.

Steps

1. Only meaningful for Layer2/VLAN deployments: show mac all
2. Per interface: show mac interface ethernet1/2
3. For Layer3 deployments use show arp all instead.

Gotchas & notes

• On a normal Layer 3 firewall the MAC table is empty or trivial — this is not the tool for finding a device on the network.
• Use the ARP table to get the MAC, then go to your switches to find the port. The firewall cannot answer the port question.
• show mac all is populated in Layer2 or VLAN-interface deployments only.

Steps

1. Diagnostics → ARP Table gives IP ↔ MAC ↔ interface (not a switch port).
2. If bridging: Status → Interfaces, or CLI ifconfig bridge0 addr for the bridge's learned MACs.
3. For appliances with a switch chip: Interfaces → Switches → Ports.

Gotchas & notes

• pfSense can tell you the MAC and which of its own interfaces the device is behind, but not which switch port — that answer lives on the switch.
• The ARP table's hostname column (from DHCP leases) is usually enough to identify the device without needing the port.
• On a bridge, ifconfig bridge0 addr lists learned MACs per member interface, which is the closest equivalent to a CAM table.

Steps

1. There is no Cisco-style dynamic MAC-address-to-port (CAM) table in SonicOS. The closest available data is the ARP cache, which maps IP↔MAC, not MAC↔port: GUI Network → ARP, or CLI show arp-cache.
2. PortShield port status (Network → Interfaces, PortShield group view) shows per-port link state and traffic counters, but not a list of learned MAC addresses per port.
3. Workaround: to physically trace a device, find its IP-to-MAC mapping on the SonicWall's ARP table, then trace that MAC to a physical port on the actual upstream managed switch, since the SonicWall itself doesn't record that association.

Gotchas & notes

• SonicWall NGFWs (including PortShield-capable TZ/NSa models) are firewall appliances first — the switch-like PortShield ports give you basic L2 grouping, not a real switching ASIC with a MAC learning table exposed to the admin.
• Anyone used to show mac address-table on a real switch (or even MikroTik's bridge host table) will not find an equivalent screen or command here — don't spend time hunting for one in the GUI menus.
• If MAC-to-port tracing is a recurring need, that's a strong signal the device downstream of the SonicWall should be a managed switch, with the SonicWall handling routing/firewalling only.

Steps

1. GUI (Insight, monitoring convenience): device → Clients or Ports tab may show a MAC/IP per port, but this is a cached client view, not the switch's live forwarding database.
2. GUI (local switch, ground truth): Switching → Monitoring → MAC Address Table (label varies slightly by model), filter/search by MAC address to see the learned port.
3. CLI (M4200/M4300): show mac-address-table or show mac-address-table address <mac-address>.
4. CLI (Smart Switch Lite CLI, where supported): the reduced monitoring command set includes an equivalent MAC-table show command, but availability varies by model and firmware — some Smart Switch SKUs have no SSH/console at all.

Gotchas & notes

• Routers, Orbi Pro APs, and the gateway/firewall side of this platform have no bridge/MAC-table concept — Insight's client list for those devices ties a MAC to an SSID/AP or a DHCP lease, never to a physical port, so 'which port is this MAC on' is strictly a switch question here.
• The Insight cloud client view lags behind reality (refresh/cache delay); for a live physical trace, the local switch GUI or CLI MAC table is the only thing to trust.
• Don't assume every Smart Switch has CLI access to check this — plenty of Smart Switch models are local-GUI-only, no Lite CLI, no SSH, no console; the real command-line MAC table is reliably available only on the M4200/M4300 line.