Slow connection. Source found! Bad Cox server. Cox rep can't help?

First, can you share your entire data set? Can you show the latency in context of a tracert or pathping or any document you can export from your tracert tool. Just knowing the IP in question doesn't help. It needs context.

Second, I highly doubt internet traffic can be re-routed with a simple mouse click. I think you are underestimating the complexity of network management. A good NOC tech doesn't even need a mouse. It's all CLI. :-)

This pops up every so often - traceroute not showing responses from specific servers indicates virtually nothing unless it doesn't get past that hop - traceroute packets and pings are usually set to the absolute lowest priority for a router to respond to - so you need to see if it continues past that node - here's some instructions on reading a tool called MTR that does a GUI version of traceroute.

https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr

If the loss continues for more than one hop, than it is possible that there is some packet loss or routing issues. Remember that rate limiting and loss can happen concurrently. In this case, take the lowest percentage of loss in a sequence as the actual loss.

I know was I being overly simple about it taking a click of the mouse to fix it. I know you IT people have a better way ;-)

Here's the traceroute detail. I hope this helps. At three attempts, different times of the day, when the "problem" occurs, traceroute shows the same three IPs with issues and one of the three failing.  PS: Local chat is that there's an ongoing intermittent outage through our area. Using the "check for outages" link on Cox's website, anywhere that link appears, goes to account management page.  There is no way to check for outages. You would think Cox would want to be very clear about outages----to acknowledge and fix them. 

-------------------------------

1
208-64-36-1.p2.agr3.troy2.waveform.net
(208.64.36.1)
0.439 ms
0.377 ms
0.237 ms
2
core5.tym.r256.net
(173.225.185.37)
0.502 ms
0.475 ms
0.488 ms
3
core8.tym.r256.net
(173.225.191.126)
0.491 ms
0.312 ms
0.487 ms
4
vlan259.car1.detroit1.level3.net
(4.31.123.97)
11.746 ms
8.985 ms
1.732 ms
5
ae-3-80.edge2.losangeles9.level3.net
(4.69.144.143)
64.220 ms
64.572 ms

ae-4-90.edge2.losangeles9.level3.net
(4.69.144.207)
64.195 ms

6
cox-communi.edge2.losangeles9.level3.net
(4.53.230.222)
64.368 ms

cox-communi.edge2.losangeles9.level3.net
(4.53.230.90)
64.375 ms

cox-communi.edge2.losangeles9.level3.net
(4.53.230.42)
64.609 ms

7
68.1.1.170
(68.1.1.170)
66.607 ms

68.1.1.60
(68.1.1.60)
66.114 ms

68.1.1.170
(68.1.1.170)
66.860 ms

8
68.4.15.27
(68.4.15.27)
70.015 ms
70.401 ms

68.4.15.43
(68.4.15.43)
68.688 ms

9
68.4.15.11
(68.4.15.11)
69.848 ms

68.4.15.43
(68.4.15.43)
68.371 ms

68.4.15.11
(68.4.15.11)
69.262 ms

10
-
-
*
*
*
11
-
-
*
*
*
12
-
-
continues for 30 attempts.

---------------------------------

Somehow your paste indicates you are trying to traceroute from outside the cox network to a destination in the cox network.

That's not really how that works, as most consumer network equipment won't even respond to pings, by design.

Now, if you are on a business line, with some sort of dedicated server with a static IP, that is a different story.

Unfortunately I have no idea the destination you are trying to reach, so have no way of checking things from my end.

Try doing a traceroute to several different places from inside the cox network -

8.8.8.8

microsoft.com

bbc.co.uk

All of those are decent targets, the BBC one is even good for getting an idea for transcontinental routes.

Try using a program like WinMTR at http://winmtr.net/

Hi Larrybic,

I'm also unable to follow your traceroute results. Are you able to post results per Grymwulf’s suggestion?

You aren't getting packet loss (atleast not in that data) , it looks like you are hitting Cox's firewall which stops the ICMP packet from returning. 

I think your security company is tunneling their upstream through Level 3 and you are hitting some latency. 55ms from Chigaco to LA is not that bad though. What is it usually? 

+1 for seeing a normal tracert or pathping from the Cox service location. This will show how you are connecting to Cox's network and how your traffic leaves it.

Here's the traceroute  using Mac OS built-in network utility.  two attempts to googleDNS.  I did a few more to various locations. Our service remains intermittent, consistently  showing a delay one minute and no problem the next. As of this moment,  and for the last 20 minutes, it is working perfectly, so I cannot post a trace route showing a problem, other than the minor one, below.  I will when/if I see a problem later. Now, it's time to read a good book.  Thanks for the assistance!

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
1 10.0.1.1 (10.0.1.1) 1.999 ms 1.121 ms 1.129 ms
2 10.6.16.1 (10.6.16.1) 12.450 ms 9.856 ms 15.702 ms
3 68.4.15.26 (68.4.15.26) 12.328 ms 12.253 ms 11.647 ms
4 ip68-4-11-96.oc.oc.cox.net (68.4.11.96) 26.723 ms 16.964 ms 15.403 ms
5 68.1.1.171 (68.1.1.171) 18.778 ms 19.741 ms 32.862 ms
6 langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181) 16.624 ms 17.544 ms 17.295 ms
7 216.239.59.219 (216.239.59.219) 23.193 ms 17.533 ms 17.431 ms
8 209.85.249.223 (209.85.249.223) 17.908 ms 17.369 ms 16.621 ms
9 google-public-dns-a.google.com (8.8.8.8) 16.769 ms 16.168 ms 25.252 ms

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
1 10.0.1.1 (10.0.1.1) 1.373 ms 1.239 ms 1.249 ms
2 10.6.16.1 (10.6.16.1) 2044.033 ms 9.098 ms 12.107 ms
3 * * *
4 * * *
5 68.1.1.171 (68.1.1.171) 2378.625 ms 123.473 ms 323.394 ms
6 * langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181) 3209.109 ms *
7 * 216.239.59.219 (216.239.59.219) 871.086 ms 26.798 ms
8 209.85.249.223 (209.85.249.223) 25.689 ms 25.879 ms 25.037 ms
9 google-public-dns-a.google.com (8.8.8.8) 19.994 ms 24.038 ms 37.310 ms

Wife, on another machine doing school admin work just shouted "it's down again!"  So, here's one that took about 10 seconds to complete. 

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

 1  10.0.1.1 (10.0.1.1)  1.409 ms  1.287 ms  1.132 ms

 2  * 10.6.16.1 (10.6.16.1)  3720.901 ms  1806.070 ms

 3  * * *

 4  * * ip68-4-11-96.oc.oc.cox.net (68.4.11.96)  189.789 ms

 5  68.1.1.171 (68.1.1.171)  16.859 ms  19.450 ms  16.579 ms

 6  langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181)  21.894 ms  18.739 ms  16.616 ms

 7  216.239.59.219 (216.239.59.219)  16.894 ms  16.254 ms  16.938 ms

 8  209.85.249.223 (209.85.249.223)  17.068 ms  17.898 ms  18.413 ms

 9  google-public-dns-a.google.com (8.8.8.8)  18.312 ms  15.501 ms  16.841 ms

Could this be something simple like a loose coax connection right here or on the street or......? As I watch Apple's Airport Utility GUI, every time there's a timeout or * in the traceroute, the internet light goes from green to yellow [no connection].  Green is  all good. Here's the traceroute when all ok and when connection slows or fails.

Traceroute has started… 14.21.34

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

 1  10.0.1.1 (10.0.1.1)  2.785 ms  1.072 ms  0.997 ms

 2  * * 10.6.16.1 (10.6.16.1)  1148.097 ms

 3  * * *

 4  * * *

 5  * * *

 6  langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181)  2719.423 ms  16.527 ms  17.366 ms

 7  216.239.59.219 (216.239.59.219)  23.338 ms  16.575 ms  18.536 ms

 8  209.85.249.223 (209.85.249.223)  20.924 ms  19.399 ms  18.708 ms

 9  google-public-dns-a.google.com (8.8.8.8)  22.170 ms  19.115 ms  20.571 ms

Traceroute has started… 14.22.07

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

 1  10.0.1.1 (10.0.1.1)  3.424 ms  1.044 ms  0.947 ms

 2  10.6.16.1 (10.6.16.1)  14.556 ms  13.814 ms  16.056 ms

 3  68.4.15.26 (68.4.15.26)  26.958 ms  13.493 ms  12.219 ms

 4  ip68-4-11-96.oc.oc.cox.net (68.4.11.96)  15.651 ms  16.835 ms  12.677 ms

 5  68.1.1.171 (68.1.1.171)  20.204 ms  15.008 ms  17.600 ms

 6  langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181)  23.100 ms  15.510 ms  18.241 ms

 7  216.239.59.219 (216.239.59.219)  25.548 ms  23.093 ms  20.033 ms

 8  209.85.249.223 (209.85.249.223)  18.216 ms  22.387 ms  21.569 ms

 9  google-public-dns-a.google.com (8.8.8.8)  19.474 ms  19.552 ms  21.323 ms

Traceroute has started…  14.26.03

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

 1  10.0.1.1 (10.0.1.1)  2.145 ms  1.066 ms  1.372 ms

 2  * * *

 3  * 68.4.15.26 (68.4.15.26)  3950.654 ms  10.806 ms

 4  ip68-4-11-96.oc.oc.cox.net (68.4.11.96)  20.026 ms  302.178 ms  15.331 ms

 5  68.1.1.171 (68.1.1.171)  1244.460 ms  20.160 ms  1319.240 ms

 6  langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181)  433.725 ms  180.878 ms *

 7  216.239.59.219 (216.239.59.219)  3841.931 ms  16.713 ms  15.810 ms

 8  209.85.249.223 (209.85.249.223)  17.162 ms  20.446 ms  16.807 ms

 9  google-public-dns-a.google.com (8.8.8.8)  18.552 ms  24.633 ms  18.531 ms

Traceroute has started… 14.30.10

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

 1  10.0.1.1 (10.0.1.1)  121.471 ms  1.090 ms  0.969 ms

 2  10.6.16.1 (10.6.16.1)  4818.784 ms * *

 3  * * 68.4.15.26 (68.4.15.26)  1205.600 ms

 4  ip68-4-11-96.oc.oc.cox.net (68.4.11.96)  52.785 ms * *

 5  * * 68.1.1.171 (68.1.1.171)  968.760 ms

 6  langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181)  26.388 ms  46.285 ms  15.787 ms

 7  216.239.59.219 (216.239.59.219)  16.669 ms  22.393 ms  18.399 ms

 8  209.85.249.223 (209.85.249.223)  18.944 ms  21.615 ms  39.829 ms

 9  google-public-dns-a.google.com (8.8.8.8)  78.977 ms  128.177 ms  318.693 ms

 

Traceroute has started… 14.30.47

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

 1  10.0.1.1 (10.0.1.1)  3.076 ms  1.072 ms  1.039 ms

 2  10.6.16.1 (10.6.16.1)  46.296 ms  31.378 ms  75.030 ms

 3  68.4.15.26 (68.4.15.26)  51.393 ms  45.449 ms  36.882 ms

 4  ip68-4-11-96.oc.oc.cox.net (68.4.11.96)  52.206 ms  38.757 ms  95.216 ms

 5  68.1.1.171 (68.1.1.171)  53.999 ms  49.346 ms  52.650 ms

 6  langbbrj01-ge050000804.r2.la.cox.net (68.105.30.181)  81.776 ms  49.529 ms  52.784 ms

 7  216.239.59.219 (216.239.59.219)  45.974 ms  50.653 ms  46.104 ms

 8  209.85.249.223 (209.85.249.223)  57.878 ms  45.450 ms  57.568 ms

 9  google-public-dns-a.google.com (8.8.8.8)  44.842 ms  59.440 ms  44.846 ms

Both of your most recent traceroutes do indicate reaching the final destination - the problem you are seeing is that several of the routers don't appear to be forwarding a TTL expired ICMP packet - probably due to load.

If it was down, you wouldn't even be able to reach 8.8.8.8 at anything resembling a reasonable ping.

Your 3 hops (10.6.16.1 +1 and 68.4.11.96) all had severally slow pings.  So that could be showing heavy load as mentioned earlier.  But it also appears that packets that go beyond them do get very fast responses.

I'd try running a program called ping plotter during the time you are having the issue(s) - I don't necessarily like the way it presents data but it does give you a running packetloss total and average ping response from destination.

As a side note, my wife used to have a very similar problem to what you are mentioning, but in that case it was due to wonky drivers for her Intel AC 3165 wifi on her laptop.

Now again, it does look like there is some delayed response from individual routers along the route, but the overall response seems in line with normal operation.  I'd be more worried by packet loss, or that the final destination was unreachable.

FYI Trace Route operates weirdly.  It sends out ping packets to your destination with an increasing TTL (in other words the maximum number of 'hops' it allows), and when the TTL expires a router is supposed to send a notice back that your packet stopped at that destination.  However, that response/notice packet is usually set to the lowest possible priority (don't want to slow down actual services!) - so individual responses from specific routers don't mean too much; it actually tends to give false positives.  The useful thing about trace route is that it gives you the specific path your packets go along so that a network admin/operator can check the individual routers along the route for load or other issues.