بروتوكول توجيه العبارة الداخلي المحسن (EIGRP) هو بروتوكول متجه المسافات المحسن القائم على خوارزمية التحديث المشتتة (DUAL). وهو قادر (بشكل متحفظ) على العثور على جميع المسارات الخالية من الحلقة إلى أي وجهة محددة استنادا إلى إعلانات المسار من الجيران. ويسمى الجار (أو الجيران) الذي لديه أفضل مسار إلى الوجهة باسم الخلف. أما بقية البلدان المجاورة التي لديها مسارات خالية من الحلقة إلى الوجهة فتسمى بلدان قابلة للتنفيذ. لتقليل حمل حركة المرور على الشبكة، يحافظ EIGRP على العلاقات المجاورة ويتبادل معلومات التوجيه فقط حسب الحاجة، باستخدام عملية استعلام للعثور على مسارات بديلة عندما تفشل جميع المسارات الخالية من التكرار إلى الوجهة.
لا توجد متطلبات خاصة لهذا المستند.
تستند المعلومات الواردة في هذا المستند إلى برنامج Cisco IOS® Software، الإصدار 12.0.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
يقال ان المسالك التي لها خلف صالح هي في حالة "سلبية". إذا فقد الموجه، لسبب ما، طريقا من خلال من يخلفه ولم يكن لديه من يحل محله عمليا في ذلك المسار، فيتحول المسار بعد ذلك إلى حالة "نشطة". في الحالة النشطة، يرسل الموجه استعلامات إلى جيرانه يطلب مسارا إلى المسار المفقود.
عندما يستلم جار EIGRP استعلاما لموجه، فإنه يتصرف كما يلي:
إذا لم يحتوي جدول مخطط EIGRP حاليا على إدخال للمسار، فيرد الموجه على الفور على الاستعلام برسالة يتعذر الوصول إليها، مشيرا إلى عدم وجود مسار لهذا المسار عبر هذا المجاور.
إذا كان جدول مخطط EIGRP يسرد الموجه الموجه الموجه الموجه الموجه الموجه الموجه كخلف لهذا المسار ويوجد خلف ممكن، فإنه يتم تثبيت الخلف المجدي ويقوم الموجه بالرد على الاستعلام على الفور.
إذا كان جدول طبولوجيا EIGRP يسرد الموجه الموجه الموجه الموجه الموجه باعتباره الخلف لهذا المسار ولا يوجد خلف ممكن، حينئذ يستعلم الموجه جميع جيرانه من EIGRP باستثناء تلك التي تم إرسالها من نفس الواجهة التي كان يخلفها السابق. لن يقوم الموجه بالرد على الموجه الموجه الموجه للاستعلام حتى يستلم ردا على جميع الاستعلامات التي قام بإنشائها لهذا المسار.
إذا تم تلقي الاستعلام من جار ليس هو الخلف لهذه الوجهة، فيرد الموجه بالمعلومات اللاحقة له.
تشير رسالة خطأ DUAL-3-SIA إلى أن مسار EIGRP في حالة "علق في نشط" (SIA).
تعني حالة SIA أن موجه EIGRP لم يستلم ردا على استعلام من واحد أو أكثر من الجيران خلال الوقت المخصص (حوالي 3 دقائق). عندما يحدث ذلك، يمسح EIGRP الجيران الذين لم يرسلوا ردا ويسجل رسالة خطأ DUAL-3-SIA للمسار الذي تم تشغيله.
خذ على سبيل المثال المخطط التالي:
يتعرف الخادم R2 على الشبكة 10.1.2.0/24 من خلال الخادم R1.
ينقطع الارتباط بين R1 و R2. يحل R2 خلفا له (R1) في 10.1.2.0/24.
يتحقق R2 من جدول مخطط EIGRP لخلف ممكن (جار آخر له طريق إلى 10.1.2.0/24 يلبي شرط الجدوى)، ولا يوجد لديه أي منها.
انتقالات R2 من الوضع السلبي إلى الوضع النشط ل 10.1.2.0/24.
يرسل R2 استعلامات إلى R3 و R5، يسأل ما إذا كان لديهم مسار آخر إلى 10.1.2.0/24. يبدأ عداد الوقت SIA.
يتحقق R5 من جدول مخطط EIGRP بحثا عن خليفة محتمل، ولا يحتوي على أي منها.
انتقالات R5 من الوضع السلبي إلى الوضع النشط ل 10.1.2.0/24.
يتحقق R5 من الجدول المجاور ل EIGRP الخاص به ولا يجد سوى جيران EIGRP خارج الواجهة التي تواجه R2 (خليفته السابق ل 10.1.2.0/24).
يرد R5 برسالة يتعذر الوصول إليها لأنه ليس لديه مسار بديل وليس لديه جيران آخرين للاستعلام.
انتقالات R5 من الوضع النشط إلى الوضع السلبي ل 10.1.2.0/24.
يتحقق R3 من جدول مخطط EIGRP بحثا عن خليفة محتمل، ولا يوجد به أي جدول.
انتقالات R3 من الوضع السلبي إلى الوضع النشط ل 10.1.2.0/24.
يتحقق R3 من جدول EIGRP المجاور ويبحث عن R4.
يرسل R3 استعلام إلى R4 للشبكة 10.1.2.0/24. يبدأ عداد الوقت SIA.
لا يتلقى R4 الاستعلام أبدا إما بسبب مشاكل في الارتباط بين R3 و R4 أو بسبب الازدحام. يمكنك رؤية هذه المشكلة من خلال إصدار الأمر show ip eigrp neighbor أو الأمر show ip eigrp topology active على R3؛ يجب أن يكون عدد قوائم الانتظار ل R4 أعلى من المعتاد.
تصل وحدة توقيت SIA على R2 إلى 3 دقائق تقريبا.
لا يمكن ل R3 الرد على استعلام R2 حتى يسمع ردا من R4.
يقوم R2 بتسجيل خطأ مزدوج-3-SIA للشبكة 10.1.2.0/24 ومسح التجاور المجاور مع R3.
DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.4.3 (Serial0) is down: stuck in active DEC 20 12:15:23: %DUAL-3-SIA: Route 10.1.2.0/24 stuck-in-active state in IP-EIGRP 1. Cleaning up
انتهت صلاحية مؤقت إعادة محاولة R3 ل R4.
ملاحظة: يمنع هذا الحدث R3 من الإبلاغ أيضا عن خطأ DUAL-3-SIA لأن مؤقت R3 SIA قد يصل أيضا إلى 3 دقائق.
يعمل R3 على مسح التجاور المجاور له مع R4.
يقوم R3 بالإعلام عن الخطأ التالي إلى سجله:
DEC 20 12:12:01: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.4 (Serial1) is down: retry limit exceeded
يرد R3 الآن على استعلام R2 برسالة يتعذر الوصول إليها.
يبلغ R4 عن الخطأ التالي إلى سجله:
DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.3 (Serial0) is down: peer restarted
ملاحظة: سيتم عرض رسائل DUAL-5-NBRCHANGE فقط إذا قمت بتكوين الأمر eigrp log-neighbor-changes ضمن عملية EIGRP. يوصى بتكوين هذا الأمر على جميع موجهات EIGRP لاستكشاف أخطاء EIGRP SIA وإصلاحها. ومن دونها، لا توجد طريقة لإخبار سبب إعادة ضبط جيران EIGRP أو أي موجه يعيد ضبط التجاور.
كما ترى أعلاه، يرجع سبب خطأ DUAL-3-SIA إلى المشاكل المتزامنة التالية، غير أنها غير ذات صلة:
مشكلة واجهة بين R1 و R2، مما يتسبب في إختفاء المسار 10.1.2.0/24 من R2. قد يكون رفرفة المسار ناتجة عن شيء آخر غير فشل الارتباط الفعلي (على سبيل المثال، تم قطع اتصال المستخدم البعيد وإزالة مسار المضيف المشتق من PPP).
مشكلة في الواجهة أو الازدحام أو التأخير بين R3 و R4.
عند حدوث رسالة خطأ SIA، تشير إلى فشل بروتوكول توجيه EIGRP في التقارب للمسار المحدد. وعادة ما يكون سبب هذا الفشل هو وجود واجهة وميض، أو تغيير في التكوين، أو عملاء اتصال (يكون فقد المسار طبيعيا). لا يتأثر التوجيه إلى الوجهات الأخرى عندما تكون عملية EIGRP في حالة نشطة للمسار المحدد. عندما تنتهي صلاحية مؤقت SIA للجار الذي لم يرد، يتم مسح المجاور (لا يثق EIGRP في حالة المجاور الذي يتجاوز المؤقت). ونتيجة لذلك، يتم مسح المسارات في جدول المخطط خارج هذا المجاور ويجب بعد ذلك إعادة التقارب. وهذا يعني أنه يمكن التأثير على جدول إعادة التوجيه بواسطة SIA، ويمكن إسقاط الحزم أثناء تقارب الشبكة.
يوفر هذا القسم الخطوات اللازمة لاستكشاف أخطاء مشاكل مؤشر الترابط (SIA) وإصلاحها، كما يوفر أسبابا مشتركة لمشاكل مؤشر الترابط (SIA).
وعلى الرغم من أن هناك طرقا مختلفة عديدة يمكن أن تحدث بها المبادرة، فإنه ينبغي دائما تناول المشكلة بنفس الطريقة.
عندما تقوم باستكشاف أخطاء مؤشر الترابط وإصلاحها، يجب عليك الإجابة على السؤالين التاليين (المدرجين في قائمة ترتيب الإلحاح) لتحديد الأسباب المحتملة لمبادرة الأمان (SIA).
لماذا لم يحصل الموجه على إستجابة من جميع جيرانه؟
لماذا اختفى الطريق؟
ملاحظة: باستخدام معرف تصحيح الأخطاء من Cisco CSCdp33034 (العملاء المسجلون فقط) —فعال مع برنامج Cisco IOS الإصدار 12.1(4.4)E— تم إجراء التحسينات التالية للمساعدة في حل مشكلة SIA:
يترك الموجه مسارا لمصدر حدث SIA.
يتم دفع اكتشاف حدث SIA وتصحيحه إلى الارتباط الفاشل.
أستخدم هذه الأوامر لجمع المزيد من التفاصيل لاستكشاف الأخطاء وإصلاحها:
إظهار جيران ip eigrp من كلا الطرفين
إظهار السجل | في ثنائي
show ip eigrp topology active
لسوء الحظ، هذا السؤال هو الجزء الأصعب من عملية حل المشاكل في روسيا. نظرا لأن مؤقت SIA أكثر من 3 دقائق بشكل افتراضي، فمن الضروري تعقب موجه غير مستجيب خلال هذه الفترة الزمنية. للقيام بذلك، تأكد من أن لديك مخطط مخطط شبكة يتضمن جميع الموجهات في الشبكة مع عناوين IP الخاصة بها. يجب أن يكون لديك أيضا كلمة مرور برنامج Telnet لكل موجه.
بوضع هذه المعلومات في المتناول، انتقل إلى الموجه الذي كان يقوم بإعداد تقارير SIs وشاهد هذا المسار أو المسارات الأخرى للعمل النشط. يمكنك تحديد المسارات النشطة على الموجه من خلال إصدار الأمر show ip eigrp topology active. من الطبيعي أن يسرد هذا الأمر بعض المسارات النشطة. ووجود طريق نشط لا يشير في حد ذاته إلى وجود مشكلة؛ بل يولي اهتماما خاصا للطرق التي كانت نشطة لأكثر من دقيقة واحدة.
R2# show ip eigrp topology active IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status A 10.1.2.0 255.255.255.0, 1 successors, FD is 2733056 1 replies, active 0:00:38, query-origin: Multiple Origins !--- The output above will appear on one line. via 10.1.4.3 (Infinity/Infinity), r, Serial0, serno 1232 via 10.1.6.5 (Infinity/Infinity), Serial1, serno 1227
يخبرك الإخراج أعلاه أن EIGRP نشط لمدة 10.1.2.0/24 لمدة 38 ثانية، وقد استفسر عن إثنين من الجيران، ولا يزال في انتظار الرد من 10.1.4.3. يشير الحرف الصغير r إلى أن الموجه ينتظر الرد على استعلام. تشير إحدى العواصم R إلى أنها تلقت ردا من هذا الجار. حسب حالة جدول المخطط عند إصدار هذا الأمر، يمكنك أيضا رؤية المجاور في قسم منفصل يسمى "الردود المتبقية".
ما إن يعين أنت من أي مسحاج تخديد EIGRP ينتظر إستجابة، أنت يستطيع Telnet إلى أن مسحاج تخديد أن يحدد لما EIGRP ينتظر. يجب أن تؤدي هذه العملية في نهاية المطاف إلى الموجه الفعلي الذي لا يستجيب للاستعلامات. بمجرد تحديد هذا الموجه، قم باستكشاف أخطاء عدم إستجابته للاستعلامات وإصلاحها. ويرد أدناه شرح لعدة أسباب مشتركة.
تم تحسين EIGRP في برنامج CISCO IOS الإصدار 10.3(11) و 11.0(8) و 11.1(3). يمنع أحد هذه التحسينات أي عملية EIGRP واحدة من إستخدام أكثر من 50٪ من النطاق الترددي المتاح لذلك الارتباط، يمكنك ضبط هذه النسبة المئوية، والتي قد تختلف على واجهات نقاط متعددة. يستخدم هذا التحسين السرعة، والتي تسمح بتسليم حزم EIGRP بشكل أكثر وثوقية على الروابط المكتظة. لمزيد من المعلومات حول حزم الحزم، ارجع إلى التقرير الرسمي لبروتوكول توجيه البوابة الداخلية المحسنة.
إذا لم يتم تكوين بيان النطاق الترددي بشكل صحيح لواجهة أو واجهة فرعية، فلن يتمكن EIGRP من تعقب حزم بيانات EIGRP بشكل صحيح. القيمة الافتراضية لمعلمة النطاق الترددي للواجهة التسلسلية هي T1 أو 1500 كيلوبت في الثانية. بالنسبة للواجهات التسلسلية بخلاف T1s-بما في ذلك الواجهات T1 أو المجزأة-يجب تعيين هذه المعلمة يدويا لتعكس النطاق الترددي الصحيح استنادا إلى معدل ساعة الواجهة. لا تستخدم معلمة النطاق الترددي أبدا للتأثير على تحديد مسار EIGRP.
في حالة المسارات المتكررة، تتمثل إحدى الممارسات الشائعة لإجبار بروتوكول توجيه على تحديد مسار بدلا من آخر في تعديل معلمة النطاق الترددي على الواجهة. يؤدي تكوين قيمة عرض نطاق ترددي منخفضة بشكل مصطنع على واجهة واحدة إلى منع بروتوكول التوجيه من إستخدام المسار عبر هذه الواجهة. يجب تجنب هذه الطريقة باستخدام EIGRP، لأنها تستخدم أيضا إعداد النطاق الترددي هذا لحزم EIGRP. للتأثير على تحديد مسار EIGRP على أساس الواجهة، أستخدم معلمة تكوين الواجهة delay.
يجب دائما التأكد من تعيين معلمة النطاق الترددي على النطاق الترددي الفعلي المتاح للواجهة أو الواجهة الفرعية.
يمكن أن تتسبب حلقات التوجيه أيضا في أخطاء SIA. يمكنك تحديد هذه المشكلة باستخدام الأمر show ip eigrp topology active. إذا رأيت نمطا دائريا من استعلامات EIGRP التي لم يتم الرد عليها، فقم باستكشاف المشكلة وإصلاحها كمشكلة في حلقة التوجيه.
--- R1 --- interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip address 10.2.1.1 255.255.255.0 secondary ! --- R2 --- interface Ethernet0 ip address 10.2.1.2 255.255.255.0 !
في المثال أعلاه، يستقبل R1 حزم EIGRP مرحبا بها من R2، ويبدي R2 كجار EIGRP. ومع ذلك، لا يعتبر R2 R1 جارا لأن حزم مرحبا R1 يتم الحصول عليها من 10.1.1.1، والتي ليست شبكة فرعية يتعرف عليها R2. في الإصدارات الأحدث من برنامج Cisco IOS Software، سيقوم R2 بإرجاع المجاور ليس على خطأ الشبكة الفرعية المشتركة. يتسبب هذا الخطأ في ظهور علامات تمييز خاصة بسبب عدم الرد مطلقا على الاستعلامات التي تم إرسالها من R1 إلى R2. لمعرفة ما إذا كان R1 يقوم بمسح R2 باستمرار كجار، أستخدم الأمر show ip eigrp neighbor.
كما يمكن أن يؤدي نقص موارد النظام - مثل وحدة المعالجة المركزية (CPU) أو الذاكرة أو المخازن المؤقتة - إلى منع الموجه من الرد على الاستعلامات أو من معالجة الحزم من أي نوع. لتحديد مشكلة متعلقة بالموارد، يتم إختبار اتصال الموجه المتأثر واستكشاف أخطائه وإصلاحها كما لو كانت هناك أي مشكلة أخرى في موارد الموجه.
هناك العديد من الأسباب الشائعة للطرق الرفرفة، موضحة أدناه.
إرتباط رفرفة.
أستخدم الأمر show interface للبحث عن عداد "عمليات إعادة ضبط الواجهة" أو "عمليات انتقال الناقل" المتزايدة.
إرتباط شبكة WAN محسن.
أستخدم الأمر show interface للبحث عن عداد "أخطاء الإدخال" أو "أخطاء الإخراج" المتزايدة.
خادم اتصال - مثل Cisco AS5800 - لم يتم تكوينه لتلخيص المسارات المضيفة التي تم إنشاؤها بواسطة إرتباطات PPP الخاصة بالاتصال.
وبشكل افتراضي، تقوم إتصالات PPP بتثبيت مسار مضيف من 32 بت للجانب البعيد من إرتباط PPP. إذا لم يتم تجميع هذه المسارات، يصبح EIGRP نشطا عند قطع اتصال كل مستخدم من خلال الاتصال.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
10-Aug-2005 |
الإصدار الأولي |