WCCP is a protocol which is used for the redirection of packets from a WCCP router (read: the WAN router or LAN switch) to a set of WCCP caches (read: the Steelhead appliances).
Figure 5.67. A WCCP setup
.-,( ),-. .-( )-. .----------------------------. .--------. ( network )-------| WCCP router |------| Server | '-( ).-' '-------------.--------------' | '--------' '-.( ).-' | | .--------. .--------'--------, '---| Server | | | | '--------' .------------. .------------. | .--------. | WCCP cache | | WCCP cache | '---| Server | '------------' '------------' '--------' WCCP router: 192.168.2.1 WCCP cache: 192.168.2.2 WCCP cache: 192.168.2.3
The WCCP router has one or more service-groups defined. A service-group is a set of IP addresses and TCP port numbers which are directed to a specific group of caches. By configuring multiple service-groups, different groups of WCCP caches can be used for the redirection of different kinds of traffic.
The WCCP cache has one or more service-groups and every service-group has one or more WCCP routers configured and various negotiable options like the encapsulation method and the assignment type.
The negotiation of a WCCP cache with the WCCP router is initiated by the WCCP cache: It sends a WCCP HERE_I_AM packet to the WCCP routers, which should be answered with a WCCP I_SEE_YOU packet.
With tcpdump, this looks like:
Figure 5.68. Tcpdump of WCCP traffic
SH # tcpdump -ni wan0_0 port 2048 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 96 bytes 16:57:40.916187 IP 192.168.2.2.2048 > 192.168.2.1.2048: UDP, length 144 16:57:40.948061 IP 192.168.2.1.2048 > 192.168.2.2.2048: UDP, length 140 16:57:50.927298 IP 192.168.2.2.2048 > 192.168.2.1.2048: UDP, length 144 16:57:50.957309 IP 192.168.2.1.2048 > 192.168.2.2.2048: UDP, length 140
The UDP packet gets send from the in-path IP address of the Steelhead appliance to the WCCP router IP address. If the WCCP router is willing to accept the WCCP cache, it will send an UDP packet back.
Figure 5.69. Tcpdump of WCCP traffic
SH # tcpdump -ni wan0_0 port 2048 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 96 bytes 16:57:40.916187 IP 192.168.2.2.2048 > 192.168.2.1.2048: UDP, length 144 16:57:50.927298 IP 192.168.2.2.2048 > 192.168.2.1.2048: UDP, length 144
Besides the obvious two reasons, that the IP address of the WCCP router is entered incorrectly on the WCCP cache or that the WCCP router is not configured correctly, this will happen when the WCCP options given by the WCCP cache are incompatible by the current operation of the WCCP router:
The WCCP cache encapsulation and assignment options are not compatible with the capabilities of the WCCP router. For example the WCCP cache wants to use GRE forwarding, the WCCP router can only do L2 forwarding.
This WCCP cache options are different from the options configured on the other WCCP caches in the same service group. In this scenario there will always be one WCCP cache joined to the WCCP router and the second one will not be successful.
It is possible that the IP address of the WCCP router configured on the WCCP cache is not the source IP address of the WCCP I_SEE_YOU packets returned and thus the packets are ignored by the WCCP cache.
Figure 5.70. Tcpdump of WCCP traffic
SH # tcpdump -ni wan0_0 port 2048 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 96 bytes 16:57:40.916187 IP 192.168.2.2.2048 > 172.16.3.2.2048: UDP, length 144 16:57:40.948061 IP 192.168.2.1.2048 > 192.168.2.2.2048: UDP, length 140 16:57:50.927298 IP 192.168.2.2.2048 > 172.16.3.2.2048: UDP, length 144 16:57:50.957309 IP 192.168.2.1.2048 > 192.168.2.2.2048: UDP, length 140
This could happen if the IP address of the WCCP router configured on the WCCP cache is an HSRP or a loopback address and the answers are coming from the IP address of the outgoing interface of the WCCP router.
Once the WCCP session is successfully negotiated, it will redirect packets as defined in the WCCP redirection list. This redirection list should be applied on both the incoming WAN interface and the incoming LAN interfaces.
The best practice is to use inbound redirection of the interfaces of the WCCP router: Packets redirected when they come in on the interface will have had less processing done on them, leaving the router free to do other important things like forwarding packets.
If the WCCP router and the WCCP cache are on the same IP subnet, L2 forwarding should be preferred over GRE encapsulation, to overcome possible IP fragmentation overhead.
When traffic or a certain kind of traffic does not get optimized, the easiest way to find out what happens is on the Steelhead appliance WAN interface with tcpdump:
If the only traffic seen is traffic on UDP port 2048 and Ethernet broadcast traffic, then the WCCP router is not redirecting packets to the WCCP cache.
Figure 5.71. Tcpdump shows that the WCCP router is not forwarding packets to the WCCP cache
SH # tcpdump -ni wan0_0 -c 100 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 96 bytes 16:57:40.916187 IP 192.168.2.2.2048 > 192.168.2.1.2048: UDP, length 144 16:57:40.948061 IP 192.168.2.1.2048 > 192.168.2.2.2048: UDP, length 140 16:57:42.123456 ARP, Request who-has 192.168.2.2 tell 192.168.2.5, length 46 16:57:44.654321 ARP, Request who-has 192.168.2.2 tell 192.168.2.5, length 46 16:57.48.932198 snap 0:0:c:20:0 CDP v2, ttl: 180s, checksum: 692 (unverified) Device-ID (0x01), length: 25 bytes: 'WCCP01.example.com' 16:57:50.927298 IP 192.168.2.2.2048 > 192.168.2.1.2048: UDP, length 144 16:57:50.957309 IP 192.168.2.1.2048 > 192.168.2.2.2048: UDP, length 140
The next steps would be checking the path the traffic takes and the WCCP redirection access-lists.
If the output shows traffic coming from one side, as in only WAN side traffic to port 80 or only LAN side traffic from port 80, then the redirect lists on either the LAN side VLANs or the WAN side interfaces is incorrect.
Figure 5.72. Tcpdump shows that the traffic is only forwarded from the server to the client
SH # tcpdump -ni wan0_0 port 80 tcpdump: WARNING: wan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 96 bytes 12:07:09.598157 IP 192.168.1.1.80 > 10.0.1.1.42825: Flags [S.], seq 2971872340, ack 387224 \ 0794, win 5792, options [mss 1460,sackOK,TS val 285084142 ecr 5351449,nop,wsc ale 2], length 0 12:07:09.602393 IP 192.168.1.1.80 > 10.0.1.1.42825: Flags [.], seq 1, ack 188, win 1716, o \ ptions [nop,nop,TS val 285084146 ecr 5351589], length 0 12:07:09.875867 IP 192.168.1.1.80 > 10.0.1.1.42825: Flags [P.], seq 1:1151, ack 188, win 1 \ 716, options [nop,nop,TS val 285084420 ecr 5351589], length 1150 12:07:10.881392 IP 192.168.1.6.80 > 10.0.1.100.42825: Flags [.], seq 1151, ack 420, win 17 \ 16, options [nop,nop,TS val 285085425 ecr 5352869], length 0 12:07:11.106812 IP 192.168.1.6.80 > 10.0.1.100.42825: Flags [P.], seq 1151:1663, ack 420, \ win 1716, options [nop,nop,TS val 285085651 ecr 5352869], length 512
The next steps would be to confirm that the forward traffic is going via the WCCP router and to check the redirection access-lists.