Configuring WCCP
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contents
Configuring WCCPLast Updated: October 15, 2012
The Web Cache Communication Protocol (WCCP) is a Cisco-developed content-routing technology that intercepts IP packets and redirects those packets to a destination other than that specified in the IP packet. Typically the packets are redirected from their destination web server on the Internet to a content engine that is local to the client. In some WCCP deployment scenarios, redirection of traffic may also be required from the web server to the client. WCCP enables you to integrate content engines into your network infrastructure. Cisco IOS Release 12.1 and later releases allow the use of either WCCP Version 1 (WCCPv1) or Version 2 (WCCPv2). The tasks in this document assume that you have already configured content engines on your network. For specific information on hardware and network planning associated with Cisco Content Engines and WCCP, see the Cisco Content Engines documentation at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/webscale/content/index.htm Finding Feature InformationYour software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Prerequisites for WCCP
Restrictions for WCCPWCCPv2The following limitations apply to WCCPv2:
WCCP VRF SupportIn Cisco IOS Release 12.2(33)SRE, this feature is supported only on Cisco 7200 NPE-G2 and Cisco 7304-NPE-G100 routers. This feature is supported in Cisco IOS Release 12.2(50)SY on Catalyst 6000 series switches with a PFC4. Layer 2 Forwarding and ReturnThe following limitations apply to WCCP Layer 2 Forwarding and Return:
Cisco Catalyst 4500 Series SwitchesThe following limitations apply to Cisco Catalyst 4500 series switches:
Cisco Catalyst 6500 Series SwitchesThe following limitation apply to Cisco Catalyst 6500 series switches:
Catalyst 6500 Series Switches and Cisco 7600 Series Routers Access Control ListsWhen WCCP is using the mask assignment, any redirect list is merged with the mask information from the appliance and the resulting merged ACL is passed down to the Catalyst 6500 series switch or Cisco 7600 series router hardware. Only Permit or Deny ACL entries from the redirect list in which the protocol is IP or exactly matches the service group protocol are merged with the mask information from the appliance. The following restrictions apply to the redirect-list ACL:
If the redirect ACL does not meet the restrictions shown, the system will log the following error message: WCCP-3-BADACE: Service <service group>, invalid access-list entry (seq:<sequence>, reason:<reason>) WCCP continues to redirect packets, but the redirection is carried out in software (NetFlow Switching) until the access list is adjusted. Information About WCCP
WCCP OverviewWCCP uses Cisco Content Engines (or other content engines running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time. WCCP enables Cisco IOS XE routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users need not configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a content engine. The word "transparent" in this case means that the end user does not know that a requested file (such as a web page) came from the content engine instead of from the originally specified server. A content engine receiving a request attempts to service it from its own local cache. If the requested information is not present, the content engine issues its own request to the originally targeted server to get the required information. A content engine retrieving the requested information forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs. WCCP enables a series of content engines, called a content engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their content engines to manage heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cluster member to work in parallel, resulting in linear scalability. Clustering content engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 content engines to scale to your desired capacity. Layer 2 Forwarding Redirection and ReturnWCCP uses either generic routing encapsulation (GRE) or Layer 2 (L2) to redirect or return IP traffic. When WCCP forwards traffic via GRE, the redirected packets are encapsulated within a GRE header. The packets also have a WCCP redirect header. When WCCP forwards traffic using L2, the original MAC header of the IP packet is overwritten and replaced with the MAC header for the WCCP client. Using L2 as a forwarding method allows direct forwarding to the content engine without further lookup. Layer 2 redirection requires that the router and content engines are directly connected, that is, on the same IP subnetwork. When WCCP returns traffic via GRE, the returned packets are encapsulated within a GRE header. The destination IP address is the address of the router and the source address is the address of the WCCP client. When WCCP returns traffic via L2, the original IP packet is returned without any added header information. The router to which the packet is returned will recognize the source of the packet and prevent redirection. The WCCP redirection method does not have to match the return method. L2 forwarding, return, or redirection are typically used for hardware accelerated platforms. Depending on your release, L2 forwarding, return, and redirection can also be used for software switching platforms. For content engines running Application and Content Networking System (ACNS) software, use the wccp custom-web-cache command with the l2-redirect keyword to configure L2 redirection. For content engines running Cisco Wide Area Application Services (WAAS) software, use the wccp tcp-promiscuous command with the l2-redirect keyword to configure L2 redirection. For information about Cisco ACNS commands used to configure Cisco Content Engines, see the Cisco ACNS Software Command Reference. For more information about WAAS commands used to configure Cisco Content Engines, see the Cisco Wide Area Application Services Command Reference. WCCP Mask AssignmentThe WCCP Mask Assignment feature enables mask assignment as the load-balancing method (instead of the default hash assignment method) for a WCCP service. For content engines running Application and Content Networking System (ACNS) software, use the wccp custom-web-cache command with the mask-assign keyword to configure mask assignment. For content engines running Cisco Wide Area Application Services (WAAS) software, use the wccp tcp-promiscuous command with the mask-assign keyword to configure mask assignment. For information about Cisco ACNS commands used to configure Cisco Content Engines, see the Cisco ACNS Software Command Reference. For more information about WAAS commands used to configure Cisco Content Engines, see the Cisco Wide Area Application Services Command Reference. Hardware AccelerationCatalyst 6500 series switches and Cisco 7600 series routers provide WCCP Layer 2 Policy Feature Card (PFC) redirection hardware acceleration. Hardware acceleration allows Cisco Content Engines to perform a L2 MAC address rewrite redirection method when directly connected to a compatible switch or router. Redirection processing is accelerated in the switching or routing hardware, which is more efficient than L3 redirection with Generic Routing Encapsulation (GRE). L2 redirection takes place on the switch or router, and is not visible to the Multilayer Switch Feature Card (MSFC). The WCCP L2 PFC redirection feature requires no configuration on the MSFC. The show ip wccp {service-number | web-cache} detail command displays which redirection method is in use for each content engine. In order for the router or switch to make complete use of hardware redirection, the content engine must be configured with L2 redirection and mask assignment. Use the ip wccp web-cache accelerated command on hardware-based platforms to enforce the use of L2 redirection and mask assignment. Using this command configures the router to form a service group and redirect packets with an appliance only if the appliance is configured for L2 and mask assignment. The following guidelines apply to WCCP Layer 2 PFC redirection:
WCCPv1 ConfigurationWith WCCPv1, only a single router services a cluster. In this scenario, this router is the device that performs all the IP packet redirection. The figure below illustrates the WCCPv1 configuration. Content is not duplicated on the content engines. The benefit of using multiple content engines is that you can scale a caching solution by clustering multiple physical content engines to appear as one logical cache. The following sequence of events details how WCCPv1 configuration works:
WCCPv2 ConfigurationMultiple routers can use WCCPv2 to service a content engine cluster. In WCCPv1, only one router could redirect content requests to a cluster. The figure below illustrates a sample configuration using multiple routers. The subset of content engines within a cluster and routers connected to the cluster that are running the same service is known as a service group. Available services include TCP and UDP redirection. In WCCPv1, the content engines were configured with the address of the single router. WCCPv2 requires that each content engine be aware of all the routers in the service group. To specify the addresses of all the routers in a service group, you must choose one of the following methods:
The multicast option is easier to configure because you need only specify a single address on each content engine. This option also allows you to add and remove routers from a service group dynamically, without needing to reconfigure the content engines with a different list of addresses each time. The following sequence of events details how WCCPv2 configuration works:
WCCPv2 Support for Services Other Than HTTPWCCPv2 allows redirection of traffic other than HTTP (TCP port 80 traffic), including a variety of UDP and TCP traffic. WCCPv1 supported the redirection of HTTP (TCP port 80) traffic only. WCCPv2 supports the redirection of packets intended for other ports, including those used for proxy-web cache handling, File Transfer Protocol (FTP) caching, FTP proxy handling, web caching for ports other than 80, and Real Audio, video, and telephony applications. To accommodate the various types of services available, WCCPv2 introduced the concept of multiple service groups. Service information is specified in the WCCP configuration commands using dynamic services identification numbers (such as 98) or a predefined service keyword (such as web-cache). This information is used to validate that service group members are all using or providing the same service. The content engines in a service group specify traffic to be redirected by protocol (TCP or UDP) and up to eight source or destination ports. Each service group has a priority status assigned to it. The priority of a dynamic service is assigned by the content engine. The priority value is in the range of 0 to 255 where 0 is the lowest priority. The predefined web-cache service has an assigned priority of 240. WCCPv2 Support for Multiple RoutersWCCPv2 allows multiple routers to be attached to a cluster of cache engines. The use of multiple routers in a service group allows for redundancy, interface aggregation, and distribution of the redirection load. WCCPv2 supports up to 32 routers per service group. Each service group is established and maintained independently. WCCPv2 MD5 SecurityWCCPv2 provides optional authentication that enables you to control which routers and content engines become part of the service group using passwords and the Hashed Message Authentication Code--Message Digest (HMAC MD5) standard. Shared-secret MD5 one-time authentication (set using the ip wccp [password [0 | 7] password] global configuration command) enables messages to be protected against interception, inspection, and replay. WCCPv2 Web Cache Packet ReturnIf a content engine is unable to provide a requested object it has cached due to error or overload, the content engine will return the request to the router for onward transmission to the originally specified destination server. WCCPv2 provides a check on packets that determines which requests have been returned from the content engine unserviced. Using this information, the router can then forward the request to the originally targeted server (rather than attempting to resend the request to the content engine cluster). This process provides error handling transparency to clients. Typical reasons why a content engine would reject packets and initiate the packet return feature include the following: WCCPv2 Load DistributionWCCPv2 can be used to adjust the load being offered to individual content engines to provide an effective use of the available resources while helping to ensure high quality of service (QoS) to the clients. WCCPv2 allows the designated content engine to adjust the load on a particular content engine and balance the load across the content engines in a cluster. WCCPv2 uses three techniques to perform load distribution:
The use of these hashing parameters prevents one content engine from being overloaded and reduces the potential for bottlenecking. WCCP Mask AssignmentThe WCCP Mask Assignment feature enables mask assignment as the load-balancing method (instead of the default hash assignment method) for a WCCP service. For content engines running Application and Content Networking System (ACNS) software, use the wccp custom-web-cache command with the mask-assign keyword to configure mask assignment. For content engines running Cisco Wide Area Application Services (WAAS) software, use the wccp tcp-promiscuous command with the mask-assign keyword to configure mask assignment. For information about Cisco ACNS commands used to configure Cisco Content Engines, see the Cisco ACNS Software Command Reference. For more information about WAAS commands used to configure Cisco Content Engines, see the Cisco Wide Area Application Services Command Reference. WCCP VRF SupportThe WCCP VRF Support feature enhances the WCCPv2 protocol by implementing support for virtual routing and forwarding (VRF). The WCCP VRF Support feature allows service groups to be configured on a per-VRF basis in addition to those defined globally. Along with the service identifier, the VRF of WCCP protocol packets arriving at the router is used to associate cache-engines with a configured service group. The same VRF must have the interface on which redirection is applied, the interface which is connected to cache engine, and the interface on which the packet would have left if it had not been redirected. WCCP VRF Tunnel InterfacesIn Cisco IOS releases that support the WCCP VRF Support feature, the use of GRE redirection results in the creation of new tunnel interfaces. You can display these tunnel interfaces by entering the show ip interface brief | include tunnel command:
Device# show ip interface brief | include tunnel
Tunnel0 172.16.0.1 YES unset up up
Tunnel1 172.16.0.1 YES unset up up
Tunnel2 172.16.0.1 YES unset up up
Tunnel3 172.16.0.1 YES unset up up
Device#
The tunnel interfaces are automatically created in order to process outgoing GRE-encapsulated traffic for WCCP. The tunnel interfaces appear when a content engine connects and requests GRE redirection. The tunnel interfaces are not created directly by WCCP, but are created indirectly via a tunnel application programming interface (API). WCCP does not have direct knowledge of the tunnel interfaces, but can redirect packets to them, resulting in the appropriate encapsulation being applied to the packets. After the appropriate encapsulation is applied, the packet is then sent to the content engine.
One tunnel is created for each service group that is using GRE redirection. One additional tunnel is created to provide an IP address that allows the other tunnel group interfaces to be unnumbered but still enabled for IPv4. You can confirm the connection between the tunnels and WCCP by entering the show tunnel groups wccp command:
Device# show tunnel groups wccp
WCCP : service group 0 in "Default", ver v2, assgnmnt: hash-table
intf: Tunnel0, locally sourced
WCCP : service group 317 in "Default", ver v2, assgnmnt: hash-table
intf: Tunnel3, locally sourced
WCCP : service group 318 in "Default", ver v2, assgnmnt: hash-table
intf: Tunnel2, locally sourced
You can display additional information about each tunnel interface by entering the show tunnel interface interface-number command: Device# show tunnel interface t0 Tunnel0 Mode:multi-GRE/IP, Destination UNKNOWN, Source 10.1.1.80 Application ID 2: WCCP : service group 0 in "Default", ver v2, assgnmnt: hash-table Linestate - current up Internal linestate - current up, evaluated up Device# show tunnel interface t1 Tunnel1 Mode:multi-GRE/IP, Destination UNKNOWN, Source 172.16.0.1 Application ID 2: unspecified Linestate - current up Internal linestate - current up, evaluated up Device# show tunnel interface t2 Tunnel2 Mode:multi-GRE/IP, Destination UNKNOWN, Source 10.1.1.80 Application ID 2: WCCP : service group 318 in "Default", ver v2, assgnmnt: hash-table Linestate - current up Internal linestate - current up, evaluated up Device# show tunnel interface t3 Tunnel3 Mode:multi-GRE/IP, Destination UNKNOWN, Source 10.1.1.80 Application ID 2: WCCP : service group 317 in "Default", ver v2, assgnmnt: hash-table Linestate - current up Internal linestate - current up, evaluated up Device# Note that the service group number shown in the examples is the internal tunnel representation of the WCCP service group number. Group 0 is the web-cache service. To determine the dynamic services, subtract 256 from the displayed service group number to convert to the WCCP service group number. For interfaces that are used for redirection, the source address shown is the WCCP router ID. You can display information about the connected content engines and encapsulation, including software packet counters, by entering the show adjacency [tunnel-interface] [encapsulation] [detail] [internal] command: Device# show adjacency t0 Protocol Interface Address IP Tunnel0 10.1.1.82(3) Device# show adjacency t0 encapsulation Protocol Interface Address IP Tunnel0 10.1.1.82(3) Encap length 28 4500000000000000FF2F7D2B1E010150 1E0101520000883E00000000 Provider: TUNNEL Protocol header count in macstring: 3 HDR 0: ipv4 dst: static, 10.1.1.82 src: static, 10.1.1.80 prot: static, 47 ttl: static, 255 df: static, cleared per packet fields: tos ident tl chksm HDR 1: gre prot: static, 0x883E per packet fields: none HDR 2: wccpv2 dyn: static, cleared sgID: static, 0 per packet fields: alt altB priB Device# show adjacency t0 detail Protocol Interface Address IP Tunnel0 10.1.1.82(3) connectionid 1 0 packets, 0 bytes epoch 0 sourced in sev-epoch 1 Encap length 28 4500000000000000FF2F7D2B1E010150 1E0101520000883E00000000 Tun endpt Next chain element: IP adj out of Ethernet0/0, addr 10.1.1.82 Device# show adjacency t0 internal Protocol Interface Address IP Tunnel0 10.1.1.82(3) connectionid 1 0 packets, 0 bytes epoch 0 sourced in sev-epoch 1 Encap length 28 4500000000000000FF2F7D2B1E010150 1E0101520000883E00000000 Tun endpt Next chain element: IP adj out of Ethernet0/0, addr 10.1.1.82 parent oce 0x4BC76A8 frame originated locally (Null0) L3 mtu 17856 Flags (0x2808C4) Fixup enabled (0x40000000) GRE WCCP redirection HWIDB/IDB pointers 0x55A13E0/0x35F5A80 IP redirect disabled Switching vector: IPv4 midchain adj oce IP Tunnel stack to 10.1.1.82 in Default (0x0) nh tracking enabled: 10.1.1.82/32 IP adj out of Ethernet0/0, addr 10.1.1.82 Adjacency pointer 0x4BC74D8 Next-hop 10.1.1.82 Device# WCCP Bypass PacketsWCCP intercepts IP packets and redirects those packets to a destination other than the destination that is specified in the IP header. Typically the packets are redirected from a web server on the Internet to a web cache that is local to the destination. Occasionally a web cache cannot manage the redirected packets appropriately and returns the packets unchanged to the originating router. These packets are called bypass packets and are returned to the originating router using either Layer 2 forwarding without encapsulation (L2) or encapsulated in generic routing encapsulation (GRE). The router decapsulates and forwards the packets normally. The VRF associated with the ingress interface (or the global table if there is no VRF associated) is used to route the packet to the destination. GRE is a tunneling protocol developed by Cisco that encapsulates packet types from a variety of protocols inside IP tunnels, creating a virtual point-to-point link over an IP network. WCCP Closed Services and Open ServicesIn applications where packets are intercepted and redirected by a Cisco IOS router to external WCCP client devices, it may be necessary to block the packets for the application when a WCCP client device is not available. This blocking is achieved by configuring a WCCP closed service. When a WCCP service is configured as closed, WCCP discards packets that do not have a WCCP client registered to receive the redirected traffic. By default, WCCP operates as an open service, wherein communication between clients and servers proceeds normally in the absence of an intermediary device. The ip wccp service-list or the ipv6 wccp service-list command can be used only for closed-mode services. Use the service-list keyword and service-access-list argument to register an application protocol type or port number. When there is a mismatch between the service list ACL and the definition received from a cache engine, the service is not allowed to start. WCCP Service GroupsWCCP is a component of Cisco IOS software that redirects traffic with defined characteristics from its original destination to an alternative destination. The typical application of WCCP is to redirect traffic bound for a remote web server to a local web cache to improve response time and optimize network resource usage. The nature of the selected traffic for redirection is defined by service groups (see figure below) specified on content engines and communicated to routers by using WCCP. The maximum number of service groups allowed across all VRFs is 256. WCCPv2 supports up to 32 routers per service group. Each service group is established and maintained independently. WCCPv2 uses service groups based on logical redirection services, deployed for intercepting and redirecting traffic. The standard service is web cache, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the content engines. This service is referred to as a well-known service, because the characteristics of the web cache service are known by both the router and content engines. A description of a well-known service is not required beyond a service identification. To specify the standard web cache service, use the ip wccp or the ipv6 wccp command with the web-cache keyword.
The dynamic services are defined by the content engines; the content engine instructs the router which protocol or ports to intercept, and how to distribute the traffic. The router itself does not have information on the characteristics of the dynamic service group's traffic, because this information is provided by the first content engine to join the group. In a dynamic service, up to eight ports can be specified within a single protocol. Cisco Content Engines, for example, use dynamic service 99 to specify a reverse-proxy service. However, other content engine devices may use this service number for some other service. WCCP--Check All ServicesAn interface may be configured with more than one WCCP service. When more than one WCCP service is configured on an interface, the precedence of a service depends on the relative priority of the service compared to the priority of the other configured services. Each WCCP service has a priority value as part of its definition. When an interface is configured with more than one WCCP service, the precedence of the packets is matched against service groups in priority order.
With the ip wccp check services all or the ipv6 wccp check services all command, WCCP can be configured to check all configured services for a match and perform redirection for those services if appropriate. The caches to which packets are redirected can be controlled by a redirect ACL and by the service priority. If no WCCP services are configured with a redirect ACL, the services are considered in priority order until a service is found that matches the IP packet. If no services match the packet, the packet is not redirected. If a service matches the packet and the service has a redirect ACL configured, then the IP packet will be checked against the ACL. If the packet is rejected by the ACL, the packet will not be passed down to lower priority services unless the ip wccp check services all or the ipv6 wccp check services all command is configured. When the ip wccp check services all or the ipv6 wccp check services all command is configured, WCCP will continue to attempt to match the packet against any remaining lower priority services configured on the interface. WCCP Interoperability with NATTo redirect traffic using WCCP to a router running WAAS software that is also configured with NAT, enable the ip nat inside or the ipv6 nat inside command on the WAAS interface. If you are not able to configure the ip nat inside or theipv6 nat inside command on the WAAS interface, disable Cisco Express Forwarding. You must also update the WCCP redirect ACL to include a private address to ensure that pretranslated traffic is redirected. WCCP Troubleshooting TipsCPU usage may be very high when WCCP is enabled. The WCCP counters enable a determination of the bypass traffic directly on the router and can indicate whether the cause is high CPU usage due to enablement of WCCP. In some situations, 10 percent bypass traffic may be normal; in other situations, 10 percent may be high. However, any figure above 25 percent should prompt a closer investigation of what is occurring in the web cache. If the counters suggest that the level of bypass traffic is high, the next step is to examine the bypass counters in the content engine and determine why the content engine is choosing to bypass the traffic. You can log in to the content engine console and use the CLI to investigate further. The counters allow you to determine the percent of traffic being bypassed. How to Configure WCCPThe following configuration tasks assume that you have already installed and configured the content engines you want to include in your network. You must configure the content engines in the cluster before configuring WCCP functionality on your routers or switches. Refer to the Cisco Cache Engine User Guide for content engine configuration and setup tasks.
Configuring Closed ServicesPerform this task to specify the number of service groups for WCCP, to configure a service group as a closed or open service, and to optionally specify a check of all services. DETAILED STEPS Registering a Router to a Multicast AddressIf you decide to use the multicast address option for your service group, you must configure the router to listen for the multicast broadcasts on an interface. For network configurations where redirected traffic needs to traverse an intervening router, the router being traversed must be configured to perform IP multicast routing. You must configure the following two components to enable traversal over an intervening router: DETAILED STEPS
Using Access Lists for a WCCP Service GroupPerform this task to configure the device to use an access list to determine which traffic should be directed to which content engines. DETAILED STEPS
Enabling WCCP Interoperability with NATSUMMARY STEPS
DETAILED STEPS
Verifying and Monitoring WCCP Configuration SettingsSUMMARY STEPS
DETAILED STEPS
Configuration Examples for WCCP
Example: Changing the Version of WCCP on a RouterThe following example shows how to change the WCCP version from the default of WCCPv2 to WCCPv1, and enabling the web-cache service in WCCPv1: Router# show ip wccp % WCCP version 2 is not enabled Router# configure terminal Router(config)# ip wccp version 1 Router(config)# end Router# show ip wccp % WCCP version 1 is not enabled Router# configure terminal Router(config)# ip wccp web-cache Router(config)# end Router# show ip wccp Global WCCP information: Router information: Router Identifier: 10.4.9.8 Protocol Version: 1.0 . . . Example: Configuring a General WCCPv2 SessionDevice# configure terminal Device(config)# ip wccp web-cache group-address 224.1.1.100 password password1 Device(config)# ip wccp source-interface GigabitEthernet 0/1/0 Device(config)# ip wccp check services all Configures a check of all WCCP services. Device(config)# interface GigabitEthernet 0/1/0 Device(config-if)# ip wccp web-cache redirect in Device(config-if)# exit Device(config)# interface GigabitEthernet 0/2/0 Device(config-if)# ip wccp redirect exclude in Device(config-if)# exit Example: Configuring a Web Cache ServiceDevice# configure terminal Device(config)# ip wccp web-cache Device(config)# interface GigabitEthernet 0/1/0 Device(config-if)# ip wccp web-cache redirect in Device(config-if)# exit Device# copy running-config startup-config The following example shows how to configure a session in which redirection of HTTP traffic arriving on Gigabit Ethernet interface 0/1/0 is enabled: Device# configure terminal Device(config)# interface GigabitEthernet 0/1/0 Device(config-if)# ip wccp web-cache redirect in Device(config-if)# exit Device# show ip interface GigabitEthernet 0/1/0 . . . WCCP Redirect inbound is enabled WCCP Redirect exclude is disabled . . . Example: Running a Reverse Proxy ServiceThe following example assumes that you are configuring a service group using Cisco cache engines, which use dynamic service 99 to run a reverse proxy service: Router# configure terminal Router(config)# ip wccp 99 Router(config)# interface gigabitethernet 0/1/0 Router(config-if)# ip wccp 99 redirect out Example: Registering a Router to a Multicast AddressDevice# configure terminal Device(config)# ip wccp web-cache group-address 224.1.1.100 Device(config)# interface gigabitethernet 0/1/0 Device(config-if)# ip wccp web cache group-listen The following example shows a router configured to run a reverse proxy service, using the multicast address of 224.1.1.1. Redirection applies to packets outgoing via Gigabit Ethernet interface 0/1/0: Device# configure terminal Device(config)# ip wccp 99 group-address 224.1.1.1 Device(config)# interface gigabitethernet 0/1/0 Device(config-if)# ip wccp 99 redirect out Example: Using Access ListsTo achieve better security, you can use a standard access list to notify the device which IP addresses are valid addresses for a content engine attempting to register with the current device. The following example shows a standard access list configuration session where the access list number is 10 for some sample hosts: Device(config)# access-list 10 permit host 10.1.1.1 Device(config)# access-list 10 permit host 10.1.1.2 Device(config)# access-list 10 permit host 10.1.1.3 Device(config)# ip wccp web-cache group-list 10 To disable caching for certain clients, servers, or client/server pairs, you can use WCCP access lists. The following example shows that any requests coming from 10.1.1.1 to 10.3.1.1 will bypass the cache, and that all other requests will be serviced normally: Device(config)# ip wccp web-cache redirect-list 120 Device(config)# access-list 120 deny tcp host 10.1.1.1 any Device(config)# access-list 120 deny tcp any host 10.3.1.1 Device(config)# access-list 120 permit ip any any The following example configures a device to redirect web-related packets received via Gigabit Ethernet interface 0/1/0, destined to any host except 209.165.200.224: Device(config)# access-list 100 deny ip any host 209.165.200.224 Device(config)# access-list 100 permit ip any any Device(config)# ip wccp web-cache redirect-list 100 Device(config)# interface gigabitethernet 0/1/0 Device(config-if)# ip wccp web-cache redirect in Example: Enabling WCCP Interoperability with NATRouter(config)# interface ethernet1 ! This is the LAN-facing interface Router(config-if)# ip nat inside Router(config-if)# ip wccp 61 redirect in Router(config-if)# exit Router(config)# interface ethernet2 ! This is the WAN-facing interface Router(config-if)# ip nat outside Router(config-if)# ip wccp 62 redirect in Router(config-if)# exit Router(config)# interface ethernet3 ! This is the WAAS-facing interface Router(config-if)# ip nat inside Router(config-if)# ip wccp redirect exclude in Example: Verifying WCCP SettingsThe following example shows how to verify your configuration changes by using the more system:running-config command in privileged EXEC mode. The following example shows that both the web cache service and dynamic service 99 are enabled on the device:
Device# more system:running-config
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname router4
!
enable secret 5 $1$nSVy$faliJsVQXVPW.KuCxZNTh1
enable password password1
!
ip subnet-zero
ip wccp web-cache
ip wccp 99
ip domain-name cisco.com
ip name-server 10.1.1.1
ip name-server 10.1.1.2
ip name-server 10.1.1.3
!
!
!
interface GigabitEthernet0/1/1
ip address 10.3.1.2 255.255.255.0
no ip directed-broadcast
ip wccp web-cache redirect in
ip wccp 99 redirect in
no ip route-cache
no ip mroute-cache
!
interface GigabitEthernet0/1/0
ip address 10.4.1.1 255.255.255.0
no ip directed-broadcast
ip wccp 99 redirect in
no ip route-cache
no ip mroute-cache
!
interface Serial0
no ip address
no ip directed-broadcast
no ip route-cache
no ip mroute-cache
shutdown
!
interface Serial1
no ip address
no ip directed-broadcast
no ip route-cache
no ip mroute-cache
shutdown
!
ip default-gateway 10.3.1.1
ip classless
ip route 0.0.0.0 0.0.0.0 10.3.1.1
no ip http server
!
!
!
line con 0
transport input none
line aux 0
transport input all
line vty 0 4
password password1
login
!
end
The following example shows how to display global statistics related to WCCP:
Device# show ip wccp web-cache detail
WCCP Client information:
WCCP Client ID: 10.1.1.2
Protocol Version: 2.0
State: Usable
Redirection: L2
Packet Return: L2
Packets Redirected: 0
Connect Time: 00:20:34
Assignment: MASK
Mask SrcAddr DstAddr SrcPort DstPort
---- ------- ------- ------- -------
0000: 0x00000000 0x00001741 0x0000 0x0000
Value SrcAddr DstAddr SrcPort DstPort CE-IP
----- ------- ------- ------- ------- -----
0000: 0x00000000 0x00000000 0x0000 0x0000 0x3C010102 (10.1.1.2)
0001: 0x00000000 0x00000001 0x0000 0x0000 0x3C010102 (10.1.1.2)
0002: 0x00000000 0x00000040 0x0000 0x0000 0x3C010102 (10.1.1.2)
0003: 0x00000000 0x00000041 0x0000 0x0000 0x3C010102 (10.1.1.2)
0004: 0x00000000 0x00000100 0x0000 0x0000 0x3C010102 (10.1.1.2)
0005: 0x00000000 0x00000101 0x0000 0x0000 0x3C010102 (10.1.1.2)
0006: 0x00000000 0x00000140 0x0000 0x0000 0x3C010102 (10.1.1.2)
For more information about the show ip wccp web-cache command, see the Cisco IOS IP Application Services Command Reference. Additional ReferencesRelated Documents
MIBsTechnical Assistance
Feature Information for WCCPThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2012 Cisco Systems, Inc. All rights reserved.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||