[c-nsp] ISR G2 Interface RX Performance

[Nathanael Law]

Thank you all for the pointers and suggestions.

On Fri, Jan 25, 2013 at 19:38 MST, Blake Dunlap wrote:
> Another option is lightly shaping out from the switch if you don't
> want to upgrade immediately down to a more absorb-able rate for the
> router platform. You're probably barely breaking the threshold just
> due to the arrival rate, and I've had success solving this in this
> manner for a client in the past who didn't want to spend. Just be
> aware of the jitter this will introduce as a consequence.

Unfortunately, the 3750 doesn't support shaping and it's the only
other network device in the path to the 3925.  This did get me thinking
about shaping more and we've managed to work around the issue by manually
setting the link speed to the source device to 100 Mbps.

On Fri, Jan 25, 2013 at 20:12 MST, Andrew Miehs wrote:
> You could possibly try enabling flow control on the interfaces - 
> although i have no idea if this would help in your situation.

Unfortunately, flow control looks like it's not supported on the
3900 built-in interfaces:

3925# show int gi0/0 | inc flow
  output flow-control is unsupported, input flow-control is unsupported

On Sat, Jan 26, 2013 at 03:01 MST, Richard Clayton wrote:
> I have some lab stress test results for the whole ISR G2 platform
> which I can share with you if you like, a quick look at the 3925
> with a traffic profile of G711 and packet marking (you would 
> probably have marking in a voice environment with QoS applied) 
> shows the cpu at 75% whilst it is passing 280Mb.

I'd be very interested in the lab results if you are able to share them.
Our traffic has an average IP packet size of 186 bytes, so it's probably
in the same range as your voice traffic.

> What is the realtime traffic in question?

Sorry, I'm abusing the term "real-time".  It's syslog data that 
we don't want to miss heading to various operational and security log
servers.  We've tried TCP syslog, but there are so many packets lost
that the source just decides the TCP syslog destination is down.

On Sat, Jan 26, at 12:23 MST, Gert Doering wrote:
> Since this is a software box, try increasing the interface hold-queue
> ("int g0/0 -> hold-queue 1000 in")

Thank you for the suggestion, Gert.

The input queue drop counter is not increasing at all during the packet
loss we are experiencing, so I have my doubts about the hold-queue
affecting the issue.  I.e., the packet loss appears to be occurring 
before the packets reach the input queue.  I will test this, however.

I'm getting a UN*X box set up at that location with hping and scapy so
we can approximately reproduce the traffic profile on-demand.

I'll post the results once we have them.

Best regards,

Nathanael Law