×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

WAE's Not Optimizing Traffic

Answered Question
Jul 28th, 2008
User Badges:

My current setup is very simple. I have 2 WAE's with Inline adapters running across the core of my network. They both see the traffic between them, but very little gets optimized.


I have been able to figure out what is going on, but don't understand if WAAS should handle this situation. I run several VLAN's and the Core switch uses EIGRP for routing. When I do a traceroute, I see that EIGRP is choosing to send traffic between it and the Core router (Core WAE in between them) across VLANs that are not the Default VLAN. If I put in static routes at the Core switch to use the default VLAN, WAAS happily optimizes the traffic. When I let EIGRP choose routing across the Core, WAAS only optimizes a small percentage of valid traffic.


Note that there is only one physical path between the 2 WAE's. There is only one router hop in the middle. I have not found any documentation that says this should not work.


I am running 4.0.19 and will happily provide configs, etc. I would love to hear what others think about whether WAAS is working properly under the circumstances?


Oh, this is only a test. I realize that there is not much point in trying to optimized traffic across the core, but I hit this same issue when I took my Edge WAE to a remote site.

Correct Answer by Zach Seils about 9 years 2 weeks ago

Barry,


By default, traffic for a given connection must be seen by the inline module on the same VLAN in both directions to be optimized. In 4.0.19 we added the ability to disable this check using the following global configuration command:


[no] inline vlan-id-connection-check


Regards,

Zach



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
dstolt Tue, 07/29/2008 - 05:11
User Badges:
  • Cisco Employee,

Could you post the network diagram showing the network paths you discribed? Sounds like it's extremely low latency, however it should give you better stats unless something is being intercepted 2x and being dropped. Do you see a lot of looping messages (sees own devid) in the syslogs?


Dan

bbeal-spang Tue, 07/29/2008 - 06:16
User Badges:

Here is the test network diagram. There is only one physical path from the test PC (10.99.0.12) to the Core 2801, but if you see from the tracert command on the PC, EIGRP routes the traffic from the Core switch to the Core 2801 via VLAN 11:


C:\Documents and Settings\bbeal>tracert 10.3.0.1


Tracing route to 10.3.0.1 over a maximum of 30 hops


1 1 ms 1 ms 1 ms 10.99.0.1

2 2 ms 1 ms 1 ms 10.0.0.1

3 1 ms 1 ms 2 ms 10.100.11.2

4 35 ms 36 ms 35 ms 10.3.0.1


Trace complete.


Following is the Show TFO Connection Summary when I copy a file from the Test PC (which is now 10.99.0.12) to the remote computer at 10.3.2.11


nedgwae99#sh tfo conn summ | in 10.99

10.99.0.12:2961 10.0.0.2:22 28646 00:14:5e:85:92:b7 T,T,T,T

10.0.2.55:2210 10.99.0.12:2537 PT In Progress

10.99.0.12:2883 10.3.2.11:445 PT No Peer

10.3.2.11:445 10.99.0.12:2883 PT No Peer

10.99.0.12:2537 10.0.2.55:2210 PT In Progress

nedgwae99#



From Core WAE:


ncrpwae01#sh tfo conn summ | in 10.99

10.99.0.12:2961 10.0.0.2:22 28643 00:14:5e:85:93:a3 T,T,T,T

10.6.1.11:80 10.99.0.12:2949 PT Asym Client

10.99.0.12:2959 10.8.0.2:443 PT In Progress

10.4.1.11:443 10.99.0.12:2939 PT Asym Client

10.5.1.13:80 10.99.0.12:2897 PT Asym Client

10.9.1.11:80 10.99.0.12:2954 PT Asym Client

10.99.0.12:2947 10.5.1.12:80 PT Asym Client

10.99.0.12:2883 10.3.2.11:445 PT Asym Client



There are looping msgs in the Core WAE Syslog. See attachment.



dstolt Tue, 07/29/2008 - 06:46
User Badges:
  • Cisco Employee,

I agree that it really looks like you start to miss traffic when you send it over VLAN 11.


Do you have both the inline cards set to accept traffic from all the VLANs (Intercept All VLANs box checked)? If you are using both inline groups, make sure they are both "no shut" so you are intercepting on both links.


Also as an FYI, if you are doing CIFS and have a connectivity directive, autodiscovery won't work under 5 ms, so most of the CIFS traffic should be using full optimization, NOT the CIFS AO 4050 tunnel. It requires latency to kick in unless you manually export a server to force it inside the tunnel.


Let me know what you find, we may have to take a look at the wae configs as well...


Dan

dstolt Tue, 07/29/2008 - 06:49
User Badges:
  • Cisco Employee,

Also, double check your port speeds/duplex on both core and edge. Your lab box should be hard set to 100/full on inlinegroup, switch and router. The core looks like you should keep them all auto (gig capable).


Dan

bbeal-spang Tue, 07/29/2008 - 07:01
User Badges:

Attached are the first parts of the Show Runs and the Show Int InlineGroup 1/1 for both WAEs.


The Edge WAE is connected to a Cisco 2611 with 10Meg interfaces (I had this same problem when I took the Edge WAE to a remote site with another 2801 (both Interfaces were at 100 Full). The Core WAE did not autosense properly when connected between the 2801 and the 3750G, so it is hard set for 100 Full.


Again, if I static route the traffic to go across the Default VLAN the problem goes away (all traffic is optimized). So, I think this is most likely a routing issue, even though it is one physical path, rather than an interface issue.



dstolt Tue, 07/29/2008 - 20:32
User Badges:
  • Cisco Employee,

Configs look OK, the only thing I would try would be to move the primary interface on the core to gig 1/0 and put the IP addresses there and see if that helps any.


The edge is setup as auto, do you need to hard code that one as well?


You are intercepting All VLANs, so it should pick up any of them, as long as it's not bouncing out to the router and back twice for some reason.


Dan

bbeal-spang Wed, 07/30/2008 - 04:59
User Badges:

This is interesting! I have done some TCPDUMP's and the Core WAE is not processing (only bridging) traffic that comes in on anything but the default (untagged) VLAN.


Any ideas on why that is? I am suspicious that it is a bug in 4.0.19. Anyone else running Inline with multiple VLANs and 4.0.19?


Is there any reason to believe that InlineGroup 1/0 might handle this differently?

I am happy to try it, but it does take a small outage on our production network, so it would be nice to know if there is a good reason to try.

dstolt Wed, 07/30/2008 - 09:12
User Badges:
  • Cisco Employee,

You can try it to see if there is any difference, but there shouldn't be. Let me know if you try it and it works.


Dan

bbeal-spang Mon, 08/04/2008 - 11:32
User Badges:

One update on this problem. It is clear from captures and the Show Int InlineGroup 1/1 (attached previously) that the WAE's are bridging all traffic that comes in on any VLAN other than the Default VLAN. This is not what I expect the WAE's to do with "include all VLANs" configured.


Any ideas?

Correct Answer
Zach Seils Tue, 08/05/2008 - 10:35
User Badges:
  • Cisco Employee,

Barry,


By default, traffic for a given connection must be seen by the inline module on the same VLAN in both directions to be optimized. In 4.0.19 we added the ability to disable this check using the following global configuration command:


[no] inline vlan-id-connection-check


Regards,

Zach



Actions

This Discussion