Hi all, this is a continuation of a discussion I started with Victor Nelson and Peter Memishian in private. I am continuing it on the list as per Victor's suggestion (thank you for suggesting this, I am very much in favor of open discussions).
The context is that I had written a fix for 6667021 which is about in.dhcpd invalidating its own offers when being run in an IPMP configuration or any other configuration where in.dhcpd is bound to two IP addresses from the same broadcast domain. The effect is that dhcpd does not seem to respond and clients time out without ever getting an address. Peter's and Victor's argument is that Clearview would obsolete this fix. I agree that it would for the normal IPMP case, but I am trying to convince them that there might be more scenarios to consider which would justify integrating the fix, IMHO. This is where we're at, here's the ongoing discussion (quotes will give you more context): > > I've had a brief look at > http://cr.opensolaris.org/~meem/clearview-ipmp-cr2/ > > > > I have not yet reviewed the whole thing - at the moment I cannot afford to > do > > such a huge review as voluntary work, but I am very sure that it does not > fix > > the issue, it will just avoid it to surface for most cases. > > > > My main point is that though clearview will eliminate the worst issues > > regarding in.dhcpd on IPMP by implementing a single IP interface for an > > IPMP group, the bug I have been working on is relevant whenever > > in.dhcpd listens on more than one interface of the same broadcast > > domain. This issue even exists if you use several virtual IP addresses > > on the same physical i/f with or without old IPMP, with or without > > Clearview new IPMP. > > Please be aware that having multiple IP interfaces configured on the same > link-layer broadcast domain without IPMP is unsupported -- and one of the > major reasons is because of duplicate broadcast/multicast. Agree. But what about "logical interfaces" (ifconfig addif)? in.dhcpd can (and in some situations must) be bound to those and you'll get exactly the same issues as with IPMP. One case where you must bind in.dhcpd to more than one logical interface on the same physical i/f is when, for instance for transition phases, you are forced to provide addresses for more than one IP net on the same link-layer. To fix this issue, Clearview does not help. > > Could you please reconsider my suggested fix which is available at > > > > http://cr.opensolaris.org/~nigoroll/6667021_dhcpd_purge_own_offer/ > > > > Please note: An optimal solution was to change in.dhcpd to remember all > the > > offers which have been sent out for an individual DHCPDISCOVER, which I > have > > considered, but not implemented because I think it was not worth it. > > > > My suggested change fixes the worst problems and has been proven to work > in > > practice (on production systems). > > > > Also, I don't know about how plans are to backport clearview to older > > Solaris Versions - my fix works also without clearview so this might be > > another reason to consider it again. > > You're right, there are no immediate plans to backport Clearview IPMP. > However, as far as OpenSolaris is concerned, as above, the only supported > configs in which this issue can arise will be addressed with Clearview > IPMP. I disagree in that I don't see why running in.dhcpd on locical interfaces should be desupported. > I'm not convinced it makes sense for us to spend time integrating a > fix into e.g. build 103 that will be rendered unnecessary only a few > builds later. There would still be a reason for this fix even after Clearview integration, see above. > Further, suppose we work together to get your fix into > build 103. Without a customer escalation (perhaps you can do this?), the > organization inside Sun responsible for backporting to Solaris 10 will not > pick it up -- and even with an escalation, the work will need to be > prioritized relative to all other escalations. (Yes, it's frustrating, > but unfortunately resources are finite.) I'd be very surprised if none of the various IPMP&dhcpd bugs (follow the links of 6667021 or search for "IPMP in.dhcpd") had open escalations already. But unfortunately, I'm outside SWAN so I can't see them. If it was important to get another escalation, that wouldn't be a problem. I have a customer running my fix with s10 who would want this and I know of others who abandoned Solaris in.dhcpd because of this issue. Also if there are no plans to backport Clearview to s10 and older, it's only a matter of time until the next customer opens a case on this issue. in.dhcpd is even supported in Sun Cluster and Sun Cluster MUST use (old fashioned) IPMP, so without the fix, Sun Cluster and IPMP simply will not work properly. Nils _______________________________________________ networking-discuss mailing list [email protected]
