On Wed, May 13, 2015 at 12:29:00AM +0800, d tbsky wrote:
2015-05-12 20:07 GMT+08:00 Flavio Leitner <fbl(a)sysclose.org>:
> Connecting directly offers some challenges because some NICs have
> WoL enabled, so even when the other side is down, the link is still
> up, so you get a wrong status.
> The "ethtool" relies on the NIC to report the link connectivity. If
> you are talking to another host and the WoL is disabled, etc, it might
> be good enough. But if you are talking with a switch, then it's
> limited to the link between the host and the switch, while the
> arp_ping will check the full path between peers. The cost is
> sending/receiving packets at a fixed period of time.
> You could also use arp_ping for back-to-back connection because that
> would also check not only if the link is functional but also if the
> host can process the packet and reply back.
never thought about the wol thing. I think I should use "arp_ping"
to make sure the link status is correct.
and I don't know if it is a good idea to use "roundrobin" under teamd?
any better options to handle both bandwidth and failover under teamd?
It depends on the use-case. If you are running TCP sessions,
round-robin may cause a huge amount of re-ordering and that can
trigger the congestion algorithm to slow down a bit.
On the other hand, it doesn't matter from UDP perspective, so you
get more throughput with using round-robin.
Another possible solution is using 802.3ad/LACP, because then you
have the streams fixed per port which avoid the re-ordering problem
but you also have parallel streams in different ports to improve
total throughput. LACP also exchanges LACPDU packets to make sure the
other peer is functional.