[c-nsp] Redundant DHCP Server

[Nick Cutting]

DHCP always sends the broadcast / relay to both servers.

Whoever answers first will send back to the client, then it is up to the client to ACK the address that it wants.

IF the MLS adds clients without receiving their ACK, "yes I want that address" then that is the bad implementation of DHCP on IOS.
I find that the DHCP conflict database gets full - when there are no conflicts - and we have to periodically remove addresses from here.
Also reservations are a massive pain - I think DHCP on IOS is about the worst implementation there is.

-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: 02 June 2015 09:05
To: Peter Rathlev
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Redundant DHCP Server

Hi peter , thanks for the great reply :) Usually I rely on DHCPD package on Linux distributions to configure my DHCP server , but the issue is that my client wants his MLS to do that job 

Is there a way that I can remove the unused releases from the database like my case where I am using two hosts only ?
Is there a way that I can make the DHCP assign addresses for the clients in a round-robin fashion?

Thanks again

BR,
Mohammad

> Subject: Re: [c-nsp] Redundant DHCP Server
> From: peter at rathlev.dk
> To: eng_mssk at hotmail.com
> CC: cisco-nsp at puck.nether.net
> Date: Mon, 1 Jun 2015 21:07:02 +0200
> 
> Hi Mohammad,
> 
> On Mon, 2015-06-01 at 13:44 +0300, Mohammad Khalil wrote:
> > Sorry for the bad format
> 
> You did an okay-ish job of making it better. :-) But you should 
> probably consider using another mail client. Then you don't have to 
> spend all that time making your emails readable.
> 
> ...
> > Now , when the clients requested IP address
> > PC1> show
> > NAME  IP/MASK            GATEWAY       MAC                LPORT  [...]
> >       192.168.10.6/24    192.168.10.3  00:50:79:66:68:01  20501  [...]
> > 
> > PC2> show
> > NAME  IP/MASK            GATEWAY       MAC                LPORT  [...]
> >       192.168.10.133/24  192.168.10.3  00:50:79:66:68:02  20502  
> > [...]
> > 
> > R1#sh ip dhcp binding
> > Bindings from all pools not associated with VRF:
> > IP address       Client-ID/           Lease expiration       Type
> >                  Hardware address/
> >                  Username
> > 192.168.10.7     0100.5079.6668.01    Mar 01 2002 12:23 AM   Automatic
> > 192.168.10.6     0100.5079.6668.02    Mar 01 2002 12:23 AM   Automatic
> > 
> > R2#sh ip dhcp binding
> > Bindings from all pools not associated with VRF:
> > IP address       Client-ID/           Lease expiration       Type
> >                  Hardware address/
> >                  User name
> > 192.168.10.133   0100.5079.6668.01    Mar 02 2002 12:18 AM   Automatic
> > 192.168.10.132   0100.5079.6668.02    Mar 02 2002 12:18 AM   Automatic
> >  
> > I do not understand why the two servers assigned IP addresses?
> 
> This is probably "normal" for IOS. Each of the two servers offer an 
> address to the client, but the client only actually ACKs one of these.
> Since the client doesn't NAK the other lease (the one it didn't take) 
> the server doesn't know for certain that the lease isn't taken. (DHCP, 
> being a UDP based protocol, does have some weaknesses concerning 
> packet
> loss.)
> 
> I think "real" DHCP servers (no offense towards IOS) start by handing 
> the client a shorter-than-normal lease and then hands out a 
> full-length lease at the first "renew" request.
> 
> This shouldn't be a problem. If the DHCP service is supposed to be 
> redundant you would have to have addresses enough for every device on 
> each of the two routers anyway. Otherwise you will not have enough 
> addresses if one of the fails.
> 
> More dedicated DHCP servers can coordinate their leases and avoid this 
> 50% waste. But I don't think IOS is that advanced.
> 
> --
> Peter
> 
> 
 		 	   		  
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/