المحتويات

المقدمة

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

الأسباب

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

السيناريو 1 - تكوين وكيل جدار الحماية

وصف المشكلة:

أعراض المشكلة

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

إنعزالا

خطة العمل

القرار/التحقق

السيناريو 2 -نطاق خادم DHCP

وصف المشكلة:

الأعراض

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

إنعزالا

خطة العمل

القرار/التحقق

تكوين SDA للسيناريو 3 -C9300

وصف المشكلة:

أعراض المستخدم

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

إنعزالا

خطة العمل

القرار/التحقق

السيناريو 4 - مشكلة في مهايئ شبكة LAN

وصف المشكلة:

الأعراض

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

إنعزالا

خطة العمل

القرار/التحقق

السيناريو 5 -MTU غير متطابق

وصف المشكلة:

أعراض المستخدم

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

إنعزالا

خطة العمل

القرار/التحقق

السيناريو 6 - حماية IPDT

وصف المشكلة:

أعراض المستخدم

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

إنعزالا

خطة العمل

القرار/التحقق

المقدمة

تصف هذه الوثيقة المسائل المتعلقة بعناوين APIPA وتوفر الحلول لها.

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

- المحولات Catalyst 9000 switches.

- جدران حماية ASA مثل 5516

- خادم DHCP من أي نوع

- مادة حفازة 9300 في إعداد SDA

- البرامج: غير متوفر

الأسباب

يعين المستخدمون النهائيون APIPA أثناء هذه السيناريوهات،

- خادم DHCP غير متوفر.

- يتم إسقاط عرض DHCP قبل الخطوة الحالية أو قبلها.

- يحصل ARP Probe على إستجابة تمثل IP مكرر.

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

السيناريو 1 - تكوين وكيل جدار الحماية

وصف المشكلة:

- تأثرت أجهزة المستخدم التي تتلقى عنوان IP APIPA واتصال المستخدم.

أعراض المشكلة

1. يواجه المستخدمون على شبكة VLAN معينة مشاكل متقطعة حيث يتلقون عنوان IP APIPA ويفقدون الاتصال بالشبكة.

2. تحتوي جدران الحماية على إدخالات ARP متعددة لعنوان MAC للمستخدم النهائي الواحد مثل هذا:

Firewall/pri/act# show arp | include abcd.abcd.abcd

inside 10.1.1.12 abcd.abcd.abcd 30

inside 10.1.1.13 abcd.abcd.abcd 40

inside 10.1.1.14 abcd.abcd.abcd 51

inside 10.1.1.15 abcd.abcd.abcd 53

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

1. يشير تصحيح الأخطاء على جدار الحماية إلى جدار الحماية الذي يرسل الاستجابة إلى المستخدمين النهائيين ARP Probe.

DHCPD/RA: creating ARP entry (10.1.1.12, abcd.abcd.abcd).

DHCPRA: Adding rule to allow client to respond using offered address 10.1.1.12

يؤدي هذا إلى جعل الجهاز الطرفي يفكر في أنه عنوان مكرر.

2. التقاط على الجهاز الطرفي أو جدار الحماية

تظهر عمليات الالتقاط الجهاز الطرفي الذي يرسل حزم رفض DHCP بمجرد اكتمال عملية DORA.

إنعزالا

- تستجيب واجهة جدار الحماية الداخلية إلى تحقيق ARP عن طريق العمل كوكيل، بمجرد اكتمال عملية DORA. هذا يجعل ال pc أن يرسل DHCP رفض.

خطة العمل

- قم بتعطيل ARP للوكيل على جدار الحماية داخل الواجهة باستخدام الأمر "sysopt noproxyYarp inside"

القرار/التحقق

- تتلقى الأجهزة الطرفية عنوان IP بعد تعطيل بروتوكول تحليل العناوين للوكيل.

- ملاحظة: تأكد من عدم عمل أي جهاز كوكيل أو إرسال إستجابة لمستكشفات ARP للمستخدم النهائي.

.

السيناريو 2 - نطاق خادم DHCP

وصف المشكلة:

- تأثرت أجهزة المستخدم التي تتلقى عنوان IP APIPA واتصال المستخدم.

الأعراض

1. يتلقى المستخدمون على شبكة VLAN معينة عنوان IP APIPA فقط ويفقدون الاتصال بالشبكة.

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

- تم إرسال رفض DHCP إلى المستخدمين النهائيين وتم تكوينه باستخدام عنوان APIPA

إنعزالا

- يعين خادم DHCP عنوان IP واحدا من النطاق A ونفس عنوان IP الذي يتم تعيينه لكمبيوتر محمول آخر لأن النطاق B له نفس النطاق. هذا يسبب انخفاض DHCP:

خطة العمل

- تعيين نطاق نطاق نطاق DHCP الفريد

القرار/التحقق

- تتلقى الأجهزة الطرفية عنوان IP بعد تغيير النطاق.

- ملاحظة: تأكد من أن خادم DHCP لا يحتوي على نطاقات مكررة تم تكوينها.

تكوين SDA للسيناريو 3 -C9300

وصف المشكلة:

- تأثرت أجهزة المستخدم التي تتلقى عنوان IP APIPA واتصال المستخدم.

أعراض المستخدم

1. لا يستطيع بعض المستخدمين في شبكة VLAN معينة الحصول على عناوين DHCP من خلال نقطة الوصول اللاسلكية.

2. يحتوي جدار الحماية على إدخالات ARP متعددة لعنوان MAC لمستخدم نهائي واحد

Firewall# show arp | i abcd

Inside 10.1.1.22 abcd.abcd.abcd 48

Inside 10.1.1.23 abcd.abcd.abcd 49

Inside 10.1.1.24 abcd.abcd.abcd 50

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

- تم إسقاط عرض DHCP بواسطة المحول

- يقوم FTD بملء ARP استنادا إلى عرض DHCP الصادر من خادم DHCP.

***DROP*** Broadcast to Access-Tunnel disallowed (accessTunnelBroadcastDrop)

إنعزالا

- إن شكلت L2-only VLAN يكون ل SDA لاسلكي setup، عرض ربط مع بث علم لا يبلغ AP. بما أن Access-tunnel لا يسمح ببث الحزم بشكل افتراضي.

خطة العمل

- السماح ب "إمكانية الفيضان" داخل بيئة LISP.

router lisp

instance-id 8456

flood access-tunnel

القرار/التحقق

- بعد تكوين "نفق الوصول إلى الفيضان" في C9300 المتصل على الواجهة الداخلية، يستلم العملاء عناوين DHCP.

ملاحظة: تأكد من تمكين نفق الوصول إلى الفيضان تحت الرمز، في حالة تكوين الجهاز الطرفي لتلقي عرض البث.

السيناريو 4 - مشكلة في مهايئ شبكة LAN

وصف المشكلة:

- تأثرت أجهزة المستخدم التي تتلقى عنوان IP APIPA واتصال المستخدم.

الأعراض

1. يظهر جدول عناوين MAC الإدخالات ذات "drop".

#show mac address-table interface gigabitethernet1/0/20

Mac Address Table

-------------------------------------------

Vlan    Mac Address       Type        Ports

----    -----------       --------    -----

10    0000.0001.000a    DYNAMIC     Drop

2. يظهر عرض جلسة المصادقة العديد من الإدخالات، ربما أكثر من 2000 أو حتى 10000.

switch2#show authentication sessions

Gi1/0/1  0000.0001.1234 N/A   UNKNOWN Unauth  0AFF0B8D000000EC000000AF

Gi1/0/1  0000.0001.2345 N/A   UNKNOWN Unauth  0AFF0B8D000000F00016B7D7

Gi1/0/1  0000.0001.3456 N/A   UNKNOWN Unauth  0AFF0B8D0028DE3500000000

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

- يظهر التقاط الحزمة العديد من الحزم الواردة من الجهاز الطرفي باستخدام عناوين MAC مختلفة للمصدر.

- حد جلسة المصادقة هو 2000 وبمجرد تجاوز الحد تنشأ مشاكل غير متوقعة في الشبكة

- https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-12/configuration_guide/sec/b_1612_sec_3650_cg/configuring_ieee_802_1x_port_based_authentication.html

إنعزالا

- هذا مؤشر على وجود مشكلة في مهايئ المستخدم النهائي.يرسل هذا حزم مكونة بشكل غير صحيح يفهمها المحول على أنها عناوين MAC للمصدر العشوائي.

خطة العمل

- قم بتكوين "مصادقة وضع المضيف متعدد المجالات" الذي يسمح بعناوين MAC إثنين فقط.

- التعرف على جهاز المسؤول وعزله.

القرار/التحقق

- بعد تكوين هذا الحل لا توجد مشكلة يمكن ملاحظتها.

- ملاحظة: تأكد من تمكين إما أمان المنفذ أو Dot1x auth session host-mode multi-domain.

السيناريو 5 - عدم تطابق MTU

يمثل ISE هذا الخطأ على الخادم.

وصف المشكلة:

- تأثرت أجهزة المستخدم التي تتلقى عنوان IP APIPA واتصال المستخدم.

أعراض المستخدم

1. يرسل العميل الطرفي إستجابة EAP مع طول الحزمة أعلى من (مثال: 3736) طول الحزمة الفعلي المتوقع 1492.

Extensible Authentication Protocol

Code: Response (2)

Id: 4

Length: 1492

Type: TLS EAP (EAP-TLS) (13)

• EAP-TLS Flags: 0xc0

..0. .... = Start: False

EAP-TLS Length: 3736

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

- تم تعيين وحدة الحد الأقصى للنقل (MTU) على حجم أقل على المحول كإدخال على مستوى النظام. (على سبيل المثال: 1998 بايت)

- تم تكوين واجهة الخروج بحجم أكبر. (على سبيل المثال: 9198 بايت)

إنعزالا

- عدم التطابق في MTU عبر المسار يسبب المشكلة.

خطة العمل

- قم بتغيير وحدة الحد الأقصى للنقل (MTU) للنظام إلى 1500 وأعد تحميل المحول

القرار/التحقق

- بعد تكوين هذه الإعدادات، تصبح المصادقة ناجحة.

- ملاحظة: تأكد من تمكين نفس وحدة الحد الأقصى للنقل (MTU) عبر مسار تدفق الحزمة.

السيناريو 6 - حماية IPDT

وصف المشكلة:

- تأثرت أجهزة المستخدم التي تتلقى عنوان IP APIPA واتصال المستخدم.

أعراض المستخدم

- عند وجود الأجهزة الافتراضية في HA، إذا كان لديك هذا النهج مطبقا في الواجهة:

نهج تتبع الأجهزة IPDT_POLICY

لا يوجد بروتوكول UDP

تمكين التعقب

- بعد تجاوز الفشل، يتم إسقاط الرد على بروتوكول تحليل العناوين (ARP) من خلال محول الوصول.

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

1. سيتم إسقاط استجابات ARP للمستكشفات بواسطة المحول.

2. تم تكوين المحول باستخدام واقي IPDT.

3. IPDT - حماية إسقاط تحقيق ARP والجهاز الطرفي الحصول على APIPA.

إنعزالا

- حزم ARP التي تصل إلى IPDT ويتم إسقاطها بسبب ميزة "الواقي".

- تسقط سياسة IPDT التي يتم تكوينها باستخدام تكوين "حماية مستوى الأمان" حزم ARP مما يتسبب في عدم إمكانية الوصول إلى سوى القليل من الأجهزة الطرفية أو جميعها

خطة العمل

- قم بتغيير الإعداد من Guard إلى Glean.
تكوين نهج مستوى الأمان" في نهج IPDT

القرار/التحقق

- بعد تكوين إعدادات glean تتم معالجة مسابر ARP بواسطة عملية ARP ويتم حل المشكلة.

- ملاحظة: هذا عيب معروف جيدا وسيتم إصلاحه في الإصدار 17.15.1 والإصدارات اللاحقة.