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

LWAPP and MSS (Maximum Segment size)

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

18 REPLIES
Bronze

Re: LWAPP and MSS (Maximum Segment size)

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

New Member

Re: LWAPP and MSS (Maximum Segment size)

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

Bronze

Re: LWAPP and MSS (Maximum Segment size)

Thank You!

Silver

Re: LWAPP and MSS (Maximum Segment size)

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.

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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-----------------------------------------------------------------------------

Silver

Re: LWAPP and MSS (Maximum Segment size)

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)?

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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,

Silver

Re: LWAPP and MSS (Maximum Segment size)

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.

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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,

Silver

Re: LWAPP and MSS (Maximum Segment size)

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?

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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,

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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.

Silver

Re: LWAPP and MSS (Maximum Segment size)

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?

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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,

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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.

Bronze

Re: LWAPP and MSS (Maximum Segment size)

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 ;).

New Member

Re: LWAPP and MSS (Maximum Segment size)

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

1090
Views
9
Helpful
18
Replies
CreatePlease to create content