El 13/10/2014 17:53, "Camaleón" <noelamac@gmail.com> escribió:
>
> El Mon, 13 Oct 2014 17:14:10 +0200, José Miguel (sio2) escribió:
>
> > El Sun, 12 de Oct de 2014, a las 09:02:12PM +0000, Camaleón dijo:
> >
> >> ¿Por algún motivo en particular? Dadas las restricciones que tienes con
> >> la asignación de las IP sería lo más lógico ¿no? :-?
> >
> > Es una larga historia: las configuración del DHCP no la hago
> > directamente, sino a través de un script. Ponerles ip fija me resultaría
> > engorroso.
>
> 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;
> }
>
> >> ¿Tampoco vale en los clientes Windows que arrancan por red o es que
> >> sólo los clientes Linux tiran de PXE? Si es esto último entonces
> >> entendido :-)
> >
> > En realidad son ordenadores que tienen arranque dual: a veces arrancan
> > con linux, a veces arrancan con windows y a veces (muy pocas) es
> > necesario arrancarlos por red para descargarles la imagen del disco con
> > clonezilla.
> >
> > El arranque por red o con linux no envía ningún identificador, windows
> > en cambio, sí. Así que a todos los efectos windows es un cliente y linux
> > (o el arranque por pxe), otro. Si hago que linux envíe el mismo
> > identificador que windows, sigue habiendo dos clientes: la máquina
> > arrancando windows o linux, y la máquina arrancando con pxe.
> >
> > Lamentablemente no hay forma de hacer que windows no envíe el uid al
> > servidor.
>
> 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.
>
> >> > 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.
> >> ¿Y con "deny duplicates" sigue la .66 ocupada o el servidor la ha
> >> liberado?
> >
> > Sigue ocupada. Eso podría haber ocurrido con
> >
> > one-lease-per-client true;
> >
> > pero tampoco porque un mismo cliente es el que envía el mismo
> > identificador, no el que tiene la misma MAC.
>
> Volvemos a lo mimos de antes, si el servidor usara sólo la MAC para
> identificar a los clientes no habría problemas, al menos no en este caso,
> en otros escenarios sí que sería posible que la MAC fuera diferente.
>
> >> Es posible que estemos interpretando mal lo que hace esa variable o que
> >> nos estemos saltando algo básico, como que demos por hecho que el
> >> servidor esté evaluando la petición del cliente recibiendo la
> >> información correcta (MAC duplicadas → no más leases) cuando realmente
> >> no es así de ahí la importancia de los registros para que qué datos son
> >> los que le llegan al servidor.
> >
> > Sí, si cada vez que ha pasado algo he ido a ver qué se ha quedado
> > registrado en la caché del servidor. Es cierto que podría haber mirado
> > /var/log/syslog cuando el servidor no ha dado la ip,
>
> Más que nada para hacer ingeniería inversa, es decir, ponerse en el
> pellejo del servidor/cliente para ver qué hace y qué responde cuando se
> activa esa variable.
>
> 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).
>
> > pero en realidad lo que me parece inexplicable es que con "deny
> > duplicates" dé una segunda ip a un cliente con la misma MAC y distinto
> > UID. El manual da a entender que no debería darla (o bien, que le diera
> > la misma que fue lo que interpreté yo, quizás mal).
>
> Sí, es raro... es raro que obtengas el mismo resultado si activas/
> desactivas esa opción, tendría que haber algún tipo de cambio o
> diferencia que no vemos.
>
> >> > Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que
> >> > ocurre.
> >> Y también en el cliente podrás obtener información jugosa (creo que
> >> esto va a parar al /var/log/syslog).
> >
> > En el cliente también puede consultarse la caché:
> > /var/lib/dhcp/dhclient.eth0.leases. Y el syslog, claro.
>
> Sí, pero no en la información de leases no ves el "diálogo" entre cliente/
> servidor, sólo el resultado de la asignación final.
>
> >> Y buscando en Google parece que la duda es generalizada :-):
> >>
> >> https://forums.novell.com/showthread.php/353997-DHCP-double-leases
> >> https://forums.novell.com/showthread.php/220615-PXE-and-Windows-eating-
> up-
> >> DHCP-leases
> >
> > A mí me da la impresión de que:
> >
> > a) Muy posiblemente no interpretara correctamente "deny duplicates" y
> > que no me sirva para lo que quiero.
> >
> > b) Que la interpretación correcta sea la que me has dado, pero que en
> > ese caso la directiva, directamente, no funcione. Yo tampoco he visto
> > ningún hilo en internet donde den una explicación satisfactoria.
>
> Por aquí arrojan algo de luz:
>
> https://lists.isc.org/pipermail/dhcp-users/2006-November/002376.html
>
> ---8<---8<---
> (P)
> 4. I was convinced that the "deny duplicates" option would solve the
> problem, am i doing something wrong in the config file, do i use it the
> wrong way?
>
> The bottom line is, the client allways grabs 2 adresses upon start, and
> the second adress is not available until it has expired, resulting in ip
> adress shortage on some subnets. The only solution right now is to use
> really short lease times.
>
> (R)
> 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.
> --->8--->8---
>
> > 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.
>
> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] pan.2014.10.13.15.52.13@gmail.com">https://lists.debian.org/[🔎] pan.2014.10.13.15.52.13@gmail.com
>
En tu caso usaría ip fijas a través de dhcp fijando por mac como te han comentado, pornlo pronto.
Depende de la prisa que te corra... Luego haría pruebas en otro entorno hasta dar con la solución