Ask the Expert: Setting up and troubleshooting WCCP on IOS

[ciscomoderator]

With Michael Schueler

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn how to setup and troubleshoot WCCP (Web Cache Communication Protocol) on different IOS platforms from Cisco experts Peter Van Eynde and Michael Schueler

Peter Van Eynde is a customer support engineer in the Technical Assistance Center in Belgium, where he supports content technologies including Cisco Wide Area Application Services (WAAS), Cisco Application and Content Networking System (ACNS), and Cisco Content Delivery System Internet Streaming (CDS-IS). He holds CCIE certification #23042 in Security.

Michael Schueler has been a Cisco support engineer in the Cisco Technical Support Assistance team in Germany for more than 5 years. He and is an expert on content technologies including Cisco Wide Area Application Services (WAAS), Cisco Application and Content Networking System (ACNS), Cisco Content Delivery System Internet Streaming (CDS-IS), and Cisco Digital Media Suite (DMS). He holds CCIE certification #23835 in Security.

Remember to use the rating system to let Peter and Michael know if you have received an adequate response.  

They might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Network Infrastructure sub-community "Wide Area Application Services"discussion forum shortly after the event. This event lasts through August,24 2012. Visit this forum often to view responses to your questions and the questions of other community members.

[Sarah Staker]

Hello Peter and Michael,

I am interesting in knowing what are the advantages and disasvatnages of ussing L2 or GRE redirection/ return? Can you provide me with some insight?

Thanks a lot.

Sarah

[Michael Schueler]

Hello Sarah,

L2 redirection/return is usually the preferred method for the following reasons:

• Hardware-accelerated on many platforms (Cisco Catalyst switches, Cisco Nexus 7000 Series, and the Cisco ASR 1000 Series).
• Supported on all Cisco routers since IOS version 12.4(20)T.
• No additional overheard: As only the destination MAC address is modified, no additional space is used per packet.
• Easier troubleshooting, especially in case packet captures are required.

There are some drawback as well, though:

• The WCCP router and the content engine need to be directly connected, i.e. on the same IP subnet (L2 adjacent).
• The content engine needs to be place on a dedicated interface, i.e. it must not be connected to an interface, that has WCCP redirection enabled.

With L2 redirection/return Cisco recommends MASK assignment, as with this every packet is redirected in hardware on hardware-accelerated platforms. When using HASH assignment (not supported on the Nexus 7000 Series and the ASR 1000 Series), the first redirected packet is handled in software, all subsequent packets are handled in hardware.

GRE redirection/return has the following advantages:

• The WCCP router and the content engine do not need to be directly connected, i.e. the content engine can be multiple L3 hops away from the WCCP router.
• Can ensure, that traffic forwarded by the content engine is returned to the same WCCP router, which redirected this particular packet when using either WCCP GRE or Generic GRE as egress method. This can be useful to avoid routing loops caused by WCCP redirection in certain network designs.
• Before IOS version 12.4(20)T this was the only supported method on Cisco routers.

Disadvantages of using GRE redirection/return are the following:

• Causes 28 bytes of overhead (8 bytes GRE header + 20 bytes for the additional IP header), thus reducing amount of data, that can be sent in a single frame.
• GRE return is hardware-accelerated on the Catalyst 6500/7600 Series only when using Generic GRE, which requires manual configuration of the GRE Tunnel interface on the Catalyst side.
• MASK assisgnment - where you can influence the load-balancing algorithm based on the specific MASK you configured - is not recommended with GRE redirection. Instead HASH assignment is usually used with GRE redirection - the hash function is not configurable, though.
• Not supported on all platforms.

Please find a good summary of what methods are supported on what platform here:

http://www.cisco.com/en/US/prod/collateral/contnetw/ps5680/ps6870/white_paper_c11-608042.html

Further information regarding the different methods can be found here:

http://www.cisco.com/en/US/docs/ios/ipapp/configuration/guide/ipapp_wccp.html

http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v441/configuration/guide/traffic.html#wp1041841

Best regards,

Michael

[Sebastian Garcia]

Hello guys,

I noticed that my router showing the "Router Identifier" as "not yet determined" although I have fully configured WCCP in the router. Do you know why this is happening?

Thanks,

- Sebastian

[Michael Schueler]

Hello Sebastian,

Router Identifier showing as "not yet determined" means, that WCCP communication between the router and the content engine have not yet been established. The usual cause for this is, that the router does not receive any WCCP HERE_I_AM messages from the content engine, e.g. because WCCP has not yet been enabled on the content engine, or because of communication issues between the content engine and the router.

The router will only select the Router Identifier once it starts to receive HERE_I_AM messages from a content engine.

Best regards,

Michael

[Ramraj Sivagnanam Sivajanam]

Hi Bro

Can I ask you a question? My client would like to deploy Web Cache WCCP solution and the Web Cache server is situated on a different interface of a Cisco ASA FW, and the LAN users are situated on different interface of a Cisco ASA FW as well. I checked on the Cisco website, it says this design cannot be done as the Web Cache server and the LAN users must belong under the same interface http://www.cisco.com/en/US/docs/security/asa/asa84/configuration85/guide/access_wccp.html#wp1101443

However, if it's URL filtering, the URL filtering server can sit on a different interface of a Cisco ASA FW, and the LAN users on different interface of a Cisco ASA FW. This will work.

What's the difference between a Web Cache and a URL filtering? How come one solution doesn’t allow the server and the user to be on a separate interface, while another does. I thought both these solutions are the same thing. Please kindly elaborate. Sorry if I'm asking a silly question.

[pevaneyn]

Hi,

This is because URL filtering and WCCP redirection are different beasts.

URL filtering in brief is when the ASA parses the traffic and sends the relevant information to the filtering server. The filtering server will then accept or reject the connection.

This means that you can only filter on traffic the ASA can parse and that the contents of the traffic does not reach the filtering server.

Most of the time the ASA will extract the URL from a HTTP request, send that over a dedicated UDP or TCP connection tot the filtering server and either the permit the request or send a reset to kill the connection.

WCCP redirection will send all matching TCP traffic from the clients towards the WCCP client. This means that for example a web cache can pretend to be the servers on the internet or a filtering device can intercept and inspect all traffic from the clients towards the internet.

The ASA does little to no work on the traffic and does not need to parse it. The limits of the manipulations done on the traffic are entirely in the hands on the WCCP client.

Please notice that the WCCP redirection on the ASA is a different system then used in IOS, with different advantages and limitations.  Most noticable of which is that the ASA cannot redirect traffic to an WAAS device as this would require the use of more advanced WCCP features.

WCCP on ASA is mostly designed for one use-case: a traffic filtering/caching device on the same LAN as the clients.

Peter

[Ramraj Sivagnanam Sivajanam]

Hi Peter
Please do correct me if I've misunderstood you. What you're saying is that in URL Filtering, only the URL portion is extracted from the user's HTTP request, and sent to the URL Filtering Server. For this reason, the users and the URL Filtering Server can be on a different interface in a Cisco ASA FW.

However, WCCP will cache and send all matching TCP traffic from the user towards the WCCP Server. Since there's caching involve, for this reason, the users and the WCCP Server cannot be on a different interface in a Cisco ASA FW.

If I've understood you correctly, just to inquire, what does the Cisco ASA cache. I'm guessing username/passwords, last visited web page etc.???

[pevaneyn]

Hi,

Please do correct me if I've misunderstood you. What you're saying is that in URL Filtering, only the URL portion is extracted from the user's HTTP request, and sent to the URL Filtering Server. For this reason, the users and the URL Filtering Server can be on a different interface in a Cisco ASA FW.

This is correct

However, WCCP will cache and send all matching TCP traffic from the user towards the WCCP Server. Since there's caching involve, for this reason, the users and the WCCP Server cannot be on a different interface in a Cisco ASA FW.

It is not the action of caching which is the problem, but it is just the implementation of WCCP on the ASA which has this limitation. On IOS for example this is perfectly possible.

If I've understood you correctly, just to inquire, what does the Cisco ASA cache. I'm guessing username/passwords, last visited web page etc.???

The ASA doesn't cache in the WCCP case, even in the URL filtering case there is no caching of the results of the filtering.

Best regards, Peter

[Ramraj Sivagnanam Sivajanam]

Hi Peter

Thanks for your kind feedback. If it's not the action of caching which is the problem here, what's the limitation of Cisco ASA that IOS doesn't have, and the rationale behind it.

[pevaneyn]

Hello Ramraj,

The limitations of the ASA are due to the design objectives.

The WCCP support on the ASA was intented only to support web caching/filtering devices on the VLAN of the client devices. So no other features were implemented or tested.

Because of this limited scope we also did not use the WCCP parts from IOS as porting that would be more complex then doing the limited WCCP.

In short the account teams told the developers that we needed limited WCCP support and that is what we got. So if you think this is not what you want then feel free to talk to your account team...

Best regards, Peter

[Ramraj Sivagnanam Sivajanam]

Thanks Peter. You have been a great help.

[huangedmc]

hi,

Could you please tell me which switch & router platforms perform WCCP in hardware?

When a wccp session is negotiated between wccp server (router) & cache engine, who determines how the service groups behave?

For example, groups 61 & 62 are "reserved" for tcp traffic used by WAAS.

What happens if I redirect UDP traffic instead? Would it still work?

ip access-list extended WCCP-ACL

remark WCCP redirect ACL

  permit udp any any

ip wccp 61 redirect-list WCCP-ACL

ip wccp 62 redirect-list WCCP-ACL

==

Are the service group numbers something we can just make up, since the redirect ACL is what's really deciding what gets redirected?

thanks,

Kevin

[pevaneyn]

Hello Kevin,

Could you please tell me which switch & router platforms perform WCCP in hardware?

WCCP redirection in hardware happens if the WCCP parameters are suitable on the

Catalyst 3550, 3750, 4500, 6500 Sup2, Sup32 and Sup720,  7600, ASR 1000 and Nexus 7000. If the parameters are not ok you either get software redirection/return or WCCP fails.

When a wccp session is negotiated between wccp server (router) & cache engine, who determines how the service groups behave?

The router/switch determines where the interception happens. All other parameters (traffic selection, load distribution, load allocation, redirection and return method) are determined by the lead WCCP client. The router/switch can only reject proposals with parameters it doesn't like.

For example, groups 61 & 62 are "reserved" for tcp traffic used by WAAS.
What happens if I redirect UDP traffic instead? Would it still work?
ip access-list extended WCCP-ACL
 remark WCCP redirect ACL
  permit udp any any
ip wccp 61 redirect-list WCCP-ACL
ip wccp 62 redirect-list WCCP-ACL

The parameters of the WCCP client would get merged with this ACL, so in the end nothing would match. Or this is the theory, but as this is a non-supported configuration anything might happen.

==
Are the service group numbers something we can just make up, since the redirect ACL is what's really deciding what gets redirected?

There are two kinds of WCCP service numbers: fixed and dynamic. For the fixed services only one is defined: 0 or web-cache.

For the dynamic services the standard is silent, however we try to have some order, see http://www.cisco.com/en/US/docs/app_ntwk_services/waas/acns/v52/configuration/local/guide/wccpch.html#wp1262001

or https://supportforums.cisco.com/thread/2067558 for the services defined by ACNS.

However as far as I know there is no need to follow this 'standard' in the configuration, the software doesn't expect you to follow this.

Best regards, Peter

[huangedmc]

Thank you for the response.

Follow up questions:

1. What do you mean by "If the parameters are not ok you either get software redirection/return or WCCP fails"?

What kinds of parameters are considered not ok...could you please give me an example?

I just want to make sure our switches handle wccp in hardware.

==

2. Does the option "accelerated" do anything at all?

Even when I specify it, it doesn't show up in running-config on a 3560:

core17(config)#ip wccp 61 redirect-list 100 accelerated

core17(config)#do sh run | i wccp

ip wccp 61 redirect-list 100

==

3. You had said most of the parameters are determined by the lead WCCP client.

So what happens if the client's parameters deviate from the "standard" in terms of what a service group is supposed to do?

Would the router accept or reject the parameters?

I'm asking because we may have non-Cisco products that don't follow the "standard".

Service groups 61 & 62 are defined as "tcp-promiscuous" because that's how WAAS is implemented, correct?

During the wccp negotiation, does the cache (WAAS) instruct the router how a service group behaves (61&62 = tcp),

or does the IOS device have "built-in" intelligence that knows they're supposed to redirect all tcp traffic?

Just trying to understand if the dynamic groups in table in https://supportforums.cisco.com/thread/2067558 is just a guideline, or if all vendors must use the standard group numbers.

==

4. currently the timers are 10sec/30sec for hello/dead.

Is there any plan to allow custom values, such as 1sec/3sec?

We'd like to be able to detect a cache failure faster than 30 seconds.

thanks!

Kevin