0

My Internet is really laggy today, I did a tracerout and I realize that I'm having no answer from an ip at the beginning of the traceroute. see:

Tracing route to 12.129.202.154 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.0.1 
  2     *        *        *     Request timed out.
  3     8 ms     8 ms     8 ms  bd044008.virtua.com.br [189.4.64.8] 
  4     9 ms     8 ms     8 ms  bd044009.virtua.com.br [189.4.64.9] 
  5    26 ms    26 ms    24 ms  embratel-T0-1-5-0-tacc01.cas.embratel.net.br [200.174.243.21] 
  6   360 ms    15 ms    12 ms  ebt-T0-15-0-12-tcore01.ctamc.embratel.net.br [200.244.140.218] 
  7   330 ms   349 ms   261 ms  ebt-Bundle-POS11942-intl04.mianap.embratel.net.br [200.230.220.10] 
  8   139 ms   141 ms   139 ms  sl-st30-mia-.sprintlink.net [144.223.64.221] 

Connection diagram: PC - Router configured as access point - Router (192.168.0.1) - Cable modem (192.168.100.1).

Well, I think it is odd that the 2nd ip is not returning the ping. I looked some old tracerout logs to see what was the 2nd ip. The ip was: 10.19.0.1

So, what this 2nd ip stand for? How can I find why it is not answering the ping? I don't understand it, if does not answer the ping, how can the packets continue (yeah newbie question)?


edit: well, because the hope 3 have a ping of 8 ms the hop 2 request time out should really not be a problem. But it is still odd that the 2nd hop stopped to answer ping request. So my doubts are:
1. Were the ip 10.19.0.1 is from?
2. Why it stopped to answer ping requests?
3. How can hop 7 be smaller than 6 and 8 smaller than 7 and 6!?? Shouldn't the pings be higher for each hop? Like: hop 3 time should be the sum of the hops before it plus its own time (hop 3 = 1+2+3) ??

3
  • To answer part of your edit: Because when you run tracert each hop is responding to traffic TO it not THROUGH it. My guess is that hop 3 is giving low priority to ICMP packets sent TO it. If you really want to test the latency of the path you need to test it with "real" traffic.
    – joeqwerty
    Oct 23, 2013 at 1:30
  • Traceroute results are not really cumulative. Each hop responds independently of every other hop. If hop 2 had latency and packet loss and hop 3 and all subsequent hops had higher latency and packet loss than hop 2 only then would I think there was a problem in the path.
    – joeqwerty
    Oct 23, 2013 at 1:32
  • @joeqwerty, how can I test with "real" traffic? well, it is really odd to me. I would be glad if you point some site that this isue is explained in more details.
    – Pedro77
    Oct 23, 2013 at 1:39

1 Answer 1

7

A router's job is to route packets. It's not a ping responder. It can route packets just fine even if it can't respond to pings. Since you're seeing latency of less than a hundredth of a second to the hop after it and no packet loss, I'd say it's routing just fine.

How can hop 7 be smaller than 6 and 8 smaller than 7 and 6!?? Shouldn't the pings be higher for each hop? Like: hop 3 time should be the sum of the hops before it plus its own time (hop 3 = 1+2+3) ??

Because some routers are great routers and lousy traceroute responders. That's not their main job, so they're generally not optimized for it. When your traceroute stops on a hop, you're measuring that hop's ability to respond to a traceroute. When it goes through a hop, you're measuring its ability to forward traffic. If you were designing a router, which would you optimize?

There's another possibility, but it's not common. The route could be asymmetric. If the longer route takes a better return path, the time can be lower.

6
  • Boy I wish more people understood how traceroute works.
    – joeqwerty
    Oct 23, 2013 at 1:10
  • Ok, but why it was responding the ping before? The ip 10.19.0.1 was from my router too? What I really don't understand is how can a hop have higher time than the hop after it (ex: hop 3 = 150 ms, hop 4 = 50 ms)? I have edited my question.
    – Pedro77
    Oct 23, 2013 at 1:29
  • @David, can you please take a look at the edit? thanks
    – Pedro77
    Oct 23, 2013 at 1:35
  • 1
    Great answer...and to further corroborate from Cisco themselves: "When a packet destination is the router itself, this packet has to be process-switched. The processor has to handle the information from this packet, and send an answer back. This is not the main goal of a router. By definition, a router is built to route packets. Answering a ping is offered as a best-effort service."
    – TheCleaner
    Oct 23, 2013 at 2:25
  • @Pedro77 See updates. Oct 23, 2013 at 3:53

Not the answer you're looking for? Browse other questions tagged .