Re: tracert from A to B dies just before reaching B -- and vice versa?
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Mon, 09 Feb 2009 14:16:06 -0600
On Mon, 9 Feb 2009, in the Usenet newsgroup comp.os.linux.networking, in article
<37a3c87c-9aaf-4cf7-b639-8c3ee94f2d5e@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Bennett Haselton wrote:
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
For some reason they are unable to ping each other or ssh to each
other (even though each host is pingable from apparently everywhere
else). As recently as a few days ago, I was able to ssh from one to
the other so I have no idea what went wrong.
Someone changed the firewall/routing rules.
I did a tracert from 69.72.177.140 to 67.43.158.218, and the
traceroute died just before reaching 67.43.158.218. I took this to
mean that the problem was somewhere on the network hosting
67.43.158.218 (perhaps a router blocking incoming connections from
69.72.177.140 for some unknown reason), and reported the problem to
them:
Exactly which application did you use? "tracert" is the windoze
wanna-be application that uses ICMP echos (ping) as the trace. While
several later versions of the LBL "traceroute" _can_ use ICMP echos
(with the -i option), the default is to use UDP packets. It may
come as a surprise to you, but neither ICMP or UDP is used for SSH
connections, so failures of TRACERT.EXE or traceroute won't explain
TCP/IP connection problems. See the man page.
However, the network admins for 67.43.158.218 replied that they tried
doing the reverse -- doing traceroute from 67.43.158.218 back to
69.72.177.140 -- and it showed that the traceroute got almost the
entire distance, but died just before reaching 69.72.177.140:
Replace the providers with someone less incompetent.
This, to me, seems extremely weird.
But not exactly relavent. 'tracert' and 'traceroute' are not testing
the firewall rules that apply to TCP.
How can the traceroute work *almost* all the way, but not quite, in
both directions?
Dozens of explanations - most probably is the fact that firewall rules
can be directional, and that multiple protocols are in use.
If there were a firewall on one network that was preventing the
traceroute from completing in one direction, wouldn't it also stop the
traceroute in the other direction before it even got out the door?
Read the man page for tcpdump. It works by the originator sending out
packets (ICMP Type 8 or UDP to ports ~34334+) with a time to live of
"1". The router that receives such a packet decrements the TTL count,
sees that it is now zero, drops the packet, and MAY send back an ICMP
Type 11 Code 0 "Time Exceeded" error. The sender increments the TTL
and repeats - with the "next hop" discovering the TTL is zero, lather
rinse, repeat. When the originating TTL is large enough to reach the
destination, that host sends back an ICMP Type 0 (echo reply to a
ICMP type 8), or ICMP Type 3 Code 3 (port unreachable).
Now look on your system for the old but readable "Firewall-HOWTO" or
the more modern "packet-filtering-HOWTO" which you can find at
http://www.netfilter.org/documentation/HOWTO/. Notice that firewalls
can have different rules for "inbound" and "outbound" packets,
different protocols, and even different rules for the 25 types of ICMP
packets. The providers may or may not be using Linux, but the concepts
of packet filtering are the same.
Even without knowing what IS causing this, what is a plausible set of
conditions that COULD be causing it?
Depends on how the firewalls are configured - but it is a firewall
issue. If your providers can't _explain_ to you what they have done
and make some effort to fix the problem, replace them with someone who
can. You may also want to check the various RBL lists before you
sign any contract, and check news.admin.net-abuse.sightings for other
signs of trouble.
Old guy
.
- Follow-Ups:
- References:
- tracert from A to B dies just before reaching B -- and vice versa?
- From: Bennett Haselton
- tracert from A to B dies just before reaching B -- and vice versa?
- Prev by Date: Re: tracert from A to B dies just before reaching B -- and vice versa?
- Next by Date: Re: tracert from A to B dies just before reaching B -- and vice versa?
- Previous by thread: Re: tracert from A to B dies just before reaching B -- and vice versa?
- Next by thread: Re: tracert from A to B dies just before reaching B -- and vice versa?
- Index(es):
Relevant Pages
|
