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.
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]
