Forum Discussion

wcm's avatar
wcm
New Contributor II
9 months ago

HEAVY Packet loss between 172.27.11.78 and 68.1.4.42 (chgopbrj01-ae0.rd.ch.cox.net)


Any one else seeing heavy packet loss (74%) between these two IPs?

Target Name: dns.google
         IP: 8.8.8.8
  Date/Time: 1/9/2024 08:56:30 - 1/9/2024 09:06:30

Hop  Sent  PL%    Min    Max    Avg  Host Name / [IP]
  2   239    0   7.21  53.37  10.47  10.98.0.1 [10.98.0.1]
  3   239    0   6.82  34.69  10.30  172.27.0.152 [172.27.0.152]
  4   239    0   8.22  40.64  12.06  172.27.11.78 [172.27.11.78]
  5   239   74  17.43  33.82  20.59  chgobprj01-ae0.rd.ch.cox.net [68.1.4.42]
  6   239    2  19.26  54.18  23.22  70.167.150.66 [70.167.150.66]
  7   239    0  17.80  36.28  20.81  142.251.64.199 [142.251.64.199]
  8   239    0  17.35  27.70  19.70  142.251.60.23 [142.251.60.23]
  9   239    0  16.81  48.26  20.02  dns.google [8.8.8.8]

  • Found this:


    https://forums.cox.com/discussions/internet/slow-trace-route-wtime-outs/149845

  • wcm's avatar
    wcm
    New Contributor II

    Found this:


    https://forums.cox.com/discussions/internet/slow-trace-route-wtime-outs/149845

    • ExtraChrispy's avatar
      ExtraChrispy
      Contributor III

      What you're seeing there looks more like ICMP de-prioritization and not really packet loss.  If packet loss was occurring, you'd see it all the way through to the destination.  If you think about it for a moment, how is it possible to reach your destination without packet loss if you're traffic is going through a hop that is dropping packets?

      • WiderMouthOpen's avatar
        WiderMouthOpen
        Esteemed Contributor

        While I don't disagree with you about this issue, I think there was something weird going on with Cox routing in general. If you read the post OP referenced you will see latency spikes that follow through to the destination. ae2.rd.la.cox.net more specifically, which looks similar to ae0.rd.ch.cox.net but I am not familiar with Cox's naming scheme. I think it is semi resolved now. If OP still has the problem, I suggest using Pingplotter and changing the traffic type to either TCP or UDP and see if the "issue" still occurs.

  • wcm's avatar
    wcm
    New Contributor II

    Everything is back to normal.  Disabled VPN and tested.

    I 100% agree about the ICMP de-prioritization and what it looks like.  Just ping -n 1000 8.8.8.8, resulted in 10 - 20 % dropped pings as well.  Switched to the VPN solution and the ping -n 1000 8.8.8.8 went to 0% dropped. 

    I was using 8.8.8.8 for my primary DNS.  I switched to 1.1.1.1, which did not see any packet loss.  However, I did not think about switching primary DNS until after disabling the VPN and everything returned back to normal.