LWAPP and MSS (Maximum Segment size)

[msartorel]

I fell in the problem described in http://www.cisco.com/en/US/partner/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml

A server sent a MTU greater than 1500 and the frame wasn't able to pass thru a GRE tunnel.

I am asking if the same problem could happen passing thru an LWAPP tunnel. And if the answer is yes, is it possible to bypass the problem coding the "TCP ADJST-MSS XXXX" on the WLC interface controller?

Moreno Sartorel

[wififofum]

Well it works when there's only one link active so I don't suspect the endpoints at this juncture. The links between all the routers are CEF-enabled/per destination IP load balancing.

The local web app is on a connected vlan interface to the WiSM 6509, Internet and Exchange are accessed via edge router.

2 Pt-Pt OSPF paths (1 via bugged-6548 100M port directly to edge, 1 via sup-sup Gig port to pair distribution router and out good 6548 100M to edge). ATM WAN egress to data center and Internet. MTU is 1530 all the way.

We eliminated the bad blade (direct path) this morning and so forced traffic through the other distribution switch which worked without issue. All of this is completely isolated to the wireless side - no STP/OSPF instability.

We're replacing all the identified mods so once good mods are used through both paths this should settle things once and for all.

I am interested in how traffic from the WiSM is handled differently by the Sup post-LWAPP. I will also try taking out all but one Gig Inetrface from the channel-group for the controller and see if the issue persists.

Regards,

[wififofum]

FYI - A documentation bug that may apply here:

CSCse34118 Bug Details

LAG documentation incomplete

The 4400 series Wireless LAN Controllers (including the 4402, the 4404, the controllers on the WiSM, and the embedded controller in the 3750G) are not able to reassemble packets from fragments that arrive on different ports.

Where we see this problem is when the LAG is connected to a channel group that uses a load balancing method that fails to ensure

that all fragments of a given IP datagram are transmitted on the same port. If an IP datagram's fragments arrive on different

ports, then that datagram will be discarded. As a result, an AP may be seen to be unable to join the controller - for example,

the controller may fail to process the incoming LWAPP JOIN request. Or, an AP may join, but some large data packets that are in transit to a wireless client may fail to be forwarded from the switch to the AP.

Given the following options (from Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches):

port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port}

src-dst-ip is the load balancing method recommended for use with a WLC LAG, and is the default on the 6500.

The following methods are expected to work, but have not been extensively tested, and would not balance the traffic as well:

dst-mac | src-dst-mac | src-ip | dst-ip

src-port, dst-port and src-dst-port are known not to work with WLCs.

Workaround: if the switch cannot be configured to use a supported load balancing method, then either configure the WLC not to use LAG, or use LAG with a single member link.

[wififofum]

Follow-up: while the default is XOR src-dst-ip I removed all but one of the links from the channel-group bundle to no avail. The issue appears related to the 6548 bug not handling a frame with less than 32 bytes of IP Data. Granted that systems are supposed to pad the data frame to equal 32 Bytes, but who's counting - apparently not the controller ;).

[miloskv]

Hello rseiler,

May I ask you to give me some example of how can I configure WLC controller to do TCP-MSS adjustments?

I have problem of transmitting LWAPP data between two sites separated by MPLS cloud and protected with firewalls on the site edge. A lot of IP fragments are lost due to extensive CPU usage on firewalls

Thanks for any tip

Milos