Return to

Cisco: PBR and WCCP on same device


Hi guys,

I’ve tried this with google a bit but haven’t managed to find anything conclusive as it’s a bit of an awkward thing to search for…

Is it possible to do both WCCP and PBR on the same Cisco device, with any version of IOS? Specifically for a Cat 4507 switch running sup7-E - currently running IOS 15.1 on it (but we can upgrade IOS if required)?

The reason I ask is because i have an existing WCCP setup to do Riverbed steelhead traffic optimisation (virtual deployment, so i can’t do in-path, has to be other WCCP or PBR). Unfortunately, the need has come up to do policy based routing (at least temporarily) in order to redirect specific traffic (not necessarily HTTP/HTTPS, so WCCP = not going to do it?) through a second internet gateway.

Long term, i’d like to fully cut over service (at least primary) to the new, bigger pipe but there is a significant amount of work involved with that and ideally as step one i’d like to redirect a handful of services out the new pipe on an ad-hoc basis, as that will at least allow me to get a bunch of load off the other pipe. Also, i’ll be able to do a phased transition and deal with smaller amounts of fall-out rather than big bang and hope for the best (in terms of possibly unforeseen issues - like remote third parties only permitting some of our apps from a specific endpoint, etc. - this subnet has been in use for 10+ years).

Initial investigations indicate(d) that PBR and WCCP can’t be run (or rather is not “supported”) on the same device at the same time; however my vendor who is assisting thinks that maybe it might be possible with an updated IOS.

I figure there’s perhaps a few advanced routing/switching Cisco guys on here, does anyone know (i.e., you have deployed it like that or know of a client running it) otherwise?

I’d lab it up but unfortunately i dont have a spare 4500 switch with a Sup7 in it :-\

Right now the plan is to migrate to PBR for the steelhead deployment so i can also use PBR for routing decisions, but if a newer IOS will allow us to do both we can avoid re-configuring all that (and WCCP has its advantages for that use case).


I guess a negative response MIGHT be helpful, but I’ve never seen nor heard of it being done.


Yeah, we’re a bit of an edge case :smiley:

If it can’t be done, so be it. I need to upgrade IOS for an option that isn’t currently supported with PBR on it as is anyway, ip next-hop reachability isn’t available or something… but would be nice if we could just upgrade and not have to reconfigure the steelhead side.

thanks for reading anyway :slight_smile:


I’m definitely not the be-all-end-all in this arena. I passed my CCNA in 2009, and rarely have i ever had to type en since then.


Thanks anyway.

But yeah, i figured there might also be some CCIEs or at least route/switch guys floating about who might know for sure


From what I’m reading, the evaluation order is gonna kill you. The WCCP will be evaluated before the PBR, which from the sound of things is not gonna do it for you.


It might be OK; WCCP happening before PBR shouldn’t be a problem i don’t think.

This switch is not on the edge, everything here is pre-NAT (that happens on each internet gateway, the only traffic the steelhead is looking at via WCCP is for private MPLS networks which are via other routers). So if PBR comes after WCCP, it will be for destinations that are already excluded from the WCCP ACLs :slight_smile:

But yeah, we had that discussion here already :slight_smile:


Topology looks something like this…

Essentially PBR would be for specific local-to-4507 IPs of select hosts, to (via either ISP1 or ISP2).

WCCP is configured for specific subnets (of only, is excluded from the WCCP ACLs specifically…


I don’t know about the 4500 series or IOS 15.1. I do know we used PBR and WCCP together on a 6509-VE running 12.2 for multiple years at QuakeCon. The policy was a very simple route-map, just matched on source address and set a next-hop, while WCCP would pick up the TCP/80 traffic to punt over to squid.

I don’t know if this was “supported” but it did work.


Thanks for the update. I suspect that it may well work but is “not a supported configuration” and “may have different behaviour on different versions of IOS”.

I’ve committed at this point to migrating the steelhead configuration to PBR, but that has unfortunately meant an IOS upgrade to get PBR object tracking.