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)? The only way to be certain is to examine the client's configuration once booted using netstat -nr; you can also use /sbin/dhcpinfo Router to determine whether DHCP did in fact supply a router. Dave
