I was going to say the same thing
example pathping:
Tracing route to mdf1-bi8k-1-ve-87.phx1.attens.net [63.241.138.161]
over a maximum of 30 hops:
0 KIMCHIZ [192.168.1.100]
1 192.168.1.1
2 10.75.128.1
3 24-234-8-58.ptp.lvcm.net [24.234.8.58]
4 24-234-6-28.ptp.lvcm.net [24.234.6.28]
5 dllsdsrc02-pos0901.rd.dl.cox.net [68.1.0.149]
6 xe-5-0-0.edge2.LosAngeles9.Level3.net [4.53.230.81]
7 ae-105-3505.bar2.Tustin1.Level3.net [4.69.158.98]
8 ae-105-3505.bar2.Tustin1.Level3.net [4.69.158.98]
9 192.205.37.145
10 cr1.la2ca.ip.att.net [12.122.128.102]
11 cr2.phmaz.ip.att.net [12.122.31.190]
12 12.123.158.129
13 * * *
Computing statistics for 300 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 KIMCHIZ [192.168.1.100]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.1
0/ 100 = 0% |
2 8ms 0/ 100 = 0% 0/ 100 = 0% 10.75.128.1
0/ 100 = 0% |
3 9ms 0/ 100 = 0% 0/ 100 = 0% 24-234-8-58.ptp.lvcm.net [24.234.8.58]
0/ 100 = 0% |
4 10ms 0/ 100 = 0% 0/ 100 = 0% 24-234-6-28.ptp.lvcm.net [24.234.6.28]
0/ 100 = 0% |
5 18ms 0/ 100 = 0% 0/ 100 = 0% dllsdsrc02-pos0901.rd.dl.cox.net [68.1.0.149]
0/ 100 = 0% |
6 23ms 0/ 100 = 0% 0/ 100 = 0% xe-5-0-0.edge2.LosAngeles9.Level3.net [4.53.230.81]
17/ 100 = 17% |
7 18ms 17/ 100 = 17% 0/ 100 = 0% ae-105-3505.bar2.Tustin1.Level3.net [4.69.158.98]
7/ 100 = 7% |
8 18ms 26/ 100 = 26% 2/ 100 = 2% ae-105-3505.bar2.Tustin1.Level3.net [4.69.158.98]
0/ 100 = 0% |
9 50ms 24/ 100 = 24% 0/ 100 = 0% 192.205.37.145
76/ 100 = 76% |
10 --- 100/ 100 =100% 0/ 100 = 0% cr1.la2ca.ip.att.net [12.122.128.102]
0/ 100 = 0% |
11 --- 100/ 100 =100% 0/ 100 = 0% cr2.phmaz.ip.att.net [12.122.31.190]
0/ 100 = 0% |
12 --- 100/ 100 =100% 0/ 100 = 0% 12.123.158.129
Trace complete.
And this has been going on for months now. Not sure this is something that Cox can fix though.
Whether it's a tracert, or pathping, I have always seemed to notice that Level3 @ LA has come up. Above example shows big issue at Tustin1 too though.