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:
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:
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:
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
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 -
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: