6.6. Working with Web Cache Communication Protocol (WCCP)¶
6.6.1. What it is¶
Web Cache Communication Protocol (WCCP) is a Cisco-developed content routing protocol that provides a mechanism to redirect traffic flows in real time. It has built-in load balancing, scaling, fault tolerance, and service assurance (failsafe) mechanisms. Cisco IOS Release 12.1 and later releases allow using either Version 1 (WCCPv1) or Version 2 (WCCPv2) of the protocol.
Essentially, WCCP allows an SSL Orchestrator solution to be deployed in a one-armed deployment configuration. The Cisco router can intercept outbound traffic and redirect to SSL Orchestrator, which does not need to be in the network path.
Figure 100: WCCP-based SSL Orchestrator One-Armed Configuration¶
6.6.2. How to build it¶
Please reference the following for additional details on setting up WCCP:
Configuration starts with registering the BIG-IP with the WCCP router. The service group number must match on both sides. For this example we use a service group number of 90:
modify net wccp wccpsg { services add {90{ hash-fields {src-ip} port-type dest ports add { 443 } redirection-method l2 return-method l2 routers add { 192.168.8.128 } tunnel-local-address 192.168.8.105 tunnel-remote-addresses add { 192.168.8.128 } } } }
The most important thing is that the service group number matches. In this case, we use 90. On the Cisco router, configure the same:
ip wccp 90 redirect-list wccp-redirect
!
interface GigabitEthernet1
ip address dhcp
no ip redirects
ip wccp 90 redirect in
negotiation auto
!
interface GigabitEthernet2
ip address dhcp
negotiation auto
!
interface GigabitEthernet3
ip address 192.168.1.209 255.255.255.0
no ip redirects
negotiation auto
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
ip access-list extended wccp-redirect
10 permit tcp any any eq www
20 permit tcp any any eq 443
30 deny ip any any
!
ip access-list extended 110
10 permit ip 192.168.1.0 0.0.0.255 any
20 deny ip any any
ip access-list extended 120
10 permit ip any any
ip access-list extended 130
10 deny ip any 10.0.0.0 0.255.255.255
20 deny ip any 172.16.0.0 0.15.255.255
30 deny ip any 192.168.0.0 0.0.255.255
40 permit ip any any
!
end
Verifying on the Cisco router:
router#sh ip wccp
Global WCCP information:
Router information:
Router Identifier: 192.168.153.128
Service Identifier: 90
Protocol Version: 2.00
Number of Service Group Clients: 1
Number of Service Group Routers: 1
Total Packets Redirected: 34390
Process: 0
CEF: 0
Platform: 34390
Service mode: Open
Service Access-list: -none-
Total Packets Dropped Closed: 0
Redirect access-list: wccp-redirect
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total GRE Bypassed Packets Received: 0
Process: 0
CEF: 0
Platform: 0
Validating which client is registered:
router#sh ip wccp 90 clients
WCCP Client information:
WCCP Client ID: 192.168.8.105
Protocol Version: 2.00
State: Usable
Redirection: L2
Packet Return: L2
Assignment: HASH
Connect Time: 03:23:47
Redirected Packets:
Process: 0
CEF: 0
Platform: 35918
GRE Bypassed Packets:
Process: 0
CEF: 0
Hash Allotment: 256 of 256 (100.00%)
A quick note on High Availability (HA):
The tunnel-local-address IP addresses on the peer BIG-IPs are actual tunnel addresses, so cannot use a single floating IP. Peering is done between each BIG-IP device independently, therefore only the active device will register. When a failover event happens, the newly active device will register and the inactive device will drop out. This will incur a very short delay in picking up the new device path.
To test failover on the BIG-IP, issue a failover command:
root@(bip1)(cfg-sync In Sync)(Active)(/Common)(tmos)# run sys failover standby
And then verify on the router:
router#sh ip wccp 90 clients
WCCP Client information:
WCCP Client ID: 192.168.8.59
Protocol Version: 2.00
State: Usable
Redirection: L2
Packet Return: L2
Assignment: HASH
Connect Time: 00:03:26
Redirected Packets:
Process: 0
CEF: 0
Platform: 6522
GRE Bypassed Packets:
Process: 0
CEF: 0
Hash Allotment: 256 of 256 (100.00%)
Activity on the newly active device:
tail -f /var/log/wccpd.log
<13> Mar 27 11:56:27 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You
<13> Mar 27 11:56:29 bip1.local notice wccpd-1[17bb:f59af340] WccpApp.cpp:208 : Failover status active 0
<13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] WccpApp.cpp:208 : Failover status active 1
<13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:503 : <<< Got: Removal Query !
<13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0
<13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You
<13> Mar 27 12:22:38 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0
<13> Mar 27 12:22:38 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You
<13> Mar 27 12:22:39 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0
And on the newly standby device:
tail -f /var/log/wccpd.log
<13> Mar 27 11:56:07 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You
<13> Mar 27 11:56:17 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0
<13> Mar 27 11:56:17 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You
<13> Mar 27 11:56:27 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0
<13> Mar 27 11:56:27 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You
<13> Mar 27 11:56:29 bip1.local notice wccpd-1[17bb:f59af340] WccpApp.cpp:208 : Failover status active 0