Re: DHCP: máquinas que consumen dos ips
El Mon, 13 Oct 2014 19:23:24 +0200, José Miguel (sio2) escribió:
> 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.
Siempre será mejor delimitar las direcciones IP fijas para que ciertos
equipos sólo tomen una dentro de un rango limitado en el que no se
permiten duplicados que permitir al servidor DHCP asignarle varias que se
supone es lo que quieres evitar.
>> 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.
¿Qué es lo que viola el protocolo? ¿Que se identifique al equipo por la
MAC en lugar del identificador? ¿Dónde has leído eso? :-?
Lo que sí que pone en la ayuda de dhcpd.conf es que precisamente la
variable "deny duplicates" va en contra de lo que dicta la normativa pero
igualmente lo permiten.
>> 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.
El cliente no debe pedir ninguna IP en especial, simplemente solicitar
una al servidor cuando esté configurado para hacerlo y eso es otra cosa
que tendrías que revisar, el motivo de por qué la solicita una vez que ya
la tiene. Si no quieres que renueve su IP (esto es algo que se suele
hacer con clientes móviles que pasan de un servidor DHCP a otro)
configúralo para que no haga.
>> 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)
Lo interesante no es lo que dicen del "one-leases-per-client" sino lo que
opina de la función del "deny duplicates", que aunque esté activado el
cliente obtendrá una segunda dirección y en el caso de que lo necesite,
podrá reutilizar la anterior. Eso no concuerda con la idea que tienes del
funcionamiento del "deny duplicates", por eso decía que quizá lo estemos
interpretando mal.
>> > 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:
(...)
> 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.
Ya nos dirás si funciona como esperas y te sirve para tu entorno.
Saludos,
--
Camaleón
Reply to: