ICMP Responses for Offline Devices

[Gregor Blaj]

Hi,

I've come across a strange situation and I can't seem to figure it out. When a certain device on the network is unplugged (a Citizen or HP printer in this case), instead of the ping timing out another device start responding instead (see below). Now, the devices responding are always all Citizen printers so I'm not sure if these devices are doing something weird.

The ARP cache on the switch shows a unique address for each entry.

Any explanations welcome :)

Switch#ping 192.168.1.184

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.184, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.182, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.195, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.186, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.193, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.194, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.172, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.188, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.189, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.187, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.218, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.219, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.190, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.191, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.181, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.185, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.198, dst 192.168.1.254
.Aug 29 ....390: ICMP: echo reply rcvd, src 192.168.1.192, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.194, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.189, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.191, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.172, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.195, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.190, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.187, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.192, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.185, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.188, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.193, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.181, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.182, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.186, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.218, dst 192.168.1.254
.Aug 29 ....416: ICMP: echo reply rcvd, src 192.168.1.219, dst 192.168.1.254
.Aug 29 ....424: ICMP: echo reply rcvd, src 192.168.1.198, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.188, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.181, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.193, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.182, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.195, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.190, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.172, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.194, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.218, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.219, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.192, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.198, dst 192.168.1.254
.Aug 29 ....432: ICMP: echo reply rcvd, src 192.168.1.189, dst 192.168.1.254
.Aug 29 ....441: ICMP: echo reply rcvd, src 192.168.1.185, dst 192.168.1.254
.Aug 29 ....441: ICMP: echo reply rcvd, src 192.168.1.186, dst 192.168.1.254
.Aug 29 ....441: ICMP: echo reply rcvd, src 192.168.1.191, dst 192.168.1.254

Gregor

[Kevin Dorrell]

It does sound like a weird behaviour in the Citizen printers.

You imply that when the device 192.168.1.184 is plugged in, you only get a reply from that device.  That figures, because the switch will only send the ping to the MAC address of that particular device.  But when you unplug it, the switch CAM entry for the device will be deleted from the forwarding table, so the ping will get flooded to all ports on the VLAN.

But it is another question why the other printers should respond to a ping that does not concern them.  That really does sound like a bug in the printers.

Do you have non-Citizen printers on the VLAN?  Do they respond?  If they don't, then it probably is the Citizen that is weird.

Kevin Dorrell

Luxembourg

[Gregor Blaj]

Yes, when 1.184 is plugged in that is the only device that responds.

I did just find that about 80% of the printers responding to the wrong IP had a /24 subnet mask, instead of a /23. Although some that were responding had the correct settings.

To me that still doesn't explain the behavior but I'll re run the test when the settings have been updated.

[Kevin Dorrell]

I agree, I don't think the incorrect mask will have anything to do with it.  But you might as well correct it now that you have noticed it.

Let us know how it works out.

Kevin