IPSI A packet trace showing old IPSI B traffic

[kjrnec]

We had an IPSI B and control network IP Address change because they were on the same VLAN. This was done by our BP to try and correct sanity errors. I've been running traces on IPSI A and seeing IPSI B's old address still sending data to our S8730. Has anyone else seen this before?

*.*109.205 [5010] - *.*109.202 [34072] - FIN/ACK (Retry) - Generic - 5/11/2010

Source Destination
.109.205 109.201 IPSICTL [TCP Retransmission]
.109.205 109.202 TCP telepathstart > 34072 [FIN, ACK]

 

[simreal]

The server that is active may be the same server that was active when the change was made. It's possible the changes have not duplicated to the standy server.


My recomendation is to telnet or ssh into the standby server. At the linux command line enter th command "pingall -i"


This will ping all IPSI and you should only see valid IPSI address. I suspect you will see a failed ping to the old address.

To resolve this you may need to interchange servers and I have even seen cases where we had to reset system 4 while running on the alternate server.

Good luck with this issue. Please let us know if you find a resolution.

 

[kjrnec]

The address is coming from the old IPSI B IP Address before it was changed by the BP. I'm guessing the arp cache wasn't cleared after the IPSI IP address change.

 

[simreal]

Clear the arp entries for the IPSI b address.

If the IPSI IP was changed the there shouldnt be a host on that address to send traffic from.

The server may however associate traffic sent from that device based on mac and may show the old IP because arp hasn't been cleared.

 

[kjrnec]

There isn't an host anymore since you can't ping that address and nothing else on the network is using it anymore. I just don't see how its even possible for it to send IPSICTL messages to the server from that IP Address. The packet traces aren't even monitoring the port where IPSI B is connected.

There isn't an clear arp command for the IPSI. I was told by our BP we could just remove then reinsert the IPSI to clear the arp cache. On another forum they said clearing the IPSI arp cache manually could cause serious problems with our network. I don't even feel those packets are the cause of our problems anyway. More than likely deflection from Avaya Support on the root cause since they can automatically blame the network and close the ticket.

 

[simreal]

Ok you can clear arp for any host simply by removing the host from the network.


The arp table is in the S87xx server. The command to see the arp table is arp -a (you may need to use "/sbin/arp -a) depending on your permissions.


You will see something similar to this:

username@TCOMA_HS8720SEC>  /sbin/arp -a
ipsi-A01a (x.x.129.34) at 00:07:3B:CE:98:78 [ether] on eth0
TCOMA_HS8720PRI (x.x.128.31) at 00:00:50:38:A4:B8 [ether] on eth4.0000
TCOMA_HS8720PRI-cnb (x.x.130.31) at 00:00:50:38:A4:B7 [ether] on eth3
TCOMA_HS8720PRI-dup (192.11.13.13) at 00:00:50:38:A4:B6 [ether] on eth2
TCOMA_HS8720PRI-cna (x.x.129.31) at 00:1A:4B:CF:28:B6 [ether] on eth0
? (x.x.128.200) at 00:21:28:6D:56:C2 [ether] on eth4.0000
? (x.x.128.1) at 00:00:0C:07:AC:01 [ether] on eth4.0000
ipsi-A01b (x.x.130.34) at 00:07:3B:CE:99:98 [ether] on eth3
username@TCOMA_HS8720SEC>

Notice the line : ipsi-A01b (x.x.130.34) at 00:07:3B:CE:99:98 ...

This line tells the server that to is can communicate with the hostname "ipsi-A01b by using the IP or the mac address. If the entry isnt cleared then this wont change.

To clear the entry all you need to do is enter the command arp -d ipsi-A01b (in my case) or /sbin/arp -d ipsi-A01b (permissions again).


You may have given your IPSI's different hostnames but the command arp-a and arp -d will be the same.