Re: DHCP: máquinas que consumen dos ips
El Fri, 17 Oct 2014 20:23:54 +0200, José Miguel (sio2) escribió: > El Fri, 17 de Oct de 2014, a las 04:22:22PM +, Camaleón dijo: > >> Con la opción b) puedes decirle que envíe como UID la dirección MAC >> editando manualmente el campo desde los clientes lo que a todos los >> efectos sería como si sólo se le enviara un dato,o al menos als ervidor >> sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección >> MAC). > > No son datos distintos: la MAC es una cosa y el UID es otra, que se > envían en campos distintos del paquete DHCPREQUEST. De hecho, de modo > predeterminado ocurre lo que tú dices: que el UID vale lo mismo que la > MAC. Pero a pesar de ello un cliente que envía un UID(=MAC) y una MAC se > considera distinto al que no envía UID y sí la misma MAC (que es dato > que siempre se envía). La idea central es que al servidor le llegue el mismo identificador (UID=MAC) para que el servidor trabaje siempre con ese dato y que pueda aplicar la configuración que necesite en base a ese identificador. >> ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me >> da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ >> dhclient.leases" :-? > > En todo momento estoy hablando de ifup/ifdown que internamente usan > dhclient. En cualquier caso, he mirado el manual y "dhclient -r" no pide > ip, sino que para el cliente enviando al servidor una notificación para > que libere la ip. Como con ifdown ocurre esto, supongo que ipdown usará > esta opción "-r". Si usas Network-Manager ifup/down no es el comando apropiado para configurar la interfaz de red (independientemente de que lo ejecute N-M como parte de su rutina). Y obviamente cuando se libera una IP el cliente pide otra al servidor, al menos eso es lo que aparece en el syslog cuando ejecutas el comando. > Si el cliente vuelve a pedir la ip y nadie recibió esa ip entre el > momento en que se liberó y el que se ha vuelvo a pedir, se le concede la > misma, porque el cliente le sugiere al servidor que se la dé. Esa es mi > experiencia: no he hecho pruebas exhaustivas, que tampoco vienen mucho a > cuento, porque en nada cambian el problema con "deny duplicates". Ya te digo que ese no es comportamiento que veo en mi netbook (con N-M y dhcp) y no tengo ninguna configuración especial en el servidor dhcp. >> No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a >> clientes que usan BOOTP? > > La estructura del paquete DHCPREQUEST que te envié yo era de un artículo > sobre el protocolo DHCP. La opción 50 que mencionabas en el correo anterior es una extensión del protocolo relacionada con BOOTP, por eso te lo decía. >> No sé... yo sigo pensando que si el cliente no pide otra IP al servidor >> no volverías a tener problemas porque mantendría la misma durante toda >> la sesión, salvo, efectivamente que el equipo reiniciara o recargara el >> demonio de la red y no tuviera información alguna de los leases que >> como dices más arriba, > > Es que el problema no se produce mientras se está usando un ordenador y, > de repente, se queda uno sin ip. El problema se produce porque se está > usando un ordenador en windows (o se estuvo usando hace sólo unas horas > por lo que la concesión de ip no ha caducado) y se reinicia en linux o > se reinicia para arrancar por red. De ahí la importancia de que el cliente se identifique (UID o MAC) siempre de la misma forma tanto en linux como en windows para que el servidor le dé la misma IP. Y si ambos sistemas mantienen los leases que han recibido, siguiendo con tu argumento de que los clientes siempre piden la última IP que tienen almacenada, tendrían que recibir la misma y no renovarla. >> Pero eso no ataca el problema de fondo que es evitar que los clientes >> pidan (u obtengan) direcciones distintas cada vez. > > Es que ese no es el problema que quiero resolver: a mí me trae sin > cuidado que un ordenador no reciba siempre la misma ip: para eso ya está > fixed-address. Lo que yo quiero impedir es que un cliente (entendiendo > por cliente una ordenador con una tarjeta de red) acapare dos ips a la > vez: una que le dieron cuando ejecutaba windows y que no está libre > porque no ha acabado la concesión, y otra que usa en el presente porque > está ejecutando linux. Con el "deny duplicates" entiendo que el cliente va a tener (o puede tener) siempre dos IP asociadas, así que tampoco te serviría. Sigo pensando que la mejor forma de ver cómo funciona o qué es lo que hace esa opción es probándola y analizando el syslog del cliente para ver qué IP recibe con cada reinicio. 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.18.15.49...@gmail.com
Re: DHCP: máquinas que consumen dos ips
El Fri, 17 de Oct de 2014, a las 04:22:22PM +, Camaleón dijo: > Con la opción b) puedes decirle que envíe como UID la dirección MAC > editando manualmente el campo desde los clientes lo que a todos los > efectos sería como si sólo se le enviara un dato,o al menos als ervidor > sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección > MAC). No son datos distintos: la MAC es una cosa y el UID es otra, que se envían en campos distintos del paquete DHCPREQUEST. De hecho, de modo predeterminado ocurre lo que tú dices: que el UID vale lo mismo que la MAC. Pero a pesar de ello un cliente que envía un UID(=MAC) y una MAC se considera distinto al que no envía UID y sí la misma MAC (que es dato que siempre se envía). > ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me > da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ > dhclient.leases" :-? En todo momento estoy hablando de ifup/ifdown que internamente usan dhclient. En cualquier caso, he mirado el manual y "dhclient -r" no pide ip, sino que para el cliente enviando al servidor una notificación para que libere la ip. Como con ifdown ocurre esto, supongo que ipdown usará esta opción "-r". Si el cliente vuelve a pedir la ip y nadie recibió esa ip entre el momento en que se liberó y el que se ha vuelvo a pedir, se le concede la misma, porque el cliente le sugiere al servidor que se la dé. Esa es mi experiencia: no he hecho pruebas exhaustivas, que tampoco vienen mucho a cuento, porque en nada cambian el problema con "deny duplicates". > No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a > clientes que usan BOOTP? La estructura del paquete DHCPREQUEST que te envié yo era de un artículo sobre el protocolo DHCP. > Pero ese archivo de leases no parece una base de datos sino un archivo de > información que le ha enviado el servidor. No, es un archivo que almacena los datos que se ha recibido del servidor. > No sé... yo sigo pensando que si el cliente no pide otra IP al servidor > no volverías a tener problemas porque mantendría la misma durante toda la > sesión, salvo, efectivamente que el equipo reiniciara o recargara el > demonio de la red y no tuviera información alguna de los leases que como > dices más arriba, Es que el problema no se produce mientras se está usando un ordenador y, de repente, se queda uno sin ip. El problema se produce porque se está usando un ordenador en windows (o se estuvo usando hace sólo unas horas por lo que la concesión de ip no ha caducado) y se reinicia en linux o se reinicia para arrancar por red. > Pero eso no ataca el problema de fondo que es evitar que los clientes > pidan (u obtengan) direcciones distintas cada vez. Es que ese no es el problema que quiero resolver: a mí me trae sin cuidado que un ordenador no reciba siempre la misma ip: para eso ya está fixed-address. Lo que yo quiero impedir es que un cliente (entendiendo por cliente una ordenador con una tarjeta de red) acapare dos ips a la vez: una que le dieron cuando ejecutaba windows y que no está libre porque no ha acabado la concesión, y otra que usa en el presente porque está ejecutando linux. > Saludos, Saludos. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo --- -- 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/20141017182354.ga10...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El Thu, 16 Oct 2014 21:35:26 +0200, José Miguel (sio2) escribió: > El Thu, 16 de Oct de 2014, a las 06:07:37PM +, Camaleón dijo: > >> Sí, eso está claro, pero estamos hablando de tu caso donde además >> necesitas una configuración muy concreta y donde sí controlas los >> clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y >> además, puedes configurar los clientes para que envíen como UID la >> dirección MAC. > > No, no puedo, aunque controle los clientes; porque, aun habiendo en > principio dos soluciones: > > a) Hacer que todos los sistemas enviaran el mismo UID. > b) Hacer que ningún sistema enviara el UID. > > La a) no puedo hacerla porque no puedo manipular el arranque por red. > La b) no puedo hacerla porque el cliente de windows siempre envía un UID > y no hay forma de que no lo envíe: lo más que deja es cambiarlo, pero > siempre envía uno. Con la opción b) puedes decirle que envíe como UID la dirección MAC editando manualmente el campo desde los clientes lo que a todos los efectos sería como si sólo se le enviara un dato,o al menos als ervidor sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección MAC). >> ¿Dices que el cliente mantiene una base de datos local con la última >> dirección que se le ha asignado y solicita esa dirección cuando tiene >> que renovar la IP?i > > > Sí, en /var/lib/dhcp/dhclient.nombre_interfaz.conf. El cliente le > sugiere al servidor una ip (la última que se le concedió) ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ dhclient.leases" :-? >> Pensaba que eso no dependía del cliente sino del servidor. > > La concesión de la IP depende en última instancia del servidor, pero el > cliente puede sugerirle una ip (opción 50), cuando hace la petición. Si > no hay ningún impedimento, el servidor le hace caso, y se la entrega. No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a clientes que usan BOOTP? >> Bueno, ahí estás manipulando la configuración y además sin reiniciar >> los demonios, no es una prueba fiable. > > Da igual que reinicie el demonio: la caché está en un fichero. Si lo > reinicio, el servidor sigue recordando qué ips entregó, porque las lee > del fichero. Para limpiar la caché del servidor DHCP hay que vaciar por > completo ese fichero (/var/lib/dhcp/dhcpd.conf). Pero ese archivo de leases no parece una base de datos sino un archivo de información que le ha enviado el servidor. >> ¿Y no crees que si los clientes no solicitaran la renovación el >> servidor mantendría una única IP (la primera que les ha dado) para cada >> uno de ellos? > > No creo que sea un problema de renovaciones: más bien es un problema de > revocaciones. Me he dado cuenta de que cuando en linux se baja la > interfaz, dhclient le dice al servidor DHCP que libere la ip, y éste lo > hace, aunque la concesión pudiera haberse alargado más. Con los windows > en cambio no parece que pase eso: aunque el sistema se apague, la > concesión sigue vigente, así que si luego arranco linux la ip que se > concedió en windows, sigue ocupada. Si windows obrara como linux, no > habría ningún problema, salvo en el caso de que se apagara windows de > improviso (por un corte de luz) y la petición de revocación no se > efectura. No sé... yo sigo pensando que si el cliente no pide otra IP al servidor no volverías a tener problemas porque mantendría la misma durante toda la sesión, salvo, efectivamente que el equipo reiniciara o recargara el demonio de la red y no tuviera información alguna de los leases que como dices más arriba, debería usar los datos de la última configuración que ha recibido del servidor. >>> No sé, o hay un error en la programación o un error en la >>> documentación. >> Yo apuesto más por el fallo humano, que nos gustaría que se tratara de >> un parámetro que haga lo que queremos pero que sirve para otra cosa >> O:-) > > Bueno, en ese caso es un error de documentación: se interpreta una cosa > que no es. Además, no hay nadie (o yo no lo he visto) que diga por qué > no funciona y cuál es la verdadera interpretación. > >> Porque entonces el cliente podría estar pidiendo direcciones IP >> distintas continuamente, primero una (192.168.0.1), luego otra >> (192.168.0.2) y reserva la anterior, luego pide otra (192.168.0.n) y >> aunque sigue con la primera reservada no la usa, luego pide otra y se >> le da la reservada (192.168.0.1) y así... > > No, cada vez que pidiera una ip distinta y se le concediera, se > liberarían todas las ips que se hubieran asignado anteriormente a esa > MAC (eso es lo que yo y muchos entendemos al leer el manual). Por tanto, > un cliente podría haber tenido muchas ips, pero sólo habría ocupado una > en cada momento. Pero eso no ataca el problema de fondo que es evitar que los clientes pidan (u obtengan) direcciones distintas cada vez. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-
Re: DHCP: máquinas que consumen dos ips
El Thu, 16 de Oct de 2014, a las 06:07:37PM +, Camaleón dijo: > Sí, eso está claro, pero estamos hablando de tu caso donde además > necesitas una configuración muy concreta y donde sí controlas los > clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y > además, puedes configurar los clientes para que envíen como UID la > dirección MAC. No, no puedo, aunque controle los clientes; porque, aun habiendo en principio dos soluciones: a) Hacer que todos los sistemas enviaran el mismo UID. b) Hacer que ningún sistema enviara el UID. La a) no puedo hacerla porque no puedo manipular el arranque por red. La b) no puedo hacerla porque el cliente de windows siempre envía un UID y no hay forma de que no lo envíe: lo más que deja es cambiarlo, pero siempre envía uno. > ¿Dices que el cliente mantiene una base de datos local con la última > dirección que se le ha asignado y solicita esa dirección cuando tiene que > renovar la IP?i Sí, en /var/lib/dhcp/dhclient.nombre_interfaz.conf. El cliente le sugiere al servidor una ip (la última que se le concedió) > Pensaba que eso no dependía del cliente sino del servidor. La concesión de la IP depende en última instancia del servidor, pero el cliente puede sugerirle una ip (opción 50), cuando hace la petición. Si no hay ningún impedimento, el servidor le hace caso, y se la entrega. > Bueno, ahí estás manipulando la configuración y además sin reiniciar los > demonios, no es una prueba fiable. Da igual que reinicie el demonio: la caché está en un fichero. Si lo reinicio, el servidor sigue recordando qué ips entregó, porque las lee del fichero. Para limpiar la caché del servidor DHCP hay que vaciar por completo ese fichero (/var/lib/dhcp/dhcpd.conf). > De todas formas, si aumentas el nivel > de depuración del registro esa información debería aparecer en el syslog, > bien del cliente o del servidor. Por curiosidad, si tengo tiempo uno de estos días miraré a ver si en syslog dice algo diferente el servidor con el "deny duplicates" o sin él. > ¿Y no crees que si los clientes no solicitaran la renovación el servidor > mantendría una única IP (la primera que les ha dado) para cada uno de > ellos? No creo que sea un problema de renovaciones: más bien es un problema de revocaciones. Me he dado cuenta de que cuando en linux se baja la interfaz, dhclient le dice al servidor DHCP que libere la ip, y éste lo hace, aunque la concesión pudiera haberse alargado más. Con los windows en cambio no parece que pase eso: aunque el sistema se apague, la concesión sigue vigente, así que si luego arranco linux la ip que se concedió en windows, sigue ocupada. Si windows obrara como linux, no habría ningún problema, salvo en el caso de que se apagara windows de improviso (por un corte de luz) y la petición de revocación no se efectura. > > Sí soluciona el problema "fixed-address", porque se puede asociar la ip > > a una MAC con independencia del UID. > > Pero ya has dicho que esta opción no la querías usar ¿no? :-? Sí, ya dije eso. >> No sé, o hay un error en la programación o un error en la documentación. > Yo apuesto más por el fallo humano, que nos gustaría que se tratara de un > parámetro que haga lo que queremos pero que sirve para otra cosa O:-) Bueno, en ese caso es un error de documentación: se interpreta una cosa que no es. Además, no hay nadie (o yo no lo he visto) que diga por qué no funciona y cuál es la verdadera interpretación. > Porque entonces el cliente podría estar pidiendo direcciones IP distintas > continuamente, primero una (192.168.0.1), luego otra (192.168.0.2) y > reserva la anterior, luego pide otra (192.168.0.n) y aunque sigue con la > primera reservada no la usa, luego pide otra y se le da la reservada > (192.168.0.1) y así... No, cada vez que pidiera una ip distinta y se le concediera, se liberarían todas las ips que se hubieran asignado anteriormente a esa MAC (eso es lo que yo y muchos entendemos al leer el manual). Por tanto, un cliente podría haber tenido muchas ips, pero sólo habría ocupado una en cada momento. > Saludos, Un saludo. Gracias. -- Sabed que menda es don Mendo. --- Muñoz Seca --- -- 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/20141016193526.ga19...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El Thu, 16 Oct 2014 18:27:37 +0200, José Miguel (sio2) escribió: > El Tue, 14 de Oct de 2014, a las 02:01:16PM +, Camaleón dijo: > >> Pero ahí no dice que el uso único de MAC como identificador vulnere >> ninguna especificación ni normativa, sólo avisa de que ese valor no es >> fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema. >> De hecho dice expresamente (MUST) que si el cliente no envía UID alguno >> el servidor usará la MAC. Además, nada te impide usar la dirección MAC >> como identificador (UID) ;-) > > Claro, si el cliente no envía UID se usa la MAC, pero al cliente no lo > controlas, así que no puedes forzarlo que no te envíe un UID y, si te lo > envía, debes (MUST) usarlo. Si el servidor no atiende el UID y sólo se > fija en la MAC, viola el RFC. Sí, eso está claro, pero estamos hablando de tu caso donde además necesitas una configuración muy concreta y donde sí controlas los clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y además, puedes configurar los clientes para que envíen como UID la dirección MAC. >> Me refería a que en tu configuración, que no tiene configurada ninguna >> reserva específica de direcciones IP para los clientes (ya has dicho >> que no quieres usar la opción de "fixed-address") cuando un equipo pide >> renovar la IP no solicita al servidor ninguna en concreto, sólo que la >> renueve. > > La opción "fixed-address" está fijada en el servidor: el cliente no > tiene nada que ver con ella (salvo que tiene la MAC que hay en la > declaración "host"). Así que haya "fixed-address" o no la haya el > cliente siempre se comporta de la misma manera: pidiendo la última ip > que se le concedió. El que actúa de diferente forma es el servidor, que > siempre le da la misma en cualquier caso (incluso si no coinciden los > UID). ¿Dices que el cliente mantiene una base de datos local con la última dirección que se le ha asignado y solicita esa dirección cuando tiene que renovar la IP? Pensaba que eso no dependía del cliente sino del servidor. > Para comprobar el "one-lease-per-client true;", yo mismo me metí en la > caché del cliente y sustituí un 66, por un 67; para hacerle creer al > cliente que le habían concedido anteriormente la 67. Cuando volví a > pedir ip, el servidor le dio la .67 y desechó la .66: señal de que el > cliente le había pedido la .67. Bueno, ahí estás manipulando la configuración y además sin reiniciar los demonios, no es una prueba fiable. De todas formas, si aumentas el nivel de depuración del registro esa información debería aparecer en el syslog, bien del cliente o del servidor. >> Simplemente que revises cuándo expiran los leases de los clientes y >> mires a ver si no te convendría hacerlos perpetuos (que no renueven >> bajo ninguna circunstancia), así el servidor sólo les asignará una >> dirección. > > Eso no resuelve el problema: mi problema no es que expiren las ips, sino > que una MAC puede recibir varias concesiones si se enviaron distintos > UID. Es más, esto agravaría el problema: si las concesiones son cortas, > puede que tenga suerte y, cuando arranque linux, ya haya expirado la > concesión que se hizo cuando arranqué windows. ¿Y no crees que si los clientes no solicitaran la renovación el servidor mantendría una única IP (la primera que les ha dado) para cada uno de ellos? > Sí soluciona el problema "fixed-address", porque se puede asociar la ip > a una MAC con independencia del UID. Pero ya has dicho que esta opción no la querías usar ¿no? :-? >> Hombre, el comentario que he puesto antes es de la lista de usuarios de >> ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la >> definición del manual da lugar a muchas interpretaciones. > > Yo, en realidad, lo que veo es gente que interpreta más o menos lo mismo > que interpreté yo, pero a la que luego no le salen las cosas. Y, además, > no hay nadie que argumente por qué no salen. > > No sé, o hay un error en la programación o un error en la documentación. Yo apuesto más por el fallo humano, que nos gustaría que se tratara de un parámetro que haga lo que queremos pero que sirve para otra cosa O:-) >> > Creo que la interpretación más lógica es la siguiente: >> > >> > 1. En el servidor hay una reserva vigente asociada a una MAC. >> > 2. Le llega la petición de un cliente con una MAC igual, pero >> > distinto >> >UID (si el UID fuera el mismo, no hay ningún problema). >> > 3. El servidor desecha la reserva anterior asociada a esa MAC y le da >> >una ip al cliente. No se especifica que sea la misma o no. Incluso >> >podría ser distinta, si el propio cliente le sugiere que le dé >> >otra diferente. El caso es que en el servidor siempre hay una sóla >> >reserva asociada a cada MAC (de ahí el nombre de "deny >> >duplicates"). >> >> Pero no serviría para el propósito que persigue el "deny duplicates" >> que es evitar que un cliente solicite direcciones IP >> indiscriminadamente y las agote. > > ¿Por qué no? S
Re: DHCP: máquinas que consumen dos ips
El Tue, 14 de Oct de 2014, a las 02:01:16PM +, Camaleón dijo: > Pero ahí no dice que el uso único de MAC como identificador vulnere > ninguna especificación ni normativa, sólo avisa de que ese valor no es > fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema. De > hecho dice expresamente (MUST) que si el cliente no envía UID alguno el > servidor usará la MAC. Además, nada te impide usar la dirección MAC como > identificador (UID) ;-) Claro, si el cliente no envía UID se usa la MAC, pero al cliente no lo controlas, así que no puedes forzarlo que no te envíe un UID y, si te lo envía, debes (MUST) usarlo. Si el servidor no atiende el UID y sólo se fija en la MAC, viola el RFC. > Me refería a que en tu configuración, que no tiene configurada ninguna > reserva específica de direcciones IP para los clientes (ya has dicho > que no quieres usar la opción de "fixed-address") cuando un equipo > pide renovar la IP no solicita al servidor ninguna en concreto, sólo > que la renueve. La opción "fixed-address" está fijada en el servidor: el cliente no tiene nada que ver con ella (salvo que tiene la MAC que hay en la declaración "host"). Así que haya "fixed-address" o no la haya el cliente siempre se comporta de la misma manera: pidiendo la última ip que se le concedió. El que actúa de diferente forma es el servidor, que siempre le da la misma en cualquier caso (incluso si no coinciden los UID). Para comprobar el "one-lease-per-client true;", yo mismo me metí en la caché del cliente y sustituí un 66, por un 67; para hacerle creer al cliente que le habían concedido anteriormente la 67. Cuando volví a pedir ip, el servidor le dio la .67 y desechó la .66: señal de que el cliente le había pedido la .67. > Simplemente que revises cuándo expiran los leases de los clientes y mires > a ver si no te convendría hacerlos perpetuos (que no renueven bajo > ninguna circunstancia), así el servidor sólo les asignará una dirección. Eso no resuelve el problema: mi problema no es que expiren las ips, sino que una MAC puede recibir varias concesiones si se enviaron distintos UID. Es más, esto agravaría el problema: si las concesiones son cortas, puede que tenga suerte y, cuando arranque linux, ya haya expirado la concesión que se hizo cuando arranqué windows. Sí soluciona el problema "fixed-address", porque se puede asociar la ip a una MAC con independencia del UID. > Hombre, el comentario que he puesto antes es de la lista de usuarios de > ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la > definición del manual da lugar a muchas interpretaciones. Yo, en realidad, lo que veo es gente que interpreta más o menos lo mismo que interpreté yo, pero a la que luego no le salen las cosas. Y, además, no hay nadie que argumente por qué no salen. No sé, o hay un error en la programación o un error en la documentación. > > Creo que la interpretación más lógica es la siguiente: > > > > 1. En el servidor hay una reserva vigente asociada a una MAC. > > 2. Le llega la petición de un cliente con una MAC igual, pero distinto > >UID (si el UID fuera el mismo, no hay ningún problema). > > 3. El servidor desecha la reserva anterior asociada a esa MAC y le da > >una ip al cliente. No se especifica que sea la misma o no. Incluso > >podría ser distinta, si el propio cliente le sugiere que le dé otra > >diferente. El caso es que en el servidor siempre hay una sóla reserva > >asociada a cada MAC (de ahí el nombre de "deny duplicates"). > > Pero no serviría para el propósito que persigue el "deny duplicates" que > es evitar que un cliente solicite direcciones IP indiscriminadamente y > las agote. ¿Por qué no? Si al concedérsele una IP, se desechan las otras concesiones a esa misma MAC, resulta que una MAC sólo estaría reservando en cada momento una sola IP. Por tanto, un cliente (entendiendo cliente=MAC) no agotaría indiscriminadamente ips. > Los resultados que has obtenido son los mismos que los que ha obtenido el > resto de personas que lo han intentado pensando que servía para eso. Se > ve que no. Es cierto, no tengo mucha fe. De todos modos, algunos de los casos que he consultado en internet tenían un error manifiesto de configuración: la MAC no la habían declarado en una declaración HOST, cosa que el manual dice que es necesario. Otros en cambio, sí lo habían hecho... Ya hice la prueba de meter a las máquinas que arrancan por red (PXEClient) en una clase aparte y hacerles: a) Cortita la concesión de la ip. b) Meterlos en el pool "general", de manera que reciban una ip del rango que queda para las máquinas que no son de ninguna clase en especial. Con eso y con configurar el dhclient para que envíe el mismo UID que linux, basta. No me entusiasma la solución, pero no hay otra (excepto la de usar fixed-address, claro). > Saludos, Saludos. -- El hombre que se ríe de todo es que todo lo desprecia. La mujer que se ríe de todo es que sabe que tiene una dentadura bonita.
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 Oct 2014 21:52:21 +0200, José Miguel (sio2) escribió: > El Mon, 13 de Oct de 2014, a las 05:39:34PM +, Camaleón dijo: > >> ¿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? :-? > > Pues no recuerdo bien (incluso quizás me lo he inventado o lo me > malinterpretado), así que me he ido al RFC 2131 y he leído en la sección > 4.2: > > > DHCP server needs to use some unique identifier to associate a client > with its lease. The client MAY choose to explicitly provide the > identifier through the 'client identifier' option. If the client > supplies a 'client identifier', the client MUST use the same 'client > identifier' in all subsequent messages, and the server MUST use that > identifier to identify the client. If the client does not provide a > 'client identifier' option, the server MUST use the contents of the > 'chaddr' field to identify the client. It is crucial for a DHCP client > to use an identifier unique within the subnet to which the client is > attached in the 'client identifier' option. Use of 'chaddr' as the > client's unique identifier may cause unexpected results, as that > identifier may be associated with a hardware interface that could be > moved to a new client. Some sites may choose to use a manufacturer's > serial number as the 'client identifier', to avoid unexpected changes in > a clients network address due to transfer of hardware interfaces among > computers. Sites may also choose to use a DNS name as the 'client > identifier', causing address leases to be associated with the DNS name > rather than a specific hardware box. > > Ahí dice que el servidor debe usar el UID si el cliente se lo ha > enviado; y sólo usar la MAC, si no le envió ninguno. Así que pasar del > UID y fijarse sólo en la MAC, viola este RFC. Yo lo entiendo así y > supongo que por eso el servidor del ISC no lo ha implementado. Pero ahí no dice que el uso único de MAC como identificador vulnere ninguna especificación ni normativa, sólo avisa de que ese valor no es fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema. De hecho dice expresamente (MUST) que si el cliente no envía UID alguno el servidor usará la MAC. Además, nada te impide usar la dirección MAC como identificador (UID) ;-) >> El cliente no debe pedir ninguna IP en especial, > > Sí, sí que puede pedir una: es la opción 50. El paquete DHCPREQUEST > incluye esa opción. Mira el contenido de este tipo de paquete: (...) Me refería a que en tu configuración, que no tiene configurada ninguna reserva específica de direcciones IP para los clientes (ya has dicho que no quieres usar la opción de "fixed-address") cuando un equipo pide renovar la IP no solicita al servidor ninguna en concreto, sólo que la renueve. >> 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. > > No entiendo qué quieres decir. Simplemente que revises cuándo expiran los leases de los clientes y mires a ver si no te convendría hacerlos perpetuos (que no renueven bajo ninguna circunstancia), así el servidor sólo les asignará una dirección. >> 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. > > El único elemento de juicio que tenemos para opinar es lo que dice la > página del manual, que copio otra vez: (...) Hombre, el comentario que he puesto antes es de la lista de usuarios de ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la definición del manual da lugar a muchas interpretaciones. > Yo entendí en un principio que esto me servía, porque era una forma de > violar el punto 4.2 del RFC: aunque los UID sean diferentes, si la MAC > es igual (siempre que haya una declaración "host" con ella según el > primer párrafo), el servidor desecha todas las otras reservas que le > hizo a esa MAC. Entendí que me servía, porque esto me aseguraría que > siempre habría una sola ip reservada para cada MAC. Y no eres el único que lo entiende así, como ya has visto. Pero parece que no hace lo que la gente espera. > Tú argumentaste que quizás lo único que hace es evitar que me dé otra > ip. Releyendo ahora me parece que no tienes razón o que no se puede > entender lo que pensaste en un momento. Mi argumento iba en relación a la prueba que habías hecho de pasarle primero un UID, pedir una IP y después volver a pedirle una IP sin pasarle el identificador. > Creo que la interpretación más lógica es la sigu
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 de Oct de 2014, a las 05:39:34PM +, Camaleón dijo: > ¿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? :-? Pues no recuerdo bien (incluso quizás me lo he inventado o lo me malinterpretado), así que me he ido al RFC 2131 y he leído en la sección 4.2: DHCP server needs to use some unique identifier to associate a client with its lease. The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the 'client identifier' option. Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box. Ahí dice que el servidor debe usar el UID si el cliente se lo ha enviado; y sólo usar la MAC, si no le envió ninguno. Así que pasar del UID y fijarse sólo en la MAC, viola este RFC. Yo lo entiendo así y supongo que por eso el servidor del ISC no lo ha implementado. > El cliente no debe pedir ninguna IP en especial, Sí, sí que puede pedir una: es la opción 50. El paquete DHCPREQUEST incluye esa opción. Mira el contenido de este tipo de paquete: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_request Incluye la opción 50. Y una explicación más prolija de para qué sirve la opción 50, aquí: http://www.cisco.com/c/en/us/td/docs/net_mgmt/network_registrar/6-1-1/user/guide/users/UserApB.html#wp1069731 "Used in a client request (DHCPDISCOVER) to allow the client to request that a particular IP address be assigned." En el DHCPDISCOVER (si miras la página de la wiki) verás que también se puede incluir la opción. Esa es la razón por la que los ordenadores (si son menos que ips disponibles) suelen obtener siempre la misma ip: piden la que obtuvieron por última vez, y, si tienen suerte, estará libre y el servidor se la volverá a conceder. Si no lo está, el servidor les asigna otra. > 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. No entiendo qué quieres decir. > 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. El único elemento de juicio que tenemos para opinar es lo que dice la página del manual, que copio otra vez: $ man 5 dhcpd.conf [...] The duplicates keyword allow duplicates; deny duplicates; Host declarations can ma
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 +, 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 s
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 de Oct de 2014, a las 03:52:14PM +, 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 --
--
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/20141013172324.ga25...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El 13/10/2014 17:53, "Camaleón" 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 +, 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
Re: DHCP: máquinas que consumen dos ips
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 +, 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 doi
Re: DHCP: máquinas que consumen dos ips
El Sun, 12 de Oct de 2014, a las 09:02:12PM +, 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. > ¿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. > > 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. > 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, 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). > > 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. > 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. Al final creo que voy a optar por la solución de meter los clientes en una clase aparte cuando arranquen por PXE. 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 -- -- 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/20141013151410.ga21...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El Sun, 12 Oct 2014 21:04:33 +0200, José Miguel (sio2) escribió:
> El Sun, 12 de Oct de 2014, a las 11:45:06AM +, 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.
¿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? :-?
>> 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.
(...)
¿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 :-)
>> 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.
¿Y con "deny duplicates" sigue la .66 ocupada o el servidor la ha
liberado?
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.
>> 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.
Y también en el cliente podrás obtener información jugosa (creo que esto
va a parar al /var/log/syslog).
>> 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:
(...)
> 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 ha
Re: DHCP: máquinas que consumen dos ips
El Sun, 12 de Oct de 2014, a las 11:45:06AM +, 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 d
Re: DHCP: máquinas que consumen dos ips
El Sat, 11 Oct 2014 23:30:20 +0200, José Miguel (sio2) escribió:
> Un saludo a la lista:
>
> Tengo un pequeño problema, del que creía haber hallado la solución, pero
> que no me acaba de funcionar.
>
> Resulta que hay una serie de máquinas que he metido en un rango de ips,
> de manera que hay el mismo número de ips que de máquinas. Mientras cada
> máquina sólo consuma una ip no hay problema.
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.
> Sin embargo, el servidor DHCP usa como criterio para decidir sin un
> cliente es el mismo o no, no la MAC, sino preferentemente un
> identificador que el cliente le envía. Resulta que linux de modo
> predeterminado o el arranque por red no envían ningún identificador,
> mientras que windows sí lo hace. La consecuencia es que estos
> ordenadores pueden consumir más de una ip y se me fastidia el invento,
> porque las ips se acaban.
(...)
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.
> Y creí llegar a la solución: incluyo "deny duplicates" en el fichero de
> configuración y, si las máquinas están declaradas (que lo están),
> recibirán siempre una ip, aunque envíen distinto uid.
>
> Pero no me funciona. No sé si es que no he entendido algo o si me falla
> algo.
(...)
> Si prueba a fijar un "uid" a dhclient, obtengo la 192.168.129.66, como
> es de esperar. Si lo quito y vuelvo a pedir ip, ya no obtengo ninguna,
> en vez de obtener la misma; muy a pesar de la cláusula "deny
> duplicates". ¿Se me ha pasado algo por alto?
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.
De todas formas, revisa en registro para ver qué es lo que hace
exactamente y consulta también la opción "one-lease-per-client", es
posible que tengas que combinar ambas para que funcione.
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.12.11.45...@gmail.com
DHCP: máquinas que consumen dos ips
Un saludo a la lista:
Tengo un pequeño problema, del que creía haber hallado la solución, pero
que no me acaba de funcionar.
Resulta que hay una serie de máquinas que he metido en un rango de ips,
de manera que hay el mismo número de ips que de máquinas. Mientras cada
máquina sólo consuma una ip no hay problema.
Sin embargo, el servidor DHCP usa como criterio para decidir sin un
cliente es el mismo o no, no la MAC, sino preferentemente un
identificador que el cliente le envía. Resulta que linux de modo
predeterminado o el arranque por red no envían ningún identificador,
mientras que windows sí lo hace. La consecuencia es que estos
ordenadores pueden consumir más de una ip y se me fastidia el invento,
porque las ips se acaban.
Estuve leyendo y llegué a esto:
$ man 5 dhcpd.conf
[...]
The duplicates keyword
allow duplicates;
deny duplicates;
Host declarations can match client messages based on the DHCP
Client Identifier option or based on the client's network
hardware type and MAC address. If the MAC address is used, the
host declaration will match any client with that MAC address -
even clients with different client identifiers. This doesn't
normally happen, but is possible when one computer has more than
one operating system installed on it - for example, Microsoft
Windows and NetBSD or Linux.
The duplicates flag tells the DHCP server that if a request is
received from a client that matches the MAC address of a host
declaration, any other leases matching that MAC address should be
discarded by the server, even if the UID is not the same. This
is a violation of the DHCP protocol, but can prevent clients
whose client identifiers change regularly from holding many
leases at the same time. By default, duplicates are allowed.
[...]
Y creí llegar a la solución: incluyo "deny duplicates" en el fichero de
configuración y, si las máquinas están declaradas (que lo están),
recibirán siempre una ip, aunque envíen distinto uid.
Pero no me funciona. No sé si es que no he entendido algo o si me falla
algo.
La configuración pertinente para el caso la tengo así:
#v+
deny duplicates;
[...]
subnet 192.168.129.0 netmask 255.255.255.0 {
option routers 192.168.129.1;
option domain-name-servers 192.168.129.1;
option domain-name "smr2.dominio.com";
option domain-search "smr2.dominio.com", "dominio.com";
option ntp-servers time.smr2.dominio.com;
ddns-domainname "smr2.dominio.com";
ddns-rev-domainname "in-addr.arpa";
option broadcast-address 192.168.129.255;
option aula "smr2";
zone smr2.dominio.com {
primary 127.0.0.1;
key "rndc-key";
}
zone 129.168.192.in-addr.arpa {
primary 127.0.0.1;
key "rndc-key";
}
pool {
allow known-clients;
range 192.168.129.66 192.168.129.66;
}
pool {
denyknown-clients;
range 192.168.129.67 192.168.129.254;
}
group {
use-host-decl-names on;
update-static-leases on;
host pc05-vlan9 {
hardware ethernet 00:11:22:33:44:55;
ddns-hostname "pc05";
}
}
}
#v-
Si prueba a fijar un "uid" a dhclient, obtengo la 192.168.129.66, como
es de esperar. Si lo quito y vuelvo a pedir ip, ya no obtengo ninguna,
en vez de obtener la misma; muy a pesar de la cláusula "deny
duplicates". ¿Se me ha pasado algo por alto?
De antemano, gracias.
--
Femmina è cosa mobil per natura.
--- Francisco Petrarca ---
--
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/20141011213020.ga9...@cubo.casa
