WCCP Load balancing

[WILLIAM STEGMAN]

I've setup WCCP to redirect to 2 BlueCoat SGs using an access list that includes both proxies.  All 3 hosts, ASA gateway and 2 proxies are in the same VLAN.  I'm thinking this might be an issue with GRE and the routing ID, so I've modified the access list on the inside interface facing the proxies to allow GRE to the router ID of the ASA, which is a DMZ interface.  The default route on the proxies is pointing to an SVI on a switch in the same VLAN as the proxy interfaces and inside interface of the firewall.  However, I tried adding a route on the proxy to point to the ASA inside interface when trying to reach the router ID network, but no luck.  I ran a packet capture and see the ASA initiating GRE communication to the proxy, but never see anything in the return direction related to GRE.  

I see WCCP redirect hits 

MTAASA1(config)# sh wccp 70

Global WCCP information:
    Router information:
        Router Identifier:                   192.168.208.1
        Protocol Version:                    2.0

    Service Identifier: 70
        Number of Cache Engines:             2
        Number of routers:                   1
        Total Packets Redirected:            2901
        Redirect access-list:                wccp-traffic
        Total Connections Denied Redirect:   11
        Total Packets Unassigned:            155
        Group access-list:                   wccp-servers
        Total Messages Denied to Group:      328
        Total Authentication failures:       0
        Total Bypassed Packets Received:     372

access-list wccp-servers line 1 extended permit ip object-group BlueCoat_Servers any 0x7948c20d
 access-list wccp-servers line 1 extended permit ip host 10.14.6.8 any (hitcnt=84) 0x4e3c82a4
 access-list wccp-servers line 1 extended permit ip host 10.14.6.9 any (hitcnt=85) 0x959ad46f

WCCP config:

wccp 0 redirect-list wccp-traffic group-list wccp-servers
wccp 70 redirect-list wccp-traffic group-list wccp-servers
wccp interface INSIDE 0 redirect in
wccp interface INSIDE 70 redirect in

access-list wccp-servers extended permit ip object-group BlueCoat_Servers any

thank you, 

Bill

[Ken Stieers]

I'm pretty sure you're looping because the traffic from the BlueCoats is being redirected back to them.

The redirect ACL should look like this:

access-list WCCP_Redirect extended deny ip any4 object-group MyInternalNetworks
access-list WCCP_Redirect extended deny ip host 172.16.15.10 any4
access-list WCCP_Redirect extended deny ip host 172.16.15.11 any4
access-list WCCP_Redirect extended permit ip object-group MyInternalNetworks any4

Line 1 keeps inbound traffic from being WCCPd, it is probably redundant.

Line 2 and 3 keep traffic from my WSA's from being WCCP

Line 4 allows outbound traffic to be WCCPd.

right now you're only allowing your bluecoats outbound traffic to be WCCPd and not WCCPing any of your clients traffic at all.

[WILLIAM STEGMAN]

Ken, I think I'm following your suggestions, I just hadn't included the config that attests to that in my first post.  I'm denying my proxies from being redirected, and am redirecting one client for testing purposes, 10.15.150.1.  I added a deny any to 10.15.150.1 in the wccp-traffic acl, but it doesn't get any hits and I see the same results.  

MTAASA1(config)# sh access-li wccp-traffic
access-list wccp-traffic; 4 elements; name hash: 0xb7b6044d
access-list wccp-traffic line 1 extended deny ip object-group BlueCoat-WCCP_Inside_Exclude any 0xe3c512e5
  access-list wccp-traffic line 1 extended deny ip host 10.14.6.8 any (hitcnt=4) 0x7333b881
  access-list wccp-traffic line 1 extended deny ip host 10.14.6.9 any (hitcnt=2) 0x6eff2f4b
access-list wccp-traffic line 2 extended deny ip any host 10.15.150.1 (hitcnt=0) 0x706233ae
access-list wccp-traffic line 3 extended permit ip object-group BlueCoat-WCCP_Inside any 0x84c41e04
  access-list wccp-traffic line 3 extended permit ip host 10.15.150.1 any (hitcnt=9936) 0xa3e20aeb

[Vance Kwan]

Not sure this belongs in the Cisco Web Security forums as this pertains to the Cisco Ironport product, as well as Cisco Cloud Web Security.  This will probably get more attention in Firewall forums as the Firewall team supports WCCP on the FW.

But many things can go wrong at this point.  It'd probably be best if you started with a packet capture on your Blue Coat to see what it is doing.

In the packet capture, you should be looking for 2 things:

-TCP 3 way handshake (source IP client, destination IP web server) + HTTP request method/response

-TCP 3 way handshake (Blue COAT IP, destination IP webserver) + HTTP request method/response

[WILLIAM STEGMAN]

Thanks Vance.  I've moved this to the firewall group.  I've run some packet captures, and it looks to me like there might be a GRE issue.  I only see one side of the conversation, and although GRE is connectionless, I'm thinking I should still see some GRE traffic sourcing from both endpoints.  I do see back and forth traffic between ASA and proxy on UDP port 2048, which appears to the a common proxy port.  I don't see any HTTP traffic in the capture from the test users.

thanks