Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Verifying Dialup Pools?

Cliff posted about 13 years ago | from the automating-tedious-jobs dept.

Hardware 10

freebase asks: "I've been asked to come up with a way to verify SLA's relating to our inbound corporate dial-up. Before I push down the path of writing a series of shell scripts and a reverse-telnet serial driver to use an AS5200 to gather data necessary for our monthly reports, I thought I'd ask and see if anyone knows of any products/projects which can do this off the shelf. If I can find the right product, I have the money to purchase, especially if it will save me from having to completely re-invent the wheel."

"At least monthly, I will need to produce a report that details at a minimum:

  1. Connection Throughput (IP based connectivity)
  2. Authentication Success (PPP PAP/CHAP)
  3. Compression Stats (Protocol, etc)
  4. Error Correction Stats (Protocol, Bad EC frames, etc)
  5. Physical Stats (line busy, quality, retrains, sign-noise ratio, etc)"

Sorry! There are no comments related to the filter you selected.

Dial this: (-1)

Dead Fart Warrior (525970) | about 13 years ago | (#2467817)


And tell me what it sounds like.

Re:Dial this: (0)

Anonymous Coward | more than 12 years ago | (#2487845)

damn... you know it's bad when you can look at that and think "Mary Had a Little Lamb".

this is a very early post (-1, Offtopic)

Anomymous Coward (303315) | about 13 years ago | (#2467820)

this is a very very early post ....


dumbass. obvious solution is mrtg. (1)

Zurk (37028) | about 13 years ago | (#2467991)

just use MRTG. thats what its there for. youre not a sysadmin if you havent heard of it. go learn - - good page for cisco as52xx and 53xx monitoring with mrtg.

Re:dumbass. obvious solution is mrtg. (1)

Anonymous Coward | about 13 years ago | (#2470863)

dumbass, the obvious solution is a nice reply to a simple question. politeness goes a long way.

Dumbass. obvious solution is Ask Slashdot (-1, Troll)

Anonymous Coward | about 13 years ago | (#2471117)

No the obvious solution is to ask slashdot, instead of spending 0.1 minutes with Google [] .

Re:dumbass. obvious solution is mrtg. (1)

freebase (83667) | about 13 years ago | (#2471654)

Actually, you sound like someone that's never had to worry about anything below layer 4...

MRTG is fine for pulling stats from one end of the connection, and then only for which Cisco has thought to put counter OID's into their mibs. I've got two mrtg servers polling my 400+ routers and switches now for stats like utilization, errors, etc.

However, what I'm looking for is something that lets me quantify the connection from the END USER'S point of view. I already log CDR's to a syslog server. Coupled with these Call Detail Records, and certain debugs, I can analyze my side of the connection fine, even though I have to puruse form than 9000 lines of logfile info daily to do it.

SO next time, listen to your mother, and if you don't have something constructive to say, SHUT THE HELL UP, ok?

This isn't too difficult to do by yourself... (0)

Anonymous Coward | about 13 years ago | (#2472467)

I had to do much the same thing in a previous job with around 40 USR TC racks. I had to attack the problem from two directions; first, do snmp probes which were logged to mysql for call counts, call failures, connection types (V.34, V.90, etc) and then generate a nightly report which dumped all that info into an html page and a CDF file (for the excel spreadsheet spods). Second, I had a machine with two couriers that did nothing but dial out to the racks 24/7/365 and analyse the results.

After this was up and running, call failures went from around 40% (yes, forty) down to around 2%; turned out that some of the modems in the TC would hang in a fashion that they'd accept calls but fail to negotiate. Power cycle would fix it. Procedure was if a modem & NMC were flashed up to the latest code and a modem had more than I think 5 failures, it went back to USR/3Com for replacement.

The whole thing took me about a month to write and get running (in between doing my other admin duties), then a couple of hours' maintenance every week. There was nothing commercially available then that would do this, and I doubt whether there is now. There's plenty of freeware tools out there for the snmp side of things, though (at least for USR); I took a few of the available ones, ripped out the useful bits and created the scripts.

Hardware required was:
* 1 PC with 2 USR Couriers for dialout
* 1 PC running MySQL for DB
* 1 PC running SNMP probes
* 1 PC running Apache doing interactive reports on material from the MySQL server

I am the lamest asshole ever. (-1, Flamebait)

Anonymous Coward | about 13 years ago | (#2474972)

Dear Slashdot: Please do my job for me. I am totally lame.

There are some client-side tools (2)

anticypher (48312) | about 13 years ago | (#2475174)

I can't remember their names, however.

I've seen two large dial-in companies distribute a small program for windoze dialups that keeps a small log of connect attempts. After a successful dialup establishes a proper PPP connection, the software sends the info to a logging server, so that missed attempts are also logged. The clients also keep track of DCE speed, PPP negotiation attempts, retrains, reason for disconnect, etc. Both of them cause all kinds of problems for network managers, since they fuck around with the windoze IP/dialup networking stack, and break things in mysterious ways.

I saw both companies at CeBIT this year (which doesn't do you any good since there are thousands of companies). I'm pretty sure there were others.

One allows their client software to be distibuted freely, and then the customer who wants reports pays by the number/report/detail etc., but requires that all the dialins establish a fully routable IP connection to the internet. The info is slightly encrypted, and may possibly contain sensitive info like login/password and windoze info. The company wouldn't admit it, but that was the only way for them to distinguish which client belongs to which company. Nasty shit for security people. I've heard many reports of targeted spam hitting every person in the company soon after installing the widget.

The other was a full client/server setup, where the server could be installed on the company network, and not require internet access. Cost was based on number of clients/laptops/server size. But it allowed all sensitive info to stay within an organisation. Less nasty shit for paranoid security people. They promised a newer version could also do correlation reports with logging info from radius, and then tried to recruit me to write it :-)

Do some web searches, maybe poke around in comp.dcom groups on google. These tools exist, you just have to be ready to pay for them. And we on slashdot are too lazy to do your job for you (but are available for a hefty consluting fee :-)

the AC
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?