[Fwd: Re: Making ICMP the default traceroute protocol?]

From: Clark Gaylord (gaylord_at_dirtcheapemail.com)
Date: 01/24/05

  • Next message: Marian Durkovic: "Re: Making ICMP the default traceroute protocol?"
    Date: Mon, 24 Jan 2005 13:01:05 -0500
    To: freebsd-net@freebsd.org
    
    

    Marian Durkovic wrote:

    > seems that in today's networking environment the original traceroute
    >concept utilising high UDP ports no longer works - since those ports
    >are now typically blocked by firewalls.
    >
    > However, when traceroute is performed using ICMP protocol, the results
    >are much better.
    >
    > Therefore, I'd like to propose to patch
    >
    >src/contrib/traceroute/traceroute.c
    >
    > so the ICMP protocol is the first one in

    I disagree. Firstly, IWFs tend to also block ICMP. Secondly, routers
    sometimes queue ICMP differently than UDP (not just in their own
    processing, which they almost always do, but also in their forwarding),
    giving even more distortion to these data than they naturally possess
    otherwise. In particular, if filtering happens, this becomes obvious;
    if differential queueing happens, it is difficult to notice that is
    likely what is happening as it doesn't break the trace, it just distorts
    the data. Finally, knowing that there is some IWF between me and the
    destination is usually a good indication of where a performance problem
    resides. ;-)

    This is most likely to make a difference at the end hop itself, though
    of course filtering can happen anywhere along the path.

    If you are finding that your destinations tend to need ICMP, I'd
    recommend aliasing traceroute to "traceroute -I".

    --ckg

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"


  • Next message: Marian Durkovic: "Re: Making ICMP the default traceroute protocol?"

    Relevant Pages

    • Re: Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable
      ... The real LBL traceroute ... icmp error in reponse to an icmp packet. ... icmp time exceeded in response to an icmp echo or echo reply. ... had created a b0rken network stack that could be kicked over by sending ...
      (comp.security.firewalls)
    • Re: icmp type 11 not go via nat POSTROUTING table
      ... everthing is working as it "should", there is no reason for a "ICMP ... I generated two test icmp packets ... This is how traceroute knows the IP of the ... If x.y.z.t is a private IP address, it cannot be tracerouted anyway, so ...
      (comp.os.linux.networking)
    • Re: Traceroute anomaly
      ... Hm - checking back on previous exchanges I have had over traceroute I ... I'm sorry I "muddied the water" with RFC 1393 and the IP "route ... Do remember that I said I used to teach ICMP and what seems to have ... generated when the packet which might give rise to the ICMP packet is ...
      (comp.dcom.sys.cisco)
    • Re: set srcIP for ICMP replies, or for locally sourced connections?
      ... I just performed a traceroute from a Windows XP host through my IPSec+ GRE VPN, and captured it with Wireshark to confirm my beliefs. ... The router that gets the packet with a TTL of 1 will reply with an ICMP TTL exceeded message. ... Extended ping permits you to specify the source IP address that will be used in the outbound ping, which then becomes the destination IP address in the reply packet. ... But that would block replies from simple outbound pings and traceroutes from router CLI sessions. ...
      (comp.dcom.sys.cisco)
    • ICMP pokes holes in firewalls...
      ... Traceroute uses two protocols: UDP and ICMP ... A system inside a firewall performs a traceroute to a system ... Traceroute chooses the next available UDP port. ...
      (Bugtraq)