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'm teaching on LDAP at SCaLE U today, so I've uploaded my slides in advance.

OK, not related to work, but worthy of a blog entry at least.

The other day I dove into VOIP for the first time. I admit, I'm a bit of a holdout with regards to my home phone service. I'm also old enough to recall the days when the phone in our house plugged into the wall with that huge 4-prong plug, and Ma Bell engineer(s) needed to do ANYTHING with regards to phone jacks or phones. If you so much as clipped a wire, out came the Bell-Police :-) Getting to the point of cutting my AT&T service is emotionally difficult. I've ALWAYS had AT&T.

Anyway, I finally decided to switch to VoIP and cut my land line. I'm not there yet, as I'm currently testing out the device first. I opted for an "ooma", which is essentially a product that's "VoIP in a box". You pay for the unit (about $200 US), and that's it. Everything else is free for as long as you own the unit. No monthly charges, no fees, no regulatory charges, nothing. Free local calls, free long distance. And they support porting your land-line number to the device when you're ready ($40 fee).

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 ]


I love it. Just when I start getting a little bored..., something comes along that basically makes me go, "WTF?" - and ends up giving me a chuckle in the end. There's stuff that's broken, and then there's stuff that's REALLY broken....

Very recently, we've been tasked with helping migrate key components of an old server that belonged to another department. We're going to migrate the important stuff to a new server of ours,and retire the rest. A lot of this has been my task, but it also involves our DBA and a handful of developers taking a little time on the side to hunt and migrate.

The cool thing about being a sysadmin is you're always learning - whether you want to or not...

Today I sent an email to a colleague from my corporate email account, and while we were IRC'ing about other stuff-- he told me that no, he didn't get the email. Huh. I double-checked my sent-items folder-- yes, the email address WAS correct. No, still no email.

About 2 minutes later, he eventually found it - in his 'Spam' folder.

While I was thrilled he got the email (something that took me a bit of time to compose), I was now immediately wondering- why the heck was my email, something that contained only technical text (no attachments), considered as SPAM? Time to check it out.

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.