Wireless In Healthcare

And now for something completely different!

Life has thrown me a curve ball this month, which helps explain my recent absence.  Without getting into any gorey details, suffice it to say that my relationship and living situation status has abruptly changed, which is also putting my financial status into an unknown state.  Still, happily, life goes on and I’ve been concentrating more on a big project at work and putting my studies on a temporary hold.  This project is a huge one, involving a large hospital campus and surveying for a completely new 802.11n wireless deployment which will be VoIP grade.  I feel lucky to have been involved with this project early on and to be doing so much of the leg work on it as it’s been a huge learning experience.

Working in IT in Healthcare always presents unique opportunities and challenges and nowhere is this more apparent to me than when it comes to wireless.  It seems like every day a new application is found for wifi or RFID and it really does have the power to make a huge impact on the day to day workflow of physicians and nurses.  Whether it’s improving communication to staff on a critical care floor, allowing remote assistance in the OR for special surgeries, or even tracking babies and making sure they aren’t taken out of the nursery by the wrong people, or tracking temperatures of refridgerators so that staff don’t have to, wireless is going everywhere.

Unfortunately, just like the wild wild west, this frontier isn’t always understood by those pushing us to explore it.  Most people think wireless networks are all just as easy to set up as their network at home, but enterprise wireless networks require very careful planning and a lot of surveying.  Then add to that the unique architecture of a hospital campus.  Before I worked at a hospital, I thought they were just buildings with some different walls and such.  Nope.  Hospitals almost grow like organic organisms, with old buildings merging into new ones, the lines between blurred and constant change and construction.  Then there are all the building systems in the walls, from lines for oxygen and water, to lead walls to protect an X-ray room that hasn’t been there for 20 years.  Then you have hallways that are a constantly changing landscape of beds, carts of food trays, IV poles, and other obstructions.  Finally, you have the shiny floors, stainless steel, and glass.  Why is all this important?  Because it all adds up to an environment that is probably the least suited to clean RF signal propigation!  I’ve actually talked to an engineer at another hospital who resorted to bringing in a company that specialized in deploying wireless networks in coal mines to get their wireless network to work.

What this all boils down to is that you have to become intimately familiar with each and every building that you are going to be deploying wireless in.  You survey and tweak and survey again, walking each and every square foot you can get into, whether that means putting on scrubs to walk around the Operating Rooms, or dodging your way through a busy Emergency Room.  You get to know it all and you design a network tailor made to fit it.  Then, when things change, as they will before you even finish, you survey again and adjust with the changes.  I’d recommend a good pair of walking shoes and some weekend weight lifting to anyone considering such a career.

What makes it worth it?  A network that helps doctors and nurses do their job even better than they already did, which means patients might get taken care of just a bit better because of you…how often does a network engineer get to play hero or pretend to be Dr. House?

Multi-Area OSPF LSA Types

I started off my studies today with some review of multi-area OSPF before I dive back into IS-IS, which is definitely proving to be a challenging topic.  One of the toughest things for me to grasp about OSPF so far as been the different LSA types that routers use, which routers use them and which ones stay within a specific area.  Below is a table to try to help make this a bit clearer in my own mind:

LSA Type 1 - Sent by All OSPF Routers - Stays within one area - Also called Router Link States
LSA Type 2 - Sent by BDR’s Only - Stays within one area - Also called Net Link States
LSA Type 3, 4 - Sent by ABR’s Only - travels outside areas - Type 3 is also called a Summary Net Link State and is a Inter-Area Summary Route - Type 4 is also called a Summary ASB Link State and is a route to the ASBR
LSA Type 5,7 - Sent by ASBR’s Only - Travels outside areas - Type 5 is also called External Link State and is a route that has been redistributed into OSPF - Type 7 only exists within a NSSA and is translated into a type 5 LSA when it leaves the NSSA, otherwise it is the same as a type 5.
LSA Type 6 - This is reserved for Multicast OSPF, which is not current supported by Cisco

Let me just write out some of those acronyms…

ABR - Area Border Router - Connects OSPF areas and has at least 1 interface in each area.  Route summarization happens here.
ASBR - Autonomous System Border Router - Connects 1 routing domain to another, often with a different routing protocol.  This router does redistribution of external routes into the OSPF domain.
NSSA - Not-So-Stubby-Area - Essentially, this is the same as a Stubby Area, except that it contains an ASBR and a link to an external network.  Otherwise, it has only one path into the rest of the OSPF network.
LSA - Link State Advertisement - the messages that OSPF routers send each other to update their topology tables.

EIGRP for Me

This has been the week of EIGRP reading for me and it is soon to become the week of EIGRP labs as well.  I’ve learned a ton I didn’t know about EIGRP, both good and bad and now I feel like I’m ready to hit some labs to make this information a bit more concrete and get my debug fix in without crashing production systems.  (Always good to get a safe debug fix!)

With that in mind, I plan on attempting to install GNS3 on my Windows 7 RC1 laptop at home tonight.  Yes, I know I could just toughen up and do straight dynamips, but I’m just not feeling it right now.  I’m thinking that GNS3 will be a kinder, gentler introduction to router emulation than just diving headfirst into dynamips.  I’m also thinking that I will spend part of friday (hopefully!) sneaking back into our spare equipment room at work to see what spare routers and MLS might want to be a part of an EIGRP AS this weekend.  I may also seek to answer a burning question, “What can you do with a 6509 that’s missing one of its redundant power supplies?”

Overall, my first week of hardcore study has been going well.  I probably managed a combined total of 8 hours of study over the weekend with a solid hour last night and now I’m hoping for a bit more tonight.  The real challenge is keeping my mind alert after a long day of work, particularly as I spend most of my days lately doing wireless surveying, which is a bit tiring physically as well.

MS NLB on Cisco Switches?

mibOk, 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!