Dear Patrice and All, First, sorry, i was not of help to you earlier. I hope this would not be late to help you. I've been working for an ISP and I had the exact same scenario as you do.
My work around may not be a good solution for you but i'd like to present it here in the purpose that it may give you some ideas to start with. My approach was to re-generate the config file mrtg.cfg every 5 minutes and schedule it to start just before the mrtg command in the crontab. Here are roughly what I did: 1. I set the virtual interface's description to corresponding username by passing the Cisco-Avpair value through RADIUS such as this: Cisco-Avpair := "lcp:interface-config=description [username]\r" 2. Then, I use snmpwalk to get the interface description of each virtual interface with appropriate OID such as this: snmpwalk -On -v 2c -c public router-name "1.3.6.1.4.1.9.2.2.1.1.28" It took me a while to search for the right OID to use: "1.3.6.1.4.1.9.2.2.1.1.28", which outputs exactly just the descriptions along with indexes of all the interfaces of the given router-name, something like this: .1.3.6.1.4.1.9.2.2.1.1.28.31 = STRING: "[username]" The last number in the line, in this case 31, is the interface index that we can use in the mrtg.cfg file. Please note also that, I use square brackets around username as i set it that way from Cisco-Avpair above. 3. After experimenting for while with the above 2 steps, I started to write a simple script named "mycfgmaker.sh" such as below: ############ #!/bin/bash # *** Usage: # mycfgmaker.sh community router-hostname/ip # Defining some variables COMMUNITY=$1 ROUTER=$2 OID="1.3.6.1.4.1.9.2.2.1.1.28" CFGFILE="/etc/mrtg/${ROUTER}-pppoe.cfg" # MRTG="/var/www/mrtg" MRTG="." WORKDIR="$MRTG/$ROUTER" # Printing the global options for MRTG cat << EOT1 > "$CFGFILE" EnableIPv6: no WorkDir: $WORKDIR YTics[_]: 8 Options[_]: growright,bits EOT1 # Check if the folder to store the graphs exists if [ ! -e "$WORKDIR" ]; then mkdir "$WORKDIR" elif [ ! -d "$WORKDIR" ]; then rm -rf "$WORKDIR" mkdir "$WORKDIR" fi # Walking through the SNMP OID (for interface description) of the router and printing to the config file for i in `snmpwalk -On -v 2c -c $COMMUNITY $ROUTER $OID | egrep 'STRING:.*\[.+\].*' | sed -e 's/^.*\.\([[:digit:]]\+\) = STRING:.*\[\(.\+\)\].*/\1:\2/g'`; do IFINDEX=`echo $i | cut -d: -f1` PPPUSER=`echo $i | cut -d: -f2` cat << EOT2 >> "$CFGFILE" Target[${2}_${PPPUSER}]: ${IFINDEX}:$commun...@$router:::::2 SetEnv[${2}_${PPPUSER}]: MRTG_INT_IP="" MRTG_INT_DESCR="$PPPUSER" MaxBytes[${2}_${PPPUSER}]: 250000 Title[${2}_${PPPUSER}]: Traffic Analysis for $PPPUSER -- $ROUTER PageTop[${2}_${PPPUSER}]: <h1>Traffic Analysis for $PPPUSER -- $ROUTER</h1> <div id="sysdetails"> <table> <tr> <td>System:</td> <td>$ROUTER in </td> </tr> <tr> <td>Maintainer:</td> <td></td> </tr> <tr> <td>Description:</td> <td>$PPPUSER </td> </tr> <tr> <td>ifType:</td> <td>ppp (23)</td> </tr> <tr> <td>ifName:</td> <td>PPP-$PPPUSER</td> </tr> <tr> <td>Max Speed:</td> <td>10000</td> </tr> </table> </div> EOT2 done # Running MRTG till there are no more errors let "RUNCOUNT=0" while true; do env LANG=C /usr/bin/mrtg "$CFGFILE" --lock-file /var/lock/mrtg/${ROUTER}-pppoe_l --confcache-file /var/lib/mrtg/{$ROUTER}-pppoe.ok > /dev/null 2>&1 let "RUNCOUNT += 1" if let "$? == 0 || RUNCOUNT == 3" ; then break; fi done ############ My actual script has extra lines to customize to my ISP's requirements here. Hope that helps. And ip hope for more comments also to my approach to make it a more suitable solution to everyone. Ragards, Khem On 02/08/2010 11:17 PM, Patrice Blot - FCNET wrote: > Hi steve and Jan, > > You both are right. > My comments below. > > >> What I thought was the issue (correct me if Im wrong) was that Patrice >> is trying to create a MRTG graph per user, although which interface >> corresponds to the user will change and can only be identified via the >> ifAlias. Since MRTG does not allow identification of interfaces via >> ifAlias, this cannot be done. >> > Right. this is what I want to do. > For example for my own ADSL connection my radius reply to my cisco : > cisco-avpair =="lcp:interface-config=descr blot" > > And snmpwalk gives for my Iface : > IF-MIB::ifIndex.92 = INTEGER: 92 > IF-MIB::ifDescr.92 = STRING: Virtual-Access87 > IF-MIB::ifType.92 = INTEGER: ppp(23) > IF-MIB::ifMtu.92 = INTEGER: 1464 > IF-MIB::ifSpeed.92 = Gauge32: 608000 > IF-MIB::ifPhysAddress.92 = STRING: > IF-MIB::ifAdminStatus.92 = INTEGER: up(1) > IF-MIB::ifOperStatus.92 = INTEGER: up(1) > IF-MIB::ifLastChange.92 = Timeticks: (69431785) 8 days, 0:51:57.85 > IF-MIB::ifInOctets.92 = Counter32: 364474592 > IF-MIB::ifOutOctets.92 = Counter32: 1798235934 > [...] > IF-MIB::ifName.92 = STRING: Vi87 > IF-MIB::ifAlias.92 = STRING: blot > > This is what is great ->>>>>>^^^^ > > >> >>> Besides I can't see how mrtg should be able to obtain ifnumber based >>> >> on >> >>> ifDescr or ifAlias other than listing the interfaces. And you don't >>> >> need >> >>> to list (snmpwalk) more than the right table. >>> >> This is actually how MRTG does it for all other ways of identifying the >> interface, and caches information in the .ok file (sometimes). >> > You're right. There is an mrt.ok file by me which contains these information. > I never pay attention to it. > > >> >> You shouldn't rewrite mrtg.cfg as this would be needlessly complex. A >> far better solution would be to write a data collection plugin that >> identifies the correct interface from a passed username parameter, and >> retrieves the appropriate counters. You should probably make this >> plugin cache the snmpwalk output for a certain period (at least 5min) >> in order to have efficiency - just as MRTG does with its other checks. >> >> >>>> So to my mind it should be a very small development to make MRTG >>>> >> uses >> >>>> "IF-MIB::ifAlias" to reference a target like "IF-MIB::ifDescr" is >>>> already used. >>>> >> I generally agree, although I think it would be slightly more complex >> to use the vendor-MIBs to identify interfaces. You'd also need to add >> a new identifier syntax to the Target definition and extend the caching >> of data (eg: Target[]: ~alias:commun...@host ). If you do this, >> please modify the latest MRTG, and pass the patch back to Tobi for >> inclusion into the official code. >> >> Steve >> > According to your advices I think I will keep working in 2 directions : > - writing plugin > - hacking mrtg code. Really more complex. Need to grab new OID,add new syntax > to mrtg.cfg, new cache to mrtg.ok. Will see ! > > More news in a few weeks or months due to the small priority affected to this > project :( > > Thanks for you precious advices, > > Patrice > > > _______________________________________________ > mrtg mailing list > mrtg@lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg > > _______________________________________________ mrtg mailing list mrtg@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/mrtg