Cisco Wireless – Understand CAPWAP/LWAPP

What is CAPWAP:

As Wikipedia defines: The Control And Provisioning of Wireless Access Points (CAPWAP) protocol is a standard, interoperable networking protocol that enables a central wireless LAN Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs), more commonly known as Wireless Access Points.

The protocol specification is described in RFC 5415.

CAPWAP is based on LWAPP (Lightweight Access Point Protocol). The state machine of CAPWAP is similar to LWAPP’s, but with the addition of a full Datagram Transport Layer Security (DTLS) tunnel establishment.

Evolution of CAPWAP:
===================

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Basic differences between LWAPP and CAPWAP:

LWAPP:
=========


Fragmentation/Re-assembly:                                        Relies on IpV4
Path-MTU Discovery:                                                    Not supported
Control Channel Encryption between AP and WLC:     Yes (using AES)
Data Channel Encryption between AP and WLC:         No
UDP Ports:                                                                    12222, 12223

CAPWAP:
==========



Fragmentation/Re-assembly:                                         CAPWAP itself does both
Path-MTU Discovery:                                                     Has a robust P-MTU discovery mechanism,
can also detect dynamic MTU changes.
Control Channel Encryption between AP and WLC:      Yes (Using DTLS)
Data Channel Encryption between AP and WLC:          Yes (using DTLS)
UDP Ports:                                                                     5246 (ctrl) 5247 (data)

 

More on LWAPP:
===============

LWAPP is a generic protocol with a binding definition for the 802.11 wireless LAN protocol. LWAPPdefines how access points communicate with wireless LAN controllers. This communication can be either by means of native, Layer 2 Ethernet frames, or Layer 3 via IP packets. In the Cisco LWAPP implementation, Layer 3 LWAPP packets are carried in UDP packets.

LWAPP messages carry one of two types of payload:

•LWAPP Data Messages, which are encapsulated and forwarded data frames sent from and to wireless clients.

•LWAPP Control Messages, which are management messages exchanged between the wireless LAN controller and the access point.

The LWAPP protocol header contains a control bit (the C-Bit) which identifies data and control packets. When Layer 3 LWAPP is used, the LWAPP data and control packets are sent to separate UDP ports. Because both data and control frames can be fragmented, the payload LWAPP data or control message can be fragmented.

LWAPP Layer 2 Transport Mode:
========================

LWAPP communication between the access point and the wireless LAN controller can be in native, Layer 2 Ethernet frames. This is known as Layer 2 LWAPP mode.

 

 

 

 

 

 

 

The LWAPP Control and Data messages are encapsulated in Ethernet frames using Ethertype “0xBBBB”. In Layer 2 LWAPP mode, although the access points may get an IP address via DHCP, all LWAPP communications between the access point and WLC are in Ethernet encapsulated frames, not IP packets. The access points must be on the same Ethernet network as the WLC. For this reason, Layer 2 LWAPP mode may not be suitable for scalability purposes in most deployments. Furthermore, Layer 2 mode is supported only by the Cisco 410x and 440x series of WLCs and the Cisco 1000 series access points. Layer 2 LWAPP is not supported by lightweight Cisco Aironet 1200, 1252, 1130AG, or 1240AG access points, or the Cisco 2006, WiSM, or WLCM series WLCs.

Data packets between wireless LAN clients and other hosts are typically IP packets.

When Host A sends a packet to Host B, the following sequence occurs:

•An IP packet is transmitted by Host A over the 802.11 RF interface after being encapsulated in an 802.11 frame with Host A’s MAC address as the source address and the access point’s radio interface MAC address as the destination address.

•At the access point, the access point adds an LWAPP Header to the frame with the C-Bit set to zero and then encapsulates the LWAPP Header and 802.11 frame into an Ethernet frame. This Ethernet frame uses the access point Ethernet MAC address as the source MAC address and the WLC MAC address as the destination MAC address.

•At the WLC, the Ethernet and LWAPP headers are removed and the original 802.11 frame is processed.

•After processing the 802.11 MAC Header, the WLC extracts the payload (the IP packet), encapsulates it into an Ethernet frame, and then forwards the frame onto the appropriate wired network, typically adding an 802.1Q VLAN tag.

•The packet then travels through the wired switching and routing infrastructure to Host B.

LWAPP Layer 3 Transport Mode:
===========================

Layer 3 LWAPP Control and Data messages are transported over the IP network in UDP packets. This transport architecture is inherently more flexible and scalable than Layer 2 LWAPP and is the generally preferred solution. Layer 3 LWAPP is supported on all Cisco WLC platforms and lightweight access points.

 

The LWAPP Control and Data messages are encapsulated in UDP packets that are carried over the IP network. The only requirement is established IP connectivity between the access points and the WLC. The LWAPP tunnel uses the access point’s IP address and the WLC’s AP Manager interface IP address as endpoints. On the access point side, both LWAPP Control and Data messages use an ephemeral port that is derived from a hash of the access point MAC address as the UDP port. On the WLC side, LWAPP Data messages always use UDP port 12222. On the WLC side, LWAPP Control messages always use UDP port 12223.

The mechanics and sequencing of Layer 3 LWAPP are similar to Layer 2 LWAPP except that the packets are carried in UDP packets instead of being encapsulated in Ethernet framesThe mechanics and sequencing of Layer 3 LWAPP are similar to Layer 2 LWAPP except that the packets are carried in UDP packets instead of being encapsulated in Ethernet frames.

When Host A sends a data packet to Host B, the following sequence occurs:

•The packet is transmitted by Host A over the 802.11 RF interface. This packet is encapsulated in an 802.11 frame with Host A’s MAC address as the source address and the access point’s radio interface MAC address as the destination address.

•At the access point, the access point adds an LWAPP Header to the frame with the C-Bit set to zero and then encapsulates the LWAPP Header and 802.11 frame into a UDP packet that is transmitted over IP. The source IP address is the access point’s IP address and the destination IP address is the WLC’s AP Manager Address. The source UDP port is the ephemeral port based on a hash of the access point MAC address. The destination UDP port is 12222.

•The IP packet is encapsulated in Ethernet as it leaves the access point and transported by the switching and routed network to the WLC.

•At the WLC, the Ethernet, IP, UDP, and LWAPP headers are removed from the original 802.11 frame.

•After processing the 802.11 MAC header, the WLC extracts the payload (the IP packet from Host A), encapsulates it into an Ethernet frame, and then forwards the frame onto the appropriate wired network, typically adding an 802.1Q VLAN tag.

•The packet is then transmitted by the wired switching and routing infrastructure to Host B.

Layer 2 LWAPP WLC Discovery Algorithm:
=====================================

LWAPP communication between the AP and the WLC can be in native, Layer 2 Ethernet frames. This is known as Layer 2 LWAPP mode. Although defined in the RFC draft, Layer 2 LWAPP mode is considered deprecated in Cisco’s implementation.

This is the first method that a LAP uses to discover a WLC. The LAPs that support Layer 2 LWAPP mode broadcast a LWAPP discovery request message in a Layer 2 LWAPP frame. If there is a WLC in the network configured for Layer 2 LWAPP mode, the controller responds with a discovery response. The LAP then moves to the join phase.

This debug lwapp events enable command output shows the sequence of events that occur when a LAP using Layer 2 LWAPP mode registers with the WLC:

Thu Sep 27 00:24:25 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST
from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port ‘2’
Thu Sep 27 00:24:25 2007: 00:0b:85:51:5a:e0 Successful transmission of
LWAPP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 2
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Received LWAPP JOIN REQUEST
from AP 00:0b:85:51:5a:e0 to 00:0b:85:48:53:c0 on port ‘2’
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0:
txNonce  00:0B:85:48:53:C0 rxNonce  00:0B:85:51:5A:E0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 LWAPP Join-Request MTU path from
AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Successfully added NPU Entry for
AP 00:0b:85:51:5a:e0 (index 48)Switch IP: 0.0.0.0, Switch Port: 0, intIfNum 2,
vlanId 0AP IP: 0.0.0.0, AP Port: 0, next hop MAC: 00:0b:85:51:5a:e0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Successfully transmission of
LWAPP Join-Reply to AP 00:0b:85:51:5a:e0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Register LWAPP event for
AP 00:0b:85:51:5a:e0 slot 0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Register LWAPP event for
AP 00:0b:85:51:5a:e0 slot 1

Layer 3 LWAPP WLC Discovery Algorithm:
====================================

The LAPs use the Layer 3 discovery algorithm if the Layer 2 discovery method is not supported or if the Layer 2 discovery method fails. The Layer 3 discovery algorithm uses different options in order to attempt to discover WLCs. The Layer 3 LWAPP WLC discovery algorithm is used to build a controller list. After a controller list is built, the AP selects a WLC and attempts to join the WLC. The LWAPP Layer 3 WLC discovery algorithm repeats until at least one WLC is found and joined.

Boadcast Method:
================

After the LAP gets an IP address from the DHCP server, the LAP begins this discovery process:

The LAP broadcasts a Layer 3 LWAPP discovery message on the local IP subnet. Any WLC that is configured for Layer 3 LWAPP mode and that is connected to the same local subnet receives the Layer 3 LWAPP discovery message.
Each of the WLCs that receives the LWAPP discovery message replies with a unicast LWAPP discovery response message to the LAP.

Here the debug lwapp events enable command shows this discovery process:

(Cisco Controller) >debug lwapp events enable
Mon May 22 12:00:21 2006: Received LWAPP DISCOVERY REQUEST from AP
00:0b:85:5b:fb:d0 to ff:ff:ff:ff:ff:ff on port ‘1’
Mon May 22 12:00:21 2006: Successful transmission of LWAPP Discovery-Response
to AP 00:0b:85:5b:fb:d0 on Port 1

The debug lwapp packet enable command output for the local subnet broadcast discovery looks like this example:

(Cisco Controller) >debug lwapp packet enable
Tue May 23 12:37:50 2006: Start of Packet
Tue May 23 12:37:50 2006: Ethernet Source MAC (LRAD):      00:0B:85:51:5A:E0
Tue May 23 12:37:50 2006: Msg Type       :
Tue May 23 12:37:50 2006:    DISCOVERY_REQUEST
Tue May 23 12:37:50 2006: Msg Length     :   31
Tue May 23 12:37:50 2006: Msg SeqNum     :   0
Tue May 23 12:37:50 2006:
IE            :   UNKNOWN IE 58
Tue May 23 12:37:50 2006: IE Length : 1
Tue May 23 12:37:50 2006: Decode routine not available, Printing Hex Dump
Tue May 23 12:37:50 2006: 00000000: 00

The value of the IE 58 parameter indicates the discovery type, which could be the following:

0 – broadcast
1 – configured
2 – OTAP
3 – dhcp server
4 – dns

OTA Method:
===========

LAPs also use the Over-the-Air Provisioning (OTAP) feature in order to discover the WLC. The OTAP feature is disabled by default in 4.2.39.13, 5.0.68.0 and later WLC versions. OTAP is enabled by default in the WLC versions earlier than 4.2.39.13.. This is the discovery process when OTAP is enabled:

The LAPs that are already registered to the WLC can advertise the WLC IP address to the LAPs (in an attempt to find the WLC) with the use of neighbor messages that are sent over the air.

New LAPs that attempt to discover WLCs hear these messages and then unicast LWAPP discovery request messages to the WLCs.

WLCs that receive the LWAPP discovery message reply with a unicast LWAPP discovery response message to the LAP

You should have OTAP enabled only during AP provisioning intervals. After APs are deployed, disable OTAP as a deployment best practice. Also, Cisco Aironet LAPs (1130 AG, 1200, and 1240 AG series) ship from the factory with a stripped-down version of lightweight Cisco IOS® Software that is called the LWAPP Recovery Cisco IOS image. OTAP is not supported on those APs out-of-the-box that run LWAPP Cisco IOS Software. When you upgrade Cisco Aironet APs from autonomous Cisco IOS Software to lightweight mode, the LWAPP Recovery Cisco IOS image is the software that is loaded. The LWAPP Recovery Cisco IOS image does not support OTAP. In order to support OTAP, Aironet LAPs must first join a WLC in order to download a full LWAPP Cisco IOS image.

The debug lwapp event enable command output illustrates the sequence of messages that the WLCs send:

Tue May 23 14:37:10 2006: Received LWAPP DISCOVERY REQUEST from AP
00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port ‘1’
Tue May 23 14:37:10 2006: Successful transmission of LWAPP Discovery-Response to
AP 00:0b:85:5b:fb:d0 on Port 1

Because the LAP knows the WLC IP address through neighbor messages, the LAP sends a unicast discovery request to the WLC.

The value of the IE 58 parameter in the debug lwapp packet enable command output shows you that the LAP used OTAP as the discovery method.

Tue May 23 14:21:55 2006: Start of Packet
Tue May 23 14:21:55 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 14:21:55 2006: Msg Type       :
Tue May 23 14:21:55 2006:    DISCOVERY_REQUEST
Tue May 23 14:21:55 2006: Msg Length     :   31
Tue May 23 14:21:55 2006: Msg SeqNum     :   0
Tue May 23 14:21:55 2006:
IE            :   UNKNOWN IE 58
Tue May 23 14:21:55 2006: IE Length     :   1
Tue May 23 14:21:55 2006: Decode routine not available, Printing Hex Dump
Tue May 23 14:21:55 2006: 00000000: 02                                                .

Locally Saved WLC IP:
===================


If the LAP was registered to a WLC in a previous deployment, the LAP maintains the list of WLC IP addresses locally in NVRAM. The stored WLC IP addresses include all of the WLCs that are in previously joined WLC “mobility groups”. This is the discovery process:

LAPs send a unicast Layer 3 LWAPP discovery request to each of the WLC IP addresses that the LAP has in its NVRAM.

WLCs that receive the LWAPP discovery message reply with a unicast LWAPP discovery response message to the LAP.

The debug lwapp events enable command and the debug lwapp packet enable command for this method of WLC discovery:

Note: If you use the clear ap-config ap_name command in order to reset the LAP to the factory defaults, all the LAP configurations are reset. The configurations that are reset include the WLC IP addresses that are stored in NVRAM. In this case, the LAP must use some other method in order to discover the WLC.

(Cisco Controller) >debug lwapp events enable
Tue May 23 14:37:10 2006: Received LWAPP DISCOVERY REQUEST from AP
00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port ‘1’
Tue May 23 14:37:10 2006: Successful transmission of LWAPP Discovery-Response to
AP 00:0b:85:5b:fb:d0 on Port 1
(Cisco Controller) >debug lwapp packet enable
Tue May 23 14:45:36 2006: Start of Packet
Tue May 23 14:45:36 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 14:45:36 2006: Msg Type       :
Tue May 23 14:45:36 2006:    DISCOVERY_REQUEST
Tue May 23 14:45:36 2006: Msg Length     :   31
Tue May 23 14:45:36 2006: Msg SeqNum     :   0
Tue May 23 14:45:36 2006:
IE            :   UNKNOWN IE 58
Tue May 23 14:45:36 2006: IE Length     :   1
Tue May 23 14:45:36 2006: Decode routine not available, Printing Hex Dump
Tue May 23 14:45:36 2006: 00000000: 01

DHCP OPTION 43 Method:
======================

When the LAP powers up, it looks for a DHCP server in order to get an IP address. The DHCP server allots an IP address to the LAP and also provides the list of WLC IP addresses with the use of DHCP option 43. The LAP sends out a unicast discovery request to each of the WLCs. The WLCs that hear these messages reply with a discovery response, which initiates the registration process.

The debug lwapp events enable command output shows the sequence of LWAPP messages:

Tue May 23 14:43:42 2006: Received LWAPP DISCOVERY REQUEST from AP
00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port ‘1’
Tue May 23 14:43:42 2006: Successful transmission of LWAPP Discovery-Response to
AP 00:0b:85:5b:fb:d0 on Port 1

The debug lwapp packet enable command output that indicates that DHCP option 43 was used as the discovery method in order to discover WLC IP addresses:

Tue May 23 16:14:32 2006: Start of Packet
Tue May 23 16:14:32 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 16:14:32 2006: Msg Type       :
Tue May 23 16:14:32 2006:    DISCOVERY_REQUEST
Tue May 23 16:14:32 2006: Msg Length     :   31
Tue May 23 16:14:32 2006: Msg SeqNum     :   0
Tue May 23 16:14:32 2006:
IE            :   UNKNOWN IE 58
Tue May 23 16:14:32 2006: IE Length     :   1
Tue May 23 16:14:32 2006: Decode routine not available, Printing Hex Dump
Tue May 23 16:14:32 2006: 00000000: 03                                            .

DNS Discovery Method:
===================

You can also use the DNS server in order to return WLC IP addresses to the LAP. This is the discovery process:

The LAP attempts to resolve the DNS name “CISCO-LWAPP-CONTROLLER.localdomain.”

The AP is informed of this domain name through DHCP option 15. DHCP option 15 specifies the domain name that the AP should use for DNS resolution. Therefore, it is necessary that DHCP option 15 be configured with the domain name information. This allows the DHCP server that sends the IP address of the DNS server to also send this DHCP option 15 information (the domain name to be resolved) to the AP.

When the LAP is able to resolve this name to one or more WLC IP addresses, the LAP sends a unicast Layer 3 LWAPP discovery request to each of the WLCs.

The WLCs that receive the LWAPP discovery message reply with a unicast LWAPP discovery response message to the AP.

After the LAP gets the DNS server IP address, the LAP sends out a DNS query for the DNS name CISCO-LWAPP-CONTROLLER.localdomain. The DNS server should be configured such that it returns the WLC IP address for this query. When the LAP gets the WLC IP address, the LAP starts the registration process with the WLC.

The debug lwapp packet enable command output shows the discovery type as DNS:

 Tue May 23 16:14:32 2006: Start of Packet
Tue May 23 16:14:32 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 16:14:32 2006: Msg Type       :
Tue May 23 16:14:32 2006:    DISCOVERY_REQUEST
Tue May 23 16:14:32 2006: Msg Length     :   31
Tue May 23 16:14:32 2006: Msg SeqNum     :   0
Tue May 23 16:14:32 2006:
IE            :   UNKNOWN IE 58
Tue May 23 16:14:32 2006: IE Length     :   1
Tue May 23 16:14:32 2006: Decode routine not available, Printing Hex Dump
Tue May 23 16:14:32 2006: 00000000: 04                                                .
Note:  If, after the completion of steps 1 through 5, the LAP does not receive an LWAPP discovery response, the LAP resets and restarts the hunting algorithm.

 

 Using IP-HELPER on the L3 Interface:
================================

After the LAP gets an IP address from the DHCP server, the LAP broadcasts a Layer 3 LWAPP discovery message on to its local subnet. The IP address of the WLC is configured as the ip-helper address on the router. The router forwards these broadcasts to the IP addresses configured with the ip-helper command on the interface on which the broadcast is heard. When you use the ip helper-address command, DIRECTED BROADCASTS, as well as unicasts, eight different UDP ports are forwarded automatically.

Please find the previous post:

 

Following example shows the configuration on the router:

 

Router(config)#interface Fastethernet 0/1
Router(config-if)#ip helper-address 172.16.0.1
Router(config-if)#exit
Router(config)ip forward-protocol udp 12223

Note: If you run WLC version 5.2 or later, use the UDP port number 5246 because the CAPWAP broadcast uses UDP port 5246.

Router(config)ip forward-protocol udp 5246

Hope this post was helpful….

One thought on “Cisco Wireless – Understand CAPWAP/LWAPP

  1. Hi Bharath,

    We are looking for someone to help us with some Cisco CAPWAP packet analysis. Specifically we are writing packet capture software to extract the encapsulated IP/TCP/HTTP user data.

    Is this something you would be able to assist us with?

    Thanks,

    Michael Stone

Leave a Reply

Your email address will not be published. Required fields are marked *