I just had one of those "duh" experiences today, and it made me think a bit... At my job at <vijay> a promising local ISP </vijay>, I was turning up a customer, who decided to test his connectivity by trying to ping and trace to www.sprint.net and www.uu.net. As it turns out, both servers are behind firewalls, that block ICMP and UDP, so you can't ping or trace to either server. But then my customer asked me, "OK, can you give me a hostname in UU's netspace that I CAN ping?" It took some thought and experimentation to find one (mail.uu.net and ns1.sprint.net, in case anyone wants to know). What this brought to mind was this question: would it be worth my time to compile a list of pingable and traceable IPs that live on the major backbones for connectivity testing and troubleshooting? I do wind up seeing a lot of cloobies trying to ping a site, and assuming it's down because IMCP-blocked. Thoughts? -C --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
On Tue, 30 Jan 2001, Christopher A. Woodfield wrote:
What this brought to mind was this question: would it be worth my time to compile a list of pingable and traceable IPs that live on the major backbones for connectivity testing and troubleshooting? I do wind up seeing a lot of cloobies trying to ping a site, and assuming it's down because IMCP-blocked.
What I've been wondering is why is ICMP seen as such an inherent evil that it should be completely blocked? There are so many ways to pound on host tcp stacks, the days that "ping -f" was an actual problem seem far gone. This ICMP-envy seen on some networks takes away a useful tool and leads to paranoid misconfiguration (like blocking pmtu-discovery combined with tcp don't fragment flags, *cough*) makes me wonder, is it still really any use at all to block icmp echo-requests? If so, would using CAR on it be prohibitively expensive? Or is this all just a brick wall to run in to, sort of like the smurf-reflector issues? Cheers, Pi
participants (2)
-
Christopher A. Woodfield -
Pim van Riezen