Anyone who has ever administered a Cisco Unified Communications Manager (AKA Call Manager, or CM) system learns very quickly that there are approximately 17 billion different configuration settings in CM. All of those configuration dials have to be maintained in the right ways to get the system to do what you want.

I've taken several Cisco training courses on CM, and I felt like the thing that was missing was a real-world case study of how you setup all the pieces to interact with each other and why. There was no real "best practices" in the classes, just a lot of "this setting does X or Y" without any explanation of why you would choose to do X vs Y.

Read on for exactly that information from documentation I've been working on for the CM environment at my job.

I use OpenBSD's packet filter, PF, and am in the middle of building a new router/firewall with a moderately complex ruleset. I generally code rulesets the same way I write shell scripts: adding small bits and testing. My basic ruleset was preventing routing, and the logs kept telling me that the routing packets were being blocked by a rule that I thought shouldn't.

PF has a feature called "antispoof" that builds a set of rules that block packets that claim to originate from interfaces they shouldn't. The rule looks something like:


@16 block drop in log on ! vlan1 inet from 192.0.2.0/24 to any
[ Evaluations: 9907 Packets: 9283 Bytes: 794994 States: 0 ]
[ Inserted: uid 0 pid 2131 ]


Today I was working with my DBA on a server migration-- the replacement server is configured, loaded, secured- and before we lit it up, she asked me to take one special final full cold backup. No problem!

...until I started monitoring the backup (to estimate when it would be done) - and was seeing well, absolutely horrible backup rates (averaging "2,645KB/S"). Terrible.

So, I started checking the logs to see what kind of tape device issues I was having. Huh- nothing. Backup configuration (parallelism, etc)? Set just right.

Then I remembered- this server was one of those servers that was very recently moved to another rack. I shipped out one of my favorite sysadmin tools, 'ethtool'. OUCH. Not only was my network connection at 100MB (instead of gig speed), but it was 100/half. With one command, I verified that not only was the server plugged into the wrong port in the switch, but that the promised "we'll fix that next week" response from the network team was never followed through (they were supposed to fix the broken autonegotiation on the 100mb ports weeks ago).

Each LISA brings a new challenge or two...or four...so far. The conference network started out barely usable, then went offline entirely twice, then came back up with sporadic outages before finally performing acceptably. I feel like I owe an explanation, so here goes.

The other day I received my shiny new copy of Windows 7 Enterprise. Now, while new OS's don't necessarily drive me, I needed to spend some time on this to test an X-Windows product we use a lot-- ahead of time-- for the users' sake. (X-Win32).

(Yes, I know, typical users and lots of x-windows.. ewwwwwwwwwww.)

So-- off I loaded Windows 7 in Virtualbox. No issues. Connected to my office's domain - check. Outlook/mailbox- check, mapped network drives, check. Antivirus/etc-- all good and finished after a day of fiddling.

Then I loaded our famous X-Windows server on the workstation. Fired up a connection-- and.. nothing. Went back to my trusty XP virtual Machine (same host desktop) - new version of X-Windows software connected instantly.

Today I am going to TRY to start logging a daily blog entry. I'll add more info about myself later, but I am essentially a sysadmin generalist. That means I manage a LOT of stuff, and I don't necessarily specialize in ONE particular thing.

My blog entries are going to be totally random-- mostly tech stuff (some not) - as a means of documenting day to day things I learn or discover. I've been doing this 20 years. I'm still learning.

Today's tip of the day: Broadcom nic drivers suck. That opinion was more or less confirmed from the masses in irc #lopsa today :-)

OK, more specifically, I have a pair of new Dell servers. One of these servers is a backup storage node (legato networker), which means that system has a tape library attached. It also means that when backups start, a half dozen nodes or so start shoving boatloads of data toward the storage nodes in parallel. *HERE*, says the nodes.

For some reason, I get a lot of resumes from people who sign their resumes and emails (including the GECOS fields) with their irc/renaissance faire/SCA/WoW handles .. I should not have to be saying this to grown men and women (let's face it, it's men, and they're not that grown), but if you cannot sign your real name for a resume, I cannot be bothered to do anything but file it into the rejection folder.

This is the story of my afternoon yesterday, Friday 12/5/08. It's a case where the simple act of "keeping an eye on things" caught an anomaly that would've attracted a lot of negative attention from the business and scaled it down to a slight inconvenience.

Last weekend we went to LinuxFest NorthWest 2008 in Bellingham, WA. It was a great time, we handed out a bunch of Tee-Shirts, met a lot of good people, and saw some interesting presentations. I even spoke with around half a dozen potential summer interns.