Two IPs on one NIC

[Jeff Haran]

> -----Original Message-----
> From: dhcp-users-bounces at lists.isc.org 
> [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Simon Hobson
> Sent: Wednesday, September 16, 2009 11:43 AM
> To: Users of ISC DHCP
> Subject: RE: Two IPs on one NIC
> 
> Jeff Haran wrote:
> 
> >Just an FYI, I was able to run two dhcpcd client instances on the 
> >same linux machine (custom Brocade hardware platform) to accomplish 
> >this. Each client instance had to be passed a unique client ID on 
> >it's command line and likewise one was started up to service an 
> >interface name while the other was started up to service an 
> >interface alias, e.g. eth0 and eth0:0. The only other things that I 
> >can recall were to make sure each client instance locate it's data 
> >files in a separate directory, but that was just a command line 
> >option in the script that started them, and to modify the way the 
> >client generated it's XID so that each XID was unique. The 
> >unmodified dhcpcd client code generated it's XID using a hash of the 
> >MAC address and time(), which meant that each client generated the 
> >same XID which confused the servers big time. I just added the pid 
> >of the client process to what got hashed to make sure each client 
> >got it's own XID.
> 
> Right, so you generated client-ids that would ensure churn by 
> changing one every boot - thus appearing to be a different client to 
> the server.

No. The client IDs generated by a given system are the same on each reboot. The host the clients ran on generated the client IDs based on other information that was unique to each system (not the MAC addresses). So it looked like the same client to the servers on each reboot.

This was admittedly an atypical application of DHCP. The clients are running on blades in a chassis. The network is in the chassis backplane (there are two of them per chassis) and the ISC dhcp servers run on other "central processor" blades (two of them, too, one on each backplane network).

> And you did nothing to deal with the ambiguities of routing ? One 
> client gets router A, the other gets router B - what is your default 
> route now ?

In the application, the blades only need to contact hosts on those isolated networks, so the default route was not pertainent in this case. But, the dhcpcd client has a command line option to prevent it from installing a default route. From the man page:

"-G [gateway]
    Prevents dhcpcd from installing default routes provided by DHCP server. If optional gateway ip address parameter is supplied then use it for default route."

So had this been a problem we could have started one client with -G and one without.

> You lose one of the leases for some reason, now what is 
> your default route and how does it get set properly ?

The leases are years long. The client requests a lease time of 0xffffffff and though the servers were configured to pass out leases of the same length, what I found is that the ISC server would only offer leases that lasted until what appeared to be the end of the unix epoch in 2038. I posted an email to this list about this some time back, and the response was something along the lines of "isn't that long enough?". A valid question. We figured 2038 is in fact more than long enough for the product's expected lifetime so I dropped the issue, but this behavior on the part of the server still does not seem correct to me. If a client requests a 136 year lease and the server is configured to give them one, why  should the server implementation not allow the client to get one that long? It will be a problem for more typical users 29 years from now, but I can remember writing non-Y2K compliant code back in the 70s and everybody laughing about the Y2K rollover back then so I can understand why this one is not at the top of the bug fix list. 8^)

> Similarly DNS servers - if you lose one lease, that could potentially 
> mean you lose access to the DNS servers configured.

Likewise, the blades in the backplane don't make use of DNS on these ports. But had this been a problem, we could have used the client's -R option on one of the clients:

"-R
    Prevents dhcpcd from replacing existing /etc/resolv.conf file."

> As I suggested, there are a lot of combinations of sequences to 
> consider, and a lot of potential conflicts. Far from trivial - though 
> many of them also apply if you use DHCP client on two separate 
> interfaces.

In the general case, the biggest problem is generating the two unique client IDs. On a generic PC of unknown origin, I don't know how I'd go about doing that. I was just pointing out you could get two IP addresses via DHCP without major changes to the client code.

Jeff Haran
Brocade

> -- 
> Simon Hobson
> 
> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
> author Gladys Hobson. Novels - poetry - short stories - ideal as
> Christmas stocking fillers. Some available as e-books.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.101/2376 - Release 
> Date: 09/16/09 11:21:00
>