What does the 50 percent ping loss indicate on line 9 of the attached.
Notice there is no ping loss AFTER line 9, so it is only dropping pings TO the router, is that right?
Notice however the increase in ping times, which DO continue to further lines of the display, this indicates the router is slowing down packets through it but only dropping pings TO it.
Don’t forget that chassis routers of ISP’s have separated control plane and forwarding plane. These routers in trace don’t have to answer to you with shortest time stamp, because ICMP being answered on their CPU’s. Data flows much faster through them than in them.
However you say that data flows much faster through them than in them, does this include pings that are passed through the routers to later routers but with higher latencies that persist to the end of the traceroute. Are real packets suffering the same latency?
It is clear that a router can return a ping answer when and if it wants to, or not at all, showing ‘packet loss’, without affecting actual throughput at all.
But latencies that go high after a particular router, and continue to remain high forever afterwards, what does that indicate? Since there is no more ping loss on later routers, it is obvious that the pings to later routers
are being passed in real time by the earlier router, but then how come the latencies are higher on the
later routers?
Does that mean the higher latencies only apply to ping going through the later routers, or are all
packets so affected?
And I’m considering buffering as part of reason #2.
The processing in a given node might be due to some firewalling, traffic shaping, complex routing decission, etc. Or due to TTL expired and node needs to reply with TTL expired. Which is understandably a low priority task, hence delay which might be higher than the one for real traffic. But this only applies to the node where TTL drops to 0, previous nodes should pass the probing packet with normal priority and the ICMP TTL exceeded reply packet as well.
I’d say that increase in RTT at/after some node doesn’t really show which reason is causing increase in delay. Perhaps if RTT to the node is longer than RTT to later nodes thus could mean processing issues at that particular node - congestion/queuing on connection towards next hop should not affect generation of TTL expired packet. Partial ping loss IMHO indicates processing issues at that particular node as well … unless configured intentionally which personally I would never do myself.
ICMP packets forwarded through bunch of routers processing as faster as possible by special chips. Don’t worry about latency. Only optical wired range does latency higher.
In tracing you see replies from each router only. This is not about real regular fast process.