Highlighted

Traffic issues at 66.109.7.162

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 -- 

https://forums.timewarnercable.com/t5/Connectivity/Routing-issues-with-routes-including-66-109-7-162...

 

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!

 

screenshot3.jpgscreenshot2.jpg

2 REPLIES 2
Highlighted
Established Sharer

Re: Traffic issues at 66.109.7.162

It may be an issue with Level3 or other third party peering provider, and not Spectrum.

Reminds me of a case filed with the FCC about 20 years ago or something where one side of the exchange point had plenty of bandwidth availble, but the service on the other end (Verizon IIRC) was not willing to update their hardware for more bandwidth. It wasn't much more than installing a 10gb interface (some routers are designed for upward scalability like that), and patching it in. It was one of the cases that sparked the push for the net neutrality debate.

Sometimes things just get choked down switching to someone else's network. Not necessarily an issue for Spectrum to resolve... may depend on the language of the peering arrangement on play. There may not be any recourse for Spectrum to lean on a third party if the bandwidth just isn't there on the other side... depends on the arrangement they have for that particular IXP.
Highlighted
Proven Sharer

Re: Traffic issues at 66.109.7.162

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.