Category: Uncategorized

Supporting Apple devices on the WLAN

Since the iPad was released, it has received a mixed welcome within Enterprise environments. While a lot companies have at least some plan to move forward with iPads, these drivers are usually coming from the business side, instead of IT. In-fact, most IT shops are being dragged into IOS support with strong reluctance.

The broad questions which are causing resistance can be summed up in one word: SUPPORT. IT departments must figure out how to support the device in multiple areas. Information integrity and control, end-user support, and connectivity support all must be dealt with. Since this is a networking blog, I want to deal with the last one; and will do so in the next two articles.

Supporting iPads on the network is more complex than connecting them to an SSID and providing login credentials. If we look at the standard iPad user in most organizations, we see a highly mobile user, users who also have laptops. Most of these users requested an iPad after having a positive experience with their company issued iPhones. That translates to a user having three wireless devices at there desk at any given time: their laptop, their iPhone and their iPad.

To understand the problem this creates, let’s look at how we survey for a wireless network. There are two considerations: coverage and capacity.

Wireless Coverage
A survey can be  based on square footage, and provide a certain RSSI from wall-to-wall. This is a perfectly acceptable way to survey if everyone has their own office. However in Cube-ville, a single AP may cover 100 desk or more. If each desk has one wireless device, you now have a physical medium (the channel or airspace) that is incapable of supporting all of the connected clients.

Wireless Capacity
The other way to perform a wireless survey is based on capacity. In a high capacity environment, the wireless spectrum, not the AP is the bottleneck. More on this later…

In a capacity based scenario, a number of desk are chosen, lets say 25. For every 25 desk, there is an AP. Those AP’s are placed based on coverage area, and in to minimize channel overlap. For the same 100 desk in Cube-ville, you now have 4 AP’s. Since there will be channel overlap, the radios are turned way down, and in general, the physical medium is now capable of handling the number of clients.

Taking this environment to the next step, each desk gets an iPhone, and a few months later, 1 in 4 request an iPad. We can safely assume that complaints will begin coming into IT about the wireless network. The AP airspace that was previously servicing 25 clients now contends with 62 per AP. Time for another wireless survey and at least twice as many AP’s!

Now we can see the problem that many companies are facing. The i-devices are here, and businesses seem to love them. The network team must begin planning and building now. I would like to make a few suggestions which might keep network teams from finding themselves behind the eight  ball.

  • Budget to begin surveying your high density environments now.
  • Develop a plan for support, complete with timelines and cost. Present this to the highest management level you can reach, so that it can be considered as the business begins planning device deployments.
  • If your company has a charge-back system for devices, be certain a cost is associated with each IOS device to support the wireless network going forward.
  • Be certain to include a survey and additional equipment as a cost of any iPad rollout projects, make certain the business can see the total cost of deploying iPads and iPhones.
  • Finally, be first in line to get an iPad if you don’t already have one. You can’t support what you don’t understand; besides, it really is a great device.

I realize that there are other options out there other than the “i” devices. However, I haven’t heard of, or seen, a single enterprise level roll out. However, these rules apply to the world of Android and Windows too. More devices per square foot equals more demand on the wireless network.

The velociraptor died after choking on a rib bone, so creating IPv7 is out of the question

OK, I admit it. I’ve had my head stuck firmly in the sand for almost 11 years. 11 years ago, to the month, I was sitting in my first TCP/IP class. I had fought through the first two days of class feeling mentally exhausted. I was finally beginning to wrap my head around IPv4 and variable length subnet mask. In fact, I was understanding IPv4 well enough that I could help my fellow students decipher the statements coming from our newly minted (and very proud of it) CCIE.
I was feeling pretty good about myself, and may have started to strut, just a little, as I moved from desk to desk, helping other students.
I should mention now, that I’m fairly quick on the up-take. I’m not bragging, simply stating that I meet the minimal requirements to be a geek. For some reason, I had really struggled with IPv4, so once I felt like I had a firm grasp of the concept, I was feeling pretty good.
My CCIE instructor, from his seat of power, saw a little pride develop in his class as more people caught the basics of VLSM. He, in the ultimate wisdom which comes with that coveted CCIE number, decided it was time to strangle those good feelings until they were most certainly dead. He did so, by launching into a 30 minute diatribe of how IPv4 would die a “quick death” and how IPv6 would take its place.
I’m sure you can imagine the look of horror on the faces of the students in the room. He certainly saw it, and fed off the fear as he blew through the broad topic that is IPv6. He delighted in mentioning that every device would have multiple IP’s, that each IP would be part of a different subnet. He threw out new words like anycast to a group of people who barely understood muilticast and unicast.
Wait, what?
In 30 minutes, he convinced three students that IT was not really the field they wanted to pursue, and the rest that IPv6 was EVIL. I was so affected and confused by that 30 minute rant, it took me five years before I had a practical understanding of subnetting IPv4 networks again.
Since that time, I have done my best to ignore the existence of IPv6. I used the fact that vendors were still releasing new products without IPv6 support as a reason to keep my eyes and ears firmly closed.
<My IPv6 Rant>
I believe that when IPv6 was being created someone said, “Yes, we COULD do that, but SHOULD we do that”. The rest of the attendees sat silently as he was taken from the room, and forced to watch his organs being fed to a genetically engineered, but very bored, velociraptor. The group then hired a soothsayer to read the velociraptor droppings, which gave us IPv6, reality TV, and the song “Friday”. The velociraptor died after choking on a rib bone, so creating IPv7 is out of the question.
</My IPv6 Rant>
With that said, IPv6 is here to stay, and it’s time for us, as Network Engineers, to get on board. We can’t complain about NAT64, without being willing to make the commitment to IPv6. When new protocols like TRILL are brought up for discussion, it’s easy to get excited. TRILL takes something that we already know (IS-IS, L2, etc) and simply builds on it. It is also transparent to layers 4-7, so it doesn’t affect non-network types.
IPv6, causes us to backtrack. It changes all of the rules. It’s not just IPv6, it’s new routing protocols, DNS, application stacks, etc. We have to forget what we learned in IPv4, and relearn it for IPv6. Server admins and developers will also have to update their skills. It’s painful.
With that acknowledged, we can’t put off learning to subnet, route, and filter IPv6. It’s time to begin examining IPv6 routing protocols, and buying equipment or ordering circuits which don’t support IPv6 should be out of the question. Yes, it does feel like starting from scratch. Yes, you will have to learn every protocol that you thought you knew all over again. Yes, IPv6 makes everything more complicated.
System Admins and developers can’t support IPv6 until we do. We must move forward, so that they can move forward.
Most network engineers agree that NAT is a poor solution to the problem staring us down. There are only a few other options. We can upgrade our skills, beginning the long arduous task of becoming experts in IPv6. We can ignore the change, until we are required to upgrade; then deal with entire IT teams being unprepared, learning on the fly, while implementing poor solutions in the near-term. Finally, we can make the same choice that those three classmates of mine did. “Maybe networking isn’t for me, I’ll go do something easier, like lion taming.”

Comparing Cisco and Juniper – Why doesn’t Cisco do this?

In Cisco land, we have all learned that when making changes to a remote router, you have to be ready for anything. Most admins that I know start any changes with the command:

Reload in X ( x=time in minutes to make and test changes)

The idea being that if a command is made incorrectly, and the remote router stops responding, it will reload itself in X minutes, and become accessible again since the changes would not have been saved. It’s a good idea to do this, and it’s saved my butt a few times.

However, it’s not the most elegant solution. If the router is a production level router, and the change that made the terminal unresponsive hasn’t affected it’s ability to route, it’s still going to reboot. Clients will figure out that you screwed up while they wait for the router to post, load, rebuild routing tables, etc. Darn those fat fingers, and enter key muscle memory.

Enter Juniper’s Commit Confirmed X command.

As some of you may know, changes in JunOS aren’t applied to the running config until they have been committed. (ANOTHER great idea.) Thus, it is easy to check, and recheck your changes without losing your session because the commands have yet to be applied. Once they are committed, they are all applied at once.

Now, I know what you are thinking. If you are able to cue all of your changes, review those changes for errors, and then apply them all at once, you shouldn’t ever need to rollback those changes, right? *Clears throat* Right.

BUT, if you did, somehow miss an important command, or maybe that subnet should have been a /22 instead of a /30, that’s where the Confirmed part of the command comes in. If the router stops responding, the changes are rolled back in X minutes to the previous config. No reloads, no angry emails, no voicemail, and no meetings.

To stop the router from rolling back those changes, simply commit the changes a second time after it is clear everything is working (and before X expires).

Filtering LLDP and CDP packets with Wireshark

I have written an update to this post, which can be found here. It has better information, better filters, and a better attitude.

We’ve all seen the picture of the IDF which looks like a tornado has ripped through it, with cables hanging everywhere. Generally there are two reactions. The type A people in the room shudder and wonder how anyone could work in that environment. The type B people shrug, and think about all of the ways that it could be worse.

Sadly, we don’t always have control of the cable management in the places we work. Whether it is a customer’s site, or we have managers that don’t care about organization, we will eventually find ourselves entangled in cable, trying to trace a wire from patch-panel to switch.

What if it was easier than that? Anyone who has ever had the pleasure of using a Fluke Optiview, knows that it happily displays CDP info right there on the home screen. The problem there exist when management sees the price point of a Fluke Optiview and begins laughing uncontrollably. There is a better cheaper way though!

With the proper Wireshark filters, it’s quite easy to find the port ID using either CDP or LLDP for those non-Cisco devices.

The best CDP Wireshark filter that I have found and used for years is this:

ether[12:2] <= 1500 && ether[14:2] == 0xAAAA && ether[16:1] == 0x03 && ether[17:2] == 0x0000 && ether[19:1] == 0x0C && ether[20:2] == 0x2000

Sadly, I don’t remember where I found this, to give credit, it was a long time ago.

For LLDP, I’ve found a much simpler capture filter that seems to work well:

ether proto 0x88cc

Yes, that is it. I found this on Wireshark’s website.

Hopefully, this will help you like it has helped me to identify ports without doing the IDF Tango.

Thoughts on the new job…

First, what were they thinking, hiring me?
Really, I’m a Cisco network engineer, with loads of Microsoft experience. Cisco wired, wireless, voice, security, you name it, I’ve done it. Microsoft NT, 2000, 2003, 2008, IIS, SQL, AD, yep, yep.

The new job:
HP.
Juniper.
Linux.

I haven’t felt lost in IT in a long time. I will say, I LOVE to learn new things, so I think I can become a very effective team member in short order.

Next, what a cool company!
From the Company Concierge, workout center, free drinks, masseuse appointments, to my own four walls and the “fun room”; everywhere I look I see things that make me laugh at my experience while working at Honda. I’m working with a strong team of individuals, who know what they are doing, and care about the future of the company. In fact, after working at Honda for 4 years, I’m not quite certain what to do: listen to the silence that comes with having a private office, or listen to PacketPushers, some other podcast, or even music * gasp* since I can do so without incurring the rath of those around me.

Finally, what I’m learning.
Luckily, I learn well under pressure. I’ll continue to post here about the things that I’m learning through these new challenges. Maybe I can help another Cisco or Microsoft engineer break free in the process.

For example, no matter what, DO NOT press CTRL+ALT+DEL while at a Linux machine to lock the station. This is not Windows.