Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Verifying Dialup Pools? 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)"
This discussion has been archived. No new comments can be posted.

Verifying Dialup Pools?

Comments Filter:
  • 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.
    • by Anonymous Coward
      dumbass, the obvious solution is a nice reply to a simple question. politeness goes a long way.
    • 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?
  • 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

As of next Tuesday, C will be flushed in favor of COBOL. Please update your programs.