February 1, 2010 10:49 AM
When it comes to router features, less is more
The other week I had a bit of a rant about people not spending enough time configuring network devices—basically letting the networks do their own thing. I should have known better.
Last week I was in seeing a company that wanted some design advice—the (mainly Cisco-based) network was growing pretty dramatically, and they wanted to be sure it was built so that they could add to it without major upheaval. I started having a look at some of the configurations and one thing instantly sprang to mind.
“Okay guys, who’s studying for their Cisco exams?”
Every feature known to man (or at least to Cisco IOS developers) was enabled somewhere. Some were set up in one part of the network; some in others. The same thing was done in different ways in different places. Some things were configured where they couldn’t possibly work, and some just didn’t make sense at all.
An example: Spanning Tree (I know it keeps cropping up, but we haven’t yet figured out how to do away with it completely). There’s this thing called BPDUGuard — if you configure it on a port on a switch, it tells the switch that it shouldn’t be seeing BPDUs on that port. It’s a user port or something. If the switch does see a BPDU, then it should shut the port down, because someone’s plugged in a switch somewhere they shouldn’t.
There’s also another feature called RootGuard that you can set. Configure that one on a switch port, and the port is quite happy unless it receives a BPDU that claims that the Spanning Tree root bridge is connected out that port (called a superior BPDU), at which point it will shut the port down to prevent rogue root bridges playing havoc with your Spanning Tree layout.
These are both excellent features to configure—but not on the same port! Spot the issue? BPDUGuard will shut the port down if it sees any BPDU. So what’s RootGuard supposed to be doing?
Okay it might not cause a major problem—after all, neither of these features will kick in until someone connects the wrong thing to the switch, and then it’s their own fault anyway. But they’re not designed to work together like that, it’s a bad config, and it’s likely to confuse matters at 3am when some poor soul is called out for a fault and is trying to understand the configuration.
Just because there are thousands of possible commands listed in the command reference doesn’t mean you have to use them all. If you want to see how something works, by all means try it out, but don’t leave it there after, In fact, you shouldn’t be experimenting on live networks anyway—that’s what test networks are for, remember?
Just as too little control and configuration is bad, so is too much. Especially when the configurations you’re saving conflict with each other. It’s a waste of time, the configs get too big and complex, and troubleshooting becomes a nightmare. Pick the key features that you need to protect your network, and that make sense in your environment, and apply them consistently. This is a production network—not a playground.