WAAS upgrade to 4.5.1 - ICA acceleration not working

[agod131]

Hello,

I upgraded our WAAS to 4.5.1 at the weekend so we can test if ICA optimisation is worth having and thus if WAAS is worth keeping. The upgrade went fairly smoothly. I upgraded the central manager, the core and one of our test WAE on our test network. I turned the WCCP redirects back on specifically for this network. When I plug a laptop into this network I can see optimisation working fine. When I plug my wyse terminal in, I am seeing the connection on both ends:

....

Historical Flows:                                    98

Local IP:Port        Remote IP:Port        Peer ID          ConnType         
10.205.100.51:3615    10.110.22.44:1494    N/A              PT In Progress   
10.110.22.44:1494    10.205.100.51:3615    N/A              PT In Progress

My wyse ip is 10.205.100.51 and my remote desktop is 10.110.22.44.

I have checked that ICA acceleration is on at both ends.

Any ideas what I am missing?

Thanks

Andrew

[Nicolas Fournier]

Hi Andrew,

If you setup a policy as TDL only between 10.205.100.51 and 10.110.22.44, do you see those connections as optimized or are they also displayed as "PT In Progress"?

From what we see in your post, it simply seems that some of the traffic between those two hosts is bypassing WAAS on either the core or the edge site and seeing those connections as "PT In Progress" with a TDL policy would simply confirm that the issue is not ICA related but more general.

If you still see them in that state, taking captures on the WAE on both sides should show you on which side we miss some traffic (or if a device in the path is clearing the WAAS TCP option).

Regards,

Nicolas

[agod131]

Thanks for your reply Nicolas.

Can you help me with setting up a policy for TDL or point me at a how to?

Just to give you some more info. At the far end (test network) there is no other path into the core over the 'WAN'. At the core end there is a VSS pair of 6500s. These should act as a single unit. There is howvever another pair of VSS switches at our DR site that have the HSRP standby intefaces. These shouldn't be routing as the traffic would need to traverse the l1gig link to our DR site and back again but I am seeing the interface stats incrementing. This could be local traffic however.

Thanks

Andrew

[Nicolas Fournier]

hi Andrew,

Here is a document that describes how to setup a policy:

http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v441/configuration/guide/policy.html

Again, if you want to make sure that all the traffic is hitting your WAAS boxes, nothing beats a capture on the device themselves.

Regards,

Nicolas

[agod131]

OK I setup a policy and it didn't seem to get any traffic so I moved onto the capture.

I ran the capture on both devices several times. Each time I didn't see the return traffic on the Core wae - just the outbound.

I then ran several other tests, this time not using a filter and not using my wyse terminal. These captures also didn't see the return traffic but did optimise the traffic!

Not sure where it is going as there is only one way back!

[Nicolas Fournier]

Hi Andrew.

What are you using to intercept the traffic on the core side? WCCP also?

Can you verify the 61/62 statements are on the correct interfaces?

Is there a redirect list on the WCCP services? If so, can you verify they are mirror of each others for 61 and 62?

Regards,

Nicolas

[agod131]

Hi Nicolas,

Thanks for sticking with this.

To answer your question, yes WCCP at both ends. See below for actual setup:

• At the far end (test network), I have a 2821 router with a WAE NM and a switch. The Wyse is plugged into the switch. There is no other way back into the core except over the WAN simulator. The router redirects using the following:
  

ip wccp 61 redirect-list 150 group-list 20

ip wccp 62 redirect-list 150 group-list 20

interface GigabitEthernet0/0.100

encapsulation dot1Q 100

ip address 10.205.100.1 255.255.255.0

ip helper-address 10.101.2.10

no ip redirects

no ip unreachables

no ip proxy-arp

ip wccp 61 redirect in

no cdp enable

interface GigabitEthernet0/1

description ** WAN link to London **

bandwidth 4096

ip address 10.252.205.1 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip wccp 62 redirect in

ip flow ingress

ip authentication mode eigrp 1 md5

ip authentication key-chain eigrp 1 EIGRP_KEY

duplex full

speed 10

no mop enabled

service-policy output QoS_Out

interface Integrated-Service-Engine1/0

ip address 10.205.10.1 255.255.255.0

ip wccp redirect exclude in

service-module ip address 10.205.10.2 255.255.255.0

!Application: Restarted at Sat Dec  8 16:27:07 2012

service-module ip default-gateway 10.205.10.1

no keepalive

access-list 150 permit tcp 10.205.100.0 0.0.0.255 any

access-list 150 permit tcp any 10.205.100.0 0.0.0.255

I'm guessing this works just fine.

• At the core end we have a couple of 3800 routers. The wan is terminated on one of these. Both these routers are connected into the Core using a ‘WAN vlan” = 926. This then enables me to redirect the traffic on core using this vlan interface. The core is a couple of 6500s running VSS. The VDI lives in vlan22 and other servers live in vlan 1.
  

ip wccp 61 redirect-list 120 group-list 20

ip wccp 62 redirect-list 120 group-list 20

access-list 120 remark ** Match traffic for WAAS optimisation **

access-list 120 permit tcp 10.205.100.0 0.0.0.255 any

access-list 120 permit tcp any 10.205.100.0 0.0.0.255

interface Vlan1

ip address 10.101.1.20 255.255.0.0

no ip redirects

no ip proxy-arp

ip wccp 61 redirect in

ip flow ingress

standby 2 ip 10.101.1.1

standby 2 timers 5 15

standby 2 priority 105

standby 2 preempt

standby 2 authentication asdf

hold-queue 2000 in

hold-queue 2000 out

interface Vlan22

description ** London Statics **

ip address 10.110.22.2 255.255.255.0

ip helper-address 10.101.2.10

no ip redirects

no ip unreachables

no ip proxy-arp

ip wccp 61 redirect in

standby 22 ip 10.110.22.1

standby 22 timers 5 15

standby 22 priority 105

standby 22 preempt

standby 22 authentication asdf

interface Vlan926

description ** WAN VLAN **

ip address 10.252.101.2 255.255.255.0

ip access-group block_loopback in

no ip redirects

no ip unreachables

no ip proxy-arp

ip wccp 62 redirect in

standby 254 ip 10.252.101.1

standby 254 timers 5 15

standby 254 priority 105

standby 254 preempt

standby 254 authentication asdf

The access list appears to be working both ways:

LON-CORE-SWT1#sh access-list 120

Extended IP access list 120

    10 permit tcp 10.205.100.0 0.0.0.255 any (742 matches)

    20 permit tcp any 10.205.100.0 0.0.0.255 (19810 matches)

The observant will notice the HSRP. The standby interfaces for these are at our DR site on another pair of 6500s running VSS and although they have the WCCP set they don't appear to be doing anything. The access list on this core is showing zero hits.

This is a fairly historic setup as we have been running WAAS for some time. It may be that there is a better way of doing it or perhaps a prefered way. If this is the case then please let me know.

Thanks

Andrew

[Nicolas Fournier]

Hi Andrew,

The redirection on the catalyst is done in hardware so I believe it is normal you don't see any hits on the ACL.

I believe we've reached here the limits of what can be troubleshooted within a public forum so I would advise you to open a TAC case so that a deeper look at this can be taken.

Regards,

Nicolas