Re: DHCP: máquinas que consumen dos ips
El Sun, 12 de Oct de 2014, a las 11:45:06AM +0000, Camaleón dijo:
> En ese caso quizá te convenga repartir las IP de manera estática ("fixed-
> address") usando DHCP para evitar que haya duplicados y así te olvidas
> del problema.
Sé que esa es una solución posible, pero me gustaría no tener que
utilizarla.
> Si los clientes Windows envían el ID ¿has pensando en configurar los
> clientes linux para que hagan lo mismo? En "man dhclient.conf" hablan de
> "dhcp-client-identifier", quizá te pueda servir.
Sé que puedo hacer eso. De hecho, en el mensaje al que respondes creo
que conté que las pruebas las había hecho exclusivamente con clientes
linux. La forma de hacer las pruebas consistió en comentar y descomentar
la línea que hace a dhclient enviar el uid. Sin embargo, esa solución no
vale cuando se arranca por red.
De hecho, mi plan B, si no logro esto, es hacer que los linux también
envíen el UID y para solucionar el arranque por red (hay un servidor
PXE), podría crear una clase especial para los ordenadores que arrancan
por PXE (se pueden distinguir por la vendor-string, creo recordar) y que
ellos reciban ip de un rango distinto: así no consumirían ninguna. Pero
es una pequeña chapuza.
> El manual dice que la opción "deny duplicates" evita que un cliente
> reciba leases adicionales cuando la MAC que está declarada en el host es
> la misma. Bien, pero quizá eso no implica que mantenga o se le vuelva a
> asignar el lease anterior, simplemente evita que reciba otro. Y quizá lo
> haga porque primero da prioridad al ID y luego a la dirección MAC cuando
> únicamente debería utilizar la dirección MAC para evaluar quién es el
> cliente que solicita una nueva IP.
Tiene sentido lo que dices y es una posible explicación de por qué no
funcionan las cosas. Para confirmarla he hecho la siguiente prueba:
1. El rango de ips posibles, en vez de ser de una ip, es de dos:
la 192.168.129.66 y la .67.
2. Primero pide el cliente con un uid (el típico de
1:MAC:DE:LA:TARJETA) y luego, sin que envíe al servidor noticia
de que ya no quiere la ip concedida, con otro distinto uid
(1:1:1:1:1:1:1)
Si fuera cierto lo que supones y estuviera bien configurado el servidor:
+ con "allow duplicates" (o sea, sin nada) en la primera ocasión se
recibiría una ip (la .66, por ejemplo) y en la segunda ocasión la
segunda (la .67). Y ya no habría más ips disponibles.
+ con "deny duplicates" en la primera ocasión se recibiría una ip (la
.66, por ejemplo) y en la segunda ocasión, aunque haya una ip
disponible no se recibiría ninguna, porque el ordenador se negaría a
entregar una segunda ip ya que hay vigente una concesión para la MAC
que está requiriendo otra (aunque el uid sea distinto).
Pues he probado, y no ocurre lo previsto: con "deny duplicates" recibo
primero una ip (la .66) y luego la otra (la .67).
No entiendo nada.
> De todas formas, revisa en registro para ver qué es lo que hace
> exactamente
Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que
ocurre.
> consulta también la opción "one-lease-per-client", es
> posible que tengas que combinar ambas para que funcione.
La conocía también probé y no me funcionó. Después de leer tu mensaje,
me releí el manual:
#v+
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
particular lease, the server will automatically free any other leases
the client holds. This presumes that when the client sends a
DHCPREQUEST, it has forgotten any lease not mentioned in the
DHCPREQUEST - i.e., the client has only a single network interface
and it does not remember leases it's holding on networks to which it
is not currently attached. Neither of these assumptions are
guaranteed or provable, so we urge caution in the use of this
statement.
#v-
No me pareció que aquí dijera nada acerca de que al cliente sólo lo
identifique por su MAC (con lo cual es de suponer que lo identifica con
UID), pero igualemente hice una nueva prueba.
La otra vez que había probado lo había hecho con sólo una ip disponible
y pensé que a lo mejor el servidor liberaba el resto de concesiones una
vez que concedía la nueva ip. Así que me decidí a probarlo de nuevo,
con dos ips disponibles: quizás primero concede la .66, luego la .67,
pero libera la .66 y así sucesivamente.
Pero tampoco: se concede la .66 y luego, con uid distinto, la .67 sin
liberar la .66. Pero esto sí tiene explicación: el uid no coincide, así
que es otro cliente. De hecho, después de recibir la 67, pare el cliente
sin que se coscase el servidor, me metí en la caché de concesiones,
cambié el .67 por el .66 para que el cliente al enviar si nueva petición
le diga al servidor que quiere la .66 y... funcionó: el servidor le dió
la 66 e revocó la concesión de la 67.
Así que esta segunda opción no sirve en absoluto.
Quizás es que, simplemente, no se puede hacer lo que quiero. Lo que me
tiene escamado es que el comportamiento con "deny duplicates": o no
tengo algo bien configurado o no le veo el sentido.
> Saludos,
Un saludo. Gracias.
--
Tu dulce habla, ¿en cúya oreja suena?
--- Garcilaso de la Vega ---
Reply to: