RedWarriorNet

I was very, very sick for about a week, which threw my exam preparations into disarray, but now I’m back to studying and I have scheduled my exam for next monday morning.  I’m feeling pretty confident about the material and I’m thinking it will be a great feeling to be 75% done with my CCNP and ready to move on to routing with my last exam, BSCI.  I hope to have my CCNP all wrapped up by the end of the summer and be ready to refocus my studies back on wireless.

I am thinking that, for me, next year will be the year of wireless.  I hope to face again my nemesis, the CCNA Wireless, and defeat it, and then probably move on to the new professional level wireless certification that Cisco is rolling out this summer.  I am considering also trying to work in one or two of the CWNP vendor-neutral wireless certifications along the way.  Wireless is a big part of my current job and I support both autonomous and lightweight Cisco networks and we have the possibility of adding another network made up of a third party vendor’s gear later this year.  That is a lot of wireless to take care of and there are only 2 engineers in our company specializing in wireless, which is a big deal in our particular market, particularly as RFID applications grow.

There’s just so much to learn and so little time.

Ok, I freely admit I have no idea how Men In Black has anything to do with Microsoft Network Load Balancing and the tricks you need to do on catalyst switches to make it work without flooding the network, but every time I heard the term NLB, it just seemed to remind me of the MIB guys, particularly when I read on Cisco’s site about how the tricks Microsoft does with this to make a group of servers answer for a single IP violate the RFC for ethernet communication…seemes like something Will Smith would do if he felt the need, let alone Tommy Lee Jones.  I bet he violates RFC’s every day!

Similar to the DECnet debacle a while ago, this all came up as a result of moving servers into the new datacenter and suddenly finding that a feature that worked at the old datacenter no longer worked in the new one.  While there are other, arguably better ways to do it, Microsoft NLB allows a group of servers to load-balance traffic going to a single IP, like 3 or 4 exchange servers, etc.  It has 2 different ways of doing this.  The first and probably most simple method is to mess with the MAC addresses on the ethernet frame, but since Cisco switches do not recognise this kind of foolishness, they end up treating these frames just like a broadcast, flooding them out all ports in the vlan whether that port belongs to an NLB group member or not.  Ugly.  The only way around this with the unicast method is to put the NLB group members in their own vlan and let them flood all day.

The other method, and the one we are using, is to use multicast IGMP to let these servers make a multicast group.  In order for this to work you have to have multicast enabled on your network and configure a static arp entry for each multicast group, mapping the virtual IP address they will all answer to to a multicast MAC address.  I also found an issue where it is recommended to disable IGMP snooping on your higher end switches capable of it so that these frames are hardware-switched versus software-switched.

After all that, I think I need a dose of that neuralizer!

I’ve been sick and lightly joking that it is “the pig flu” but to be honest, it’s more likley just a nasty combination of a lack of sleep, plus stress, plus a regular flu virus.  2 weekends of major moves in the datacenter in a row have taken their toll on my immune system, with their associated all-nighters.  On the bright side, I have a 4-day weekend coming up this weekend which will involve a whole lot of unplugging from anything remotely network-related.

I did want to drop in before, though, and post updates to the two issues that came up during the moves that I blogged about here.  The first was the problems with the twingig modules and SFP’s on our 4900M’s.  This issue was actually resolved by downgrading the affected 4900M’s to  Version 12.2(40)XO, RELEASE SOFTWARE (fc1) versus the 12.2(50) code they were on.  Apparently, although the 12.2(40) version is the first that supported twingig interfaces, it seems to be less buggy, at least for what we’re doing.  I’d recommend anyone seeing similar symptoms to give it a try.

DECnet…well, it’s still there, but it’s now contained in one vlan.  Apparenlty, forcing these two systems to talk to each other in a current protocol (heck, at this point I’d even take IPX!!) would cost us 7 figures, so for now, we are just isolating it.  I’m just happy we don’t have to try to figure out how to route it.

These datacenter moves have been grueling for everyone involved, but it is satisfying to see these systems on a network with a tengigabit backbone and the kind of redundant power structure they need.  Not only that, but the cable labeling is gorgeous!  I’m going to go take my next dose of airborne and hope the pigs stop flying.