[CLUE-Tech] DSL QoS monitoring.

[Dave Anselmi]

Brad wrote:

> Our diagnostic abilities are limited to a few critical
> facts-
> Does the user hit a DSL gateway on our facility?
> Does the user hit our RADIUS authentication server?
>
> In all of these cases, the answers to the above questions
> are both 'no'.  Qwest was simply not delivering the data to
> our facility.  The user will show the line being trained,
> but will not be able to authenticate or ping anything.
> Qwest will say it it our fault because the customer's line
> trains.  The process takes a minimum of three hours per
> subscriber to diagnose with qwest's help.
> Fortunately, Qwest only breaks about 2% of our customers.
> Still enough to file weekly PUC complaints though.

This is the sort of thing I was wondering about.  Unfortunately, I don't know much
about ATM networks.  I'd like to be able to get some info out of my DSL modem (which
seems to talk PPP over ATM, right?) to tell me whether my cells are getting to the
ISP or not.

I'd really like to be able to get my linux box to talk to Qwest's ATM switches - then
I could probably get some answers.  But maybe that requires hardware I don't have
(and maybe can't get) - would an internal DSL modem tell linux more than my external
can tell me?

Anyway, if I knew how to use the DSL modem to do some ATM diagnostics, then I could
decide whether to call Qwest or the ISP, and maybe Qwest would listen if I talked
ATM-tech to them (I can always dream, can't I?)

As it stands, all I can tell is whether I train to the CO, and whether I get a PPP
connection to the ISP.  I had assumed that no PPP meant a Qwest problem and PPP but
no Internet meant an ISP problem.  But I did see one where no PPP was the ISP's
equipment.

Thanks to all who responded, if I become an ATM engineer, I'll let you know.

Dave