pjhtech Tools
Ubiquiti · EdgeOS

EdgeRouter Interface and ARP Diagnostics

A physical link being up answers one question: the Ethernet endpoints established a link. It does not establish the correct VLAN, an IPv4 address, successful neighbor resolution or a usable route. Inspect these layers separately so that a routing symptom does not trigger an unnecessary cable replacement or interface reset.

Scope: EdgeRouter running EdgeOS; official interface detail and tcpdump workflow. Interface layout depends on model and configuration. Switch-capable ER-X family differs from models with individually routed ports. No invented universal port mapping; not EdgeSwitch.

Start with the actual interface inventory. A connector marked eth1 can participate in a switch group or carry a VLAN interface; the address relevant to your test might not belong directly to the physical port. Copy the model, firmware and interface names into your incident notes before narrowing the investigation.

Read-only inventory #

Read-only inventory
EdgeOS · EdgeOS operational CLI / shell for tcpdump

Read-only
show version
Read-only
show interfaces
Read-only
show interfaces ethernet detail

The detailed Ethernet view exposes interface-specific MAC information. Do not assume the base MAC or serial-derived MAC shown for the chassis is the source address used by every interface. When correlating a neighbor entry or switch MAC table, compare the correct port or logical interface identity.

Use ARP to test the local IPv4 segment #

For a short observation on the relevant Ethernet/VLAN interface, replace the placeholder before execution:

Use ARP to test the local IPv4 segment
EdgeOS · EdgeOS operational CLI / shell for tcpdump

Diagnostic state

Replace these example values: <interface>.

sudo tcpdump -ni <interface> -c 30 arp

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

Generate one authorized test from the affected client while the capture runs. Stop with Ctrl+C if it remains waiting; the packet limit is not a wall-clock timer. This uses the documented EdgeOS tcpdump facility with a standard ARP filter and does not flush existing neighbor state.

ObservationInterpretation to investigate
Repeated request for the gateway, no reply hereCheck VLAN continuity, intended gateway address and whether the gateway sees the request
Reply with an unexpected MACCompare actual interface identity and investigate address ownership
No ARP during an IP testExisting cache, wrong capture point, nonlocal destination or no generated traffic
ARP succeeds but the application failsContinue with IP routing, policy and the endpoint service

For an off-subnet destination, the client normally resolves its next-hop gateway rather than the remote server's MAC. Searching for the remote server in a local ARP capture can therefore create a false diagnosis. For IPv6, use Neighbor Discovery analysis instead of an ARP filter; the two are different protocols.

Compare the same test at the client edge and the gateway-facing segment. Write down the expected VLAN on each link and whether frames are tagged there. Avoid changing PVIDs, deleting interfaces or enabling proxy ARP as an exploratory shortcut. Those actions change the behavior you are trying to observe and may interrupt unrelated users. Once the failing layer is identified, make a separate, reviewed configuration change.

Sources

Documentation reviewed: 8 October 2026