Using NetOS 7.5 patched to latest, on CC-9P
Communicating with a host computer on a different subnet, via one or more Cisco switches, using TCP/IP.
After about 7.5 minutes, the device locks up. (Other units on the same subnet as the host computer work continuously for months, or even years!).
Network tracing has revealed the following sequence of events:
- Every 7.5 minutes, a network device (Cisco Switch, not necessarily the one our unit is plugged in to) generates a multicast (220.127.116.11) Mobile IP Advertisement packet.
- As soon as it receives the multicast packet, the unit responds with ARP request, “Who has 10.755.1.155? Tell 10.75.1.90”. This tells us that it does not have an entry in its ARP table for the network device that sent the Mobile IP Advertisement. The network device responds with an ARP response, “10.75.1.155 is at 00:b0:e1:53:74:b1”. So far nothing is out of the ordinary.
- The unit then resumes its communication with the host computer, but the next packet that it sends has its destination Ethernet address set to that of the network device, not the router. The network device cannot route the packet and responds with an ICMP Destination Unreachable packet. All subsequent packets from the waveguide switch controller to the host computer are routed the same way and communication is quickly lost.
In this particular case the workaround is to suppress the multicast packets, but that’s not always possible.
Has anyone else seen anything like this, or got ideas on how to resolve the problem properly?
(I think we’ve seen this problem a few times over the years, triggered by an inter-site link failing to the backup, but this is the first time anyone has been able to look in detail at the network traffic)
Mobile IP Advertisement packets are part of Mobile IP (IETF RFC 5944)