Last week, I posted a message, where I asked for help with NIS-problems
on a subnet with a 255.255.254.0 netmask.
Here's a part of my original message:
> The Network-group decided to use a 255.255.254.0 netmask in the
> subnetted network. After the change of netmasks and IP-numbers
> almost everything worked O.K., except NIS on the diskless Sun's.
>
> We changed the netmask in the local /etc/netmask and the NIS netmask-map and
> in /etc/rc.local on the diskless client we configured ifconfig as follow:
>
> ifconfig -a netmask + > /dev/null
> ifconfig le0 broadcast xxx.xxx.81.255 > /dev/null
>
> During the clients boottime we get a "NIS server not responding for domain..",
> after ypbind is started in /etc/rc.local.
Some people asked if I had a NIS-server on the subnet, because broadcasts
are generally not forwarded by routers. Well, we have a NIS-server on the
subnet, so that was not the problem.
Another response said that we should have 0-broadcasts. If you only have
Sun's on your subnet, it is probably OK to use 0-broadcasts. But we
have a heterogene network, so we must have 1-broadcasts.
Kevin Elphinstone (kevine@vast.unsw.edu.au) suggested the following:
> The problem was solved by giving all the diskless clients a hostname.le0
> file just like on the diskfull machines. /etc/rc.boot looks for this
> particular file and runs ifconfig appropriately. It seems that if this
> initial ifconfig is not done, then changing the broadcast address later
> in rc.local breaks yp? I don't know why this is the case, this was just
> a quick fix I stumbled across.
We didn't try it, but I think it will work.
Stefan Turowski's <Stefan.Turowski@informatik.uni-erlangen.de> answer was the
best, and it solved our problem:
> Did you check the routing tables after the ifconfig's ?
> What I found out, is that the Sun does not enter the correct entry for
> an interface in its routing tables.
> This in turn will cause all broadcast packets to be send to the default
> gateway and if this is not a Sun _and_ a NIS-Server the NIS binding fails.
This was exactly what happened. With a traffic-analyzer we observerd traffic
between the NIS-client and the Cisco-gateway.
> Solution:
> ifconfig -a netmask + broadcast + > /dev/null
> ifconfig le0 broadcast xxx.xxx.81.255 > /dev/null
> (the first ifconfig defines an incorrect broadcast address, but a
> correct routing table entry.)
I changed the /etc/rc.local and it worked.
Well folks, thanx again for the quick response.
Jaap
Credits:
Ron Wessels <ron@turing.toronto.edu>
Barry Margolin <barmar@Think.COM>
Manfred Kwiatkowski <kwia4000@wncs.zrz.TU-Berlin.DE>
mills@ccu.UManitoba.CA
Kevin Elphinstone <kevine@vast.unsw.edu.au>
Stefan Turowski <Stefan.Turowski@informatik.uni-erlangen.de>
S.vanderZee@research.ptt.nl (Siebren van der Zee)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:42 CDT