أستكشاف أخطاء ترحيل DHCP وإصلاحها في قائمة التحكم في الوصول (ACI) باستخدام نقاط النهاية المحلية

المقدمة

يصف هذا المستند أستكشاف أخطاء ترحيل DHCP وإصلاحها في بنى قائمة التحكم في الوصول (ACI).

الاختصارات

• بي دي: مجال الجسر
• برونو: مجموعة نقاط النهاية
• ExEPG: مجموعة نقاط النهاية الخارجية
• تردد VRF: التوجيه وإعادة التوجيه الظاهري
• معرف الفئة أو PCtag: العلامة التي تعرف EPG
• DHCP: بروتوكول تكوين الاستضافة الديناميكية
• إس في: الواجهة الظاهرية المحولة

المتطلبات

بالنسبة لهذه المقالة، يوصى بأن تكون لديك معرفة عامة بالمواضيع التالية:

• مفاهيم DHCP وسير العمل (عملية DORA)
• مفاهيم ACI: سياسات الوصول، والتعلم من نقاط النهاية، والعقود، و L3out
• يجب إنشاء نهج ترحيل DHCP بالفعل

المكونات المستخدمة

تم إجراء عملية أستكشاف الأخطاء وإصلاحها هذه على الإصدار 6.0(8f) من ACI باستخدام محولات Nexus من الجيل الثاني طراز N9K-C93180YC-EX و N9K-C93240YC-FX2.

تم تشغيل جميع الأوامر على هذه المقالة على بيئة معملية واستخدام RFC1819 لعنونة IP. إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر وتأكد من ملاءمتك للأمر المعني مع إحتياجاتك الخاصة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

توصيات أستكشاف الأخطاء وإصلاحها

تعلم نقطة النهاية

إن لم يتم التعرف على نقاط النهاية، دققت ساكن إستاتيكي ميناء سياسة مثل مفتاح، قارن، و VLAN تشكيل. بالنسبة للخوادم الظاهرية، تأكد من نشر مجموعة المنافذ بشكل صحيح وتخصيصها للخادم الافتراضي.

نشر السياسة

تأكد من تكوين سياسة ترحيل DHCP (DHCPrelayP) وتسمية ترحيل DHCP (DHCPlbl) بشكل صحيح واستهلاكهما بواسطة مجال الجسر المناسب (BD). قواعد الملكية لنهج التسمية هي:

• ملكية المستأجر للمستخدم: يمكن فقط للمستأجر إستخدام النهج
• الملكية المشتركة للمستأجر: يمكن لجميع المستأجرين إستخدام السياسة، ولكن يجب التعرف على خادم DHCP على EPG مشترك
• ملكية المستأجر أدناه: يمكن لجميع المستأجرين إستخدام السياسة، ويمكن تعلم خادم DHCP في أي مكان في البنية

إذا كانت الفئة التابعة ل DHCPrtLblDefToRelayP مفقودة ضمن نهج الأصل ل DHCPrelayP، فلن يقوم BD باستهلاك نهج الترحيل، ويلزم إتخاذ إجراء تصحيحي.

إمكانية الوصول إلى المضيف

يجب أن يكون عميل DHCP قابلا للوصول إليه من SVI الخاص ب BD الخاص به. إذا تعذر الوصول إليه، فتحقق من العقود وتكوينات التوجيه لضمان الاتصال.

تعليم وتوجيه نقاط النهاية

ضمنت أن ال DHCP نادل يكون يمكن الوصول من ال SVI من الجسر مجال حيث الزبون يقيم. 

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

يجب التعرف على كل من عملاء DHCP وخوادم DHCP كنقاط نهاية عند تكوينها تحت بروتوكول EPG. للتحقق من أن نقاط النهاية هذه تم التعرف عليها بشكل صحيح، يمكنك التحقق من جدول إدارة نقاط النهاية على الورقة. 

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|

::::

التحقق من صحة النهج

عند التحقق من صحة سياسة ترحيل DHCP، يمكن تأكيد سمات المفاتيح التالية:

• الاسم: معرف نهج ترحيل DHCP.
• المالك: المستأجر الذي يتم تكوين السياسة ضمنه، مشيرا إلى نطاق الرؤية الخاص به والمقتصر على ذلك المستأجر.
• العنوان: عنوان IP الخاص بخادم DHCP الذي يتم إرسال طلبات DHCP إليه.
• موقع خادم DHCP: تم التحقق من صحته من خلال علامات مثل epgDn و bdDefDn و ctxDefDn لضمان الاقتران الصحيح مع EPG ومجال الجسر و VRF.
• حالة السياسة: يجب أن يكون النهج في حالة تكوين، مما يشير إلى نشره بشكل صحيح ونشطه في البنية.

يتم إجراء هذا التحقق من الصحة عن طريق تشغيل استعلامات على APIC لتأكيد إنشاء سياسات ترحيل DHCP بشكل صحيح، وإقرانها بالمستأجرين المناسبين، وربطها بشكل صحيح بمجالات الجسر ذات الصلة. تساعد هذه الخطوة في تحديد عمليات التكوين غير الصحيحة مبكرا، مما يمنع حالات فشل ترحيل DHCP الناتجة عن نشر النهج غير الصحيح أو المفقود.

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

بمجرد اقتران سياسة ترحيل DHCP بمجال الجسر (BD) الخاص بالعميل، يتم إنشاء سياسة تسمية DHCP المقابلة تلقائيا. يعمل نهج تسمية DHCP هذا كإرتباط بين سياسة ترحيل DHCP و BD، مما يتيح وظيفة الترحيل.

أنت يستطيع دققت ال DHCP تسمية سياسة يستعمل ال APIC CLI مع أمر مثل:

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:

يعرض هذا كائن تسمية DHCP المقترن ب BD.

إذا تم تكوين نهج ترحيل DHCP بشكل صحيح، فسيكون له كائن تابع حيث يتم إستهلاك تسمية DHCP، والذي يمكن التحقق منه باستخدام:

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

تسجل واجهة التحكم في الوصول (ACI) جميع حزم DHCP التي يتم إرسالها إلى وحدة المعالجة المركزية في ملفات التتبع، والتي يمكن تحليلها لاستكشاف أخطاء عملية اكتشاف DHCP والعرض والطلب والاعتراف بها (DORA) وإصلاحها. أستخدم هذا الأمر لعرض آثار حزمة DHCP:

show dhcp internal event-history traces

تلميح: تقوم حزمة DHCP واحدة بإنشاء أكثر من 100 إدخال تتبع. يوصى بشدة باستخدام GREP مع التعبيرات العادية لتصفية المخرجات ذات الصلة من أجل التحليل الفعال.

أثناء تحليل تتبع DHCP في Cisco ACI، يمكن تأكيد العديد من سمات المفاتيح لضمان عملية ترحيل DHCP المناسبة:

• إضافة الخيار الفرعي لمعرف الدائرة:

يشير إلى أنه تتم إضافة خيار DHCP رقم 82 إلى الحزمة، وهو ضروري لمعلومات وكيل الترحيل.

• عنوان GI:

يمثل عنوان IP لخادم DHCP الذي تم تكوينه في نهج ترحيل DHCP.

• عنوان المساعد:

ال SVI عنوان يستعمل ب الترحيل أن يبلغ ال DHCP نادل.

• العميل والخادم في نفس VRF:

تؤكد أن كل من عميل DHCP والخادم ينتميان إلى سياق VRF نفسه.

• msg:

نوع رسالة DHCP التي تمت ملاحظتها، مثل اكتشاف أو عرض أو طلب أو ACK.

• اسم CTX:

اسم VRF حيث يتم تكوين نهج تسمية DHCP.

• SMAC:

عنوان MAC لعميل DHCP.

• منفذ UDP src/dst:

ال DHCP ميناء يستعمل، بشكل خاص 68 لعميل و 67 لخوادم.

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

المشكلات الشائعة

المسألة 1: إسقاط L3Out الصامت

• المشكلة

عندما يستخدم L3Out واجهة vPC لتكوين علاقة مجاورة باستخدام موجه مجاور، يرسل كل محول الحزم باستخدام vTEP الخاص به. إذا كان نظير vPC يستلم عرض DHCP بعنوان vTEP غير خاص به، فإنه يعيد توجيه الحزمة عبر البنية، مما يتسبب في قيام المنشئ vTEP بإسقاطه بصمت دون سجلات الأخطاء.

للتحقق من وجود حالات إسقاط كهذه، أستخدم هذا الأمر:

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.

• الحل

انتقل إلى المستأجرين > [ اسم المستأجر ] > الشبكة > L3out > [ L3out name] > ملف تعريف العقدة المنطقي > [ اسم LNP ] > ملف تعريف الواجهة المنطقي [ اسم الشفة ] > SVI > [ سياسة SVI]

بمجرد الوصول، قم بإنشاء أو فتح عنوان IP الثانوي وenable لمربع تجزئة ترحيل DHCP.

وسيؤدي ذلك إلى فرض إرسال الرسائل باستخدام عنوان vPC vTEP بدلا من vTEP المحلي وستتم إعادة توجيه الحزم كما هو متوقع.

المسألة 2: لا يدعم خادم DHCP الخيار 82

يعتبر الخيار 82 مهما في بيئات VXLAN مثل ACI، إنشاء دائرة بين ورقة المصدر والوجهة بناءا على عناوين vTEP. ويتضمن هذا النهج ما يلي:

• معرف الدائرة: الواجهة الواردة و VLAN و EPG VNID حيث يتم رؤية اكتشاف DHCP.
• المعرف البعيد: عنوان TEP للمحول الذي استلم الاكتشاف.

إذا كان الخيار 82 مفقودا، يتم إسقاط حزم ترحيل DHCP. تحقق من صحة وجود الخيار 82 على الورقة المتصلة بخادم DHCP عن طريق التحقق من سجلات تتبع DHCP بحثا عن أخطاء تشير إلى الخيار 82 المفقود.

يتحقق هذا الأمر من صحة المحول الطرفي حيث يتم توصيل خادم DCHP واستلام العروض باستخدام خيار DHCP رقم 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

المراجع

أستكشاف الأخطاء وإصلاحها بشكل عميق في ترحيل DHCP في بنية واجهة التحكم في الوصول (ACI) - TACDCN-2017