Alcatel Carrier Internetworking Solutions 8800 User Manual
Troubleshooting ARP
Dshell Troubleshooting
OmniSwitch Troubleshooting Guide
September 2005
page 11-9
10.40.212.3 00:d0:95:6b:4c:e9 300 0x0
1948275 0
405 0
0 212
10.40.212.4 00:d0:95:7c:7d:78 300 0x0 1946929 0
405 0
0 212
10.40.212.127 08:00:20:b0:ea:d1 300 0x0 1948092 0
405 0
0
212
10.40.212.238 00:c0:4f:12:f7:1b 300 0x0 1947153 0
405 0
0 212
192.168.50.1 00:d0:95:82:05:16 380 0x0 194847e 0
405
0
0 50
192.168.50.2 00:d0:95:83:e7:81 380 0x0 1948e5c 0
405 0
0 50
192.168.50.5 00:d0:95:6a:f5:bb 380 0x0 1948165 0
405
0
0 50
192.168.51.5 00:d0:95:6a:f5:bc
380
0x0
194693a 0
405 0
0
51
192.168.52.5 00:d0:95:6a:f5:bd 380 0x0 194673b 0
405
0
0 52
192.168.53.5 00:d0:95:6a:f5:be 380 0x0 1945b2a 0
405 0
0 53
192.168.54.5 00:d0:95:6a:f5:bf 380 0x0 1946746 0
405
0
0 54
192.168.56.2 00:d0:95:83:e7:87 380 0x0 19469e4 0
405 0
0 56
192.168.57.1 00:d0:95:82:05:1d 380 0x0 1948764 0
405
0
0 57
192.168.57.2 00:d0:95:83:e7:88 380 0x0
1948041 0
405
0
0
57
192.168.57.5 00:d0:95:6a:f5:c2 380 0x0 1948165 0
405
0
0 57
192.168.58.5 00:d0:95:6a:f5:c3
0380 0x0 1948165 0
405
NiDebug>>>quit
Source Port is shown as 481. It is calculated based on Coronado ports. Each Coronado has 32 ports.
32*16=512 ports is the total Coronado port that can exist on OS7800.
32*16=512 ports is the total Coronado port that can exist on OS7800.
First 15 modules will have 480 ports. The count starts from 0 so ports 0 to 479 exist on the first 15 slots.
480 is the first port on slot 16 and 481 is the second port on slot 16. So, this does confirm that the arp was
learned on port 16/2.
480 is the first port on slot 16 and 481 is the second port on slot 16. So, this does confirm that the arp was
learned on port 16/2.
The table on the NI shows all the ARP entries as on the CMM. If a particular NI is having problems to
another NI then the arp table of that NI should also be looked at. The ARP entry for device A does exist
on NI 16, source NI of the device.
another NI then the arp table of that NI should also be looked at. The ARP entry for device A does exist
on NI 16, source NI of the device.
If an entry exists on an NI ARP table and is not fully synchronized with all the other NIs then the problem
might be because the IPC message is lost from that NI to the CMM which holds the master ARP table.
This will result in un synchronized ARP across the NIs which will cause problems when routing between
NIs.
might be because the IPC message is lost from that NI to the CMM which holds the master ARP table.
This will result in un synchronized ARP across the NIs which will cause problems when routing between
NIs.
To look at the number of ARP entries being added and deleted in the switch use the following command:
Working: [Kernel]->ipedrArpStatShow
arp add : 3
arp add fail : 0
arp del : 3
arp del fail: 1
arp change : 0
arp refresh : 0
arp putlist : 0
value = 0 = 0x0
Working: [Kernel]->
arp add : 3
arp add fail : 0
arp del : 3
arp del fail: 1
arp change : 0
arp refresh : 0
arp putlist : 0
value = 0 = 0x0
Working: [Kernel]->
If arp add, del and fail are changing in large numbers then it might indicate unusual activity in the network
which may be a result of some virus or spoof attack. In normal conditions the entries should be quite
stable.
which may be a result of some virus or spoof attack. In normal conditions the entries should be quite
stable.
If everything from the switch point of view looks fine then the best tool to find out the source of the prob-
lem is to use a sniffer.
lem is to use a sniffer.