El propósito de este artículo es simplificar la configuración del servicio DHCP para la fábrica VXLAN BGP EVPN y DFA utilizando Microsoft Windows Server 2016/2019.
En la documentación oficial, el servicio DHCP basado en Microsoft Windows Server 2012 para la fábrica se configura como SuperScope, que contiene un grupo Loopback (este grupo incluye la exclusión de todas las direcciones IP del grupo (excluded IP address = pool)) y grupos de asignación de direcciones IP para redes reales (aquí la peculiaridad es que se configuran policies que filtran el Circuit ID de DHCP Relay y este Circuit ID de DHCP Relay contiene VNI para la red, es decir, para otro grupo, este Circuit ID de DHCP Relay será un poco diferente).
Para configurar DHCP en el servidor de Windows.
1. Crea un super scope. Dentro del super scope, crea el scope B, S1, S2, S3, …, Sn para la subred B y las subredes para cada segmento.
2. En el scope B, especifica el 'Rango de Exclusión' para ser todo el rango de direcciones (para que el rango de direcciones ofrecido no deba provenir de este scope).
3. Para cada segmento scope Si, especifica una policy que coincida con el Agent Circuit ID con un valor de '0108000600XXXXXX', donde '0108000600' es un valor fijo para todos los segmentos, los 6 números "XXXXXX" son el valor del ID del segmento en hexadecimal. Asegúrate de marcar la casilla de verificación de Agregar comodín (*).
4. Establece el rango de direcciones de la policy para todo el rango del scope.Este artículo contiene respuestas a las siguientes preguntas:
Contenido
- ( & )
Introducción
En esta parte se enumeran brevemente todos los datos de origen: Instrucciones para la configuración de dispositivos de red, RFC utilizados en los paquetes DHCP en fábricas eVPN, se proporciona una visión general de la evolución de la configuración del servidor DHCP en Microsoft Windows Server 2012 en la documentación de Cisco. También se incluyen breves detalles sobre Superscope y Policy en el servicio DHCP en servidores Microsoft Windows Server.
¿Cómo se configura DHCP Relay en la fábrica VXLAN BGP EVPN, DFA?
La configuración de DHCP Relay en la fábrica VXLAN BGP EVPN no es el tema principal de este artículo, ya que es bastante simple. Proporciono enlaces a la documentación y un resumen sobre la configuración en los dispositivos de red.
Ejemplo de configuración de DHCP Relay en Nexus 9000V v9.2(3)
servicio dhcp
ip retransmisión dhcp
opción de información de retransmisión dhcp
opción de información de retransmisión dhcp vpn
interfaz loopback10
miembro de vrf VRF1
dirección ip 10.120.0.1/32 etiqueta 1234567
interfaz Vlan12
sin apagado
miembro de vrf VRF1
sin redirecciones ip
dirección ip 10.120.251.1/24 etiqueta 1234567
sin redirecciones ipv6
modo de reenvío de tejido puerta de enlace anycast
dirección de retransmisión dhcp ip 10.0.0.5
interfaz de origen de retransmisión dhcp ip loopback10
RFC que se implementan en el servicio DHCP Relay en fábricas VXLAN BGP EVPN
RFC#6607: Sub-opción 151(0x97) — Selección de Subred Virtual
• Sub-opción 151(0x97) - Selección de Subred Virtual (Definida en RFC#6607)
Usado para transmitir información relacionada con VRF al servidor DHCP en un entorno multi-inquilino MPLS-VPN y VXLAN EVPN.Se transmite el "nombre" de VRF en el que se encuentra el cliente.
RFC#5107: Sub-opción 11(0xb) — Anulación de ID de Servidor
• Sub-opción 11(0xb) - Anulación de ID de Servidor (Definida en RFC#5107.)
La sub-opción de anulación del identificador del servidor (servidor ID) permite al agente de retransmisión DHCP especificar un nuevo valor para la opción de ID del servidor, que se inserta por el servidor DHCP en el paquete de respuesta. Esta sub-opción permite que el agente de retransmisión DHCP actúe como el servidor DHCP real de modo que las solicitudes de renovación vengan al agente de retransmisión en lugar de al servidor DHCP directamente. La sub-opción de anulación de ID de servidor contiene la dirección IP de la interfaz de entrada, que es la dirección IP en el agente de retransmisión que es accesible desde el cliente. Usando esta información, el cliente DHCP envía todos los paquetes de renovación y liberación al agente de retransmisión. El agente de retransmisión agrega todas las sub-opciones apropiadas y luego reenviará los paquetes de solicitud de renovación y liberación al servidor DHCP original. Para esta función, la implementación propietaria de Cisco es la sub-opción 152(0x98). Puedes usar el comando ip dhcp relay sub-option type cisco para gestionar la función.La opción se utiliza para que el cliente envíe una solicitud de renovación de arrendamiento de dirección a la dirección IP utilizada en esta opción. (En Cisco VXLAN BGP EVPN, esta es la dirección anycast de la puerta de enlace por defecto para el cliente.)
RFC#3527: Sub-opción 5(0x5) — Selección de Enlace
Sub-opción 5(0x5) - Selección de Enlace (Definida en RFC#3527.)
La sub-opción de selección de enlace proporciona un mecanismo para separar la subred/enlace en la que reside el cliente DHCP de la dirección de puerta de enlace (giaddr), que puede usarse para comunicar con el agente de retransmisión por el servidor DHCP. El agente de retransmisión establecerá la sub-opción en la subred del suscriptor correcta y el servidor DHCP utilizará ese valor para asignar una dirección IP en lugar del valor giaddr. El agente de retransmisión establecerá el giaddr en su propia dirección IP para que los mensajes DHCP puedan ser reenviados a través de la red. Para esta función, la implementación propietaria de Cisco es la sub-opción 150(0x96). Puedes usar el comando ip dhcp relay sub-option type cisco para gestionar la función.Dirección de la red de la cual se necesita la dirección IP para el cliente.
Evolución de la documentación de Cisco en cuanto a la configuración de DHCP en Microsoft Windows Server 2012
He incluido esta sección porque se observa una tendencia positiva por parte del proveedor:
La documentación solo proporciona la configuración de DHCP Relay en el equipo de red.
Para la configuración de DHCP en Windows Server 2012 se utilizó otro artículo:
Este artículo indica que para cada red/VNI es necesario un propio conjunto de SuperScope y un conjunto de direcciones Loopback propias:
Si se requieren múltiples Alcances DHCP para múltiples subredes, necesitas crear un LoopbackX por cada subred/vlan en todos los LEAFS y crear un superscope con un rango de loopbackX y el alcance de subred IP real por vlan.
Se añadieron configuraciones de Windows 2012 Server a la documentación sobre la configuración del equipo de red. Para todos los grupos de direcciones utilizados, se necesita un SuperScope en el centro de datos y este SuperScope es el límite del centro de datos:
Crea un Superscope para todos los alcances que deseas utilizar para políticas basadas en Opción 82. Nota: El Superscope debe combinar todos los alcances y actuar como el límite administrativo.
Se ha explicado de manera muy concisa sobre todo:
Supongamos que el switch está utilizando la dirección de la subred B (puede ser la subred de backbone, subred de gestión o cualquier subred designada por el cliente para este propósito) para comunicarse con el servidor DHCP de Windows. En DFA tenemos subredes S1, S2, S3, ..., Sn para los segmentos s1, s2, s3, ..., sn. Para configurar DHCP en el servidor Windows.
1. Crea un super scope. Dentro del super scope, crea el alcance B, S1, S2, S3, ..., Sn para la subred B y las subredes para cada segmento.
2. En el alcance B, especifica el 'Rango de Exclusión' para ser todo el rango de direcciones (para que el rango de direcciones ofrecido no deba ser de este alcance).
3. Para cada alcance de segmento Si, especifica una política que coincida con el ID de circuito del agente con el valor '0108000600XXXXXX', donde '0108000600' es un valor fijo para todos los segmentos, y los 6 números "XXXXXX" son el valor del ID de segmento en hexadecimal. También asegúrate de marcar la casilla de verificación de añadir comodín (*).
4. Establece el rango de direcciones de la política en todo el rango del alcance.
DHCP en Microsoft Windows Server (superscope & política)
El Superscope es una característica administrativa de un servidor DHCP que se puede usar para agrupar múltiples alcances como una sola entidad administrativa. El Superscope permite a un servidor DHCP proporcionar arrendamientos de más de un alcance a los clientes en una sola red física. Los alcances añadidos a un superscope se llaman alcances miembros. Qué es SuperScope: es una funcionalidad que permite combinar varios grupos de direcciones IP en una sola unidad administrativa. Para anunciar a los usuarios en una sola red física (en un mismo VLAN) direcciones IP de varios grupos. Si una solicitud llega a un grupo de direcciones en el SuperScope, se puede otorgar una dirección al cliente desde otro Scope que forma parte de este SuperScope.
El rol del servidor DHCP en Windows Server 2012 introduce una nueva característica que te permite crear políticas IPv4 que especifican direcciones IP personalizadas y asignaciones de opciones para los clientes DHCP basadas en un conjunto de condiciones. La función de asignación basada en políticas (PBA) te permite agrupar clientes DHCP por atributos específicos basados en campos contenidos en el paquete de solicitud del cliente DHCP. PBA permite una administración dirigida y un mayor control de los parámetros de configuración entregados a dispositivos de red con DHCP. Las políticas permiten asignar direcciones IP a los usuarios según el tipo de usuario o parámetro. Los ingenieros de Cisco utilizan políticas en Windows Server 2012 para filtrar por VNI (Identificador de Red Virtual).
Parte principal
En esta sección se presentan los resultados de las investigaciones sobre por qué no se admite, cómo funciona (lógica), qué hay de nuevo y cómo nos ayudará esta novedad.
¿Por qué no se admite Microsoft Windows Server 2000/2003/2008?
Microsoft Windows Server 2008 y versiones anteriores no procesan la opción 82 (Option 82) y envían el paquete de respuesta sin la opción 82.
- La solicitud del cliente se envía como Broadcast (DHCP Discover).
- El equipo (Nexus) envía un paquete al servidor DHCP (DHCP Discover + Option 82).
- El servidor DHCP recibe el paquete, lo procesa, pero envía la respuesta sin la opción 82. (DHCP Offer – sin opción 82)
- El equipo (Nexus) recibe el paquete del servidor DHCP. (DHCP Offer) Pero no envía este paquete al usuario final.
Datos del sniffer — en Windows Server 2008 y en el cliente DHCPWindows Server 2008 recibe una solicitud del equipo de red. (La opción 82 está presente en la lista)
Windows Server 2008 envía una respuesta al equipo de red. (La opción 82 no está en la lista de opciones en el paquete)
Solicitud del cliente – se presentan DHCP Discover y no hay DHCP Offer
Estadísticas en el equipo de red:
NEXUS-9000V-SW-1# show ip dhcp relay statistics
----------------------------------------------------------------------
Tipo de mensaje Rx Tx Drops
----------------------------------------------------------------------
Discover 8 8 0
Offer 8 8 0
Request(*) 0 0 0
Ack 0 0 0
Release(*) 0 0 0
Decline 0 0 0
Inform(*) 0 0 0
Nack 0 0 0
----------------------------------------------------------------------
Total 16 16 0
----------------------------------------------------------------------
DHCP L3 FWD:
Total de paquetes recibidos : 0
Total de paquetes reenviados : 0
Total de paquetes descartados : 0
No DHCP:
Total de paquetes recibidos : 0
Total de paquetes reenviados : 0
Total de paquetes descartados : 0
DROP:
DHCP Relay no habilitado : 0
Tipo de mensaje DHCP inválido : 0
Error de interfaz : 0
Fallo en Tx hacia el servidor : 0
Fallo en Tx hacia el cliente : 0
Interfaz de salida desconocida : 0
vrf o interfaz desconocida para el servidor : 0
Excedido el número máximo de saltos : 0
Validación de opción 82 fallida : 0
Paquete mal formado : 0
Puerto de Relay de confianza no configurado : 0
Solicitud DHCP descartada en MCT : 0
* - Estos contadores mostrarán el valor correcto cuando el switch
reciba un paquete de solicitud DHCP con la dirección IP de destino como dirección de broadcast. Si la solicitud es unicast, será conmutada por HW
NEXUS-9000V-SW-1#
¿Por qué la configuración en Microsoft Windows Server 2012 es tan compleja?
En Microsoft Windows Server 2012 aún no se admite RFC#3527 (Opción 82 Sub-opción 5(0x5) — Selección de Enlace)
Pero ya se ha implementado la funcionalidad de Políticas.
Cómo funciona:
- Microsoft Windows Server 2012 tiene un superpiscina (SuperScope) que incluye direcciones Loopback y piscinas para redes reales.
- La selección de la piscina para la asignación de direcciones IP cae en el SuperScope, ya que la respuesta provino de DHCP Relay con dirección de origen Loopback, que forma parte del SuperScope.
- Utilizando Políticas, la solicitud selecciona del Superscope el scope miembro, cuyo VNI está contenido en la Opción 82 Subopción 1 ID de Circuito del Agente. (“0108000600” + 24 bits VNI + 24 bits cuyo valor no conozco, pero el sniffer muestra valores 0 en este campo.)
¿Cómo se simplifica la configuración en Microsoft Windows Server 2016/2019?
En Microsoft Windows Server 2016 se ha implementado la funcionalidad RFC#3527. Es decir, Windows Server 2016 puede reconocer la red correcta a partir del atributo Opción 82 Sub-opción 5(0x5) — Selección de Enlace.
Inmediatamente surgen 3 preguntas:
- ¿Podemos prescindir del Superscope?
- ¿Podemos prescindir de Políticas y la conversión del VNI a formato hexadecimal?
- ¿Podemos prescindir de Scope para direcciones Loopback de DHCP Source?
P. ¿Podemos prescindir del Superscope?
R. Sí, se puede crear un scope directamente en el rango de direcciones IPv4.
P. ¿Podemos prescindir de Políticas y la conversión del VNI a formato hexadecimal?
R. Sí, la selección de la red se realiza sobre la base de Opción 82 Subopción 0x5.
P. ¿Podemos prescindir de Scope para direcciones Loopback de DHCP Source?
R. No, no podemos. Ya que en Microsoft Windows Server 2016/2019 existe protección contra solicitudes DHCP malintencionadas. Es decir, todas las solicitudes desde direcciones que no están en el pool del servidor DHCP se consideran malintencionadas.
Nota
Todas las direcciones IP del agente de retransmisión (GIADDR) deben ser parte de un rango de direcciones IP activas en el scope DHCP. Cualquier GIADDR fuera de los rangos de direcciones IP del scope DHCP se considera un agente de retransmisión no autorizado y el Servidor DHCP de Windows no reconocerá las solicitudes de cliente DHCP de esos agentes de retransmisión.
Se puede crear un scope especial para "autorizar" a los agentes de retransmisión. Crea un scope con el GIADDR (o múltiples si los GIADDR son direcciones IP secuenciales), excluye las direcciones GIADDR de la distribución, y luego activa el scope. Esto autorizará a los agentes de retransmisión mientras evita que las direcciones GIADDR sean asignadas.Es decir, para configurar un pool DHCP en Microsoft Windows Server 2016/2019 para la fábrica VXLAN BGP EVPN, solo es necesario:
- Crear un pool para las direcciones Source de la retransmisión.
- Crear un pool para redes de clientes.
Lo que no es estrictamente necesario (pero se puede configurar y funcionará sin interferir con el funcionamiento):
- Crear Políticas.
- Crear SuperScope.
EjemploEjemplo de configuración del servidor DHCP (hay 2 clientes DHCP reales presentes — los clientes están conectados a la fábrica VXLAN)
Ejemplo de configuración de pool personalizado:
Ejemplo de configuración de pool personalizado (se seleccionaron políticas — para demostrar que no se utilizaron políticas para el funcionamiento correcto del pool):
Ejemplo de configuración de pool para las direcciones Source de DHCP Relay (el rango de direcciones para la asignación coincide completamente con la exclusión del pool de direcciones):
Configuración del servicio DHCP en Microsoft Windows Server 2019
Configuración del grupo para direcciones Loopback (source) para DHCP Relay.
Creamos un nuevo grupo (Scope) en el espacio IPv4.
Asistente de creación de grupo. «Siguiente >»
Configuramos el nombre del grupo y la descripción (Description) del grupo.
Establecemos el rango de direcciones IP para Loopback y la máscara para el grupo.
Añadimos excepciones. El rango de excepciones debe coincidir completamente con el rango del grupo.
Tiempo de arrendamiento. «Siguiente >»
Consulta: ¿Vas a configurar las opciones DHCP ahora (DNS, WINS, Gateway, Domain) o lo harás más tarde? Es más rápido responder que no y activar el grupo manualmente después. O avanzar hasta el final sin completar ninguna información y al final del asistente activar el grupo.
Confirmamos que las opciones no están configuradas, el grupo no está activado. «Finalizar»
Activamos el grupo manualmente. — Seleccionamos Scope y en el menú contextual — elegimos «Activar».
Creamos un grupo para usuarios/servidores.
Creamos un nuevo grupo.
Asistente de creación de grupo. «Siguiente >»
Configuramos el nombre del grupo y la descripción (Description) del grupo.
Establecemos el rango de direcciones IP para Loopback y la máscara para el grupo.
Añadimos excepciones. (Por defecto no se requieren excepciones) «Siguiente >»
Tiempo de arrendamiento. «Siguiente >»
Consulta: ¿Vas a configurar las opciones DHCP ahora (DNS, WINS, Gateway, Domain) o lo harás más tarde? Sí, lo configuraremos ahora.
Configuramos la dirección de la puerta de enlace predeterminada.
Configuramos el dominio y las direcciones de los servidores DNS.
Configuramos las direcciones IP de los servidores WINS.
Activación del Scope.
Grupo configurado. «Finalizar»
Conclusión
El uso de Windows Server 2016/2019 reduce la complejidad de la configuración del servidor DHCP para la fábrica VXLAN (o cualquier otra fábrica). (No se requiere la transmisión de paquetes especiales a los especialistas en IT: Network/Agent Circuit ID para escribir filtros.)
¿Funciona la configuración para Windows Server 2012 en los nuevos servidores 2016/2019? – sí, funcionará.
Este documento incluye enlaces a 2 versiones: 7.X y 9.3. Esto se debe a que la versión 7.0(3)I7(7) es la propuesta por Cisco, y la versión 9.3 es la más innovadora (incluida la compatibilidad con Multicast a través de VXLAN Multisite).
Lista de fuentes
Fuente: habr.com
