Work Group Bridges (WGB) are used in Radiology, Cardiology Imaging, and Telemedicine for nomadic systems from Avaya, GE, and Phillips (for example). These systems do not have an integrated wireless NIC option. The department workflows require wireless service to reduce inconvenience to patients of moving their beds from a diagnostic room to an imaging room. In the Emergency Department, having theses systems mobile can speed up trauma diagnostics and can result in faster and more positive patient outcomes.
Step 1. Join Light Weight AP to Wireless Controller
- Connect the AP to a routed network that can reach the Cisco Wireless Control System either by L2 or L3. You will need to ensure that the DNS record for Cisco-Capwap-Controller is pointed to the Cisco WLC that you wish to use to manage the AP.
- The AP will connect to the WLC and download the current code, extract this code, reload, and join the controller as a client.
1. AP attempts to join the WLC but needs to upgrade code.
2. AP upgrades and reboots and joins the WLC.
Step 2. Convert LWAPP AP to Autonomous AP
- Set local user name and password to the AP from the GUI of the WLC.
- Console into the AP and login with the username and password you set in the WLC for the AP.
- Erase the startup-config and copy the running config to the AP.
- Download the Cisco Autonomous Code to the AP.
- AP reloads. *Unfortunately this causes an issue which I will describe in the next section.
1. Create local credentials for the AP.
2. Console to the AP using the credentials you created to login.
3. Erase startup-config. Download new config to AP.
copy ftp://username:password@FTPServerIPAddress/Filename startup-config
4. Download the Autonomous Code for the AP.
archive download-sw /force-reload /overwrite ftp://username:password@FTPServerIPAddress/Filename
5. AP reloads. *Unfortunately this causes an issue which I will describe in the next section.
Step 3. Connect Client and Correct Configuration
- Connect the WGB to the client. The AP will reload.
- Correct the configuration.
2. Correct configuration such as hostname and any other commands that align it with the current golden standard.
Step 4. Correct Bridging Issue
During the build of the WGB the AP reloads while still connected to your wired network. The bridge enters the mac addresses that it learns about from the VLAN into its bridging table. If twenty mac addresses are entered into the bridging table the client’s mac address won’t be entered and any traffic won’t be forwarded. The Client won’t be able to get an IP Address since the DHCP Discover won’t be forwarded. The WLC message log will show that the bridge wired clients are maxed out. It is possible you won’t see this issue if the VLAN that you connected the AP to has no other device on it, or if you are in a lab environment with few devices. Reloading the AP will not clear this table. You have to de-authenticate the AP from the WLC.
Show Bridge 1 (assuming your bridge group is bridge group 1)
On the WLC you will see the following message in the message logs.
To easily find the bridge mac address type the following command in the console session on the bridge.
show dot11 bssid
You can verify the error in the WLC CLI by entering the following command in the terminal session to the WLC.
show wgb detail BridgeMacAddress
De-authenticate the bridge in the WLC CLI by using the following command.
config client deauthenticate BridgeMacAddress
Verify that the WGB associates to the SSID and WLC by using the following command in the console session of the bridge.
show dot11 associations
Verify that the WGB forwarding table is now cleared and has the client’s mac address in the forwarding table. In the following example the ec8e.b56d.70f3 is the client station attached to the bridge. The WGB should now work.
show bridge 1 (assuming you are using bridge group 1)
I will be going over the WGB config that I used for bridges in the next document. Chalk one up for the good guys and patient care!