Junos Troubleshooting: A LAN Where Static Hosts Never Answer

Some of the best networking lessons come from mistakes — and this one is a genuinely weird Junos puzzle: a brand-new FTTC circuit on a Juniper SRX comes up, DHCP works, the internet flies, and then the test print fails. The printer answers nothing, even though the SRX clearly sees its MAC address at Layer 2. This article walks through the troubleshooting logic that separates a Junos SRX's switching plane from its routing plane, and shows why the ARP table can lie about what the switch fabric already knows.

The Setup

The LAN is 192.168.10.0/24 with a DHCP pool of .50–.100 and three static hosts outside that range. The SRX uses ge-0/0/5 as the WAN and five access-mode ports (ge-0/0/0 to ge-0/0/4) bound to a virtual L3 interface irb.100 — Junos's equivalent of a Cisco SVI. Only ge-0/0/1 is actually used, plugged into a 24-port switch.

The Symptom

DHCP clients work, but the static hosts (like the printer at .5) do not respond to pings. Checking the ARP cache shows no machines outside the DHCP range. Yet show ethernet-switching table lists more machines than the ARP table does — the SRX sees the static hosts at Layer 2 but they are not progressing from the "switch" part of the device to the "router" part.

The Debugging Sequence

1. Check the ARP cache — if hosts are missing entirely, they are not completing Layer 3 resolution.
2. Check the ethernet-switching table — confirming the MACs are learned at L2 narrows the fault to the L2→L3 boundary.
3. Look up the MAC vendor — a MAC OUI match confirms the device is genuinely on the wire.
4. Question the routing instance — the key insight: the SRX may have a route to the /24 for transit traffic, but the irb interface's own host routes behave differently. When return traffic comes back, the SRX can hold a more specific route to the specific machine instead of the subnet, breaking reachability even though the L2 table is populated.

The Takeaway

Junos treats switching and routing as separate planes with different tables. When MACs appear in show ethernet-switching table but not in ARP, the problem is almost never the cable — it is the routing-instance or host-route logic between the planes. The monitor traffic interface ge-0/0/1 no-resolve layer2-headers command is a superb tool for watching exactly what the SRX itself sends and receives during such a hunt.

Related Junos material: Junos EX 接口 Flap 识别 and Junos BGP 建立排障.

原文链接：https://www.networkfuntimes.com/lessons-in-junos-troubleshooting-fixing-a-lan-with-a-weird-problem