16 messages in net.nether.puck.cisco-nsp[c-nsp] Better way of finding out the...
FromSent OnAttachments
Dave TemkinJan 27, 2005 7:42 am 
Joe MaimonJan 27, 2005 8:17 am 
Dave TemkinJan 27, 2005 8:27 am 
Jason AckleyJan 27, 2005 8:43 am 
Dave TemkinJan 27, 2005 8:44 am 
Rodney DunnJan 27, 2005 8:54 am 
Dave TemkinJan 27, 2005 8:57 am 
Rodney DunnJan 27, 2005 9:09 am 
Dave TemkinJan 27, 2005 9:14 am 
Dave TemkinJan 27, 2005 9:17 am 
Rodney DunnJan 27, 2005 9:21 am 
Dave TemkinJan 27, 2005 9:28 am 
Rodney DunnJan 27, 2005 9:33 am 
Dave TemkinFeb 1, 2005 6:47 pm 
Rodney DunnFeb 1, 2005 7:30 pm 
Dave TemkinFeb 1, 2005 8:51 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] Better way of finding out the source of process switched traffic?Actions...
From:Dave Temkin (da@ordinaryworld.com)
Date:Jan 27, 2005 8:57:49 am
List:net.nether.puck.cisco-nsp

Thanks Rodney.

The one thing I'm hesitant to blame it on is the fact that the actual NAT'ed traffic is very very little (it's AIM conversations, that's it). So I'm wondering why on a box that's as big as this one (NPE-400) it'd choke on that...

-Dave

On Thu, 27 Jan 2005, Rodney Dunn wrote:

Your problem is almost surely that the packets being punted are TCP control packets where we punt to create/tear down the translations. SYN, FIN, RST.

If you want to see the packets at process level you can either turn on: debug ip packet <acl> to limit the granularity of the debug since that only prints packets at process level. /*not true for 12.2S with the right commands*/

You can also do "sh buffers input-interface <name> packet" a few times and catch some packets in the buffer and manually decode the TCP header to see if the flags are set in the header.

Now, in 12.3(4)T and later we made some NAT enhancements where we create the flows in the CEF path without punting traffic. That is the suggested way to go if you are seeing a high number of process switched traffic with NAT enabled.

Rodney

On Thu, Jan 27, 2005 at 07:42:33AM -0500, Dave Temkin wrote:

I've got an internet-facing router that's seeing a very high rate of process switched traffic. Nothing too crazy is configured on this router - a little bit of NAT, a couple of route maps, BGP. That's about it. Aside from doing a debug ip packet and killing the router (it's passing about 30-40mbit of traffic), are there any other options for tracking down what's in the process queue? Router is running 12.3.6a

FastEthernet0/0 Throttle count 4 Drops RP 5 SP 0 SPD Flushes Fast 3103 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 83215964 Drops 0

Protocol IP Switching path Pkts In Chars In Pkts Out Chars Out Process 1803602701 4025634609 1661069368 456573125 Cache misses 0 - - - Fast 2713542052 1802705001 3837108389 304620460 Auton/SSE 0 0 0 0

FastEthernet1/0 Outside Throttle count 0 Drops RP 0 SP 0 SPD Flushes Fast 1796 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 6927146 Drops 0

Protocol IP Switching path Pkts In Chars In Pkts Out Chars Out Process 543622379 2397426796 317919218 1743487367 Cache misses 0 - - - Fast 3071349692 1923264716 1211037578 2505497398 Auton/SSE 0 0 0 0

FastEthernet2/0 Outside 2 Throttle count 0 Drops RP 0 SP 0 SPD Flushes Fast 1480 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 42435822 Drops 0

Protocol IP Switching path Pkts In Chars In Pkts Out Chars Out Process 1056561152 1934756549 1414955036 1939153311 Cache misses 0 - - - Fast 819752907 318162363 1502399074 1302221329 Auton/SSE 0 0 0 0

! interface FastEthernet0/0.101 encapsulation dot1Q 101 ip address x.x.x.x x.x.x.x.x no ip redirects no ip proxy-arp ip nat inside ip policy route-map RM101 no cdp enable standby 101 ip x.x.x.y standby 101 timers 1 3 standby 101 priority 250 standby 101 preempt standby 101 name HSRP101 !

! interface FastEthernet1/0 description Outside 1 ip address x.x.x.x x.x.x.x ip access-group Yipes-Outside in ip nat outside load-interval 30 duplex full ntp disable hold-queue 300 in hold-queue 300 out