On 03/ 5/09 05:04 PM, Dave Miner wrote: > Steven Lau wrote: >> On 03/ 5/09 04:31 PM, Dave Miner wrote: >>> Sundar Yamunachari wrote: >>>> Dave Miner wrote: >>>>> Evan Layton wrote: >>>>>> Hi Sundar, >>>>>> >>>>>> Looking at what we're doing in setup-dhcp.sh and how the dhcp >>>>>> server needs to be set up it appears that in order to create the >>>>>> proper macro we have to have the default router for that subnet >>>>>> we are attempting to configure. However if the subnet we're are >>>>>> attempting to configure is not the same as the default router on >>>>>> the server we have no way to determine the router for that subnet. >>>>>> >>>>>> Based on this I've found no way to do any kind of automated >>>>>> configuration of all the subnets on the system. The best I can >>>>>> think of to do for this bug is to print out a message telling the >>>>>> user that we found other subnets and if they wish to configure >>>>>> those for dhco they will have to do it manually. We can generate >>>>>> at least part of the macro needed however since we need to >>>>>> default router for the subnet to do this we can only give an >>>>>> example and not a fully functional command. >>>>>> >>>>>> Does anyone have any ideas on another way to handle this or to >>>>>> gather the default router for all the subnets on the server? >>>>>> >>>>> >>>>> Well, strictly speaking a router (default or otherwise) is only >>>>> required if you need to communicate with systems which are not on >>>>> your local link. If the install server is connected to the link, >>>>> then installation should work just fine without any router being >>>>> configured. Thus I'm not sure what problem you're concerned about >>>>> here? >>>> The bug report mentions that the clients in the second interface >>>> subnet is getting the router that is in the first interface. This >>>> is because the installadm code picks up the default router for >>>> system and setup the DHCP macro and the client cannot access the >>>> router. >>>> >>>> From the bug report: >>>> >>>> nic1 192.168.1.1 ---> router 192.168.1.254 --> connected to internet >>>> nic2 192.168.2.1 ---> router 192.168.2.1 --> private network >>>> >>>> Our macro have router as 192.168.1.254 where as the submitter >>>> wanted 192.168.2.1 as the router. >>>> >>>> By creating network macros for each subnet 192.168.1.0 and >>>> 192.168.2.0, we can ensure that the client gets the correct router >>>> >>> >>> So, create the macros, but if you don't have correct router >>> information, then just don't configure it into the macro initially. >>> Alternatively, you may be able to configure the install server as >>> the router and let ICMP redirects cause the , though that might need >>> some testing to verify it works. If the user wants/needs to >>> configure the Router into an existing macro he'd then just need to do: >>> >>> dhtadm -M -m <network macro> -e Router=<address> -g >> Hmm ... our group setup an AI server with four network interfaces >> serving 4 different subnets. We use the dhcp macros in our dhcp >> server as following ... we never put Router record in the entry in >> this case and it seems work for us. ... So I am not sure if we >> should add Router record by default .... >> >> ----- >> b01h Macro >> :Include=dns-info:BootFile="http://xxx.xx.241.xxx:5555/cgi-bin/wanboot-cgi":BootSrvA=xxx.xx.241.xxx: >> >> >> Rootpath="http://xxx.xx.241.xxx:5555/platform/images/osol-0906-106a-ai-sparc": >> >> >> >> b44e Macro >> :Include=dns-info:BootFile="http://xxx.xx.248.xx:5555/cgi-bin/wanboot-cgi":BootSrvA=xxx.xx.248.xx: >> >> >> Rootpath="http://xxx.xx.248.xx:5555/target/images/osol-0906-106a-ai-sparc": >> >> > > Are you certain that a default router isn't being supplied through > some other macro (there are others automatically used by the server, > and in both cases you also have inclusion of the dns-info macro, which > may in turn include others)? I confirm dns-info macro only contain DNS server names and DNS domain name records .... not including any Router record ...
BUT, I have some other macro did using Router, which used by other non-AI clients .... As you said, the dhcp might already registers the Router record info for the 'whole' dhcp server .... > The only way to be certain is to examine the client's configuration > once booted using netstat -nr; xxx.xx.241.xxx indeed is our 241 subnet router .... root at opensolaris:~# netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default xxx.xx.241.xxx UG 1 15 bge0 > you can also use /sbin/dhcpinfo Router to determine whether DHCP did > in fact supply a router. Tried on our dhcp server and failed .... ==> /sbin/dhcpinfo -i ce1 Router /sbin/dhcpinfo: connect: Connection refused ==> /sbin/dhcpinfo Router /sbin/dhcpinfo: connect: Connection refused > > Dave
