أستكشاف أخطاء عنوان APIPA وإصلاحها في الشبكة

• تأثرت أجهزة المستخدم التي تتلقى عنوان 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 للمستخدم النهائي.

وصف المشكلة:

• تأثرت أجهزة المستخدم التي تتلقى عنوان 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.

وصف المشكلة:

• تأثرت أجهزة المستخدم التي تتلقى عنوان 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.

وصف المشكلة:

• تأثرت أجهزة المستخدم التي تتلقى عنوان 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) عبر مسار تدفق الحزمة.

وصف المشكلة:

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

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

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

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

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

تمكين التعقب

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

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

1. سيتم إسقاط استجابات ARP للمستكشفات بواسطة المحول.
2. تم تكوين المحول باستخدام واقي IPDT.
3. IPDT - حماية إسقاط تحقيق ARP والجهاز الطرفي الحصول على APIPA.