Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

LWAPP over "IPSEC over TCP"

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.

3 REPLIES
Bronze

Re: LWAPP over "IPSEC over TCP"

I think the document

"http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00807e0b6a.shtml"

should give you some idea on configuring IPSEC VPN in a Controller environment. Try this configuration and let me know it it doesn't help.

New Member

Re: LWAPP over "IPSEC over TCP"

Hi,

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

header.

New Member

Re: LWAPP over "IPSEC over TCP"

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

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

Not a routing problem.

1238
Views
0
Helpful
3
Replies