El 13/10/2014 17:53, "Camaleón" <noela...@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-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.10.13.15.52...@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