WAAS, and 4948 switches with wccp

Answered Question
Mar 31st, 2009


I know the 4948 switches do not support a redirect list as per the WAAS deployment cookbook I found somewhere else on netpro.

The problem I get is that I cannot telnet to the loopback interface of the 4948 when I've got wccp and waas functioning at the wan edge layer. It pings ok; but it seems that the telnet packets are being redirected to the WAEs and not 'coming back' - the session hangs.

I can telnet to other IPs bound to interfaces on the 4948, and the WAAS appliance vlan interface address - its just the loopback that hangs.

I have "ip wccp 61 redirect in" on the WAN interface of the 4948 and " ip wccp 62 redirect in" on the LAN interface and the WAAS appliances are using L2 redirect and masking.

Note that I've also got the the 61 and 62 'reversed' at the DC end compared to the branch as per WAAS cookbook/text book.

On the 3750's we could set up a redirect list and deny the loopback from being redirected- but how can I get around this on the 4948?

I can get around it by creating a "loopback" vlan and assign the address to that, but I'd prefer just to have the standard loopback interface by itself working.

Any ideas?

Also, what IOS is recommended for the 4948 in this wccp/waas scenario?


Correct Answer by dstolt about 7 years 10 months ago


You definitely need a L3 link between the two where traffic doesn't get re-intercepted, especially for situations on WAN failures, etc. so your traffic doesn't loop back through the LAN side.

You can look for things like that in your syslog (find match “Routing Loop” syslog.txt) or in the stats under "sh stat filtering.

Good luck with your deployment!!


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
dstolt Tue, 03/31/2009 - 18:49

Sounds like you might be hitting

CSCsg30875 wccp blocking telnet to router

This DDTS should be fixed in 12.2(37)SG. For the 4500/4900, I usually start with 12.2(40)SG or later for WCCP implementations. I would try that and see if you still have the issues.

Hope that helps,


cstockwe Tue, 03/31/2009 - 19:08


I was running 12.2(40)SG and was striking some strange telnet issues, but since then I've ugraded to 12.2(50)SG1 - just for testing if nothing else.

I'm still unable to telnet to loopback interface on 12.2(50)SG1; but some of the other issues went away.



dstolt Wed, 04/01/2009 - 07:51

Just to verify, your WAAS box is directly connected to the switch and is using the following config?

wccp tcp-promiscuous router-list-num 1 l2-redirect mask-assign l2-return



cstockwe Wed, 04/01/2009 - 14:31

Hi Dan - yes that's correct.

One thing I've noticed is that for the wccp router list on the WAE the IPs of the switches on that line are the loopback addresses of the switch; rather than the switch address on the same vlan as the WAEs.


Loopback address of the 4948s: and

WAEs on vlan 10: 4948 vlan 10 interface addresses and (/24)

(We are using HSRP on the 2 x 4948's and the HSRP gateway for that vlan 10 is

The WAE's are and .22 for example. We want to add more so that we get scalability should the connection count increase obviously at the Data Centre end.

When I do a "show ip wccp" on the 4948s, does it matter what the switch reports as its 'router identifier'? ie. does it have to be on the same vlan as the wae's? At the moment it either reports the loopback IP (presumably because of 'higher' priority)...but does this matter at all?

I'll change the WAE's config to :

wccp router-list 1

wccp tcp-promiscuous router-list-num 1 l2-redirect mask-assign l2-return

wccp version 2

...and I'll try it again. Thanks for your help.

dstolt Wed, 04/01/2009 - 18:34


For WAEs using L2 redirect, always use the L3 interface address the WAEs are connected to for the router lists (not the loopback). Most importantly, they all have to be L2 adjacent (which yours look like they are). Also, make sure it's not a HSRP address in case it fails over. However using HSRP for the default Gateway is definitely recommended for fault tolerance.

When you do a sh wccp routers, the loopback will usually show up as the router ID due to the way WCCP registers with the router, however the WAEs will register to the L3 addresses you put in the router lists.

Let us know how it works...



cstockwe Wed, 04/01/2009 - 22:45

Hi Dan

Solved it by adding a 2nd vlan that was non-passive; so that there was a direct link between the switches that was L3.

It looks like because I only had one vlan (the wae's vlan) configured on the 4948s and that vlan was passive in eigrp; this was causing the redirection to occur twice (once per switch) as the route was thrown back up to the wan router; which made the waas unhappy.

Thanks again

Correct Answer
dstolt Thu, 04/02/2009 - 05:33


You definitely need a L3 link between the two where traffic doesn't get re-intercepted, especially for situations on WAN failures, etc. so your traffic doesn't loop back through the LAN side.

You can look for things like that in your syslog (find match “Routing Loop” syslog.txt) or in the stats under "sh stat filtering.

Good luck with your deployment!!


jkeeffe Fri, 04/03/2009 - 12:20

Do you think the 4948 switch will ever be able to support the redirect-list function?

dstolt Fri, 04/03/2009 - 13:29

From what I can see, the current hardware and software doesn't support it. If the Cat4K goes through a hardware upgrade and the WCCP code is upgraded as well, then it will.

Timeline? No idea.


jkeeffe Mon, 04/06/2009 - 06:35

So what are the limitations on a device that doesn't support redirect-lists? Does that mean it is an either/or situation? Either all TCP hosts/IPs are redirected - or none are redirected?

To be clear, if I MUST be able to redirect all hosts, but not redirect all hosts, than I better not use the 4948 switches as the WCCP redirect points?

dstolt Mon, 04/06/2009 - 08:02

If the device doesn't support redirect-lists, then you get all the traffic from the interface(s) that you enable redirection on.

Looking at your scenario, you can still do redirection on your 4948 and have a application policy in WAAS to put into Passthrough and just put it back on the wire without inspecting it for optimization. This would result in redirecting traffic much like inline interception (except you are only getting TCP traffic), however you would be using the 4948 for redirection. Otherwise, you might have to look at a different platform for WCCP.



jkeeffe Mon, 04/06/2009 - 08:18

This question actually doesn't have anything to do with WAAS, so I can't use the pass-through funtio, but I was curious as this is the forum that I realized the 4948's WCCP limitation.

(WCCP that redirects traffic to our WAAS devices is on a 6500 switch elsewhere in our datacenter.)

The 4948 is our connection to our Internet Access layer and we need to use WCCP to redirect streaming video and other web traffic to some content engines, and the redirect-list would be where we deny certain subnets from being redirected. If I can't be that granular, I'm going to have to look at something other than the 4948.

dstolt Mon, 04/06/2009 - 08:35

Makes sense.

Most WCCP clients also have a bypass feature as to what content it will accept for "caching" or whatever. The WCCP client should return the bypassed traffic to the switch, so I would explore that if your client allows that config. However, they are all different, so I would pursue that with your vendor.



jkeeffe Mon, 04/13/2009 - 07:29

I just found out that the 4948 Enterprise IOS does Policy Base Routing.

Do you think that is a good alternative to the inability of the 4948 to use the WCCP Redirect-list? Do you think PBR could be used instead to direct certain traffic to a WCCP client?

m.an Tue, 05/05/2009 - 19:13

Hello cstockwe,

I have the same problem as you. I have two CAT4948 SWs, one with WCCP config (SW1) can be telneted via loopback interface, but the other (SW2) can't. The two SWs have the same IOS version (cat4500-entservicesk9-mz.122-46.SG), the same model, the same size of flash&RAM memory, the same config...

And all the interfaces except the loopback interface on the SW2 can be telneted.

You mentioned you have workaround solution, how to do the solution ? Can you explain the detail ?



cstockwe Mon, 05/18/2009 - 17:33


Just make sure you have an active Layer 3 link between the switches.

See Dan's reply in this thread above.



This Discussion