Description

This article provides a concise guide to troubleshoot ARP (Address Resolution Protocol) learning issues on Juniper equipment. ARP is crucial for mapping IP addresses to MAC addresses, and problems with ARP learning can disrupt network connectivity.

 

  • Inability to ping the default gateway or other devices in the same subnet.
  • Missing or incomplete ARP entries in the ethernet-switching table.
  • ARP requests are sent but not replied to.
  • ARP replies are not processed.
  • Packet loss or intermittent connectivity to local devices.

Symptoms

Here an example topology:

 

irb.10 = 10.0.0.1/24         vlan 10        irb.10 = 10.0.0.2/24

      [Switch-1] ge-0/0/0 ------------ ge-0/0/1 [Switch-2]

 

Solution

By following these steps, you should be able to diagnose and resolve most ARP learning issues on Juniper equipment:

 

1) Check the related interfaces Status:

Ensure that the interfaces involved in the communication are operational displaying Admin up and Link up.

> show interfaces terse ge-x/x/x

 

If the affected interfaces are IRBs, make sure they are up as well

> show interfaces terse irb.x

 

2) Verify Interfaces configuration. Make sure both IPs belong to the same subnet by checking they have the right IP address and a matching mask /24 in this case. Also, verify that the same vlan is correctly configured on both ports using the following commands:

> show configuration interfaces ge-x/x/x

> show configuration interfaces irb.x

> show vlans <vlan-name> <-- Make sure the ports displayed contain an asterisk *, this indicates the ports are active on that vlan.

 

3) Verify the ARP cache. Check the ARP table on both devices, each of them should have an ARP entry for the device they are trying to communicate with. Make sure the table has the expected entry:

> show arp

> show arp hostname x.x.x.x <--- x.x.x.x being the IP of the remote device

 

If the ARP is not learned check step 4:

 

4) Verify the MAC Address Table. Make sure that you're able to see the mac-address of the remote device:

> show ethernet-switching table interface ge-x/x/x

 

If the MAC is learned skip to step 5.

 

If the mac-address is not learned, look out for any configured firewall filters that could be blocking the traffic:

> show configuration | display set | match firewall

 

If there's no configured firewall filters, extract the L2-learning traceoptions:

# set protocols l2-learning traceoptions file <name.txt>

# set protocols l2-learning traceoptions flag all

# commit confirmed 1

 

After a minute the switch rollbacks the traceoptions configuration and the file will be saved into /var/log. Check for any evident errors using any of the above commands:

> show log <name.txt>

> file show /var/log/<name.txt>

 

5) Monitor ARP Traffic on both devices. Do a packet capture to verify that ARP Requests and ARP Replies are being sent and received using this command:

> monitor traffic interface irb size 1500 no-resolve matching arp

 

You should see the ARP requests from the device initiating the ping:

04:40:32.272058 Out arp who-has 10.0.0.2 tell 10.0.0.1

 

You should see the ARP reply from the device responding with his mac-address:

04:40:34.083531 In arp reply 10.0.0.2 is-at xx:xx:xx:xx:xx:xx

 

If both switches are generating the required ARPs but the peering is not seeing them, this most likely mean these packets are getting lost or blocked along the path. In such case troubleshooting L2 devices in the middle will be required.

 

If you see the requests and replies but the ARP cache not updating:

 

6) Review the Logs for any ARP-related errors, warnings or duplicated IP addresses:

> show log messages | match arp

> show log messages | match duplicated

 

7) Clear ARP cache to force the device to relearn ARP entries:

> clear arp hostname x.x.x.x

> clear arp interface <ge-x/x/x | irb.x>

 

9) If you've reached this point and you're still unable to restore the connectivity, a reboot would be a good idea. Previous reports indicate a miss-programming could happen preventing basic protocols to work properly.

> request system reboot at now

 

10) If you have rebooted and still unable to ping, make sure the Junos OS you're running is still under support by checking this link:

https://support.juniper.net/support/eol/software/junos/

 

If it's expired we suggest upgrading your device to a newer supported version where support by JTAC is still warranted and at the same time, doing this will integrate newer fixes and correct any possible miss-programming happening on the switches. 

 

11) Contact Juniper Support if the issue persists after doing all the previous steps.

 

Modification History

2024-09-12 : Article Created
2025-03-06 : Flipped to public view