بروتوكول التوجيه الداخلي المحسن بين البوابات

بروتوكول التوجيه الداخلي المحسن بين البوابات
	ترويسة البروتوكول
اختصار	EIGRP
الوظيفة	بروتوكول توجيه داخليّ
المُطوِّر	شركة سيسكو
تاريخ التطوير	1993[1]
تأثَّر بـ	بروتوكول التوجيه الداخلي بين البوابات (IGRP)
طبقة نموذج OSI	طبقة الشبكة[2]
وثيقة طلب التعليقات RFC	RFC 7868[3]

بروتوكول التوجيه الداخلي المحسن بين البوابات[4] أو بروتوكول بوابة التوجيه الداخلية المعززة[5] (بالإنجليزية: Enhanced Interior Gateway Routing Protocol اختصاراً EIGRP)‏ هو بروتوكول توجيه، داخلي، هجين، غير قياسي يعمل في طبقة الشبكة من نموذج الربط البيني للأنظمة المفتوحة. في الأصل، تمّ تصميم البروتوكول ليكون مُلكية خاصّة لشركة سيسكو، وليعمل فقط على موجهاتها، ولكنّه تحوّل لاحقاً بشكل جزئي إلى بروتوكول مفتوح المصدر في العام 2013م، ثمّ نُشرت وثيقة طلب تعليقات خاصّة به فيه العام 2016، هي الوثيقة RFC 7868.[3]

جاء تطوير بروتوكول التوجيه الداخلي المُحسن بين البوابات ليحل محل بروتوكول التوجيه الداخلي بين البوابات ^{[الإنجليزية]}. لقد كان الدافع الأساسي لهذا التطوير هو محدوديّة الأخير وعدم قدرته على مواكبة تطوّر الشبكات، يتميز البروتوكول بسرعة إنجازه لعملية حساب خالية من الحلقات ^{[الإنجليزية]} وببساطة آليّة عمله العامة رغم اعتماده على خوارزمية شديدة التعقيد.

نظرة عامة

بروتوكول التوجيه الداخلي المحسن بين البوابات هو بروتوكول توجيه داخلي، هجين، غير قياسي، طُوّر من قبل شركة أنظمة سيسكو في العام 1994، ليحلّ محل بروتوكول التوجيه الداخلي بين البوابات ^{[الإنجليزية]}. في الأصل كان البروتوكول ملكية خاصّة، لكن سيسكو جعلت منه معياراً مُتاحاً للاستخدام العام،[6] وهو موصوف في وثيقة طلب التعليقات RFC 7868.[3] يمكن لبروتوكول التوجيه المُحسّن أن يُوجِّه رزم الإصدار الرابع من بروتوكول الإنترنت،[7] والإصدار السادس ،[8] وبروتوكول تبادل الرزم ^{[الإنجليزية]}[9] وبروتوكول آبل توك ^{[الإنجليزية]}.

يُشغَّل البروتوكول في كل موجه بشكلٍ مُنفصل، وبعد تشغيله، يصبح المُوجّه عضواً في مجموعة كل الموجّهات التي تُشغّل بروتوكول التوجيه المُحسّن، ويبدأ عندها باستقبال رسائل التعارف من المُوجّهات الأخرى التي تشغل البروتوكول والتي تسمى جيراناً. رسائل التعارف، وهي رسائل بث مجموعاتي، تُرسل إلى العنوان 224.0.0.10 من أجل الإصدار الرابع من بروتوكول الإنترنت،[10] وإلى العنوان FF02::A من أجل الإصدار السادس،[11] وفي كلا الحالتين، فإن هذا العنوان هو عنوان مجموعة كل المُوجّهات التي تُشغّل بروتوكول التوجيه المُحسن. بعد ذلك، يتمّ تبادل المعلومات التي تخصّ الطوبولوجيا، ثم حساب أفضل المسارات نحو الوجهات وأخيراً إضافة هذه المسارات إلى جدول التوجيه لاستخدامها في توجيه رزم البيانات.

يتميّز بروتوكول التوجيه المُحسّن بعدد من الميزات، أهمها سرعة عملية إعادة الحساب، فهو الأسرع من بين بروتوكولات التوجيه إذا تمّ استعمال كامل ميزاته، بالإضافة إلى عدم استهلاكه لعرض النطاق المُتاح في الشبكة من أجل تبادل معلومات التوجيه، فباستثناء عملية التبادل التي تحصل عند التعارف، فإنّ العقد التي تشغّل هذا البروتوكول لا تتبادل كامل معلومات التوجيه بعد ذلك مطلقاً، بل تكتفي بتبادل المعلومات المُتعلقة بالتغيرات الحاصلة في الطوبولوجيا، ويكون هذا التبادل محدوداً ولا يشمل كامل الشبكة.[12] بالإضافة لذلك، فمن السهل تشغيل البروتوكول وتقديم الدعم الفني له، ولكن الاستفادة من كامل ميزاته، تتطلب تصميماً دقيقاً للشبكة، وفهماً لخوارزمية العمل المُعقّدة، وكيفية حساب الأوزان وآليّة انتشار التحديثات.

نبذة تاريخية

صورة لجزء من الصفحة الأولى من المسودة الخامسة لبروتوكول التوجيه المُحسّن.

منذ منتصف الثمانينات، ولإنجاز التوجيه، اعتمدت شركة سيسكو على بروتوكولها الخاصّ، وهو بروتوكول التوجيه الداخلي بين البوابات ^{[الإنجليزية]}، الذي أبدى تفوقاً ملحوظاً على بروتوكول معلومات التوجيه المُسيطر في تلك الفترة، لكنّ بروتوكول التوجيه الداخلي بين البوابات عانى من عدد من العيوب والسلبيات، أهمها محدودية طول المسار، واستهلاكه لعرض النطاق من خلال حاجته الدائمة لإرسال كامل معلومات التوجيه، بالإضافة لكونه بروتوكول توجيه قياسي لا يدعم تجزئة الشبكات بل يكتفي بدعم الأصناف القياسيّة فقط، مع عملية إعادة حساب طويلة وبطيئة،[13] لذلك تطلّعت سيسكو إلى تطوير بروتوكول توجيه جديد يُلائم احتياجاتها.

كان تطوير خوارمية نشر التحديثات ^{[الإنجليزية]} في عام 1993م [14] هو النقطة الأساسية التي ارتكزت عليها عملية تطوير البروتوكول. بعد ذلك، وفي نفس العام، تمّ تطوير بروتوكول التوجيه المُحسّن بشكلٍ نهائيّ كملكيّة خاصة لشركة سيسكو، وفي العام التالي طُرحت ورقة بحثيّة من قبل المُطورين لخّصت آليّة عمله وميزاته.[1]

في مطلع العام 2013، أوضحت سيسكو رغبتها في جعل البروتوكول مُتاحاً للاستخدام العام،[15] وبالتوازي مع ذلك، وفي شهر فبراير من نفس العام، طرحت سيسكو بالتعاون مع جمعية الإنترنت أول مسودة لمعيار مفتوح لبروتوكول التوجيه المُحسّن،[16] واستغرق العمل 3 سنوات أخرى، مع مشاركة من أطراف أخرى من شركة كومولوس للشبكات ^{[الإنجليزية]} ولينكد إن وجامعة زيلينا في سلوفاكيا، وطُرحَت المسودة الأخيرة التي حملت الرقم 5 في 23 فبراير من العام 2016م،[17] بعد ذلك بشهرين، وبالتحديد في شهر مايو، طُرح المعيار الرسمي للبروتكول في وثيقة طلب تعليقات من صنف المعلومات، حملت الرقم (RFC 7868).[3]

محددات البروتوكول

يعتمد بروتوكول التوجيه المُحسن على تقنية شعاع المسافة، ولكن لديه شكل خاص مُطوّر من الخوارزمية الأساسية، بالإضافة لاعتماده على معادلة خاصة لحساب وزن المسار، آخذاً بالحسبان كلاً من زمن التأخير والوثوقية وعرض النطاق والحمولة. يعتمد البروتوكول على مفاهيم خاصّة مثل شرط الملائمة والوارث المُلائم من أجل تحقيق عملية إعادة حساب سريعة.

خوازمية العمل

الجداول المُختلفة التي تنتج عن عمل بروتوكول التوجيه المحسن (EIGRP)، القيم غير واقعية وهي بهذا الشكل من أجل التبسيط.

خوارزمية عمل بروتوكول التوجيه المحسن (EIGRP).

يعمل بروتوكول التوجيه المُحسّن على بناء جدول التوجيه والحفاظ عليه بأحدث صورة مُمكنة، كما يتميز بإجرائه عملية إعادة حساب سريعة وبدون تشكّل حلقات. من حيث فلسفة التصميم، فإنّ هذا البروتوكول يعمل وفق خوارزمية مُشابهة لخوارزمية شعاع المسافة، من حيث الشكل، ولكن هناك العديد من الاختلافات من حيث المضمون.

بعد تفعيل البروتكول على منافذ الموجه، يبدأ المُوجّه باكتشاف جيرانه أولاً، والجار هو مُوجّه آخر يُشغّل البروتوكول ويقع على بعد قفزة واحدة فقط، ثم يُنشئ البروتوكول الذي يعمل في كلا الموجهين علاقة جيران تربطهما، ويتمّ الحفاظ على فعاليّة هذه العلاقة من خلال تبادل نوع خاص من الرسائل يسمى رسائل التعارف. يحتفظ كل مُوجّه بجدول خاصّ يضمّ المعلومات الخاصّة بالجيران المُتصلين معه، وبالعلاقات معهم ويُسمى هذا الجدول بجدول الجيران.

بعد إنشاء علاقات الجيران، يقوم المُوجّه الذي تم تفعيل البروتوكول فيه، بإرسال المعلومات التي ترتبط بالشبكات المُتصلة معه بشكل مباشر إلى جيرانه، بالإضافة لاستقباله معلومات التوجيه الخاصة بالطوبولوجيا منهم، ولا يتمّ بعد ذلك تبادل كامل معلومات التوجيه بين الجيران أبداً، وتقتصر المعلومات المُتبادلة فقط على التغيرات الحاصلة في الطوبولوجيا.

بعد ذلك يقوم الموجه بتجميع المعلومات التي استقبلها في جدول خاص هو جدول الطوبولوجيا، ويضمّ هذا الجدول بنوداً يُمثل كل منها وجهة ما في الشبكة. إنّ المعلومات الموجودة في هذا الجدول لا تقدّم وصفاً دقيقاً مُتكاملاً لكامل الطوبولوجيا، وهي عبارة عن توصيف لمسارات فيها، وهي تشمل التأخير الكلي الحاصل على طول المسار، وأدنى عرض نطاق خاص بوصلة من بين الوصلات التي تُشكّل المسار، بالإضافة للوزن المنقول الخاص بالمسار، وغير ذلك.

من حيث المبدأ، يزداد وزن المسار مع زيادة طوله، ويزداد طول المسار من خلال إضافة وصلات جديدة إليه. من أجل كل مسار، يملك المُوجّه وزناً خاصّاً، بالإضافة لمعرفته للموجّه الذي يُمثّل الخطوة التالية في المسار، والذي يُسمى الوارث بحسب مصطلحات البروتوكول، في هذا فإنّ البروتوكول يسلك سلوك بروتوكول عامل بخوارزمية شعاع المسافة، لكنّ في نفس الوقت، فإنه يحتفظ بمعلومات تخصّ الطوبولوجيا مثل زمن التأخير وعرض النطاق الأدنى في وصلات المسار، وهو بذلك يسلك سلوك بروتوكول عامل بخوزازمية حالة الوصلة من حيث تجميعه لمعلومات تصفّ الطوبولوجيا، على أي حال، فإن هذا البروتوكول لا ينتمي إلى أي من المجموعتين، وغالباً ما يُوصف بأنّه بروتوكول هجين (Hybrid)،[18] أو بأنّه بروتوكول توجيه عامل بخوارزميّة شُعاع المسافة المُطوّرة (Advanced Distance-Vector).[19][20]

بعد اكتمال عملية تبادل المعلومات، يتمّ تطبيق معادلة خاصة لحساب وزن كل مسار، ويُضاف هذا الوزن إلى جدول الطوبولوجيا، لحساب الوزن الخاص بكل مسار، يستخدم: عرض الحزمة الأدنى على طول المسار، وزمن التأخير الكلي، وقيمة الوثوقية الدنيا على طول المسار، ونسبة الحمولة العليا على طول المسار ونسبة الوثوقية الدُنيا على طول المسار، ويُسمّى الوزن عندها وزناً تقليدياً. بالإمكان إضافة مُعاملات أخرى لحساب الوزن، مثل عدد القفزات ووحدة النقل العظمى (MTU) و تقلقل الإرسال والطاقة، ويسمى الوزن عندها بالوزن المُوسّع.

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

في حالة وجود أكثر من مسار نحو نفس الوجهة، قد يختار البرتوكول مساراً احتياطياً، ليكون مساراً بديلاً في حال فشل المسار الأصلي، ويتطلب ذلك تجاوز المسار لشرط خاص يسمى شرط المُلائمة. يسمح وجود مسار احتياطي بتسريع عملية إعادة الحساب بشكل كبير، ففي حال فشل المسار الأصلي يتمّ الانتقال بشكل مُباشر نحو المسار الاحتياطي، بدون إضاعة الوقت لإنجاز عملية حساب مسار جديد، لكن ذلك يتطلب تصميمَ الشبكة بشكلٍ دقيق للاستفادة من هذه الميزة.

عند حصول تغيير في الطوبولوجيا، يطبّق البروتوكول خوارزمية خاصة هي خوارمية نشر التحديثات ^{[الإنجليزية]}، تعمل هذه الخوارزمية على إيجاد العقد التي تأثّرت بالتغيير الحاصل، لتقوم وحدها بالقيام بعملية إعادة الحساب، عوضاً عن قيام كل عقد الشبكة بذلك، تضمن خوارزمية نشر التحديثات الحصول على أفضل مسار بدون تشكل حلقات وبأسرع وقت مُمكن من خلال تقليل عدد العقد المُشاركة في الحاسب إلى أدنى عدد ممكن.

باستثناء ذلك، فإن البروتوكول يُحافظ على علاقات الجيران فعّالة من خلال تبادل رسائل التعارف بشكلٍ دوريّ، ولا يتم أبداً تبادل أي معلومات تتعلق بالطوبولوجيا أو بالتوجيه، وتستمر هذه الحالة المُستقرة إلى حين حصول تغيير في الطوبولوجيا أو إيقاف تشغيل البروتوكول في الموجه.

شرط الملائمة

شرط الملائمة (بالإنجليزية: Feasibility Condition)‏ هو مُعيار يُستخدم للتأكّد من أن المسار لا يحتوي على حلقات. إنّ كل مُسار يُحقق شرط الملائمة هو بالتأكيد مسار خالٍ من الحلقات، ولكن ليس بالضرورة أن يحقق كل مسار خال من الحلقات شرط الملائمة، فالعلاقة ليست عكسية. يُستخدم شرط الملائمة كجزء من عمل خوارمية نشر التحديثات ^{[الإنجليزية]}، فلابد أن تحقق جميع المسارات التي ستختارها الخوارزمية هذا الشرط، يُطبق هذا الشرط عند حصول تغيير في الطوبولوجيا.

إنّ لكل مسار بحسب بروتوكول التوجيه المُحسّن ثلاث محددات أساسية، هي وجهته النهائيّة، ووزنه والخطوة التالية إليه، بعد تحديد حصول تغيّر في الطوبولوجيا يؤثّر على مسار معروف ومُستخدم نحو وجهة ما، فإنّ تجاوز شرط الملائمة هو ما يحدد حالة هذا المسار، فإذا تحقق الشرط، فإن المسار يظلّ في الحالة السلبيّة، إما إذا لم يتحقق الشرط، فيجب أن يتم نقله إلى الحالة الفعّالة، أي يجب البحث من جديد عن أفضل وزن نحو تلك الوجهة، وتحديد المُوجّه الذي يعلن عنه ليكون الخطوة التاليّة إليه.

إنّ التعاريف التاليّة أساسيّة لوصف شرط الملائمة:[21][22]

الوزن المنقول (بالإنجليزية: Reported Distance)‏ بالنسبة لموجه ما: هو وزن لمسار، كما أعلن عنه جار ما، بدون إدخال أي تعديل على قيمة الوزن، والحفاظ عليها كما وردت من الجار.
الوزن المحسوب (بالإنجليزية: Feasible Distance)‏: هو وزن منقول بعد التعديل، ويشمل التعديل إدخال مُعاملات المنفذ المحلي التي يربط المُوجّه مع الجار في الحسابات الخاصة بالوزن. بشكلٍ عام، الوزن المحسوب لمسار ما هو دائماً أكبر من الوزن المنقول لنفس المسار.
الوارث (بالإنجليزية: Successor)‏: الوارث هو جار. ووارث مسار نحو وجهة ما، هو المُوجّه الذي يُمثّل الخطوة التالية (بالإنجليزية: Next Hop)‏ نحو هذه الوجهة. عمليّاً، يكون وارث المسار، هو المُوجّه الذي يكون وزن مساره المحسوب نحو تلك الوجهة هو الوزن الأدنى قيمةً بين جميع الأوزان المحسوبة نحو تلك الوجهة. وهناك دائماً وارث واحد على الأقل.
الوراث المُلائم (بالإنجليزية: Feasible Successor)‏ لمسار نحو وجهة ما: هو مُوجّه، يُحدد بعد اختيار الوارث، هو جار يملك مساراً نحو الوجهة ويُحقق شرط الملائمة، ويمكن للوارث المُلائم أن يتحول إلى وارث في حال فشل الوارث، أو في حال تعذّر الوصول إليه. قد لا يوجد أي مسار ملائم أو قد يوجد مسار ملائم واحد أو أكثر.[23]

يتحقق شرط المُلائمة عندما يكون الوزن المنقول للجار المُرشح لأن يكون وارثاً مُلائماً أقل من قيمة الوزن المحسوب للوارث الحالي.[24]

في الحالة الدراسيّة المرفقة، بُسِّطت الأرقام المعمتدة وفي الواقع هي أكبر وأكثر تعقيداً، كما عُومِلت الزيادة في الأوزان تحصل بشكل مجموع جبري وهي ليست كذلك، وكل ذلك بغرض التبسيط لبيان المفاهيم السابقة.

الوزن المنقول والوزن المحسوب في بروتوكول التوجيه المحسن (EIGRP).

على سبيل المثال، إذا كان للموجه A، ثلاث جيران هم الموجهات R1 وR2 وR3، وكان الجيران الثلاثة يعلنون عن مسارٍ نحو الشبكة X، بأوزان مُختلفة، هي 10 للموجه R1، و 20 للموجه R2، و30 للموجه R3.

إن الوزن المنقول بالنسبة للموجه A عن الشبكة X هو كالتالي:

الوزن المنقول من الجار R1 هو 10، والوزن المحسوب هو 25.
الوزن المنقول من الجار R2 هو 20، والوزن المحسوب هو 27.
الوزن المنقول من الجار R3 هو 30، والوزن المحسوب هو 38.

بالنسبة للموجه A فإن الموجه R1 هو الوارث للمسار نحو الشبكة (X)، لأن قيمة الوزن المحسوب هي الدنيا.

إن الوزن المنقول من الجار R2 هو 20، وهو أدنى من الوزن المحسوب للوارث، لأن 20<25، أي أن الموجه R2 يحقق شرط الملائمة بالنسبة لهذا المسار، وهو وارث ملائم.
إن الوزن المنقول من الجار R2 هو 30، وهو أكبر من الوزن المحسوب للوارث، لأن 25<30، أي أن الموجه R3 يملك مساراً نحو الوجهة ولكنّه لا يحقق شرط الملائمة، وهو لا يصلح لأن يكون وارثاً ملائماُ.

أنواع الرسائل

في البداية، يجب التمييز بين أنواع الرسائل الخاصّة خوارمية نشر التحديثات ^{[الإنجليزية]}، وأنواع الرسائل الخاصة ببروتوكول التوجيه المُحسن، وعادة ما يتم الخلط بين الاثنين بسبب تشابه الأسماء. تعتمد خوارزمية نشر التحديثات على 3 أنواع من الرسائل هي: رسائل التحديث والاستعلام والرد. أمّا بروتوكول التوجيه المُحسن فهو يعتمد على 5 أنواع من الرسائل، وتستخدم رسائل بروتوكول التوجيه المُحسّن من أجل نقل رسائل خوازرمية نشر التحديثات، وأيضاً لإنجاز وظائف البروتوكول الأخرى، وهي إمّا أن تكون رسائل مُنفردة أو رسائل بثّ مجموعاتي.

بحسب نموذج الإنترنت، يعمل بروتوكول التوجيه المُحسّن في طبقة الإنترنت، ويتم تغليف رسائله داخل رزم بيانات بروتوكول الشبكة، مثل الإصدار الرابع من بروتوكول الإنترنت أو الإصدار السادس، في الإصدار الرابع، تمّ حجز الرقم (88) في حقل البروتوكول لتمييز رسائل بروتوكول التوجيه المُحسّن.[25] لا يمكن تقطيع رسائل البروتوكول، لذلك فإنّه لا يقوم بتوليد رسائل ذات طول يتجاوز وحدة النقل العظمى (MTU).

إنّ الأنواع الخمسة للرسائل الخاصة بالبروتوكول هي:[3][26]

رسالة التعارف (Hello Message).
رسالة الاستعلام (َQuery)، ورسالة الاستعلام لإبقاء الحالة الفعّالة (SIA-Query).
رسالة الرد (Reply)، ورسالة الرد لإبقاء الحالة الفعّالة (SIA-Reply).
رسالة الطلب (Request).
رسالة التحديث (Update).

ويبين الجدول التالي معلومات تفصيلية عن الرسائل الخاصة ببروتوكول التوجيه المُحسّن:[3][27]

نوع الرسالة	نوع الرزمة	نقل موثوق ؟	وظيفة الرسالة
رسالة التعارف	بثّ مجموعاتيّ	لا	تستخدم لاكتشاف الجيران، وهي تُرسل بشكلٍ دوريّ وبفواصل زمنيّةٍ ثابتة يتمّ تحديدُها بواسطة مُؤقّت خاصّ هو مُؤقّت التعارف، تحتوي هذه الرسالة على ثوابت حساب الوزن وقيمة مُؤقّت الانتظار.
رسالة الاستعلام	بثّ منفرد أو مجموعاتي (الحالة العامة)	دائماً	تستخدم هذه الرسالة لحمل رسائل الاستعلام الخاصّة بخوارزمية نقل التحديثات (DUAL)، بالإضافة إلى استخدامها من قبل المُوجّهات للإعلان عن كون أحد المسارات نحو وجهة ما بالحالة الفعّالة، وبأنّ مصدر المعلومات يطلب معلومات مساراً بديلاً نحو ذات الوجهة من جيرانه. إذا سبب التغيير الحاصل في الطوبولوجيا نقل عدّة مسارات إلى الحالة الفعّالة، فإنّ البروتوكول قد يُضمّن وجهات هذه المسارات في رسالة استعلام واحدة أو أكثر، ولا داعي عندها لتشمل رسالة الرد جميع هذه الوجهات، ويُكتفى بالوجهة التي تصفّ المعلومات الجديدة المُشار إليها في رسالة الرد. بعد مُعالجة رسالة الاستعلام بحسب خوارزمية نقل التحديثات يجب أن تُرسل رسالة ردّ أو رسالة ردّ بسبب كون الوجهة عالقة في الحالة الفعّالة.
رسالة الردّ	بثّ منفرد	دائماً	تُستخدم هذه الرسالة لحمل رسالة الردّ الخاصّة بخوارزمّية نشر التحديثات، وهي ترسل رداً على رسالة استعلام أو رسالة استعلام لإبقاء الحالة الفعّالة. تحتوي رسالة الردّ على قسم واحد أو أكثر من رسالة الإستعلام، وهذه الأقسام هي التي يتمّ الردّ عليها، أيّ أنّ معلومات رسالة الردّ تصفّ هذه الأقسام. يتمّ إرسال إشعار تأكيد الوصول عند استقبال رسالة الردّ، وإمّا أن يتم ذلك بشكل مُستقل أو من خلال إضافة الإشعار إلى إحدى رسائل البروتوكول.
رسالة الطلب	بثّ مُنفرد أو مجموعاتيّ	لا	تُستخدم هذه الرسالة لطلب معلومات مُحددة عن جارٍ واحد أو أكثر.
رسالة الاستعلام لإبقاء الحالة الفعّالة (SIA-Query)	بثّ مُنفرد	دائماً	عند إرسال رسالة استعلام وانتظار الردّ، يجعل المُوجّه المسارات المؤدية إلى تلك الوجهة في الحالة الفعّالة، قد يتأخر وصول الردّ لعدة أسباب مثل فقدان الرزمة أو بطء الجار أو غيرها، وتساعد هذه الرسالة المُوجّه على معرفة المزيد من المعلومات عن الجار في هذه الحالة، مثل الإجابة عن السؤال التالي: هل قُطع الاتصال مع الجار أم أنّه لم ينهِ عملية إعادة الحساب بعد ؟ في كل مرة يصل الردّ الإيجابي على هذه الرسالة، يتمّ إعادة ضبط مُؤقّت الفعاليّة إلى قيمته الاسمية، ما يسمح بالإبقاء عليه، واستمرار عملية إعادة الحساب. تُرسل رسالة الاستعلام لإبقاء الحالة الفعّالة عندما تنخفض قيمة المؤقت عن نصف القيمة الاسميّة، ومن الممكن أن يتمّ تمديد فترة البقاء في الحالة الفعّالة بهذه الطريقة ثلاث مرات متتالية. يتمّ الردّ على هذه الرسالة برسالة الردّ لإبقاء الحالة الفعّالة، والتي تُحدد فيما إذا كان المُوجّه سيُبقي المسارات نحو الوجهة في الحالة الفعّالة أم لا.
رسالة الرد لإبقاء الحالة الفعّالة (SIA-Reply)	بثّ مُنفرد	دائماً	تُرسل هذه الرسالة كرد على رسالة الاستعلام لإبقاء الحالة الفعّالة، وهي إمّا أن تُخبر المُوجّه بأنّ عملية إعادة الحساب قد انتهت أو بأنّها مازالت جاريّة، تحتوي رسالة الردّ على ثلاثيّة نوع-طول-قيمة (TLV) من أجل كل وجهة تكون مسارات الجار فعّالة إليها، تحتوي الثلاثية على علم خاص هو علم الفعاليّة (Active Flag)، وهو بت يأخذ قيمة الواحد ليكون الردّ إيجابياً لإبقاء الحالة الفعّالة، أو صفر لإيقافِها.
رسالة التحديث	بثّ مجموعاتي في الحالة العامّة، بثّ مُنفرد عند اكتشاف جار جديد	دائماً	تُستخدم هذه الرسائل لحمل رسائل التحديث الخاصّة بخوازرمية نشر التحديثات. بالإضافة لذلك، يتمّ إرسال رسالة تحديث مُنفردة إلى كل جار جديد بعد اكتشافه، وذلك لمساعدته على بناء جدول الطوبولوجيا خاصّته، أمّا عند اكتشاف حصول تغيّر في الطوبولوجيا فإنّ رسالة التحديث تكون رسالة بث مجموعاتي.

حساب الوزن

يدعم بروتوكول التوجيه المُحسّن عمليّة مُعقّدة لحساب الوزن، وهي تجري بشكلٍ آليّ اعتماداً على مُعادلة رياضيّة تشتمل على عدد من المُتحولات والمُعاملات، فأمّا المُتحولات فهي تخصّ طوبولوجيا الشبكة نفسَها، وأمّا المُعاملات فهي قيم عددية ثابتة، تُضبط من أجل التأثير بطريقة مُحددة على أحد المتحولات، كجعل أثره مُضاعفاً مُقارنةً مع البقيّة، أو حتى إهمالُه بالكامل. يُستخدم البروتوكول المتحولات لتمثيل القيم الخاصّة بعرض نطاق الوصلات، وزمن التأخير فيها بالإضافة لقيم ترتبط بالحمولة والوثوقيّة ووحدة النقل العظمى وتقلقل الإرسال والطاقة، بالإضافة لوجود ست مُعاملات هي بالترتيب (K1, K2, K3, K4, K5, K6).

المُتحوّلات المُستعملة في حساب الوزن

تُستعمل المُتحولات لوصف الخواص التي يُمكن قياسها ومقارنتها والاعتماد عليها لاختيار أفضل مسار. يستخدم البروتوكول عرض النطاق الأصغري على طول المسار بشكلٍ مُباشر كأحد المتحوّلات الرئيسيّة لحساب وزن المسار، كما يستخدمه بالإضافة لقيمة الحمولة العُظمى على طول المسار من أجل حساب معدل إنتاجيّة المسار، وهو عامل آخر لحساب الوزن. بشكلٍ افتراضيّ، يُعتمد عرض النطاق الأصغري في حساب الوزن ويُهمل معدل الإنتاجيّة.

بالإضافة لذلك، يُمكن حساب الوزن اعتماداً على زمن التأخير الكليّ الحاصل على طول المسار، وهو الزمن اللازم لانتقال بت من الوجهة النهائيّة للمسار إلى العقدة التي تُشغّل البروتوكول، إنّ زمن التأخير يقاس بالثانية، لكن القيمة المُستعملة تكون صغيرةً جداً، ومن مرتبة الميكرو ثانية، كما يدخل هذا المتحول في مُعادلات حساب الأوزان بمرتبة أصغر هي عشرات الميكروثانية في الوزن التقليدي والبيكو ثانية في الوزن المُوسّع.[28]

يُمكن أيضاً الاعتماد على جودة الوصلة في حساب وزن المسار، ولتحقيق ذلك يقيس البروتوكول أدنى قيمة للوثوقية على طول المسار، ويقوم بإدخالها في معادلات حساب الأوزان. يتمّ تمثيل الوثوقيّة بعدد صحيح من المجال [256,1]، يقابل النسبة المئوية المُستخدمة. على أيّ حال، إنّ الوثوقية ليست مُتحوّلاً أساسيّاً في عملية حساب الوزن، ويتمّ إهماله في الحالة الافتراضية.

يدعم البروتوكول أيضاً حساب الوزن واختيار المسارات على أساس تقلقل الإرسال واستهلاك الطاقة، حيث تُقضّل المسارات التي تكون تقلقل الإرسال فيها أقلّ ما يُمكن، وكذا الأمر بالنسبة لاستهلاك الطاقة.[29] رغم دعم البروتوكول للمفهومين السابقين، إلا أنّه لا يمتلك أي وسيلة حاليّاً لقياس أيّ منهما، ولذلك فإنّ إدخال قيم هذه المُتحولات في معادلة حساب الوزن غير مُمكن.[30]

وحدة النقل العظمى هي أحد المتحولات التي يقيسُها البروتوكول وينقلُها في رسائله، والهدف الأساسي من ذلك هو التعرّف على أدنى وحدة نقل أعظمية طول المسار، لكنّ هذه القيمة لا تدخُل في مُعادلات حساب الأوزان.[31]

المعاملات المستعملة في حساب الوزن

طُوِّرت معادلة حساب الوزن الخاصّة ببروتوكول التوجيه المحسن بناء على دراسة دقيقة لإعطاء كل مسار وزناً يتلائم مع محدداته، بحيث يكون للمسار الأفضل وزنٌ أقل، وقد تمّ اختيار قيم المُعاملات بناء على هذا، لذلك لا يُستحسن أن يتمّ تعديل هذه القيم.[32] يُمكن أن تأخذ قيمة أي مُعامل أي عدد صحيح موجب في ضمن المجال [255,0].[33] إنّ تطابق هذه القيم بين مُوجّهين يُشغّلان البروتوكول هو شرطٌ أساسيّ لنجاح إنشاء علاقة الجيران فيما بينهما.[34]

يُعطي المُعامل K1 أهمية لعرض النطاق، أما المُعامل K2 فإنه يُستخدم ليعطي أهمية لإنتاجية الشبكة، والتي تُحسب بصيغة رياضية تربط بين اثنين من المُتحولات هما عرض النطاق والحمولة. يسمح المُعامل K3 بإعطاء أهميّة للتأخير الحاصل على طول المسار في معادلة حساب الوزن. أمّا المعاملين K4 و(K5) فهما يُدخلان جودة الوصلة في الحساب، عن طريق الوثوقية. إنّ القيمة الافتراضيّة للمُعاملين K1 وK3 هي 1، أمّا القيمة الافتراضيّة للمُعاملات K2 وK4 وK5 فهي 0.[35]

يقتصر استخدام المعامل K6 على عملية حساب الوزن المُوسّع فقط، وهو يُدخل متحولات تقلقل الإرسال والطاقة في الحساب، تكون القيمة الافتراضيّة لهذا المعامل هي 0.[36]

حساب الوزن التقليدي

لحساب الوزن التقليدي تُستخدم المعادلة التاليّة:[37]

{\text{C= }}{\bigg [}{\bigg (}K_{1}\cdot {\text{Bw}}_{L}+{\frac {K_{2}\cdot {\text{Bw}}_{L}}{256-{\text{L}}}}+K_{3}\cdot {\text{D}}_{L}{\bigg )}\cdot {\frac {K_{5}}{K_{4}+{\text{R}}}}{\bigg ]}\cdot 256

حيث ( ${{\text{Bw}}_{L}}$ ) هي القيمة الخطيّة لأدنى عرض نطاق على طول المسار، و ${{\text{D}}_{L}}$ هي القيمة الخطيّة لمجموع أزمنة التأخير على كامل الوصلات التي تشكل المسار مقدرّة بعشرات الميكروثانية، أما الحمل ${\text{L}}$ والوثوقيّة ${\text{R}}$ ، فهما يأخذان قيماً صحيحة من المجال [256,1]، لتعكس نسبة مئويّة، حيث تمثل القيمة 255 النسبة 100% وتمثل القيمة 127 النسبة 50%. إنّ أدنى قيمة وثوقية على طول المسار تدخل في حساب الوزن، أمّا لإيجاد قيمة مُتحول الحمل، فإنّ أعلى قيمة على طول المسار هي ما يُعتمد في معادلة حساب الوزن.[38] يرجع استعمال القيم الخطيّة إلى الاختلاف في واحدات القياس، ففي حين يقاس عرض النطاق، بملايين الهرتز، والهرتز هو مقلوب الثانية، فإنّ زمن التأخير يقاس بالميكرو ثانية، لذلك تُستعمل القيم الخطيّة بهدف تجانس الوحدات.

أمثلة عن قيم المتحولات المُستعملة لحساب الوزن في بروتوكول التوجيه المُحسّن من أجل منافذ مُختلفة.

لحساب عرض النطاق الخطيّ للمسار ${{\text{Bw}}_{L}}$ بشكل يدويّ:

تحديد المسار، ويشمل ذلك تحديد بداية المسار، وهي الوجهة التي يُوصِل المسارُ الرزمَ إليها، ونهايته، وهي العقدة التي تُشغّل البروتوكول، بالإضافة لتحديد كل العقد التي تشغل البروتوكول على المسار.
على فرض إرسال رزمة من بداية المسار إلى نهايته، تحديد المنافذ التي تستقبل الرزمة على طول المسار، وقيمة عرض النطاق المُوافق لكلٍ منها.
اختيار أدنى قيمة من القيم السابقة، وهي القيمة التي يُرمز لها (BWmin)، مُقدّرة بواحدة الكيلو بت في الثانية (Kbps).
حساب القيمة الخطيّة لعرض النطاق السابق بحسب المعادلة:

{{\text{Bw}}_{L}=}({\frac {10^{7}}{BWmin}})

لحساب عرض النطاق الخطيّ للمسار ${{\text{D}}_{L}}$ بشكل يدويّ:

تحديد المسار، ويشمل ذلك تحديد بداية المسار، وهي الوجهة التي يُوصِل الرزم إليها، ونهايته، وهي العقدة التي تشغّل البروتوكول، بالإضافة لتحديد كل العقد التي تشغل البروتوكول على المسار.
على فرض إرسال رزمة من بداية المسار إلى نهايته، تحديد المنافذ التي تستقبل الرزمة على طول المسار، وقيمة التأخير الحاصل في كل منها مُقدّراً بالثانية.
إيجاد مجموع القيم السابقة.
ضرب الناتج بالقيمة $10^{-7}$ ، لتحويله إلى واحدة عشرات الميكرو ثانية.

من أجل القيم الافتراضية للمُعاملات، مع افتراض أن ${\frac {K_{5}}{K_{4}+{\text{R}}}}$ مُساوية للواحد من أجل قيمة صفرية للمُعامل ( ${K_{5}}$ )، فإنّ مُعادلة حساب الوزن التقليدي تؤول إلى الشكل التالي:[39]

{\text{C= }}[K_{1}\cdot {\text{Bw}}_{L}+K_{3}\cdot {\text{D}}_{L}]\cdot 256

تتمّ عملية الحساب بشكلٍ آليّ. إنّ وحدة النقل العظمى لا تدخل في معادلة الوزن التقليدي.[40]

حساب الوزن المُوسّع

لحساب الوزن المُوسّع تُستخدم المعادلة التالية:[28]

{\text{C= }}{\bigg [}(K_{1}\cdot {\text{NetTh}})+{\text{Latency}}+(K_{6}\cdot {\text{ExtAttr}}){\bigg ]}\cdot {\frac {K_{5}}{K_{4}+{\text{R}}}}

حيث ( ${\text{NetTh}}$ ) هي مُعدّل الإنتاجية الصافيّ، و( ${\text{Latency}}$ ) هو زمن الكمون، و ( ${\text{ExtAttr}}$ ) هو المُتحوّل الخاص بالسمات الإضافية، و ( ${\text{R}}$ ) هي الوثوقيّة، وهي مُتحوّل يمثل أدنى قيمة للوثوقية على طول المسار، وهو نسبة مئويّة تقابل عدداً صحيحاً من المجال [256,1] حيث تُمثّل النسبة (100%) بالعدد (256).

لحساب معدل الإنتاجيّة الصافيّ، تُستخدم المعادلة التالية:[41]

{\text{NetTh =}}{\text{MaxTh +}}{\frac {K_{2}\cdot {\text{MaxTh}}}{265-{\text{L}}}}

حيث ( ${\text{MaxTh}}$ ) هو مُعدل الإنتاجيّة الأعظميّ، و ( ${\text{L}}$ ) هو أعلى قيمة للحمل على طول المسار، وهو نسبة مئويّة تُقابل عدداً صحيحاً من المجال [256,1] حيث تُمثّل النسبة (100%) بالعدد (256). لحساب مُعدل الإنتاجيّة الأعظمي، تُستخدم المعادلة:[41]

{\text{MaxTh =}}K_{1}\cdot ({\frac {EBW*EWS}{BWmin}})

حيث ( $BWmin$ ) هو عرض النطاق الأدنى على طول المسار، و( $EWS$ ) و( $EBW$ ) هي ثوابت عدديّة خاصة بالبرتُوكول، ويُمكن أخذ قيمتُها الحقيقيّة من محدداته.

الاختصارات المُستعملة في معادلات حساب الوزن المُوسّع وقيم الثوابت الموافقة
اسم الثابت الكامل	الاختصار المقابل	القيمة
EIGRP_BANDWIDTH	EBW	10000000
EIGRP_DELAY_PICO	EDP	1000000
EIGRP_INACCESSIBLE	EIN	(FFFFFFFFFFFFFFFF)₁₆
EIGRP_MAX_HOPS	EMH	100
EIGRP_CLASSIC_SCALE	ECS	256
EIGRP_WIDE_SCALE	EWS	65536

لحساب زمن الكمون ( ${\text{Latency}}$ )، تُستخدم المُعادلة التاليّة:[41]

{\text{Latency =}}K_{3}\cdot ({\frac {{\text{D}}\cdot EWS}{EDP}})

حيث ( $D$ ) هي أدنى زمن تأخير على طول المسار، مقاساً بواحدة البيكو ثانية، و( $EWS$ ) و( $EDP$ ) هي ثوابت عددية خاصّة بالبرتوكول، ويمكن أخذ قيمتها الحقيقية من محدداته.

إنّ متحوّل السمات الإضافية ( ${\text{ExtAttr}}$ ) يُمثّل المجموع التراكمي لأحد السمات الإضافية على طول المسار، وهناك سمتين إضافيتين يمكن إدخالُهما في حساب الوزن هما تقلقل الإرسال و الطاقة.

من أجل القيم الافتراضيّة للمُعاملات، مع افتراض أنّ ( ${\frac {K_{5}}{K_{4}+{\text{R}}}}$ ) مُساوية للواحد من أجل قيمة صفريّة للمُعامل ( ${K_{5}}$ )، فإنّ مُعادلة حساب الوزن المُوسّع تؤول إلى الشكل التاليّ:

{\text{C= }}K_{1}\cdot BWmin+K_{3}\cdot {\text{D}}

طوبولوجيا الشبكة

يتعامل بروتوكول التوجيه المحسن (EIGRP) مع كامل الطوبولوجيا دفعة واحدة، أي أنّه لا يُقسمها إلى أقسام ولا يُجزّؤها إلى مناطق.[42] خلال عمله، يُقوم البروتوكول بإنشاء جدولين هما جدول الجيران الذي يحتوي معلومات عن عن جيران المُوجّه التي تُشغّل البروتوكول، وجدول الطوبولوجيا الذي يُخزّن معلومات تصف مساراتٍ مُختلفة في طوبولوجيا الشبكة. بالإضافة لذلك، فإنّ بروتوكول التوجيه المُحسّن يضيف مجموعة من البنود إلى جدول التوجيه كنتيجة نهائيّة لعمله.

جدول الجيران

يضمّ جدول الجيران معلومات عن جيران المُوجّه الحاليين، والجار هو مُوجّه آخر يُشغّل بروتوكول التوجيه المُحسن ويتبادل رسائل التعارف مع المُوجّه المحليّ الذي يضمّ جدول الجيران. يتمّ تجميع المعلومات الموجودة في جدول الجيران من رسائل التعارف المُستقبلة من الجيران المُختلفين، عند التعرف على جار جديد يتمّ إضافته إلى جدول الجيران، وكذلك الأمر عند انتهاء العلاقة مع أحد الجيران، حيث يصار إلى حذفه من جدول الجيران. بشكلٍ عام، يوجد جدول جيران واحد، ولكن إذا تمّ تشغيل أكثر من وحدة غير مُستقلة من وحدات البروتوكول فسيتمّ إنشاء جدول جيران لكل وحدة، بعبارة أخرى، من أجل كل بروتوكول مُوجّه، يتمّ إنشاء جدول جيران مُستقل.[43]

يضمّ جدول الجيران عنواناً مُميزاً للجار، ومنفذ المُوجّه المحلي الذي يتصل معه، يكون مُؤقّت الانتظار مُلحقاً بجدول الجيران، إنّ نفاذ مُؤقّت الانتظار يعني فشل الجار، ويتطلب تطبيق خوارمية نشر التحديثات ^{[الإنجليزية]}. بالإضافة لذلك، فإنّ الجدول يضمّ معلومات مُكتسبة من بروتوكول النقل الموثوق (RTP)، وهو بروتوكول يُقدّم خدمة النقل الموثوق، ويعتمد عليه بروتوكول التوجيه المُحسّن لضمان إيصال الرزم.

جدول الطوبولوجيا

يحتوي جدول الطوبولوجيا على المعلومات الخاصّة بطوبولوجيا الشبكة، يتمّ تجميع هذه المعلومات من خلال الشبكات المُتصلة بشكلٍ مُباشر مع الموجه بالإضافة للمعلومات المُكتبسة من الجيران، سواءً أثناء إنشاء علاقة الجيران أو بسبب حصول تغيرات في الطولولوجيا. يتكوّن الجدول من عدد من البنود، ويُمثّل كل بند شبكة وجهة، ويضم معلوماتٍ عن المسار إلى تلك الوجهة، مثل الوزن المنقول والوزن المحسوب ووارث المسار نحو هذه الشبكة الوجهة، بالإضافة إلى الوارث أو الورثة الملائمين في حال وجودهم.[44]

إنّ بروتوكول التوجيه المُحسّن يعتمد بالأساس على خوازمية عمل مشتقة من خوارزميّة شعاع المسافة، لذلك فإنّه لا يُخزّن معلومات تفصيليّة عن كامل طوبولوجيا الشبكة، بل تصف هذه المعلومات مساراتٍ فيها، ولا يكون وصف المسارات تفصيليّاً أيضاً، لكنّه يضمّ المعلومات المطلوبة لحساب الأوزان، إن جدول الطولولوجيا هو المصدر الأساسي للمعلومات التي سوف تضاف إلى جدول التوجيه.[45]

جدول التوجيه

جدول التوجيه هو قاعدة بيانات موجودة في كل مُوجّه، تخصص لتخزين المعلومات الخاصّة بالتوجيه والتي تستعمل بشكل مباشر لاتخذ قرار التوجيه، يقوم بروتوكول التوجيه المُحسّن (EIGRP) بإضافة المسارات التي يختارها إلى جدول التوجيه، مع علامة خاصّة للإشارة إلى مصدرها، في الموجّهات العاملة بأنظمة تشغيل سيسكو تكون هذه العلامة هي حرف (D).[46]

مثال عن جدول توجيه في مُوجّه يُشغّل نظام تشغيل سيسكو، يحتوي على بنود تمت إضافتها بواسطة بروتوكول التوجيه المُحسن (EIGRP).في شبكة تُشغّل الإصدار الرابع من بروتوكول الإنترنت (IPv4).
مثال عن جدول توجيه يحتوي بنوداً تمت إضافتها بواسطة بروتوكول التوجيه المُحسّن (EIGRP)، تم استخدام الإصدار السادس من بروتوكول الإنترنت (IPv6) كبروتوكول مُوجّه.
مثال عن جدول الطوبولوجيا الخاصّ ببروتوكول التوجيه المُحسّن (EIGRP) في مُوجّه يُشغّل نظام تشغيل سيسكو. في شبكة تُشغّل الإصدار السادس من بروتوكول الإنترنت (IPv6).
مثال عن جدول الطوبولوجيا الخاصّ ببروتوكول التوجيه المُحسّن (EIGRP) في مُوجّه يُشغّل نظام تشغيل سيسكو.في شبكة تُشغّل الإصدار الرابع من بروتوكول الإنترنت (IPv4).
مثال عن جدول الجيران الخاصّ ببروتوكول التوجيه المُحسّن (EIGRP) في مُوجّه يُشغّل نظام تشغيل سيسكو، في شبكة تُشغّل الإصدار الرابع من بروتوكول الإنترنت (IPv4).

رسائل التحديث

تُستخدم رسائل التحديث لنقل معلومات التوجيه بين المُوجّهات المُختلفة، ولا يتمّ تبادل معلومات التوجيه إلا بين المُوجّهات الجيران. تحصل عملية تبادل رسائل التحديث وفق القواعد التالية:[47]

بعد نشوء علاقة الجيران بين مُوجّهين، يتمّ تبادل كامل معلومات التوجيه، وهي الحالة الوحيدة التي يتمّ فيها تبادل كامل معلومات التوجيه.
عند حصول تغيير في الطوبولوجيا، ويشمل ذلك تغيير في معاملات أو متحولات حساب الوزن، أو فشلاً في إحدى الوصلات، أو اكتشاف جار جديد، فإن المُوجّه الذي اكتشف التغيير يقوم بإرسال تحديثٍ جزئي يصفّ فيه التغيير الحاصل في الشبكة فقط. في حال اكتشاف جار جديد، يتمّ تبادل كافة معلومات التوجيه مع الجار الجديد فقط، ويتمّ نشر تحديثات تُفيد بالتغيير الحاصل في باقي الشبكة.
في حال فشل علاقة جيران ثم إعادة تشكيلها مُجدداً، يجب تبادل كامل معلومات التوجيه، بشكل مُطابق للتعرّف على جار جديد.
يدعم بروتوكول التوجيه المُحسّن خاصية تحديد الأفق (Split Horizon) بشكلٍ افتراضيّ، كآليّة لمنع تشكّل الحلقات،[48] وتُحدد هذه الخاصيّة المعلومات التي يتمّ إرسالها عبر كل منفد، سواء في التحديثات الكليّة أو الجزئية.[49]

المؤقتات ودورات الحياة

يعتمد بروتوكول التوجيه المُحسّن (EIGRP) على ثلاث مُؤقّتات لإنجاز عمله هي مُؤقّت التعارف ومُؤقّت الانتظار اللذان يحكُمان دورة حياة الجار، ومُؤقّت الفعاليّة الذي يلعب دوراً هامّاً في دورة حياة المسار.

مؤقت التعارف

يُحدد مُؤقّت التعارف (Hello Timer) الفترة الزمنيّة الفاصلة بين رسائل التعارف التي يُرسلها البروتوكول عبر منفذ ما.[50] في المُوجّهات العاملة بأنظمة تشغيل سيسكو تكون القيمة الاسميّة لهذا المؤقت هي (5) ثواني في منافذ الشبكات المحليّة، و (60) ثانية في منافذ الشبكات المُتباعدة.[51] لا يُسبب اختلاف قيم مُؤقّت التعارف بين طرفين مانعاً لتشكيل علاقة الجيران، ولكن وضع قيم غير مدرُوسة بشكلٍ جيّد قد يُسبب إنشاء علاقة جيران غير مُستقرّة.[52]

مؤقت الانتظار

يُحدد مؤقت الانتظار (Hold Timer) الزمن الذي ينتظره البروتوكول بعد استلام رسالة تعارف من جارٍ ما قبل إعلان فشل علاقة الجيران معه، ويعني الفشل أنّ الوصول إلى الجار غير مُمكن،[3] ويُعدّ ذلك تغييراً في الطوبولوجيا. يُسبب استلام رسالة تعارف نت جار ما إعادة ضبط مُؤقّت العلاقة مع ذلك الجار إلى قيمته الإسميّة. بشكلٍ افتراضيّ، تكون قيمة هذا المُؤقّت ثلاث أضعاف قيمة مُؤقّت التعارف، وفي المُوجّهات العاملة بنظام تشغيل سيسكو تبلغ القيمة الاسميّة لهذا المؤقت (15) ثانية في المنافذ المُتصلة مع شبكات محليّة، و(180) ثانية في المنافذ المُتصلة مع شبكات مُتباعدة.[53]

يجب الانتباه إلى أن آليّة تحديد فشل أو استمرار علاقة الجيران تعمل بشكلٍ مُستقلٍ في كل من طرفي علاقة الجيران. لا يظهر أيّ إشكالٍ إذا استخدمُت نفس قيمة مُؤقّت الانتظار في طرفي علاقة الجيران، ولكن عند تهيئة قيم مُختلفة في الطرفين، فإنّ كل طرف سيستخدم قيمة مُؤقّت الانتظار التي تمّت تهيئتُها في الطرف الآخر كأساس لتحديد حالة علاقة الجيران، لا القيمة التي تمّت تهيئتُها محليّاً.[54]

ُُيُرسل كل مُوجّه قيمة مُؤقّت الانتظار الخاصّة به ضمن رسائل التعارف ليتمّ اعتمادها في جدول جيران الجار لاحقاً في حال نجاح علاقة الجيران، يجب أن تكون قيمة مُؤقّت الانتظار أكبر من قيمة من مُؤقّت التعارف، وتستحسن سيكسو أن تكون قيمة مُؤقّت الانتظار ثلاث أضعاف قيمة مُؤقّت التعارف.[55]

مؤقت الفعاليّة

يُحدد مُؤقّت الفعاليّة (Active Timer) الزمن الذي يقضيه المسار في الحالة الفعّالة بعد إرسال رسالة الاستعلام قبل أن يعتبره البروتوكول عالقاً في الحالة الفعّالة (Stuck in Active SIA)، يسبب نفاذ مؤقت الفعاليّة اعتبار الوصول إلى الوجهة غير مُمكناً وحذف المسار من جدول الطوبولوجيا [56] ويُمكن أن تستخدم رسالة الاستعلام للإبقاء على الحالة الفعّالة (SIA Query) من أجل إعادة ضبط هذا المُؤقّت إلى قيمته الاسميّة بهدف منح المسار مزيداً من الوقت في الحالة الفعّالة لحين انتهاء الحساب.

دورة حياة الجار

مخطط الحالة لدورة حياة الجار بحسب بروتوكول التوجيه المُحسنّ (EIGRP).

تصفُ دورة حياة المسار علاقة المُوجّه الذي يُشغل بروتوكول التوجيه المُحسن (EIGRP) مع جاره. بحسب البروتوكول هناك حالة وحيدة في هذه الدورة، وهي حالة الجار الفعّال، وهو الجار الذي ما يزال الاتصال قائماً معه، ويتحكّم بدورة الحياة هذه مُؤقّتين اثنين هما مُؤقّت التعارف ومُؤقّت الانتظار الخاصّين بالجار، حيث يحدد مُؤقّت التعارف الخاصّ بالجار الزمن الفاصل بين رسائل التعارف التي يُرسلها الجار،[57] والتي تسبب بدورها إعادة ضبط لقيمة موقت الانتظار في المُوجّه الذي يُشغل البروتوكول.

يجب الانتباه إلى أن القيمة الاسمية لمُؤقّت الانتظار الخاصّ بالجار هي القيمة المُكتبسة من الجار نفسه عن طريق رسائل التعارف القادمة منه وليست قيمة المُؤقّت المحليّة، أيّ أن لكل جار قيمة مُؤقّت انتظار خاصّة به يُحددها في رسائل تعارفه.

تبدأ دورة حياة الجار بالتعرّف عليه من خلال استقبال رسالة تعارف من طرفه، ويتمّ بعدها إنشاء علاقة الجيران معه إذا تحققت شروط إنشاء علاقة الجيران. بعد ذلك، يجري إضافة الجار إلى جدول الجيران، ويتمّ ضبط مُؤقّت الانتظار خاص به، وتشغيله لتتناقص القيمة تنازلياً من القيمة الاسميّة وصولاً إلى الصفر. إنّ لكل جار مُؤقّت انتظار خاص، ويتمّ اكتساب قيمة المُؤقّت من رسائل التعارف التي يُرسلها ذلك الجار. يتمّ إزالة الجار من جدول الجيران عند نفاذ قيمة المؤقت، أي عندما تبلغ قيمته الصفر.

مع كل استقبال لرسالة تعارف قادمة من الجار يتمّ إعادة ضبط قيمة مؤقت الانتظار الخاص به إلى القيمة الاسميّة مجدداً ليبدأ التناقص مُجدداً نحو الصفر، وطالما بقي تدفّق الرسائل من الجار مُستمراً فإنّ الجار سيظلّ في الحالة الفعّالة، لأن قيمة مُؤقّت التعارف أقل من قيمة مُؤقّت الانتظار، أمّا عند غياب رسائل التعارف لفترة زمنية تفوق قيمة مُؤقّت الانتظار، فإنّ علاقة الجيران ستفشل ولا بد من التخلّص من الجار وإزالته من جدول الجيران.[58]

دورة حياة المسار

مخطط الحالة للمسار بحسب بروتوكول التوجيه المُحسّن (EIGRP).

إنّ المسار بحسب بروتوكول التوجيه المحسن (EIGRP) هو الطريق الذي يتمّ اختياره لتوجيه الرزم فيه نحو وجهة معيّنة، ولكل مسار ثلاث مُحددات أساسيّة هي الوجهة النهائيّة، ووزن المسار، والخطوة التالية فيه. بالنسبة لأي مُوجّه يُشغل البروتوكول، تبدأ دورة حياة المسار عند اكتشاف وجود الوجهة، عن طريق رسالة تحديث، فيقوم المُوجّه بإضافتها إلى جدول توجيهه، أمّا عند اكتشاف حصول تغيير يخصّ هذا المسار في الطوبولوجيا، فإنّ المُوجّه يبحث في جدول الطوبولوجيا عن وارثٍ مُلائم، ليجعله وارثاً للمسار وليضيفه لجدول التوجيه. في حال عدم وجود وارثٍ مُلائم، يقوم البروتوكول عندها بإرسال رسائل استعلام نحو الجيران للبحث عن أفضل طريق نحو تلك الوجهة، أي الطريق الأقل وزناً، ثم يقوم البروتوكول بجعل المُوجّه الذي يُعلن ذلك الطريق هو الخطوة التالية فيه، وذلك من خلال جعله وارثاً للمسار.[59]

خلال وجوده في جدول الطوبولوجيا، يمر المسار بحالتين هما:[3][60]

الحالة الفعّالة (Active): هي حالة مُؤقّتة لمسارٍ نحو وجهة ما، في هذه الحالة مايزال البحث جاريّاً عن وارثٍ لهذا المسار، وتكون الوجهة النهائيّة للمسار معلُومة، ولكن وزن المسار الكليّ والخطوة التالية فيه مجهولان، ويجري حسابهما. يتمّ الانتقال إلى هذه الحالة عندما يفشل الوراث الحالي، دون وجود وارث مُلائم، وعندها لابد من البحث عن جار جديد ليرث المسار نحو تلك الوجهة. عندما يكون المسار في هذه الحالة فهو خارج الخدمة ولا يُمكن استخدامه.
الحالة السلبيّة (Passive): وهي حالة مسار نحو وجهة ما عند وجود وارث أو وارث ملائم له. في هذه الحالة تكون وجهة المسار النهائيّة، والخطوة التالية فيه، ووزنه كلّها معلومة، ولا داعي لإجراء أيّ حساب، ولا لتشغيل خوارزمية نشر التحديثات (DUAL). عندما يكون المسار في الحالة الفعّالة فمن المُمكن استخدامُه وإضافته إلى جدول التوجيه.

إنّ الحالة الفعّالة هي مرحلة مُؤقّتة يتمّ تحديدُها بواسطة مُؤقّت الفعاليّة، كما يُمكن زيادة مدة البقاء فيها من خلال إعادة ضبط المُؤقّت عن طريق استخدام رسائل الاستعلام والرد الخاصّة بالإبقاء في الحالة الفعّالة (SIA)، لكن لا يمكن زيادة مدة البقاء فيها إلا ثلاث مرات فقط. بعد ذلك، وفي حال عدم العثور على مسارٍ نحو الوجهة، فمن غير الممكن بلوغها ويتمّ التخلّص منها، وحذفُها من جدول الطوبولوجيا.

إعادة الحساب

عند حصول تغيير في الطوبولوجيا، تُصبح الشبكة غير مُستقرّة، أي تملك المُوجّهات فيها وجهاتٍ لا يمكن بلوغها، وإعادة الحساب (Convergence) هي العمليّة التي يتمّ فيها إيجاد مسارات جديدة نحو تلك الوجهات أو حذفها من جدول التوجيه، وتُنجز عمليّة إعادة الحساب عندما يملك كل مُوجّه في الشبكة مساراتٍ فعّالة نحو كل الوجهات، ويُسمّى الزمن المُستغرق لإنجاز عملية إعادة الحساب بزمن إعادة الحساب.[61]

يُنجز بروتوكول التوجيه المُحسّن (EIGRP) شكلين من أشكال إعادة الحساب، الأول هو إعادة الحساب السريعة، وتحصل عندما يفشل الوارث ولكن المسار يملك وارثاً ملائماً، فيتمّ الانتقال من الوارث إلى الوارث الملائم بشكلٍ مُباشر، ولا تستغرق العملية زمناً يُذكر، أمّا الشكل الثاني، فهو إعادة الحساب البطيئة، وتحصل عند فشل الوارث، وعدم وجود وارثٍ مُلائم له، ولابد عندها من اللجوء إلى رسائل الاستعلام لحساب المسار الجديد، إنّ العامل الأساسيّ في تسريع عمليّة إعادة الحساب لمسارٍ ما هو وجود وارثٍ مُلائم له.[62]

تُقسّم عملية إعادة الحساب في بروتوكول التوجيه المُحسّن إلى 3 مراحل وظيفياً هي:[63]

مرحلة اكتشاف الفشل، وتتحدد بسرعة التجهيرات في اكتشاف حصول الفشل وتفاعلُها معه.
مرحلة نشر المعلومات، ويتمّ فيها نشر المعلومات عن الخطأ الذي تمّ اكتشافه في المرحلة السابقة.
مرحلة التصحيح، وتتحدد بسرعة التجهيزات في حساب مسار بديل لتعويض الفشل الحاصل وإعادة الشبكة إلى مرحلة الاستقرار.

وجدت دراسة مُقارنِة على سرعة إعادة الحساب، شملت بروتوكول التوجيه المُحسّن وبروتوكول أقصر مسار أولاً المفتوح (OSPF) وبروتوكول معلومات التوجيه (RIP). إنّ بروتوكول التوجيه المُحسّن يملك أسرع عمليّة إعادة حساب، وهي مرتبة الميلي ثانية في حال المُحاكاة، أما في حال التطبيق الفعليّ فستغرق بضع ثوانٍ.[64]

آلية العمل

ترويسة البروتوكول

ترويسة بروتوكول التوجيه المحسن (EIGRP).

تتكون ترويسة بروتوكول التوجيه المُحسن (EIGRP) من 8 حقول أساسيّة، بالإضافة إلى عدد من الثلاثيّات التي يتكون كل منها من ثلاث حقول هي حقل نوع الثلاثيّة، وحقل طول الثلاثيّة وحقل القيمة. إنّ الحقول الثمانيّة الأساسيّة في الترويسة هي:[65]

حقل الإصدار: (Version): طوله (8) بت، وهو يحتوي على رقم الإصدار الحالي، وهو الإصدار الثاني.
حقل ترميز العملية: (OpCode): طوله (8) بت، ويحدد نوع الرسالة، وهو يأخذ القيم التالية:
- رسالة تحديث: 1
- رسالة طلب: 2
- رسالة استعلام: 3
- رسالة رد: 4
- رسالة تعارف: 5
- محجوز:6-9
- رسالة استعلام بسبب كون الوجهة عالقة في الحالة الفعّالة: 10
- رسالة طلب بسبب كون الوجهة عالقة في الحالة الفعّالة: 11

الثوابت المُستعملة في حقل الموجه الافتراضي.
مجال القيم (بالنظام الست عشري)	الاستعمال
0000	عائلة العناوين الفريدة
0001	عائلة عناوين البث المجموعاتي
0002 حتى 7FFF	مجال محجوز
8000	عائلة الخدمات الفريدة
8001 حتى FFFF	مجال محجوز

حقل التحقق الجمعي (Checksum): طوله (16) بت، يُستخدم للتحقق من صحة محتويات الترويسة بعد نقلها. إذا لم تتجاوز الترويسة اختبار التحقق الجمعيّ يتم التخلّص من الرزمة.
أعلام: بطول (32) بت، ويحتوي على أربع أعلام:[66]
- علم الابتداء (INIT-Flag)، وهو البت رقم (1)، ويستخدم في عملية اكتشاف الجيران.[67]
- علم نمط الاستقبال الشرطي (CR (Conditionally Received)-Flag)، وهو البت رقم (2).
- علم إعادة التشغيل (RS-Flag)، وهو البت رقم (4)، ويستخدم هذا البت في رسائل التعارف والتحديث خلال فترة إعادة التشغيل وذلك لمعرفة فيما إذا كان الجار في مرحلة إعادة التشغيل، وهذا يسمح بالحفاظ على علاقة الجيران لحين انتهاء إعادة التشغيل.
- علم نهاية الجدول (EOT(End-of-Table)-Flag)، وهو البت رقم (8)، وهو يُشير إلى نهاية عملية تبادل معلومات التوجيه مع جار جديد.
رقم التتابع (Sequence Number): وهو حقل بطول (32) بت، مُخصص من أجل عمليّة النقل الموثُوق. من أجل كل رُزمة يُرسلها موجه ما، يجب أن تكون قيمة هذا الحقل فريدة. إنّ القيمة الصفريّة في هذا الحقل تعني عدم الحاجة لإرسال إشعار تأكيد الوصول.
رقم إشعار تأكيد الوصول (Acknowledgment Number): وهو حقل بطول (32) بت، ويستخدم لحمل رقم تتابع لرزمة ما، يُراد تأكيدُ استقبالِها.
مُعرّف المُوجّه الافتراضي (Virtual Router Identifier VRID): بطول (16) بت، يُستخدم لتحديد عائلة العناوين المُستعملة. إنّ قيم الثوابت الخاصّة بهذا الحقل مُحددة في مواصفات البروتوكول.
رقم النظام المستقل (Autonomous System Number): بطول (16) بت، وهو رقم صحيح مُوجب يتراوح بين (1) و (65,535) يُمثّل مُعرّفاً للنظام الذي أُرسلت منه الرزمة. إنّ تطابق رقم النظام المُستقل في الرزمة مع رقم النظام المُستقل في راوترالذي يستقبلها هو شرطٌ أساسيّ لقبول الرسائل من أيّ جار، وإلا فسيتمّ التخلص من الرزمة.[68]
ثُلاثيّات (النوع-الطول-القيمة) (Type-Length-Value TLV): الثُلاثيّة هي عدد من البايتات مُختلفة الطول، مُقسّمة إلى ثلاثة حقول، هم حقل نوع الثُلاثيّة، وحقل طول الثُلاثيّة وحقل القيمة، الذي يختلف طوله بحسب الثُلاثيّة نفسِها، وهو يضمّ بدوره عدداً من الحقول المُختلفة التي تتعلق بنوع الثلاثُيّة. يُمكن أن تضمّ الرزمة أكثر من ثُلاثيّة مُختلفة في نفس الوقت.

تسمح الثُلاثيّات بإضافة إمكانيّات جديدة لبروتوكول التوجيه المُحسّن، أو لدعم ميّزات مُضافة غير موجودة حاليّاً،[69] ويتم ترميز نوع الثُلاثيّة بحسب الترميز التالي:

يُستخدم البايت الأول من حقل النوع لترميز البروتوكول المُوجّه:

عام (لجميع البروتوكولات المُوجّهة): (0x00).
الإصدار الرابع من بروتوكول الإنترنت (IPv4) يكون: (0x01).
الإصدار السادس من بروتوكول الإنترنت (IPv6) يكون: (0x04).

يُستخدم البايت الثاني من حقل النوع لترميز نوع الثلاثية من أجل البروتوكول الذي تم تحديده في البايت الأول:[70]

ثلاثية مُحددات: (0x01)
ثلاثية مُصادقة: (0x02)
ثلاثية إصدار البرمجية: (0x04)
ثلاثية تتابع البثّ المجموعاتيّ (0x05)

فيما يلي نماذج عن بعض الثلاثيات التي يستخدمها بروتوكول التوجيه المُحسن (EIGRP):[3]

ثُلاثيّة المحددات، وتستخدم في رسائل التعارف.
ثلاثية المُصادقة، تُضاف إلى رزم البروتوكول إذا تمّ تفعيل المصادقة.
ثُلاثيّة المسارات الداخلية للإصدار الرابع من بروتوكول الإنترنت (IPv4)، وتُستخدم في عملية إعادة التوزيع.
ثُلاثيّة المسارات الخارجيّة للإصدار الرابع من بروتوكول الإنترنت (IPv4)، وتُستخدم في عملية إعادة التوزيع.
ثُلاثيّة المسارات الداخليّة للإصدار السادس من بروتوكول الإنترنت (IPv6)، وتُستخدم في عملية إعادة التوزيع.
ثُلاثيّة المسارات الخارجيّة للإصدار السادس من بروتوكول الإنترنت (IPv4)، وتُستخدم في عملية إعادة التوزيع.

اكتشاف الجيران

مخطط التتابع لإنشاء علاقة الجيران بحسب بروتوكول التوجيه المُحسّن (EIGRP). تجري العملية بحسب الخطوات التالية: (1) يُرسل المُوجّه الأول رسالة تعارف على شكل رسالة بث مجموعاتي. (2) يرسل المُوجّه الثاني رسالة تعارف على شكل رسالة بثّ مجموعاتي. (3) يرسل المُوجّه الأول رسالة تحديث فارغة، مع رفع علم الابتداء. (4) يُرسل المُوجّه الثاني رسالة تحديث فارغة، مع رفع علم الابتداء، يُؤكّد فيها استقباله للرسالة في الخطوة الثالثة. (5) يُرسل المُوجّه الثاني كامل معلومات التوجيه، برسالة فريدة، يُؤكّد أيضاً استقباله للرسالة المُرسلة في الخطوة الرابعة. (6) يُرسل المُوجّه الأول كامل معلومات التوجيه، برسالة فريدة، ويُؤكّد أيضاً استقباله للرسالة المُرسلة في الخطوة الخامسة، لكن الرسالة تٌفقد في الشبكة. (7) بعد 5 ثواني، وبسبب عدم استقباله إشعار تأكيد الوصول، يُعيد الموجّه الثاني الخطوة الخامسة.(8) يستقبل المُوجّه الأول نفس الرسالة للمرة الثانية، فيتخلّص منها، ويعيد إرسال الرسالة في الخطوة السادسة.

تحصل عمليّة اكتشاف الجيران بين طرفين، هما موجّهان أو عُقدتان تُشغّلان بروتوكول التوجيه المُحسّن (EIGRP)، بعد تبادل رسائل التعارف، وكنتيجة لنجاح هذه العلاقة يقوم كل مُوجّه بإضافة الطرف الآخر إلى جدول الجيران الخاصّ به،[71] بعد ذلك تبدأ مرحلة تبادل معلومات التوجيه، ثُمّ يتمّ الحفاظ على علاقات الجيران فعّالة من خلال استمرار تبادل رسائل التعارف، إن غياب رسائل التعارف لفترة زمنيّة يُحددها مؤقت الانتظار يعني فشل علاقة الجيران.[72]

لتنجح علاقة الجيران، يجب أن تتطابق المُحددات التالية بين الطرفين:[73]

رقم النظام المستقل.
قيم مُعاملات حساب الوزن.
عناوين الشبكة، أي يجب أن يستضيف الطرفان عناوين تنتمي إلى نفس الشبكة، لكن يُستثنى هذا الشرط عندما يكون البروتوكول المُوجّه هو الإصدار السادس من بروتوكول الإنترنت (IPv6).[74]

قد تسبب بعض القضايا الأخرى عدم استقرارٍ في علاقة الجيران، مثل عدم تطابق وحدة النقل العظمى (MTU)، أو بسبب مشاكل تتعلّق بدعم البث الفردي أو البث المجموعاتيّ في الشبكة، أو مشاكل تتعلق بجودة الوصلة أو بفشل عملية مصادقة أو بسبب مشاكل ترتبط بالتهيئة.[75] إنّ عدم تطابق المُؤقّتات ليس شرطاً أساسيّاً لنجاح علاقة الجيران في بروتوكول التوجيه المُحسن، لكنّ الاختيار غير المدروس للقيم قد يسبب فشلاً أو عدم استقرار في علاقة الجيران.[52]

تبدأ العملية عندما يتمّ تشغيل البروتوكول في مُوجّه جديد مُتصل مع شبكة تحتوي موجه آخر يُشغل البروتوكول ويرسل رسائل التعارف فيها، لغرض تبسيط العملية، يُطلق على المُوجّه الجديد اسم الطرف الأول، وعلى الموجه الآخر اسم الطرف الثاني، وتتمّ عملية اكتشاف الجيران وفق الخطوات التالية:[3]

يُرسل الطرفان الأول والثاني رسائل تعارف دوريّة، بفواصل زمنيّة يُحددها مُؤقّت التعارف.
يستقبل كل من الطرفين رسالة التعارف التي أرسلها الطرف الآخر، ويعني ذلك اكتشاف الجار، ويتمّ التحقق من شروط إنشاء علاقة الجيران.
في حال تجاوز كل الشروط يتم إنشاء علاقة الجيران، وإلا فإنّ العملية تنتهي هاهنا.
يُرسل كل طرف، نحو الطرف الآخر، رسالة تحديث فريدة فارغة، مع رفع علم الابتداء.
يُرسل كل طرف رسالة تحديث، واحدة أو أكثر، تحتوي على كل معلومات التوجيه، ويؤكّد فيها أيضاً استقبال رسالة التحديث الفارغة السابقة.
يُؤكّد كل طرف استقبال كامل معلومات التوجيه من الطرف الآخر.
يُحافظ الطرفان على فعاليّة علاقة الجيران من خلال التبادل الدوريّ لرسائل التعارف.

يدعم بروتوكول التوجيه المُحسّن خاصية المنافذ السلبيّة (Passive Interface)، ويعني تفعيل هذه الخاصيّة على المنفذ استمرار تشغيل البروتوكول فيه، ولكن مع إيقاف إرسال أو استقبال رسائل التعارف، بالتالي منع تشكيل علاقات الجيران عبره. ولهذه الميزة استخدامات أمنيّة.[76][77]

بروتوكول النقل الموثوق

بروتوكول النقل الموثُوق (بالإنجليزية: Reliable Transport Protocol)‏ اختصاراً RTP، هو جزء من بروتوكول التوجيه المُحسّن، وهو المسؤول عن تأمين النقل الموثوق، من خلال اعتماده على حقلي رقم التتابع ورقم إشعار التأكيد الموجُودين في ترويسة البروتوكول.[78] لا يستطيع بروتوكول التوجيه المُحسّن الاستفادة من خدمات بروتوكولات طبقة النقل التي تقدّم هذه خدمة النقل الموثوق لأنّه يعمل في الطبقة التي تسبقُها، وهذا هو سبب اعتماده على بروتوكول مُستقل لإنجاز النقل الموثوق.[2]

يُحدد بروتوكول النقل الموثوق مجموعة القواعد التي تضمن وصول رزم البروتوكول بترتيب إرسالها إلى جميع الجيران، وهو يدعم البث الفردي والمجموعاتي. يتمّ وضع رقم تتابع خاص بكل رزمة يجري إرسالُها، ويجب على الجار أن يضع هذا الرقم في حقل رقم إشعار التأكيد في رسالة لاحقة لتأكيد الاستقبال، إذا أُرسلت رزمة موثوقة لبروتوكول التوجيه المُحسّن ولم يصل إشعار لتأكيد وصولها، فإنّ البروتوكول يقوم بإعادة إرسالها مرة أخرى نحو نفس الوجهة، ويتحدد زمن انتظار الردّ بمؤقّت خاص هو مؤقت إعادة الإرسال (Retransmission Timeout RTO)، الذي يتمّ حساب قيمته من أجل كل جار اعتماداً على زمن الجولة السلس (Smooth Round-Trip Time SRTT).[79]

خوارزمية نشر التحديثات

يستخدم بروتوكول التوجيه المُحسن خوارزمية خاصّة من تطوير معهد ستانفورد للأبحاث (SRI)، هي خوارزمية نشر التحديثات (Diffusing Update ALgorithm DUAL)،[14] تُستخدم هذه الخورازمية من أجل بناء المسارات الأقل وزناً نحو كل الوجهات المُتاحة، تتعامل هذه الخوارزمية مع الشبكة على أنها مُخطط بياني مُكوّن من عُقد ووصلات، وهي تضمن إيجاد مسارات خالية من الحلقات من كل عقدة نحو كل العُقد الأخرى، ويشمل ذلك فترات إعادة الحساب وعند حصول تغيّرات في الطوبولوجيا. باستعمال هذه الخوارزمية، يُنجز البروتوكول عملية إعادة حساب سريعة وخالية من الحلقات مع عدم وجود حاجة لتبادل كميّة كبيرة من المعلومات، وهي الأسرع في بعض الحالات مُقارنة ببروتوكولات التوجيه العاملة بخوازميّة حالة الوصلة.[80]

عند حصول تغيير في الطوبولوجيا، لا تقوم الخوارزميّة بإعادة الحساب في كل العقد التي تُشغّل البروتوكول، ولكن فقط في تلك التي تأثرت بالتغيير الحاصل، وتسمح هذه الميزة للبروتوكول بالتوسّع والعمل في شبكات كبيرة الحجم، وتقلل حجم المعلومات المُتبادلة في رسائل التحديث وتقلل أيضاً من تعقيد الحسابات اللازمة لإنجاز إعادة الحساب.

إنّ خوارزميات التوجيه المُوزّع، أي الخوارزميّات التي يتمّ فيها إجراء الحسابات بشكل مُوزّع ولامركزيّ، ضروريّة لنشر وتحديد وجهة المعلومات نحو جزء من كل عقد الشبكة. وهي بذلك تختلف عن خوارزمية بلمان فورد التي تعتمد على نشر المعلومات في كامل الشبكة، بدون أي تحديد، بعد حصول تغيير في طولولوجيا الشبكة. إنّ خوارزمية نشر التحديثات (DUAL)، وهي إحدى خوارزميات التوجيه المُوزّع.

وحدات البروتوكول غير المستقلة

وحدات البروتوكول غير المُستقلة (بالإنجليزية: Protocol Dependent Modules اختصاراً PDM)‏ هي المبدأ الذي يعتمده بروتوكول التوجيه المُحسن لدعم البروتوكولات المُوجّهة المُختلفة، إنّ وحدات البروتوكول غير المُستقلة مسؤولة عن المتطلّبات الخاصة ببروتوكولات طبقة الشبكة. بعبارة أخرى، من أجل كل بروتوكول مُوجّه، يقوم بروتوكول التوجيه المُحسّن ببناء جدول جيران وجدول طوبولوجيا، بحيث يتلائم كل جدول مع طبيعة ومُتطلبات العنونة الخاصّة بالبروتوكول المُوجّه، كما يضيف البروتوكول المسارات إلى جداول التوجيه الخاصّة بكل بروتوكول مُوجّه بشكلٍ مُنفصل.[13]

يسمح استخدام وحدات البروتوكول غير المُستقلة لبروتوكول التوجيه المُحسّن بالعمل مع مُختلف البروتوكولات المُوجّهة، تشرف كل وحدة بروتوكول غير مُسستقلة على الأعمال التالية:[81]

الحفاظ على جدولي جيران وطوبولوجيا من أجل بروتوكول مُوجّه مُحدد.
بناء الرزم الخاصّة ببروتوكول التوجيه المُحسّن بشكلٍ يتوافق مع مُتطلبات بروتوكول مُوجّه مُحدد.
الربط بين عمل خوارمية نشر التحديثات ^{[الإنجليزية]}.وجدول التوجيه الخاصّ ببروتوكول مُوجّه مُحدد. بعبارة أخرى، إضافة المسارات التي تختارها الخوارزميّة إلى جدول التوجيه بالشكل المُلائم.
حساب الأوزان وتمريرُها إلى خوارزميّة نشر التحديثات.
التعامل مع قوائم التحكّم بالوصول الخاصّة ببروتوكول مُوجّه مُحدد.
القيام بوظيفة إعادة التوزيع (redistribution) لمعلومات التوجيه مع بروتوكولات التوجيه الأُخرى.

توزيع الحمل من أجل المسارات غير المتساوية الأوزان

يمكن للموجه أن يحصل على معلومات التوجيه من أكثر من مصدر، كالتوجيه اليدوي، أو آليّاً عبر واحد أو أكثر من بروتوكولات التوجيه. في الحالة التي يتعرّف فيها المُوجّه على مسارين نحو نفس الوجهة، ولكن من مصدرين مختلفين، فإنّه يختار المسار صاحب الوزن الإشرافي الأقل ويضيفه إلى جدول التوجيه. في الحالة التي يتعرف فيها المُوجّه على مسارين مختلفين نحو نفس الوجهة، ولكن من مصدر واحد، أي في حالة تساوي الوزن الإشرافي، فإنّه يختار المسار صاحب الوزن الأدنى، ويتم تعريف الوزن في مُحددات البروتوكول. وفي حال تساوي الوزن الإشرافي ثم تساوي الوزن التقليدي، فإنّ هناك إمكانية لاستخدام كلا المسارين معاً، وتوزيع الحمل فيما بينهما، بدلاً من استخدام مسار واحد فقط، ويسمى ذلك توزيع الحمل بين المسارات متساوية الأوزان، وهي ميزة يدعمها بروتوكول التوجيه المُحسّن.[82]

يدعم بروتوكول التوجيه المُحسن أيضاً نوعاً آخر من توزيع الحمل، وهو توزيع الحمل بين المسارات غير مُتساوية الأوزان، وفي هذه الحالة فإنّ هناك إمكانية لتحديد مجال من الأوزان يلي وزن أفضل مسار، وإذ كانت قيمة أي مسار آخر اكتشفه البروتوكول نحو نفس الوجهة ضمن هذا المجال، فسيتمّ توزيع العمل بينه وبين المسار الرئيسي.[83]

لتحقيق ذلك تُستخدم قيمة عدديّة تُسمى عامل التنوع (Variance)، ويكون المجال الخاص بقيم الأوزان المقبولة مُمتداً بين قيمة أفضل وزن وقيمة جداء عامل التنوع معه. إنّ القيمة الافتراضية لعامل التنوع هي (1)، ويُمكن أي يتمّ ضبطه إلى أي قيمة صحيحة من المجال [128,1].[84] على سبيل المثال، إذا اكتشف البروتوكول (3) مسارات نحو شبكة ما، وكانت أوزان هذه المسارات هي بالترتيب: (25) و(80) و(110). إنّ أفضل مسار هو المسار صاحب الوزن الأدنى وهو المسار ذو الوزن (25). ستجعل اختيار قيمة عامل التنوع لتكون (4)، أكبر قيمة في مجال القيم المقبولة هي (25x4 =100) وسيكون مجال القيم هو [100,25]، إنّ وزن المسار الثاني يقع ضمن هذا المجال، وسيتم بالتالي توزيع الحمل بين المسارين صاحبي الوزنين (25) و (80) على الترتيب.

المصادقة

تستخدم المُصادقة من قبل بروتوكول التوجيه المُحسّن بصفتها خياراً أمنيّاً، والسبب الرئيس من استخدامها هو حماية البروتوكول من استقبال رسائل تحديث من مصادر غير موثوقة، وتسمح هذه الميزة بالتحقق من هوية الطرف الذي يريد إنشاء علاقة الجيران،[85] بدون استخدام المُصادقة من الممكن أن يتمّ العبث بمحتويات جدول التوجيه من خلال تعريف المُوجّه بمسارات غير صحيحة بهدف توجيه حركة البيانات نحو موقع مُعيّن، إمّا لحجب الخدمة[86] أو للإطلاع على محتواها ثُمّ إعادة إرسالها إلى هدفها.

يدعم بروتوكول التوجيه المُحسّن خوارزمية هضم الرسالة الخامسة (MD5) من أجل إنجاز عملية المُصادقة، ولنجاح العملية يجب تزويد الموجه بسلسلة من المفاتيح لتُستخدم في عملية هضم الرسالة،[87] يتطلب نجاح تهيئة المصادقة تزامن المُوجّهات على ساعة واحدة، كما يجب الانتباه إلى أن تهيئة المُصادقة على أحد المُوجّهات دون البقية سيسبب فشلاً في علاقة الجيران لحين إتمام تهيئة المصادقة في بقية الشبكة.[88]

انظر أيضًا

المراجع

Boyle, J. (1994)، "EIGRP - A FAST ROUTING PROTOCOL BASED ON DISTANCE VECTORS"، The Pennsylvania State University (باللغة الإنجليزية)، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 26 ديسمبر 2017.
"Routing protocols operate at what OSI layers?"، Cisco Systems Inc. (باللغة الإنجليزية)، 19 يونيو 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.
Savag, D.؛ Ng؛ Moore؛ Slice؛ Paluch (مايو 2016)، "RFC 7868, Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)"، The Internet Society (باللغة الإنجليزية)، ISSN 2070-1721، مؤرشف من الأصل في 14 أبريل 2020، اطلع عليه بتاريخ 21 ديسمبر 2017.
ميشيل بكني (2022)، ساندرا هانبو (المحرر)، برُوتُوكُول الإِنترنِت: الإِصداران الرَّابِع والسَّادِس، أورتيز: مطبعة إيسن، ص. 357، doi:10.6084/M9.FIGSHARE.19326086، ISBN 978-2-9576887-1-5، ويكي بيانات Q111284802.
"التعريفات الأمنية"، المركز الوطني للسلامة المعلوماتية، مؤرشف من الأصل في 26 ديسمبر 2017، اطلع عليه بتاريخ 1 يناير 2018.
"Enhanced Interior Gateway Routing Protocol (EIGRP) Informational RFC Frequently Asked Questions"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 24 ديسمبر 2017.
Postel, J. (سبتمبر 1981)، "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 6 أغسطس 2019، اطلع عليه بتاريخ 13 يوليو2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (مساعدة)
Deering, S.؛ Hinden (يوليو 2017)، "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 30 أغسطس 2020، اطلع عليه بتاريخ 31 يوليو 2017.
XSIS 028112, Internet Transport Protocols (باللغة الإنجليزية)، Xerox Corporation، 1981.
"IPv4 Multicast Address Space Registry"، IANA (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 20 ديسمبر 2017.
"IPv6 Multicast Address Space Registry"، IANA (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 20 ديسمبر 2017.
"Routing Protocol Selection Guide - IGRP, EIGRP, OSPF, IS-IS, BGP"، Cisco Systems Inc. (باللغة الإنجليزية)، 27 فبراير 2013، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.
Leahy, Eric (4 سبتمبر 2011)، "EIGRP – History"، Eric Leahy (باللغة الإنجليزية)، مؤرشف من الأصل في 8 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.
Garcia-Lunes-Aceves, J. J. (فبراير 1993)، "Loop-free routing using diffusing computations"، IEEE/ACM Transactions on Networking، IEEE Press، 1 (1): 130-141، doi:10.1109/90.222913.
Adler, Saul (11 مارس 2013)، "Cisco Opens Up EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 22 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.
Savage؛ Slice؛ Ng؛ Moore؛ White (18 فبراير 2013)، "Enhanced Interior Gateway Routing Protocol draft-savage-eigrp-00.txt"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (مساعدة)
Savage؛ Slice؛ Ng؛ Moore؛ White؛ Paluch (23 فبراير 2016)، "Cisco Enhanced Interior Gateway Routing Protocol draft-savage-eigrp-05.txt"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 15 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.
"EIGRP Properties as Distance Vector & Link State?"، Cisco Systems Inc. (باللغة الإنجليزية)، 13 نوفمبر 2011، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 18 ديسمبر 2017.
"Cisco Networking Academy's Introduction to Routing Dynamically"، Cisco Systems Inc. (باللغة الإنجليزية)، 24 مارس 2014، مؤرشف من الأصل في 15 ديسمبر 2017، اطلع عليه بتاريخ 18 ديسمبر 2017.
"Is EIGRP a Hybrid Routing Protocol or Advanced Distance Vector Routing Protocol?"، RedNectar's Blog (باللغة الإنجليزية)، 28 أغسطس 2013، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 18 ديسمبر 2017.
"EIGRP Feasibility Condition, oh and RD and FD"، Cisco Systems Inc. (باللغة الإنجليزية)، 4 ديسمبر 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.
"CCNP ROUTE (Part 6 EIGRP Terminology in Diagrams)"، DEVILWAH's BLOG (باللغة الإنجليزية)، 7 أوكتوبر 2010، مؤرشف من الأصل في 6 نوفمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (مساعدة)
"Configuring the Enhanced Interior Gateway Routing Protocol"، Packet life (باللغة الإنجليزية)، 9 أغسطس 2010، مؤرشف من الأصل في 24 ديسمبر 2006، اطلع عليه بتاريخ 26 ديسمبر 2017.
"EIGRP Feasibility Condition"، Practical Networking.net (باللغة الإنجليزية)، 11 أبريل 2016، مؤرشف من الأصل في 21 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
"Protocol Numbers"، IANA (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 20 ديسمبر 2017.
"Demystifying EIGRP message types with Wireshark"، Jesin's Blog (باللغة الإنجليزية)، 25 يونيو 2013، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
"Introduction to EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 28 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
"IP Routing: EIGRP Configuration Guide, Cisco IOS XE Release 3S, Chapter: EIGRP Wide Metrics"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 25 ديسمبر 2017.
"Enhanced Interior Gateway Routing Protocol (EIGRP) Wide Metrics White Paper"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 23 ديسمبر 2017، اطلع عليه بتاريخ 25 ديسمبر 2017.
"EIGRP Metric notes"، blogspot (باللغة الإنجليزية)، 29 أغسطس 2015، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 25 ديسمبر 2017.
Christoph Neulinger (15 ديسمبر 2009)، "Metric Calculation in EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 10 يناير 2020، اطلع عليه بتاريخ 25 ديسمبر 2017.
"Regarding EIGRP 'K' Values"، Cisco Systems Inc. (باللغة الإنجليزية)، 11 أبريل 2015، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 22 ديسمبر 2017.
"Cisco IOS IP Routing: EIGRP Command Reference"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 22 ديسمبر 2017.
"EIGRP K -value mismatch issue"، Cisco Systems Inc. (باللغة الإنجليزية)، 3 يونيو 2015، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 22 ديسمبر 2017.
Kevin Dooley؛ Ian Brown (2007)، Cisco IOS Cookbook (باللغة الإنجليزية)، O'Reilly Media, Inc، ص. 267، ISBN 0596527225.
"EIGRP Wide Metrics" (PDF)، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل (PDF) في غير معروف، اطلع عليه بتاريخ 22 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ أرشيف= (مساعدة)
Astorino, Joe (3 مارس 2010)، "EIGRP Metric & K-Values"، IPexpert Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 17 مارس 2014، اطلع عليه بتاريخ 27 ديسمبر 2017.
kamlesh, Sharma (25 ديسمبر 2005)، "EIGRP load and reliability"، Cisco Systems, Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 27 ديسمبر 2017.
Diane Teare, Bob Vachon, Rick Graziani (2015)، Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101) (باللغة الإنجليزية) (ط. الأولى)، Cisco Press، ص. 89، ISBN 1587204568، مؤرشف من الأصل في 30 يونيو 2019.{{استشهاد بكتاب}}: صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)
"MTU in EIGRP metric?"، Cisco Systems Inc. (باللغة الإنجليزية)، 10 مارس 2006، مؤرشف من الأصل في 21 ديسمبر 2017، اطلع عليه بتاريخ 23 ديسمبر 2017.
Brad Edgeworth, Aaron Foss, Ramiro Garza Rios (2014)، IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols (باللغة الإنجليزية) (ط. الأولى)، Cisco Press، ص. 154، ISBN 1587144239، مؤرشف من الأصل في 30 يونيو 2019.{{استشهاد بكتاب}}: صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)
"Small Enterprise Design Profile Reference Guide"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 1 يناير 2018.
"Configuring the Enhanced Interior Gateway Routing Protocol"، Cisco Press (باللغة الإنجليزية)، 25 ديسمبر 2006، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.
Michael J. Shannon (2004)، CCNP Exams: Exams 642-801, 642-811, 642-821, 642-831 (باللغة الإنجليزية)، Que Publishing، ص. 171، ISBN 0789730170.
Wendell Odom (2010)، CCNP Route 642-902 Official Certification Guide (باللغة الإنجليزية)، Cisco Press، ص. 60، ISBN 1587202530.
Stephen McQuerry. (11 يناير 2008)، "Implementing EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.
"Building the EIGRP Topology Table"، networkrange word press blog (باللغة الإنجليزية)، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 26 ديسمبر 2017.
Jeremy Stretch (3 نوفمبر 2008)، "Disabling split horizon"، Packet life (باللغة الإنجليزية)، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
"why split horizon needed in EIGRP?"، Cisco System Inc. (باللغة الإنجليزية)، 3 نوفمبر 2008، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 29 ديسمبر 2017.
Wael Osama (8 أغسطس 2008)، "EIGRP timers (hello, hold and active)"، Networkers-online (باللغة الإنجليزية)، مؤرشف من الأصل في 29 ديسمبر 2017، اطلع عليه بتاريخ 30 ديسمبر 2017.
Jeremy Stretch (14 مايو 2008)، "Hello timer behaviors"، packet life (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 30 ديسمبر 2017.
"EIGRP Neighborship"، Cisco System Inc. (باللغة الإنجليزية)، 31 مارس 2012، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.
"Eigrp holdtime"، Cisco System Inc. (باللغة الإنجليزية)، 6 أوكتوبر 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 30 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (مساعدة)
Kevin Dorrell (25 مايو 2008)، "EIGRP Timers – Solution"، Word press blog (باللغة الإنجليزية)، مؤرشف من الأصل في 24 ديسمبر 2017، اطلع عليه بتاريخ 30 ديسمبر 2017.
Anthony Bruno, Jacqueline Kim. (12 ديسمبر 2003)، "CCDA Self-Study: RIP, IGRP, and EIGRP Characteristics and Design"، Overblog (باللغة الإنجليزية)، مؤرشف من الأصل في 15 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.
"Chapter: EIGRP Commands"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 26 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
"Cisco Eigrp Timers"، Overblog (باللغة الإنجليزية)، 23 فبراير 2014، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017. {{استشهاد ويب}}: الوسيط غير المعروف |مسار أرشيف http://webcache.googleusercontent.com/search?q= تم تجاهله (مساعدة)
Michael J. Shannon (2004)، CCNP Exams: Exams 642-801, 642-811, 642-821, 642-831 (باللغة الإنجليزية)، Que Publishing، ص. 169، ISBN 0789730170.
Brad Hedlund، "Notes on EIGRP"، BradHedlund.com (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.^{[وصلة مكسورة]}
"EIGRP ACTIVE AND PASSIVE"، Cisco System Inc. (باللغة الإنجليزية)، 1 يونيو 2011، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 29 ديسمبر 2017.
Lance Cockcroft (24 يوليو 2001)، "Understanding the protocols underlying dynamic routing"، CBS Interactive. (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.
John Tiso (8 ديسمبر 2011)، "Designing Cisco Network Service Architectures (ARCH): Developing an Optimum Design for Layer 3 (CCDP)"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.
"Bidirectional Forwarding Detection for EIGRP"، Cisco System Inc. (باللغة الإنجليزية)، 2005، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.
Sankar, D.؛ Lancaster (2013)، "Routing Protocol Convergence Comparison using Simulation and Real Equipment"، Advances in Communications, Computing, Networks and Security، University of Plymouth Press، 10: 186-194، ISBN 1841023582، مؤرشف من الأصل في 22 مايو 2018.
Yap Chin Hoong (2010)، "Chapter 5 EIGRP" (PDF)، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل (PDF) في غير معروف، اطلع عليه بتاريخ 24 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ أرشيف= (مساعدة)
"debug eigrp packets! meaning of flags???"، Cisco Systems Inc. (باللغة الإنجليزية)، 27 نوفمبر 2012، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.
"EIGRP Init Flag"، Cisco Systems Inc. (باللغة الإنجليزية)، 16 يوليو 2003، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.
"EIGRP neighbors with different AS numbers"، Cisco Systems Inc. (باللغة الإنجليزية)، 9 يناير 2015، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 21 ديسمبر 2017.
"EIGRP-TLV vs. Header Fields"، Cisco Systems Inc. (باللغة الإنجليزية)، 25 مايو 2009، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 21 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (مساعدة)
Kashyap, Ravi (25 مايو 2009)، "EIGRP Packet Format"، Blogspot (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 1 يناير 2018.
"EIGRP Neighborship Requirements And Conditions"، Computer Networking Basic Tutorials and Study Guides (باللغة الإنجليزية)، 10 مايو 2016، مؤرشف من الأصل في 24 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.
Wallace, Kevin (9 يناير 2017)، "Understanding EIGRP – Part 3 (EIGRP Timers)"، Kevin Wallace Training, LLC (باللغة الإنجليزية)، مؤرشف من الأصل في 23 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.
Zaheer Aziz, Johnson Lui, Abe Martey, Faraz Shamim. (26 يوليو 2002)، "Troubleshooting EIGRP"، Cisco Systems, Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 24 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.{{استشهاد ويب}}: صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)
"EIGRP IPv6 Configuration Example"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.
"Troubleshoot Common EIGRP Issues"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.
"Passive-interface EIGRP command"، Cisco System Inc. (باللغة الإنجليزية)، 21 يونيو 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 29 ديسمبر 2017.
"How Does the Passive Interface Feature Work in EIGRP?"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
Stretch, Jeremy (17 يناير 2009)، "RTP in EIGRP"، Packet life (باللغة الإنجليزية)، مؤرشف من الأصل في 22 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017. {{استشهاد ويب}}: الوسيط غير المعروف |http://webcache.googleusercontent.com/search?q= تم تجاهله (مساعدة)
"Reliable Transport Protocol"، Blogspot (باللغة الإنجليزية)، مؤرشف من الأصل في 31 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.
"Small Enterprise Design Profile Reference Guide"، Cisco Systems Inc. (باللغة الإنجليزية)، 28 يوليو 2010، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 2 يناير 2018.
"Protocol-Dependent Modules in EIGRP"، Cisco System Inc. (باللغة الإنجليزية)، 8 مايو 2016، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 30 ديسمبر 2017.
"How Does Load Balancing Work?"، Cisco sytems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 18 ديسمبر 2017، اطلع عليه بتاريخ 19 ديسمبر 2017.
Lapukhov, Petr (1 مايو 2011)، "Understanding Unequal-Cost Load-Balancing"، INE, Inc (باللغة الإنجليزية)، مؤرشف من الأصل في 22 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.
"How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?"، Cisco sytems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 18 ديسمبر 2017، اطلع عليه بتاريخ 19 ديسمبر 2017.
"Configuring EIGRP Authentication"، Cisco Systems Inc. (باللغة الإنجليزية)، 25 ديسمبر 2006، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
McDowell, Mindi (2009)، "Security Tip (ST04-015), Understanding Denial-of-Service Attacks"، United States Coomputer Emergency Readiness Team (US-CERT) (باللغة الإنجليزية)، مؤرشف من الأصل في 22 مايو 2019، اطلع عليه بتاريخ 31 يوليو 2017.{{استشهاد ويب}}: صيانة CS1: التاريخ والسنة (link)
"Configuring EIGRP Authenticatio"، Cisco Systems Inc. (باللغة الإنجليزية)، 22 يونيو 2009، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.
"EIGRP Message Authentication Configuration Example"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

وصلات خارجية

مدخل إلى بروتوكول التوجيه المُحسن (EIGRP)، مقالة من فريق الدعم التقني في شركة سيسكو.
عرض تقديمي عن الميزات المتقدمة في بروتوكول التوجيه المُحسّن.
التعرّف على بروتوكول التوجيه المُحسّن (EIGRP)، مجموعة مقالات (1،2،3) بقلم كيفن والاس.

بوابة إنترنت
بوابة اتصال عن بعد
بوابة تقنية المعلومات

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

[Web-31-1] Boyle, J. (1994)، "EIGRP - A FAST ROUTING PROTOCOL BASED ON DISTANCE VECTORS"، The Pennsylvania State University (باللغة الإنجليزية)، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 26 ديسمبر 2017.

[Web-41-2] "Routing protocols operate at what OSI layers?"، Cisco Systems Inc. (باللغة الإنجليزية)، 19 يونيو 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.

[ietf-1-3] Savag, D.؛ Ng؛ Moore؛ Slice؛ Paluch (مايو 2016)، "RFC 7868, Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)"، The Internet Society (باللغة الإنجليزية)، ISSN 2070-1721، مؤرشف من الأصل في 14 أبريل 2020، اطلع عليه بتاريخ 21 ديسمبر 2017.

[4] ميشيل بكني (2022)، ساندرا هانبو (المحرر)، برُوتُوكُول الإِنترنِت: الإِصداران الرَّابِع والسَّادِس، أورتيز: مطبعة إيسن، ص. 357، doi:10.6084/M9.FIGSHARE.19326086، ISBN 978-2-9576887-1-5، ويكي بيانات Q111284802.

[Web-74-5] "التعريفات الأمنية"، المركز الوطني للسلامة المعلوماتية، مؤرشف من الأصل في 26 ديسمبر 2017، اطلع عليه بتاريخ 1 يناير 2018.

[Web-15-6] "Enhanced Interior Gateway Routing Protocol (EIGRP) Informational RFC Frequently Asked Questions"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 24 ديسمبر 2017.

[ietf-4-7] Postel, J. (سبتمبر 1981)، "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 6 أغسطس 2019، اطلع عليه بتاريخ 13 يوليو2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (مساعدة)

[ietf-5-8] Deering, S.؛ Hinden (يوليو 2017)، "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 30 أغسطس 2020، اطلع عليه بتاريخ 31 يوليو 2017.

[Book3-9] XSIS 028112, Internet Transport Protocols (باللغة الإنجليزية)، Xerox Corporation، 1981.

[Web-6-10] "IPv4 Multicast Address Space Registry"، IANA (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 20 ديسمبر 2017.

[Web-7-11] "IPv6 Multicast Address Space Registry"، IANA (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 20 ديسمبر 2017.

[Web-42-12] "Routing Protocol Selection Guide - IGRP, EIGRP, OSPF, IS-IS, BGP"، Cisco Systems Inc. (باللغة الإنجليزية)، 27 فبراير 2013، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-30-13] Leahy, Eric (4 سبتمبر 2011)، "EIGRP – History"، Eric Leahy (باللغة الإنجليزية)، مؤرشف من الأصل في 8 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.

[JOU-1-14] Garcia-Lunes-Aceves, J. J. (فبراير 1993)، "Loop-free routing using diffusing computations"، IEEE/ACM Transactions on Networking، IEEE Press، 1 (1): 130-141، doi:10.1109/90.222913.

[Web-29-15] Adler, Saul (11 مارس 2013)، "Cisco Opens Up EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 22 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.

[ietf-2-16] Savage؛ Slice؛ Ng؛ Moore؛ White (18 فبراير 2013)، "Enhanced Interior Gateway Routing Protocol draft-savage-eigrp-00.txt"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (مساعدة)

[ietf-3-17] Savage؛ Slice؛ Ng؛ Moore؛ White؛ Paluch (23 فبراير 2016)، "Cisco Enhanced Interior Gateway Routing Protocol draft-savage-eigrp-05.txt"، The Internet Society (باللغة الإنجليزية)، مؤرشف من الأصل في 15 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.

[Web-1-18] "EIGRP Properties as Distance Vector & Link State?"، Cisco Systems Inc. (باللغة الإنجليزية)، 13 نوفمبر 2011، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 18 ديسمبر 2017.

[Web-2-19] "Cisco Networking Academy's Introduction to Routing Dynamically"، Cisco Systems Inc. (باللغة الإنجليزية)، 24 مارس 2014، مؤرشف من الأصل في 15 ديسمبر 2017، اطلع عليه بتاريخ 18 ديسمبر 2017.

[Web-3-20] "Is EIGRP a Hybrid Routing Protocol or Advanced Distance Vector Routing Protocol?"، RedNectar's Blog (باللغة الإنجليزية)، 28 أغسطس 2013، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 18 ديسمبر 2017.

[Web-45-21] "EIGRP Feasibility Condition, oh and RD and FD"، Cisco Systems Inc. (باللغة الإنجليزية)، 4 ديسمبر 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-46-22] "CCNP ROUTE (Part 6 EIGRP Terminology in Diagrams)"، DEVILWAH's BLOG (باللغة الإنجليزية)، 7 أوكتوبر 2010، مؤرشف من الأصل في 6 نوفمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (مساعدة)

[Web-25-23] "Configuring the Enhanced Interior Gateway Routing Protocol"، Packet life (باللغة الإنجليزية)، 9 أغسطس 2010، مؤرشف من الأصل في 24 ديسمبر 2006، اطلع عليه بتاريخ 26 ديسمبر 2017.

[Web-49-24] "EIGRP Feasibility Condition"، Practical Networking.net (باللغة الإنجليزية)، 11 أبريل 2016، مؤرشف من الأصل في 21 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-8-25] "Protocol Numbers"، IANA (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 20 ديسمبر 2017.

[Web-48-26] "Demystifying EIGRP message types with Wireshark"، Jesin's Blog (باللغة الإنجليزية)، 25 يونيو 2013، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-47-27] "Introduction to EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 28 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-18-28] "IP Routing: EIGRP Configuration Guide, Cisco IOS XE Release 3S, Chapter: EIGRP Wide Metrics"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 25 ديسمبر 2017.

[Web-19-29] "Enhanced Interior Gateway Routing Protocol (EIGRP) Wide Metrics White Paper"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 23 ديسمبر 2017، اطلع عليه بتاريخ 25 ديسمبر 2017.

[Web-20-30] "EIGRP Metric notes"، blogspot (باللغة الإنجليزية)، 29 أغسطس 2015، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 25 ديسمبر 2017.

[Web-17-31] Christoph Neulinger (15 ديسمبر 2009)، "Metric Calculation in EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 10 يناير 2020، اطلع عليه بتاريخ 25 ديسمبر 2017.

[Web-10-32] "Regarding EIGRP 'K' Values"، Cisco Systems Inc. (باللغة الإنجليزية)، 11 أبريل 2015، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 22 ديسمبر 2017.

[Web-12-33] "Cisco IOS IP Routing: EIGRP Command Reference"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 19 ديسمبر 2017، اطلع عليه بتاريخ 22 ديسمبر 2017.

[Web-11-34] "EIGRP K -value mismatch issue"، Cisco Systems Inc. (باللغة الإنجليزية)، 3 يونيو 2015، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 22 ديسمبر 2017.

[Book-1-35] Kevin Dooley؛ Ian Brown (2007)، Cisco IOS Cookbook (باللغة الإنجليزية)، O'Reilly Media, Inc، ص. 267، ISBN 0596527225.

[Web-13-36] "EIGRP Wide Metrics" (PDF)، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل (PDF) في غير معروف، اطلع عليه بتاريخ 22 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ أرشيف= (مساعدة)

[Web-32-37] Astorino, Joe (3 مارس 2010)، "EIGRP Metric & K-Values"، IPexpert Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 17 مارس 2014، اطلع عليه بتاريخ 27 ديسمبر 2017.

[Web-33-38] sh, Sharma (25 ديسمبر 2005)، "EIGRP load and reliability"، Cisco Systems, Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 27 ديسمبر 2017.

[Book-5-39] Diane Teare, Bob Vachon, Rick Graziani (2015)، Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101) (باللغة الإنجليزية) (ط. الأولى)، Cisco Press، ص. 89، ISBN 1587204568، مؤرشف من الأصل في 30 يونيو 2019.{{استشهاد بكتاب}}: صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)

[Web-14-40] "MTU in EIGRP metric?"، Cisco Systems Inc. (باللغة الإنجليزية)، 10 مارس 2006، مؤرشف من الأصل في 21 ديسمبر 2017، اطلع عليه بتاريخ 23 ديسمبر 2017.

[Book-4-41] Brad Edgeworth, Aaron Foss, Ramiro Garza Rios (2014)، IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols (باللغة الإنجليزية) (ط. الأولى)، Cisco Press، ص. 154، ISBN 1587144239، مؤرشف من الأصل في 30 يونيو 2019.{{استشهاد بكتاب}}: صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)

[Web-77-42] "Small Enterprise Design Profile Reference Guide"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 1 يناير 2018.

[Web-24-43] "Configuring the Enhanced Interior Gateway Routing Protocol"، Cisco Press (باللغة الإنجليزية)، 25 ديسمبر 2006، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.

[Book-3-44] Michael J. Shannon (2004)، CCNP Exams: Exams 642-801, 642-811, 642-821, 642-831 (باللغة الإنجليزية)، Que Publishing، ص. 171، ISBN 0789730170.

[Book-2-45] Wendell Odom (2010)، CCNP Route 642-902 Official Certification Guide (باللغة الإنجليزية)، Cisco Press، ص. 60، ISBN 1587202530.

[Web-40-46] Stephen McQuerry. (11 يناير 2008)، "Implementing EIGRP"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-26-47] "Building the EIGRP Topology Table"، networkrange word press blog (باللغة الإنجليزية)، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 26 ديسمبر 2017.

[Web-54-48] Jeremy Stretch (3 نوفمبر 2008)، "Disabling split horizon"، Packet life (باللغة الإنجليزية)، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-53-49] "why split horizon needed in EIGRP?"، Cisco System Inc. (باللغة الإنجليزية)، 3 نوفمبر 2008، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-61-50] Wael Osama (8 أغسطس 2008)، "EIGRP timers (hello, hold and active)"، Networkers-online (باللغة الإنجليزية)، مؤرشف من الأصل في 29 ديسمبر 2017، اطلع عليه بتاريخ 30 ديسمبر 2017.

[Web-62-51] Jeremy Stretch (14 مايو 2008)، "Hello timer behaviors"، packet life (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 30 ديسمبر 2017.

[Web-37-52] "EIGRP Neighborship"، Cisco System Inc. (باللغة الإنجليزية)، 31 مارس 2012، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-64-53] "Eigrp holdtime"، Cisco System Inc. (باللغة الإنجليزية)، 6 أوكتوبر 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 30 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (مساعدة)

[Web-63-54] Kevin Dorrell (25 مايو 2008)، "EIGRP Timers – Solution"، Word press blog (باللغة الإنجليزية)، مؤرشف من الأصل في 24 ديسمبر 2017، اطلع عليه بتاريخ 30 ديسمبر 2017.

[Web-66-55] Anthony Bruno, Jacqueline Kim. (12 ديسمبر 2003)، "CCDA Self-Study: RIP, IGRP, and EIGRP Characteristics and Design"، Overblog (باللغة الإنجليزية)، مؤرشف من الأصل في 15 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.

[Web-57-56] "Chapter: EIGRP Commands"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 26 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-65-57] "Cisco Eigrp Timers"، Overblog (باللغة الإنجليزية)، 23 فبراير 2014، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017. {{استشهاد ويب}}: الوسيط غير المعروف |مسار أرشيف http://webcache.googleusercontent.com/search?q= تم تجاهله (مساعدة)

[Book-6-58] Michael J. Shannon (2004)، CCNP Exams: Exams 642-801, 642-811, 642-821, 642-831 (باللغة الإنجليزية)، Que Publishing، ص. 169، ISBN 0789730170.

[Web-58-59] Brad Hedlund، "Notes on EIGRP"، BradHedlund.com (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.^{[وصلة مكسورة]}

[Web-59-60] "EIGRP ACTIVE AND PASSIVE"، Cisco System Inc. (باللغة الإنجليزية)، 1 يونيو 2011، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-72-61] Lance Cockcroft (24 يوليو 2001)، "Understanding the protocols underlying dynamic routing"، CBS Interactive. (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.

[Web-71-62] John Tiso (8 ديسمبر 2011)، "Designing Cisco Network Service Architectures (ARCH): Developing an Optimum Design for Layer 3 (CCDP)"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.

[Web-70-63] "Bidirectional Forwarding Detection for EIGRP"، Cisco System Inc. (باللغة الإنجليزية)، 2005، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.

[JOU-2-64] Sankar, D.؛ Lancaster (2013)، "Routing Protocol Convergence Comparison using Simulation and Real Equipment"، Advances in Communications, Computing, Networks and Security، University of Plymouth Press، 10: 186-194، ISBN 1841023582، مؤرشف من الأصل في 22 مايو 2018.

[Web-16-65] Yap Chin Hoong (2010)، "Chapter 5 EIGRP" (PDF)، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل (PDF) في غير معروف، اطلع عليه بتاريخ 24 ديسمبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ أرشيف= (مساعدة)

[Web-43-66] "debug eigrp packets! meaning of flags???"، Cisco Systems Inc. (باللغة الإنجليزية)، 27 نوفمبر 2012، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-44-67] "EIGRP Init Flag"، Cisco Systems Inc. (باللغة الإنجليزية)، 16 يوليو 2003، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-9-68] "EIGRP neighbors with different AS numbers"، Cisco Systems Inc. (باللغة الإنجليزية)، 9 يناير 2015، مؤرشف من الأصل في 20 ديسمبر 2017، اطلع عليه بتاريخ 21 ديسمبر 2017.

[Web-75-69] "EIGRP-TLV vs. Header Fields"، Cisco Systems Inc. (باللغة الإنجليزية)، 25 مايو 2009، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 21 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (مساعدة)

[Web-76-70] Kashyap, Ravi (25 مايو 2009)، "EIGRP Packet Format"، Blogspot (باللغة الإنجليزية)، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 1 يناير 2018.

[Web-36-71] "EIGRP Neighborship Requirements And Conditions"، Computer Networking Basic Tutorials and Study Guides (باللغة الإنجليزية)، 10 مايو 2016، مؤرشف من الأصل في 24 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-38-72] Wallace, Kevin (9 يناير 2017)، "Understanding EIGRP – Part 3 (EIGRP Timers)"، Kevin Wallace Training, LLC (باللغة الإنجليزية)، مؤرشف من الأصل في 23 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-34-73] Zaheer Aziz, Johnson Lui, Abe Martey, Faraz Shamim. (26 يوليو 2002)، "Troubleshooting EIGRP"، Cisco Systems, Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 24 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.{{استشهاد ويب}}: صيانة CS1: أسماء متعددة: قائمة المؤلفون (link)

[Web-39-74] "EIGRP IPv6 Configuration Example"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 25 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-35-75] "Troubleshoot Common EIGRP Issues"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 28 ديسمبر 2017.

[Web-55-76] "Passive-interface EIGRP command"، Cisco System Inc. (باللغة الإنجليزية)، 21 يونيو 2010، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-56-77] "How Does the Passive Interface Feature Work in EIGRP?"، Cisco System Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-28-78] Stretch, Jeremy (17 يناير 2009)، "RTP in EIGRP"، Packet life (باللغة الإنجليزية)، مؤرشف من الأصل في 22 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017. {{استشهاد ويب}}: الوسيط غير المعروف |http://webcache.googleusercontent.com/search?q= تم تجاهله (مساعدة)

[Web-73-79] "Reliable Transport Protocol"، Blogspot (باللغة الإنجليزية)، مؤرشف من الأصل في 31 ديسمبر 2017، اطلع عليه بتاريخ 31 ديسمبر 2017.

[Web-78-80] "Small Enterprise Design Profile Reference Guide"، Cisco Systems Inc. (باللغة الإنجليزية)، 28 يوليو 2010، مؤرشف من الأصل في 30 ديسمبر 2017، اطلع عليه بتاريخ 2 يناير 2018.

[Web-60-81] "Protocol-Dependent Modules in EIGRP"، Cisco System Inc. (باللغة الإنجليزية)، 8 مايو 2016، مؤرشف من الأصل في 22 مايو 2018، اطلع عليه بتاريخ 30 ديسمبر 2017.

[Web-4-82] "How Does Load Balancing Work?"، Cisco sytems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 18 ديسمبر 2017، اطلع عليه بتاريخ 19 ديسمبر 2017.

[Web-27-83] Lapukhov, Petr (1 مايو 2011)، "Understanding Unequal-Cost Load-Balancing"، INE, Inc (باللغة الإنجليزية)، مؤرشف من الأصل في 22 ديسمبر 2017، اطلع عليه بتاريخ 26 ديسمبر 2017.

[Web-5-84] "How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?"، Cisco sytems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 18 ديسمبر 2017، اطلع عليه بتاريخ 19 ديسمبر 2017.

[Web-52-85] "Configuring EIGRP Authentication"، Cisco Systems Inc. (باللغة الإنجليزية)، 25 ديسمبر 2006، مؤرشف من الأصل في 14 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[US-CERT-86] McDowell, Mindi (2009)، "Security Tip (ST04-015), Understanding Denial-of-Service Attacks"، United States Coomputer Emergency Readiness Team (US-CERT) (باللغة الإنجليزية)، مؤرشف من الأصل في 22 مايو 2019، اطلع عليه بتاريخ 31 يوليو 2017.{{استشهاد ويب}}: صيانة CS1: التاريخ والسنة (link)

[Web-51-87] "Configuring EIGRP Authenticatio"، Cisco Systems Inc. (باللغة الإنجليزية)، 22 يونيو 2009، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.

[Web-50-88] "EIGRP Message Authentication Configuration Example"، Cisco Systems Inc. (باللغة الإنجليزية)، مؤرشف من الأصل في 27 ديسمبر 2017، اطلع عليه بتاريخ 29 ديسمبر 2017.