المقدمة
يوضح هذا المستند كيفية أستكشاف أخطاء عاصفة ARP وإصلاحها، دون أي حركة مرور داخل ARP.
الخلفية
يعتبر هجوم ARP Storm بمثابة هجوم شائع على رفض الخدمة (DoS) كما تشاهدون في بيئة مركز البيانات.
منطق المحول الشائع لمعالجة حزمة ARP هو:
- حزمة ARP مع التحكم في الوصول إلى وسائط وجهة البث (MAC)
- حزمة ARP مع Unicast غاية MAC، أي ينتسب إلى المفتاح
ستتم معالجتها بواسطة عملية ARP في البرنامج إذا كانت الواجهة الظاهرية للمحول (SVI) قيد التشغيل في شبكة VLAN المستقبلة.
بهذا المنطق، إذا كان هناك مضيف ضار واحد أو أكثر يستمر في إرسال طلب ARP في شبكة VLAN، حيث يكون المحول عبارة عن شبكة VLAN هذه. ستتم معالجة طلب ARP في البرنامج، وبالتالي يتسبب في تجاوز المحول. في بعض نماذج محولات Cisco وإصدارها الأقدم، سترى أن عملية ARP تأخذ إستخدام وحدة المعالجة المركزية حتى مستوى عال والنظام مشغول جدا لمعالجة حركة مرور بيانات مستوى التحكم الأخرى.الطريقة الشائعة لتتبع هذا الهجوم هي تشغيل التقاط داخل النطاق لتحديد مصدر MAC لعاصفة ARP.
في مركز البيانات حيث يعمل Nexus 7000 كبوابة التجميع، يتم تقليل هذا التأثير بواسطة CoPP على محولات Nexus 7000 Series Switches. لا يزال بإمكانك تشغيل Inband Capture Ethanalyzer على دليل أستكشاف المشكلات وحلها من Nexus 7000 لتحديد مصدر MAC لعاصفة ARP نظرا لأن "تنظيم مستوى التحكم" (CoPP) هو مجرد قطاع طرق يعمل على إبطاء سرعة عاصفة ARP ولكنه لا يعمل على تفريغ سرعة توجيه عاصفة ARP إلى وحدة المعالجة المركزية.
ماذا عن هذا السيناريو حيث:
- SVI أسفل
- لا يتم تضمين حزمة ARP الزائدة في وحدة المعالجة المركزية
- لا توجد وحدة معالجة مركزية (CPU) عالية بسبب عملية ARP
ومع ذلك، لا يزال المحول يرى مشكلة ARP ذات الصلة، على سبيل المثال، لم يكتمل ARP في المضيف المتصل المباشر. وهل من المحتمل ان تكون عاصفة ARP هي السبب فيها؟
الإجابة هي نعم على Nexus 7000.
سبب جذري
في تصميم بطاقة الخط Nexus 7000، لدعم عملية حزمة ARP في CoPP، سيقوم طلب ARP بتشغيل واجهة منطقية خاصة (LIF) ثم يتم تحديد المعدل بواسطة CoPP في محرك إعادة التوجيه (FE). هذا يحدث بغض النظر عن وجود SVI لأعلى للشبكة المحلية الظاهرية (VLAN) أو لا.
وبالتالي، بينما يكون قرار إعادة التوجيه النهائي الذي اتخذته FE هو عدم إرسال طلب ARP لداخل وحدة المعالجة المركزية (في حالة عدم وجود SVI لأعلى للشبكة المحلية الظاهرية (VLAN))، فإن عداد CoPP لا يزال محدثا. يؤدي ذلك إلى تشبع CoPP مع طلب ARP المفرط وإسقاط طلب/رد ARP المشروع. في هذا السيناريو، لن ترى أي حزم ARP داخلية مفرطة ولكن لا تزال تتأثر بعاصفة ARP.
لدينا خطأ محسن CSCub47533 تم تسجيله لهذا السلوك في يوم CoPP الأول.
الحل
قد تكون هناك خيارات قليلة لتحديد مصدر عاصفة ARP في هذا السيناريو. وأحد الخيارات الفعالة هو:
- أولا تحديد الوحدة التي تأتي منها عاصفة ARP
N7K# sh policy-map interface control-plane class copp-system-p-class-normal
Control Plane
service-policy input copp-system-p-policy-strict
class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match exception ip multicast directly-connected-sources
match exception ipv6 multicast directly-connected-sources
match protocol arp
set cos 1
police cir 680 kbps bc 250 ms
conform action: transmit
violate action: drop
module 3:
conformed 4820928 bytes,
5-min offered rate 0 bytes/sec
peak rate 104 bytes/sec at Thu Aug 25 08:12:12 2016
violated 9730978848 bytes,
5-min violate rate 6983650 bytes/sec
peak rate 7632238 bytes/sec at Thu Aug 25 00:43:33 2016
module 4:
conformed 4379136 bytes,
5-min offered rate 0 bytes/sec
peak rate 38 bytes/sec at Wed Aug 24 07:12:09 2016
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
...
- ثانيا، أستخدم إجراء ELAM لالتقاط جميع حزم ARP التي تضرب الوحدة. قد تحتاج إلى القيام بذلك عدة مرات. ولكن إذا حدثت عاصفة، فإن فرصة التقاط حزمة ARP المخالفة أفضل بكثير من حزمة ARP للسحب. تعرف على مصدر MAC و VLAN من التقاط ELAM.
التعليقات