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.

Why a Junos SRX Has Two Independent Forwarding Tables

On a Cisco router with an SVI, Layer 2 and Layer 3 are heavily coupled: a MAC learned in the bridge domain feeds the ARP process and the ARP process feeds the connected route. On a Junos branch SRX in switching mode, the same hardware runs two logically separate engines. The switching engine maintains a MAC table per VLAN (the ethernet-switching table). The routing engine maintains ARP and the routing table per routing instance, and it only consults the switching table when it needs to send a frame.

The direction that matters in a puzzle like this is inbound. A frame arriving on an access port is learned by the switching engine immediately — that is what populates the MAC table. For the packet to reach the routing engine, the ingress VLAN must map to an L3 interface, that interface must be part of the same routing instance the ARP cache belongs to, and the frame's destination MAC must match the irb interface's MAC address. If any of those three conditions fails, the MAC still appears in the switch table while ARP stays empty. That is exactly the signature we were looking at: L2 knowledge without L3 progress.

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 Commands Used in the Hunt

user@srx> show arp no-resolve
user@srx> show ethernet-switching table
user@srx> show ethernet-switching table interface ge-0/0/1
user@srx> show interfaces irb.100 terse
user@srx> show route 192.168.10.0/24
user@srx> show route 192.168.10.5 detail
user@srx> show configuration interfaces irb
user@srx> show configuration vlans

Two flags are worth memorising. show arp no-resolve prints the raw cache without trying to resolve hostnames, which makes it fast and unambiguous. show route <ip> detail prints every match for a prefix including the more specific routes — that is where a surprise /32 next-hop hiding underneath a connected /24 becomes visible.

Reading the Ethernet-Switching Table

The output is small and information-dense. Four columns decide the whole diagnosis:

• MAC address — confirm the OUI matches the vendor you expect. A printer that reports a Realtek or Intel OUI is a different class of device than the one on the purchase order.
• Flags — D marks a dynamically learned entry, S a static one. A D entry means the device transmitted recently enough to be learned; it does not mean the device can answer at Layer 3.
• Logical interface — the port and VLAN the MAC was seen on. If the VLAN here is not the VLAN mapped to irb.100, ARP will never see the host no matter how healthy the link looks.
• Age — entries age out and re-learn. An entry that keeps disappearing and reappearing points at a flapping link or a spanning-tree reconvergence, not at a Layer 3 fault.

Compare the count of dynamic entries against the number of hosts you believe are on the LAN. In this incident the switch table showed more machines than ARP did — the extra entries were the static hosts, invisible to Layer 3.

What an irb Interface Actually Is

irb stands for Integrated Routing and Bridging, and the name is literal. The interface is not a port; it is an identity the routing engine uses inside a bridge domain. When a frame arrives for the irb MAC, the switching engine hands the packet up. When the routing engine sends a packet into that VLAN, it sources it with the irb MAC and the switching engine forwards it.

set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members v100
set interfaces irb unit 100 family inet address 192.168.10.1/24
set vlans v100 vlan-id 100
set vlans v100 l3-interface irb.100

The critical line is the last one. A VLAN without an l3-interface binding is a pure Layer 2 bridge domain: MACs learn, frames forward between member ports, and nothing ever reaches the router. If that binding is missing or points at a different unit number than the interface you configured, you get precisely the symptom described here — a populated switch table and an empty ARP cache.

Host Routes, /32s and the Return Path

ARP entries in Junos install as /32 host routes inside the routing instance, and a /32 always wins over the connected /24 when the routing engine looks up a next hop. That is normally desirable: it pins a host to the interface it was learned on. It becomes a problem when a stale or mislearned /32 points somewhere unexpected — out a different irb, into a different routing instance, or at a next hop that cannot reach the host.

This is why the debugging sequence above insists on checking the routing instance rather than only the interface. A connected route for 192.168.10.0/24 in the default instance proves the subnet exists, not that traffic for .5 uses it. show route 192.168.10.5 detail is the command that settles it, because it prints the /32 that is actually selected. When the /32 and the /24 disagree about the outgoing interface, you have found the fault.

Packet-Level Proof: monitor traffic

Before changing any configuration, watch what the device actually sends and receives. The on-box capture is enough to separate "the host never answered" from "the SRX never asked".

user@srx> monitor traffic interface ge-0/0/1 no-resolve layer2-headers
user@srx> monitor traffic interface ge-0/0/1 no-resolve matching "arp"
user@srx> monitor traffic interface irb.100 no-resolve matching "icmp"

layer2-headers is the important flag: it shows the destination MAC of every frame, so you can see whether the ARP reply is addressed to the irb MAC or to something else. Running the capture on both the physical port and the irb simultaneously tells you instantly whether the frame is crossing the L2→L3 boundary inside the box.

Other Causes of "L2 Present, L3 Silent"

• Missing l3-interface binding on the VLAN — the most common cause and the one in this incident. The MAC learns, nothing routes.
• VLAN ID mismatch — the access port carries VLAN 100 while the irb is bound to VLAN 200. Frames arrive in a bridge domain with no L3 interface attached.
• Wrong routing instance — the irb sits in a custom instance while the client subnet exists in the default instance, or vice versa.
• Duplicate IP with a different MAC — two devices configured with .5. The SRX learns whichever answers first and keeps alternating, producing intermittent reachability.
• Interface in a security zone without a host-inbound service — on SRX, ARP and ICMP to the interface itself are governed by zone configuration; host-inbound-traffic must permit the protocols you expect.
• MAC move or loop — the same MAC appearing on two ports in rapid succession keeps the switch table churning and never lets a stable ARP entry form.

The SRX zone detail catches people out because it does not exist on a plain router. On a branch SRX, an interface can be perfectly configured, in the right VLAN, and still refuse to answer ARP to the device's own address if the zone forbids it. Check show security zones and the interface's host-inbound-traffic stanza before you go deeper.

Fix and Prevention Checklist

1. Confirm the VLAN is bound to an irb interface with the matching unit number.
2. Confirm the access port's VLAN membership matches the irb's VLAN.
3. Confirm the irb address and mask are the ones the hosts use as a gateway.
4. Confirm the irb belongs to the same routing instance as the client subnet.
5. Confirm the interface's zone permits ARP and ICMP as host-inbound traffic.
6. Run show route <host> detail for any host that behaves differently from its neighbours.

Then document it. A one-page diagram with the VLAN-to-irb-to-zone chain marked on it saves the next engineer the entire hunt, because this class of fault is invisible in any single show output and only appears when you line the layers up side by side.

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.

FAQ

Can ARP be empty and ping still work? Yes, briefly — the ARP cache ages out while a session stays alive, and replies continue until the routing engine needs a fresh entry. An empty cache with intermittent success is a symptom of ARP never completing, not of a working path.

Does clear arp help? It clears the symptom, not the cause. If the entry refills within seconds, the underlying L2-to-L3 binding is fine and you are chasing a different problem.

Why do DHCP clients work when static hosts do not? DHCP is a broadcast request answered by a service on the device itself, and it uses a different code path in many designs. It can succeed even when the L3 gateway binding for the subnet is broken — which is precisely why the fault looked like "everything works except the printer".

Related Junos material: Junos EX 接口 Flap 识别 and Junos BGP 建立排障. For packet-level evidence gathering on Junos, see Junos traceoptions: debug BGP without guessing.

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