On 09/14/2012 05:37 AM, Brent Chapman wrote:
Aggregated network links involving multiple parallel circuits
generally use some sort of hash on the 5-tuple (src ip, dest ip,
protocol, src port, dest port) so that packets for a given TCP or UDP
session all get sent down the same parallel circuit; this is an easy
way to help ensure that the packets don't get re-ordered, which many
protocols are sensitive to. However, if the particular "same parallel
circuit" that they get sent down is broken, as appears to have been
the case here, you can wind up with behavior like what you saw:
certain sessions (that happen to get hashed down those broken
circuits) break horribly, while others (that get hashed down
non-broken circuits) are just fine.
I've never really delved into the networking aspects of aggregation,
it's never been something I've had any need to utilise, so forgive me if
these are stupid questions.
Under circumstances with which a port goes down, would the link
aggregation generally be fine? The system would presumably be smart
enough identify that the port isn't working and stop routing traffic
that way? I'm assuming the failure in this case is that the packet loss
was too slight enough to disrupt the aggregation, but disruptive enough
to mess things up?
Why would this disrupt TCPs guarantee processes (admittedly I'm assuming
the application traffic was TCP and not UDP)? Presumably the packet
would fail to reach the other side so the sender would resend having
failed to get an ack?
Paul
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
