Multi-homed DHCP server
Michael T. Davis
HP TCP/IP Services for OpenVMS Alpha Version V5.5
on an AlphaServer DS15 running OpenVMS V8.2
A few weeks ago, we added an interface in TCPIP to provide access to
a secondary subnet which resides on our network. (We have both a /22 network
[primary] and a /24 network [secondary] on the same wire [single collision
domain].) The TCPIP$DHCP_RUN.LOG file started reporting problems (i.e.
"network not administered by server"), but DHCP-served clients still seemed
to be maintaining connectivity. Here's basically how the system looked
(obfuscated/trimmed TCPIP SHOW INTERFACE output):
Interface IP_Addr Network mask
IE1 192.168.80.3 255.255.255.0
LO0 127.0.0.1 255.0.0.0
WE0 192.168.72.3 255.255.252.0
Last night, we were forced to restart the system and after that, our
DHCP server was no longer honoring requests. I removed the ...80.3 interface
and restarted the DHCP server, and now all seems to be working as far as DHCP
is concerned.
Questions
Is there a configuration for HP's DHCP server that will work in this
environment? That is, given the server is connected to multiple subnets that
share the same collision domain, can the DHCP server handle this and if so,
how? Strictly speaking, we only need to serve DHCP clients in the ...72.0/22
subnet, and we only need a "presence" in the ...80.0/24 subnet on the server.
On the other hand, if we could also handle DHCP clients in the ...80.0/24
subnet, that would be ideal. If such a configuration isn't possible with HP's
OpenVMS tools, is there something that would work? (We have a number of
Windows 2003 servers, for example.)
Caveats
Note that the IP addresses used here are not the real values and
allocation is strictly managed by another entity. The simple solution would
be to move to a single /21 subnet, but address space to support this isn't
available. NATting is also not an option.
Thanks,
Mike
--
| Systems Specialist: CBE,MSE
Michael T. Davis (Mike) | Departmental Networking/Computing
http://www.ecr6.ohio-state.edu/~davism/ | The Ohio State University
| 197 Watts, (614) 292-6928
JF Mezei
> A few weeks ago, we added an interface in TCPIP to provide access to
> a secondary subnet which resides on our network.
I am on VAX with older version (but since Join no longer exists, I
suspect no much has been done with the DHCP server).
If you look at the TCPIP$DHCP_RUN.LOG , you'll see that when it lists
its configuration, it has and option to ignore a list of interfaces. Not
sure if this is accessible from the DHCP$GUI interface, but it is
probably configurable if you go into the actual text config files.
Note that a DHCP CLIENT sends a broadcast from a bogus IP address. Any
DHCP server on that ethernet segment can reply to it (also as a
broadcast because at that point, the client still doesn't have an IP address).
So, from the DHCP Server point of view, it can discriminate between
clients based on:
-their ethernet address (MAC)
-some host name their desire (included in the request)
-or which physical interface the broadcast is coming from.
In your case, since you have multiple IP subnets on the same ethernet,
the DHCP server has no logical way to know if a request is coming from a
PC supposed to be on one subnet or another.
If you do a NETSTAT, do you see port 67 being listened on on each
interface ?
(On my system, it is strange, it listens on the cluster alias, on the
main interface as well as *.67 and the TCPIP service is defined as
listening to 0.0.0.0 (which results in the NETSTAT *.67 and
automatically listens to any IP interface).
John E. Malmberg
Michael T. Davis wrote:
> We're running...
>
> HP TCP/IP Services for OpenVMS Alpha Version V5.5
> on an AlphaServer DS15 running OpenVMS V8.2
>
> A few weeks ago, we added an interface in TCPIP to provide access to
> a secondary subnet which resides on our network. (We have both a /22 network
> [primary] and a /24 network [secondary] on the same wire [single collision
> domain].) The TCPIP$DHCP_RUN.LOG file started reporting problems (i.e.
> "network not administered by server"), but DHCP-served clients still seemed
> to be maintaining connectivity. Here's basically how the system looked
> (obfuscated/trimmed TCPIP SHOW INTERFACE output):
DHCP does not care about collision domain.
DHCP only cares if DHCP server can be reached.
By default, routers will block DHCP traffic, but that can be changed.
All DHCP servers that a client can see must work together. This is
needed to prevent more than one server giving the same I.P. address out
to different DHCP clients.
This is easily done with out clustering and even with different
platforms by having each DHCP server have it's own unique range of
addresses that it gives out.
If a client needs a specific I.P. address, then all DHCP servers must
know to either give that I.P. address or ignore the request. Some types
of DHCP servers do not know how to ignore that type of request so that
is harder.
The simple solution is to have all DHCP servers know about the fixed MAC
to DHCP assignments.
A DHCP server may be configured to pay attention to the subnet that the
DHCP request came in on. I have not worked with that configuration, so
I do not know the details of that.
> Interface IP_Addr Network mask
>
> IE1 192.168.80.3 255.255.255.0
> LO0 127.0.0.1 255.0.0.0
> WE0 192.168.72.3 255.255.252.0
>
> Last night, we were forced to restart the system and after that, our
> DHCP server was no longer honoring requests. I removed the ...80.3 interface
> and restarted the DHCP server, and now all seems to be working as far as DHCP
> is concerned.
>
> Questions
>
> Is there a configuration for HP's DHCP server that will work in this
> environment? That is, given the server is connected to multiple subnets that
> share the same collision domain, can the DHCP server handle this and if so,
> how? Strictly speaking, we only need to serve DHCP clients in the ...72.0/22
> subnet, and we only need a "presence" in the ...80.0/24 subnet on the server.
> On the other hand, if we could also handle DHCP clients in the ...80.0/24
> subnet, that would be ideal. If such a configuration isn't possible with HP's
> OpenVMS tools, is there something that would work? (We have a number of
> Windows 2003 servers, for example.)
What you have is a "router on a stick" configuration, or two networks
that have only some systems that can reach both.
In general, no matter what platform you have, DHCP serving multiple
subnets on the same wire is not something that I would ever want to do.
It only takes one configuration glitch to start a network shutdown for
the DHCP clients, and it may take a while for it to be noticed.
That is because until a DHCP client is rebooted, it will continue to
always go to the specific DHCP server that leased it it's I.P. address
unless that DHCP server becomes unavailable.
I have not worked enough with HP's DHCP server to know it's capabilities
or limitations in this area.
> Caveats
>
> Note that the IP addresses used here are not the real values and
> allocation is strictly managed by another entity. The simple solution would
> be to move to a single /21 subnet, but address space to support this isn't
> available. NATting is also not an option.
If the routing tables are set up correctly on all systems or there is a
router on a stick, it should not matter if a DHCP client gets an address
from the 80.0/24 pool or the 72.0/22 pool.
And if that is the case, then all it is a matter of is that any DHCP
server that can receive a client broadcast can service that request.
And the simplest is to allocate each DHCP server a fragment of the
available address pool. Of course that requires you to have much more
I.P. addresses available than clients.
Effectively for running DHCP servers that do not use a common lease
database or only give out to fixed I.P. address, the total number of
I.P. addresses you need to be able to offer is the maximum number of
clients multiplied by the number of DHCP servers.
If you can get NAT to be an option, properly applied, it can really
simplify your network management, because then you can put all the
non-server devices on an reserved RFC non-routable subnet.
And the NAT only has to be at the firewall to the public Internet. It
is not needed to internally use RFC non-routable subnets. All you have
to do is change your internal routing tables to treat them as valid
internal addresses to route with in your intranet.
If you already have a NAT gateway at the firewall, then it is likely
that you could migrate all the DHCP allocated systems to something in
the 10.1/16 range without anyone noticing the change, unless they were
running a server on using an external dynamic DNS provider like dyndns.org.
It also foils a very popular spammer trick of hosting web sites and DNS
servers zombied systems in DHCP pools.
-John
wb8...@qsl.network
Personal Opinion Only