Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Wireless LAN Solution Engine with Cisco expert Keyur Shah. Keyur is a customer support engineer at the Technical Assistance Center (TAC) Cisco Systems, Inc. He specializes in Cisco Network Registrar, Building Broadband Service Manager and Wireless LAN Solution Engine. Feel free to post any questions relating to Wireless LAN Solution Engine. Remember to use the rating system to let Keyur know if youve received an adequate response.
Keyur might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through October 31. Visit this forum often to view responses to your questions and the questions of other community members.
One of our customer is having this wierd problem. They have two VLAN's - one for wireless and the other for the LAN. The wireless users can also plug the laptops to the LAN and use both the networks. Some of the users have brigding configured in the laptops. At times, this will result in the broadcast packets getting leaked from the LAN to the Wireless VLAN. The major problem they are facing is that the DHCP packets from LAN clients are getting leaked to the Wireless VLAN and hence the LAN Clients will get an IP Address from the Wireless VLAN, resulting in network connectivity problems for the LAN Client.
The biggest challenge to take care of this issue is that our customer has limited administrative control on the user laptops. Also this is a very large college network and they have some limitiations to do any type of authentication methods for the wireless network. I guess this is a common problem in college and university networks.
My questions are
Is there any tool or method we can use to track down the Wireless clients that are doing the briging ?
Does the latest version of WLSE has any new features that will help us deal with this issue ?
Theres no way on the WLSE to check / track clients doing bridging. The WLSE is primarily used to manage the APs themselves, and not the clients. However it does get details like how many clients are connected , etc by querying the mibs on the AP.
Universities generally have some form of client class processing set up in their DHCP server to assign clients IPs from certain networks. This way they can also control who can log onto their network as they maintain a database of MAC addresses. You might want to look into the Cisco DNS/DHCP server Cisco Network Registrar (CNR) for doing this.
How does Cisco handle roaming users going from a wired LAN to a wireless LAN if the two networks are in on different VLANs?
This event is targetted towards management of Wireless LANs using the WLSE management box. Your question would be more appropriate for the wireless-mobility topic. In any case, here's a white paper that should help you out.
This event is targetted towards management of Wireless LANs using the WLSE management box. Your question would be more appropriate for the wireless-mobility topic.
Can you please go over the support that the WLSE has for other vendors AP's.
I have customers with wireless deployments however they have a mixture of Cisco and various other vendors. How does Cisco support them, if at all?
Cisco WLSE only supports Cisco products. Please see this link to the documentation guide that list the supported devices as of the latest 2.0 version.
Can you cover or provide reference(s) on integrating WLSE with an existing CW2K LMS/RWAN network management environment? I currently have @20 AP1200s (IOS), all are recognized by ANI and RME is currently backing up the start-up and running configs. How do I go about turning over the management responsibilities to WLSE and what integrating would I want to keep with CW2K?
WLSE is a hardware appliance of it's own. You can integrate it with your CiscoWorks management station by using CiscoWorks Management Connection to add external application links to a CiscoWorks server's navigation tree. These links let you access applications directly from the navigation tree.
To add a link to a Wireless LAN Solution Engine, you install a connection to the WLSE's URL.
Step 1 To access CiscoWorks Management Connection, enter the CiscoWorks server's URL in a browser (for example, http://my-cw-server:1741/).
Step 2 Select Management Connection > Administration > Create.
Before a connection is installed, Management Connection ensures that folder and item names do not conflict with names on the local server and verifies that the URLs are active. After a connection is installed, the newly defined folders and items are added to the Management Connection drawer.
That's the only integrations possible. LMS/RWAN will maintain their own databases if you want them to. WLSE will however need to maintain it's own. I would recommend that you let WLSE do it all for your wireless devices.
I hope this helps.
Thanks for helping us out Keyur.
1. How do you configure WLSE's template feature if you have both AP1100 and AP1200 platforms in a given site? To be specific, since all the APs listen for DHCP option 67 for the "bootfile.ini" file, it would seem that I can only support the templating of one platform, not both within a given network segment. In the future, might it be possible for an AP to refuse one .ini file and request a different one (akin to the process of SCCP phones requesting templates from a CallManager)?
2. Is there a way, after a device has been templated, to have WLSE send out an email stating that a new wireless device has been detected and needs additional configuration and approval as a managed device?
1. The key is to be able to create different scopes on the DHCP server for AP1100 and AP1200 and specify different bootfiles. If AP1100 and AP1200 use a different class identifier, a different scope can be created based on class identifier. Otherwise, a list of MAC addresses can be directly added on the DHCP server in the respective scope.
I don't think there's a roadmap for the AP to implement the feature that you are refering to.
For your second question, WLSE currently does not send any email on discovering new devices. Rather it puts the new devices in the New folder and the administrator would need to login to WLSE and move these to managed state.
When does the WLSE supports the WGB350? Bc we have many WISP with much WGBs on the Customer site. but with the wlse they cant manage them. We just see them as clients. Are they getting managed by the WLSE in a further release?
Workgroup bridge is treated as a client and that's the only way it's supported. So you can see this in the reports and client tracking, but WLSE doesn't offer config/firmware upgrades to WGB.
Regarding future roadmap, I've sent an email to the Product manager , and shall update you as soon as I have an answer.
According to the product manager, there are no plans to support the WGB in the future releases of WLSE.
But im not so happy =). Bc we have some WISPs which have more than 300 WGB on the client site and many Bridges. And we cant really manage them. so with the wlse that would be great.
In the Cable world you also can manage the cablemodem =:-).
Maybe you can sent the infos to the product manager.
but thanks for your reply.
Sorry about that.. There's still hope :)
You have 2 options here.
1> Open a TAC case and have the engineer file a feature request on your behalf.
2> Talk to your local Cisco sales engineer and have them file a PERS request with the Engineering department.
I would recommend going the second route as that's much faster.
We currently have 150 1200 AP's using the B radio . We have just ordered the new G radios but were told we have to move from VXworks to Cisco IOS. We do have the WLSE appliance and plan to use it.
How does the WLSE help rollout the new radios? Also I understand we have to use the conversion tool from VX to IOS. Can we automate this with WLSE ?
WLSE can be setup as the TFTP server for the newly connected AP to get it's config from. As long as the AP can get the IP address from a DHCP server ( which also gives it the IP of WLSE as TFTP server), the AP can boot off from a config on the WLSE.
To set that up, please read here.
Also, you may definately use the WLSE to do the conversion. Heres the detailed instructions on how to do it.
That's a link to the WLSE 2.0 user guide. Please use WLSE 2.02 to do the conveersion, as there are some bugs with the process in WLSE 2.0