PPP / PPPoE User Traffic Graphs

[airwalk]

for the number of active dialup users on cisco router you can use the following OID:

.1.3.6.1.4.1.9.9.47.1.1.6.0

This is defined in CISCO-MODEM-MGMT-MIB:

cmSystemModemsInUse OBJECT-TYPE
SYNTAX Gauge32
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of modems in the system that are in the
following states: connected, offHook, loopback,
or downloadFirmware."
::= { cmSystemInfo 6 }

[jpingle]

for the number of active dialup users on cisco router you can use the following OID:

And that does work on my modem-based access servers, as it has for years. However, in this case we're talking about PPPoE sessions that are not actually using modems, but coming across a network link. Moreso, we're also trying to get per-user graphs by username, which is harder still...

Even when I find a way that works, it doesn't work for every username consistently. It may not be possible without writing a much more complex program that I intended.

[cajunrick]

I'm still testing what I've got so far, but it ended up being a script and a whole set of templates and such.

Have you ever made any more progress on this issue? It's been more than a year since this message was posted, and it will solve a major problem for us if we can get it to work. Thanks in advance for any assistance.

[jpingle]

Have you ever made any more progress on this issue? It's been more than a year since this message was posted, and it will solve a major problem for us if we can get it to work. Thanks in advance for any assistance.

No, I was not able to make any more progress. I have not had time to work on it and we did not need more than a few graphs. The script I wrote does not scale well at all.

I may revisit the problem in the future, but unfortunately it won't be any time soon.

[jpingle]

We updated to a new router and network link to carry our PPPoE users and so I decided to revisit this topic a little.

I'm working on a variation of my previous script that might scale better, but it's still pretty slow (Takes about 15 seconds to gather data for 130 users.)

Here is what I am doing now in a cron job run every 5 minutes that executes a python script (The "new" method):

Code: Select all

1. Gather a list of online users from the router via SNMP
2. Get a list of active interfaces from the router via SNMP
3. Get inOctets for all active interfaces from the router via SNMP
4. Get outOctets for all active interfaces from the router via SNMP
5. Correlate the interfaces to users using the VPDN identifier passed back with the username in step 1. 
6. Correlate the in/outOctets with all users based on the interface found in step 5.
7. Dump this data out to a file.

Then I have a second simple shell script run from cacti that performs a grep of this file and prints the in/outOctets for the username (or NaN if not found)

The old method performed one large snmpwalk and three snmpgets for each user, this method uses four large snmpwalk-style requests to get the data for all users at once.

There is still no easy way to create graphs automatically that I can find, so I have to manually create a graph for each user. I guess this could be scripted somehow if I knew more about cacti's internals.

I wrote the data gathering script in Python using PySNMP, but at the moment is is still very crude and not ready to be published anywhere. There's no particular reason I chose Python, just that I have been using it a lot lately and the SNMP library was fairly easy to work with.

If there is still some interest in this topic, I can try to find time to clean up the code, repackage the templates and such, and post an updated version.

Here are some pros/cons of the new script:

• Pro: Four large requests gather data for all users at once. For example, with 100 users, old method would have made 100 SNMPwalks and 300 SNMPgets, new way does 4 SNMPwalk-style requests regardless of the number of users.
  Pro: Should be much faster, especially for large numbers of users
  Con: Needs a cron job
  Con: Needs to write a file to the cacti server
  Con: Requires Python and PySNMP
  Con: Requires hardcoding the server IP and community string in the script instead of being passed this information from cacti.
  Con: Requires hardcoding paths to some utilities such as grep
  Con: Harder to support

There are probably more on both sides, but for me, the pros far outweigh the cons and it seems to be working for me at the moment.

[cajunrick]

If there is still some interest in this topic, I can try to find time to clean up the code, repackage the templates and such, and post an updated version.

I am certainly still interested, and would appreciate any assistance you could give us. I'd be happy to work with you in testing/troubleshooting anything you come up with.

[cajunrick]

Still interested...

[dexter001]

well .. I did stuff a lil bit different so far .. I got a script that when launched like this
./scriptname user
returns the bw (up/down/total) used in that second .. this way .. I don't care about it being a dynamic ip or something .. now all I'd need is a way to implement this in cacti :| .. I never did a template .. and don't know how ..

I'm using freeradius (sqlippool) .. and rp-pppoe server ..