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": ---- -Steven > > Dave > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
