WAAS MTU or Asymmetric Routing Issues

[stanley_cwy]

I'm trying to setup WAAS between 2 sites. Site A with dual WAN routers and Site B with single WAN router. Site B will have 2 tunnels connecting back to Site A as per attached topology.

I'm facing some issues here whereby I'm not able to access application after putting in the WAAS. I'm still able to ping from Site A to Site B but I'm not able to perform RDP from Site A to Site B. I suspect could be due to MTU or asymmetric routing issue.

Wonder where can I fine-tune/correct the MTU or asymmetric routing issue? Hope someone can provide some guidance or direct me to the relevant configuration guide.

[sayrmatics]

Presuming you head end site is correctly set up and this is a new branch office...have you enabled wccp redirection on LAN and both tunnel WAN interfaces on the branch router?

[stanley_cwy]

Yes, WCCP redirection has been configured on both LAN and Tunnel interfaces at all the routers. 

[Aleksey Pan]

To be sure that you do not have any assymetric routes and connections are going thru the WAAS, you can check the "show stat conn | i x.x.x.x(Client IP or server IP) and check what the status is there.

[madhusudanan p]

Fragmented packets drops over a VPN Link

If this is an IPSEC + GRE tunnel/Site to Site VPN, the problem with this communications could be related to the size of the packet after all headers are appended/crypto payloads (with MTU size of 1400).. Since WAAS has the MTU path discovery disabled by default, we could try enabling it as part of testing.  But i havent seen a difference when we have it enabled.

So the best option is to remove the “ip mtu” and “tcp adjust mss xxx” commands from the tunnel interface. This should be done on both hub and spoke tunnel interfaces.

This should fix it

[finn.poulsen]

Hi,

Normally RDP isn't WAAS optimized (Passthrough), so it's probably not a MTU issue.

How is the redirection performed in Site A (with dual routers) ?

What could happen is that traffic entering or leaving Site A, gets redirected to the same WAAS twice.

As part of the autodiscovery process a WAAS inserts its own ID in the TCP SYN packet.

And when it sees it's own ID in  packet, it assumes that there is a "routing loop" (seen from a WAAS perspective only) and drops the SYN packet.

This also occurs even with passthrough packets.

Ping is not TCP, so it won't even look into the packet.

You can verify this by looking into some of the logs on the WAAS in Site A - dependant on WAAS version :

Either it's in the "syslog.txt" file in the default directory.

or in the errorlog directory look in file "waasnet.current" (for versionb 6.0 and later).

Look for "routing loop" messages (or similiar, can't remember the exact syntax).

Best regards.

Finn 

[stanley_cwy]

I'm getting in AppNav to test now. Hopefully will help.