It looks like Cisco is trying to crack down on illegal distribution of their software.  I can’t really blame them since it’s their property.

For those that don’t know, when I say “stack”, I mean a group of 3750s connected together using the StackWise technology.  When you use a very expensive and very proprietary cable, your individual switches are combined into a single logical device.  This means you configure one device to control potentially many switches.

To the point.  I’ve spent the last few weeks replacing a mess of 3750s in stacks.  These guys are very easy to replace, but the big problem I find is getting the IOS version in sync.  When the RMA comes, it’s inevitably got a different version on it, and you’ll see something like this.

I apologize to my adoring fans (both of you) for the lack of posting.  I’m in the middle of moving, buying a new house, selling my current house, getting a mortgage, etc.  I’ve up until 11:30 nearly every night filling out forms and going through red tape.  Don’t get me started on getting money from a 401k!  Anyway…

I got in this morning, and a coworker was telling me that the data center’s HVAC was crippled due to an oil leak, and it was 90F in there.  D’oh!  It wasn’t quite that high, but it was warm.  Luckily, all of our network gear is on the end of the rows with AC, so we’re safe, but it got me thinking about monitoring temperature of our 6500s via SNMP.  I’ve done it via Cacti, but I never really looked how to do it manually.

There’s a lot of noise on the Internet.  I’m not talking about certain news sites, either; I’m talking about stuff like port scans or attempts on weak services from all sorts of bad people on the Internet.  A large chunk of that noise can be filtered by the edge routers, taking some of the load off of the network and firewalls.

Here are a few things that we filter inbound on our Internet links.  Your mileage will vary.

Did you catch the article on setting up fault tolerance on the CSM?  In that article, I mentioned that Cisco recommends a dedicated trunk for the FT VLAN if you have two HA CSMs in two chassis.  Discuss amongst yourselves while I drone on.

Why should you set up a dedicated trunk for this stuff?  The most obvious reason is to be sure that normal traffic doesn’t step on the syncing traffic.  Since we’re syncing state information as well as configuration, the frames need to arrive in a timely manner.  Any errors could potentially disrupt the FT process, which is bad.  You surely don’t want the primary to fail only to find out that the standby doesn’t have the complete or current config.

There are three different ways that a CSM checks for the health of the servers – active probes, inband health checking, and inband HTTP monitoring.  Let’s talk about active probes.

Active probes (or just probes) typically send traffic to one of the RIPs of a serverfarm, do some stuff, and give a pass or fail grade.  If the probe fails a certain number of times in a row, that server is considered sick and taken out of the pool for use.  The CSM keeps checking the unhealthy until it passes a number of times in a row, at which point it is placed back in the pool for use.  Almost everything is configurable, of course, so let’s look at some of those settings.

Like (nearly) everything in the Cisco world, you can set up your CSM to fail over to another module when the primary dies a horrible death.  You can have two in the same chassis or even have them in separate chassis – the process is the same no matter how you have it set up.  Either way, you have a primary and a secondary module in fault tolerance (FT) mode.

I like logging on an IOS device.  I like to look at the buffer and tell you that your interface went down 30 seconds ago.  I like to look on the box and see that BGP with my Internet provider has been flapping since 02:13ET.  I like to look and see that one of the other guys has been making changes to the gear all morning.  I could go on and on.

A lot of IOS commands give you a lot of information. Most of the time, though, it’s way too much information, and it sure would be nice to do some grep-like stuff on the output, right? Well, just like on Linux, you can use the pipe (|) to do such. That’s not a butt cheek, by the way.

The most useful function is the include directive. This is the equivalent of just plain grep on Linux, and will show you only lines that match a string that you give it. Say that you want to find what ports on your switch are down, but don’t want to grind through all the lines of a show ip interface brief. If you just pipe it to the include command followed by the word “down”, you’ll see something like this.

We covered QoS tagging the other day, but that just marks packets. I think you’re old enough now that we should actually do some policing. Policing is where you restrict the amount of bandwidth that a flow or set of flows can use. For example, say you have a site that serves webpages to the rest of the network. HTTP is the primary function, but the SysAdmins also have to maintain the boxes via SSH, right? To make sure that their SSH sessions don’t squash the bandwidth that your HTTP servers need, you can police the SSH sessions by giving the a bandwidth ceiling that they can’t cross.

I’ve been trying to get some experience on Cisco VOIP, and, as you probably know, Quality of Service (QoS) is quite important in that realm. Since VOIP is very time-sensitive, you have to be sure your gear delivers the voice packets first. A packet in an HTTP transaction can wait another 200ms without any problems. A voice packet with another 200ms on it means static and digital artifact on the line. Not good. There are lots of things you can do in the world of QoS, but I’ll talk about tagging this time (I may get to some of the other topics later, though).