Showing posts with label Wireless. Show all posts
Showing posts with label Wireless. Show all posts

The IT Conflict: The Network vs. Users. Part 1


We can all agree, working in IT has its challenges. A friend recently asked me "What has been the most significant challenges in IT recently?"

To that I say "how much time do you have?"

Over the years we have seen many technology innovations.  Some have been business focused while others have been consumer focused.  Business focused innovations improved network performance and reliability, application intelligence, business efficiencies, and security. Consumer innovations have focused on features, functionality, and ease of use. Often, consumer innovations have created headaches for the IT department.

I remember, back in the day, installing VPN servers when dial-up modems were the norm. Who would use a VPN when they could just dial in? A short time later, broadband Internet connections exploded, end user signed up like mad, and nobody wanted to access corporate resources through a dial-up modem any more. We struggled to install VPN servers with enough capacity.

Then wireless Ethernet appeared. Business users could connect their company provided laptops to their home wireless networks, but still had to plug-in at work. Why did they have to plug-in at work?  “Can’t the IT department implement wireless as easy as at home?”

So we struggled to install standalone wireless access points. They were cumbersome, then we figured out centrally managed wireless networks were much more efficient.

Today many organizations have deployed remote-access VPNs and centrally managed wireless networks. Business users, from home, hotel rooms, conference rooms, airports, Starbucks, or other locations, can securely connect to the corporate network. In the physical office, business users can connect with wired or wireless connections and easily access the same systems. We even can support “Guest” wireless connections
We could finally rest,  IT finally caught up to the users. But, like Steve Jobs likes to say, “but there’s more”. ...Great!@$%

Now we have business users bringing in other devices not provided by the IT department. I have a customer who has a XBOX in a conference requiring wireless Internet access.

It is now a reality; IT Departments now have to support Smartphones. Business users expect “always on” connectivity.  Users expect to not only have continuous access regardless of their platform.

Not only does the IT department have to pay for the Data plans, they now have to support the wireless Ethernet connectivity requirements. It would be easy to not support wireless Ethernet connectivity, but the cost of cellular data usage has to be considered. It is now financially prudent to allow Smartphones onto the business network.
Now, do we want the smartphones on the “Guest” wireless network, or the “internal”. Both have their advantages. “Guest” lets the user connect like they are at home but they may have to sign in to a “Guest” splash screen.  An “internal” wireless connection may open up the network to security hazards.

And then someone in management had to go and get a tablet. It could be an iPad or an Android device, it doesn’t matter. The IT department didn’t buy it, but it needs to connect to the network.  When the connection doesn’t work, we hear “what do you mean ‘no more IP addresses are available’”, “when I’m in my office, Angry Birds is slow”.

In my next installment; Unified Communications – home user features vs. business users’ functionalit


Home

Cisco Wireless AP - LWAPP: How to Recover an AP from Mis-Configuration

I am quickly learning Cisco Wireless. I had a problem with a Cisco LWAPP AP located at a remote office. This AP had not previously registered with a Wireless LAN Controller (WLC). We rely on the DNS discovery method where the AP boots up and does a DNS lookup for CISCO-LWAPP-CONTROLLER or CISCO-CAPWAP-CONTROLLER.

Well this is were the fun began. IP address and name-server was manually configured in the AP, but the name-server IP address was fat-fingered. The APs will save their IP and LWAPP configuration automatically. On a reboot, the AP came up with the same configuration. I was finally able to restore the configuration to factory default and have it discover and join the controller.

To do this a console connection to the AP is required. I had a user at the remote office connect a console cable to a notebook and let me RDP in..

1) I need to clear the static IP address settings, convert to DHCP, and have the AP connect to the WLC. With LWAPP/CAPWAP APs, you can't just go into the config and change things.

"debug lwapp console cli" (if that doesn't work try "debug capwap console cli" )

This allows me to make changes to the running configuration, but these changes can not be saved to what us router-jockeys call "startup-config". The "magic" here is that when a LWAPP/CAPWAP access point connects to a WLC, it saves the controllers address in nvram. Thus when reboted, the AP always knows which WLC to try to connect to.

"interface f0"
"ip address dhcp"

I created a DHCP pool on the core switch and included the correct DNS server. In about 5 seconds, the AP obtained an IP address and the new DNS server. Then it registered with the controller

2) One problem. After rebooting, the Cisco Wireless AP came up with the old static IP addressing and DNS old/wrong DNS server. I was, however able to register with the controller because it had previously registered with that controller.

3) I logged into the Cisco Wireless Control System (WCS) and found the AP. I removed the Static IP setting and saved. The AP rebooted and registered, still had the wrong DNS server.

In WCS I went to Configure - Access Point and found the AP, scrolled to the bottom for "set to factory defaults", clicked "clear config".

Finally cleared it!

Home