A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Tuesday, September 7, 2010

Workgroup Bridge (WGB) CLI commands

Workgroup bridges (WGB) are IOS access points configured as clients to the wireless infrastructure. They can associate to Aironet IOS APs or LWAPP/CAPWAP APs. They usually are used to relay traffic from non-802.11 clients, acting as a sort of common wireless NIC for those clients.

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:
 This is an 802.11 header. It has up to 4 MAC addresses. The logic is that if you send a frame from a wireless client to another wireless client via an AP, you need 3 MAC addresses: the source (the original emitter), the final destination, and the AP. Then we use the terms:

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
or
station-role workgroup-bridge universal .

The has to be the wired MAC of the non-802.11 client talking through the WGB. The WGB will become transparent, and the only MAC address you'll see in the wireless space will be the MAC of the wired client

Few things to keep in mind:
- This wired client must exist. If the WGB does not detect that MAC address on its Ethernet interface, it associates to the WLAN using its own MAC address, which means that you see in the wireless space the WGB BVI1 MAC address instead of the client behind.
- When the non-802.11 client appears on the wired interface, the WGB disassociates then re-associates using this time the wired client MAC address.
- 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!
:-)

22 comments:

  1. Hi Jerome,

    you are mentioning the IAPP - is there actually any security built in this protocol, besides the obvious fact you have to be an authenticated and associated user to send messages? I specially think of this "I guess something is wrong with you please shut down your interfaces"-IAPP message when using hot standby APs.

    Thanks for your blog and sharing all this stuff with us!

    Stefan

    ReplyDelete
  2. Hi Jerome,

    In an effort to rid the world of Cisco APs set up as WGBs, I'm converting my customers over to Cisco Lightweight Mesh. I've found it to be 100x easier than dealing with WGBs. Only downside is that you can't run a backhaul over 2.4G (yet anyway...right now all backhaul is at 5G, which has it's limits).

    Regards,
    Steve

    ReplyDelete
  3. Hey Steve,
    Yep, I am not a big fan of WGB in the real world either! Luckily nowadays, it is getting more and more uncommon to find networking devices that can't get their own wireless NIC.
    I like the mesh solution, it is a better alternative to wireless bridges, its dynamic side makes it more interference resilient.
    Thanks fr sharing!

    ReplyDelete
  4. Hey Stefan!
    Yes! IAPP is actually 802.11F, Cisco follows the protocol. When 2 APs start exchanging messages, they proceed through a for of 802.1X exchange based on a combination of their built in MAC address and CCX elements to secure their communication. This implies a RADIUS server, just like with standard 802.1X, but ensures that no one will inject a shut command by spoofing an AP identity...
    Please notice that security is "optional", IAPP can be enabled without infrastructure SSID using 802.1x authentication... then it is really unsecure... but who would be crazy enough to use it in these conditions? ;-)

    ReplyDelete
  5. Kristjan EdvardssonOctober 24, 2010 at 3:29 PM

    Hello Jerome,
    Very good article about the WGB. Good to get clarifications on what infrastructure SSID means in plane english and the multicast issues that needs to be addressed.

    I am preparing for the CCIE wireless LAB. There
    is one thing about WGBs that confuses me:

    We have station-role of several bridging modes.
    For example if you look at the help output:
    1242nonroot(config-if)#station-role root ?
    access-point Access point
    ap-only Bridge root in access point only mode
    bridge Bridge root (without wireless client)
    fallback Root AP action if Ethernet port fails

    This above is easy to understand.

    But then you also have these options:
    1242nonroot(config-if)#station-role non-root ?
    bridge Bridge non-root
    wireless-clients Nonroot with Wireless clients

    And to me non-root bridge has the same charecteristics as a station-role Workgroup-bridge.

    Do you have any more clarification on that ?

    regards. Kristjan Edvardsson

    ReplyDelete
  6. Hello Jerome,

    I'm kinda confused.

    At the AP Config Guide page 19-15 you see that you configure Mobile station if the workgroup bridge is mobile.

    At the paragraph before it mentioned that when a WGB is a mobile you should treat is a a Client device. (So don't use Infrastructe-client)

    Can you say that a WGB is an Infrastructure devica AND also use the Mobile Scan option ?

    ReplyDelete
  7. Hi Sjostke,
    Yes, technically you can set a WGB in infrastructure client and mobile client at the same time (you can enter both commands, and they are taken).
    The logic of the page you refer to ("Treating Workgroup Bridges as Infrastructure Devices or as Client Devices" in http://www.cisco.com/en/US/docs/wireless/access_point/12.4_10b_JA/configuration/guide/scg12410b-chap19-wgb-standby.html#wp1040354 ) is that infrastructure SSIDs (and therefore infrastructure client configuration) are designed for situations where you need network stability. If you WGB is mobile, there is no stability anymore (what would be the point of sending a unicast multicast to your WGB (to make sure it is received, because you think that a normal multicast is not safe enough), if you WGB may not receive it because it is roaming, or scanning in preparation for roaming)?
    You see, it is more a design logic concern than a technical impossibility...
    hth
    Jerome

    ReplyDelete
  8. Hi Kristjan,
    WGB are built to connect a wired client (printer, etc) that does not have wireless NIC. Bridges are made to connect entire networks (a building LAN to another building LAN).
    From a wireless standpoint, the main difference is that a WGB is seen by the AP as a wireless client, just like a laptop (maybe a special client if it is in infrastructure mode, but still a client). The non-root bridge is seen as a special device connecting another network. This makes that the AP to WGB link is an AP to client normal link (and there can be many other standard laptop clients in the same AP cell), whereas the bridge to non-root bridge is basically a wireless trunk between 2 switches, carrying VLAN tags, and requiring bridge to non-bridge negotiation about which WLANs, which VLANs are carried over.
    As a side note, the non-root bridge can also act as an AP (whereas the WGB is not an AP, it is just a client), so the non-root bridge can do more than connect a LAN, it can also take on wireless clients directly, that can connect to the LAN (on the non-root bridge side, or across the wireless trunk to the root side).
    hth
    Jerome

    ReplyDelete
  9. Hi Jerome,
    Intersting point about the non-root bridge can also act as an AP. So if i have a triangle bridge formation (AP1310) with center one root and other two as non-root bridge, will clients also be able to connect to root and non-root bridges if second ssid's are configured on all ? Any pointers to this kind of configuration for p2MP bridging + client access in all will greatly help !

    regards
    Son

    ReplyDelete
  10. Jerome - We have a situation you make can shed some light on. We have a Cisco 5508 WSC controller with 3502i APs in a warehouse. Coverage if fine and our 802.11g guns work and roam just fine. However some older guns that only run 802.11b can connect but cannot roam, they will not release from one AP to go to another, eventually times out and is out of range. Any ideas? Our gun vendor and Cisco TAC has not come up with a resolution yet. Thanks!

    ReplyDelete
  11. @Anonymous

    http://www.cisco.com/web/techdoc/wireless/access_points/online_help/eag/123-08.JA/1100/h_ap_express-setup.html

    read the note from the "Optimize Radio Network for" Part. It might help.

    ReplyDelete
  12. Thanks jerome for your explanations, they are so much useful for me.

    I have a query about the use of the infrastructure-client command. I don´t know exactly where it must be applied, on the Root ap radio interface or on the WGB AP radio interface. I always though that it should be applied on the root AP radio interface but I would be gratefull if you could explain this point.

    Thanks.

    ReplyDelete
  13. @ Anonymous
    You are right, the infrastructure-client command is applied to the AP, NOT to the WGB. It tells the AP that there are infrastructure clients in the cell. From that moment on, the AP starts listening to the Cisco specific information elements that WGB add to their association frames, and the AP registers that this or that client is in fact a WGB. When the AP has to send a multicast frame, it first sends the multicast frame normally, then sends it a second time to each detected infrastructure client as a unicast frame. The unicast framer is acknowledge, which allows the AP to make sure that the frame was received properly...

    ReplyDelete
  14. Jerome. Thank you for the article. In the section regarding "station-role workgroup-bridge universal", two statements are truncated and end with the word 'the';

    "...and the only MAC address you'll see in the wireless space will be the ."

    and

    "...the WGB disassociates then re-associates using this time the ."

    Possibly the missing phrases are highlighted in some manner. Can you clarify the point you are trying to make on using 'universal' mode?

    I am attempting to use the 'a' radio for a Cisco 1242 as a workgroup bridge in a high congestion area ( many clients ) with high levels of co-channel interference on 2.4 GHz. This is an attempt to band-aid the situation until I can get funding to re-design the 2.4GHz network. Using the 'a' radio is working well once the workgroup bridge is associated.

    I have one client behind the workgroup bridge, using ALL Cisco 1242 APs, 12.4(10b)JA, on both the AP and bridge. The wired client is connected directly to the bridge Ethernet interface. The bridge is authenticating, associating, and receiving a DHCP address, but then disassociates and attempts to re-associate. The re-association can take 10 minutes or more, but is always successful. The infrastructure-client command is not being used on the radio interface.

    Thank you for your help.

    ReplyDelete
  15. Thanks zwave19, I added the missing bits (not sure why they disappeared). Are you using universal mode or Cisco mode for your WGB?

    ReplyDelete
  16. Very good article. One point i have been concerned about: if the universal WGB only registers one MAC address (that of the wired client), if the AP needs to re-authenticate (becuase of a sessions timeout for example), the EAPOL messages will be sent to the "wired" client mac address (as this is the only mac the wifi system knows). My question is then: does the WGB intercept these packets and does it do the authentication (impersonating the client, i guess yes), and are these packets still forwarded to the client afterwards (because they have his destination mac address) ?

    ReplyDelete
  17. Thank you for the article, it helped me to understand the bridge mode. Is it possible to have some information about passive client ?

    ReplyDelete
  18. Hey Filipe,
    Passive clients (like printers for example) were a problems. In the controller topology, a client associates at Layer 2 (802.11 association, followed or not by 802.1x authentication). Then, logically, clients request an IP address or, if they have a static IP address, start communicating with then network. In both cases, the WLC sees traffic coming from the client, and can read their Layer 3 information and document the client IP address. But passive clients do not communicate. They associate at Layer 2 (802.11, with or without 802.1X), then wait for traffic (a printer, for example, does not send traffic, only receives traffic). From the WLC standpoint, the client associated, and moved to "DHCP requested" state... but never went any further. After a while, the WLC was deciding that the client was gone (the user left the area), and was removing the client entry. When traffic was sent for that passive client, the WLC was dropping it, thinking that the client was not there anymore.
    In controller code 7.0 and later, you can check the Passive Client option (saying "there are passive clients in this network"). In that case, the controller does not remove the client, but sends an ARP request to learn the client IP address (the WLC got the client MAC address from the association phase), documents the client IP address, and answers the network ARP requests for that client (so the client does not have to do it). Then, the WLC checks are regular intervals (ARP requests) that the client is still there. This way, a completely passive client can still connect and stay connected to the wireless network... nice to have!

    ReplyDelete
  19. Hi Jerome,
    Thanks for your answer. Your explanations validate my tests, but there is still something I didn't understand. From the wlc standpoint, the IP address of the client is sometimes IP of the bridge and sometimes IP of the wired client (in both cases, the mac address is the same : mac of the bridge). I can see this information in GUI or CLI with this command : "show arp switch". Once the bridge set, i don't access to it.
    Why the IP address switch in the client database of WLC ? Strange, not ?

    Filipe

    ReplyDelete
  20. Hey Filipe,
    This is normal. When the client is connected to the WGB in universal mode, the WGB associates in the name of the client. So, the MAC address is the one of the WGC because this is the physical interface facing the AP, but the client is the wired client, so the WLC sees the IP address of the client (but also mentions that this comes through a WGB).
    When the wired client is not connected (or does not send any traffic, so the WGB does not see the client), the WGB associates using its own interfaces, so you see the WGB IP address on the WLC...
    :-)

    ReplyDelete
  21. http://www.writersdigest.com/editor-blogs/there-are-no-rules/top-10-blogging-tips-for-blogging-a-book

    ReplyDelete
  22. Hi Jerome,
    Thanks for your blog. I am so much interested about this wireless devices for CCIE.
    By the way, thanks for sharing. Keep it up.

    A webmaster of ccna security practice exam

    ReplyDelete