Hi Erik,
Thank you for taking the time to continue working through this
with me! My comments below.
Thank you,
Clay
On Wed, 7 Apr 2010, Erik Nordmark wrote:
On 04/ 1/10 11:41 AM, [email protected] wrote:
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.
Actually, routers would never use this. Sounds like I didn't explain it well
enough. But I have a more fundamental question below.
Yes, I see I was misunderstanding source based routing after clarifying my
terms.
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.
How does this work if the single-homed server is running in.routed or quagga
and netstat -rn doesn't show a default route?
My point is that I think you end up making assumptions or requirements on the
server's routing configuration even in the single-homed case.
Given that, why can't you make such assumptions/requirements in the case of a
multihomed server?
Yes, we do make assumptions of a deafult route. If the machine does not
have a static route as discoverable by 'route get default' or 'netstat -rn
|egrep "^default "' then we will fail to properly setup DHCP with a router
macro at this time. However, we will advise the administrator with the
following to try and proceed gracefully:
Unable to determine the proper default router
or gateway for the X.X.X.X subnet. The default
router or gateway for this subnet will need to
be provided later using the following command:
/usr/sbin/dhtadm -M -m X.X.X.X -e Router=<address> -g
We hope to provide a setup automatically for the administrator but I don't
know how we can provide a more automated solution for unusual routing
configurations, such as for a multi-homed system ignorant of some of its
networks' default routes. As such, I believe such a solution as we do
today for advising how to add the router macro is the best way. Unless,
there are some ideas on how we can provide this information for the
user along the lines of the 80%/20% rule or better?
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?
Correct. The admin just wants to say "let this MAC address (or client ID) get
an IP address assigned based on the interface on which you hear the DHCP
packets".
That is my hope for automatic setup. The administrator need not provide
any information to create the client and as long as they have properly
setup their network infrastructure (minimum networking information in DHCP
-- router; DNS server, if desired) then the client should just work.
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.
OK
You said above that the "IP addresses will need to be filled in by the
admin", and it seems that wouldn't be needed in the above case.
Can you explain in what cases the admin would have to fill in the IP
addresses?
The IP addresses necessary for the administrator to provide would only be
router addresses.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
