[Resending to see if it makes it to the list]
-------- Original Message --------
Subject: Re: [caiman-discuss] Multihomed AI Proposal
Date: Wed, 07 Apr 2010 06:21:24 -0700
From: Erik Nordmark <[email protected]>
To: [email protected]
CC: Erik Nordmark <[email protected]>, [email protected]
On 04/ 1/10 11:41 AM, [email protected] wrote:
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.
Actually, routers would never use this. Sounds like I didn't explain it
well enough. But I have a more fundamental question below.
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.
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?
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".
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?
Erik
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
