On 10/12/2011 3:28 PM, richard Croucher wrote:
I understand that's it not good practice however I'm seeking to
understand whether actual problems have been observed.
The only issues I can suggest will be because of ARP is in the shared
broadcast domain. Is there any IPoIB state in the SM other than
QoS? I can't think of any reason why there should be. Even though
ARP requests will be seen by interfaces in a different subnet, they
should not respond with it's GUID since they will not match the
requested IP address.
wrong, see
http://lxr.linux.no/#linux+v3.0/Documentation/networking/ip-sysctl.txt#L926
I think this refers back to behaviour seen many years ago, when
multihomed hosts were rare. There was a tendency for them to respond
on all interfaces to ARP requests for their nodename and cause ARP
resolution problems.. Is there a reproducable test case of this
problem, since I certainly know of systems which are configured like
this and appear to be working fine. Maybe, they've just been lucky,
but so far I've seen numerous messages saying don't do it and none to
say what actually goes wrong.
For basic testing and/or PoC you can set net.ipv4.conf.*.arp_ignore to
1 or alike (2). For production, I wouldn't
do that or at least do it after conducting a deeper study (I gave you
the heads-up, so please share your findings...),
Indeed, I know that in the iscsi multipathing world people use
multi-homed NICs on the same IP subne, though.
Or.
_______________________________________________
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
