VRF aware WCCP – running WCCP services in a VRF environment.

The following is a config. scenario where you can deploy wccp in a vrf environment on a couple of Cisco ASRs.  I am using ASR1000 series running on the following IOS code: asr1000rp1-adventerprisek9.03.03.00.S.151-2.S.bin

Few Cisco platforms and IOS code truly suppor vrf aware IP services, I’ve come across lot of hair-pulling moments while trying to deploy various IP services on vrf. In this setup we are using VRF-Lite to run wccp.
There are advantages in in running wccp on a vrf – You can isolate which users you want to serve from the web cache engines. This is particularly useful if you have environment where there are multiple services provided by a single router.

Say for example, you have a group of customers (Group-A & Group-B). You want to cache all HTTP traffic of Group-B users while let Group-A users bypass the cache engine altogether.

This can also work in an environment where you want to serve different VPN customers from different cache engines in an MPLS cloud, you can thus achieve different levels of QoS per VPN as well. I will be using the following setup:

 

The blue colored links represent the VRF, notice the interfaces attached to the vrf, while the orange links are interface in the global route table of the routers.

The cache engine is a generic cache that supports wccp ver 2.0. You could even use a squid box configure for wccp. The configuration of the cache engine will not be covered in here. You have to make sure that the cache engine can speak wccp with the ASRs.

Note, that for this configuration I am using rfc 1918 addresses, for a production environment you’d use the respective addresses accordingly :)

Notice from the diagram, the g0/0/0.11 on the ASRs are on the same VLAN as the cache engines. The g0/0/0.12 on the ASRs are on the same VLAN as their nexthop – gateway routers. These four interfaces will be on the same VRF. The gateway routers and the cache engine need not be aware of the VRFs, rather they will be on their respective VLANs and IP prefixes.

Ok, enough of that, now for the fun part, lets get onto the routers and start configuring … first we create the the VRF and then assign interfaces to them accordingly:


ASR-1(config)#vrf definition VRF_CACHE ASR-1(config-vrf)#description CACHE VRF ASR-1(config-vrf)#rd 65500:11 ASR-1(config-vrf)#address-family ipv4 ASR-1(config-vrf-af)#route-target both 65500:11 ASR-1(config-vrf)#address-family ipv6 ASR-1(config-vrf-af)#route-target both 65500:11

Same steps will be carried out on the ASR-2 to create the VRF. Once the VRF is created the IP interfaces are configured:

IP interface on ASR-1:


interface GigabitEthernet0/0/0.11
vrf forwarding VRF_CACHE
encapsulation dot1Q 11
ip address 172.16.30.1 255.255.255.0

On ASR-2 like-wise, repeat the same steps to configure interface and assign ip addr and bind to the vrf.
Now we have the IP interfaces created on both the routers and they are attached to the VRF, we can now test if connectivity is ok between the two routers in the VRF.

ASR-1#show ip vrf brief
Name          Default RD          Interfaces
Mgmt-intf                            Gi0
VRF_CACHE     65500:11              Gi0/0/0.11


ASR-1#ping vrf VRF_CACHE 172.16.30.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.30.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms

The following routes are necessary on the ASRs for them to communicate to the upstream:


ASR-1
ip route vrf VRF_CACHE 0.0.0.0 0.0.0.0 192.168.0.254
ip route 0.0.0.0 0.0.0.0 10.0.100.254
ASR-2
ip route vrf VRF_CACHE 0.0.0.0 0.0.0.0 192.168.0.253
ip route vrf 0.0.0.0 0.0.0.0 10.0.100.253

All good, now we have connetivity between the routers, and the cache engine too (172.16.30.100). Now we create the WCCP groups.

ASR-1(config)# ip wccp ver 2
ASR-1(config)#ip wccp vrf VRF_CACHE source-interface GigabitEthernet0/0/0.11

Notice the source-interface option, this is necessary if you want wccp to speak on the vrf.

Now we create the respective wccp groups. We are creating two groups; one for the incoming traffic and one for the outgoing traffic


ASR-1(config)#ip wccp vrf VRF_CACHE 10 ! inbound wccp group
ASR-1(config)#ip wccp vrf VRF_CACHE 15 ! outbound wccp group

The same configurations will be repeated in the second ASR. At this stage it is possible to see if wccp is properly negotiating and connecting with the cache engine. A quick debug can reveal the I See You messages confirming connectivity.

ASR-1#
Feb 13 12:52:04: WCCP-PKT:D10(VRF_CACHE): Sending ISY to 172.16.30.100, rcv_id:181098
Feb 13 12:52:04: WCCP-PKT:D15(VRF_CACHE): Sending ISY to 172.16.30.100, rcv_id:181186

Note, though I have not included any configuration for the cache engine::: the nexthop of the cache engine will be the VRF interface of the ASR-1 (the ip on g0/0/0.11). This could be an a potential failure point; what if ASR-1 goes offline, the cache engine will not be able to reach beyond the VRF. We can address this by creating a virtual IP either via HSRP or GLBP and have that IP addr as the nexhop of the cache engine.

The ASRs can reach beyond the VRF via the gateway routers. A default route will be statically configured for this. We could also use a dynamic routing protocol like OSPF and form adjacency with the upstream.

Since wccp is now negotiated, we can now redirect user traffic to the cache engines. Recall from the diagram the interface facing the nexthop (gateway routers) on the ASRs – redirection will be performed on this interface -GigabitEthernet0/0/0.12

The following two lines will be added to this interface on both the ASRs to enable the redirection:


ip wccp vrf VRF_CACHE 10 redirect in
ip wccp vrf VRF_CACHE 15 redirect out

Notice the vrf in the command.

That completes the configuration. Now you can put users on this vrf and their traffic will be redirected to the cache engine accordingly. As par the diagram, users in Group-A (prefix 192.168.1.0/24) will be redirected to the cache engine, while Group-B users (prefix 10.0.200.0/24) will be routed globally on the ASRs and will never hit the WCCP redirection rules thus bypassing the cache.

Hope you enjoyed reading this guide; its always fun to configure services using VRFs. There are very few updated documentation on using vrf in these scenarios.

Some useful reference documentation:

Cisco IOS XE 3S configuration guides.

This entry was posted in ASR, Cisco, Technology, VRF, WCCP and tagged , , , , , . Bookmark the permalink.

13 Responses to VRF aware WCCP – running WCCP services in a VRF environment.

  1. Baine says:

    thanks good infoormation.

  2. •Multicast—A single multicast address is configured on each cache engine. In the multicast address method, the cache engine sends a single-address notification that provides coverage for all routers in the service group. For example, a cache engine could indicate that packets should be sent to a multicast address of 224.0.0.100, which would send a multicast packet to all routers in the service group configured for group listening using WCCP (see the ip wccp group-listen interface configuration command for details).

  3. Using the ip wccp web-cache password command, you can set a password for a router and the content engines in a service group. MD5 password security requires that each router and content engine that wants to join a service group be configured with the service group password. The password can consist of up to eight characters. Each content engine or router in the service group will authenticate the security component in a received WCCP packet immediately after validating the WCCP message header. Packets failing authentication will be discarded.

  4. •redirect-list—Configures a global WCCPv2 redirection list for the service group to control the traffic that is redirected to the cache engine.

  5. thank you guy for the response, i configured the filter and the instance, but how do i apply and specify it on the interface that is connected to the cache engine!! what is the commands plz.

    • sigey says:

      Hi Jeanie,
      Did you mean how to apply the wccp config for the interface facing the caches?

      You need to go into the interface that is facing the caching and apply the following bit there

      ip wccp vrf VRF_CACHE 10 redirect in
      ip wccp vrf VRF_CACHE 15 redirect out

  6. sigey says:

    Hi Jeanie,
    Did you mean how to apply the wccp config for the interface facing the caches?

    You need to go into the interface that is facing the caching and apply the following bit there

    ip wccp vrf VRF_CACHE 10 redirect in
    ip wccp vrf VRF_CACHE 15 redirect out

  7. Get Smart says:

    thank you guy for the response, i configured the filter and the instance, but how do i apply and specify it on the interface that is connected to the cache engine!! what is the commands plz.

  8. Using the ip wccp web-cache password command, you can set a password for a router and the content engines in a service group. MD5 password security requires that each router and content engine that wants to join a service group be configured with the service group password. The password can consist of up to eight characters. Each content engine or router in the service group will authenticate the security component in a received WCCP packet immediately after validating the WCCP message header. Packets failing authentication will be discarded.

  9. The IP address of the cache engine if its IP address is not the same as the IP address of a FortiGate interface. If the IP address of the cache engine is the same as the IP address of the FortiGate interface on which you have enabled WCCP, the cache-id should be 0.0.0.0.

  10. get smart says:

    The Barracuda Web Filter 410 and above can be deployed as a WCCP cache engine on a network with a WCCP capable core routing platform. Because the WCCP control router or switch transparently redirects content requests, you don’t need to configure end users’ browsers to use the Barracuda Web Filter as an HTTP proxy. Note the two different deployment diagrams for filtering HTTP traffic only versus filtering both HTTP and HTTPS traffic. Note: HTTPS support requires running version 6.0.1 or higher.

  11. Issue the ip wccp web-cache redirect out command on the interface going toward the Internet.

  12. Bobbie Glass says:

    This tells the router that it should accept WCCP registration requests that use mypassword as the password. It also tells the WCCP cache engine which routers are running WCCP and registers the cache with the router.

Leave a Reply