This approach would work fine, assuming the slave devices are the same
type, and you can control both client and sender in a configuration like:
|----|----subnet1---|----|
|Box1| |box2|
|----|----subnet2---|----|
(Beowulf is an excellent example of this)
The follwing is also an interesting topology:
|----|----subnet1--| |----|
|Box1| |--subnet3---|box2|
|----|----subnet2--| |----|
where Box1 stripes across 2 devices and the free capacity of subnet1 plus
subnet2 is less than the free capacity of subnet3. Under the assumption
that the 2 striping devices are using the same hardware header, who
replies to an arp from box2? I feel uncomfortable with the answer "both
striping devices". More generally, It would be nice to remove the
restriction that subnet1 and subnet2 be the same kind of subnet.
How does this sound for an alternative:
1. Move the hardware header construction process from the bottom of the
IP layer to the top of each device driver.
2. Make the route cache for IP source/destination pairs allow multiple
entries indexed by transmission device.
Then ipeql would never have to worry about hardware headers because the
slave devices would build them, using the expanded route cache.
I was under the impression that equal cost multipathing did something like
this.
-John Langford