[c-nsp] Redirects / hair-pinning traffic vs. performance

[Ivan Pepelnjak]

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:rodunn at 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 at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
>