Re: DHCP: máquinas que consumen dos ips
El Mon, 13 de Oct de 2014, a las 03:52:14PM +0000, Camaleón dijo:
> Si ya lo tienes todo hecho, sólo tendrías que añadir la IP en cada host
> que quieras que tenga una asignación fija, p. ej.:
>
> host pc05-vlan9 {
> hardware ethernet 00:11:22:33:44:55;
> ddns-hostname "pc05";
> fixed-address 192.168.129.66;
Lo sé, pero esa solución no me gusta porque la ip fija no la necesito para
nada (en realidad lo que quiero es fijarle el nombre a los clientes), y
habría que andar con cuidado para que esas ips quedaran fuera de los rangos
que sí se conceden. No es que sea difícil, pero exige al que toquetea la
configuración (que está en un xml), tener en cuenta eso.
> Que windows haga una cosa y linux otra sería irrelevante si se le pudiera
> decir al servidor DHCP que sólo tuviera en cuenta la dirección MAC del
> equipo, que es raro que cambie.
Sí, pero por lo que he leído investigando esto, eso viola el protocolo
DHCP. Por eso, el servidor del ISC no lo permite.
> Y por otra parte, también cabría preguntarse por qué el cliente solicita
> una nueva IP si se le ha asignado ya una siendo que podrías configurar la
> opción de "leases" permanentes (infinite-is-reserved).
Para investigar eso creo que debería ver el DHCPREQUEST que envía el
cliente con wireshark. No lo he hecho. De todos modos, yo creo que el
cliente sí que pide la misma IP, lo que ocurre es que el servidor se la
deniega y le da otra, porque otro cliente (él mismo con otro UID) la
reservó, y la reserva aún no ha caducado.
Puede ser que esta información también aparezca en el syslog, pero estoy
convencidísimo de que la explicación es esta.
> Por aquí arrojan algo de luz:
¿Por qué arrojan luz ahí? No soy capaz de verlo. Lo que sí veo es que
eso no podría funcionar, porque no hay ninguna declaración "host" que el
manual dice que es necesaria para que funcione "deny duplicates".
> As I read it, the client will still get two addresses during
> boot, but one of them will be freed by the server. This does not mean
> that the address WILL be reused, merely that it CAN be reused if required.
A mí esto sí me ha funcionado. "one-leases-per-client true;" me liberaba
una ip previamente reservada, si el cliente pedía luego otra distinta
sin que hubiera caducado la anterior. Lo que ocurre es que tenía que
haber sido reservada por el mismo cliente y para eso el servidor DHCP se
fija en el UID, no en la MAC (volvemos otra vez al problema de siempre)
> > Al final creo que voy a optar por la solución de meter los clientes en
> > una clase aparte cuando arranquen por PXE.
>
> Supongo que tendrás varias opciones para resolverlo, la de usar clases es
> la que maś comentan por los foros y listas que he encontrado en Google.
> Ya nos dirás cómo te fue.
En realidad, voy a probar a usar una variante de eso: crearé una clase
para los clientes PXE, pero no les reservaré un rango. Lo que voy a
hacer es denegarles los rangos reservados para las demas clases y las
máquinas conocidas, de manera que acaben pillando una ip del rango
general:
#v+
pool {
deny members of pxe;
deny known-clients;
allow members of clase1;
range a b;
}
pool {
deny members of pxe;
deny known-clients;
allow members of clase2;
range b+1 c;
}
pool {
deny members of pxe;
allow known-clients;
range c+1 d;
}
pool {
range d+1 e;
}
#v-
Con esta configuración las máquinas que arranquen por pxe, acabarán
pillando ip del último rango (el de las máquinas desconocidas y que no
pertenecen a una clase con rango reservado): así no les tengo que
reservar permanentemente un rango. Debe de funcionar sin problemas.
Como lo tengo que programar, iprocuraré buscar un hueco esta seman y ya
os confirmaré (eso espero) que funciona.
Saludos.
--
Todo es vana arquitectura,
porque dijo un sabio un día
que a los sastres se debía
la mitad de su hermosura.
--- Lope de Vega --
Reply to: