That is what I was afraid of. I guess I can put the DTUs in their own subnet if needed.
Do you know if they will only broadcast to their own network (ie, DTU IP is 99.99.28.10/16, will they only broadcast to 99.99.255.255), or do they eventually try 255.255.255.255 for broadcast also? -Jon ----- Original Message ----- From: "Paul Winder" <[email protected]> To: "SunRay-Users mailing list" <[email protected]> Sent: Friday, October 28, 2011 9:59:13 AM Subject: Re: [SunRay-Users] Broadcast Discovery Nothing avoids the broadcast .... it _always_ happens after every other option, including DNS is exhausted ... Paul Jonathan C. Bailey wrote: > I've got multiple FOGs, so I don't want to employ the DNS solution (we > actually did the DNS setup at one point and removed it). > > What would happen if I supplied a blank X servers or AltAuth list? I assume > params first, then fail when AltAuth is blank? Or does the DTU treat a blank > AltAuth as non-existent (and continue on)? > > -Jon > > ----- Original Message ----- > From: "Jörg Barfurth" <[email protected]> > To: "SunRay-Users mailing list" <[email protected]> > Sent: Friday, October 28, 2011 9:39:42 AM > Subject: Re: [SunRay-Users] Broadcast Discovery > > Jonathan C. Bailey schrieb: >> I've finally had a chance to put Wireshark on it and see what exactly >> is happening. >> >> My network is (anonymized) is 99.99.0.0/16. I split it off into >> multiple /24s with DTUs for each FOG in their own /24. I then use ISC >> DHCPd (on a server unrelated to the Sun Ray environment) to issue IPs >> and hand out a "tftp-server-name" appropriate for each subnet. >> Normally the DTUs grab the parms file off the specified TFTP server >> (which contains server IPs), and everything is happy. If the TFTP >> server is down, however, then they go into broadcast mode looking for >> *any* FOG in the /16. >> >>> From the discussions here, it sounds like broadcast discovery has >>> to be explicitly enabled (by adding a wildcard to the AltAuth >>> list). I'm only doing "utadm -L on" on the hosts and not >>> configuring an interconnect (and by extension, DHCPd) that would >>> publish the AltAuth list. This makes it seem that broadcast >>> discovery is default if no AltAuth list exists and the config >>> server can't be reached. > > It is. > >> This is the specific behavior I would like to disable. >> > > [Disclaimer: All he following is if I recall correctly. Please test > yourself.] > > IIRC a server list in option 49 (X Window servers) from DHCP is treated > like an AltAuth custom option. > > If you have both a 'servers' list (from the .parms file) and option > 49/AltAuth, the 'servers' take precedence, but if none of them is used > the AltAuth list will be checked as well. > > (Of course the lists could even be the same) > > Another option might be to set up DNS to resolve the 'sunray-servers' > name, but I'm not completely sure, if that helps to avoid broadcast, if > the resulting IP address doesn't respond.. > >> I may just end up opening a SR for this, but I want to bring this to >> the public list first to help people in the future that have the same >> situation. Thanks! >> > > HTH > > - Jörg > _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
