Tracert returns same IP address two or three times

Discussion in 'Cisco' started by david.braesicke@gmail.com, Apr 8, 2005.

  1. Guest

    Here's an example:
    C:\>tracert 10.162.248.1

    Tracing route to 10.162.248.1 over a maximum of 30 hops

    1 1 ms 1 ms 1 ms 10.162.242.1
    2 6 ms 6 ms 6 ms 10.161.225.233
    3 6 ms 6 ms 6 ms 10.162.248.1
    4 7 ms 7 ms 7 ms 10.162.248.1

    Trace complete.

    Is this some sort of loop? This is new network with many remote sites
    connected via t1's.

    David
     
    , Apr 8, 2005
    #1
    1. Advertising

  2. Brad Guest

    No loop, #3 and #4 are the same device. It just used the same IP for
    it's source address in the ICMP TTL expired msg and the icmp echo reply
    msg.

    If you research the way traceroute (in windows) works this makes sense.
    Check out:

    http://www.visualware.com/resources/tutorials/tracert.html
     
    Brad, Apr 8, 2005
    #2
    1. Advertising

  3. DigitalVinyl Guest

    wrote:

    >Here's an example:
    >C:\>tracert 10.162.248.1
    >
    >Tracing route to 10.162.248.1 over a maximum of 30 hops
    >
    > 1 1 ms 1 ms 1 ms 10.162.242.1
    > 2 6 ms 6 ms 6 ms 10.161.225.233
    > 3 6 ms 6 ms 6 ms 10.162.248.1
    > 4 7 ms 7 ms 7 ms 10.162.248.1
    >
    >Trace complete.
    >
    >Is this some sort of loop? This is new network with many remote sites
    >connected via t1's.
    >
    >David


    I've seen this with some brands of firewalls. Either both are the
    firewall or the first 10.162.248.1 was the firewall, then next is an
    end device. I think that was with Checkpoint or Pix that I experienced
    that-but honestly can't remember exactly which. And of course, your
    particular config makes a world of difference.

    DiGiTAL_ViNYL (no email)
     
    DigitalVinyl, Apr 8, 2005
    #3
  4. Brad Guest

    If a firewall is letting a traceroute through and/or responding to one
    then it's more of a paperweight than a firewall. :)
     
    Brad, Apr 8, 2005
    #4
  5. In article <>,
    Brad <> wrote:
    :If a firewall is letting a traceroute through and/or responding to one
    :then it's more of a paperweight than a firewall. :)

    I'm not convinced that what you say is true.

    We use public IP addresses for all of our servers that there is
    outside access to -- we have to do so in some cases, as NAT is incompatible
    with some networking technologies. We allow traceroute to narrow bands of
    ports (the two most common ranges) on a few of those servers; everything
    else (other servers and all internal-only systems) we do not allow it to.

    As the IPs in question are public IPs that are easily associated with
    us (e.g., whois would tell you the CIDRs if you know the simple keywords
    to ask for), traceroute to them is not going to reveal any internal
    information about our systems... other than the detail that we allow
    traceroute to them. People aren't going to be able to connect to any
    real service on those ports as the systems in question never dynamically
    allocate those ranges as destination ports.

    Thus nothing is leaked about our internal structure that isn't already deducable
    to anyone who spent a few minutes looking.

    On the other hand, the ability to traceroute to those selected systems
    performs the useful network management function of allowing us to track down
    networking issues more easily -- track down whether, for example, the
    service is unreachable or the host is unreachable or whether it is
    a VPN problem, or whether a #@$ DSL modem has frozen again...

    Recall that real-life security is not about blocking every *possible*
    problem: real-life security is a matter of risk/benefit analysis. If
    we get benefits from permitting selected traceroute that save us noticable
    time and money in network debugging, and if the risk involved with
    permitting the traceroute is small compared to other issues, then
    I don't see how one could validly say that it is "more of a paperweight
    than a firewall".

    --
    "Who Leads?" / "The men who must... driven men, compelled men."
    "Freak men."
    "You're all freaks, sir. But you always have been freaks.
    Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD
     
    Walter Roberson, Apr 8, 2005
    #5
  6. Brad Guest


    > We allow traceroute to narrow bands of
    > ports (the two most common ranges) on a few of those servers;

    everything
    > else (other servers and all internal-only systems) we do not allow it

    to.

    There are two types of traceroutes. Windows products use ICMP/ICMP
    while many UNIX flavors use UDP/ICMP. With the ICMP/ICMP no ports are
    used since ICMP rides inside of IP. With UDP/ICMP, UDP uses a RANDOM
    high port number as the destination port so there's no way to know what
    port to keep open. Feel free to do some research on the way traceroute
    actually functions.

    > As the IPs in question are public IPs that are easily associated with
    > us (e.g., whois would tell you the CIDRs if you know the simple

    keywords
    > to ask for), traceroute to them is not going to reveal any internal
    > information about our systems...


    If I can traceroute to your systems then I can map your network which
    is quite revealing...If your letting in UDP than I can use inverse
    scans to find out what services are running on your hosts.

    > On the other hand, the ability to traceroute to those selected

    systems
    > performs the useful network management function of allowing us to

    track down
    > networking issues more easily -- track down whether, for example, the
    > service is unreachable or the host is unreachable or whether it is
    > a VPN problem, or whether a #@$ DSL modem has frozen again...


    I have no problem with being able to traceroute within a network but no
    one should be able to traceroute from outside your network to inside
    your network.

    > Recall that real-life security is not about blocking every *possible*
    > problem: real-life security is a matter of risk/benefit analysis. If
    > we get benefits from permitting selected traceroute that save us

    noticable
    > time and money in network debugging, and if the risk involved with
    > permitting the traceroute is small compared to other issues


    Most routers on the Internet will block ICMP TTL expired messages
    anyways (that's why you get asterisks in the traceroute output) so the
    value of a traceroute used on the Internet is quite negligible.

    > I don't see how one could validly say that it is "more of a

    paperweight
    > than a firewall".


    I hope that makes it clearer.
     
    Brad, Apr 9, 2005
    #6
  7. In article <>,
    Brad <> wrote:
    :There are two types of traceroutes. Windows products use ICMP/ICMP
    :while many UNIX flavors use UDP/ICMP. With the ICMP/ICMP no ports are
    :used since ICMP rides inside of IP. With UDP/ICMP, UDP uses a RANDOM
    :high port number as the destination port so there's no way to know what
    :port to keep open. Feel free to do some research on the way traceroute
    :actually functions.

    Your information is incomplete. Most Unix traceroutes use port
    numbers that increment off of a constant (to the program) base, with
    the increment being one port per hop (e.g., TTL++, port++).
    The port number is NOT random: it is confined to small ranges
    near the common base ports. There are two common base ports,
    the most common of which (by far) starts at 33434. A quick peak
    at the OpenBSD source for traceroute shows that that port number
    breaks down in the source as 32768+666 .
    http://mirror.sg.depaul.edu/pub/OpenBSD/src/usr.sbin/traceroute/traceroute.c


    :If I can traceroute to your systems then I can map your network which
    :is quite revealing

    All you can "map" is the existance of the few machines to which we
    allow traceroute -- machines whose identities are fairly easy to
    discover for anyone who takes the time to do a bit of research.

    :...If your letting in UDP than I can use inverse
    :scans to find out what services are running on your hosts.

    All you can find is the 'port unreachable' to the narrow range of
    ports we allow. As I indicated in my previous posting, on those
    servers no process ever uses the port ranges in question. As
    I indicated earlier, we do not allow general UDP, we only allow
    a very confined port range.

    :I have no problem with being able to traceroute within a network but no
    :eek:ne should be able to traceroute from outside your network to inside
    :your network.

    The justifications you gave for this do not hold up if one manages
    the port range appropriately.

    Meanwhile, we have telecommuters and remote offices. Of course we
    have VPNs to the remote offices, but if the remote firewall is
    not responding, we need a way to check to find out whether the
    problem is with the VPN or with the firewall in general, so it is
    not rare for me to log in from work to my home system so as to get
    a reachability opinion from another viewpoint.


    :Most routers on the Internet will block ICMP TTL expired messages
    :anyways (that's why you get asterisks in the traceroute output) so the
    :value of a traceroute used on the Internet is quite negligible.

    "Most routers" ? You have studies to back that up?

    Starting from one of my machines at work, I find the following:

    www.apple.com 15 of 17 hops respond, including endpoint response
    www.cia.gov 14 of ?? hops respond
    www.cisco.com 18 of 18 hops respond, including endpoint response
    www.counterpane.com 16 of 17 hops respond, including endpoint response
    www.google.com 15 of 15 hops respond, including endpoint response
    www.hp.com 20 of ?? hops respond
    www.microsoft.com 12 of ?? hops respond
    www.reuters.co.uk 19+ of ?? hops respond (router loop)
    www.slashdot.com 19 of 19 hops respond, including endpoint response
    www.sony.com 21 of 21 hops respond, including endpoint response

    The above is not "selective editing" -- those are the systems I
    tried, and those are the results I got.


    :> I don't see how one could validly say that it is "more of a paperweight
    :> than a firewall".

    :I hope that makes it clearer.

    Sorry, no it doesn't -- what it seems to indicate is that you
    have not read the traceroute source, nor even the traceroute man page
    of common traceroute implimentations such as for Linux or Solaris
    or Mac OSX or IRIX. Experimentally, your statistics also appear to
    be unjustified. Perhaps you would care to re-examine your arguments.

    http://www.die.net/doc/linux/man/man8/traceroute.8.html

    http://bama.ua.edu/cgi-bin/man-cgi?traceroute 1M

    http://www.hmug.org/man/8/traceroute.html

    http://techpubs.sgi.com/library/tpl...ame=/usr/share/catman/a_man/cat1/traceroute.z

    --
    "[...] it's all part of one's right to be publicly stupid." -- Dave Smey
     
    Walter Roberson, Apr 9, 2005
    #7
  8. Brad Guest

    None of that holds true if your tracerouting from a windows box which
    the original posts indicates is the case.
     
    Brad, Apr 9, 2005
    #8
  9. DigitalVinyl Guest

    "Brad" <> wrote:

    >If a firewall is letting a traceroute through and/or responding to one
    >then it's more of a paperweight than a firewall. :)


    I configure our firewalls to allow us to conduct traceroutes from
    network administrator stations. General population or external doesn't
    need that priv but hiding the network from the admins just makes
    things more difficult.
    DiGiTAL_ViNYL (no email)
     
    DigitalVinyl, Apr 9, 2005
    #9
  10. In article <>,
    Brad <> wrote:
    :None of that holds true if your tracerouting from a windows box which
    :the original posts indicates is the case.

    Hmmm, I seem to be a bit dense tonight. Could you perhaps re-explain
    how those "most" internet routers that supposedly disallow TTL Exceeded
    messages know whether the TTL Exceeded message was generated in
    response to a Windows box or a non-Windows box?

    Also, do I have the attributions wrong, or was it not you that said
    that traceroute uses a random UDP port? I don't quite see how
    my evidence that traceroute does NOT use a random UDP port is
    negated by the fact that Windows tracert uses icmp. Either
    you agree that we are discussing two different programs with
    different modes of operation (traceroute vs tracert), or else
    your statement about the random UDP port was incorrect anyhow.
    --
    Usenet is like a slice of lemon, wrapped around a large gold brick.
     
    Walter Roberson, Apr 9, 2005
    #10
  11. In article <d37iso$fi7$>,
    -cnrc.gc.ca (Walter Roberson) wrote:

    > In article <>,
    > Brad <> wrote:
    > :None of that holds true if your tracerouting from a windows box which
    > :the original posts indicates is the case.
    >
    > Hmmm, I seem to be a bit dense tonight. Could you perhaps re-explain
    > how those "most" internet routers that supposedly disallow TTL Exceeded
    > messages know whether the TTL Exceeded message was generated in
    > response to a Windows box or a non-Windows box?


    I think he was talking about blocking the UDP messages that Unix
    traceroute sends, not the TTL Exceeded messages sent back by the
    routers. But this type of filter won't affect Windows TRACERT, because
    it uses ICMP Echo instead of UDP. If you want to allow pings, you
    effectively allow TRACERT as well.

    But there are many sites that also block ICMP Echo, which will hamper
    both ping and TRACERT. Try www.microsoft.com, for instance.

    > Also, do I have the attributions wrong, or was it not you that said
    > that traceroute uses a random UDP port? I don't quite see how
    > my evidence that traceroute does NOT use a random UDP port is
    > negated by the fact that Windows tracert uses icmp. Either
    > you agree that we are discussing two different programs with
    > different modes of operation (traceroute vs tracert), or else
    > your statement about the random UDP port was incorrect anyhow.


    While it's not a totally random port, it's also not a single, static
    port. Assuming the user doesn't override the default with the -p
    option, the port that a particular router or firewall will still depend
    on how many hops away the sender is, because the port number is
    incremented for each hop. So if you want to block the traceroute ports,
    you have to block a fairly large range.

    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
     
    Barry Margolin, Apr 9, 2005
    #11
  12. Simon Leinen Guest

    Barry Margolin writes:
    > But there are many sites that also block ICMP Echo, which will
    > hamper both ping and TRACERT. Try www.microsoft.com, for instance.


    There are traceroute variants that can use TCP probe packets with
    given destination ports, e.g.

    lft -d 80 www.example.com
    tcptraceroute www.example.com 80

    Trying not to pick on Microsoft here, because many places have similar
    filters. Anyway, these tools can be very useful for diagnosis.
    (Of course they should only be used in the crafty hands of certified
    gurus, not by mere mortals ;-)

    And just to divert this conversation even farther from the original
    topic...

    Note that on many Unix versions of traceroute, you can use the
    "-I" flag to use ICMP ECHO requests (like Windows TRACERT) rather than
    "high-port" UDP packets as probes.

    Unless I'm mistaken, Van Jacobson used UDP probes rather than ICMP
    ECHO probes, because at the time traceroute was written, some routers
    (which were prbably called "gateways" then :) didn't send ICMP TTL
    Exceeded packets in response to ICMP (ECHO) packets. RFC 792, which
    originally defined ICMP in 1981, contained this phrase:

    To avoid the infinite regress of messages about messages etc., no
    ICMP messages are sent about ICMP messages.

    RFC 1122 (which, together with RFC 1123, contains many important
    corrections and clarifications on the "early" RFCs) restricted this to
    "no ICMP error messages are send about ICMP errors" (section 3.2.2):

    An ICMP error message MUST NOT be sent as the result of
    receiving:

    * an ICMP error message, or

    [...other types of packets, orthogonal to ICMP...]

    But that one only came out in 1989, when traceroute had already been
    written.

    Oops, I could just have Google to come up with the authoritative
    explanation:

    http://www.informatik.uni-trier.de/~smith/networks/ref/jacobson.html
    --
    Simon.
     
    Simon Leinen, Apr 10, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. -Cryogenic-©

    I'm a buckpiddaling gimp, three times!!

    -Cryogenic-©, Apr 30, 2004, in forum: Computer Support
    Replies:
    6
    Views:
    476
    Keyser Soze
    Apr 30, 2004
  2. annAnne

    Why does Windows load twice or three times

    annAnne, Sep 4, 2004, in forum: Computer Support
    Replies:
    1
    Views:
    647
    Tech Guy
    Sep 4, 2004
  3. Brian

    Did I get screwed - three times? Request $$ ?

    Brian, Aug 5, 2005, in forum: Computer Support
    Replies:
    4
    Views:
    467
    Blinky the Shark
    Aug 9, 2005
  4. MuteAnt

    Strange IP Address with Tracert, anyone know?

    MuteAnt, Nov 8, 2006, in forum: Computer Security
    Replies:
    1
    Views:
    886
    siul0_0
    Dec 7, 2006
  5. Harry Stottle
    Replies:
    0
    Views:
    1,185
    Harry Stottle
    Jan 5, 2010
Loading...

Share This Page