the cpu reach 85 % when using cache server and return to 3% when shutdown it!!!

[Dr.X]

hi ,

recently i was uisng router 7206 as router gateway and the cache working fine and the max cpu was 50 %

now , i copied the config and pasted it in another router cisco 7600

every thing is fine , but i note the cpu is increasing and reached up to 85 %% !!!!!!!!!!!!!!

i just shutdown the cache server and the cpu became 3 % !!!!!!!!!!!!

which mean that the cache server is utilizng all of my cpu  .!!!!!!

actually , there are some config wasnt accepted  in 7600 which is under interface command

duplex full

speed auto

media-type rj45

negotiation auto

but i think that these lines has no affect in cache server cpu .

i will pase my config of cache with config of interfaces  ,  whch is currently in 7600

my question is how to start troubleshooting the cpu  utilization  because of cache ?

my issue  is when i was using 7206 the cpu biggest  value was 50 % when cache is full loaded . but in 7600 the utilization reached 85 % and still increasing !!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

ip wccp 80 redirect-list CACHE80

ip wccp 90 redirect-list CACHE90

!

interface GigabitEthernet1/1

description zzz

bandwidth 230000

ip address 10.160.150.2 255.255.255.0

ip wccp 80 redirect in

ip policy route-map CACHE-REDIRECT

load-interval 30

!        

interface GigabitEthernet1/2

description Cache

bandwidth 150000

ip address xxxxxxxx 255.255.255.248

ip wccp redirect exclude in

load-interval 30

!        

interface GigabitEthernet1/3

description Internet from uuuuuuu

bandwidth 230000

ip address xxxxxxxxx 255.255.255.252

ip wccp 90 redirect in

load-interval 30

!        

interface GigabitEthernet1/3.11

description Internet From rrrr

encapsulation dot1Q 11

ip address xxxxx

ip wccp 90 redirect in

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Very likely your WCCP topology and configurations are not taking full advantage of the 7600's hardware.  As Edison notes "There are some caveats ..."

You might want to search Cisco's main site on information concerning 6500/7600 and WCCP configuration.

[Dr.X]

hi,

i removed the policy and the cpu value decreased to 30 %

as you mentioned , the policy was  causing cpu trouble .

anyway , as you thought , removing the IP Policy fixed the cpu utilization .

but im looking forward a solutin ,

wt do you think i have to do ???

should i look for another solution and forget using the ip policy ?? or rearrange the policy ??

regards

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I think I recall, not all PBR statements are handled by hardware.  If I remember that correctly, you would need to check Cisco documentation against your PBR.

The Achilles heel of 6500/7600s, is anything that causes the forwarding to be done by the main CPU rather than the  ASICs.

[Dr.X]

hi , i read about that ,

i found that using set ip next hop and match ip  under  route map are all handeled by hardware .

here is reference :

•The  Policy Feature Card (PFC) and any Distributed Feature Cards (DFCs)  provide hardware support for policy-based routing (PBR) for route-map  sequences that use the match ip address, set ip next-hop, and ip default next-hop PBR keywords.

i also found another command which enable fast switching

here is refernece:

sers that need PBR to occur at faster speeds can now implement PBR without slowing down the router.

Fast-switched PBR supports all of the match commands and most of the set commands, with the following restrictions:

Router(config-if)#

  ip route-cache policy

is this command may  play role to solve the cpu issue ???

------------------------------------------------------------------------------------------

wt caveats im facing ???

should i forget using ip policy or i can find a solution , ???

regards

[Edison Ortiz]

You could have PBR and WCCP on the same interface but they can't handle the same traffic (same ACL).

Looking at your WCCP ACL:

Extended IP access list CACHE80

    10 deny tcp any hostzz.zz.4.69 eq www

    20 deny tcp host xx.xx.67.253 any eq www

    30 deny tcp any host zz.zz.92.59 eq www (316 matches)

    40 permit tcp xxxx.68.0 0.0.3.255 any eq www (115010480 matches)

    50 permit tcp xx.xx.72.0 0.0.3.255 any eq www (88556023 matches)

    60 permit tcp xx.xx.76.0 0.0.3.255 any eq www (59342978 matches)

    70 permit tcp xx.xx.67.0 0.0.0.255 any eq www (15182404 matches)

Extended IP access list CACHE90

    10 permit tcp any xx.xx.67.0 0.0.0.255 (417403 matches)

    20 permit tcp any xx.xx.68.0 0.0.3.255 (3551977 matches)

    30 permit tcp any xx.xx.72.0 0.0.3.255 (2701614 matches)

    40 permit tcp any xx.xx.76.0 0.0.3.255 (1671664 matches)

And your PBR ACL:

Extended IP access list isp1

    10 permit ip xx.xx.64.0 0.0.1.255 any (41830 matches)

Extended IP access list isp2

    10 permit ip xx.xx.66.0 0.0.1.255 any (15673605 matches)

    20 permit ip xx.xx.68.0 0.0.3.255 any (117877748 matches)

    30 permit ip xx.xx.72.0 0.0.3.255 any (91318175 matches)

    40 permit ip xx.xx.76.0 0.0.3.255 any (61154622 matches)

Clearly shows you  PBR and WCCP the same traffic.

We have plenty of internal reference documents indicating this is not a supported configuration.

The only external reference I've found so far is documented under the 6500 WCCP Best Practice at:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-629052.html

Policy-Based Routing - PBR and WCCP may be  configured on the same interface and can coexist with hardware support  provided the features are not applied to the same traffic. If the  features do overlap then the traffic will be switched in software.

Please note: 6500/7600 basically have the same caveats on these features.

Regards,

Edison

Please remember to rate helpful posts.

[Dr.X]

hi ,

i could recognize that no way to use cache server with ip policy one the same interface , but another question

as you know , in cisco 7600  we have 8 interfaces Giga , im currently using 3 only,

if i used the cache server on another interface rather   than Gi1/1 , could i find a solution ??

another question ,

if i edited my router map with only  two permit statements with the same wanted work , could i enhance cpu utilization ?

i mean the new royte map will be as follow :

Gateway7600#sh route-map CACHE-REDIRECT

route-map CACHE-REDIRECT, permit, sequence 20

  Match clauses:

    ip address (access-lists): isp1

  Set clauses:

    ip next-hop vv.vv.56.165

  Policy routing matches: 21040 packets, 1647130 bytes

reagrds

route-map CACHE-REDIRECT, permit, sequence 100

  Match clauses:

  Set clauses:

[Edison Ortiz]

As long as the WCCP and PBR are not on the same interface, you should be fine.

If the WCCP and PBR are on the same interface, the ACL used by the WCCP and PBR can't overlap.

I see you've modified the route-map for the PBR but I don't see any modification for the ACL ISP1.

if ISP1 ACL has the same subnets as the ones used by WCCP, the issue will remain.

Regards,

Edison