On Sat, Sep 06, 2008 at 11:59:24AM +0100, Mateusz B?aszczyk wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rondey, Nic, > >> > > >> >config t > >> >int null 0 > >> >no ip unreachables > > yes this is configured already. > > >> > > >> >The ACL drops are, last I checked, rate limit punts. > >> this is interesting - there is a good article detailing cef and CPU > >> punting at :- > >> > http://searchnetworkingchannel.techtarget.com/generic/0,295582,sid100_gci1261924,00.html > >> > >> > >> > >> Reading that and this posting begs the question > >> - if there is a lrage amount of ACL drops and these packets are punted to > >> cPU and the CPU rate-limit for punted packets has been exceeded, then > >> possible packets that need to be CPU processed will be dropped in favour > >> of ACL denied packets > > > > That's not true. The packets are dropped under interrupt that match > > the ACL deny other than punting some to generate the unreachable. > > You will always deny them. > > > > >> >If it's high CPU at IP Input really need 12.4(20)T and get > >> >a sniffer trace in the punt path to see what traffic it really is. > > This part is interesting. I might try that. > Question - there are 2 switching paths on the router > 1) process switching which means invoking ip_input for every packet
That is if you have CEF disabled. Let's forget the "ip fastswitching" discussion because after 12.4(20)T it's gone. It's process or CEF only. > 2) interrupt context switching which is supported by different caching > mechanisms - fast switching, CEF etc. If there is marginal utilisation > of ip_input process and also most of the CPU utilisation is pointing > to interrupts - what does it mean? That means you have a lot of interrupt traffic transit the box and some is getting punted to process level after a lookup in the rx CEF routines or either further down the CEF switching vector due to a feature punt. > > >> >>>>Also, if > >> >>>>you're denying a lot of traffic from a certain source, you might want > >> >>>>to > >> >>>>just bit-bucket it rather than sending ICMP responses. > >> >>> > >> >>You could match the access list in a route map and set the outbound > >> >>interface > >> >>to Null0. > > The configured ACL follows the example for infrastructure ACLs (here: > http://cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml#limitaccess > ) > > Does it mean the NPE-G1 is not enough to process ~400Mbps/60kpps with > ACL like above? Depends on the exact ACL and other features configured. > The other night when traffic was much lower the ACL was removed from > the port and overall utilization dropped from 45% to 37%. Is that a > lot? 8% decrease is nothing but 1/5th of drop is quite substantial. I > am puzzled here. Probably normal. I'd suggest looking at the new ASR1000 that can do ACL's in hardware. > > Would a bigger box (as mentioned in the other thread "7600 starter > kit") solve the problem? Yes as long as your process level traffic isn't the main issue. Rodney > > Best Regards, > > - -- > - -mat > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIwmKMIvBv0k5esR4RAoE3AJ9qwbN70MPfjwjo2cd4JEeROxM3VACdElAw > 7ND4V+Okkj2li6ktFVQ4+/Q= > =g9Ev > -----END PGP SIGNATURE----- _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/