Actually I'd find it likely that the bonding driver doesn't care about maintaining packet order with multiple active inputs on a single instance.
-Blake On Thu, Mar 19, 2015 at 6:46 AM, Steve Teti <[email protected]> wrote: > On 2015-03-19 9:21 AM, Phil Mayers wrote: >> >> That's kind of odd. 0.2ms on that kind of loading makes it surprising >> there's reordering. Where *is* that packet for 0.2ms? >> >> I was wondering if it was a port asic grouping / buffering thing, with >> packets from other ports on the SPAN ports own ASIC arriving "early", >> but the times and bandwidths, gut feeling says not. >> >> Odd. > > > On the one specific example that I was able to capture, the out-of-order > exchange is happening between two machines on Gi1/0/12 and Gi1/0/14 (same > port ASIC group I think?). The monitor destination port is Gi2/0/10, the > other switch in the stack. > > I haven't ruled out the possibility that the capture server is actually > reordering the packets somehow. The capture server has two NICs connected > to two different SPAN sessions. The two NICs are bonded with Linux ethernet > bonding, mode 3 (broadcast). The out-of-order packets show up when > capturing on the bond0 interface and the physical ethX interface. I think > I'm going to have to try removing the bond configuration completely and just > capturing on the one physical interface. > > _______________________________________________ > 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/
