On Fri, Nov 13, 2009 at 12:31 PM, Nils Goroll <[email protected]> wrote: > Hi Erik and all, > > I am sorry for this very late comment, I should have replied during the > review > phase, but I didn't get to it. It's only been today that I got reminded by > the commit notification and read through the PSARC emails and some of the > discussion in networking-discuss. > > I didn't want to post on psarc regarding a closed case, so I am posting on > networking-discuss. > > First of all, two questions on the new source IP selection: > > - Will it still be possible to use routing entries to force use of a certain > source address by destination? I've seen a couple of installations making > use > of this. > > - Will explicit source address selection via in_pktinfo_t sill work? I am > looking after a couple of customer cases descending from a (very) old case > regarding source address selection for RPC over UDP with (pre-clearview) > IPMP > and I would very much like to see them get closed one day (greetings to > everyone involved in those cases, you'll know what I am referring to). > >> Due to the ARP/IP merge and uniform application of Neighbor Unreachability >> Detection (RFC 4862) ... > > I would like to mention that a long time ago I had to debug weird behavior > of a > certain firewall HA solution which used multicast MAC addresses for unicast > IP > addresses in order to achieve load spreading and uninterrupted service by > having > hosts send all traffic to all nodes of a cluster (the interfaces of nodes > were > members of the same multicast group and ARP requests for the unicast > "cluster IP > address" were answered with the MAC address corresponding to that multicast > IP > address). > > This certainly is quite an exotic case (and an approach which, friendly put, > I > didn't find particularly clean) and I am not sure if such applications still > exist, but it might be relevant to check if the refactored code could handle > this properly.
Actually.. this sounds almost exactly like how Windows Network Load Balancer still works (when the multicast option, which I believe is recommended). I've seen it at least in the context of load balancing portions of exchange, so it might not be as rare as you think. > >> Currently Solaris handles IP interface MTU in odd ways in that it can be >> set differently for local IP address prefix; this leaves it quite >> undefined >> in what MTU is applied to multicast packets. >> This project fixes that by applying the IP interface MTU per interface. >> As a result ifconfig bge0:N mtu 1400 will fail with EINVAL. > > IIRC, I've used the now discontinued behavior as a simple and flexible > configuration on GigE networks with jumbo frames supported by *some* hosts > only. > By using logical addresses on the server with different MTUs, clients could > select between "default MTU" and "jumbo frame enabled" server addresses, > which > was really useful for optimizing performance for UDP based applications (I > am > generalizing, I only ever used this for NFS/UDP). > > From an administrator's standpoint, the advantage of this configuration was > that no client IP specific configuration was involved as with setting routes > with -mtu. > > I am aware that the particular customer installation I am talking about here > is > not clean in the sense that, if jumbo frames are used on a broadcast domain > they > should be supported by all devices, but sometimes it is hard to convince > users > to implement a clear design when what they have is just working for them and > changing things would imply significant additional cost. > > My questions are: > > * Could you please explain why, in the former implementation, it was not > well > defined which MTU was applied for multicast packets? > > * Why would it cause any harm to keep an interface MTU for locical > interfaces? > My understanding is that > > - for unicast packets, the effective MTU would be the minimum of the MTUs > of > the locical interface, the physical interface, the destination ire and > the > destionation IP > > - for multicast packets, the effective MTU would be the minimum of the MTUs > of > the locical interface and the physical interface > > Most likely, my understanding is wrong due to a lack of insight into the > implementation, so I'd really appreciate a more elaborate explanation. > > Also, my comment is completely obsolete if there is an easy way to achieve > similar behavior as described above which I don't know of. > > > Thank you, Nils > > > _______________________________________________ > networking-discuss mailing list > [email protected] > _______________________________________________ networking-discuss mailing list [email protected]
