WCCP shows two caches, but a new floor and all HTTPS bypass the proxy
Vantage Retail runs 260 stores, each with an ISR 4331 redirecting guest and back-office traffic by WCCPv2 service group 0 (web-cache) to a regional pair of WSAs in transparent mode. At the regional data center the core is a pair of Catalyst 9500s running VRRP. After a floor build-out added VLAN 20, users there report full internet access with no filtering, and helpdesk notices that HTTPS to a test gambling site works from every VLAN while the same site over HTTP is blocked. On the core, show ip wccp web-cache reports two routers and two caches, both usable, which the network team reads as proof that redirection is healthy. The WSA web tracking report shows plenty of sessions, all sourced from the core's VRRP address rather than client addresses. A second issue appears after a core failover: the WSA's own update traffic begins appearing in its own access logs.
1. Why are VLAN 20 and HTTPS escaping the proxy, and why does the WCCP status output look healthy anyway?
Read the worked answer
The status output only proves the WCCP protocol relationship exists between routers and caches; it says nothing about which packets are matched for redirection. Redirection is driven by two things that must both be right: the interface where ip wccp redirect is applied and the redirect ACL used by the service group.
The symptom set points to both being wrong. If the redirect statement exists only on the original client VLAN interface and was never applied inbound on VLAN 20, that floor is simply not redirected. If the redirect ACL permits only TCP/80, then HTTPS is never redirected from any VLAN; the HTTP block the helpdesk sees is real filtering, while HTTPS is going direct. That also explains why a categorised site can be blocked on HTTP and reachable on HTTPS from every floor.
The "all sessions sourced from the VRRP address" detail is a separate confirmation: the WSA is seeing traffic that has already been routed/NATed by the core, not the original client IPs. That breaks IP-based identity and makes reports misleading even where redirection works.
Verify with per-interface redirect counters and by capturing on the WSA data interface while a known client on VLAN 20 loads a plain HTTP URL.
2. What change set would you apply so that redirection is complete and verifiable, and how would you validate it?
Read the worked answer
Apply a single consistent redirection design rather than patching each symptom.
On the core: use one redirect ACL that permits the ports the estate actually uses (80 and 443 at minimum, plus any alternate ports such as 8080 if applications use them) and apply ip wccp <service> redirect in on every client-facing VLAN interface, including VLAN 20. Add ip wccp redirect exclude in on the interface facing the WSA so the appliance's own outbound traffic is not fed back to itself; that is the likely cause of the WSA logging its own update traffic after failover. Confirm both VRRP peers carry identical WCCP configuration, since a failover must not change redirection behaviour.
On the WSA: confirm the transparent redirection service is enabled on the correct data interface, and that the interface has a valid return path and default gateway.
Validation, not assumption:
- Clear and re-read WCCP counters before and after a test request from each VLAN; the redirect counter should increment.
- Make a test request to a URL in a blocked category over HTTP and over HTTPS from VLAN 20 and from an original VLAN.
- Check web tracking shows the client IP, not the VRRP address, for transparent sessions.
- Monitor the counters and alert on a flat redirect counter while interface traffic is present, which is the signature of silent bypass.
3. The organisation wants to add a second WSA for capacity. What WCCP design choices affect whether load is shared predictably and whether a node failure is graceful?
Read the worked answer
Three choices matter: assignment method, return method, and service-group design.
Assignment: WCCPv2 can assign with a hash or with a mask. Mask assignment is the preferred choice with multiple caches because it distributes by a defined portion of the client or destination address bits and is more predictable than hashing when the cache set changes. With mask assignment, adding or removing a cache redistributes only the buckets mapped to that cache instead of potentially remapping most flows, which reduces mid-session resets when a node goes down.
Return method: Layer 2 return requires the WSA to be on the same subnet as the router interface it returns through, which limits placement; GRE return works across Layer 3 but requires GRE (protocol 47) to be permitted on every device between the WSA and the router. If a firewall between the WSA and core drops GRE, redirected traffic reaches the WSA but the response never returns, producing intermittent resets that look like an application problem.
Service group: stay with a single service group containing both caches rather than creating parallel groups with overlapping match rules, and keep the redirect ACL and exclusion rules identical on both core peers. After adding the node, re-test a blocked URL repeatedly from the same client to confirm it is consistently redirected to one cache, and pull one cache out of the group to confirm the remaining node absorbs the load.