On Fri, Feb 24, 2012 at 11:36, Ben Scott <[email protected]> wrote:
> On Fri, Feb 24, 2012 at 12:53 PM, Richard McClary
> <[email protected]> wrote:
>> From Illinois, I do a tracert command to a node in an NYC location, I trace
>> it though my switch and out my router.  I then get three rows of asterisks
>> with “Request timed out” at the end.  Then, magically, there is the remote
>> IP.
>
>  Traceroute works by sending packets with an artificially low TTL.
> It starts at one and then increases it by one for each "hop".  When a
> router forwards a packet (one "hop"), it generally decreases the TTL
> by one.  As the TTL of each probe reaches zero, the intermediate
> router is supposed to respond with an ICMP "Time Exceeded" message.
> Traceroute prints the source IP address of each such message it gets
> back.  If it doesn't hear back within a timeout period, traceroute
> prints an asterisk and moves on.
>
>  The rows of asterisks indicate some of the intermediate routers are
> either not generating the ICMP "Time Exceeded" message, or some other
> device is not forwarding those messages back to you.
>
>  Given that you get a response from the destination, you might think
> this has to be a "not generating the message" scenario, and not a "not
> forwarding" scenario.  Not so.  A lot of big ISPs use RFC-1918 private
> addresses internally.  Their routers might actually emit the ICMP
> message with a source address in an RFC-1918 net.  That packet then
> gets caught by their own egress filtering, and you never see it.
>
>> From NYC (either a person in NYC running the tracert, or me in an RDP
>> session), if I do a tracert back to a node in IL, I see the external IP of
>> each router (rather than the asterisks and the “timed out” returns).
>
>  One scenario: It could be there is ICMP filtering happening at one
> end, but not the other.  In other words, it could be that in both
> cases the routers are generating the ICMP messages, but they are
> getting blocked on their way to you.  On the way to NYC, they are not
> blocked.
>
>  Another scenario: It could be the routers are using different source
> addresses for the ICMP messages, and some of those are being filtered
> while others are not.  Or that filtering is different in different
> directions.
>
>  The source address used in an ICMP message generated by a
> multi-address node (like a router) is implementation dependent.  Most
> commonly, the router will use the address of the interface which
> received the offending packet.  So, going one way, the router uses the
> addresses of the interfaces "facing" in your direction.  Going the
> other way, the router uses the addresses of the interfaces "facing"
> NYC.
>
>  You might try a third-party traceroute implementation.  Microsoft's
> can only use ICMP "Echo Request" (ping) packets.  Most other
> implementations use UDP, or offer a choice.  Sometimes routers will
> react differently depending on the type of traffic used for the
> traceroute probes.
>
> -- Ben

For those who play with *nix, there's also Layer 4 Traceroute -
http://pwhois.org/lft/index.who

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

Reply via email to