200912.html

Ethernet Bridging with Wireless Mesh Networks

A common issue that arises when customers convert from an Autonomous Access Point (aIOS AP) wireless solution to the Cisco Wireless LAN Controllers (WLCs) and Lightweight APs (LAPs) is that standard wireless bridging functionality is lost. Since the LAPs are controlled centrally at the WLC, you can no longer configure radio roles like root bridge and non-root bridge. Although you can configure an aIOS AP as a Workgroup Bridge (WGB) that associates as a client to the WLC based Wireless LAN (WLAN) to service wired clients behind it, you cannot pass multiple VLAN traffic through this link. The answer to this dilemma is using a wireless mesh deployment.

Although the wireless mesh feature allows you to provide a secure wireless solution for outdoor environments such as a college campus or an entire city, it also allows you to bridge remote wired networks together. Initially mesh was only supported on the 1500 and 1520 series LAPs. In later code releases, Cisco introduced Enterprise Mesh, which allows you to use 1130 and 1240 series APs to create an indoor mesh environment. An important caveat to remember is that the 1130 and 1240 series APs were only designed for indoor mesh deployments and you should not use those APs for outdoor mesh/bridging.

The mesh network consists of Root APs (RAPs) and Mesh APs (MAPs). The RAP is the wired connection to the WLC for the MAPs which use their 802.11a radios as a backhaul to communicate with the WLC through the RAP. You can use point-to-point mesh bridging, point-to-multipoint bridging, or a full mesh network with bridging enabled.

With either outdoor or indoor mesh deployments, you can configure Ethernet Bridging to bridge separate wired networks together. Ethernet Bridging allows you to connect remote wired networks to each other using the Ethernet port of the mesh LAPs. For bridging to work, every MAP and RAP in the path must have Ethernet Bridging enabled.

Prior to code Release 5.2, Ethernet Bridging only allowed the extension of the Layer 2 network in which the mesh LAPs resided. So if the LAPs had IP addresses in VLAN 5, for example, you could only extend VLAN 5 to the remote wired network. The 5.2 release and later allows you to bridge multiple VLANs. Like the earlier feature, every LAP in the mesh path back to, and including the RAP, must support bridging the same VLANs as the MAP with the wired connection. If you do not allow the correct VLANs on all the MAPs in the mesh, then in the event of a failure within the mesh network that results in a different path back to the RAP being created, it is possible to break the bridging feature if a MAP in the new path does not support a particular VLAN. In Figure 1, if MAP1 were to go down and MAP3 changed its parent to MAP2, VLAN2 would no longer be bridged correctly because MAP2 does not support bridging VLAN 2.

VLAN tagging Support Example within a Mesh Network


Figure 1 VLAN tagging Support Example within a Mesh Network


Configuring Ethernet Bridging


You enable Ethernet Bridging on your mesh LAPs using the Mesh tab on the LAP configuration page. After you have enabled Ethernet Bridging support on your MAPs, you need to configure the VLAN tagging settings. Figure 2 shows the Ethernet configuration of an indoor RAP, and Figure 3 shows the same configuration on the indoor MAP.

RAP VLAN Tagging Configuration


Figure 2 RAP VLAN Tagging Configuration


MAP VLAN Tagging Configuration


Figure 3 MAP VLAN Tagging Configuration


In this case, the RAP Ethernet port is configured as a trunk port with VLAN 20 set to Native and allowing VLAN 12. You can add more VLANs by entering the VLAN into the Trunk VLAN ID box and clicking Add. With the Ethernet port set to Trunk, the LAP accepts both tagged and untagged packets. Any tagged packets for a VLAN that is not in the allowed list are dropped. Because the MAP is only bridging VLAN 12 in this case, the Ethernet port mode is Access. The MAP tags the incoming untagged packet and forwards it to the RAP. Any tagged packets at the MAP are dropped.

Mesh LAPs use VLAN transparency to perform Ethernet Bridging when extending their Layer 2 network. To allow multiple VLAN bridging/tagging, you must disable VLAN transparency under the Wireless>Mesh>Ethernet Bridging section on the WLC GUI. When VLAN transparency is enabled, VLAN processing does not occur. This setting assumes that all traffic is destined to and from the same VLAN with no 802.1 tagging. After you have disabled VLAN transparency, reboot the MAPs for that setting to take effect.

It is important to understand the traffic flow when using Ethernet Bridging. Figure 4 shows the traffic flow for both wired and wireless clients within the mesh network with Ethernet Bridging enabled.

It is important to understand the traffic flow when using Ethernet Bridging. Figure 4 shows the traffic flow for both wired and wireless clients within the mesh network with Ethernet Bridging enabled.


Figure 4 Ethernet Bridging Traffic Flow


As you can see, with Ethernet Bridging enabled, the traffic flow for wireless clients is unchanged. The wireless client packets are sent using LWAPP/CAPWAP data, which is sent through the encrypted backhaul to the WLC. The WLC then bridges that traffic to the wired network. The bridged wired client traffic, however, is bridged directly into the backhaul toward the RAP. The RAP then bridges the traffic directly onto the wired network. The wired bridged traffic is not sent back to the WLC.

Several guidelines exist in addition to disabling VLAN transparency that allow the correct VLANs on the LAPs when you use the Ethernet Bridging and VLAN tagging feature:

  1. For security reasons, the Ethernet port on a mesh LAP (RAP and MAP) is disabled by default. It is enabled by configuring Ethernet Bridging on the LAP port.
  2. Ethernet Bridging must be enabled on all the LAPs in the mesh network to allow Ethernet VLAN tagging to operate.
  3. VLAN transparency is enabled by default. To set as non-VLAN transparent, you must uncheck the VLAN transparent option in the global mesh parameters window.
  4. VLAN configuration on a mesh LAP is applied only if all the uplink LAPs are able to support that VLAN.
  5. If uplink LAPs are not able to support the VLAN, the configuration is stored rather than applied.
  6. VLAN tagging can be configured only on Ethernet interfaces.
  7. On 152x mesh APs, three of the four ports can be used as secondary Ethernet interfaces: port 0-PoE in, port 1-PoE out, and port 3- fiber. Port 2 - cable cannot be configured as a secondary Ethernet interface.
  8. InEthernet VLAN tagging, port 0-PoE in on the RAP connects to the trunk port of the switch of the wired network. Port 1-PoE out on the MAP connects to external devices such as video cameras.
  9. Backhaul interfaces (802.11a radios) act as primary Ethernet interfaces. Backhauls function as trunks in the network and carry all VLAN traffic between the wireless and wired network. No configuration of primary Ethernet interfaces is required.
  10. The switch port in the wired network that is attached to the RAP (port 0-PoE in) must be configured to accept tagged packets on its trunk port. The RAP forwards all tagged packets received from the mesh network to the wired network.
  11. No configuration is required to support VLAN tagging on an 802.11a backhaul Ethernet interface within the mesh network. This includes the RAP uplink Ethernet port. The required configuration happens automatically using a registration mechanism.
  12. Any configuration changes to an 802.11a Ethernet link acting as a backhaul are ignored and a warning results. When the Ethernet link no longer functions as a backhaul, the modified configuration is applied.
  13. VLAN configuration is not allowed on a port-02-cable modem port of an 152x AP. VLANs can be configured on ports 0 (PoE-in), 1 (PoE-out), and 3 (fiber).
  14. If you are bridging between two mesh LAPs, enter the distance (mesh range) between the two APs that are bridging. (This is not applicable to applications in which you are forwarding traffic connected to the MAP or to the RAP access mode.)
  15. Up to 16 VLANs are supported on each sector. Therefore, the cumulative number of VLANs supported by RAPís children (MAPs) cannot exceed 16.
  16. Ethernet ports on APs function as either access or trunk ports within an Ethernet tagging deployment.
  17. In Access mode, only untagged packets are accepted. All packets are tagged with a user-configured VLAN called access VLAN. For this mode to take effect, the global VLAN mode should be non-VLAN transparent. This option is used for applications in which information is collected from devices connected to the MAP, such as cameras or PCs, and then forwarded to the RAP. The RAP then applies tags and forwards traffic to a switch on the wired network.
  18. Trunk mode requires the user to configure a native VLAN and an allowed VLAN list (no defaults). In this mode, both tagged and untagged packets are accepted. Untagged packets are always accepted and are tagged with the user-specified native VLAN. Tagged packets are accepted if they are tagged with a VLAN in the allowed VLAN list. For this mode to take effect, the global VLAN mode should be non-VLAN transparent. This option is used for bridging applications such as forwarding traffic between two MAPs residing in separate buildings within a campus.
  19. The switch port connected to the RAP must be a trunk.
  20. The trunk port on the switch and the RAP trunk port configuration must match.
  21. A configured VLAN on a MAP Ethernet port cannot function as a management VLAN.
  22. The RAP must always connect to the native VLAN (ID 1) on a switch.
  23. The RAPís primary Ethernet interface is by default the native VLAN of 1.

Ethernet Bridging Troubleshooting


Before the 5.2 code release, troubleshooting Ethernet Bridging with mesh LAPs was almost impossible. You had to rely on packet captures and Ethernet interface statistics. Cisco added several show and debug commands with the 5.2 release to help troubleshoot and view VLAN tagging information.

From the controller, you can verify your VLAN tagging configuration using the following commands:

show ap config ethernet AP_name
show mesh config

The show ap config ethernet command shows you the mode of the Ethernet port, the native VLAN, and any allowed VLANs, as demonstrated in Example 1.

Example 1: show ap config ethernet Command Output


(Cisco Controller) >show ap config ethernet 1131
Vlan Tagging Information For AP 1131
Ethernet 0
Mode: TRUNK
Native Vlan 12
Allowed Vlans:

The show mesh config command shows the status of VLAN transparency mode, as demonstrated in Example 2.

Example 2: show mesh config Command Output


(Cisco Controller) >show mesh config

Mesh Range.....................................12000
Backhaul with client access status.............disabled
Background Scanning State......................enabled
Mesh Security
Security Mode................................. EAP
External-Auth................................. disabled
Use MAC Filter in External AAA server......... disabled
Force External Authentication................. disabled
Mesh Alarm Criteria
Max Hop Count................................. 4
Recommended Max Children for MAP.............. 10
Recommended Max Children for RAP.............. 20
Low Link SNR.................................. 12
High Link SNR................................. 60
Max Association Number........................ 10
Association Interval.......................... 60 minutes
Parent Change Numbers......................... 3
Parent Change Interval........................ 60 minutes
Mesh Multicast Mode............................In-Out
Mesh Full Sector DFS...........................enabled
Mesh Ethernet Bridging VLAN Transparent Mode...disabled


One configuration that confuses most users is the Mesh Range setting. In the controller GUI, this setting is called the RAP to MAP distance. Most think that this is the distance from the RAP to the first MAP, but that is incorrect; this value merely adjusts a timer to tell the LAPs how long they should wait to receive an ACK from a child LAP. The higher the value (in feet), the longer the sending LAP waits for a response. The general rule of thumb is that the Mesh Distance should be set to the farthest distance between any two LAPs in the network.

You can use the remote LAP debugs from the WLC CLI or enable telnet on the LAPs and run the following mesh ap debug commands:

  1. debug mesh Ethernet Bridging: Debugs Ethernet Bridging
  2. debug mesh ethernet config: Debugs access and trunk port configuration
  3. debug mesh ethernet registration: Debugs VLAN registration protocol
  4. debug mesh forwarding table: Debugs forwarding table containing bridge groups
  5. debug mesh forwarding packet bridge-group: Debugs the bridge group packet forwarding

Here are the mesh ap show commands:

  1. show mesh forwarding table: Shows all the bridges with their mac-table entries.
  2. show mesh forwarding vlan mode: Displays VLAN-Transparent mode.
  3. show mesh forwarding vlan statistics: Displays VLAN forwarding statistics.
  4. show mesh forwarding vlans: Shows all the supported VLANs.
  5. show mesh forwarding interfaces: Displays the bridge groups and the interfaces contained in them. Useful for troubleshooting the bridge group membership.
  6. show mesh ethernet vlan statistics: Shows Ethernet subinterface statistics.

Example 3 demonstrates output from the show mesh forwarding table command.

Example 3: show mesh forwarding table Debug


(Cisco Controller) >debug ap command “show mesh forwarding table” 1242
(Cisco Controller) >*May 03 13:13:49.219: 1242:
*May 03 13:13:49.219: 1242: Mesh Forwarding Table Entries
(continues)
15_9781587058141_ch15.qxp 9/30/09 10:39 PM Page 253
254 Deploying and Troubleshooting Cisco Wireless LAN Controllers
*May 03 13:13:49.219: 1242:
*May 03 13:13:49.219: 1242: Bridge Group 1 Vlan 1 :
*May 03 13:13:49.219: 1242: 0023.5df1.9d40, nh 001c.b107.fa2f, swif Virtual-
Dot11Radio1:BACKHAUL: 43 : 8
*May 03 13:13:49.219: 1242: 0023.5df1.9d06, nh 001c.b107.fa2f, swif Virtual-
Dot11Radio1:BACKHAUL: 43 : 8
*May 03 13:13:49.219: 1242: 001c.b107.fa2f, nh 001c.b107.fa2f, swif Virtual-
Dot11Radio1:AWPP: 23 : 8
*May 03 13:13:49.219: 1242: 001c.58dc.97b0, nh 001c.b107.fa2f, swif Virtual-
Dot11Radio1:BACKHAUL: 43 : 7
*May 03 13:13:49.219: 1242: 0010.a4e5.2056, nh 001c.b107.fa2f, swif Virtual-
Dot11Radio1:BACKHAUL: 43 : 8
*May 03 13:13:49.219: 1242: 0001.0386.1991, nh 001c.b107.fa2f, swif Virtual-
Dot11Radio1:BACKHAUL: 43 : 8
*May 03 13:13:49.219: 1242:
*May 03 13:13:49.219: 1242: Bridge Group 2 Vlan 12 :
*May 03 13:13:49.219: 1242:
*May 03 13:13:49.219: 1242: Table size: 128, count 3
*May 03 13:13:49.219: 1242: 0023.5df1.9d06 Virtual-Dot11Radio1 LEARNED (life 300)
*May 03 13:13:49.219: 1242: 000f.b049.5898 FastEthernet0 LEARNED (life 300)
*May 03 13:13:49.219: 1242: 0023.5df1.9d43 Virtual-Dot11Radio1 LEARNED (life 300)


From this output you can see that this AP has two bridge groups: one for VLAN 1 and the other for VLAN 12. There is a wired client in VLAN 12 with the MAC address of 000f.b049.5898.

The output from show mesh forwarding vlan mode tells you whether VLAN transparency is enabled or disabled on the AP, as demonstrated in Example 4.

Example 4: show mesh forwarding vlan mode Debug


(Cisco Controller) >debug ap command “show mesh forwarding vlan mode” 1242
(Cisco Controller) >*May 03 13:15:53.025: 1242:
*May 03 13:15:53.025: 1242: Vlan Transparent mode DISABLED
To see the VLANs that the AP is bridging, use show mesh forwarding vlan:
(Cisco Controller) >*May 03 13:15:17.697: 1242:
*May 03 13:15:17.697: 1242: Mesh Forwarding Vlans
*May 03 13:15:17.697: 1242: Vlan: 1 Supporting Bridge Group: 1
*May 03 13:15:17.697: 1242: Vlan: 12 Supporting Bridge Group: 2

To see transmit and receive stats for the bridged VLANs, use show mesh ethernet vlan statistics, as demonstrated in Example 5.

Example 5: show mesh forwarding table Debug (continued)


(Cisco Controller) >debug ap command “show mesh ethernet vlan statistics” 1242
Interface Rx Packets Tx Packets Tbridge Reject
FastEthernet0 119 41 0

This output is helpful in determining whether traffic passing over the bridge links.

To troubleshoot bridge group membership, use show mesh forwarding interfaces, as demonstrated in Example 6.

Example 6: show mesh forwarding interfaces Debug


(Cisco Controller) >debug ap command “show mesh forwarding interfaces” 1242
(Cisco Controller) >*May 03 13:19:26.714: 1242: Bridge Group 1: Ethernet
Bridging enabled
*May 03 13:19:26.714: 1242: Virtual-Dot11Radio1: Virtual-Dot11Radio1(state is
OPEN)
*May 03 13:19:26.714: 1242: Node 001c.b107.fa2f
*May 03 13:19:26.714: 1242: Bridge Group 2: Ethernet Bridging enabled
*May 03 13:19:26.714: 1242: FastEthernet0: FastEthernet0(state is OPEN)
*May 03 13:19:26.714: 1242: Node 0083.e574.0b0d
*May 03 13:19:26.714: 1242: Virtual-Dot11Radio1: Virtual-Dot11Radio1(state is
OPEN)
*May 03 13:19:26.714: 1242: Node 001c.b107.fa2f


Here you can see that Ethernet Bridging is enabled for bridge group 1 and 2. The FastEthernet port 0 is in bridge group 2. With the preceding output of show mesh forwarding vlan, you know that bridge group 2 is forwarding VLAN 12.

The switch trunk port should not allow any VLAN other than the VLANs used in the mesh sector connected through it. Because of a bug, CSCsr87215, the packets from other non-configured VLANs are accepted in the native-VLAN through the RAP backhaul Ethernet interface. You can easily avoid this by carefully configuring the switch port.

As is the case with any network bridging deployment, you need take care that you do not create any routing or bridging loops within your network.

Summary

This article offered some insight into the Ethernet Bridging feature with mesh wireless networks, how to configure it, and how to troubleshoot it. Ethernet Bridging has evolved dramatically with the 5.2 release of code and is no longer limited to simply extending the Layer 2 network in which the mesh LAPs reside.

About the Author:

Lee Johnson is currently a wireless specialist on the RTP Wireless Technical Assistance Center (TAC) team at Cisco. He has been troubleshooting wireless networks, including both autonomous and controllerbased infrastructures, since 2006. Lee troubleshoots complex wireless issues in Cisco customer networks around the world.

He has been dispatched to customer sites to address critical accounts and represented Cisco at Networkers. He also provides training and documentation for fellow Cisco engineers in both wireless and nonwireless TAC groups. Lee works closely with the wireless development group at Cisco to improve product quality and the customer experience with the WLC.

He holds a bachelor of science degree in biology from the University of North Carolina at Chapel Hill.

Lee Johnson

Deploying and Troubleshooting Cisco Wireless LAN Controllers
By Mark L. Gress, Lee Johnson
ISBN-10: 1-58705-814-6
Published: Nov 9, 2009
US SRP $58.50
Publisher: Cisco Press