Using MRTG on VPDN user session OIDs for a Cisco 7200 router

If you handle a Cisco network (or have a decent number of VPDN users connecting to your network regularly), having MRTG on VPDN user sessions as a traffic graph is very helpful in improving your understanding of the daily network load. Especially so, if you compare the number of users to the bandwidth used.

Tip: SNMP polling is a very handy tool for us network blokes.

If you’re new to MRTG, have a look at my previous setup guide.
Looking to plot the router’s temperature? Here you go.

Look below for my preferred template for plotting VPDN sessions on a Cisco 7200.

Sample configuration for VPDN session count graph



#---------------------------------------------------
#This is the configuration to get VPDN session count
#---------------------------------------------------

Target[vpdn]:.1.3.6.1.4.1.9.10.24.1.1.4.1.3.2&.1.3.6.1.4.1.9.10.24.1.1.4.1.3.2:readstring@router
SetEnv[vpdn]: MRTG_INT_IP=”192.168.1.1″ MRTG_INT_Descr=””
Ylegend[vpdn]: # of connections
LegendI[vpdn]: VPDN sessions
LegendO[vpdn]: VPDN sessions
ShortLegend[vpdn]: sessions
MaxBytes[vpdn]: 1000
Options[sess]: nopercent, integer, gauge
Title[sess]: Traffic Analysis for VPDN (L2TP) connected users
PageTop[sess]: <H1>Traffic Analysis for VPDN (L2TP) connected users</H1>
<TABLE>
<TR><TD>System:</TD> <TD>router.mynetwork</TD></TR>
<TR><TD>Maintainer:</TD> <TD></TD></TR>
<TR><TD>ifName:</TD> <TD></TD></TR>
</TABLE>


Explanation on sample configuration

OID used in target: 1.3.6.1.4.1.9.10.24.1.1.4.1.3.2 is also known as cvpdnSystemSessionTotal (from CISCO-VPDN-MGMT-MIB.my).
You might note that there is an extra .2 at the end of this OID, which denotes L2TP sessions only.
Mailing lists read indicate that loading the MIB onto MRTG and polling cvpdnSystemSessionTotal could work, but I got a bloody error from Perl on that, so I gave up and polled the OID directly instead.

One great help in discovering the OID, was through the use of OidView. Brilliant stuff, pity it’s only available for 7-day eval.

Options used:

  • nopercent: do not display current value with a utilisation percentage.
  • integer: display as an integer instead of float (i.e. with decimal points)
  • gauge: poll the variable as a current value without calculation to previously polled values.

(If you’re interested in a better explanation, look at the MRTG configuration reference guide.)

Advertisements

Cisco MRTG temperature graphing with the 7200 router

In a way, this post is a sequel to the previous MRTG tutorial I wrote. Then again, it’s slightly more specific towards the Cisco 7200 series router, so it wouldn’t be as applicable to everyone. If you are interested in graphing Cisco MRTG temperature though, read on.

Once again the disclaimer follows – I’m using Debian distribution 2.4.18-bf2.4.


#1 Knowing what’s good and what’s not

It’s not very useful to know the temperature if you don’t know what you’re looking out for.

Ambient operating temperature: Cisco advises a minimum of 32°F (0°C) and maximum of 104°F (40°C). 40 degrees Celsius doesn’t sound like it’s enough to cook the router though.

If we check the table displayed in our router’s CLI by going into exec mode:

Router#show environment table

We get:

Sample Point LowCritical LowWarning HighWarning HighCritical
I/O Cont Inlet 40C/104F 50C/122F
I/O Cont Outlet 43C/109F 53C/127F
NPE Inlet 75C/167F 75C/167F
NPE Outlet 50C/122F 60C/140F

Seems to be a wee bit higher than what the website said? Oh well, I guess it’s a good thing.


#2 Checking your router’s temperature the quick and easy way

Login to your router (telnet, console whatever) and go into exec mode.

Router#show environment all

I believe the display differs according to the NPE (Network Processing Engine) you’ve got, but this is what mine says.

Power Supplies:

Power Supply 1 is Zytek AC Power Supply. Unit is on.
Power Supply 2 is Zytek AC Power Supply. Unit is on.

Temperature readings:

I/O Cont Inlet measured at 25C/77F
I/O Cont Outlet measured at 27C/80F
NPE Inlet measured at 28C/82F
NPE Outlet measured at 29C/84F

Voltage readings:

+3.45 V measured at +3.50 V
+5.15 V measured at +5.25 V
+12.15 V measured at +12.39 V
-11.95 V measured at -11.85 V

Envm stats saved 94 time(s) since reload

The bolded section’s what we want, period.


#3 Using MRTG to plot your router’s temperature

Takes a bit more effort, but at least you’ve got some historical data to rely on for comparison. Plus, you don’t have to keep logging into your router to check!

We can’t use cfgmaker this time round as it takes a bit of typing to get things done.
Here’s a sample .cfg template of what I used:

Target[router.temp]:1.3.6.1.4.1.9.9.13.1.3.1.3.1&1.3.6.1.4.1.9.9.13.1.3.1.3.2:CommunityName@RouterIP
Directory[router.temp]: temperature
WithPeak[router.temp]: wmy
YLegend[router.temp]: Degrees C
ShortLegend[router.temp]: °C
MaxBytes[router.temp]: 50
Options[router.temp]: nopercent, growright, gauge
Unscaled[router.temp]: dwmy
AbsMax[router.temp]: 50
Title[router.temp]: Router
Colours[router.temp]: GREEN#00eb0c,BLUE#1000ff,BLUE#1000ff,VIOLET#ff00ff
Legend1[router.temp]: Average 1 minute Inlet Temperature
Legend2[router.temp]: Average 1 minute Outlet Temperature
Legend3[router.temp]: Average 5 minute Inlet Temperature
Legend4[router.temp]: Average 5 minute Outlet Temperature
LegendI[router.temp]:  Inlet:
LegendO[router.temp]:  Outlet:
PageTop[router.temp]: <H1> Router temperature - Degrees C<BR></H1>
<TABLE>
<TR><TD>System:</TD><TD>Router</TD></TR>
<TR><TD>Maintainer:</TD><TD>Admin</TD></TR>
</TABLE>

There’s actually four points of temperature measurement for the 7200, but since we only need two for the MRTG, I used the inlet temperature and one of the outlets, which makes more sense than checking the temperature of two outlets.

OIDs for the four points are as follow:


Inlet .1.3.6.1.4.1.9.9.13.1.3.1.3.1
Outlet 1 .1.3.6.1.4.1.9.9.13.1.3.1.3.2
Outlet 2 .1.3.6.1.4.1.9.9.13.1.3.1.3.3
Outlet 3 .1.3.6.1.4.1.9.9.13.1.3.1.3.4

Follow up with the usual steps to creating the index and populating the cron job (refer to my previous MRTG article), and we should be done.


Credits for the solution goes to a whole ton of Googled results, and I sort of lost track along the way after reading numerous websites. One of the major help sites is the MRTG mailing list, and the people there are seriously good.

I hope this post helps some other poor soul out there who’s trying to do the same thing, and here’s to you saving two hours of research on doing up a Cisco MRTG temperature graph for your router.

Tech: 10 tips for FreeRADIUS server configuration

I had the pleasure (read: gruelling chore) of setting a RADIUS server up from scratch a few weeks ago. All in all it was an educational experience, to say the least. To anyone else who’s interested, here’s a rough troubleshooting guide incase you get screwed and start screaming “WTF WHY IS IT NOT WORKING!!!”

Scope of installation: to setup an authentication server in a LAN environment NAT-ed to a public internet address, that authenticates against user info in database and logs session data to database as well.

*I am assuming a basic knowledge of bash, and that you know how to edit files with vi or any other editor in the command line interface.

Packages used:

  • FreeRADIUS 1.1.3
  • MySQL 5.0.32-Debian_7etch8-log
  • Linux version 2.6.18-6-686 (Debian 2.6.18.dfsg.1-23)

Optional packages if you want to install dialupadmin:

  • Apache
  • PHP

Important note above everything else: read FreeRADIUS Wiki on SQL integration. Twice. Even thrice!

1. Network: make sure NAT is done if the server is using a private IP address (read: RFC 1918)

Default ports to be NAT-ed:

  • TCP 1812 and 1813
  • UDP 1812 and 1813
  • 1812 is for authentication, and 1813 for accounting. That’s if you did not customise the ports in the default config.

If you don’t know how NAT should be done, Google is your best friend.

2. Restart it: service should be restarted whenever you make changes!

To stop:
/etc/init.d/freeradius stop

To start:
/etc/init.d/freeradius start

RHEL (and similar distros) should use this to restart the service (via FreeRADIUS wiki):
service radiusd stop
service radiusd start

3. Protocols needed: configure /etc/freeradius/radiusd.conf as needed for types of authentication protocol e.g. CHAP, PAP, MS-CHAP.

4. Logging: check for error messages under /var/log/freeradius/radius.log

5. Debugging: debug mode is very useful:

To turn it on:
freeradius -X

*note: you have to kill to end the process, there is no stop command.

6. Dictionary check: add the relevant dictionary for your desired NAS in /usr/share/freeradius/

7. Dictionary include: include the file dictionary inside /etc/freeradius/dictionary

This is a sample entry for dictionary abc:

$INCLUDE /usr/share/freeradius/dictionary.abc

8. Client check: ensure your NAS clients are listed inside /etc/freeradius/clients.conf with a valid IP address and shared secret. NAS = Network Access Server, which is the client that’s handling the authentication. So yes, your NAS must be similarly configured.

9. Process check: Check that FreeRADIUS is running correctly.

List of processes check for freeradius:
ps -ef

If it’s not running, you’d better find out why.

Check listening ports make sure the required UDP and TCP ports are active:
netstat -tunelp

Make sure it’s listening on the right interface(s)!

10. Database check: Check that the username and and password (and related usergroup) have been inserted into the usergroup and radcheck tables.


That’s all there is to it, I wasn’t really in the mood for writing an epic saga of my woes encountered alongside the entire process. Hopefully this has been of help to you guys, so if you liked my article, please share it! Thanks as always.

Linux – Debian: One way to reset the root password

So you have either fcuked things up and forgotten what that bloody complex root password (complete with symbols, numbers, uppercase and lowercase letters!) was like. Or perhaps you decided it was high time you cracked your roommate’s Linux box because he pissed you off the other night.

This is pretty straightforward actually, once you get the hang of things.

#1 Reboot the box
Unbelieveable as it sounds, you cannot change anything until you reboot the damn thing.

#2 Edit the startup configuration when you get to the GRUB loader
Select your desired operating system to load, and press e to edit the boot configuration.

Append this to the end of the statement:

init=/bin/bash

This makes the box boot into single-user mode, which conveniently gives you root access.

Press b to continue booting, and you should arrive in bash as root.

#3 Make your filesystem writable
Use this to do so:

mount / -o remount, rw

Skipping out on this will give you problems when attempting to change the password in the next step.

#4 Change the root password
Use this command to change the root password:

passwd

(That was easy!)

Enter your desired password after that. Twice.

#5 Reboot the box (again)
We’re rebooting now just to make sure our new password works.

And we’re all done; that was quick wasn’t it?

A detailed guide for other Linux distributions and bootloaders can be found at CLUG Wiki.

MRTG graph generation for the network newbie in 8 easy steps

This post is for people like me who have had limited experience with creating an MRTG graph (aka Multi Router Traffic Grapher), and were struggling to configure it for traffic analysis. It’s also for myself, if I ever forget how to do it.

English: The graph drawn by MRTG. 日本語: MRTGが生成...

Note: configure, not setup from scratch. Setup instructions for MRTG can be found here on a guide written by sylvain.maurin@isc.cnrs.fr, or at the MRTG Implementation Manual by Florin Prunoiu.

(I’m using Debian distribution 2.4.18-bf2.4 FYI.)


#1 Use cfgmaker to create a .cfg file for your network device

You should have your device’s IP address (123.123.123.123) and the SNMP community name (SNMPnewdevice) at this point. Mine outputs to a file called newdevice.cfg.

cfgmaker SNMPnewdevice@123.123.123.123 --global "WorkDir: /var/www/mrtg/newdevice" --output /etc/mrtg/newdevice.cfg

*The above command is one single line.

**/var/www/mrtg is where my MRTG page is, you should edit it accordingly.

***/etc/mrtg is where my MRTG .cfg files are.


#2 Tidy up the .cfg file

Edit your .cfg file and remove any interfaces you might not want to monitor; use # to comment them out.

vi /etc/mrtg/newdevice.cfg

Checkout the wiki on vi if you’re new to it.


#3 Be organised: created the new work directory

You can see that we specified a WorkDir in step #1, and now we need to create it. This will hold all the graphs for the new device.

mkdir /var/www/mrtg/


#4 Use indexmaker to create the index page for your MRTG graph (or graphs)

/usr/bin/indexmaker --output /var/www/mrtg/newdevice/index.html /etc/mrtg/newdevice.cfg

*The above command is one single line.

This generates the page index.html.


#5 Populate the MRTG graph (or graphs) for the first time

cd /var/www/mrtg/newdevice

mrtg /etc/mrtg/newdevice.cfg

This generates the graphs and the nice little MRTG banner at the bottom.


#6 Tidy up your index page

Add needed information e.g. the name/IP of the interface, where it’s pointing to.

vi /var/www/mrtg/newdevice/index.html


#7 Add a job to your crontab to regenerate the MRTG graph every 5 minutes

vi /etc/cron.d/mrtg

0-55/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/newdevice.cfg ]; then env LANG=C /usr/bin/mrtg /etc/mrtg/newdevice.cfg >> /var/log/mrtg/mrtg.log 2>&1; fi

*My MRTG cron is in /etc/cron.d, so edit yours accordingly.

**This is very important: MAKE SURE the second command remains as one single line when you enter it; copy-paste sometimes breaks the line into two, and this effectively renders the cron from working. And worst, it’s the next thing to being invisible. It took me a good half hour to find the error (Thanks to ShaolinTiger’s post on WindowSecurity.com).


#8 Restart your cron

/etc/init.d/cron restart

And that’s all, we’re done! Feel free to leave any comments or suggestions that you might have on improving this article for MRTG graph generation.

-~-

Additional tip:
If you want to make your MRTG graph’s timeline go from right to left, do this:

vi /etc/mrg/newdevice.cfg

Add this section of code at the top, below ### Global Defaults

Options[_]: growright

Optional: Add this to allow the values to be converted into megabits automatically:

Options[_]: bits

To make it go from left to right, add this instead:

Options[_]: growright, bits

Remember to use # to comment out the other options!

Enhanced by Zemanta