Beyond the simple WGB configuration, there are several "optional" parameters that you may need to configure.
- Preamble: 3 or 4 MAC addresses
To understand most of these settings, keep in mind some 802.11 basics:
DA (destination address) for the final destination,
SA (source address) for the original source,
RA (receiver address) for the MAC address of the device supposed to receive that frame,
TA (transmitter address) for the MAC address of the device sending that frame.
So for example, if you send from a station A to a station C via an AP B, the frame goes from A to B (during which SA=TA=A, DA=C, RA=B, then from B to C (during which SA=A, DA=RA=C, but this time TA=B). You see that we do not use the fourth address, because it would always be A, B or C repeated. Instead, we just position the addresses where they make sense.
Address 1 is always the device receiving the frame, Address 2 is always the device transmitting the frame, and Address 3 gives additional information about who the original sender was or who the final destination is supposed to be.
The only case where you use 4 addresses is when you have 2 relays... for example a wireless bridge: you packet goes from station A, through AP B, is relayed to another AP C in bridge mode over a wireless link, then goes to your final client D. Between these 2 bridges, you need to tell:
Address 1 = RA = C
Address 2 = TA = B
Address 3 = DA = D
Address 4 = SA = A.
This is a case of "4 MAC address header". In all other cases, you use 3 MAC addresses and the fourth MAC address field is not used.
Why do we care for WGB? Because the big question is: is your WGB a normal client, just like a laptop, or is-it more a sort of infrastructure device?
It all depends of course on what type of non-802.11 clients (and how many) connect through that WGB, and what you try to achieve.
- Universal vs Cisco mode:
During the association request phase, the WGB signals to the AP that it is a special client through 2 special vendor specific tags by the end of the frame and IAPP (inter AP messaging). So the AP knows that this is not a normal client... and this is good! Because as soon as that WGB will complete the association phase, it will start behaving very strangely: imagine, it is going to relay traffic to and from several wired clients. This means that your WGB, MAC address aaaa.bbbb.cccc authenticates, negotiates the keys and everything, and as soon as you say "OK, client aaaa.bbbb.cccc, your are in my cell", you start seeing packets coming from other MAC addresses, 1111.2222.3333 for example, using the same keys as your aaaa.bbbb.cccc client... and you are supposed to find all this perfectly fine and normal! Cisco access points are perfectly fine with that, as long as those packets still have the special WGB tag indicating that it is all coming through the same WGB... but many other vendor APs turn to panic mode and block the traffic (actually exactly as they should, as this is not a normal behavior).
If you want your WGB to associate to a non-Cisco AP, then you may have to moderate its WGB erratic behavior. This quieter mode is called the universal mode (as opposed to the "normal" mode, which is the Cisco mode). In this mode, the AP only displays one single MAC address, exactly like a normal client. No IAPP in this mode, but you can still see the Cisco vendor specific information in the WGB messages, just in case the AP would be a Cisco. The downside of this mode of course is that you can only bridge one non-802.11 client, the one having the MAC address displayed by the WGB.
When you configure the WGB, you define the Cisco or universal mode from the radio configuration section. In the CLI, use:
interface d0 (or d1)
station-role workgroup-bridge
orstation-role workgroup-bridge universal
The
Few things to keep in mind:
- This
- When the non-802.11 client appears on the wired interface, the WGB disassociates then re-associates using this time the
- Are you really limited to one device in universal mode? Well not really, you are limited to one MAC address in the wireless space. If that address is the MAC address of a router connected to the WGB, and if you have 10 devices behind that router, fine! Only 1 MAC address is seen and all is well.
- Infrastructure-client:
By default, WGB are normal clients, okay we saw that. You can configure the AP to see the WGB as an infrastructure client. This is done from the radio configuration section. In the Web interface, in the radio page, this is called "reliable multicast delivery to the WGB". In the CLI, use:
interface d0 (or d1)
infrastructure-client
What does-it do? Well, two things:
- the first one, which is the most publicised, is that if the WGB is seen as an infrastructure client (which is NOT the default), then multicast (and broadcast) packets to the WGB are acknowledged (by the WGB). The advantage is that if you have several clients behind the WGB, you send one broadcast (or one multicast), then a second copy of that broadcast/multicast encapsulated into a unicast frame to the WGB and the ACK from the WGB confirms that the frame was received and is going to be relayed to the wired clients. This increases reliability (usually, broadcasts and multicasts are never acknowledged).. The downside is that it also increases traffic on the radio, as packets that are usually not acknowledged are now acknowledged (and you send as many unicast copies as you have WGBs). So the limitation of this mode is that the AP will not allow more than 20 WGB clients.
- The second one is that if your WGB is an infrastructure client, it can associate to an infrastructure SSID. Infrastructure SSIDs are SSIDs created only to authenticate other APs (bridges, repeaters, etc.). A WGB in standard mode (Cisco or Universal) is by default a "client", not an "infrastructure client" and therefore cannot associate to an infrastructure SSID. Make your WGB an infrastructure client and voila, it can magically associate now to infrastructure SSIDs.
Last detail:
- From a pure wireless standpoint, a question I often get: who is acknowledging those frames, when you have several clients behind the WGB? One of the clients? The WGB itself? The answer is: no-one! An ACK frame does not contain any SA or TA, just a RA...
- Multicast-mode client / infrastructure:
This one is usually happily confused with the previous one, as infrastructure client talks about multicast. But they do not do the same thing.
When you configure your WGB in Cisco mode (so NOT in universal mode, which is incompatible with this feature... well, you can always try, but you won't make them work together), in infrastructure client or not, the WGB will by default use 3 MAC addresses, pretending to be whatever non-802.11 it is relaying traffic for. In the scheme shown at the beginning of this post, you will see those various clients as if they each were wireless clients. The WGB relays their frames, pretending to be each of them in turn.
One downside of course is that the WGB is just a client, and a relay. In a worst case scenario configuration, suppose your WGB has 8 wired clients, and is set as infrastructure client. Bad news, you have 15 other WGBs with the same number of clients in your cell, each with 8 clients, so 128 clients in total... one of them is a phone, that needs music on hold, sent as a multicast frame... you see where this is going? The AP sends one frame, all 8 WGBs receive it, all 16 WGBs acknowledge that frame (nice collisions in your cell!), and as it is a multicast frame, all 16 WGBs relay that frame to all your wired clients, 127 of which don't care... is that efficient? Not really.
Yeah, that's also what they thought at Cisco. Although the fact that the WGB acknowledges or not is based on its infrastructure-client configuration, you still have 127 clients getting a frame they don't care about in any case.
So they built the multicast infrastructure mode. In that mode, multicast and broadcasts sent to a WGB use 4 MAC addresses, instead of 3 MAC addresses when using the multicast client mode.
What difference does that make? Well, if you configure your WGBs as multicast infrastructure, this is what happens:
The AP sends one multicast frame. The DA is the multicast address, but this time Address 1 is RA, the WGB behind which the phone sits (Address 2 is the AP or TA, Address 3 is DA, the multicast address, and Address 4 is SA, the original sender of the multicast frame). All 16 WGB receive that frame (coz they have no choice), 15 of them drop it because RA is not their MAC address, and only one WGB takes the frame, acknowledges it or not depending on its infrastructure-client configuration, then relays it to its wired interface. 8 clients receive it, 7 that do not care, plus our phone.
This mode is more efficient... in that case.
You configure that mode from the CLI with the command:
interface d0 (or d1)
station-role workgroup-bridge multicast mode {infrastructure | client}
Notice, again, that this mode is not compatible with Universal. Using station-role workgroup-bridge multicast mode blahblah meansh that you say "station-role workgroup-bridge", which is the default, and not "station-role workgroup bridge unversal
There is no mode configured by default, which means that the WGB would accept any frames, with 3 or 4 addresses. You can force the mode one way or the other (3 addresses or 4) depending on the special case you try to solve.
- Mobile-station
WGB are not good roamers. They connect to an AP and stay there until they disconnect. If you WGB is mobile (on a cart in an hospital for example), you may need it to roam better. You can imrpove its roaming behavior with the CLI global config command:
mobile-station
When you enable this setting, the workgroup bridge scans for a new parent association when the RSSI to its AP gets too poor or when it has to many retransmits. This makes that the WGB will roam when its signal to the AP degrades. When the mobile station setting is disabled (the default setting) the workgroup bridge does not search for a new AP until it loses its current association.
Additional tricks:
These two are borderline I would say, in the sense that you would not use them everyday... but there are cases when they can be useful:
- Scanned channels:
Just like a normal client, the WGB will scan all channels to discover an AP with the right SSID. This may take time, and be a waste of time if you use the classical channels 1/6/11 scheme. In this case, you can configure your WGB to only scan the channels on which you know that you have APs, instead of scanning all channels. This is done at the radio level, with the CLI command:
int d0 (or d1)
mobile station scan 1 6 11
- CCX neighbors
This setting is related to the channel scan. When the WGB scans, it actualizes its list of available APs. This is a CCX mechanism by which the WGB can transmit to its AP the details of the others APs the WGB heard. When you statically configure which channels to scan, the logic is that you know on which channels you have APs, so you don't need the WGB to tell you. You can therefore disable the CCX neighbor list building with the CLI command:
int d0 (or d1)
mobile station ignore neighbor-list Wowoo, that was a long post, sorry for that. I hope it clarifies things... comment if you have any addition or question!
:-)
Posts
