Broadcast ping

A really cool feature of the 'ping' implementation under most UNIX and Linux distributions is the ability to ping your subnets broadcast address.

[root@proxy /]# ping -b 10.70.0.255
WARNING: pinging broadcast address
PING 10.70.0.255 (10.70.0.255) 56(84) bytes of data.
64 bytes from 10.70.0.3: icmp_seq=0 ttl=64 time=0.058 ms
64 bytes from 10.70.0.10: icmp_seq=0 ttl=255 time=0.198 ms (DUP!)
64 bytes from 10.70.0.12: icmp_seq=0 ttl=64 time=0.205 ms (DUP!)
64 bytes from 10.70.0.48: icmp_seq=0 ttl=255 time=0.248 ms (DUP!)
64 bytes from 10.70.0.19: icmp_seq=0 ttl=255 time=0.254 ms (DUP!)
64 bytes from 10.70.0.16: icmp_seq=0 ttl=255 time=0.258 ms (DUP!)
64 bytes from 10.70.0.30: icmp_seq=0 ttl=255 time=0.262 ms (DUP!)
64 bytes from 10.70.0.46: icmp_seq=0 ttl=255 time=0.287 ms (DUP!)
64 bytes from 10.70.0.43: icmp_seq=0 ttl=255 time=0.292 ms (DUP!)
64 bytes from 10.70.0.35: icmp_seq=0 ttl=255 time=0.297 ms (DUP!)
64 bytes from 10.70.0.44: icmp_seq=0 ttl=255 time=0.302 ms (DUP!)
64 bytes from 10.70.0.57: icmp_seq=0 ttl=255 time=0.310 ms (DUP!)
64 bytes from 10.70.0.64: icmp_seq=0 ttl=255 time=0.336 ms (DUP!)
64 bytes from 10.70.0.253: icmp_seq=0 ttl=64 time=0.341 ms (DUP!)
64 bytes from 10.70.0.45: icmp_seq=0 ttl=255 time=0.346 ms (DUP!)
64 bytes from 10.70.0.222: icmp_seq=0 ttl=255 time=0.662 ms (DUP!)
64 bytes from 10.70.0.22: icmp_seq=0 ttl=64 time=0.669 ms (DUP!)
64 bytes from 10.70.0.229: icmp_seq=0 ttl=64 time=0.674 ms (DUP!)
64 bytes from 10.70.0.210: icmp_seq=0 ttl=64 time=0.678 ms (DUP!)
64 bytes from 10.70.0.216: icmp_seq=0 ttl=64 time=0.698 ms (DUP!)
64 bytes from 10.70.0.209: icmp_seq=0 ttl=255 time=1.42 ms (DUP!)
64 bytes from 10.70.0.40: icmp_seq=0 ttl=255 time=1.43 ms (DUP!)
64 bytes from 10.70.0.217: icmp_seq=0 ttl=60 time=1.43 ms (DUP!)
64 bytes from 10.70.0.246: icmp_seq=0 ttl=255 time=2.82 ms (DUP!)
64 bytes from 10.70.0.223: icmp_seq=0 ttl=60 time=2.85 ms (DUP!)
64 bytes from 10.70.0.252: icmp_seq=0 ttl=255 time=2.85 ms (DUP!)
64 bytes from 10.70.0.244: icmp_seq=0 ttl=60 time=4.13 ms (DUP!)
64 bytes from 10.70.0.248: icmp_seq=0 ttl=255 time=5.25 ms (DUP!)
64 bytes from 10.70.0.240: icmp_seq=0 ttl=255 time=15.4 ms (DUP!)

--- 10.70.0.255 ping statistics ---
1 packets transmitted, 1 received, +28 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.058/1.554/15.486/2.926 ms, pipe 2

A couple interesting things about this. First, the only responding hosts are hosts that are set to reply to ICMP broadcast pings. On this network this includes my UNIX and Linux hosts routers and switches, along with a couple other random hosts such as firewalls and a few network based cameras. Now it would be nice to see all of the windows hosts as well, but as part of the windows TCP/IP stack they are set to not reply to ICMP broadcast pings. This seems unfortunate, as if Microsoft did not implement their TCP/IP stack according to RFC guidelines. But upon further research, in RFC-1122 (Requirements for Internet Hosts) This behavior is allowed:

"An ICMP Echo Request destined to an IP broadcast or
IP multicast address MAY be silently discarded."

The other interesting thing about a broadcast ping is the ordering of replies. The hosts that replied the quickest are the hosts that are the physically closest to the sending host. The hosts that took the longest to reply are the physically farthest away from the sending host. The hosts that have gigabit links, even though physically farther than others appear near the top of the list. It's just cool to see propagation delay at work...