MTU WAAS/MPLS (SAP) question

[Sebastian Helmer]

Hi there,

we are facing a strange issue for me.

the Setup I'd like to Focus on:

(Server)LAN--WAAS--ISP(MPLS)--WAAS--LAN(Client)

User sessions were broken sometimes between the SAP and the user GUI. After re-searching without success we remember an MTU thing from old VPN days. After changing the MTU of the server to 1400(maybe not a cool value, just a lower one). The problems are gone. But we did not see that any other application needs that Change, just the SAP systems.(do not fragment bit is set in the SAP packets)

In my tests I can see that we have the full 1500 Bytes available (remember u need to add the 28bytes for the header informations)

C:\Users\xx>ping 10.x.y.50 -l 1473 -f Pinging 10.x.y.50 with 1473 bytes of data: Packet needs to be fragmented but DF set. Ping statistics for 10.x.y.50:     Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), Control-C ^C C:\Users\xx>ping 10.x.y.50 -l 1472 -f Pinging 10.x.y.50 with 1472 bytes of data: Reply from 10.x.y.50: bytes=1472 time=42ms TTL=55

Could the problem be that it was not the "„IP TCP PATH-MTU-DISCOVERY“ configured on the Switch/router on both sides?  I give it a try this night and try to check that in the next days..

But for me the next informations comes into the play also. Or not ?

What does the 1432 mean for the LAN with a WAAS in the WAN, do we need to adjust the MTUs for servers communicationg over the WAN?

Should we adjust the BDP when my calculation give a result of 5324.8  or 6348.8 on another Location?? Or is playing to much with those values a nightmare?

Any idea or comment is very appreciated.

Thanks Sebastian

The WAAS system automatically adjusts the maximum segment size (MSS) to match the advertised MSS of the client or server for each connection. The WAAS system uses the lower of 1432 or the MSS value advertised by the client or server.

If your network has high BDP links, you may need to adjust the default buffer settings automatically configured for your WAE device. For more information, see the "Calculating the TCP Buffers for High BDP Links" section.

Table 13-6 TCP Settings
TCP Setting	Description
Optimized Side
Maximum Segment Size	Maximum packet size allowed between this WAAS device and other WAAS devices participating in the optimized connection. The default is 1432 bytes.
Send Buffer Size	Allowed TCP sending buffer size (in kilobytes) for TCP packets sent from this WAAS device to other WAAS devices participating in the optimized connection. The default is 32 KB.
Receive Buffer Size	Allowed TCP receiving buffer size (in kilobytes) for incoming TCP packets from other WAAS devices participating in the optimized connection. The default is 32 KB.
Original Side
Maximum Segment Size	Maximum packet size allowed between the origin client or server and this WAAS device. The default is 1432 bytes.
Send Buffer Size	Allowed TCP sending buffers size (in kilobytes) for TCP packets sent from this WAAS device to the origin client or server. The default is 32 KB.
Receive Buffer Size	Allowed TCP receiving buffer size (in kilobytes) for incoming TCP packets from the origin client or server. The default is 32 KB.

Step 5 If you are deploying the WAE across a high Bandwidth-Delay-Product (BDP) link, you can set recommended values for the send and receive buffer sizes by clicking the Set High BDP recommended values button. For more information about calculating TCP buffers for high BDP links, see the “Calculating the TCP Buffers for High BDP Links” section.

Kommen wir zum BDP (Bandwidth-Delay-Product)

·         WAE-512—Default BDP is 32 KB

·         WAE-612—Default BDP is 512 KB

·         WAE-674 —Default BDP is 2048 KB

·         WAE-7341 —Default BDP is 2048 KB

·         WAE-7371 —Default BDP is 2048 KB

·         All WAVE platforms—Default BDP is 2048 KB

If your network provides higher bandwidth or higher latencies are involved, use the following formula to calculate the actual link BDP: BDP [Kbytes] = (link BW [Kbytes/sec] * Round-trip latency [Sec])

[Masoud Pourshabanian]

MTU issue usually happens on Ethernet ports or WAN backbone ports.

If you have access to MPLS network, try "MPLS MTU 1508" on switches and backbone routers interfaces. If you do not have, forward smaller packet to MPLS network.

WAAS probably add header to each packet, so your MPLS backbone drops the large packets. If so, try to send smaller packets to MPLS network.

Masoud
 

[Sebastian Helmer]

Thanks for your reply. Same as I think in general.

what I heard (WAN Team) the WAAS is almost out ot the box configured with just a few customized things. So I'm interessted if there are some point we need to consider. In the documentation we see 1432 comes into the play..

unfortunately, I don't have access to the ISP ports, we have a managed service and geht just the ethernet (1Gbit) port connected to our core, so I don't have any option there. What I will think about a discussion with them.

Any more Input, maybe regarding the WAAS would be nice...I have the feeling that there could be an issue as well...

-Sebastian

[Sebastian Helmer]

Why do you think so?

I can ping with 1472 + IP Header = 1500bytes over the line.

Also from a switch I can ping with 1500 Bytes of size.

In wireshark I can see that packets with 1514 Byte and no fragmentation on both sides.

I'm not 100% sure where any why I have an MTU Problem thats I Need to understand if I have.

I'm also not sure which role the WAAS is playing..

Also I'm not sure but it seem to help, the last tests are still in progess, by the "MTU path-discovery" command seems to help, when I'm able to ping with 1500 bytes...

Or does it maybe mens the WAAS don't touch the ICMP what I expect, but the TCP packets, I'm not sure how I can see if the TCP packets are framented, when I start a SMBv2 file copy I see very big length in wireshark...Not sure how to Interpret this..

[Masoud Pourshabanian]

You are right. WAAS does not touch ICMP and UDP. Check your configuration to figure out what kind of traffic it is accelerating. I do not think it is accelerating SMBv2. How is it placed in your network? It is your default gateway or traffic is directed to it by Policy based routing?

I think the best option to adjust MTU is adjusting it inside the WAAS. It will have impact on other traffic, if you adjust  MTU on your routers.

Please take a look at the link below to deal with MTU.

http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v407/configuration/guide/cfgd/network.html#wp1041841

[Sebastian Helmer]

Thanks!

so my test is valid and shows that I can use the line with an MTU of 1500 when the was isn't touching that. 

So, why do I need an discovery enabled on the waas?

the waas is in-line in the path on both sides where I see the issue I mentioned initially.

SMB is optimized as I understood from my waas colleagues...but I need to check that in deep but that is not important for me for that case, I think. The problem was initiated by the SAP user drops from time to time as mentioned .

Currently im at a point where I don't see the issue  just the point that I enabled the discovery on my core where the ISP is connected to and all traffic is routed to by static routing .

Sebastian

[Masoud Pourshabanian]

Discovery adjust the proper MTU automatically. I was wrong about SMB. It is supported.

I suggest you download proper document based on your WAAS version.

The one I sent was for version 4. Here is another one for version 5 which has different information about MTU.

http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v501/configuration/guide/cnfg.pdf

Activate discovery and check the result.

Another way is decreasing MTU of device by 10 ( several times) and check the result each time.

[Sebastian Helmer]

Not sure if I understand that correctly or at all what I see in the doc u send with the link. 

What does that mean it use 576byte. Does that mean maybe it was necessary to enable the path discovery on the core so that the clients are able to negotiat that very low MTU? If so I will discuss that with the waas team to change that  

By default, this feature is disabled. With the feature disabled, the sending device uses a packet size that is the lesser of 576 bytes and the next hop MTU. Existing connections are not affected when this feature is turned on or off. 

To enable the MTU Discovery feature, follow these steps:

[Beau Clark]

Sebastian,

Not sure if you are still having this issue, but I was able to configure a route-map to un-flag the do not fragment bit on the traffic from the SAP server. On the layer 3 switch connected to the subnet where the SAP server is, I configured the following:

ip access-list standard DF-BIT
  permit 192.168.1.0 0.0.0.255

route-map CLEAR-DF-BIT permit 10
   match ip address DF-BIT
   set ip df 0

interface Vlan99

   ip policy route-map CLEAR-DF-BIT

This way, all traffic from SAP is now able to be fragmented when it goes through the WAAS.

On the WAAS, I verify the traffic is being accelerated with the command:

show stat conn | inc :3299

Before this change, all sessions were below 5%. Now I see sessions being accelerated over 70%.

Hope this helps.