Blog · July 14, 2026 · Knox Hutchinson
How to Find Which Switch Port a Device Is Plugged Into (the MAC Hunt)
- Step 0: Turn the IP Into a MAC
- Step 1: Ask the Core Where It Learned the MAC
- Step 2: Access Port or Uplink?
- Step 3: Hop to the Neighbor and Repeat
- Step 4: Land on the Access Port
- The Gotchas That Eat Your Afternoon
- The Same Hunt in About a Minute
- Frequently Asked Questions
The ticket says: “Find where this device is plugged in.”
Every network engineer knows this one. A host is misbehaving, or security wants it isolated, or someone is decommissioning a desk — and somebody has to figure out which physical switch port, in which closet, one MAC address lives on. If the network is documented, you’re lucky. If it isn’t — and it isn’t — you’re about to SSH into switches one at a time until you corner it.
Since we launched Transit AI, this is one of the most common stories trial users tell us: “how many afternoons of walking the MAC tables would this have saved me?” So here’s the whole playbook — the manual method first, properly, because you should know it cold. Then what it looks like when an investigation-only AI agent runs the same trace for you.
Step 0: Turn the IP Into a MAC
You usually start with an IP address, not a MAC. Switches don’t forward on IPs — you need the MAC, and the device that knows the mapping is the host’s default gateway (the L3 boundary for its VLAN).
Cisco IOS / IOS-XE:
show ip arp | include 10.20.4.87
Junos:
show arp | match 10.20.4.87
If the entry is missing, the host has been quiet: ping it once from the gateway to repopulate ARP, then look again. If the gateway does VRFs, remember to scope the lookup (show ip arp vrf CLIENT-A | include …).
Now you have something like a036.9f12.8a5c. Write it down in every format your fleet speaks — Cisco’s dotted triplets (a036.9f12.8a5c) and the colon form everyone else uses (a0:36:9f:12:8a:5c) — because you’ll be pasting it into dissimilar boxes for the next half hour.
Step 1: Ask the Core Where It Learned the MAC
Start at the switch closest to the gateway and ask its MAC address table:
Cisco IOS / IOS-XE:
show mac address-table address a036.9f12.8a5c
Junos:
show ethernet-switching table | match a0:36:9f:12:8a:5c
(Arista EOS and NX-OS both speak a show mac address-table address … dialect; the logic is identical everywhere.)
The output names a VLAN and an interface. That interface is the direction the switch learned the MAC from — not necessarily the final port.
Step 2: Access Port or Uplink?
This is the fork in the loop. If the interface is an access port with one MAC behind it, you’re done. If it’s a trunk, a port-channel, or any port carrying dozens of MACs, you’re looking at the path toward another switch, not the destination.
Quick checks: show interfaces Gi1/0/48 switchport (is it trunking?), or count what else lives there — show mac address-table interface Gi1/0/48. A port with 300 MACs on it is an uplink, no further analysis required. If it’s a port-channel (Po2, ae0), look up the physical members before you go LLDP-hunting.
Step 3: Hop to the Neighbor and Repeat
Find out what’s on the other end of that uplink:
show lldp neighbors Gi1/0/48 detail
(or show cdp neighbors … detail in an all-Cisco estate; show lldp neighbors on Junos). The neighbor block gives you the next switch’s name, management address, and its far-side port. SSH to it. Run the MAC-table lookup again. Back to Step 2.
In a two-tier network this loop runs twice. In the real world — a campus that grew by acquisition, a warehouse with unmanaged daisy chains, an MSP client site nobody has touched since 2019 — you may hop four or five times, re-translating MAC formats and re-authenticating as vendors change under you.
Step 4: Land on the Access Port
Eventually the MAC table answer is an access port with exactly one MAC on it. That’s your port. Confirm with show interfaces ge-0/0/12 (up/up? speed/duplex sane?) and, if the host speaks LLDP, its own advertisement will introduce it by name.
Now write it all up for the ticket: the path, the evidence, the closet. That part matters — the answer without the trail is just a claim.
The Gotchas That Eat Your Afternoon
- MAC aging. Tables age quiet entries out (default 300 seconds on most platforms). If the lookup comes back empty, the host is idle — ping it, then re-check the table.
- Wireless. If the trace dead-ends on a port whose LLDP neighbor is an access point, the “port” you’re hunting is an association on a WLC. Switch tools; the wired hunt is over.
- IP phones. A PC daisy-chained through a phone shows up behind the phone’s port. The physical jack is the phone’s.
- Port-channels. The table may cite the logical interface while LLDP speaks per-member. Resolve the bundle first.
- Virtualization. A VM’s MAC lands on the hypervisor’s uplink. You’ve found the host machine, not the VM — the last hop is vSwitch archaeology.
None of this is hard. It’s just long — twenty to forty-five minutes of careful, interruptible, error-prone bookkeeping, on a good day, while whatever prompted the ticket keeps burning.
The Same Hunt in About a Minute
This exact investigation is the kind of thing we built Transit AI for. Transit is an SSH client; you’re connected to your switches the way you always are. The difference is the agent riding along in the chat panel.
You ask it the question the ticket asked you: “Which switch port is 10.20.4.87 physically connected to? Trace it.”
The agent proposes the ARP lookup on the gateway. Proposes — a modal shows you the exact command, and nothing runs until you click Approve. It reads the answer, extracts the MAC, proposes the MAC-table lookup on the core. Click. Sees the uplink, proposes the LLDP query, follows it to the access switch — reformatting the MAC per vendor on the way, because it knows Junos won’t match Cisco’s dotted form. Click. Click.
Sixty seconds later you have the artifact: the access port, plus the written trace — gateway ARP entry, core MAC-table hit, LLDP hop, final port — with the supporting output attached. Paste it into the ticket.
Three properties make this safe to do on production gear, and they’re architecture, not promises:
- Every proposed command is checked against a per-vendor, default-deny allowlist —
show-class read commands pass, everything else is rejected before it ever reaches your screen. - Every command also requires your explicit click. Both gates, always. There is no autonomous mode to toggle on.
- You can scope the chat to just the devices in the hunt, so the agent’s world is exactly the three switches you gave it.
It proposed. You clicked. Nothing on the network changed — that’s not a setting, it’s the product.
Transit’s terminal is free — download it at transitai.app →
Frequently Asked Questions
How do I find which switch port a MAC address is on?
Query the MAC address table on the switch nearest the host’s gateway (show mac address-table address <mac> on Cisco; show ethernet-switching table | match <mac> on Junos). If the answering interface is a trunk or port-channel, use LLDP/CDP to identify the neighbor switch on that uplink, SSH to it, and repeat until the table answers with a single-MAC access port.
How do I find a device’s MAC address from its IP?
Ask the ARP table on the host’s default gateway: show ip arp | include <ip> (Cisco) or show arp | match <ip> (Junos). If the entry is absent, ping the host from the gateway to repopulate ARP. On segmented networks, scope the lookup to the right VRF.
Why isn’t the MAC in the MAC address table?
MAC tables age out quiet hosts (commonly after 300 seconds). Ping the host to make it transmit, then re-check. Also verify you’re on a switch that actually carries the host’s VLAN, and that you’ve translated the MAC into the format the platform expects — Cisco’s a036.9f12.8a5c won’t match a colon-form search string on other vendors.
Does the process differ across Cisco, Juniper, and Arista?
The logic is identical — ARP, MAC table, neighbor discovery, repeat. Only the verbs and the MAC notation change: show mac address-table (Cisco IOS/IOS-XE, NX-OS, Arista EOS) versus show ethernet-switching table (Junos), CDP versus LLDP, dotted versus colon MAC formats. Mixed-vendor estates are where manual hunts slow down most.
Can Transit AI’s agent change anything on my switches while it traces? No. The agent is investigation-only by architecture: every command it proposes must pass a per-vendor, default-deny allowlist of read commands, and must then receive your explicit approval click before it runs. There is no write path to grant, no autonomous mode to enable, and the enforcement lives outside the model — a jailbroken prompt still can’t pass the gate. Details in Why We Made the AI Investigation-Only.