LWAPP over "IPSEC over TCP"

Unanswered Question
Dec 5th, 2007
User Badges:

Hi All,

I would like to know if "IPSEC over TCP" is an issue for LWAPP communication?

I am currently running Easy Vpn server & Remote using IPSEC over TCP. Trying to place a LAP on the remote site, registering back to my WLC

As i read on the cisco doc saying that LWAPP utilizes udp 12222 and 12223.

Am i working on a dead end solution? Plz advice.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
lbsoulliere Sat, 03/01/2008 - 12:46
User Badges:


I'm currently facing a problem with IPSEC VPN and LWAPP registration.

We are using a Fortinet VPN.

We try with a openvpn VPN and everything works fine.

I read a lot on MTU path discovery : http://tools.ietf.org/html/draft-ohara-capwap-lwapp-04

I tried to change the MTU on the vpn device but i does not work.

I get a MTU Path 1500 in my WLC debug message.

But the communication from the antenna to the WLC is fragmented to 1480 bytes (originaly 1506).

here are quotes from the internet :

"Note: The 1030 REAP LWAPP implementation assumes a 1500 byte MTU path between the AP and the WLC. Any fragmentation that takes place in transit due to a sub-1500 byte MTU leads to unpredictable results. Therefore, the 1030 LAP is not suited for environments, such as PPPoE, where routers proactively fragment packets to sub-1500 bytes."

"However, the minimum bandwidth restriction remains 128 kbps with the roundtrip latency no greater than 100 ms and the maximum transmission unit (MTU) no smaller than 500 bytes. "


The Join Request is used by an WTP to inform an AC that it wishes to

provide services through it.

Join Requests are sent by an WTP in the Joining state after receiving

one or more Discovery Responses. The Join Request is also used as an

MTU discovery mechanism by the WTP. The WTP issues a Join Request

with a Test message element, bringing the total size of the message

to exceed MTU.

If the transport used does not provide MTU path discovery, the

initial Join Request is padded with the Test message element to 1596

bytes. If a Join Response is received, the WTP can forward frames

without requiring any fragmentation. If no Join Response is

received, it issues a second Join Request padded with the Test

payload to a total of 1500 bytes. The WTP continues to cycle from

large (1596) to small (1500) packets until a Join Response has been

received , or until both packets sizes have been retransmitted 3

times . If the Join Response is not received after the maximum

number of retransmissions, the WTP MUST abandon the AC and restart

the discovery phase."

Fragmentation at the MAC layer is managed using the F,L and Frag ID

fields of the LWAPP message header. The LWAPP protocol only allows a

single packet to be fragmented into 2, which is sufficient for a

frame that exceeds MTU due to LWAPP encapsulation. When used with

layer 2 (Ethernet) transport, both fragments MUST include the LWAPP


lbsoulliere Sat, 03/01/2008 - 12:47
User Badges:

I'm not even sure that this is a fragmentation problem..

The fragged packet disappear somewhere in the VPN device ....

Not a routing problem.


This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode