DCEF issue

[asanes]

Hi, I have a 7500 router and the its cpu increased about 30% the last two months. I truned on DCEF on all interfaces, but the CPU keep the same value, and almost all of the use is due to interrupts, for example:

CPU utilization for five seconds: 56%/55%; one minute: 62%; five minutes: 63%... because of the cpu use didn´t decrease by turning on DCEF, might this use be due to the very huge access-lists this router have apply on it´s interfaces?... thanks ahead!

[mark-obrien]

When you have an access list on an interface, DCEF is turned off even if you enabled it. All packets on that interface are process switched, so yes, the huge access lists may be the cause. To be sure, enter the command "show processes cpu" and find the process that is taking up the most resources.

Mark

[skiv]

This is very bad.

Is any comments from cisco about this bug? Where can I read about this?

Thank you for advance.

[ruwhite]

dCEF should not be turned off when you turn on an access list--especially on a 7500. Some access lists cannot be processed on certain GSR line cards, but the 7500, with VIPs, should be able to dCEF switch just about anything that can be cef switched. I would suggest doing a couple of things:

-- Get a show align, and make certain you don't have a lot of alignemtns errors or spurious accesses. These are counted in the interrupt context, and could be driving your cpu util up. If you don't see an heavily increasing number of these, then I would check the next step.

-- Check show cef not-cef-switched, and see what it says about the amount of traffic that isn't being cef switched, and why it's not cef switched. This should give you some clue as to what's going on here.

There's no way to proceed further without this information.

Russ

[asanes]

Hi,

the sh align showed neither aligment data nor spurious memory . being recorded. Here i send you the show cef not-cef-switched output.

cha-serv-00#show cef not-cef-switched

CEF Packets passed on to next switching layer

Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag

RP 6025429 0 0 7 13138148 0 0 0

4 345971 0 0 0 483732 0 1463578843 0

5 0 0 0 0 0 0 0 0

8 0 0 0 0 0 0 0 0

I understand from this output that there have been 345971 times that VIP on slot 4 haven´t foung adjacencies on it´s route cache, but i still don´t know how to exactly interpret this output. I´m looking for that at CCO

I also found this information on this link: http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a00800873cd.html

"If you enable CEF and then create an access list that uses the log keyword, the packets that match the access list are not CEF switched. They are fast switched. Logging disables CEF"

Please, let me know your comments...

Regards,

Aisha

[lauren]

Check out -

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_r/xrfscmd4.htm#1071764

Table 6 gives you the meanings of the output of this command.

If you are logging the access list, as i understand it, it has to be punted and process switched as CEF can only forward, it doesnt know how to log.

[asanes]

Thanks for the link!, it gave me the information i needed to understand what was and wasn´t being cef switched in my routers. I could decrease the cpu of one of the routers in almost 25%, cause i have a GEIP+ module (slot 10 of my 7500 router) where i have a gigabit interface that has three vlans configured, one of those vlans handles near 100Mbps traffic and none of the packets on this linecard was being cef switched. The reason was one ACL apply to one of the subinterfaces on the GigabitEthernet interface, it was a very small ACL and it wasn´t apply to the subinterface with the large amount trafffic, nonetheless the traffic for the whole line card was being affected, i removed the ACL and inmediatly the traffic began to be cef switched and the counters in the "sh cef linecard 10" for input and output paquets increased. I´m gonna analize the value of each ACL i have apply on the routers and to reubicate them as needed. Thanks a lot!