OmniSwitch OS6860/OS6900/OS10K Troubleshooting Guide Part No.032996-00 Rev.A
AOS Release 7.X and 8.X January 2015
Alcatel-Lucent Page 39 of 148
- Duplicate IP addresses configured on the device in the same VLAN.
• STP TCNs may lead to an ARP table flush and high ARP rate (bursts).
• The ARP table is not synchronized between CMM and NIs
• ARP packets are generated by the CPU at high rate – As an example, a device scanning the network may
force an AOS switch to generate ARP traffic at high rate due to continous requests for unresolved ARPs.
6.2. Advanced ARP Troubleshooting
Maintenance Shell and debug commands should only be used by Alcatel-Lucent personnel or under the
direction of Alcatel-Lucent. Misuse or failure to follow procedures that use Maintenance Shell commands
in this guide correctly can cause lengthy network down time and/or permanent damage to hardware.
How to troubleshoot when the MAC address is learned but there is no ARP entry
a) One endpoint is not responding or ARP packets are corrupted or lost
If the MAC address is already learned on the port and the ARP is not getting resolved further troubleshooting
is required on the switch to determine if the ARP requests are reaching the switch and switch is issuing ARP
replies.
Troubleshooting the ARP packets requires the use of diagnostic CLI commands. Precautions must be taken
when using these commands as they are likely to dump a lot of information on the screen. Appending the
“timeout” argument to the command can ensure that the amount of information is manageable.
The command to use is as follows to capture the specific packets with ip address 10.255.13.26 hitting the CPU
for 2 seconds:
OS6860-> debug ip packet start ip-address 10.255.13.26 start timeout 2
1 1 S FLD 080020:a8f08a ->ffffff:ffffff ARP Request 10.255.13.26->10.255.13.66
1 1 R 1/1/47 e8e732:ab1c57 ->080020:a8f08a ARP Reply 10.255.13.66->10.255.13.26
The above capture shows that an ARP request came in on port 1/1/47 for ip address 10.255.13.66. The ARP
reply was sent by the switch to 10.255.13.26 at MAC address 08:00:20:a8:f0:8a.
This confirms that the switch is replying to the ARP requests. The ARP cache of the endpoint should
also show the correct ARP entry for the switch. If not, a sniffer should be placed between the switch
and the workstation to capture the packets and determine if the packets are corrupted or if either of the
devices are not responding in the correct format.
b) ARP table is full
In CLI, use command show arp summary to see the total number of ARP entries.
-> show arp summary
Type Count
-----------------+--------------
Total 3400
Static 0
To Next Page
Loading...
