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]

Moreno,

Any chance you could cut and paste the content of this url in a reply? Its a Partner link and apparently not accessible from the public links.

Thanks in advance,

Bruce Johnson

[msartorel]

I'm attaching the content of the url as requested by Bruce

[wififofum]

Thank You!

[rseiler]

The WLC controller already deals with the MSS/MTU issue, either by adjusting the tcp mss or fragmenting buffered packets into multiple lwapp frames.

If you are having an issue that you suspect is related to lwapp overhead, open a TAC case.

Otherwise, if you are having a VPN or IPSEC issue OVER lwapp, then you are having a VPN or IPSEC issue with mtu size, not an lwapp issue.

[wififofum]

Thanks,

I assume it does any MTU magic behind the scenes. Have you seen this bug below? Is it possible the controller might receive a less than 32Byte fragment on one of the port-channels?

The following defect(s) in your Bug Watcher profile were either added to the

profile or changed state or had a release notes modification:

-----------------------------------------------------------------------------

BugID: CSCsh96186

Title: 4400 FPGA cannot handle an IP fragment < 32 bytes

Feature: hw

Version: 4.0(206)

Integrated:

Severity: 3

State: N

Release Notes:

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsh96186-----------------------------------------------------------------------------

[rseiler]

What exactly is the issue you are dealing with? Is your network fragmenting packets toward the LAN side of the controller?

What is not working?

What is the EXACT version of the firmware you are running on the controller?

What model controller are you using?

How is the controller connected to the network? Multiple AP manager interfaces or an EtherChannel (LAG)?

[wififofum]

Hey,

We're getting severely degraded performance through an LWAPP AP, but no issue through an IOS AP using the same VLAN used by the controller for the LWAPP AP (trunked to an Access switch).

Basically we can get an IP address and that's about it. Any other traffic (web browsing, telnet) is choppy at best.

Using 4.0.179.11. WiSM in a 6509 (LAG default).

FYI - We are looking into an issue with 6548 blades dropping frames less than 64 Bytes.

CSCeb67650 - WS-X6548-GE-TX & WS-X6148-GE-TX may drop frames on egress

From Release note:

"Packets destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX that are less than 64 bytes will be dropped. This can occur when a device forwards a packet that is 60 bytes and the 4 byte dot1q tag is to added to create a valid 64 byte packet. When the tag is removed the packet is 60 bytes. If the destination is out a port on the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard."

http://www.cisco.com/en/US/products/hw/switches/ps700/products_field_notice09186a0080228f16.shtml

[wififofum]

Thanks for your feedback rseiler - we're eliminating any bug-affected 6548 uplink ports as a possible issue tomorrow and so will have new results very soon. I'm hoping this is it. I think we need to sniff the port-channel to see if this WLC bug might also be affecting us. Regards,

[rseiler]

Ethernet frames less than 64 bytes are invalid and runts and errors.

Assuming you have a Sup720-3B as the supervisor in the 6509? What version of IOS?

Can you send a 'show mod' and 'show fabric' from the switch?

Why do you have a WS-X6548-GE-TX blade in the chassis at all? You understand that blade has only 6 GigabitEthernet ports (6 groups of 8 ports) with HUGE oversubscription and head-of-line blocking issues.

The WS-X6148-GE-TX (or any 61XX,63XX,64XX module) have even bigger issues.

[wififofum]

Its a 3B running 12.2(18)SXF3.

The 6548s are going RMA ASAP.

The output is attached. There is 1 Fabric error noted on slot 2 (the WiSM blade). We already swapped out the chassis once after we saw a fabric error message. We have also RMA swapped the WiSM.

Thanks,

[rseiler]

Actually, your 'show fabric' looks good to me. As long as the 6548-GE-TX blades are only clients and not servers, you are good.

Note that the 6748-GE-TX line-rate modules do not support PoE.

I would start with an upgrade to the IOS on the Supervisor 720 to 12.2(18)SXF8, your existing IOS is quite old from Feb, 2006.

Be sure to download the IP SERVICES SSH LAN ONLY image since you don't want to inherit a few hundred bugs related to WAN connectivity for modules not even installed in your switch.

Note that 12.2(18)SXF3 was deferred on 11/30/2006 due to a number of critical bugs.

Also, there are several ROMMON upgrades (from several years ago) that don't appear to have been done to your switch. The latest RP ROMMON is 12.2(17r)SX5. The latest SP ROMMON is 8.5(1).

As a matter of curiosity, who sold you the 6548-GE-TX blades with the Sup720? There seems to be a lot of resellers/partners confused about using wiring closet oversubscribed blades in a core switch chassis.

Finally, what kind of packet recirculation are you doing on this switch with the FWSM? Do any packets from or to the WiSM use the FWSM as the next hop?

[wififofum]

Thank you,

Your points are well taken, esp. the deferred state on SXF3 and ROMMON versions (looking forward to the modular IOS). I'll review the SXF3 notices and bring it to the attention of management, who interfaces with AS.

These 6548s went under the radar. We received word of this bug from AS and we identified live blades for RMA, but a new switch subsequently went in with some inventory hardware.

AFAIK, the traffic's not passsing through the FWSM, but I'll verify with the onsite engineers.

Really appreciate your time on this one. I will let you know what comes of things.

Best Regards,

[wififofum]

The WISM issues appear to be related to the blade issues (bug).

We disabled the link from the bug affected blade to the edge router. This left a single link to the edge router on a non bug-affected blade.

We were able to use all resources (outlook, internet browsing, and telnet / ping) successfully. With both links active this was not possible, whereas it was possible with an IOS AP on the same VLAN as the WLAN-mapped interface on the controller.

More analysis to come, but its odd the same traffic now works when we remove the bug issue. It seems to suggest that the WLC is creating a < 64Byte frame.

[rseiler]

Are you sure that there is not an MTU issue with the path to the Internet or your Exchange server, etc?

A major difference between the autonomous AP and the WiSM is that traffic is in an LWAPP tunnel and it is routed differently by the Supervisor Engine.

Also, what changes when both links are up? Are they going to two different routers? Are they layer-3 links?

Is it possible that this is a routing, spanning-tree, asymmetric routing, or MTU (ATM,DSL,PPPoE) issue?