Forum Discussion

Robion3090's avatar
Robion3090
New Contributor
2 years ago

Loss on langbprj01-ae1.rd.la.cox.net

Hey there, 

Still seeing more loss on  langbprj01-ae1.rd.la.cox.net Is there anyway to escalate this to the appropriate individuals at COX ? This is causing a huge problem for me professionally in a work from home setting. 

This seems to be a consistent issue I have been monitoring closely with various tools for verification. Systematically this appears in various ways everything from latency on applications to overall performance impact.

0/ 100 = 0% |
2 11ms 0/ 100 = 0% 0/ 100 = 0% 10.130.120.1
0/ 100 = 0% |
3 12ms 0/ 100 = 0% 0/ 100 = 0% 100.127.73.70
0/ 100 = 0% |
4 14ms 0/ 100 = 0% 0/ 100 = 0% 100.120.100.4
0/ 100 = 0% |
5 --- 100/ 100 =100% 100/ 100 =100% langbprj01-ae1.rd.la.cox.net [68.1.1.13]
0/ 100 = 0% |
6 27ms 0/ 100 = 0% 0/ 100 = 0% 68.105.30.130
0/ 100 = 0% |
7 223ms 0/ 100 = 0% 0/ 100 = 0% ae1-br01-eqla1.as57976.net [137.221.68.33]

8 hours later : 
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0/ 100 = 0% |
2 11ms 0/ 100 = 0% 0/ 100 = 0% 10.130.120.1
0/ 100 = 0% |
3 12ms 0/ 100 = 0% 0/ 100 = 0% 100.127.73.70
0/ 100 = 0% |
4 14ms 0/ 100 = 0% 0/ 100 = 0% 100.120.100.4
0/ 100 = 0% |
5 --- 100/ 100 =100% 100/ 100 =100% langbprj01-ae1.rd.la.cox.net [68.1.1.13]
0/ 100 = 0% |
6 28ms 0/ 100 = 0% 0/ 100 = 0% 68.105.30.130
0/ 100 = 0% |
7 189ms 0/ 100 = 0% 0/ 100 = 0% ae1-br01-eqla1.as57976.net [137.221.68.33]

  • beep's avatar
    beep
    New Contributor II

    the ae1 host name is a Juniper interface naming scheme.  Assuming it is a juniper router, it takes 1 keyword of “rapid” to rate limit this traffic.  Many router and switching vendors tend to limit traffic like this so using trace route and pinging hops is not going to be a good metric for determining an issue.  The traffic still is getting to the destination (as seen by hops 6/7/8) so traffic is still flowing despite this individual hop failing to respond to icmp 

  • WiderMouthOpen's avatar
    WiderMouthOpen
    Esteemed Contributor

    Try using Pingplotter. You can change the packet type to TCP or UDP instead of the test packet ICMP. Looks ICMP deprioritization to me but I am no engineer. IMO If it was real packet loss you would see it continue in hop 6 and 7.

    • Darkatt's avatar
      Darkatt
      Honored Contributor

      Pretty much what I was thinking, that's why i provided info on ping. It's too bad that these sites that tell people to use ping to see what's not responding doesn't provide more accurate information. 

      • WiderMouthOpen's avatar
        WiderMouthOpen
        Esteemed Contributor
        It's too bad that these sites that tell people to use ping

        What sites?

        Also, if it's easier and you have a Mac laptop, try a trace from it. Pretty sure MacOS uses UDP for their traces.

  • Darkatt's avatar
    Darkatt
    Honored Contributor

    Just a reminder, ping tests are not accurate, nor or ping on traceroutes, due to the fact a ping is the lowest level of communication priority, and if the router is busy, it will ignore the ping request and time them out.