|
windows
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Understanding tracert outputGenerally speaking, what does it mean when the last lines of a tracert output are the same? I'm troubleshooting a network issue and found that when I do a 'tracert' to a destination address (being 'destination' any host inside the network I'm troubleshooting) the last five lines are repeated. For example, suppose aaa.bbb.ccc.ddd is the IP address of the destination host, then if I perform a tracert from a host just one hop away I get: tracert -d aaa.bbb.ccc.ddd gives: TEST #1: ====== Tracing route to aaa.bbb.ccc.ddd over a maximum of 30 hops 1 23 ms 23 ms 23 ms 200.3.60.11 2 28 ms 23 ms 23 ms aaa.bbb.ccc.ddd 3 29 ms 35 ms 35 ms aaa.bbb.ccc.ddd 4 * * * Request timed out. 5 29 ms 35 ms 35 ms aaa.bbb.ccc.ddd 6 30 ms 35 ms 35 ms aaa.bbb.ccc.ddd Trace complete. Or from the other side of the world: TEST #2: ====== [preceding hops trimmed for brevity] 10 81 ms 81 ms 81 ms 154.54.25.238 11 102 ms 99 ms 99 ms 154.54.24.154 12 113 ms 107 ms 117 ms 154.54.3.26 13 112 ms 112 ms 118 ms 154.54.2.154 14 109 ms 109 ms 110 ms 154.54.10.102 15 * * * Timeout 16 * * * Timeout 17 255 ms 257 ms 258 ms aaa.bbb.ccc.ddd 18 255 ms 256 ms 256 ms aaa.bbb.ccc.ddd 19 255 ms 255 ms 255 ms aaa.bbb.ccc.ddd 20 257 ms 256 ms 256 ms aaa.bbb.ccc.ddd 21 257 ms 256 ms 256 ms aaa.bbb.ccc.ddd As can be seen from both tests, the problem is not dependent on the host/network initiating the 'tracert'. A couple more things: 1) When the tracert is performed against my gateway (owned and configured by the ISP) the same problem happens. This rules out a misconfiguration on my part. 2) aaa.bbb.ccc.ddd belongs to a small subnet whose mask is: 255.255.255.248 ( maybe the masks are messed up somewhere outside of my scope? ) My questions: Why does this happen? What can be so badly configured (and where) such that the destination has to be probed five times before 'tracert' acknowledges that the host has been reached? How do I identify the misbehaving device? Thanks. Fernando Hi
You Tracert through the Internet into a LAN with Router, Firewalls, and close ports? Jack (MS, MVP-Networking) Show quoteHide quote "Fernando Ronci" <fernandoro***@hotmail.com> wrote in message news:Occ%2337I2JHA.1380@TK2MSFTNGP05.phx.gbl... > Hi, > > Generally speaking, what does it mean when the last lines of a tracert > output are the same? I'm troubleshooting a network issue and found that > when I do a 'tracert' to a destination address (being 'destination' any > host inside the network I'm troubleshooting) the last five lines are > repeated. For example, suppose aaa.bbb.ccc.ddd is the IP address of the > destination host, then if I perform a tracert from a host just one hop > away I get: > tracert -d aaa.bbb.ccc.ddd gives: > > TEST #1: > ====== > Tracing route to aaa.bbb.ccc.ddd over a maximum of 30 hops > > 1 23 ms 23 ms 23 ms 200.3.60.11 > 2 28 ms 23 ms 23 ms aaa.bbb.ccc.ddd > 3 29 ms 35 ms 35 ms aaa.bbb.ccc.ddd > 4 * * * Request timed out. > 5 29 ms 35 ms 35 ms aaa.bbb.ccc.ddd > 6 30 ms 35 ms 35 ms aaa.bbb.ccc.ddd > > Trace complete. > > Or from the other side of the world: > TEST #2: > ====== > [preceding hops trimmed for brevity] > 10 81 ms 81 ms 81 ms 154.54.25.238 > 11 102 ms 99 ms 99 ms 154.54.24.154 > 12 113 ms 107 ms 117 ms 154.54.3.26 > 13 112 ms 112 ms 118 ms 154.54.2.154 > 14 109 ms 109 ms 110 ms 154.54.10.102 > 15 * * * Timeout > 16 * * * Timeout > 17 255 ms 257 ms 258 ms aaa.bbb.ccc.ddd > 18 255 ms 256 ms 256 ms aaa.bbb.ccc.ddd > 19 255 ms 255 ms 255 ms aaa.bbb.ccc.ddd > 20 257 ms 256 ms 256 ms aaa.bbb.ccc.ddd > 21 257 ms 256 ms 256 ms aaa.bbb.ccc.ddd > > > As can be seen from both tests, the problem is not dependent on the > host/network initiating the 'tracert'. > > A couple more things: > 1) When the tracert is performed against my gateway (owned and configured > by the ISP) the same problem happens. This rules out a misconfiguration on > my part. > 2) aaa.bbb.ccc.ddd belongs to a small subnet whose mask is: > 255.255.255.248 ( maybe the masks are messed up somewhere outside of my > scope? ) > > My questions: Why does this happen? What can be so badly configured (and > where) such that the destination has to be probed five times before > 'tracert' acknowledges that the host has been reached? How do I identify > the misbehaving device? > > Thanks. > Fernando > > Thanks Jack,
Router --> Yes Firewall and closed ports --> No (AFAIK) As you can see this is a very very simple setup. (security hardening will come at a later stage) Fernando Show quoteHide quote "Jack-MVP" <j***@discussgroups.com> wrote in message news:eshWfVJ2JHA.5276@TK2MSFTNGP04.phx.gbl... > Hi > You Tracert through the Internet into a LAN with Router, Firewalls, and > close ports? > Jack (MS, MVP-Networking) Hi
A Router acts like a NAT firewall and close all the ports to traffic that was not generated from inside the Network. I.e. running a tracert from the outside without special port forwarding configuration would not work. Jack (MS, MVP-Networking). Show quoteHide quote "Fernando Ronci" <fernandoro***@hotmail.com> wrote in message news:uErkFlJ2JHA.1644@TK2MSFTNGP02.phx.gbl... > Thanks Jack, > > Router --> Yes > Firewall and closed ports --> No (AFAIK) > > As you can see this is a very very simple setup. (security hardening will > come at a later stage) > Fernando > > "Jack-MVP" <j***@discussgroups.com> wrote in message > news:eshWfVJ2JHA.5276@TK2MSFTNGP04.phx.gbl... >> Hi >> You Tracert through the Internet into a LAN with Router, Firewalls, and >> close ports? >> Jack (MS, MVP-Networking) > > Thanks for following up Jack,
On a clean pipe with no firewalls, no NAT, no filters, all ports open, where you have full visibility to/from the public Internet, there shouldn't be any issues with tracert (ICMP). In this context, I cannot understand why the last hop appears five times in every tracert output targeted at hosts within my subnet. My guess is that the routes are messed up on my perimeter network, but I don't know how to prove it so that I call my ISP with a solid argument. Any insights? Thanks. Fernando Show quoteHide quote "Jack [MVP-Networking]" <j***@discussiongroup.com> wrote in message news:uPkJ0YP2JHA.3544@TK2MSFTNGP04.phx.gbl... > Hi > A Router acts like a NAT firewall and close all the ports to traffic that > was not generated from inside the Network. > I.e. running a tracert from the outside without special port forwarding > configuration would not work. > Jack (MS, MVP-Networking). > Is your ISP Cox by chance? This occurred in our area about a year or so
ago. Cox claimed nothing was wrong, yet, the problem went away after some "routine" Cox net maintance. Show quoteHide quote "Fernando Ronci" <fernandoro***@hotmail.com> wrote in message news:ea9SUMV2JHA.3676@TK2MSFTNGP06.phx.gbl... > Thanks for following up Jack, > > On a clean pipe with no firewalls, no NAT, no filters, all ports open, > where you have full visibility to/from the public Internet, there > shouldn't be any issues with tracert (ICMP). > In this context, I cannot understand why the last hop appears five times > in every tracert output targeted at hosts within my subnet. My guess is > that the routes are messed up on my perimeter network, but I don't know > how to prove it so that I call my ISP with a solid argument. Any insights? > > Thanks. > Fernando > > > "Jack [MVP-Networking]" <j***@discussiongroup.com> wrote in message > news:uPkJ0YP2JHA.3544@TK2MSFTNGP04.phx.gbl... >> Hi >> A Router acts like a NAT firewall and close all the ports to traffic that >> was not generated from inside the Network. >> I.e. running a tracert from the outside without special port forwarding >> configuration would not work. >> Jack (MS, MVP-Networking). >> > > |
|||||||||||||||||||||||