As harsh as it sounds this is partially because of the ‘give a mouse a cookie and he’ll try to use it as an umbrella at which point you’ve done him more harm than good’ scenario.
If you give a user ping then they’ll try to use it to test everything connection related. This is fine because it by itself won’t bring down your network. However the tickets coming in telling you that ‘Server X won’t respond to pings and so therefore there must be a firewall rule preventing their service on port 8083 from working with their laptop on the wireless’ probably will make your life more aggravating. Especially when the wireless network blocks all ICMP traffic.
From a long time of dealing with connectivity errors I’ve found ping to be more an enemy to you than a friend. A lot of users use ping to check things because someone made them ping Google to test their internet connection a long time ago and it stuck for everything. The problem is that ping doesn’t check ports and many corporate networks block it for security purposes. So when ping fails it means that ping is blocked not port 8083 – which turns out not to be running the service in the first place. This doesn’t even cover the tickets that come in stating that whole swathes of the network are ‘down’ because Joe Bloggs cannot hit them with his ping command.
It also becomes a tool for extremely misguided tickets. I’ve seen ones where no ICMP traffic was allowed across the main outward facing firewall and whole tickets were troubleshot and eventually discarded because someone got a 404 error and tried to ping these server. To be fair some of these have indicated a distinct lack of networking knowledge by the person troubleshooting.
It’s unlike me to offer a problem without a solution, so here it is. Telnet. If telnet makes a successful connection then a TCP session started, the firewall is fine. Of course it doesn’t protect you from the people who don’t start their web server and can’t make a connection to a service that doesn’t exist. Another test if you are aware that there’s no service on the other end to connect to is using netcat, but that’s a discussion for another day.
Happy troubleshooting,
Robert Small.
Pingback: Troubleshooting connectivity | Robert Small, The blog thereof.