Just guessing: for PBR you need netflow-like TCAM entries, so the first packet in the flow is always processor-switched and then the subsequent packets can be hardware-switched. Does this make sense to the switching gurus?
Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Rodney Dunn [mailto:rod...@cisco.com] > Sent: Thursday, June 18, 2009 8:35 PM > To: Peter Rathlev > Cc: cisco-nsp > Subject: Re: [c-nsp] Redirects / hair-pinning traffic vs. performance > > Curious..I don't know that platform forwarding architecture. > > But what does 'sh int stat' give you? > > Also, sh ip traffic a couple times once you start the traffic. > > > On Thu, Jun 18, 2009 at 07:13:02PM +0200, Peter Rathlev wrote:lso > > > On Thu, 2009-06-18 at 00:01 +0000, Peter Rathlev wrote: > > > I have the need to introduce some PBR to solve a > hopefully temporary > > > problem. Some of the traffic being routed will leave the same > > > interface as it arrives on. > > > > > > My worry is if this would have any performance impact the traffic > > > arrives on and leaves from the same interface. I could > imagine that > > > some forwarding implementations might penalize this scenario. > > > > Follow up: We've tested this and it works fine. It seems to > have some > > CPU impact when the unit policy routes, but not much. When > pushing 100 > > mbps traffic through the CPU rises to ~25-30% for a few > seconds (spent > > on interrupt switching) and then falls down ~5% again. > > > > This might be PBR-specific and have nothing to do with the traffic > > arriving on and exiting the same interface though. We will be doing > > some more (production) testing soon, with more flows and more > > bandwidth. I can't see why the number of flows should > matter since the > > 3560 AFAIK just pushes packets, but I also can't see why > the start of > > a TCP session should matter. The "ip route-cache" hasn't > been disabled > > of course; I assume this would have a detrimental effect on > performance. > > > > Regards, > > Peter > > > > > > _______________________________________________ > > 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/ > > _______________________________________________ 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/
