The slow death of an ISP?

0 comments

Posted on 1st August 2011 by admin in Fault Finding |Training

Being highly dependant on the fourth utility, the Internet, we have services from two different ISPs in our home office. One is slow but to date reliable. The second far faster for established connections but prone to issues. Our systems are patched into one of the two separate networks, but a policy based router may be added soon.

I’m also a photographer. Pushing large volumes of images up to my server for clients takes far less time with the second ISP, picked due to its much faster upload speeds.  I suspect they have a device buffering and shaping traffic as although speed test tools confirm the bandwidth is as advertised the 3-way TCP handshake and any DNS resolution takes far longer than on the slower ISP’s service. An ideal way to protect uplinks from those running bit-torrent services.

Now my reason for posting. The second ISP’s Hub has developed a fault. It can route traffic to the Internet just fine and do it’s own DNS resolution when running traceroute through it’s admin page, but not perform any DNS for clients. Despite countless reboots and a factory reset it wouldn’t change. Wireshark shows clients sending request packets and not getting a single reply.  It looks very much like the firmware problem that impacted many 2WIRE ASDL hubs in the past, and issue that also resulted in many calls to help desks and multiple replacements being shipped, also with the same broken firmware despite telling the help desk staff that shipping them was futile.

I’m reading in the technical press that my 2nd ISP is having clients leave them in large numbers.  From my recent experiences I think I know why and wonder how much longer they’ll survive.

To make matters worse the configuration setting on their hub to disable its local DHCP service was broken, so having another DHCP server override DNS details was impossible without putting a router between the LAN and hub. Thankfully keeping the Hub switched off for many hours somehow fixed DHCP.  DNS remains broken but as I’ve been able to regain control of leases I’ve got clients talking directly to the external DNS servers.

I see hardware, firmware and software issues all the time. It’s part of our modern life. It’s all designed by humans and we’re fallible. Where I have the necessary access and rights I’ll identify and if possible fix the issues, escalating to a product owner when needed, as in this case.

A support team failing their customers and ultimately their employer is another issue.

Any ISP wanting to retain customers should have an adequate 1st, 2nd and 3rd level support team. Teams that listen to what their customers say. I fully expect 1st to do the “Please power cycle the hub and reboot the computer” script following exercise. Anyone suitably experienced to work outside the script should be in 2nd or 3rd level support.

But when you get through to the supposed higher level support teams and tell them “I can traceroute from the client to the Internet fine but not do DNS resolution” only to get “Can you ping the default gateway?” you know something is wrong. Done Networking 101? When told that “nslookup run with server details changed from the hub address to a real DNS server works” only to have a response of “What happens if you enter a URL in a browser?” just enforces the point that the individual is in the wrong team or just not listening.

ISPs, these people are your front line. Many customers will talk to nobody else within your organisation, with maybe the exception of the billing team when they find they’ve been paying for a service they either don’t receive or don’t need. Do your best to have a properly trained workforce that listens to their customers, checks their understanding of the problem and escalates properly when needed. A continued bad impression will see your customers finding alternate suppliers.

37 views

No comments yet.

Leave a comment