Tuesday, 15 September 2009

The basics of broadband fault diagnosis

How fucking hard can it be?

There are two main types of fault on a broadband line. Probably as common as each other but very different solutions.

1. Copper...
The line itself can be an issue.. Sync low or wrong. Packet loss. Dropping. Etc. Even end user router screwing up.

2. Back-haul
BRAS wrong. PPP not working. Latency (cannot happen on line itself). Exchange wide loss or latency. etc.

It surely is a basic part of training for anyone on fault repair to work out which applies. One needs engineers to end user site or changing copper pairs or whatnot. One needs people on consoles checking configs, and people fixing fibres, and sorting bugs in the system.

They have no bloody clue - they will harp on about special engineers until they are blue in the face when the issue is blatantly not a sync/line issue.

Arrrrrrrrrrrg!

My latest comments on a fault:-

"We do not need an SFI as this is not a line sync issue - its an exchange/back-haul issue. Why even suggest an SFI. That shows a fundamental failure in you understanding. Please pass to someone who has a clue how thinhw work."

"Why would an appointment be needed - thing about it. If an SFI is not appropriate then why do we have to make an appointment. There is no line/sync issue. Its back-haul. Pass to someone with a brain please."

[sorry about typos]

3 comments:

  1. Sorry about typos? But without them it would fail the typocryptographic signature check!

    You forgot the very first step in troubleshooting...could you click on the Start Menu sir and tell me, what version of Windows does it say? OK, Windows XP, so what we're going to do is...

    ReplyDelete
  2. I had Sky first line support asking me to run 'netstat'.

    'How many entries are there listed?'
    '17'
    'Ah, well, your broadband is slow because so many programs are using your connection'
    'No, 16 are on the loopback interface and the other one is a connection to my printer. Anyway the router you supplied says current data transfer on the WAN is 20bytes/sec download and 6 upload. That is hardly going to fill a line synced at 4.3Mb/s is it?'
    'Erm, ok, I'll open a fault ticket. Someone should get back to you within 72 hours'

    Idiots

    ReplyDelete
  3. Well, our favourite telco used to routinely bounce faults to say that the user was "over using their link" and that is why they were losing sync.

    They totally failed to understand the difference between the ADSL sync and the packets going over it. The idea that cells run continuously on an ATM link and you can never send more or less cells did not get through to them. Neither did the idea that the protocol TCP will always "over use" the link is so far as sending until full and trying to send a bit more so dropping some packets.

    Took a long time to get them to stop using that excuse. I think we even have some automatic sarcasm in the system for that response still.

    ReplyDelete