topic bootp and DHCP mystery in Operating System - HP-UX

bootp and DHCP mystery

Jeff Traigle — Sat, 17 Aug 2002 12:30:49 GMT

I've tried the newsgroups and havent' gotten an answer that is sensible. Hopefully, I'll have better luck here before I call HP support. :)

I've done a lot of searching on Google regarding the problem we're having,
but I've not found the specific information that would explain what's
happening. Here's the situation:

We've been using static IP addresses for many years and it's been totally
unmanageable with over 700 nodes (servers, printers, and PCs) the past few
years as more people have gotten their hands into assigning addresses as
needed. Since we're getting new computers next month, we've decided this is
an excellent time to move to DHCP to take some of the hassle out of managing
the network when our IP address changes take place soon as a result of our
company's spin-off requirements from our parent company. We're running into
a problem getting our current subnets working on this, however.

We're in a single building so we're not trying to jump across a router to
get to the DHCP server, which is an HP-UX 10.20 server. Our clients are
Win98. Our router is a Cisco 3600 series, which we do not control at all. We
have three IP subnets, call them 169.129.4.X, 169.129.50.X, and 169.129.90.X, with subnet masks of 255.255.254.0. DHCP and bootp server is on IP subnet 4.X.

Here's what does work:

1. DHCP pool with addresses in subnet 4.X will be properly configured on a DHCP client.

2. bootp will serve any address from any IP subnet.

Here's what doesn't work:

1. DHCP pool with addresses on IP subnet 50.X or 90.X won't be assigned to a DHCP
client.

Now, I've seen plenty of posts regarding the bootp helper parameter that can
be configured in the Cisco 3600, but, since everything here is on a single
physical LAN behind this router, I don't think this applies. The fact that bootp works regardless of the IP subnet of the assigned IP address leads me to believe that broadcasts are properly being handled on the LAN so the router should be no problem. DHCP
and bootp use the same port and, from what I've been able to gather, broadcast over the network in the same manner while negotiating the assignement of IP addresses, after all so, if one works, the other should
also even if the router was in the way.

Anyone have any ideas what the problem is and how to fix it without configuring multiple IP addresses for each IP subnet on this server?

Re: bootp and DHCP mystery

Ceesjan van Hattum — Sat, 17 Aug 2002 14:28:15 GMT

A nice challenge indeed.
I think.. not sure.. that it is the router anyway. The router is maybe not just a router, but uses some firewall rules as well. All tree subnets, 4,50,90 need to be included into the same rule for this specific port.

But you seem to know quit well that the router is not your problem.. but you also say you do not control this router.
If you have indeed a few hundreds of hosts, why not setup a test-environment.

Take 1 ux, 3 win98clients and one 'spare' Cisco3600 and try to find your way out.
Make sure that you do not all thinking yourself, a networker with Cisco experience and you will find the way.. i'm sure you can do it !!

Succes,
Ceesjan

Re: bootp and DHCP mystery

harry d brown jr — Sat, 17 Aug 2002 14:51:39 GMT

Jeff,

bootp is routable, dhcp is not by design.

http://www.more.net/technical/netserv/tcpip/dhcp.pdf

You might be able to get them to open up the 3600 and allow dhcp requests to "pass-thru"?

http://www.cisco.com/warp/public/794/wicadsl_dhcp_unnum.html

Or, if not, then setup THREE dhcp servers, one for each subnet! Maybe virtual IP's would work here?

live free or die
harry

Re: bootp and DHCP mystery

Ron Kinner — Sat, 17 Aug 2002 21:26:28 GMT

I think I see the problem and it's not the router. Bootp replies from the server are by default broadcasts to port 68 which the router has been told to pass on to the other subnets. DHCP replies are by default unicasts which work only if you are on the same LAN. There is a flag in the DHCP packet that needs to be set which tells the server to send the reply via broadcast. (http://www.ecse.rpi.edu/Homepages/shivkuma/teaching/sp2001/ip2001-Lecture11-6pp.pdf is a nice simple tutorial about the differences between the two.) Normally this is something the client should set but don't ask me how. I have also seen reports of several DHCP servers fixing bugs where they had ignored the "please reply via broadcast flag" so you might check your patches and also look in your DHCP server manual to see if there is a way to force broadcasts.

Ron

Re: bootp and DHCP mystery

Ron Kinner — Sun, 18 Aug 2002 02:17:49 GMT

Rather than waste a lot of time on the problem why don't you talk the owner of the 3600 into programming the router so that it becomes the DHCP server. A 3600 should have no problem handling that little chore and I know the IOS supports it.

Ron

Re: bootp and DHCP mystery

Jeff Traigle — Mon, 19 Aug 2002 18:12:28 GMT

Well, since we don't control the router locally, we sure don't want to configure the DHCP server into the router. Given the situation in our company, it's much better for us if we can get this working locally. Paperwork, politics, and other unsavory things abound and keep progress from being made any time we go through corporate channels.

It would also be wonderful to have a separate test environment. I'm not blessed with extra equipment sitting idle. The only testing I can do is on the production systems we have now.

I called the support center and their best suggestion was putting three NICs and assigning one to each subnet. (ifalias won't work because it apparently only allows you to add IP addresses from the same subnet onto a NIC.) Not what we wanted to do, but looks like that's what we'll have to do until we get our new IP addresses.

My best guess... the ba flag on the bootp side of the daemon is being read and handled. I have the ba flag set in the dhcptab file for the pools also, but judging by the problems we saw, it is apparently ignored. Oh well.

Re: bootp and DHCP mystery

Berlene Herren — Tue, 20 Aug 2002 19:03:42 GMT

Jeff, do you have PHNE_12492
installed?

Are you getting an error message when issuing the command? (see ITRC A5024086)

Is this the command you used?

ifalias lan# addmask 255.xxx.xxx.xxx

Did you create a static arp cache entry for the other machine(s) that will connect to it? This is needed for IP's assigned to another subnet.

Berlene

Re: bootp and DHCP mystery

Jeff Traigle — Tue, 20 Aug 2002 19:14:19 GMT

I do have the patch installed.

Didn't do the addmask, however. Probably would have realized that was necessary if I'd taken the time to read the man page for the command beyond the syntax. :) Will try it out when I get a chance and see what happens.

Re: bootp and DHCP mystery

Ron Kinner — Wed, 21 Aug 2002 02:10:05 GMT

Now that I think about it you are really better off without this working over a single LAN. As Berlene points out you have to maintain a static arp cache which is a list of all of the MACs that you expect to showup on Net b and Net c so your admin effort is really going to be high. Much simpler to just let the same DHCP server have a presence on each LAN then it's all automatic.

Ron

Re: bootp and DHCP mystery

Jim Butler — Wed, 21 Aug 2002 11:39:54 GMT

I am not sure how a netmask of 255.255.254.0 fits here. One way of doing this is as follows.

Set up your subnets as 169.129.4, .5, .6, .7 and use a netmask of 255.255.255.252 -

Then set up your dhcp pool to serve the entire vlan.

That works for us.

Re: bootp and DHCP mystery

Jeff Traigle — Wed, 21 Aug 2002 19:52:13 GMT

Much simpler from a configuration perspective to do multiple NICs and we've got the interfaces for the temporary fix we're needing to implement right now until we get our new addresses.

As for changing the IP ranges we're using and changing our subnet mask, that is not at all possible because we don't control which IP address ranges we get. We're a single plant in a large corporation... and we're not even part of the same company whose IP addresses we're using currently, hence the upcoming IP address change. Hopefully, our new addresses will be arranged in a better manner. :)