Re: OT: 7609S Feature Manager and WCCP

Sorry, I was wrong... After removing the last sequence everything was just
O.K.
I though removing it would cause all other traffic to be dropped because I
had this experience some years ago with an older device which I can't
remember as well, but had it in back of my mind that somewhere removing the
last catch-all permit sequence caused the other traffic being dropped.

Thanks a lot

On Sun, Sep 15, 2013 at 4:39 PM, Mohammad Moghaddas
<moghaddas.it_at_gmail.com>wrote:

> I can't remove the last permit all seq, because all other traffic which
> doesn't match the previous sequences, will be dropped.
>
>
> On Sun, Sep 15, 2013 at 4:29 PM, Johnny Morris <johnnymorris01_at_gmail.com>wrote:
>
>> I had a similar issue and removing the catch all permit statement in pbr
>> fixed the high cpu interrupt. by default pbr will perform destination
>> routing if it doesnt match anything in pbr. Try removing your permit catch
>> all statement in pbr.
>> On Sep 15, 2013 6:12 AM, "Mohammad Moghaddas" <moghaddas.it_at_gmail.com>
>> wrote:
>>
>>> Dear all,
>>>
>>> sorry for posting an OT.
>>>
>>> I've faced an issue on 7609-S router, which its engine is RSP720-3C-GE .
>>> On one of the RSP's Gigabit interfaces, we *had "*wccp redirect in"
>>>
>>> configured. After a topology redesign, we removed all wccp configurations
>>> on the router, and configured PBR on the same interface.
>>> The PBR has 4 sequences, each one of the first 3 sequences is matching a
>>> different ACL (each has 3 ACEs referring to /24 subnets) and sets the
>>> "ip *default
>>> *next-hop" of the traffic to different next-hops than the default route,
>>>
>>> and the last sequence permits all other traffic.
>>> After removing all wccp configurations and implementing PBR, the CPU
>>> usage
>>> of the RP (interrupt) has increased to 80% . When the PBR is removed, it
>>> decreases to 1% .
>>> The input traffic on the interface is just about 150Mbps, and the output
>>> is
>>> around 300Mbps.
>>>
>>> I went through lots of documents, and reached to Feature Manager.
>>> Surprisingly, when I issue "sh fm wccp inband" and other related
>>> commands,
>>> I still see the WCCP is the feature which bumps the interface.
>>>
>>> HT-CoreRT#sh fm wccp inband
>>> Current Slot Mask is 20
>>> Cache-Engine address: aaaa.bbbb.cccc at H/W adjacency:
>>> Slot 5: 524290
>>> Cache-Engine address: aaaa.bbbb.cccc at H/W adjacency:
>>> Slot 5: 524291
>>> Cache-Engine address: 192.168.64.6 at H/W adjacency:
>>> Slot 5: 524292
>>> Cache-Engine address: 192.168.64.6 at H/W adjacency:
>>> Slot 5: 524293
>>> Cache-Engine address: 192.168.64.6 at H/W adjacency:
>>> Slot 5: 524294
>>> Cache-Engine address: aaaa.bbbb.cccc at H/W adjacency:
>>> Slot 5: 524295
>>>
>>> I've cleared the hardware logic of the interface, cleared all fm related
>>> things, cleared CEF, enabled and re-enabled WCCP and PBR, and etc.
>>> The last resort of solution would be reload, but I wish not to.
>>>
>>> Hope you can help me.
>>>
>>> Regards,
>>> Mohammad
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Sep 15 2013 - 16:57:43 ART