¿Cómo se manejan dos declaraciones de "dirección de ayuda ip"?

15

He descubierto una subred con dos declaraciones de "dirección de ayuda ip". Esta no es nuestra configuración normal.

interface Vlan300
 ip address 10.1.3.2 255.255.255.0
 ip helper-address 10.2.1.10
 ip helper-address 10.3.1.10

Mirando nuestros servidores DHCP, parece que hay arrendamientos provenientes de ambos.

Me doy cuenta de que esto no se recomienda, y los dos servidores DHCP pueden no estar al tanto de las asignaciones de arrendamiento del otro (estoy bastante seguro de que no lo hacen).

La pregunta es, ¿cómo maneja esto el conmutador Cisco (4510 Sup7 12.2)?

¿Es el primer servidor DHCP en responder?
¿Es el primero, luego el segundo si el primero se agota?
¿Es round robin?

cisco dhcp

— Pseudocyber
fuente

12

El ip helper-addresscomando designa una dirección a la que se reenvían las transmisiones; enviará el paquete original a cada una de las direcciones enumeradas.

Si ambos responden, ambas respuestas se reenvían a LAN.

— ytti
fuente

1

Entonces, el host tomaría una IP de cualquier servidor DHCP que respondiera primero: ¿es probable que gane el que esté más cerca, si el otro está sobre una WAN?

— Pseudocyber

2

Ordinariamente sí. Una razón para hacerlo sería la conmutación por error / HA de DHCP (por ejemplo, ISC DHCPD lo admite)

— LapTop006

2

ACK LapTop006 está en lo cierto. El cliente DHCP manejará esta situación de doble oferta mediante un diseño elegante, no se requiere una implementación específica.

— ytti

6

Su ip-helper es la forma correcta de hacer esto por redundancia y es el método recomendado.

DHCPDiscovery (broadcast) es recogido por el ip-helper y luego se unicast a cada servidor DHCP con el agente de retransmisión (el enrutador) en la solicitud.

Por lo general, el primer servidor DHCP en responder gana. Ambos servidores DHCP pueden (y deberían) hacer DCHPOffers para el cliente. Es el cliente el que decide cuál conservar y luego envía una DHCPRequest (unicast) al servidor que la ofreció para la IP que desea usar. El servidor necesita DHCPAck esa solicitud para completar el proceso.

Para la redundancia, pero para no violar la regla DHCP de no tener ámbitos superpuestos definidos para sus grupos de IP, necesita dos ayudantes de IP. Como los servidores DHCP no se conocen entre sí, los grupos de IP deben ser únicos. Un método común para la redundancia de DHCP es tomar su subred / 24 típica y dividirla en dos / 25 para sus ámbitos (uno por servidor).

Ejemplo: 192.0.2.0/24 es su red real, por lo que la divide en 192.0.2.0/25 y 192.0.2.128/25. Por lo tanto, las aproximadamente 256 direcciones se dividen en dos grupos de 128 direcciones y se asignan a cada ámbito DHCP. Ahora no tiene direcciones superpuestas + redundancia.

Dado que reduce su grupo de alcance a la mitad, asegúrese de que los servidores puedan admitir toda su red si falla un servidor DHCP. Considere que el tiempo de arrendamiento es el tiempo que los clientes pueden retener sus direcciones donde no agotarán su grupo si tiene muchos clientes rotativos, sin embargo, podrán darle suficiente tiempo para detectar y reparar un servidor DHCP fallido.

— generalnetworkerror
fuente

1

En realidad, no desea dividirlos, sino configurar un alcance idéntico en todos los servidores dhcp y configurar rangos de exclusión únicos en cada uno. De esta manera, tendrá una mayor agilidad si un servidor se cae por un tiempo.

— Pauska

1

Las exclusiones tienden a quedar ocultas en la configuración y prefiero ver los dos ámbitos fácilmente identificados con sus grupos separados, por lo que no hay duda de lo que está haciendo cada servidor DHPC. Siempre que el diseño pueda manejar un servidor DHCP fallido durante un período de tiempo, no veo ningún problema con esto, pero estoy de acuerdo en que seguir la ruta de exclusiones es una mejor opción para algunos. (Estos comentarios son con respecto a la GUI de DHCP de Windows que oculta algunos de los detalles.)

— generalnetworkerror

2

IIRC, envía a los dos ayudantes configurados y el más rápido gana.

1

con respecto a su preocupación por el hecho de que DHCP no esté al tanto de los otros arrendamientos, antes de que se envíe un DHCPOFFER al host, el servidor DHCP envía un mensaje ICMP a la dirección IP, si el servidor DHCP recibe un mensaje de respuesta de eco ICMP, el DHCP el servidor elige una dirección IP diferente y envía otro mensaje ICMP a esa dirección IP hasta que no se reciba un mensaje de respuesta de eco ICMP, luego el servidor DHCP envía la dirección IP en el DHCPOFFER al host.

— Dave
fuente

Si así está configurado. Uno puede configurar su servidor DHCP para que no "proteja" las tareas de esa manera.

— Ricky Beam

Iría un poco más allá de Ricky y diría que esto ya no es una práctica común en muchas redes más grandes, ya que puede crear un problema de rendimiento en los servidores DHCP. La mayoría de las estaciones ahora ejecutan un firewall local y, a menudo, no responden a las solicitudes de ping, pero el servidor todavía tiene que esperar un tiempo de espera por solicitud. Esto también hace que la función sea menos útil (la estación con firewall no responderá, el servidor tuvo que esperar a que se agote el tiempo de espera de la solicitud y aún se produce un conflicto de IP).

— YLearn