Fehlerbehebung für DHCP-Relay in der ACI mit lokalen Endgeräten

Einleitung

In diesem Dokument wird die Fehlerbehebung für DHCP Relay in ACI-Fabrics beschrieben.

Abkürzungen

• BD: Bridge-Domäne
• EPG: Endpunktgruppe
• ExEPG: Externe Endpunktgruppe
• VRF: Virtual Routing and Forwarding
• Klassen-ID oder pcTag: Tag, das eine EPG identifiziert
• DHCP: Dynamic Host Configuration Protocol (DHCP)
• SVI: Switched Virtual Interface

Anforderungen

Für diesen Artikel wird empfohlen, dass Sie allgemeine Kenntnisse über diese Themen haben:

• DHCP-Konzepte und Workflow (DORA-Prozess)
• ACI-Konzepte: Zugriffsrichtlinien, Endgeräte-Schulungen, Verträge und L3out
• DHCP-Relay-Richtlinien müssen bereits erstellt werden

Verwendete Komponenten

Diese Fehlerbehebung wurde in ACI-Version 6.0(8f) mit Nexus Switches der zweiten Generation N9K-C93180YC-EX und N9K-C93240YC-FX2 durchgeführt.

Alle Befehle in diesem Artikel wurden in einer Laborumgebung ausgeführt und verwendeten RFC1819 für die IP-Adressierung. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen aller Befehle kennen und sicherstellen, dass Sie den betreffenden Befehl Ihren spezifischen Anforderungen entsprechend ausführen.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Empfehlungen zur Fehlerbehebung

Endgeräteerlernen

Wenn keine Endgeräte erkannt werden, überprüfen Sie statische Port-Richtlinien wie Switch-, Schnittstellen- und VLAN-Konfigurationen. Überprüfen Sie für virtuelle Server, ob die Port-Gruppe ordnungsgemäß bereitgestellt und dem virtuellen System zugewiesen ist.

Richtlinienbereitstellung

Stellen Sie sicher, dass die DHCP Relay Policy (dhcpRelayP) und das DHCP Relay Label (dhcpLbl) ordnungsgemäß konfiguriert und von der entsprechenden Bridge-Domäne (BD) verwendet werden. Für Kennzeichnungsrichtlinien gelten folgende Eigentumsregeln:

• Besitzer des Benutzer-Tenant: Nur dieser Tenant kann die Richtlinie verwenden.
• Gemeinsamer Tenant-Besitz: Alle Tenants können die Richtlinie verwenden, aber der DHCP-Server muss über eine gemeinsame EPG abgefragt werden.
• Infra.-Tenant-Zuständigkeit: Alle Tenants können die Richtlinie verwenden, und der DHCP-Server kann an einer beliebigen Stelle in der Fabric abgerufen werden.

Wenn die untergeordnete dhcpRtLblDefToRelayP-Klasse in der übergeordneten dhcpRelayP-Richtlinie fehlt, verwendet kein BD die Relay Policy, und es sind Korrekturmaßnahmen erforderlich.

Host-Erreichbarkeit

Der DHCP-Client muss über die SVI seines BD erreichbar sein. Wenn sie nicht erreichbar ist, überprüfen Sie die Verträge und Routing-Konfigurationen, um die Verbindung sicherzustellen.

Endgeräte-Schulungen und -Routing

Stellen Sie sicher, dass der DHCP-Server über die SVI der Bridge-Domäne erreichbar ist, in der sich der Client befindet. 

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

Sowohl DHCP-Clients als auch DHCP-Server müssen als Endpunkte erfasst werden, wenn sie unter einer EPG konfiguriert sind. Um sicherzustellen, dass diese Endpunkte korrekt erfasst werden, können Sie die Tabelle des Endpunkt-Managers auf dem Blatt überprüfen. 

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|

::::

Richtlinienvalidierung

Bei der Validierung einer DHCP-Relay-Richtlinie können die folgenden Schlüsselattribute bestätigt werden:

• Name: Der Bezeichner der DHCP-Relay-Richtlinie.
• Besitzer: Der Tenant, unter dem die Richtlinie konfiguriert wird. Er gibt an, dass der Sichtbarkeitsbereich auf diesen Tenant beschränkt ist.
• Adresse: Die IP-Adresse des DHCP-Servers, an den DHCP-Anfragen weitergeleitet werden.
• Speicherort des DHCP-Servers: Validiert durch Tags wie epgDn, bdDefDn und ctxDefDn, um die korrekte Zuordnung zur EPG, Bridge-Domäne und VRF sicherzustellen.
• Stand der Richtlinie: Die Richtlinie muss einen formatierten Zustand aufweisen, um anzugeben, dass sie korrekt bereitgestellt und im Fabric aktiv ist.

Diese Validierung erfolgt durch Ausführen von moquery auf dem APIC, um zu bestätigen, dass die DHCP-Relay-Richtlinien korrekt erstellt, den entsprechenden Tenants zugeordnet und ordnungsgemäß mit den relevanten Bridge-Domänen verknüpft sind. Dieser Schritt hilft dabei, Fehlkonfigurationen frühzeitig zu erkennen und verhindert DHCP-Relay-Fehler, die durch fehlende oder falsche Richtlinienbereitstellung verursacht werden.

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

Sobald eine DHCP-Relay-Richtlinie mit der Bridge-Domäne (BD) des Clients verknüpft ist, wird automatisch eine entsprechende DHCP-Label-Richtlinie erstellt. Diese DHCP-Label-Richtlinie fungiert als Verbindung zwischen der DHCP-Relay-Richtlinie und dem BD und aktiviert die Relay-Funktion.

Sie können die DHCP Label-Richtlinie mithilfe der APIC-CLI mit einem Befehl wie dem folgenden überprüfen:

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:

Hier sehen Sie das mit dem BD verknüpfte DHCP-Label-Objekt.

Wenn die DHCP-Relay-Richtlinie korrekt konfiguriert ist, verfügt sie über ein untergeordnetes Objekt, in dem das DHCP-Label verwendet wird. Dieses kann wie folgt überprüft werden:

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

DHCP-Paketverfolgung

Die ACI protokolliert alle an die CPU gesendeten DHCP-Pakete in Trace-Dateien, die zur Fehlerbehebung beim DHCP Discover, Offer, Request, and Acknowledge (DORA)-Prozess analysiert werden können. Verwenden Sie diesen Befehl, um DHCP-Paket-Traces anzuzeigen:

show dhcp internal event-history traces

Tipp: Ein einzelnes DHCP-Paket generiert mehr als 100 Ablaufverfolgungseinträge. Es wird dringend empfohlen, grep mit regulären Ausdrücken zu verwenden, um relevante Ergebnisse für eine effiziente Analyse zu filtern.

Während der DHCP-Trace-Analyse in der Cisco ACI können verschiedene wichtige Attribute bestätigt werden, um den ordnungsgemäßen DHCP-Relay-Betrieb sicherzustellen:

• Unteroption "Schaltkreis-ID hinzufügen":

Zeigt an, dass die DHCP-Option 82 dem Paket hinzugefügt wird, was für die Relay-Agent-Informationen erforderlich ist.

• gi-Adresse:

Stellt die IP-Adresse des DHCP-Servers dar, die in der DHCP Relay Policy (DHCP-Relay-Richtlinie) konfiguriert wurde.

• Adresse des Helfers:

Die vom Relay zum Erreichen des DHCP-Servers verwendete SVI-IP-Adresse.

• Client und Server befinden sich in derselben VRF-Instanz:

Bestätigt, dass der DHCP-Client und der DHCP-Server zum gleichen VRF-Kontext gehören.

• Meldung:

Der Typ der erkannten DHCP-Nachricht, z. B. "Erkennen", "Angebot", "Anfrage" oder "Bestätigen".

• ctx-Name:

Der VRF-Name, unter dem die DHCP-Label-Richtlinie konfiguriert wird.

• SMAC:

Die MAC-Adresse des DHCP-Clients

• UDP-src/dst-Port:

Verwendete DHCP-Ports, in der Regel 68 für Clients und 67 für Server.

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

Häufige Probleme

Ausgabe 1: Unbeaufsichtigter L3out-Absturz

• Problem

Wenn ein L3Out eine vPC-Schnittstelle verwendet, um eine Nachbarbeziehung zu einem benachbarten Router aufzubauen, sendet jeder Switch Pakete über seine eigene vTEP. Wenn der vPC-Peer ein DHCP-Angebot mit einer anderen vTEP-Adresse empfängt, leitet er das Paket über die Fabric weiter, sodass der vTEP-Ausgangspunkt das Angebot ohne Fehlerprotokolle verwirft.

Verwenden Sie den folgenden Befehl, um nach solchen Auslassungen zu suchen:

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.

• Lösung

Navigieren Sie zu Tenants > [ Tenant-Name ] > Networking > L3outs > [ L3out-Name ] > Logical Node Profile > [ LNP-Name ] > Logical Interface Profile [ LIP-Name ] > SVI > [ SVI-Richtlinie]

Erstellen oder öffnen Sie dort die sekundäre IP-Adresse, und aktivieren Sie das Kontrollkästchen Enable for DHCP Relay (Für DHCP-Relay aktivieren).

Dadurch wird erzwungen, dass die Nachrichten mit der vPC-vTEP-Adresse anstatt der lokalen vTEP gesendet werden, und die Pakete werden wie erwartet weitergeleitet.

Ausgabe 2: DHCP-Server unterstützt Option 82 nicht.

Option 82 ist in VXLAN-Umgebungen wie der ACI von kritischer Bedeutung, da sie eine Schaltung zwischen Quell-Leaf und Ziel auf der Basis von vTEP-Adressen ermöglicht. Sie umfasst:

• Schaltungs-ID: Eingehende Schnittstelle, VLAN und EPG-VNID, bei der die DHCP-Erkennung erkannt wird.
• Remote-ID: TEP-Adresse des Switches, der die Erkennung erhalten hat.

Wenn Option 82 fehlt, werden DHCP-Relay-Pakete verworfen. Überprüfen Sie das Vorhandensein von Option 82 auf dem mit dem DHCP-Server verbundenen Leaf, indem Sie die DHCP-Trace-Protokolle auf Fehler überprüfen, die auf das Fehlen von Option 82 hinweisen.

Mit diesem Befehl wird überprüft, ob der Leaf-Switch, an den der DHCP-Server angeschlossen ist, die Angebote mit einer gültigen DHCP-Option 82 empfängt.

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

Referenzen

Detaillierte Fehlerbehebung per DHCP-Relay in der ACI-Fabric - TACDCN-2017