Skip navigation

Tag Archives: Cisco Catalyst

Ok, so here’s the deal: you want to monitor all your network infrastructure with Nagios (or something else, but these instructions are geared towards Nagios specifically), but you’re new to the program and so you’re starting with the little things first, like collecting system up-time on your switches.  The problem is that you’re just seeing service timeouts where you would like to see that up-time.  Fear not!  I have done the leg-work (or click-work) and present you with the answer to your problem in two parts.

The Switch

The first part is to get your switch set up to use SNMP version 3 (much more secure than 1 or 2c).  Log in to your switch and run the following

conf t
snmpv3 enable

At this point, you’ll have to set up an initial user. Don’t sweat it–you’ll be deleting this user in a minute, so you can just enter junk information here.

snmpv3 only
snmpv3 user "username" auth sha "password" priv des "password"
snmpv3 group operatorauth user "username" sec-model ver3
no snmpv3 user initial
wr mem

Now SNMP is enabled on your switch, you can move over to the Nagios end of things.

Nagios

Note: I’m using NConf to configure Nagios, and these instructions assume that you’re doing the same.  Wherever your snmp_check command is configured, set it up to execute with the following parameters:

snmp_check!-P 3 -a sha -U [username as set above] -A [password as set above] -L authNoPriv -o 1.3.6.1.2.1.1.3.0

Now just reload the Nagios service, and the next time a service check is run for up-time, you should get a nice number telling you how many days the switch in question has been up.

Giving credit where it’s due, the SNMP configuration information came from here (where you can also find information on how to configure Cisco switches).

Advertisements

When I took on the role of Systems and Network Administrator at my work, we had been using a Linux-based software firewall as the backbone of our network.  In fact, up until about seven weeks ago, we’d been running the same hardware box for around seven years.

Then it crashed.

Luckily, the crash was caused by a problem with the motherboard, and we had a recently-decomissioned server running on the same hardware that we could just swap in without too many problems (though I did spend most of a weekend at work getting everything back up and running).  After we got the firewall back up and running, though, more and more problems started coming out of the woodwork.  Our RADIUS-based MAC authentication was spotty sometimes, and whole classes were unable to access the network.  It was clear that something had to change, but until we could isolate the problems, we couldn’t even start.

Consultants were consulted, outside eyes looked over our infrastructure, and there was an “aha!” moment.  The Linux firewall, the heart of everything, had become insufficient.  Every year, we’ve added more devices, and with the pilot of a one-to-one iPad program in our middle school, we had hit the breaking point.  If our firewall had only been doing firewalling and routing functions, we might have been able to go on for another year, but with iptables, RADIUS, squid caching, routing, and DHCP all running on the same box, with pretty much all of our traffic making several trips through the one internal interface, the system bus, and asking for CPU clock cycles on our firewall, there was no way that we could sustain the model indefinitely.

So what did we do?  We made a major overhaul of our core infrastructure, moving different services to different hardware.  You can (for a pretty penny) get switches that do both layer-2 switching and layer-3 routing at line speed.  We had a firewall appliance that had never been fully deployed before precisely because it takes a lot of work to break out all the services we had running on our firewall and keep everything running smoothly without the end-user noticing a change.  Of course, with such a big change on an inherited network, there are things that didn’t get caught right away, but that always happens.  After some late nights, our network has smoothed out to the point that I’m not just putting out fires constantly.

But where does this leave the Linux firewall?  While I have a working, if somewhat limited knowledge of Cisco switching, wireless, and internet-telephony solutions, their security appliances and layer-3 switches are mostly foreign to me.  I won’t claim that I’m an expert with iptables, but I knew my way around the command well enough to maintain things.  But the question is larger than this one case.

For small and even medium businesses, a Linux firewall is probably still the best, most economical choice if you have a serious network, as long as you have or are willing to gain the appropriate Linux wizardry, with the caveat that that box should only be doing firewalling and routing.  If you have other services that you need to run on your network, put them somewhere else, especially if you’re running something like RADIUS, where timely response packets are required for authentication.  However, if you’re supporting many hundreds of devices across multiple VLANs and expect to expand even further, a hardware-based solution will be a better investment in the long run, even if it’s a greater initial expense.