Solucionar problemas de retransmisión DHCP en ACI con terminales locales

Introducción

Este documento describe la solución de problemas de DHCP Relay en los Fabrics ACI.

Abreviaturas

• BD: Dominio de Bridge
• EPG: Grupo de terminales
• ExEPG: Grupo de terminales externos
• VRF: Routing y reenvío virtual
• Id. de clase o pcTag: Etiqueta que identifica un EPG
• DHCP: Protocolo de configuración de host dinámico
• SVI: Interfaz virtual conmutada

Requirements

Para este artículo, se recomienda que tenga un conocimiento general de estos temas:

• Conceptos y flujo de trabajo de DHCP (proceso DORA)
• Conceptos de ACI: Políticas de acceso, aprendizaje de terminales, contratos y L3out
• Las políticas de retransmisión DHCP ya deben estar creadas

Componentes Utilizados

Este ejercicio de resolución de problemas se realizó en la versión 6.0(8f) de ACI con los switches Nexus de segunda generación N9K-C93180YC-EX y N9K-C93240YC-FX2.

Todos los comandos de este artículo se ejecutaron en un entorno de laboratorio y se utilizó RFC1819 para el direccionamiento IP. Si su red está activa, asegúrese de comprender el impacto potencial de cualquier comando, asegurándose de que el comando en cuestión se ajusta a sus necesidades específicas.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Recomendaciones de Troubleshooting

Aprendizaje de terminales

Si no se aprenden los terminales, valide las políticas de puertos estáticos como las configuraciones de switch, interfaz y VLAN. Para los servidores virtuales, confirme que el grupo de puertos esté implementado y asignado correctamente a la VM.

Implementación de políticas

Asegúrese de que la directiva de retransmisión DHCP (dhcpRelayP) y la etiqueta de retransmisión DHCP (dhcpLbl) están correctamente configuradas y son consumidas por el dominio de puente (BD) adecuado. Las reglas de propiedad para las políticas de etiquetas son:

• Propiedad de arrendatario de usuario: Solo ese arrendatario puede usar la política
• Propiedad de arrendatario común: Todos los arrendatarios pueden utilizar la política, pero el servidor DHCP se debe aprender en un EPG común
• Propiedad de arrendatario infraroja: Todos los arrendatarios pueden utilizar la política y el servidor DHCP se puede aprender en cualquier lugar del fabric

Si falta la clase secundaria dhcpRtLblDefToRelayP en la directiva primaria dhcpRelayP, ningún BD consume la directiva de retransmisión y se requieren acciones correctivas.

Alcance del host

El cliente DHCP debe ser accesible desde el SVI de su BD. Si no está disponible, verifique los contratos y las configuraciones de ruteo para garantizar la conectividad.

Aprendizaje y routing de terminales

Asegúrese de que el servidor DHCP es accesible desde la SVI del dominio de puente donde reside el cliente. 

iping -V [ tenant : VRF ] -S [ SVI IP of the Client ] [ DHCP server IP]

Leaf101# iping -V tz:VRF1 -S 172.16.19.1 172.16.18.100
PING 172.16.18.100 (172.16.18.100) from 172.16.19.1: 56 data bytes
64 bytes from 172.16.18.100: icmp_seq=0 ttl=64 time=0.912 ms
64 bytes from 172.16.18.100: icmp_seq=1 ttl=64 time=0.706 ms
64 bytes from 172.16.18.100: icmp_seq=2 ttl=64 time=0.643 ms
64 bytes from 172.16.18.100: icmp_seq=3 ttl=64 time=0.689 ms
64 bytes from 172.16.18.100: icmp_seq=4 ttl=64 time=0.717 ms

--- 172.16.18.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.643/0.733/0.912 ms

Tanto los clientes DHCP como los servidores DHCP se deben aprender como extremos cuando se configuran bajo un EPG. Para validar que estos extremos se conocen correctamente, puede comprobar la tabla del administrador de extremos en la hoja. 

show system internal epm endpoint [ip | mac] [ DHCP server IP | DHCP client MAC]

Leaf101# show system internal epm endpoint ip 172.16.18.100

MAC : 0050.56b7.80cf ::: Num IPs : 1
IP# 0 : 172.16.18.100 ::: IP# 0 flags : ::: l3-sw-hit: No
Vlan id : 12 ::: Vlan vnid : 8535 ::: VRF name : tz:VRF1
BD vnid : 15400880 ::: VRF vnid : 2981888
Phy If : 0x1a02c000 ::: Tunnel If : 0
Interface : Ethernet1/45
Flags : 0x80004c04 ::: sclass : 16402 ::: Ref count : 5
EP Create Timestamp : 09/11/2025 17:37:15.158380
EP Update Timestamp : 09/11/2025 19:17:41.261985
EP Flags : local|IP|MAC|sclass|timer|

::::

•••

Leaf101# show system internal epm endpoint mac 0050.56b7.33ee

MAC : 0050.56b7.33ee ::: Num IPs : 0
Vlan id : 25 ::: Vlan vnid : 8494 ::: VRF name : tz:VRF1
BD vnid : 15630228 ::: VRF vnid : 2981888
Phy If : 0x1a02c000 ::: Tunnel If : 0
Interface : Ethernet1/45
Flags : 0x80004804 ::: sclass : 32780 ::: Ref count : 4
EP Create Timestamp : 09/11/2025 17:33:36.158122
EP Update Timestamp : 09/11/2025 19:17:41.258478
EP Flags : local|MAC|sclass|timer|

::::

Validación de políticas

Al validar una directiva de retransmisión DHCP, se pueden confirmar estos atributos clave:

• Nombre: Identificador de la directiva de retransmisión DHCP.
• OWNER : El arrendatario bajo el que se configura la política, indicando su alcance de visibilidad limitado a ese arrendatario.
• Dirección: Dirección IP del servidor DHCP al que se retransmiten las solicitudes DHCP.
• Ubicación del servidor DHCP: Se validan mediante etiquetas como epgDn, bdDefDn y ctxDefDn para garantizar una asociación correcta con el EPG, el dominio de puente y VRF.
• Estado de la política: La política debe estar en un estado formado, lo que indica que está implementada correctamente y activa en el fabric.

Esta validación se realiza mediante la ejecución de moqueries en el APIC para confirmar que las políticas de retransmisión DHCP se han creado correctamente, están asociadas con los arrendatarios adecuados y están enlazadas correctamente con los dominios de puente relevantes. Este paso ayuda a identificar las configuraciones erróneas de forma temprana, evitando los fallos de retransmisión DHCP causados por la implementación de políticas incorrecta o ausente.

moquery -c dhcpRelayP -f 'dhcp.RelayP.dn*"[ tenant name ].*[ DHCP Relay Policy name ]"' -x rsp-subtree=children

APIC# moquery -c dhcpRelayP -f 'dhcp.RelayP.dn*"tz.*Relay"' -x rsp-subtree=children
Total Objects shown: 1

# dhcp.RelayP
name : tz-DHCP_Relay
<-- cut for brevity-->
dn : uni/tn-tz/relayp-tz-DHCP_Relay
<-- cut for brevity-->
owner : tenant
<-- cut for brevity-->
rn : relayp-tz-DHCP_Relay

# dhcp.ProvDhcp
epgDn : uni/tn-tz/ap-AP1/epg-EPG1
addr : 172.16.18.100
bdDefDn : uni/bd-[uni/tn-tz/BD-BD1]-isSvc-no
<-- cut for brevity-->
ctxDefDn : uni/ctx-[uni/tn-tz/ctx-VRF1]
ctxDefStQual : none
ctxSeg : 2981888
descr : 
dn : uni/tn-tz/relayp-tz-DHCP_Relay/provdhcp-[uni/tn-tz/ap-AP1/epg-EPG1]
l3CtxEncap : vxlan-2981888
<-- cut for brevity-->
name : EPG1
<-- cut for brevity-->
pcTag : 16402
<-- cut for brevity-->

# dhcp.RsProv
tDn : uni/tn-tz/ap-AP1/epg-EPG1
addr : 172.16.18.1
<-- cut for brevity-->
state : formed

Una vez que se asocia una directiva de retransmisión DHCP con el dominio de puente (BD) del cliente, se crea automáticamente una directiva de etiqueta DHCP correspondiente. Esta directiva de etiquetas DHCP actúa como un vínculo entre la directiva de retransmisión DHCP y el BD, lo que habilita la funcionalidad de retransmisión.

Puede verificar la política de etiquetas DHCP mediante la CLI de APIC con un comando como:

moquery -c dhcpLbl -f 'dhcp.Lbl.dn*"[ tenant ].*[ DHCP Relay Policy name]"'

APIC# moquery -c dhcpLbl -f 'dhcp.Lbl.dn*"tz.*Relay"'
Total Objects shown: 1

# dhcp.Lbl
name : tz-DHCP_Relay
annotation : 
childAction : 
descr : 
dn : uni/tn-tz/BD-BD2/dhcplbl-tz-DHCP_Relay
extMngdBy : 
lcOwn : local
modTs : 2025-09-11T16:30:03.016+00:00
monPolDn : uni/tn-common/monepg-default
nameAlias : 
owner : tenant
ownerKey : 
ownerTag : 
rn : dhcplbl-tz-DHCP_Relay
status : modified
tag : yellow-green
uid : 15374
userdom : :all:

Muestra el objeto de etiqueta DHCP asociado al BD.

Si la política de retransmisión DHCP está configurada correctamente, tendrá un objeto secundario donde se consume la etiqueta DHCP, que se puede verificar con:

APIC# moquery -c dhcpRelayP -f 'dhcp.RelayP.dn*"tz.*Relay"' -x rsp-subtree=children rsp-subtree-class=dhcpRtLblDefToRelayP
Total Objects shown: 1

# dhcp.RelayP
name : tz-DHCP_Relay
annotation : 
childAction : 
descr : 
dn : uni/tn-tz/relayp-tz-DHCP_Relay
extMngdBy : 
lcOwn : local
modTs : 2025-09-11T16:10:56.421+00:00
mode : visible
monPolDn : uni/tn-common/monepg-default
nameAlias : 
owner : tenant
ownerKey : 
ownerTag : 
rn : relayp-tz-DHCP_Relay
status : modified
uid : 15374
userdom : :all:

# dhcp.RtLblDefToRelayP
tDn : uni/bd-[uni/tn-tz/BD-BD2]-isSvc-no/dhcplbldef-tz-DHCP_Relay
childAction : deleteNonPresent
dn : uni/tn-tz/relayp-tz-DHCP_Relay/rtlblDefToRelayP-[uni/bd-[uni/tn-tz/BD-BD2]-isSvc-no/dhcplbldef-tz-DHCP_Relay]
lcOwn : local
modTs : 2025-09-11T16:30:03.106+00:00
rn : rtlblDefToRelayP-[uni/bd-[uni/tn-tz/BD-BD2]-isSvc-no/dhcplbldef-tz-DHCP_Relay]
status : 
tCl : dhcpLblDef

Seguimiento de paquetes DHCP

ACI registra todos los paquetes DHCP enviados a la CPU en archivos de seguimiento, que se pueden analizar para solucionar los problemas del proceso DHCP Discover, Offer, Request, and Acknowledge (DORA). Utilice este comando para ver los seguimientos de paquetes DHCP:

show dhcp internal event-history traces

Consejo: Un solo paquete DHCP genera más de 100 entradas de seguimiento. Se recomienda utilizar grep con expresiones regulares para filtrar el resultado relevante para un análisis eficiente.

Durante el análisis de seguimiento de DHCP en Cisco ACI, se pueden confirmar varios atributos clave para garantizar un funcionamiento correcto de la retransmisión DHCP:

• Agregar subopción de ID de circuito:

Indica que la opción 82 de DHCP se está agregando al paquete, lo cual es esencial para la información del agente de retransmisión.

• dirección gi:

Representa la dirección IP del servidor DHCP configurada en la directiva de retransmisión DHCP.

• Dirección del ayudante:

La dirección IP SVI utilizada por el relay para alcanzar el servidor DHCP.

• El cliente y el servidor están en el mismo VRF:

Confirma que tanto el cliente DHCP como el servidor pertenecen al mismo contexto VRF.

• Mensaje:

El tipo de mensaje DHCP observado, como Discover, Offer, Request o Ack.

• nombre de ctx:

El nombre VRF donde se configura la política de etiquetas DHCP.

• Smac:

La dirección MAC del cliente DHCP.

• Puerto UDP src/dst:

Los puertos DHCP utilizados, normalmente 68 para clientes y 67 para servidores.

Leaf101# show dhcp internal event-history traces | grep -A34 -B70 "00 50 56 b7 33 ee" | egrep "(Rec.*pkt.*intf|ip add|UDP|packet vlan|IfIndex|interface:|[DS]mac|ctx.*is.*:|Pkt.*ID|relay_handle.*(ifindex|msg|from.*ctx)|relayback|relay_send.*(ifindex|Client.*Server)|Adding option82|Mac addr|dhcp_get_vlan|Add.*suboption.*epg_vnid|Helper|Outgoing|gi.*is|Cross-vrf|Sending.*Server|Relaying.*DHCP)" | head -29

2) 2025 Sep 11 04:14:46.660433 _relay_handle_packet_from_pkt_mgr: 480 : Relaying the DHCP pkt on intf: Vlan24
28) 2025 Sep 11 04:14:46.659985 _relay_add_circuitid_rmtid_msiteinfo: 3354 : Add circuit id suboption: if_index: Ethernet1/45 (1a02c000) , svlan: 24, option def id: 0 epg_vnid 8529.
••
31) 2025 Sep 11 04:14:46.659934 _relay_add_option82: 3151 : Mac addr is 28:6f:7f:eb:54:9f
32) 2025 Sep 11 04:14:46.659930 _relay_add_option82: 3147 : Adding option82 suboptions
35) 2025 Sep 11 04:14:46.659924 _relay_send_packet: 1975 : gi address is 172.16.18.1
••
37) 2025 Sep 11 04:14:46.659921 _relay_send_packet: 1965 : Helper address is 172.16.18.100
38) 2025 Sep 11 04:14:46.659918 _relay_send_packet: 1956 : Client and Server are in the same VRF
39) 2025 Sep 11 04:14:46.659793 _relay_send_packet: 1898 : ifindex is Vlan24
40) 2025 Sep 11 04:14:46.659786 _relay_send_packet: 1833 : dhcp_relay_send_packet: relayback_ifindex is Ethernet1/45
••
42) 2025 Sep 11 04:14:46.659730 _relay_handle_packet_from_pkt_mgr: 447 : DHCPDISCOVER msg
43) 2025 Sep 11 04:14:46.659728 _relay_handle_packet_from_pkt_mgr: 438 : ifindex is Vlan24
••
61) 2025 Sep 11 04:14:46.657274 _snoop_handle_istack_packet: 1763 : ctx name is tz:VRF1
64) 2025 Sep 11 04:14:46.657062 _snoop_handle_istack_packet: 1751 :  Smac = [00 50 56 b7 33 ee ]
65) 2025 Sep 11 04:14:46.657057 _snoop_handle_istack_packet: 1749 : Dmac = [ff ff ff ff ff ff ];
68) 2025 Sep 11 04:14:46.657050 _snoop_handle_istack_packet: 1737 : Logical interface: Vlan24
72) 2025 Sep 11 04:14:46.657044 _snoop_handle_istack_packet: 1721 : Physical interface: Ethernet1/45
••
86) 2025 Sep 11 04:14:46.657024 _snoop_handle_istack_packet: 1669 : UDP src port 68 UDP dst port 67
88) 2025 Sep 11 04:14:46.657021 _snoop_handle_istack_packet: 1577 : destination ip address 255.255.255.255
89) 2025 Sep 11 04:14:46.657018 _snoop_handle_istack_packet: 1574 : source ip address 0.0.0.0
95) 2025 Sep 11 04:14:46.656991 _snoop_handle_istack_packet: 1533 : Received pkt on Vlan 25  intf Ethernet1/45

Problemas comunes

Problema 1: L3out silent drop

• Problema

Cuando un L3Out utiliza una interfaz vPC para formar una relación de vecino con un router adyacente, cada switch envía paquetes usando su propio vTEP. Si el par vPC recibe una oferta de DHCP con una dirección vTEP que no es la suya, reenvía el paquete a través del fabric, lo que hace que el vTEP de origen lo descarte de forma silenciosa sin registros de errores.

Para comprobar si hay tales caídas, utilice este comando:

show dhcp internal event-history traces | egrep “(failed|Drop).*packet" | head

Leaf101# show dhcp internal event-history traces | egrep "(failed|Drop).*packet" | head

53) 2025 Sep 10 04:14:26.685020 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
172) 2025 Sep 10 04:14:23.792669 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
239) 2025 Sep 10 04:14:22.516679 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
444) 2025 Sep 10 04:14:17.055216 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
563) 2025 Sep 10 04:14:14.450437 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
736) 2025 Sep 10 04:14:09.056993 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
803) 2025 Sep 10 04:14:07.344467 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
906) 2025 Sep 10 04:14:06.290135 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
1025) 2025 Sep 10 04:14:03.770388 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.
1094) 2025 Sep 10 04:14:03.234017 _snoop_handle_istack_packet: 1881 : Drop DHCP DISCOVER/REQUEST packet because it is for a BD SVI, and recvd from fabric facing intf.

• Solución

Vaya a Arrendatarios > [ nombre de arrendatario ] > Redes > L3outs > [ nombre de L3out ] > Perfil de nodo lógico > [ nombre LNP ] > Perfil de interfaz lógica [ nombre LIP ] > SVI > [ política SVI]

Una vez allí, active la casilla de verificación create o open Secondary IP address y enable para DHCP Relay.

Esto obligará a enviar los mensajes mediante la dirección vTEP de vPC en lugar de vTEP local y los paquetes se reenviarán según lo previsto.

Problema 2: El servidor DHCP no admite la opción 82

La opción 82 es fundamental en entornos VXLAN como ACI, ya que crea un circuito entre la hoja de origen y el destino basado en direcciones vTEP. Incluye:

• ID del circuito: Interfaz entrante, VLAN y VNID de EPG donde se ve la detección de DHCP.
• ID remoto: Dirección TEP del switch que recibió la detección.

Si falta la opción 82, los paquetes de retransmisión DHCP se descartan. Valide la presencia de la opción 82 en la hoja conectada al servidor DHCP comprobando los registros de seguimiento de DHCP para ver si hay errores que indiquen que falta la opción 82.

Este comando valida el switch de hoja donde el servidor DHCP está conectado y recibe las ofertas con una opción DHCP válida 82

Leaf101# show dhcp internal event-history traces | egrep “(failed|Drop).*packet" | head

67) 2025 Sep 10 05:16:52.336785 _relay_handle_packet: 1478 : dhcp_relay_handle_packet: DHCP UDP failed to relay packet back to client - Unknown error -1
68) 2025 Sep 10 05:16:52.336772 _relayback_response: 929 : dhcp_relayback_response : option 82 not present. Drop the packet
479) 2025 Sep 10 05:11:07.308085 _relay_handle_packet: 1478 : dhcp_relay_handle_packet: DHCP UDP failed to relay packet back to client - Unknown error -1
480) 2025 Sep 10 05:11:07.308073 _relayback_response: 929 : dhcp_relayback_response : option 82 not present. Drop the packet
891) 2025 Sep 10 05:10:22.312386 _relay_handle_packet: 1478 : dhcp_relay_handle_packet: DHCP UDP failed to relay packet back to client - Unknown error -1
892) 2025 Sep 10 05:10:22.312374 _relayback_response: 929 : dhcp_relayback_response : option 82 not present. Drop the packet
1303) 2025 Sep 10 05:09:37.309888 _relay_handle_packet: 1478 : dhcp_relay_handle_packet: DHCP UDP failed to relay packet back to client - Unknown error -1
1304) 2025 Sep 10 05:09:37.309874 _relayback_response: 929 : dhcp_relayback_response : option 82 not present. Drop the packet
1715) 2025 Sep 10 05:08:52.295721 _relay_handle_packet: 1478 : dhcp_relay_handle_packet: DHCP UDP failed to relay packet back to client - Unknown error -1
1716) 2025 Sep 10 05:08:52.295709 _relayback_response: 929 : dhcp_relayback_response : option 82 not present. Drop the packet

Referencias

Resolución de problemas profundos de retransmisión DHCP en fabric ACI - TACDCN-2017