Hi Erik,
Thank you for reading through the proposal. My responses are
in-line.
Thank you,
Clay
On Wed, 31 Mar 2010, Erik Nordmark wrote:
On 03/30/10 11:21 PM, [email protected] wrote:
Hi all,
I've been thinking over the approach to take for supporting a multihomed
AI server, as now, one faces the bugs below. Please let me know by
Wednesday April 7th, 2010 if you see any issues.
Thank you,
Clay
Problem:
--------
Today, the OpenSolaris Automated Installer makes many assumptions which
prevent widespread or simple use of a server running multihomed.
Bugs:
6182 - installadm tools doesn't support install servers which have
mutiple subnets
6922 - installadm create-service should have option to specify ip address
passed to dhcp config
7115 - Custom wanboot.conf files are ignored in AI servers with multiple
NIC cards
7148 - installadm should give correct dhcp macro for the subnet being
configured on the server
7149 - installadm should allow user to choose which subnets to use
Requirements:
-------------
There are a number of desires for multihomed support in the Automated
Installer, however, the requirements picked are based on perceived
technical capabilities and customer site needs:
* The solution must be automatic
* The solution must support one to all subnets served by the server
* The solution must not depend on routing between subnets (i.e. subnets
are otherwise isolated)
Areas of impact:
---------------
* DHCP
Unable to automatically determine the router for an
arbitrary interface for initial DHCP setup (i.e. installadm -i and
-c options will be unsupported on a multihomed system):
I don't understand why this issue is specific for a multihomed server.
In general, either the DHCP server is explicitly configured with the default
router options to return, or it has to infer/guess them from the kernel
routing table on the DHCP server. In the former case, the configuration would
have to be per interface. Are you concerned about the latter case?
On a single-homed server how do you infer/guess the router?
I can see using something functionally equivalent to
netstat -rn -f inet | grep UG
and looking at the gateway field, or
route get default
Such a technique can be extended to handle multiple interfaces. If the DHCP
server is configured with source-based routing (See the recent putback to
onnv - 4173841 Packet goes out with source IP address of another interface)
then the above becomes
netstat -rn -f inet | grep UG | grep $ifname
and looking at the gateway field, or
route get default -ifp $ifname
If it isn't configured to do source-based routing then you'd need to resolve
the gateway address (e.g., using the equivalent of route get) to find the
interface.
I didn't realize we could do source-based routing, that's very cool for
helping Solaris grow as a router platform, I'd imagine. Unfortunately, I
see many systems being configured much more simply, however, so that they
have one default route to the broader world and then simply use the local
interfaces to talk to a particular subnet and are not themselves
configured to forward or route traffic. As such, I don't think we can
depend on the Solaris host to know all necessary default routes.
Currently, for a single network, we assume the machine has the subnet's
desired default route and simply populate the result of parsing
netstat -rn.
SPARC:
Will provide an AI macro for each subnet
with differentiated BootFile location to provide the
correct IP for that subnet.
X86:
Will provide an AI macro for each service with a BootFile
location, however, it will be desired that an
administrator configure the BootSvrA location on a
per-subnet basis (i.e. in the network macro or some other
macro which is included for the clients' use)
(We will provide a template of Solaris DHCP commands as we do now,
however, IP addresses will need to be filled in by the admin as
it doesn't makes sense for us to become a multi-subnet DHCP
manager)
Is there a use case where the system will not be statically configured (but
configured with DHCP) where the admin doesn't want to specify the interface.
In such a case wouldn't the admin just want to say "this MAC address (or
client ID)" and have that apply to all interfaces on the DHCP server?
I'm not quite sure if I'm understanding your question correctly. I think
you're asking for a client configured via DHCP but where a DHCP
administrator does not want to specify what interface the client will
request on?
If so, that is envisioned to be handled by a nifty feature of the Solaris
DHCP server. The administrator will be advised to create a macro on the
server keyed off the client ID (MAC address). However, macros are served
off any interface the server is configured for. Lastly, the server will
overlay macros, so the client will get data such as router and boot server
from the particular network macro and then get the boot file info it needs
out of its client specific macro.
* mDNS
Will have a separate mDNS responder listening on each interface to
respond with the correct IP address to advertise for the AI
webserver and interface.
Possible solutions for this are to use the PyZeroConf[1] library
or writing a Python CTypes bridge to libdns_sd.so.
I think IPS will use pybonjour, thus it makes sense to look at it as well.
Ah very cool to hear they've come to use pybonjour. It seems to be a good
implementation taking advantage of the libdns_sd library opposed to
providing its own mDNS bits. Thank you for the pointer.
Erik
* GRUB
Will extend the install_media and install_svc_address fallback
mechanisms in slim_source's
usr/src/cmd/auto-install/svc/manifest-locator as delivered by GRUB
to flag for using dhcpinfo(1) instead to locate which machine
provided the boot server via DHCP and use that IP address.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
