RIS Works 1/2 Of The Time

[sporup]

I have a single domain with 2 DHCP servers that are both authorized and
handing out non overlapping scopes on the same subnet. Lets call them
SERVER1 and SERVER2. SERVER1 is also my RIS server. When a client
gets an IP address from SERVER1, RIS works fine. When the same client
gets an IP address from SERVER2 the client is not able to find the RIS
server and errors out. Any suggestions?

 

[NIC Student]

Hmm, are your dhcp servers set up as follows:

1. both servers hand out addresses on the 192.168.1.x subnet (for example)
2. both servers have the same scope of addresses
3. server a has excluded the addresses that server b hands out and vice
versa?

My first thought is that you have two dhcp servers that do not hand out the
*same* range of addresses, differentiated by the exclusion ranges... ie

server a address range 192.168.1.100-200
excluded 192.168.1.150-200

server b address range 192.168.1.100-200
excluded 192.168.100-149

Your client will get a NAK from the ris/dhcp server in the above scenario,
halting the RIS process.

 

[sporup]

Let me try to explain my setup a little better. Server1 DHCP scope is
10.11.8.1 - 10.11.10.254 and the scope on Server2 is 10.11.11.1-254
both with 255.255.252.0 as the subnet mask. All of my static address
fall in the 10.11.10.x range including the servers which is excluded.
I hope that helps.

Jack

 

[NIC Student]

Jack,

I think your dhcp should be configured as follows to get RIS working between
both servers:

server1
scope 10.11.11.1-254/22 scope active but all addresses excluded
scope 10.11.8.1-10.11.10.254/22 all active

server2
scope 10.11.11.1-254/22 all active
scope 10.11.8.1-10.11.10.254/22 scope active but all addresses excluded

From what you told me, when dhcp2 gives out an address, the client gets a
dhcp2 address and then asks for pxe info using dhcp as the transport but
your RIS server dhcp1 will not reply since he has no scopes active for the
client's address range.

I assume that your RIS server is not multihomed.

 

[sporup]

None of my servers are multihomed. I changed the scopes on both DHCP
servers and excluded the appropriate address as suggested but I am
still getting the same results. I must say that when I read what you
wrote I thought that had to be the answer.

Jack

 

[NIC Student]

Crap.

Do all your client pcs behave this way? Are you using a boot floppy or
"F12" to initiate RIS?

What OS/Service Pack are your RIS/DHCP servers?

Have you modified your scopes to include options 60, 66 or 67? If so, undo
those changes and test. If you have not set those options, I'd be
interested in seeing what happens if you enable just option 66 on dhcp
server #2 (both scopes).

Using Dynamic Host Configuration Protocol Options 60, 66, 67 to Direct PXE
Clients to RIS Servers May Fail
http://support.microsoft.com/default.aspx?scid=kb;en-us;259670

 

[sporup]

Crap was my first thought too.

I am running W2k SP4 on both servers and the boot floppy works fine.
We are forced to use the boot floppy any time a workstation gets an IP
from Server2 when using F12 option. We have several labs and each lab
has all the same make and models of machines in them. The only time we
have a problem is when the workstation gets an IP from Server2, so I am
confident that it is not the workstation or the NIC.

I have seen the kb article in my search for the answer and I too was
curious to see if adding option 66 would do anything. Unfortunately it
didn't work.
Thanks for continuing to help me with this problem!

Jack

 

[NIC Student]

Hmm, so the boot floppy works even when you get an address from dhcp2.

Have you gone to the nic manufacturer's web site and downloaded/updated the
PXE Rom on the nics?

That would be my next step.

Let me know.

 

[sporup]

I'm sorry, I missed typed. We have created boot floppies that just
map a drive to the network share where our Ghost images are located.
The boot floppies do not connect to the RIS server.

I spoke with somebody else who has had this same problem. He used two
DHCP servers for redundancy as well and made one of them a RIS server
on Microsoft's recommendation. During his testing, he moved the RIS
Services to a separate box other than the two DHCP Servers and he
experienced the same problem. When he brought this up to Microsoft,
the engineer once again said the RIS server may not respond correctly
to the client. He now has only one DHCP server and performs regular
backups of DHCP so he can restore it to another server if needed.

Looks like this may be the way I have to go.


Thanks for all of your help. If you have any more suggestions let me
know and I will try them.

Jack

 

[NIC Student]

Hi Jack,

In our environment, we have two dhcp servers and one RIS server which is not
on a dhcp server. All three of these servers sit on the same subnet and
service machines across routers all around our network. They also services
machines on the server subnet without problems.

We do not use the scope options 66 or any other than name a RIS server. All
of our dhcp servers service the same subnets but each subnet on each dhcp
server excludes part of the range so the other does not hand out the same
addresses.

Perhaps if you move RIS off dhcp server 1 and on to its own server it would
work better.

 

[Guest]

Guys I have a solution! I;ve been suffering with this for ages. I have two
DHC servers each serving adjacent ranges. (i.e. one does x.x.1.1 - x.x.1.254,
the other does x.x.2.1 - x.x.2.254). The RIS server is the second of the two
DHCP servers. I was getting the same problem most of the time. Eventually I
found that in the advanced tab of the DHCP options the "conflict detection
attempts" was set to 0. Setting this to 1 on both ranges seems to have done
the trick.

As an aside; is there a problem with this DHCP set-up? The suggestions you
made in the other tail on this question suggested that there was.

Thanks

Jason

 

[NIC Student]

Good detective work, Jason.

I like to have the same subnets on both servers but each excludes the other
server's portion of that subnet. That way you get redundancy and load
balancing for those subnets.