We have been seeing this issue accross multiple of our clients on and off over that past several months. Today we were finally able to get traceroutes from multiple client networks at multiple geographic locations at the A and Z ends. So far we have seen the issue from Lexington KY to Wilmington PA, Dayton OH to Wilmington PA, Columbia SC to Columbus OH, Dayton OH to Columbus OH, Winchester KY to Columbus OH. The issue does not appear to affect general Internet traffic, only certain protocols -- we have noticed it due to our L2L VPN tunnels between these geographic locations intermittently being unable to pass IPsec VPN traffic.
The attached photos illustrate a traceroute with probe 10/50 for repeated traceroute data.
There is definitely an issue at this hop and I am so relieved we are not the only one experiencing this. We have been fighting with Spectrum over this for almost three months now with absolutely zero progress.
Where are you at Spectrum !?
Here is a previous thread on the same topic --
Another note my colleagues wanted me to mention, is the flat out rude and irresponsive nature of Spectrum we have suffered through these past two to three months. We have engaged Spectrum COUNTLESS times throughout this period, and been met with an almost identical response each time: it is not our problem. During one call, I remember repeating, "So what you are saying is that you are refusing to cooperatively test and troubleshoot with us?" The technician would not say "Yes", and semed to genuinely feel sorry I was having trouble, which leads me to believe that this is how they are trained to respond when their customer is having difficulty -- NOT ACCEPTABLE SPECTRUM!
If the original complainant @joshuabiddle can provide complete (unedited) tracert output listings which include the device names and the column headers, we could more easily determine if the device at that IP address is indeed an edge router linked to a 3rd party IXP (which we both suspect). I did see that the next device downstream did not respond to ping requests, which is standard networking practice when crossing from backbone transport over to an IXP.