يوضح هذا المستند كيفية تكوين ميزة الاسترداد التلقائي ل PortChannel الظاهرية (vPC) على Nexus 7000.
لا توجد متطلبات خاصة لهذا المستند.
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.
لماذا نحتاج إلى برنامج vPC Auo-Recovery؟
هناك سببان رئيسيان لتعزيز vPC هذا:
في الإصدار 5.2(1) والإصدارات الأحدث، تدمج ميزة الاسترداد التلقائي ل vPC هاتين التحسينات.
وتتسم تهيئة ميزة الاسترداد التلقائي لأجهزة الكمبيوتر الافتراضية (vPC) بالوضوح التام. تحتاج إلى تكوين الاسترداد التلقائي ضمن مجال vPC على كل من نظاري vPC.
هذا مثال على التكوين:
على المحول S1
S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 5
Peer Gateway : Enabled
Peer gateway excluded VLANs : -
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1-112,114-120,800,810
vPC status
-----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
10 Po40 up success success 1-112,114-1
20,800,810
على المحول S2
S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 5
Peer Gateway : Enabled
Peer gateway excluded VLANs : -
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1-112,114-120,800,810
vPC status ----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
40 Po40 up success success 1-112,114-1
20,800,810
كيف يعمل الاسترداد التلقائي حقا؟
يناقش هذا القسم كل سلوك مذكور في قسم المعلومات الأساسية على حدة. يفترض أن يتم تكوين الاسترداد التلقائي ل vPC وحفظه إلى تكوين بدء التشغيل على كلا المحولين S1 و S2.
على سبيل المثال:
تم إيقاف تشغيل S1. يصبح S2 هو الأساسي التشغيلي كما هو متوقع. تم قطع اتصال Peer-link and peer-keepalive وجميع إرتباطات vPC من S1. لم يتم تشغيل S1. بما أن S1 معزول تماما، فإنه يشغل vPC (على الرغم من أن الروابط المادية معطلة) بسبب الاسترداد التلقائي ويلعب دور الأساسي. الآن، إذا كان رابط النظير أو رسائل تنشيط النظير متصلة بين S1 و S2، تحافظ S1 على دور الأساسي وتصبح S2 ثانوية. يتسبب هذا التكوين في إيقاف S2 مؤقتا عن عمل vPC الخاص به حتى يتم تشغيل كل من vpc peer-link و peer-keepalive واستكمال التحقق من التناسق. يتسبب هذا السيناريو في حدوث حركة مرور بيانات إلى الثقب الأسود نظرا لأن جهاز الكمبيوتر S2 vPC ثانوي وأن الارتباطات المادية S1 متوقفة.
هل يجب تمكين الاسترداد التلقائي ل vPC؟
من الممارسات الجيدة تمكين الاسترداد التلقائي في بيئة vPC لديك.
هناك احتمال ضئيل أن تؤدي ميزة الاسترداد التلقائي ل vPC إلى إنشاء سيناريو مزدوج النشاط. على سبيل المثال، إذا فقدت إرتباط النظير أولا ثم فقدت إرتباط النظير، فسيكون لديك سيناريو مزدوج النشاط.
في هذه الحالة، يواصل كل عضو ميناء vPC الإعلان عن نفسه خطوة تراكم تحكم بروتوكول أن هو عمل قبل dual-active إخفاق.
تحمي مخطط vPC بشكل أساسي من حلقات التكرار في حالة وجود سيناريوهات مزدوجة النشاط. في أسوأ الحالات، هناك إطارات مكررة. وعلى الرغم من ذلك، كآلية لمنع التكرار الحلقي، يقوم كل محول بإعادة توجيه وحدات بيانات بروتوكول الجسر (BPDUs) باستخدام معرف جسر وحدة بيانات بروتوكول الجسر (BPDU) نفسه كما كان الحال قبل فشل النشاط المزدوج ل vPC.
وعلى الرغم من أنه غير بديهي، فما يزال من الممكن ومن المرغوب فيه الاستمرار في إعادة توجيه حركة المرور من طبقة الوصول إلى طبقة التجميع دون حالات السقوط لتدفقات حركة المرور الحالية، شريطة أن تكون جداول بروتوكول تحليل العنوان (ARP) مشغولة بالفعل على كل من نظائر Cisco Nexus 7000 Series لجميع الأجهزة المضيفة المطلوبة.
إذا كان يلزم تعلم عناوين MAC الجديدة بواسطة جدول ARP، فقد تنشأ مشاكل. تنشأ المشاكل لأنه قد تتم تجزئة إستجابة ARP من الخادم إلى جهاز واحد من أجهزة Cisco Nexus 7000 Series وليس إلى الآخر، مما يجعل من المستحيل تدفق حركة المرور بشكل صحيح.
ومع ذلك، لنفترض أنه قبل الفشل في الحالة الموضحة للتو، تم توزيع حركة المرور على كل من أجهزة Cisco Nexus 7000 Series بشكل متساو بواسطة قناة PortChannel صحيحة ومن خلال تكوين متعدد المسارات (ECMP) ذي تكلفة متساوية. في هذه الحالة، تستمر حركة مرور البيانات من خادم إلى خادم ومن عميل إلى خادم مع التحذير من أن الأجهزة المضيفة الأحادية المرفق المتصلة مباشرة بسلسلة Cisco Nexus 7000 لن تكون قادرة على الاتصال (بسبب نقص إرتباط النظير). أيضا، لا يمكن تعلم عناوين MAC الجديدة التي تم التعرف عليها على واحد من سلسلة Cisco Nexus 7000 على النظير، لأن هذا قد يتسبب في تدفق حركة مرور البيانات العائدة التي تصل إلى جهاز سلسلة Cisco Nexus 7000 النظير.
راجع الصفحة 19 من قناة PortChannel الظاهرية لبرنامج Cisco NX-OS: المفاهيم الأساسية للحصول على مزيد من المعلومات.
لا يوجد حاليًا إجراء للتحقق من صحة هذا التكوين.
لا تتوفر حاليًا معلومات محددة لاستكشاف الأخطاء وإصلاحها لهذا التكوين.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
20-Jun-2013 |
الإصدار الأولي |