Is this packet loss?

<ctrl>xx i<ctrl>xx i Member Posts: 2 ■□□□□□□□□□
Hi,

Let me say upfront I'm sorry if this is a stupid question or if I make a mess of trying to get my point across!

I've often noticed when I running a traceroute that one of the three responses for a "hop" can sometimes be a *.

So is the * a sign of packet loss?

I understand how traceroute works, incrementing the ttl value by one with each "hop" until it reaches it's destination.

I believe that traceroute sends three different ICMP packets to each "hop" thus giving us a set of three response times for each "hop". I'm aware that if one of the "hop" in the traceroute was loadbalancing between links then the path to the next "hop" in the traceroute will be different for the 1st and 2nd sets of ICMP packets.

Hope your still with me confused.png.

When the 1st set of ICMP packets pass through the loadbalancing "hop" they will be sent one direction and when the 2nd set of ICMP packets pass through the loadbalancing "hop" they will be sent a different direction. Should a node further along that link be down I can see how this could results in a * being returned.

However I have seen the second response for a "hop" be a star even when I know there are one a couple of routers between the source and destination devices and no load balancing is occouring.

I have checked all the cables and there were no problems.

Phew :) hopefully that makes sense to someone out there. If anyone can help me better understand whats happening here I'd appreciate it

Comments

  • GiddyGGiddyG Member Posts: 89 ■■□□□□□□□□
    The star/asterisk means that the router is busy or that link is slow. It's just taken longer than the normal time out allowed. You still got through.
    WIP:

    CCENT; CCNA; CWSP; 70-680; CompTIA Stitchup+
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    For starters, try using MTR or WinMTR, it tends to be better at diagnosing.

    Secondly - a random * here and there does not mean you're seeing packet loss. It usually means the router is employing CoPP (Control Plane Protection) and is just dropping ICMP. This is an anti-DDoS measure.

    If you start seeing *'s in every hop thereafter, then you're probably taking some packet loss, but if it's in like 2 hops in the entire traceroute, it's not much to worry about
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Ok, just to give you an idea of what packet loss actually looks like -

    The output below can be read as the following -

    Hop Hostname %PacketLoss #Packets sent, the rest are latency timers and the standard deviation, but we don't need them for the purposes of this discussion. I've also masked some of the hostnames

    1. xxx.xxx.xxx 0.0% 10 15.1 15.9 12.6 30.0 5.0
    2. xxx.xxx.xxx 0.0% 10 22.7 15.7 13.3 22.7 2.9
    3. xxx.xxx.xxx 0.0% 10 22.6 17.6 13.0 22.6 3.5
    4. xxx.xxx.xxx 0.0% 10 16.3 19.2 14.0 48.5 10.4
    5. telia.tengigabitethernet7-2. 0.0% 10 15.5 18.3 12.8 45.8 9.7
    6. ash-bb1-link.telia.net 0.0% 10 38.7 33.1 28.4 38.7 3.8
    7. ldn-bb2-pos6-0-0.telia.net 30.0% 10 108.8 109.8 103.1 122.5 7.0
    8. adm-bb3-link.telia.net 30.0% 10 149.0 118.1 111.0 149.0 13.7
    9. adm-b2-link.telia.net 60.0% 10 120.1 120.1 114.5 131.4 7.9
    10. adm-evo-i2-link.telia.net 30.0% 10 114.8 114.0 112.1 116.3 1.4
    11. leaseweb-ic-126777-adm-evo.c 60.0% 10 114.8 129.6 114.8 154.9 17.6
    12. po100.sr1.evo.leaseweb.net 30.0% 10 116.9 116.2 112.3 120.9 3.1
    13. te5-1.sr5.evo.leaseweb.net 50.0% 10 113.3 113.2 111.0 115.4 1.6
    14. xxx.xxx.xxx 30.0% 10 121.1 119.8 115.2 127.0 4.7

    As you can see, around hop #7, packet loss is shown, and it continues all the way down to the last node. That's a good sign the packet loss is real. Now, if nodes 7 and 11 showed a bit of packetloss, but everyone else was 100%, that would more likely than not be CoPP kicking in.

    Bonus points if you can identify which link was actually the cause of the problem
  • <ctrl>xx i<ctrl>xx i Member Posts: 2 ■□□□□□□□□□
    Thanks for the replys guys.

    Forsaken_GA - Is it the preceding link between
    6. ash-bb1-link.telia.net and 7. ldn-bb2-pos6-0-0.telia.net ?
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Hi there,

    Yeah, link #6 is reponsible. It receives traffic with no packet loss, but when it forwards it on to the next node, packet loss occurs, so that's the node that's at fault.

    Funny thing is, it happened to us twice. The first time, they told us that they screwed up a QoS setting, and best effort traffic was getting dropped, despite the link not being saturated enough for it to kick in.

    The second time they told us it was a duplex mismatch.

    Telia makes me want to go postal sometimes.
Sign In or Register to comment.