This article describes the following scenario experienced by a customer: On EX4100-48T running Junos 23.4R2-S4.11, sustained traffic to unused IP addresses inside locally-connected IRB subnets can trigger excessive ARP resolution attempts. Under this condition, the fxpc process may enter a non-recoverable 100% CPU loop. While CPU is pegged, control-plane processing is starved and routing protocols (OSPF) may flap. The only immediate recovery is to manually terminate fxpc, which causes a brief forwarding hit.

This typically happens when the site advertises aggregate prefixes for IRB-connected networks into eBGP, and upstream routers forward “internet background” traffic for unused IPs within those aggregates to the EX4100.

> fxpc at 100% CPU and does not recover on its own

> High system load (often 25+; normal <1)

> OSPF adjacencies drop at the same time (hello timer expiration during CPU starvation)

> Large ARP/ICMP counters indicating unresolved ARP activity, for example:

• ARP requests sent far higher than received
• Many ARP resolution requests generate
• Packets discarded waiting for ARP resolutio
• Elevated ICMP destination unreachable messages

> Terminating fxpc restores CPU temporarily, but the issue returns if the same traffic continues

Recommended fix: stop attracting the traffic

• Do not advertise unused (“dark”) IP space inside aggregate prefixes, or
• Blackhole/discard unused ranges on the border routers so traffic to unused IPs never reaches the EX4100

This prevents the ARP resolution churn that drives fxpc into the high-CPU condition.

Alternatively

• Apply an ingress filter on the uplinks or VLAN to rate-limit/drop the triggering traffic destined to unused ranges.