Thanks for the info Lee
On 4/24/09, Richard Gallagher <[email protected]> wrote: > It does block these packets, but this does not effect the CPU, they > are still punted, nothing can be done about this. > > There is no rate-limiter either on this platform, on the 6k we have: > > - mls rate-limit all ttl-failure <value per milisec> > > Best case is going to be stop the sources sending, not many other > options. > > Rich > > On 24 Apr 2009, at 16:06, Lee wrote: > >> Too bad the multicast ttl-thresold doesn't work. Does your >> access-list 178 block traffic to 224.0.0.252? >> >> Lee >> >> >> On 4/24/09, Chris Lane <[email protected]> wrote: >>> nterface Vlan217 >>> description CUSTOMER A >>> ip address x.x.x.x.x >>> ip access-group 178 in >>> no ip redirects >>> no ip unreachables >>> no ip proxy-arp >>> ip multicast ttl-threshold 3 >>> >>> shcpu >>> CPU utilization for five seconds: 92%/51%; one minute: 92%; five >>> minutes: >>> 92% >>> PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process >>> 9 14412 39169 367 0.95% 0.19% 0.08% 0 ARP >>> Input >>> >>> 51 155152 901076 172 2.55% 0.92% 0.93% 0 Fifo >>> Error >>> Detec >>> 67 12541 522329 24 0.15% 0.07% 0.05% 0 HLFM >>> address >>> ret >>> 115 622003 413812 1503 7.34% 7.52% 7.49% 0 Hulc >>> LED >>> Process >>> 136 166229 17815 9330 0.63% 0.60% 0.60% 0 PI MATM >>> Aging >>> Pr >>> 168 5892258 12519191 470 25.23% 23.54% 24.45% 0 IP >>> Input >>> >>> 171 32572 45322 718 0.15% 0.13% 0.12% 0 >>> Spanning >>> Tree >>> >>> thanks for input >>> 2009/4/24 Lee <[email protected]> >>> >>>>> These TTL=1 are causing the high CPU. >>>> >>>> Just out of curiousity, would adding "ip multicast ttl-threshold 3" >>>> and/or "no ip unreachable" on the interface reduce cpu usage? >>>> >>>> Lee >>>> >>>> >>>> On 4/24/09, Richard Gallagher <[email protected]> wrote: >>>>> Input queue was full of packets like this: >>>>> >>>>> Buffer information for RxQ3 buffer at 0x2E792F0 >>>>> data_area 0x7BB2AB0, refcount 1, next 0x2E7E210, flags 0x200 >>>>> linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 >>>>> if_input 0x3ABBAE0 (Vlan217), if_output 0x0 (None) >>>>> inputtime 00:00:00.000 (elapsed never) >>>>> outputtime 00:00:00.000 (elapsed never), oqnumber 65535 >>>>> datagramstart 0x7BB2AF6, datagramsize 82, maximum size 2196 >>>>> mac_start 0x7BB2AF6, addr_start 0x7BB2AF6, info_start 0x0 >>>>> network_start 0x7BB2B04, transport_start 0x7BB2B18, caller_pc >>>>> 0x6D1024 >>>>> >>>>> source: 74.212.165.187, destination: 224.0.0.252, id: 0x3CDA, >>>>> ttl: >>>>> 1, >>>>> TOS: 0 prot: 17, source port 58064, destination port 5355 >>>>> >>>>> Buffer information for RxQFB buffer at 0x2672BB0 >>>>> data_area 0x758C35C, refcount 1, next 0x263960C, flags 0x200 >>>>> linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 >>>>> if_input 0x3ABBAE0 (Vlan217), if_output 0x0 (None) >>>>> inputtime 00:00:00.000 (elapsed never) >>>>> outputtime 00:00:00.000 (elapsed never), oqnumber 65535 >>>>> datagramstart 0x758C3A2, datagramsize 64, maximum size 2196 >>>>> mac_start 0x758C3A2, addr_start 0x758C3A2, info_start 0x0 >>>>> network_start 0x758C3B0, transport_start 0x0, caller_pc 0x6D1024 >>>>> >>>>> source: 74.212.165.187, destination: 224.0.0.252, id: 0x3CDA, >>>>> ttl: >>>>> 1, >>>>> TOS: 0 prot: 17, source port 58064, destination port 5355 >>>>> >>>>> These TTL=1 are causing the high CPU. >>>>> >>>>> >>>>> On 24 Apr 2009, at 14:26, Chris Lane wrote: >>>>> >>>>>> Richard Gallagher found that it was one of my customers sending >>>>>> mcast >>>>>> packets with a TTL 1. Tried adding ACL's to lower CPU but this >>>>>> didn't fix. >>>>>> We shutdown Vlan to verify and CPU came down 40% to adequate >>>>>> levels. >>>>>> >>>>>> I have a call into out customer notifying them to fix. >>>>>> >>>>>> Thanks to all for your input >>>>>> >>>>>> Regards >>>>>> Chris >>>>>> >>>>>> 2009/4/24 Chris Lane <[email protected]> >>>>>> >>>>>>> Yes with a high preference. >>>>>>> >>>>>>> 2009/4/24 junior <[email protected]> >>>>>>> >>>>>>> Hello. >>>>>>>> >>>>>>>> Does this switch have default route? >>>>>>>> >>>>>>>> Chris Lane wrote: >>>>>>>> >>>>>>>>> sh ip traffic IP statistics: >>>>>>>>> Rcvd: 37788273 total, 24253 local destination >>>>>>>>> 0 format errors, 0 checksum errors, 9771492 bad hop count >>>>>>>>> 0 unknown protocol, 27979860 not a gateway >>>>>>>>> 0 security failures, 0 bad options, 7762670 with options >>>>>>>>> Opts: 0 end, 0 nop, 0 basic security, 0 loose source route >>>>>>>>> 0 timestamp, 0 extended security, 0 record route >>>>>>>>> 0 stream ID, 0 strict source route, 7762670 alert, 0 >>>>>>>>> cipso, 0 ump >>>>>>>>> 0 other >>>>>>>>> Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble >>>>>>>>> 0 fragmented, 0 couldn't fragment >>>>>>>>> Bcast: 2884 received, 87 sent >>>>>>>>> Mcast: 2334 received, 2209 sent >>>>>>>>> Sent: 24621 generated, 8328118 forwarded >>>>>>>>> Drop: 4258 encapsulation failed, 0 unresolved, 83 no adjacency >>>>>>>>> 69 no route, 0 unicast RPF, 0 forced drop >>>>>>>>> 0 options denied, 0 source IP address zero >>>>>>>>> >>>>>>>>> ICMP statistics: >>>>>>>>> Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 0 >>>>>>>>> unreachable >>>>>>>>> 9560 echo, 0 echo reply, 0 mask requests, 0 mask >>>>>>>>> replies, 0 >>>>>>>>> quench >>>>>>>>> 0 parameter, 0 timestamp, 0 info request, 0 other >>>>>>>>> 0 irdp solicitations, 0 irdp advertisements >>>>>>>>> Sent: 0 redirects, 3129 unreachable, 0 echo, 9560 echo reply >>>>>>>>> 0 mask requests, 0 mask replies, 0 quench, 0 timestamp >>>>>>>>> 0 info reply, 47 time exceeded, 0 parameter problem >>>>>>>>> 0 irdp solicitations, 0 irdp advertisements >>>>>>>>> >>>>>>>>> TCP statistics: >>>>>>>>> Rcvd: 7710 total, 8 checksum errors, 1 no port >>>>>>>>> Sent: 6762 total >>>>>>>>> >>>>>>>>> UDP statistics: >>>>>>>>> Rcvd: 4615 total, 0 checksum errors, 1430 no port >>>>>>>>> Sent: 2909 total, 0 forwarded broadcasts >>>>>>>>> >>>>>>>>> IP-EIGRP statistics: >>>>>>>>> Rcvd: 0 total >>>>>>>>> Sent: 0 total >>>>>>>>> >>>>>>>>> BGP statistics: >>>>>>>>> Rcvd: 162 total, 1 opens, 0 notifications, 1 updates >>>>>>>>> 160 keepalives, 0 route-refresh, 0 unrecognized >>>>>>>>> Sent: 159 total, 1 opens, 0 notifications, 0 updates >>>>>>>>> 158 keepalives, 0 route-refresh >>>>>>>>> >>>>>>>>> PIMv2 statistics: Sent/Received >>>>>>>>> Total: 0/0, 0 checksum errors, 0 format errors >>>>>>>>> Registers: 0/0 (0 non-rp, 0 non-sm-group), Register Stops: 0/0, >>>>>>>>> Hellos: >>>>>>>>> 0/0 >>>>>>>>> Join/Prunes: 0/0, Asserts: 0/0, grafts: 0/0 >>>>>>>>> Bootstraps: 0/0, Candidate_RP_Advertisements: 0/0 >>>>>>>>> State-Refresh: 0/0 >>>>>>>>> >>>>>>>>> IGMP statistics: Sent/Received >>>>>>>>> Total: 0/0, Format errors: 0/0, Checksum errors: 0/0 >>>>>>>>> Host Queries: 0/0, Host Reports: 0/0, Host Leaves: 0/0 DVMRP: >>>>>>>>> 0/0, PIM: >>>>>>>>> 0/0 >>>>>>>>> >>>>>>>>> OSPF statistics: >>>>>>>>> Rcvd: 2363 total, 0 checksum errors >>>>>>>>> 1900 hello, 12 database desc, 2 link state req >>>>>>>>> 345 link state updates, 104 link state acks >>>>>>>>> >>>>>>>>> Sent: 2231 total >>>>>>>>> 1904 hello, 11 database desc, 4 link state req >>>>>>>>> 223 link state updates, 89 link state acks >>>>>>>>> >>>>>>>>> ARP statistics: >>>>>>>>> Rcvd: 2254 requests, 82 replies, 0 reverse, 0 other >>>>>>>>> Sent: 4178 requests, 2447 replies (2 proxy), 0 reverse >>>>>>>>> Drop due to input queue full: 0 >>>>>>>>> >>>>>>>>> Thanks for looking. >>>>>>>>> >>>>>>>>> On Fri, Apr 24, 2009 at 7:45 AM, junior <[email protected] <mailto: >>>>>>>>> [email protected]>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Did You check TAC cases? >>>>>>>>> Can You post this switch current configuration with sh ip >>>>>>>>> traffic >>>>>>>>> command output? >>>>>>>>> >>>>>>>>> WBR >>>>>>>>> Roman A. Nozdrin >>>>>>>>> >>>>>>>>> Chris Lane wrote: >>>>>>>>> >>>>>>>>> 1 routed interface.sh platform ip unicast failed route >>>>>>>>> Total of 0 covering fib entries >>>>>>>>> >>>>>>>>> Thanks for reply.. I checked earlier regarding sdm. >>>>>>>>> Its the same on all of my 3750's i have about 20 of them >>>>>>>>> throughout the >>>>>>>>> states, this is probably the quietest one in regards to >>>>>>>>> bandwidth and >>>>>>>>> services. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Apr 24, 2009 at 7:21 AM, Brian Turnbow < >>>> [email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> how many routed interfaces do you have ( sh ip int >>>>>>>>> brief >>>>>>>>> with ip >>>>>>>>> addresses ) ? >>>>>>>>> if more than 8 change the sdm template to routing >>>>>>>>> >>>>>>>>> you can use sh platform ip unicast failed route to >>>>>>>>> see >>>>>>>>> if >>>>>>>>> routes are >>>>>>>>> failing to be programmed into tcam >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> *From:* Chris Lane [mailto:[email protected] >>>>>>>>> <mailto:[email protected]>] >>>>>>>>> *Sent:* venerdě 24 aprile 2009 11.17 >>>>>>>>> >>>>>>>>> *To:* Brian Turnbow >>>>>>>>> *Cc:* Peter Rathlev; [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Subject:* Re: [c-nsp] 3750 High Cpu IP Input >>>>>>>>> >>>>>>>>> sh controllers cpu-interface >>>>>>>>> ASIC Rxbiterr Rxunder Fwdctfix Txbuflos >>>>>>>>> Rxbufloc >>>>>>>>> Rxbufdrain >>>>>>>>> >>>>>>>>> >>>> ------------------------------------------------------------------------- >>>>>>>>> ASIC0 0 0 0 >>>>>>>>> 0 0 >>>>>>>>> 0 >>>>>>>>> ASIC1 0 0 0 >>>>>>>>> 0 0 >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> cpu-queue-frames retrieved dropped invalid >>>>>>>>> hol- >>>>>>>>> block >>>>>>>>> stray >>>>>>>>> ----------------- ---------- ---------- ---------- >>>>>>>>> ---------- ---------- >>>>>>>>> rpc 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> stp 1807 0 0 0 >>>>>>>>> 0 >>>>>>>>> ipc 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> routing protocol 1516326 0 0 0 >>>>>>>>> 0 >>>>>>>>> L2 protocol 27 0 0 0 >>>>>>>>> 0 >>>>>>>>> remote console 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> sw forwarding 915 0 0 0 >>>>>>>>> 0 >>>>>>>>> host 2014 0 0 0 >>>>>>>>> 0 >>>>>>>>> broadcast 1766 0 0 0 >>>>>>>>> 0 >>>>>>>>> cbt-to-spt 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> igmp snooping 1518651 0 0 0 >>>>>>>>> 0 >>>>>>>>> icmp 45 0 0 0 >>>>>>>>> 0 >>>>>>>>> logging 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> rpf-fail 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> queue14 0 0 0 0 >>>>>>>>> 0 >>>>>>>>> cpu heartbeat 14116 0 0 0 >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> ODD i have disabled IGMP SNOOPING... >>>>>>>>> >>>>>>>>> On Fri, Apr 24, 2009 at 4:19 AM, Brian Turnbow >>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> You can use show controller cpu to help see >>>>>>>>> whats >>>>>>>>> going to the cpu >>>>>>>>> Make sure you have no ip redirects and no proxy >>>>>>>>> arp >>>>>>>>> on >>>>>>>>> all the interfaces. >>>>>>>>> How many routed interfaces do you have ? >>>>>>>>> The output below for "max" is for 8 routed >>>>>>>>> interfaces if >>>>>>>>> you have more you >>>>>>>>> should change to the desktop switching template. >>>>>>>>> With your roughly your values for indirectly >>>>>>>>> connected >>>>>>>>> routes and 13 ip >>>>>>>>> interfaces on a box I needed to switch the >>>>>>>>> template >>>>>>>>> "sdm >>>>>>>>> prefer routing" >>>>>>>>> requies reload. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> [mailto: >>>>>>>>> [email protected] >>>>>>>>> <mailto:[email protected]>] On >>>>>>>>> Behalf Of >>>>>>>>> Chris Lane >>>>>>>>> Sent: venerdě 24 aprile 2009 1.09 >>>>>>>>> To: Peter Rathlev >>>>>>>>> Cc: [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> Subject: Re: [c-nsp] 3750 High Cpu IP Input >>>>>>>>> >>>>>>>>> sh platform tcam utilization >>>>>>>>> >>>>>>>>> CAM Utilization for ASIC# 0 >>>>>>>>> Max >>>>>>>>> Used >>>>>>>>> Masks/ >>>>>>>>> Values >>>>>>>>> Masks/values >>>>>>>>> >>>>>>>>> Unicast mac addresses: >>>>>>>>> 784/6272 >>>>>>>>> 37/235 >>>>>>>>> IPv4 IGMP groups + multicast routes: >>>>>>>>> 144/1152 >>>>>>>>> 6/26 >>>>>>>>> IPv4 unicast directly-connected routes: >>>>>>>>> 784/6272 >>>>>>>>> 37/235 >>>>>>>>> IPv4 unicast indirectly-connected routes: >>>>>>>>> 272/2176 >>>>>>>>> 52/326 >>>>>>>>> IPv4 policy based routing aces: >>>>>>>>> 0/0 >>>>>>>>> 0/0 >>>>>>>>> IPv4 qos aces: >>>>>>>>> 528/528 >>>>>>>>> 18/18 >>>>>>>>> IPv4 security aces: >>>>>>>>> 1024/1024 >>>>>>>>> 57/57 >>>>>>>>> >>>>>>>>> Note: Allocation of TCAM entries per feature uses >>>>>>>>> a complex algorithm. The above information is >>>>>>>>> meant >>>>>>>>> to provide an abstract view of the current TCAM >>>>>>>>> utilization >>>>>>>>> >>>>>>>>> Hope this helps. >>>>>>>>> >>>>>>>>> On Thu, Apr 23, 2009 at 4:41 PM, Peter Rathlev >>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Thu, 2009-04-23 at 16:15 -0400, Chris Lane >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> This box has been in production for >>>>>>>>> over a >>>>>>>>> year >>>>>>>>> and doesn't really do >>>>>>>>> to much as you can see from my orig >>>>>>>>> thread it >>>>>>>>> moves about 11MB. >>>>>>>>> >>>>>>>>> This just started late last night yet we >>>>>>>>> didn't >>>>>>>>> add any new customer >>>>>>>>> nor did anybody even touch switch as the >>>>>>>>> device >>>>>>>>> is remote. >>>>>>>>> >>>>>>>>> I read in an older thread regarding same >>>>>>>>> thing >>>>>>>>> that the person >>>>>>>>> rebooted and of course it resolved >>>>>>>>> issue. I >>>>>>>>> am >>>>>>>>> planning to do that >>>>>>>>> Early tomorrow am, but >>>>>>>>> i really want to know what the heck is >>>>>>>>> causing >>>>>>>>> this. >>>>>>>>> >>>>>>>>> Yes CEF is running. >>>>>>>>> >>>>>>>>> What about TCAM utilisation ("show platform >>>>>>>>> tcam >>>>>>>>> utilization")? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> //CL >>>>>>>>> _______________________________________________ >>>>>>>>> cisco-nsp mailing list [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>>>>>> archive at http://puck.nether.net/pipermail/cisco- >>>>>>>>> nsp/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> //CL >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> //CL >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> //CL >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> //CL >>>>>> _______________________________________________ >>>>>> cisco-nsp mailing list [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>>>> >>>>> _______________________________________________ >>>>> cisco-nsp mailing list [email protected] >>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>>>> >>>> >>> >>> >>> >>> -- >>> //CL >>> > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
