ARP resolution in Juniper EX Switches

ARP Resolution process in Juniper EX switches

 

When an ip packet which requires a L3 lookup hits an interface it will be subjected to L3 lookup provided Destination Mac address is the Mac address of the switch.

Let us take an example of a ip packet destined to 10.1.1.10 which is not resolved yet and falls under the subnet 10.1.1.0/24, this is a directly connected subnet on the EX.

The packet matches the following route entry:

20.1.1/24 Resolve 1337 RT-ifl 66 ge-0/0/16.0 ifl 66

This entry will be installed when the L3 interface is created on the switch.

Due to the above lookup, the packet will be trapped to the CPU (SFI) for resolving the destination.Such packets are rate-limited (1000 pps).

SFI queues the packets and informs the pfem to resolve it.
PFE queues this request and informs the kernel to resolve the ip destination.The route corresponding to this ip will be kept on HOLD in the PFE.

10.1.1.10 Hold 1346 RT-ifl 66 ifl 131079

A timer is also associated with this route

kernel then resolves this ip, by broadcasting ARP request in the broadcast domain.

If a reply is not received the hold timer is expired and the HOLD route is deleted.PFE informs SFI about the failure and packet is dropped by SFI.

If the reply is received by the Kernel, Kernel informs pfe to install the unicase route ,PFE does that and informs SFI who inturn will forward the packet.

10.1.1.10 10.1.1.10 Unicast 1346 RT-ifl 66 ge-0/0/16.0 ifl 66

Hold NH is added when arp request is sent.
If the arp reply is not received, this times out and the NH is deleted:

Packets are Soft-dropped by pfe, till the Hold NH is present

The below commands can be useful in debugging arp issues:

PFEM0(/dev/ttyp0)# show halp-nh statistics
Shim Layer Next Hop Statistics:
Nh Type: Hold
Inst Req: 1
UnInst Req: 1
root@EX-lab:0% rtsockmon -t
PFEM0(/dev/ttyp0)# show nhdb management all
PFEM0(/dev/ttyp0)# show halp-rt route ip rtt-index 0 prefix 10.1.1.10 p 32

About the author

James Palmer

Leave a Comment