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

[نسخة منشورة][نسخة منشورة]
تم حذف المحتوى تمت إضافة المحتوى
JarBot (نقاش | مساهمات)
ط بوت:الإبلاغ عن رابط معطوب أو مؤرشف V3.3
JarBot (نقاش | مساهمات)
ط بوت:الإبلاغ عن رابط معطوب أو مؤرشف V4.2 (تجريبي)
سطر 11:
| influenced = [[بروتوكول التوجيه الداخلي بين البوابات]] (IGRP)
| osilayer = [[طبقة الشبكة]]<ref name="Web-41">{{مرجع ويب
| التاريختاريخ = 19 يونيو 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/14911
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/14911
| العنوانعنوان= Routing protocols operate at what OSI layers?
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
| rfcs = RFC 7868
سطر 31:
| الأخير5= Paluch
| الأول5= P.
| التاريختاريخ= مايو 2016
| المسارمسار= https://www.ietf.org/rfc/7868
| العنوانعنوان= RFC 7868, Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
| الموقعموقع= The Internet Society
| اللغةلغة= en
| issn = 2070-1721
| تاريخ الوصول= 21 ديسمبر 2017| وصلة مكسورة = yes }}</ref>
}}
'''بروتوكول التوجيه الداخلي المحسن بين البوابات''' أو '''بروتوكول بوابة التوجيه الداخلية المعززة'''<ref name="Web-74">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.cert.gov.om/library_information_glossary_arabic.aspx#.WkmHZd-nHIV
| تاريخ الأرشيفأرشيف = 26 ديسمبر 2017
| المسارمسار= http://www.cert.gov.om/library_information_glossary_arabic.aspx#.WkmHZd-nHIV
| العنوانعنوان= التعريفات الأمنية
| الموقعموقع= المركز الوطني للسلامة المعلوماتية
| اللغةلغة= ar
| تاريخ الوصول= 1 يناير 2018}}</ref> {{إنج|Enhanced Interior Gateway Routing Protocol اختصاراً EIGRP}} هو [[بروتوكول توجيه]]، [[بروتوكول توجيه داخلي|داخلي]]، هجين، غير قياسي يعمل في [[طبقة الشبكة]] من [[نموذج اتصال معياري|نموذج الاتصال المعياري]]. في الأصل، تمّ تصميم البروتوكول ليكون مُلكية خاصّة [[سيسكو سيستمز|لشركة سيسكو]]، وليعمل فقط على [[راوتر (حوسبة)|موجهاتها]]، ولكنّه تحوّل لاحقاً بشكل جزئي إلى بروتوكول [[برمجيات مفتوحة المصدر|مفتوح المصدر]] في العام 2013م، ثمّ نُشرت [[طلب تعليقات|وثيقة طلب تعليقات]] خاصّة به فيه العام 2016، هي الوثيقة (RFC 7868).<ref name="ietf-1">{{مرجع ويب
| الأخير= Savag
| الأول= D.
سطر 57:
| الأخير5= Paluch
| الأول5= P.
| التاريختاريخ= مايو 2016
| المسارمسار= https://www.ietf.org/rfc/7868
| العنوانعنوان= RFC 7868, Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
| الموقعموقع= The Internet Society
| اللغةلغة= en
| issn = 2070-1721
| تاريخ الوصول= 21 ديسمبر 2017| وصلة مكسورة = yes }}</ref>
 
جاء تطوير بروتوكول التوجيه الداخلي المُحسن بين البوابات ليحل محل {{وإووصلة إنترويكي|بروتوكول التوجيه الداخلي بين البوابات|Interior Gateway Routing Protocol|en|بروتوكول التوجيه الداخلي بين البوابات}}. لقد كان الدافع الأساسي لهذا التطوير هو محدوديّة الأخير وعدم قدرته على مواكبة تطوّر الشبكات، يتميز البروتوكول بسرعة إنجازه لعملية حساب خالية من {{وإووصلة إنترويكي|مشكلة حلقات التوجيه|Routing loop problem Protocol|en|الحلقات}} وببساطة آليّة عمله العامة رغم اعتماده على خوارزمية شديدة التعقيد.
 
== نظرة عامة ==
 
بروتوكول التوجيه الداخلي المحسن بين البوابات (EIGRP) هو [[بروتوكول توجيه]] [[بروتوكول توجيه داخلي|داخلي]]، هجين، غير قياسي، طُوّر من قبل [[سيسكو سيستمز|شركة أنظمة سيسكو]] في العام 1994، ليحلّ محل {{وإووصلة إنترويكي|بروتوكول التوجيه الداخلي بين البوابات|Interior Gateway Routing Protocol|en|بروتوكول التوجيه الداخلي بين البوابات}}. في الأصل كان البروتوكول ملكية خاصّة، لكن سيسكو جعلت منه معياراً مُتاحاً للاستخدام العام،<ref name="Web-15">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/qa_C67-726299.html
| تاريخ الأرشيفأرشيف = 20 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/qa_C67-726299.html
| العنوانعنوان= Enhanced Interior Gateway Routing Protocol (EIGRP) Informational RFC Frequently Asked Questions
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 24 ديسمبر 2017}}</ref> وهو موصوف في [[طلب تعليقات|وثيقة طلب التعليقات]] (RFC 7868).<ref name="ietf-1"/> يمكن لبروتوكول التوجيه المُحسّن أن يقوم [[توجيه (شبكات)|بتوجيه]] [[رزمة بيانات|رزم]] [[آي بي في4|الإصدار الرابع من بروتوكول الإنترنت]]،<ref name="ietf-4">{{مرجع ويب
| الأخير= Postel
| الأول= J.
| التاريختاريخ= سبتمبر 1981
| السنةسنة= 1981
| الشهرشهر= سبتمبر
| مسار الأرشيفأرشيف =
| المسارمسار= https://tools.ietf.org/html/rfc791
| العنوانعنوان= RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification
| الموقعموقع=The Internet Society
| اللغةلغة= en
| تاريخ الوصول= 13 يوليو2017}}</ref> و[[بروتوكولآي الإنترنتبي (الإصدار السادس)في6|الإصدار السادس]] ،<ref name="ietf-5">{{مرجع ويب
| الأخير= Deering
| الأول= S.
| الأخير2= Hinden
| الأول2= R.
| التاريختاريخ= يوليو 2017
| السنةسنة= 2017
| الشهرشهر= يوليو
| مسار الأرشيفأرشيف =
| المسارمسار= https://tools.ietf.org/html/rfc8200
| العنوانعنوان= RFC 8200, Internet Protocol, Version 6 (IPv6) Specification
| الموقعموقع= The Internet Society
| اللغةلغة= en
| تاريخ الوصول= 31 يوليو 2017}}</ref> و{{وإووصلة إنترويكي|بروتوكول تبادل الرزم|Internetwork Packet Exchange|en|بروتوكول تبادل الرزم}}<ref name="Book3">{{مرجع كتاب
|العنوانعنوان= XSIS 028112, Internet Transport Protocols
|السنةسنة=1981
|الناشرناشر= Xerox Corporation
|اللغةلغة= en
}}</ref> و{{وإووصلة إنترويكي|بروتوكول آبل توك|AppleTalk|en|بروتوكول آبل توك}}.
 
يتمّ تشغيل البروتوكول في كل [[راوتر (حوسبة)|موجه]] بشكلٍ مُنفصل، وبعد تشغيله، يصبح المُوجّه عضواً في مجموعة كل الموجّهات التي تُشغّل بروتوكول التوجيه المُحسّن، ويبدأ عندها باستقبال رسائل التعارف من المُوجّهات الأخرى التي تشغل البروتوكول والتي تسمى جيراناً. رسائل التعارف، وهي رسائل [[بث متعدد|بث مجموعاتي]]، تُرسل إلى العنوان ''224.0.0.10'' من أجل الإصدار الرابع من بروتوكول الإنترنت،<ref name="Web-6">{{مرجع ويب
| مسار الأرشيفأرشيف =http://webcache.googleusercontent.com/search?q=cache:https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
| تاريخ الأرشيفأرشيف = 19 ديسمبر 2017
| المسارمسار= https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
| العنوانعنوان= IPv4 Multicast Address Space Registry
| الموقعموقع= IANA
| اللغةلغة= en
| تاريخ الوصول= 20 ديسمبر 2017}}</ref> وإلى العنوان ''FF02::A'' من أجل الإصدار السادس،<ref name="Web-7">{{مرجع ويب
| مسار الأرشيفأرشيف =http://webcache.googleusercontent.com/search?q=cache:https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
| تاريخ الأرشيفأرشيف = 19 ديسمبر 2017
| المسارمسار= https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
| العنوانعنوان= IPv6 Multicast Address Space Registry
| الموقعموقع= IANA
| اللغةلغة= en
| تاريخ الوصول= 20 ديسمبر 2017}}</ref> وفي كلا الحالتين، فإن هذا العنوان هو عنوان مجموعة كل المُوجّهات التي تُشغّل بروتوكول التوجيه المُحسن. بعد ذلك، يتمّ تبادل المعلومات التي تخصّ [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]]، ثم حساب أفضل المسارات نحو الوجهات وأخيراً إضافة هذه المسارات إلى [[جدول توجيه|جدول التوجيه]] لاستخدامها في [[توجيه (شبكات)|توجيه]] [[رزمة بيانات|رزم البيانات]].
 
يتميّز بروتوكول التوجيه المُحسّن بعدد من الميزات، أهمها سرعة عملية [[إعادة الحساب (شبكات)|إعادة الحساب]]، فهو الأسرع من بين بروتوكولات التوجيه إذا تمّ استعمال كامل ميزاته، بالإضافة إلى عدم استهلاكه [[عرض نطاق|لعرض النطاق]] المُتاح في الشبكة من أجل تبادل معلومات التوجيه، فباستثناء عملية التبادل التي تحصل عند التعارف، فإنّ [[عقدة (شبكات)|العقد]] التي تشغّل هذا البروتوكول لا تتبادل كامل معلومات التوجيه بعد ذلك مطلقاً، بل تكتفي بتبادل المعلومات المُتعلقة بالتغيرات الحاصلة في الطوبولوجيا، ويكون هذا التبادل محدوداً ولا يشمل كامل الشبكة.<ref name="Web-42">{{مرجع ويب
| التاريختاريخ = 27 فبراير 2013
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/docs/DOC-17431
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/docs/DOC-17431
| العنوانعنوان= Routing Protocol Selection Guide - IGRP, EIGRP, OSPF, IS-IS, BGP
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref> بالإضافة لذلك، فمن السهل تشغيل البروتوكول وتقديم الدعم الفني له، ولكن الاستفادة من كامل ميزاته، تتطلب تصميماً دقيقاً للشبكة، وفهماً لخوارزمية العمل المُعقّدة، وكيفية حساب [[وزن (شبكات)|الأوزان]] وآليّة انتشار التحديثات.
 
سطر 136:
[[ملف:EIGRP Draft.png|تصغير|300بك|صورة لجزء من الصفحة الأولى من المسودة الخامسة لبروتوكول التوجيه المُحسّن.]]
 
منذ منتصف الثمانينات، ولإنجاز [[توجيه (شبكات)|التوجيه]]، اعتمدت [[سيسكو سيستمز|شركة سيسكو]] على بروتوكولها الخاصّ، وهو {{وإووصلة إنترويكي|بروتوكول التوجيه الداخلي بين البوابات|Interior Gateway Routing Protocol|en|بروتوكول التوجيه الداخلي بين البوابات}}، الذي أبدى تفوقاً ملحوظاً على [[بروتوكول معلومات التوجيه]] المُسيطر في تلك الفترة، لكنّ بروتوكول التوجيه الداخلي بين البوابات عانى من عدد من العيوب والسلبيات، أهمها محدودية طول المسار، واستهلاكه [[عرض نطاق|لعرض النطاق]] من خلال حاجته الدائمة لإرسال كامل معلومات التوجيه، بالإضافة لكونه [[بروتوكول توجيه]] قياسي لا يدعم [[تجزيءتجزئة الشبكاتالشبكة|تجزئة الشبكات]] بل يكتفي بدعم الأصناف القياسيّة فقط، مع عملية [[إعادة حساب (شبكات)|إعادة حساب]] طويلة وبطيئة،<ref name="Web-30">{{مرجع ويب
| الأول= Eric
| الأخير = Leahy
| التاريختاريخ = 4 سبتمبر 2011
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://ericleahy.com/index.php/eigrp-part-one/
| تاريخ الأرشيفأرشيف = 8 ديسمبر 2017
| المسارمسار= http://ericleahy.com/index.php/eigrp-part-one/
| العنوانعنوان= EIGRP – History
| الموقعموقع= Eric Leahy
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref> لذلك تطلّعت سيسكو إلى تطوير بروتوكول توجيه جديد يُلائم احتياجاتها.
 
كان تطوير {{وإووصلة إنترويكي|خوارمية نشر التحديثات|Diffusing update algorithm|en|خوارمية نشر التحديثات}} في عام 1993م <ref name="JOU-1"/> هو النقطة الأساسية التي ارتكزت عليها عملية تطوير البروتوكول. بعد ذلك، وفي نفس العام، تمّ تطوير بروتوكول التوجيه المُحسّن بشكلٍ نهائيّ كملكيّة خاصة لشركة سيسكو، وفي العام التالي طُرحت ورقة بحثيّة من قبل المُطورين لخّصت آليّة عمله وميزاته.<ref name="Web-31">{{مرجع ويب
| الأول= R.
| الأخير = Albrightson
سطر 155:
| الأول= J.
| الأخير =Boyle
| التاريختاريخ =1994
| المسارمسار= http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.75.9870&rep=rep1&type=pdf
| العنوانعنوان= EIGRP - A FAST ROUTING PROTOCOL BASED ON DISTANCE VECTORS
| الموقعموقع= The Pennsylvania State University
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017| مسار الأرشيفأرشيف = https://web.archive.org/web/20180522042652/http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.75.9870&rep=rep1&type=pdf | تاريخ الأرشيفأرشيف = 22 مايو 2018 }}</ref>
 
في مطلع العام 2013، أوضحت سيسكو رغبتها في جعل البروتوكول مُتاحاً للاستخدام العام،<ref name="Web-29">{{مرجع ويب
| الأول= Saul
| الأخير = Adler
| التاريختاريخ = 11 مارس 2013
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.thocp.net/reference/internet/internet1.htm
| تاريخ الأرشيفأرشيف = 22 ديسمبر 2017
| المسارمسار= http://webcache.googleusercontent.com/search?q=cache:https://blogs.cisco.com/getyourbuildon/cisco-opens-up-eigrp
| العنوانعنوان= Cisco Opens Up EIGRP
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref> وبالتوازي مع ذلك، وفي شهر فبراير من نفس العام، طرحت سيسكو بالتعاون مع [[جمعية الإنترنت]] أول مسودة لمعيار [[برمجيات مفتوحة المصدر|مفتوح]] لبروتوكول التوجيه المُحسّن،<ref name="ietf-2">{{مرجع ويب
| الأخير1= Savage
سطر 183:
| الأخير5= White
| الأول5= R.
| التاريختاريخ= 18 فبراير 2013
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://tools.ietf.org/html/draft-savage-eigrp-00
| المسارمسار= https://tools.ietf.org/html/draft-savage-eigrp-00
| العنوانعنوان= Enhanced Interior Gateway Routing Protocol draft-savage-eigrp-00.txt
| الموقعموقع= The Internet Society
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر2017}}</ref> واستغرق العمل 3 سنوات أخرى، مع مشاركة من أطراف أخرى من {{وإووصلة إنترويكي|بكومولوس للشبكات (شركة)|Cumulus Networks|en|شركة كومولوس للشبكات}} و[[لينكد إن]] و[[جامعة زيلينا]] في [[سلوفاكيا]]، وطُرحَت المسودة الأخيرة التي حملت الرقم 5 في 23 فبراير من العام 2016م،<ref name="ietf-3">{{مرجع ويب
| الأخير1= Savage
| الأول1= D.
سطر 203:
| الأخير6= Paluch
| الأول6= P.
| التاريختاريخ= 23 فبراير 2016
| تاريخ الأرشيفأرشيف = 15 ديسمبر 2017
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://tools.ietf.org/html/draft-savage-eigrp-05
| المسارمسار= https://tools.ietf.org/html/draft-savage-eigrp-05
| العنوانعنوان= Cisco Enhanced Interior Gateway Routing Protocol draft-savage-eigrp-05.txt
| الموقعموقع= The Internet Society
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref> بعد ذلك بشهرين، وبالتحديد في شهر مايو، طُرح المعيار الرسمي للبروتكول في [[طلب تعليقات|وثيقة طلب تعليقات]] من صنف المعلومات، حملت الرقم (RFC 7868).<ref name="ietf-1"/>
 
سطر 222:
يعمل بروتوكول التوجيه المُحسّن على بناء [[جدول توجيه|جدول التوجيه]] والحفاظ عليه بأحدث صورة مُمكنة، كما يتميز بإجرائه عملية [[إعادة حساب (شبكات)|إعادة حساب]] سريعة وبدون تشكّل [[مشكلة حلقات التوجيه|حلقات]]. من حيث فلسفة التصميم، فإنّ هذا البروتوكول يعمل وفق خوارزمية مُشابهة لخوارزمية شعاع المسافة، من حيث الشكل، ولكن هناك العديد من الاختلافات من حيث المضمون.
 
بعد تفعيل البروتكول على [[بطاقة الشبكة|منافذ]] [[راوتر (حوسبة)|الموجه]]، يبدأ المُوجّه باكتشاف جيرانه أولاً، والجار هو مُوجّه آخر يُشغّل البروتوكول ويقع على بعد [[قفزة (شبكات)|قفزة]] واحدة فقط، ثم يُنشئ البروتوكول الذي يعمل في كلا الموجهين علاقة جيران تربطهما، ويتمّ الحفاظ على فعاليّة هذه العلاقة من خلال تبادل نوع خاص من الرسائل يسمى رسائل التعارف. يحتفظ كل مُوجّه بجدول خاصّ يضمّ المعلومات الخاصّة بالجيران المُتصلين معه، وبالعلاقات معهم ويُسمى هذا الجدول بجدول الجيران.
 
بعد إنشاء علاقات الجيران، يقوم المُوجّه الذي تم تفعيل البروتوكول فيه، بإرسال المعلومات التي ترتبط بالشبكات المُتصلة معه بشكل مباشر إلى جيرانه، بالإضافة لاستقباله معلومات التوجيه الخاصة [[طوبولوجيا الشبكةشبكة|بالطوبولوجيا]] منهم، ولا يتمّ بعد ذلك تبادل كامل معلومات التوجيه بين الجيران أبداً، وتقتصر المعلومات المُتبادلة فقط على التغيرات الحاصلة في الطوبولوجيا.
 
بعد ذلك يقوم الموجه بتجميع المعلومات التي استقبلها في جدول خاص هو [[جدول الطوبولوجيا]]، ويضمّ هذا الجدول بنوداً يُمثل كل منها وجهة ما في الشبكة. إنّ المعلومات الموجودة في هذا الجدول لا تقدّم وصفاً دقيقاً مُتكاملاً لكامل الطوبولوجيا، وهي عبارة عن توصيف لمسارات فيها، وهي تشمل [[زمن تأخير|التأخير الكلي]] الحاصل على طول المسار، وأدنى [[عرض نطاق]] خاص بوصلة من بين الوصلات التي تُشكّل المسار، بالإضافة للوزن المنقول الخاص بالمسار، وغير ذلك.
 
من حيث المبدأ، يزداد [[وزن (شبكات)|وزن]] المسار مع زيادة طوله، ويزداد طول المسار من خلال إضافة وصلات جديدة إليه. من أجل كل مسار، يملك المُوجّه وزناً خاصّاً، بالإضافة لمعرفته للموجّه الذي يُمثّل الخطوة التالية في المسار، والذي يُسمى الوارث بحسب مصطلحات البروتوكول، في هذا فإنّ البروتوكول يسلك سلوك [[بروتوكول عامل بخوارزمية شعاع المسافة]]، لكنّ في نفس الوقت، فإنه يحتفظ بمعلومات تخصّ الطوبولوجيا مثل زمن التأخير وعرض النطاق الأدنى في وصلات المسار، وهو بذلك يسلك سلوك [[بروتوكول عامل بخوزازمية حالة الوصلة]] من حيث تجميعه لمعلومات تصفّ الطوبولوجيا، على أي حال، فإن هذا البروتوكول لا ينتمي إلى أي من المجموعتين، وغالباً ما يُوصف بأنّه بروتوكول هجين (Hybrid)،<ref name="Web-1">{{مرجع ويب
| التاريختاريخ = 13 نوفمبر 2011
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/36725
| تاريخ الأرشيفأرشيف = 15 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/36725
| العنوانعنوان= EIGRP Properties as Distance Vector & Link State?
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 18 ديسمبر 2017}}</ref> أو بأنّه بروتوكول توجيه عامل بخوارزميّة شُعاع المسافة المُطوّرة (Advanced Distance-Vector).<ref name="Web-2">{{مرجع ويب
| التاريختاريخ = 24 مارس 2014
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=2180210&seqNum=7
| تاريخ الأرشيفأرشيف = 15 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=2180210&seqNum=7
| العنوانعنوان= Cisco Networking Academy's Introduction to Routing Dynamically
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 18 ديسمبر 2017}}</ref><ref name="Web-3">{{مرجع ويب
| التاريختاريخ = 28 أغسطس 2013
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://rednectar.net/2013/08/28/is-eigrp-a-hybrid-routing-protocol-or-advanced-distance-vector-routing-protocol/
| تاريخ الأرشيفأرشيف = 14 ديسمبر 2017
| المسارمسار= https://rednectar.net/2013/08/28/is-eigrp-a-hybrid-routing-protocol-or-advanced-distance-vector-routing-protocol/
| العنوانعنوان= Is EIGRP a Hybrid Routing Protocol or Advanced Distance Vector Routing Protocol?
| الموقعموقع= RedNectar's Blog
| اللغةلغة= en
| تاريخ الوصول= 18 ديسمبر 2017}}</ref>
 
سطر 260:
في حالة وجود أكثر من مسار نحو نفس الوجهة، قد يختار البرتوكول مساراً احتياطياً، ليكون مساراً بديلاً في حال فشل المسار الأصلي، ويتطلب ذلك تجاوز المسار لشرط خاص يسمى شرط المُلائمة. يسمح وجود مسار احتياطي بتسريع عملية [[إعادة الحساب (شبكات)|إعادة الحساب]] بشكل كبير، ففي حال فشل المسار الأصلي يتمّ الانتقال بشكل مُباشر نحو المسار الاحتياطي، بدون إضاعة الوقت لإنجاز عملية حساب مسار جديد، لكن ذلك يتطلب تصميمَ الشبكة بشكلٍ دقيق للاستفادة من هذه الميزة.
 
عند حصول تغيير في الطوبولوجيا، يطبّق البروتوكول [[خوارزمية]] خاصة هي {{وإووصلة إنترويكي|خوارمية نشر التحديثات|Diffusing update algorithm|en|خوارمية نشر التحديثات}}، تعمل هذه الخوارزمية على إيجاد [[عقدة (شبكات)|العقد]] التي تأثّرت بالتغيير الحاصل، لتقوم وحدها بالقيام بعملية إعادة الحساب، عوضاً عن قيام كل عقد الشبكة بذلك، تضمن خوارزمية نشر التحديثات الحصول على أفضل مسار بدون تشكل حلقات وبأسرع وقت مُمكن من خلال تقليل عدد العقد المُشاركة في الحاسب إلى أدنى عدد ممكن.
 
باستثناء ذلك، فإن البروتوكول يُحافظ على علاقات الجيران فعّالة من خلال تبادل رسائل التعارف بشكلٍ دوريّ، ولا يتم أبداً تبادل أي معلومات تتعلق بالطوبولوجيا أو [[توجيه (شبكات)|بالتوجيه]]، وتستمر هذه الحالة المُستقرة إلى حين حصول تغيير في الطوبولوجيا أو إيقاف تشغيل البروتوكول في الموجه.
سطر 266:
==== شرط الملائمة ====
 
شرط الملائمة {{إنج|Feasibility Condition}} هو مُعيار يُستخدم للتأكّد من أن المسار لا يحتوي على [[مشكلة حلقات التوجيه|حلقات]]. إنّ كل مُسار يُحقق شرط الملائمة هو بالتأكيد مسار خالٍ من الحلقات، ولكن ليس بالضرورة أن يحقق كل مسار خال من الحلقات شرط الملائمة، فالعلاقة ليست عكسية. يُستخدم شرط الملائمة كجزء من عمل {{وإووصلة إنترويكي|خوارمية نشر التحديثات|Diffusing update algorithm|en|خوارمية نشر التحديثات}}، فلابد أن تحقق جميع المسارات التي ستختارها الخوارزمية هذا الشرط، يُطبق هذا الشرط عند حصول تغيير في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]].
 
إنّ لكل مسار بحسب بروتوكول التوجيه المُحسّن ثلاث محددات أساسية، هي وجهته النهائيّة، ووزنه والخطوة التالية إليه، بعد تحديد حصول تغيّر في الطوبولوجيا يؤثّر على مسار معروف ومُستخدم نحو وجهة ما، فإنّ تجاوز شرط الملائمة هو ما يحدد حالة هذا المسار، فإذا تحقق الشرط، فإن المسار يظلّ في الحالة السلبيّة، إما إذا لم يتحقق الشرط، فيجب أن يتم نقله إلى الحالة الفعّالة، أي يجب البحث من جديد عن أفضل وزن نحو تلك الوجهة، وتحديد [[راوتر (حوسبة)|المُوجّه]] الذي يعلن عنه ليكون الخطوة التاليّة إليه.
 
إنّ التعاريف التاليّة أساسيّة لوصف شرط الملائمة:<ref name="Web-45">{{مرجع ويب
| التاريختاريخ = 4 ديسمبر 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/24103
| تاريخ الأرشيفأرشيف = 26 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/24103
| العنوانعنوان= EIGRP Feasibility Condition, oh and RD and FD
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref><ref name="Web-46">{{مرجع ويب
| التاريختاريخ = 7 أوكتوبر 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.devilwah.com/2010/10/ccnp-route-part-6-eigrp-terminology-in-diagrams/
| تاريخ الأرشيفأرشيف = 6 نوفمبر 2017
| المسارمسار= http://www.devilwah.com/2010/10/ccnp-route-part-6-eigrp-terminology-in-diagrams/
| العنوانعنوان= CCNP ROUTE (Part 6 EIGRP Terminology in Diagrams)
| الموقعموقع= DEVILWAH's BLOG
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
* ''' الوزن المنقول ''' (Reported Distance) بالنسبة لموجه ما: هو وزن لمسار، كما أعلن عنه جار ما، بدون إدخال أي تعديل على قيمة الوزن، والحفاظ عليها كما وردت من الجار.
سطر 291:
* '''الوارث''' (Successor): الوارث هو جار. ووارث مسار نحو وجهة ما، هو المُوجّه الذي يُمثّل الخطوة التالية (Next Hop) نحو هذه الوجهة. عمليّاً، يكون وارث المسار، هو المُوجّه الذي يكون وزن مساره المحسوب نحو تلك الوجهة هو الوزن الأدنى قيمةً بين جميع الأوزان المحسوبة نحو تلك الوجهة. وهناك دائماً وارث واحد على الأقل.
* '''الوراث المُلائم''' (Feasible Successor) لمسار نحو وجهة ما: هو مُوجّه، يتم اختياره بعد اختيار الوارث، هو جار يملك مساراً نحو الوجهة ويُحقق شرط الملائمة، ويمكن للوارث المُلائم أن يتحول إلى وارث في حال فشل الوارث، أو في حال تعذّر الوصول إليه. قد لا يوجد أي مسار ملائم أو قد يوجد مسار ملائم واحد أو أكثر.<ref name="Web-25">{{مرجع ويب
| التاريختاريخ = 9 أغسطس 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://packetlife.net/blog/2010/aug/9/eigrp-feasible-successor-routes/
| تاريخ الأرشيفأرشيف = 24 ديسمبر 2006
| المسارمسار= http://packetlife.net/blog/2010/aug/9/eigrp-feasible-successor-routes/
| العنوانعنوان= Configuring the Enhanced Interior Gateway Routing Protocol
| الموقعموقع= Packet life
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref>
 
{{اقتباس خاص|يتحقق شرط المُلائمة عندما يكون الوزن المنقول للجار المُرشح لأن يكون وارثاً مُلائماً أقل من قيمة الوزن المحسوب للوارث الحالي.<ref name="Web-49">{{مرجع ويب
| التاريختاريخ = 11 أبريل 2016
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.practicalnetworking.net/stand-alone/eigrp-feasibility-condition/
| تاريخ الأرشيفأرشيف = 21 ديسمبر 2017
| المسارمسار= http://www.practicalnetworking.net/stand-alone/eigrp-feasibility-condition/
| العنوانعنوان= EIGRP Feasibility Condition
| الموقعموقع= Practical Networking.net
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>}}
 
سطر 326:
==== أنواع الرسائل ====
 
في البداية، يجب التمييز بين أنواع الرسائل الخاصّة {{وإووصلة إنترويكي|خوارمية نشر التحديثات|Diffusing update algorithm|en|خوارمية نشر التحديثات}}، وأنواع الرسائل الخاصة ببروتوكول التوجيه المُحسن، وعادة ما يتم الخلط بين الاثنين بسبب تشابه الأسماء. تعتمد خوارزمية نشر التحديثات على 3 أنواع من الرسائل هي: رسائل التحديث والاستعلام والرد. أمّا بروتوكول التوجيه المُحسن فهو يعتمد على 5 أنواع من الرسائل، وتستخدم رسائل بروتوكول التوجيه المُحسّن من أجل نقل رسائل خوازرمية نشر التحديثات، وأيضاً لإنجاز وظائف البروتوكول الأخرى، وهي إمّا أن تكون [[بث منفردفريد|رسائل مُنفردة]] أو رسائل [[بث مجموعاتيمتعدد|بثّ مجموعاتي]].
 
بحسب [[حزمة بروتوكولات الإنترنت|نموذج الإنترنت]]، يعمل بروتوكول التوجيه المُحسّن في [[طبقة الإنترنت]]، ويتم تغليف رسائله داخل رزم بيانات بروتوكول الشبكة، مثل [[آي بي في4|الإصدار الرابع من بروتوكول الإنترنت]] أو [[الإصدارعنوان السادسآي منبي بروتوكول الإنترنتفي6|الإصدار السادس]]، في الإصدار الرابع، تمّ حجز الرقم (88) في حقل البروتوكول لتمييز رسائل بروتوكول التوجيه المُحسّن.<ref name="Web-8">{{مرجع ويب
| مسار الأرشيفأرشيف =http://webcache.googleusercontent.com/search?q=cache:https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
| تاريخ الأرشيفأرشيف = 19 ديسمبر 2017
| المسارمسار= https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
| العنوانعنوان= Protocol Numbers
| الموقعموقع= IANA
| اللغةلغة= en
| تاريخ الوصول= 20 ديسمبر 2017}}</ref> لا يمكن [[تقطيع (شبكات)|تقطيع]] رسائل البروتوكول، لذلك فإنّه لا يقوم بتوليد رسائل ذات طول يتجاوز [[وحدة النقل الأعظمية]] (MTU).
 
إنّ الأنواع الخمسة للرسائل الخاصة بالبروتوكول هي:<ref name="ietf-1"/><ref name="Web-48">{{مرجع ويب
| التاريختاريخ = 25 يونيو 2013
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://websistent.com/demystifying-eigrp-message-types-wireshark/
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= https://websistent.com/demystifying-eigrp-message-types-wireshark/
| العنوانعنوان= Demystifying EIGRP message types with Wireshark
| الموقعموقع= Jesin's Blog
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>
 
سطر 354:
 
ويبين الجدول التالي معلومات تفصيلية عن الرسائل الخاصة ببروتوكول التوجيه المُحسّن:<ref name="ietf-1"/><ref name="Web-47">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13669-1.html
| تاريخ الأرشيفأرشيف = 28 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13669-1.html
| العنوانعنوان= Introduction to EIGRP
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>
 
سطر 369:
! style="width:60%;"| وظيفة الرسالة
|-
| رسالة التعارف || [[بث مجموعاتيمتعدد|بثّ مجموعاتيّ]] || لا || تستخدم لاكتشاف الجيران، وهي تُرسل بشكلٍ دوريّ وبفواصل زمنيّةٍ ثابتة يتمّ تحديدُها بواسطة مُؤقّت خاصّ هو مُؤقّت التعارف، تحتوي هذه الرسالة على ثوابت حساب الوزن وقيمة مُؤقّت الانتظار.
|-
| رسالة الاستعلام || [[بث منفردفريد|بثّ منفرد]] أو مجموعاتي (الحالة العامة) || دائماً || تستخدم هذه الرسالة لحمل رسائل الاستعلام الخاصّة بخوارزمية نقل التحديثات (DUAL)، بالإضافة إلى استخدامها من قبل [[راوتر (حوسبة)|المُوجّهات]] للإعلان عن كون أحد المسارات نحو وجهة ما بالحالة الفعّالة، وبأنّ مصدر المعلومات يطلب معلومات مساراً بديلاً نحو ذات الوجهة من جيرانه.
إذا سبب التغيير الحاصل في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]] نقل عدّة مسارات إلى الحالة الفعّالة، فإنّ البروتوكول قد يُضمّن وجهات هذه المسارات في رسالة استعلام واحدة أو أكثر، ولا داعي عندها لتشمل رسالة الرد جميع هذه الوجهات، ويُكتفى بالوجهة التي تصفّ المعلومات الجديدة المُشار إليها في رسالة الرد. بعد مُعالجة رسالة الاستعلام بحسب خوارزمية نقل التحديثات يجب أن تُرسل رسالة ردّ أو رسالة ردّ بسبب كون الوجهة عالقة في الحالة الفعّالة.
|-
| رسالة الردّ || بثّ منفرد || دائماً || تُستخدم هذه الرسالة لحمل رسالة الردّ الخاصّة بخوارزمّية نشر التحديثات، وهي ترسل رداً على رسالة استعلام أو رسالة استعلام لإبقاء الحالة الفعّالة. تحتوي رسالة الردّ على قسم واحد أو أكثر من رسالة الإستعلام، وهذه الأقسام هي التي يتمّ الردّ عليها، أيّ أنّ معلومات رسالة الردّ تصفّ هذه الأقسام. يتمّ إرسال إشعار تأكيد الوصول عند استقبال رسالة الردّ، وإمّا أن يتم ذلك بشكل مُستقل أو من خلال إضافة الإشعار إلى إحدى رسائل البروتوكول.
سطر 389:
 
=== حساب الوزن ===
يدعم بروتوكول التوجيه المُحسّن (EIGRP) عمليّة مُعقّدة لحساب [[وزن (شبكات)|الوزن]]، وهي تجري بشكلٍ آليّ اعتماداً على مُعادلة رياضيّة تشتمل على عدد من المُتحولات والمُعاملات، فأمّا المُتحولات فهي تخصّ [[طوبولوجيا شبكة|طوبولوجيا الشبكة]] نفسَها، وأمّا المُعاملات فهي قيم عددية ثابتة، تُضبط من أجل التأثير بطريقة مُحددة على أحد المتحولات، كجعل أثره مُضاعفاً مُقارنةً مع البقيّة، أو حتى إهمالُه بالكامل. يُستخدم البروتوكول المتحولات لتمثيل القيم الخاصّة [[عرض نطاق|بعرض نطاق]] الوصلات، و[[زمن تأخير (شبكات)|زمن التأخير]] فيها بالإضافة لقيم ترتبط [[حمولة (حوسبة)|بالحمولة]] و[[وثوقيّة (شبكات)|الوثوقيّة]] و[[وحدة النقل الأعظمية]] (MTU) و[[تقلقل الإرسال]] والطاقة، بالإضافة لوجود ست مُعاملات هي بالترتيب (K1, K2, K3, K4, K5, K6).
 
==== المُتحوّلات المُستعملة في حساب الوزن ====
سطر 396:
 
بالإضافة لذلك، يُمكن حساب الوزن اعتماداً على زمن التأخير الكليّ الحاصل على طول المسار، وهو الزمن اللازم لانتقال [[بت]] من الوجهة النهائيّة للمسار إلى العقدة التي تُشغّل البروتوكول، إنّ زمن التأخير يقاس [[ثانية|بالثانية]]، لكن القيمة المُستعملة تكون صغيرةً جداً، ومن مرتبة الميكرو ثانية، كما يدخل هذا المتحول في مُعادلات حساب الأوزان بمرتبة أصغر هي عشرات الميكروثانية في الوزن التقليدي والبيكو ثانية في الوزن المُوسّع.<ref name="Web-18">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-wid-met.html
| تاريخ الأرشيفأرشيف = 20 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-wid-met.html
| العنوانعنوان= IP Routing: EIGRP Configuration Guide, Cisco IOS XE Release 3S, Chapter: EIGRP Wide Metrics
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 25 ديسمبر 2017}}</ref>
 
سطر 407:
 
يدعم البروتوكول أيضاً حساب الوزن واختيار المسارات على أساس [[تقلقل الإرسال]] واستهلاك الطاقة، حيث تُقضّل المسارات التي تكون تقلقل الإرسال فيها أقلّ ما يُمكن، وكذا الأمر بالنسبة لاستهلاك الطاقة.<ref name="Web-19">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/whitepaper_C11-720525.html
| تاريخ الأرشيفأرشيف = 23 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/whitepaper_C11-720525.html
| العنوانعنوان= Enhanced Interior Gateway Routing Protocol (EIGRP) Wide Metrics White Paper
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 25 ديسمبر 2017}}</ref> رغم دعم البروتوكول للمفهومين السابقين، إلا أنّه لا يمتلك أي وسيلة حاليّاً لقياس أيّ منهما، ولذلك فإنّ إدخال قيم هذه المُتحولات في معادلة حساب الوزن غير مُمكن.<ref name="Web-20">{{مرجع ويب
| التاريختاريخ = 29 أغسطس 2015
| مسار الأرشيفأرشيف = httphttps://web.archive.org/web/20171225001125/http://bearscciejourney.blogspot.fr/2015/08/eigrp-metric-notes.html
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= http://bearscciejourney.blogspot.fr/2015/08/eigrp-metric-notes.html
| العنوانعنوان= EIGRP Metric notes
| الموقعموقع= blogspot
| اللغةلغة= en
| تاريخ الوصول= 25 ديسمبر 2017}}</ref>
 
إنّ [[وحدة النقل الأعظمية]] (MTU)، هي أحد المتحولات التي يقيسُها البروتوكول وينقلُها في رسائله، والهدف الأساسي من ذلك هو التعرّف على أدنى وحدة نقل أعظمية طول المسار، لكنّ هذه القيمة لا تدخُل في مُعادلات حساب الأوزان.<ref name="Web-17">{{مرجع ويب
| المؤلفمؤلف = Christoph Neulinger
| التاريختاريخ = 15 ديسمبر 2009
| المسارمسار= https://learningnetwork.cisco.com/message/44024#44024
| العنوانعنوان= Metric Calculation in EIGRP
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 25 ديسمبر 2017}}</ref>
 
سطر 435:
 
تمّ تطوير معادلة حساب [[وزن (شبكات)|الوزن]] الخاصّة ببروتوكول التوجيه المحسن (EIGRP) بناء على دراسة دقيقة لإعطاء كل مسار وزناً يتلائم مع محدداته، بحيث يكون للمسار الأفضل وزنٌ أقل، وقد تمّ اختيار قيم المُعاملات بناء على هذا، لذلك لا يُستحسن أن يتمّ تعديل هذه القيم.<ref name="Web-10">{{مرجع ويب
| التاريختاريخ = 11 أبريل 2015
| مسار الأرشيفأرشيف =http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/83504
| تاريخ الأرشيفأرشيف = 7 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/83504
| العنوانعنوان= Regarding EIGRP 'K' Values
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 22 ديسمبر 2017}}</ref> يُمكن أن تأخذ قيمة أي مُعامل أي عدد صحيح موجب في ضمن المجال [255,0].<ref name="Web-12">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/command/ire-cr-book/ire-i1.html#wp3835409071
| تاريخ الأرشيفأرشيف = 19 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/command/ire-cr-book/ire-i1.html#wp3835409071
| العنوانعنوان= Cisco IOS IP Routing: EIGRP Command Reference
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 22 ديسمبر 2017}}</ref> إنّ تطابق هذه القيم بين مُوجّهين يُشغّلان البروتوكول هو شرطٌ أساسيّ لنجاح إنشاء علاقة الجيران فيما بينهما.<ref name="Web-11">{{مرجع ويب
| التاريختاريخ = 3 يونيو 2015
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/lan-switching-and-routing/eigrp-k-value-mismatch-issue/td-p/1008233
| تاريخ الأرشيفأرشيف = 20 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/lan-switching-and-routing/eigrp-k-value-mismatch-issue/td-p/1008233
| العنوانعنوان= EIGRP K -value mismatch issue
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 22 ديسمبر 2017}}</ref>
 
يُعطي المُعامل (K1) أهمية [[عرض نطاق|لعرض النطاق]]، أما المُعامل (K2) فإنه يُستخدم ليعطي أهمية [[معدل الإنتاجية (اتصالات)|لإنتاجية الشبكة]]، والتي تُحسب بصيغة رياضية تربط بين اثنين من المُتحولات هما عرض النطاق و[[حمولة (حوسبة)|الحمولة]]. يسمح المُعامل (K3) بإعطاء أهميّة [[زمن تأخير (شبكات)|للتأخير]] الحاصل على طول المسار في معادلة حساب الوزن. أمّا المعاملين (K4) و(K5) فهما يُدخلان جودة الوصلة في الحساب، عن طريق [[وثوقية (شبكات)|الوثوقية]]. إنّ القيمة الافتراضيّة للمُعاملين (K1) و(K3) هي 1، أمّا القيمة الافتراضيّة للمُعاملات (K2) و(K4) و(K5) فهي (0).<ref name = "Book-1">{{مرجع كتاب
|المؤلف1مؤلف1= Kevin Dooley
|المؤلف2مؤلف2= Ian Brown
|العنوانعنوان= Cisco IOS Cookbook
|الصفحةصفحة= 267
|السنةسنة=2007
|الناشرناشر= O'Reilly Media, Inc
|الرقم المعياري=0596527225
|اللغةلغة= en
}}</ref>
 
إنّ استخدام المعامل (K6) يقتصر على عملية حساب الوزن المُوسّع فقط، وهو يُدخل متحولات [[تقلقل الإرسال]] والطاقة في الحساب، تكون القيمة الافتراضيّة لهذا المعامل هي (0).<ref name="Web-13">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-wid-met.pdf
| تاريخ الأرشيفأرشيف = غير معروف
| المسارمسار= https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-wid-met.pdf
| العنوانعنوان= EIGRP Wide Metrics
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 22 ديسمبر 2017}}</ref>
 
سطر 484:
| الأول= Joe
| الأخير = Astorino
| التاريختاريخ =3 مارس 2010
| مسار الأرشيفأرشيف = httphttps://web.archive.org/web/20140317083156/http://blog.ipexpert.com/2010/03/03/eigrp-metric-k-values/
| تاريخ الأرشيفأرشيف = 17 مارس 2014
| المسارمسار= http://blog.ipexpert.com/2010/03/03/eigrp-metric-k-values/
| العنوانعنوان= EIGRP Metric & K-Values
| الموقعموقع= IPexpert Inc.
| اللغةلغة= en
| تاريخ الوصول= 27 ديسمبر 2017}}</ref>
 
سطر 499:
| الأول= Sharma
| الأخير = kamlesh
| التاريختاريخ =25 ديسمبر 2005
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/wan-routing-and-switching/eigrp-load-and-reliability/td-p/475653
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/wan-routing-and-switching/eigrp-load-and-reliability/td-p/475653
| العنوانعنوان= EIGRP load and reliability
| الموقعموقع= Cisco Systems, Inc.
| اللغةلغة= en
| تاريخ الوصول= 27 ديسمبر 2017}}</ref> يرجع استعمال القيم الخطيّة إلى الاختلاف في [[وحدات قياس|واحدات القياس]]، ففي حين يقاس عرض النطاق، بملايين [[هرتز|الهرتز]]، والهرتز هو مقلوب [[ثانية|الثانية]]، فإنّ زمن التأخير يقاس بالميكرو ثانية، لذلك يتمّ اللجوء إلى القيم الخطيّة بهدف تجانس الوحدات.
 
سطر 523:
 
من أجل القيم الافتراضية للمُعاملات، مع افتراض أن ( <math>\frac {K_5}{K_4 + \text{R}}</math> ) مُساوية للواحد من أجل قيمة صفرية للمُعامل ( <math>{K_5}</math> )، فإنّ مُعادلة حساب الوزن التقليدي تؤول إلى الشكل التالي:<ref name = "Book-5">{{مرجع كتاب
|المؤلف1مؤلف1= Diane Teare, Bob Vachon, Rick Graziani
|العنوانعنوان= Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101)
|الطبعةطبعة= الأولى
|الصفحةصفحة= 89
|المسارمسار= http://www.ciscopress.com/store/implementing-cisco-ip-routing-route-foundation-learning-9781587204562
|السنةسنة= 2015
|الناشرناشر= Cisco Press
|الرقم المعياري= 1587204568
|اللغةلغة= en
}}</ref>
 
سطر 537:
 
تتمّ عملية الحساب بشكلٍ آليّ. إنّ [[وحدة النقل الأعظمية]] (MTU) لا تدخل في معادلة الوزن التقليدي.<ref name="Web-14">{{مرجع ويب
| التاريختاريخ = 10 مارس 2006
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/other-network-infrastructure/mtu-in-eigrp-metric/td-p/646073
| تاريخ الأرشيفأرشيف = 21 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/other-network-infrastructure/mtu-in-eigrp-metric/td-p/646073
| العنوانعنوان= MTU in EIGRP metric?
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 23 ديسمبر 2017}}</ref>
 
سطر 555:
 
لحساب معدل الإنتاجيّة الصافيّ، تُستخدم المعادلة التالية:<ref name = "Book-4">{{مرجع كتاب
|المؤلف1مؤلف1= Brad Edgeworth, Aaron Foss, Ramiro Garza Rios
|العنوانعنوان= IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols
|الطبعةطبعة= الأولى
|الصفحةصفحة= 154
|المسارمسار= http://www.ciscopress.com/store/ip-routing-on-cisco-ios-ios-xe-and-ios-xr-an-essential-9781587144233
|السنةسنة= 2014
|الناشرناشر= Cisco Press
|الرقم المعياري= 1587144239
|اللغةلغة= en
}}</ref>
 
سطر 606:
 
=== طوبولوجيا الشبكة ===
يتعامل بروتوكول التوجيه المحسن (EIGRP) مع كامل [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]] دفعة واحدة، أي أنّه لا يُقسمها إلى أقسام ولا يُجزّؤها إلى مناطق.<ref name="Web-77">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Small_Enterprise_Design_Profile/SEDP/chap2.html
| تاريخ الأرشيفأرشيف = 30 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Small_Enterprise_Design_Profile/SEDP/chap2.html
| العنوانعنوان= Small Enterprise Design Profile Reference Guide
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 1 يناير 2018}}</ref> خلال عمله، يُقوم البروتوكول بإنشاء جدولين هما جدول الجيران الذي يحتوي معلومات عن عن جيران [[راوتر (حوسبة)|المُوجّه]] التي تُشغّل البروتوكول، و[[جدول الطوبولوجيا]] الذي يُخزّن معلومات تصف مساراتٍ مُختلفة في طوبولوجيا الشبكة. بالإضافة لذلك، فإنّ بروتوكول التوجيه المُحسّن يضيف مجموعة من البنود إلى [[جدوب توجيه|جدول التوجيه]] كنتيجة نهائيّة لعمله.
==== جدول الجيران ====
 
يضمّ جدول الجيران معلومات عن جيران [[راوتر (حوسبة)|المُوجّه]] الحاليين، والجار هو مُوجّه آخر يُشغّل بروتوكول التوجيه المُحسن ويتبادل رسائل التعارف مع المُوجّه المحليّ الذي يضمّ جدول الجيران. يتمّ تجميع المعلومات الموجودة في جدول الجيران من رسائل التعارف المُستقبلة من الجيران المُختلفين، عند التعرف على جار جديد يتمّ إضافته إلى جدول الجيران، وكذلك الأمر عند انتهاء العلاقة مع أحد الجيران، حيث يصار إلى حذفه من جدول الجيران. بشكلٍ عام، يوجد جدول جيران واحد، ولكن إذا تمّ تشغيل أكثر من وحدة غير مُستقلة من وحدات البروتوكول فسيتمّ إنشاء جدول جيران لكل وحدة، بعبارة أخرى، من أجل كل [[بروتوكول توجيه#البروتوكولات المُوجّهة|بروتوكول مُوجّه]]، يتمّ إنشاء جدول جيران مُستقل.<ref name="Web-24">{{مرجع ويب
| التاريختاريخ = 25 ديسمبر 2006
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=687478&seqNum=2
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=687478&seqNum=2
| العنوانعنوان= Configuring the Enhanced Interior Gateway Routing Protocol
| الموقعموقع= Cisco Press
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref>
 
يضمّ جدول الجيران عنواناً مُميزاً للجار، و[[بطاقة الشبكة|منفذ]] المُوجّه المحلي الذي يتصل معه، يكون مُؤقّت الانتظار مُلحقاً بجدول الجيران، إنّ نفاذ مُؤقّت الانتظار يعني فشل الجار، ويتطلب تطبيق {{وإووصلة إنترويكي|خوارمية نشر التحديثات|Diffusing update algorithm|en|خوارمية نشر التحديثات}}. بالإضافة لذلك، فإنّ الجدول يضمّ معلومات مُكتسبة من بروتوكول النقل الموثوق (RTP)، وهو بروتوكول يُقدّم [[خدمة (شبكات)|خدمة]] النقل [[وثوقية (شبكات)|الموثوق]]، ويعتمد عليه بروتوكول التوجيه المُحسّن لضمان إيصال [[رزمة بيانات|الرزم]].
 
==== جدول الطوبولوجيا ====
{{مفصلة|جدول الطوبولوجيا}}
يحتوي جدول الطوبولوجيا على المعلومات الخاصّة [[طوبولوجيا الشبكةشبكة|بطوبولوجيا الشبكة]]، يتمّ تجميع هذه المعلومات من خلال الشبكات المُتصلة بشكلٍ مُباشر مع الموجه بالإضافة للمعلومات المُكتبسة من الجيران، سواءً أثناء إنشاء علاقة الجيران أو بسبب حصول تغيرات في الطولولوجيا. يتكوّن الجدول من عدد من البنود، ويُمثّل كل بند شبكة وجهة، ويضم معلوماتٍ عن المسار إلى تلك الوجهة، مثل الوزن المنقول والوزن المحسوب ووارث المسار نحو هذه الشبكة الوجهة، بالإضافة إلى الوارث أو الورثة الملائمين في حال وجودهم.<ref name = "Book-3">{{مرجع كتاب
|المؤلف1مؤلف1= Michael J. Shannon
|العنوانعنوان= CCNP Exams: Exams 642-801, 642-811, 642-821, 642-831
|الصفحةصفحة= 171
|السنةسنة=2004
|الناشرناشر= Que Publishing
|الرقم المعياري=0789730170
|اللغةلغة= en
}}</ref>
 
إنّ بروتوكول التوجيه المُحسّن (EIGRP) يعتمد بالأساس على خوازمية عمل مشتقة من خوارزميّة شعاع المسافة، لذلك فإنّه لا يُخزّن معلومات تفصيليّة عن كامل طوبولوجيا الشبكة، بل تصف هذه المعلومات مساراتٍ فيها، ولا يكون وصف المسارات تفصيليّاً أيضاً، لكنّه يضمّ المعلومات المطلوبة لحساب [[وزن (شبكات)|الأوزان]]، إن جدول الطولولوجيا هو المصدر الأساسي للمعلومات التي سوف تضاف إلى [[جدول توجيه|جدول التوجيه]].<ref name = "Book-2">{{مرجع كتاب
|المؤلف1مؤلف1= Wendell Odom
|العنوانعنوان= CCNP Route 642-902 Official Certification Guide
|الصفحةصفحة= 60
|السنةسنة=2010
|الناشرناشر= Cisco Press
|الرقم المعياري=1587202530
|اللغةلغة= en
}}</ref>
 
سطر 653:
{{مفصلة|جدول توجيه}}
 
جدول التوجيه هو [[قاعدة بيانات]] موجودة في كل [[راوتر (حوسبة)|مُوجّه]]، تخصص لتخزين المعلومات الخاصّة [[توجيه (شبكات)|بالتوجيه]] والتي تستعمل بشكل مباشر لاتخذ قرار التوجيه، يقوم بروتوكول التوجيه المُحسّن (EIGRP) بإضافة المسارات التي يختارها إلى جدول التوجيه، مع علامة خاصّة للإشارة إلى مصدرها، في الموجّهات العاملة بأنظمة تشغيل [[سيسكو سيستمز|سيسكو]] تكون هذه العلامة هي حرف (D).<ref name="Web-40">{{مرجع ويب
| المؤلفمؤلف = Stephen McQuerry.
| التاريختاريخ = 11 يناير 2008
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=1171169&seqNum=3
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=1171169&seqNum=3
| العنوانعنوان= Implementing EIGRP
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
 
<gallery>
Routing table.png|مثال عن [[جدول توجيه]] في [[راوتر (حوسبة)|مُوجّه]] يُشغّل نظام تشغيل سيسكو، يحتوي على بنود تمت إضافتها بواسطة بروتوكول التوجيه المُحسن (EIGRP).في شبكة تُشغّل [[آي بي في4|الإصدار الرابع من بروتوكول الإنترنت]] (IPv4).
Routing Table 1.png|مثال عن جدول توجيه يحتوي بنوداً تمت إضافتها بواسطة بروتوكول التوجيه المُحسّن (EIGRP)، تم استخدام [[عنوان آي بي في6|الإصدار السادس من بروتوكول الإنترنت]] (IPv6) كبروتوكول مُوجّه.
Topology Table 1.png| مثال عن [[جدول الطوبولوجيا]] الخاصّ ببروتوكول التوجيه المُحسّن (EIGRP) في مُوجّه يُشغّل نظام تشغيل سيسكو. في شبكة تُشغّل الإصدار السادس من بروتوكول الإنترنت (IPv6).
Topology Table.png|مثال عن جدول الطوبولوجيا الخاصّ ببروتوكول التوجيه المُحسّن (EIGRP) في مُوجّه يُشغّل نظام تشغيل سيسكو.في شبكة تُشغّل الإصدار الرابع من بروتوكول الإنترنت (IPv4).
سطر 674:
=== رسائل التحديث ===
 
تُستخدم رسائل التحديث لنقل معلومات التوجيه بين [[راوتر (حوسبة)|المُوجّهات]] المُختلفة، ولا يتمّ تبادل معلومات التوجيه إلا بين المُوجّهات الجيران. تحصل عملية تبادل رسائل التحديث وفق القواعد التالية:<ref name="Web-26">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://networkrange.wordpress.com/building-the-eigrp-topology-table/
| تاريخ الأرشيفأرشيف = 21 ديسمبر 2017
| المسارمسار= https://networkrange.wordpress.com/building-the-eigrp-topology-table/
| العنوانعنوان= Building the EIGRP Topology Table
| الموقعموقع= networkrange word press blog
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref>
* بعد نشوء علاقة الجيران بين مُوجّهين، يتمّ تبادل كامل معلومات التوجيه، وهي الحالة الوحيدة التي يتمّ فيها تبادل كامل معلومات التوجيه.
* عند حصول تغيير في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]]، ويشمل ذلك تغيير في معاملات أو متحولات حساب [[وزن (شبكات)|الوزن]]، أو فشلاً في إحدى الوصلات، أو اكتشاف جار جديد، فإن المُوجّه الذي اكتشف التغيير يقوم بإرسال تحديثٍ جزئي يصفّ فيه التغيير الحاصل في الشبكة فقط. في حال اكتشاف جار جديد، يتمّ تبادل كافة معلومات التوجيه مع الجار الجديد فقط، ويتمّ نشر تحديثات تُفيد بالتغيير الحاصل في باقي الشبكة.
* في حال فشل علاقة جيران ثم إعادة تشكيلها مُجدداً، يجب تبادل كامل معلومات التوجيه، بشكل مُطابق للتعرّف على جار جديد.
* يدعم بروتوكول التوجيه المُحسّن خاصية [[تحديد الأفق والإعلان عن المسار|تحديد الأفق]] (Split Horizon) بشكلٍ افتراضيّ، كآليّة لمنع تشكّل الحلقات،<ref name="Web-54">{{مرجع ويب
| المؤلفمؤلف = Jeremy Stretch
| التاريختاريخ = 3 نوفمبر 2008
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://packetlife.net/blog/2008/nov/03/disabling-split-horizon/
| تاريخ الأرشيفأرشيف = 14 ديسمبر 2017
| المسارمسار= http://packetlife.net/blog/2008/nov/03/disabling-split-horizon/
| العنوانعنوان= Disabling split horizon
| الموقعموقع= Packet life
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref> وتُحدد هذه الخاصيّة المعلومات التي يتمّ إرسالها عبر كل [[بطاقة الشبكة|منفد]]، سواء في التحديثات الكليّة أو الجزئية.<ref name="Web-53">{{مرجع ويب
| التاريختاريخ = 3 نوفمبر 2008
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/78494
| تاريخ الأرشيفأرشيف = 13 ديسمبر 2014
| المسارمسار= https://learningnetwork.cisco.com/thread/78494
| العنوانعنوان= why split horizon needed in EIGRP?
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>
 
سطر 710:
 
يُحدد مُؤقّت التعارف (Hello Timer) الفترة الزمنيّة الفاصلة بين رسائل التعارف التي يُرسلها البروتوكول عبر [[بطاقات الشبكة|منفذ]] ما.<ref name="Web-61">{{مرجع ويب
| المؤلفمؤلف = Wael Osama
| التاريختاريخ = 8 أغسطس 2008
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.networkers-online.com/blog/2008/08/eigrp-timers-hello-hold-down-and-active/
| تاريخ الأرشيفأرشيف = 29 ديسمبر 2017
| المسارمسار= http://www.networkers-online.com/blog/2008/08/eigrp-timers-hello-hold-down-and-active/
| العنوانعنوان= EIGRP timers (hello, hold and active)
| الموقعموقع= Networkers-online
| اللغةلغة= en
| تاريخ الوصول= 30 ديسمبر 2017}}</ref> في [[راوتر (حوسبة)|المُوجّهات]] العاملة [[نظام تشغيل|بأنظمة تشغيل]] [[سيسكو سيستمز|سيسكو]] تكون القيمة الاسميّة لهذا المؤقت هي (5) ثواني في منافذ [[شبكة محلية|الشبكات المحليّة]]، و (60) ثانية في منافذ [[شبكة متباعدة|الشبكات المُتباعدة]].<ref name="Web-62">{{مرجع ويب
| المؤلفمؤلف = Jeremy Stretch
| التاريختاريخ = 14 مايو 2008
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://packetlife.net/blog/2008/may/14/hello-timer-behaviors/
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= http://packetlife.net/blog/2008/may/14/hello-timer-behaviors/
| العنوانعنوان= Hello timer behaviors
| الموقعموقع= packet life
| اللغةلغة= en
| تاريخ الوصول= 30 ديسمبر 2017}}</ref> لا يُسبب اختلاف قيم مُؤقّت التعارف بين طرفين مانعاً لتشكيل علاقة الجيران، ولكن وضع قيم غير مدرُوسة بشكلٍ جيّد قد يُسبب إنشاء علاقة جيران غير مُستقرّة.<ref name="Web-37"/>
 
==== مؤقت الانتظار ====
يُحدد مؤقت الانتظار (Hold Timer) الزمن الذي ينتظره البروتوكول بعد استلام رسالة تعارف من جارٍ ما قبل إعلان فشل علاقة الجيران معه، ويعني الفشل أنّ الوصول إلى الجار غير مُمكن،<ref name="ietf-1"/> ويُعدّ ذلك تغييراً في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]]. يُسبب استلام رسالة تعارف نت جار ما إعادة ضبط مُؤقّت العلاقة مع ذلك الجار إلى قيمته الإسميّة. بشكلٍ افتراضيّ، تكون قيمة هذا المُؤقّت ثلاث أضعاف قيمة مُؤقّت التعارف، وفي [[راوتر (حوسبة)|المُوجّهات]] العاملة [[نظام تشغيل|بنظام تشغيل]] [[سيسكو سيستمز|سيسكو]] تبلغ القيمة الاسميّة لهذا المؤقت (15) [[ثانية]] في [[بطاقة الشبكة|المنافذ]] المُتصلة مع [[شبكة محلية|شبكات محليّة]]، و(180) ثانية في المنافذ المُتصلة مع [[شبكة متباعدة|شبكات مُتباعدة]].<ref name="Web-64">{{مرجع ويب
| التاريختاريخ = 6 أوكتوبر 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/21780
| تاريخ الأرشيفأرشيف = 29 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/21780
| العنوانعنوان= Eigrp holdtime
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 30 ديسمبر 2017}}</ref>
 
يجب الانتباه إلى أن آليّة تحديد فشل أو استمرار علاقة الجيران تعمل بشكلٍ مُستقلٍ في كل من طرفي علاقة الجيران. لا يظهر أيّ إشكالٍ إذا استخدمُت نفس قيمة مُؤقّت الانتظار في طرفي علاقة الجيران، ولكن عند تهيئة قيم مُختلفة في الطرفين، فإنّ كل طرف سيستخدم قيمة مُؤقّت الانتظار التي تمّت تهيئتُها في الطرف الآخر كأساس لتحديد حالة علاقة الجيران، لا القيمة التي تمّت تهيئتُها محليّاً.<ref name="Web-63">{{مرجع ويب
| المؤلفمؤلف = Kevin Dorrell
| التاريختاريخ = 25 مايو 2008
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://dorreke.wordpress.com/2008/05/25/eigrp-timers-solution/
| تاريخ الأرشيفأرشيف = 24 ديسمبر 2017
| المسارمسار= https://dorreke.wordpress.com/2008/05/25/eigrp-timers-solution/
| العنوانعنوان= EIGRP Timers – Solution
| الموقعموقع= Word press blog
| اللغةلغة= en
| تاريخ الوصول= 30 ديسمبر 2017}}</ref>
 
ُُيُرسل كل مُوجّه قيمة مُؤقّت الانتظار الخاصّة به ضمن رسائل التعارف ليتمّ اعتمادها في جدول جيران الجار لاحقاً في حال نجاح علاقة الجيران، يجب أن تكون قيمة مُؤقّت الانتظار أكبر من قيمة من مُؤقّت التعارف، وتستحسن سيكسو أن تكون قيمة مُؤقّت الانتظار ثلاث أضعاف قيمة مُؤقّت التعارف.<ref name="Web-66">{{مرجع ويب
| المؤلفمؤلف = Anthony Bruno, Jacqueline Kim.
| التاريختاريخ = 12 ديسمبر 2003
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=102174&seqNum=6
| تاريخ الأرشيفأرشيف = 15 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=102174&seqNum=6
| العنوانعنوان = CCDA Self-Study: RIP, IGRP, and EIGRP Characteristics and Design
| الموقعموقع= Overblog
| اللغةلغة= en
| تاريخ الوصول= 31 ديسمبر 2017}}</ref>
 
سطر 765:
 
يُحدد مُؤقّت الفعاليّة (Active Timer) الزمن الذي يقضيه المسار في الحالة الفعّالة بعد إرسال رسالة الاستعلام قبل أن يعتبره البروتوكول عالقاً في الحالة الفعّالة (Stuck in Active SIA)، يسبب نفاذ مؤقت الفعاليّة اعتبار الوصول إلى الوجهة غير مُمكناً وحذف المسار من [[جدول الطوبولوجيا]] <ref name="Web-57">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/1rfeigrp.html
| تاريخ الأرشيفأرشيف = 26 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/1rfeigrp.html
| العنوانعنوان= Chapter: EIGRP Commands
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref> ويُمكن أن تستخدم رسالة الاستعلام للإبقاء على الحالة الفعّالة (SIA Query) من أجل إعادة ضبط هذا المُؤقّت إلى قيمته الاسميّة بهدف منح المسار مزيداً من الوقت في الحالة الفعّالة لحين انتهاء الحساب.
 
سطر 776:
[[ملف:EIGRP Neighbor state machine -ar.png|تصغير|300بك|[[مخطط الحالة]] لدورة حياة الجار بحسب بروتوكول التوجيه المُحسنّ (EIGRP).]]
 
تصفُ دورة حياة المسار علاقة [[راوتر (حوسبة)|المُوجّه]] الذي يُشغل بروتوكول التوجيه المُحسن (EIGRP) مع جاره. بحسب البروتوكول هناك حالة وحيدة في هذه الدورة، وهي حالة الجار الفعّال، وهو الجار الذي ما يزال الاتصال قائماً معه، ويتحكّم بدورة الحياة هذه مُؤقّتين اثنين هما مُؤقّت التعارف ومُؤقّت الانتظار الخاصّين بالجار، حيث يحدد مُؤقّت التعارف الخاصّ بالجار الزمن الفاصل بين رسائل التعارف التي يُرسلها الجار،<ref name="Web-65">{{مرجع ويب
| التاريختاريخ = 23 فبراير 2014
| مسار أرشيف http://webcache.googleusercontent.com/search?q=cache:http://cisco2960.over-blog.com/2014/02/cisco-eigrp-timers.html
| تاريخ الأرشيفأرشيف = 14 ديسمبر 2017
| المسارمسار= http://cisco2960.over-blog.com/2014/02/cisco-eigrp-timers.html
| العنوانعنوان = Cisco Eigrp Timers
| الموقعموقع= Overblog
| اللغةلغة= en
| تاريخ الوصول= 31 ديسمبر 2017| مسار الأرشيفأرشيف = https://web.archive.org/web/20180522042429/http://cisco2960.over-blog.com/2014/02/cisco-eigrp-timers.html }}</ref> والتي تسبب بدورها إعادة ضبط لقيمة موقت الانتظار في المُوجّه الذي يُشغل البروتوكول.
 
يجب الانتباه إلى أن القيمة الاسمية لمُؤقّت الانتظار الخاصّ بالجار هي القيمة المُكتبسة من الجار نفسه عن طريق رسائل التعارف القادمة منه وليست قيمة المُؤقّت المحليّة، أيّ أن لكل جار قيمة مُؤقّت انتظار خاصّة به يُحددها في رسائل تعارفه.
سطر 791:
 
مع كل استقبال لرسالة تعارف قادمة من الجار يتمّ إعادة ضبط قيمة مؤقت الانتظار الخاص به إلى القيمة الاسميّة مجدداً ليبدأ التناقص مُجدداً نحو الصفر، وطالما بقي تدفّق الرسائل من الجار مُستمراً فإنّ الجار سيظلّ في الحالة الفعّالة، لأن قيمة مُؤقّت التعارف أقل من قيمة مُؤقّت الانتظار، أمّا عند غياب رسائل التعارف لفترة زمنية تفوق قيمة مُؤقّت الانتظار، فإنّ علاقة الجيران ستفشل ولا بد من التخلّص من الجار وإزالته من جدول الجيران.<ref name = "Book-6">{{مرجع كتاب
|المؤلف1مؤلف1= Michael J. Shannon
|العنوانعنوان= CCNP Exams: Exams 642-801, 642-811, 642-821, 642-831
|الصفحةصفحة= 169
|السنةسنة=2004
|الناشرناشر= Que Publishing
|الرقم المعياري= 0789730170
|اللغةلغة= en
}}</ref>
 
سطر 803:
[[ملف:EIGRP route state machine - ar.png|تصغير|300بك|[[مخطط الحالة]] للمسار بحسب بروتوكول التوجيه المُحسّن (EIGRP).]]
 
إنّ المسار بحسب بروتوكول التوجيه المحسن (EIGRP) هو الطريق الذي يتمّ اختياره [[توجيه (شبكات)|لتوجيه]] [[رزمة بيانات|الرزم]] فيه نحو وجهة معيّنة، ولكل مسار ثلاث مُحددات أساسيّة هي الوجهة النهائيّة، و[[وزن(شبكات)|وزن]] المسار، والخطوة التالية فيه. بالنسبة لأي [[راوتر (حوسبة)|مُوجّه]] يُشغل البروتوكول، تبدأ دورة حياة المسار عند اكتشاف وجود الوجهة، عن طريق رسالة تحديث، فيقوم المُوجّه بإضافتها إلى [[جدول توجيه|جدول توجيهه]]، أمّا عند اكتشاف حصول تغيير يخصّ هذا المسار في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]]، فإنّ المُوجّه يبحث في [[جدول الطوبولوجيا]] عن وارثٍ مُلائم، ليجعله وارثاً للمسار وليضيفه لجدول التوجيه. في حال عدم وجود وارثٍ مُلائم، يقوم البروتوكول عندها بإرسال رسائل استعلام نحو الجيران للبحث عن أفضل طريق نحو تلك الوجهة، أي الطريق الأقل وزناً، ثم يقوم البروتوكول بجعل المُوجّه الذي يُعلن ذلك الطريق هو الخطوة التالية فيه، وذلك من خلال جعله وارثاً للمسار.<ref name="Web-58">{{مرجع ويب
| المؤلفمؤلف = Brad Hedlund
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://bradhedlund.com/notes/eigrp/
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= http://bradhedlund.com/notes/eigrp/1rfeigrp.html
| العنوانعنوان= Notes on EIGRP
| الموقعموقع= BradHedlund.com
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017| وصلة مكسورة = yes }}</ref>
 
خلال وجوده في جدول الطوبولوجيا، يمر المسار بحالتين هما:<ref name="ietf-1"/><ref name="Web-59">{{مرجع ويب
| التاريختاريخ = 1 يونيو 2011
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/30822
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/30822
| العنوانعنوان= EIGRP ACTIVE AND PASSIVE
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>
* '''الحالة الفعّالة''' (Active): هي حالة مُؤقّتة لمسارٍ نحو وجهة ما، في هذه الحالة مايزال البحث جاريّاً عن وارثٍ لهذا المسار، وتكون الوجهة النهائيّة للمسار معلُومة، ولكن وزن المسار الكليّ والخطوة التالية فيه مجهولان، ويجري حسابهما. يتمّ الانتقال إلى هذه الحالة عندما يفشل الوراث الحالي، دون وجود وارث مُلائم، وعندها لابد من البحث عن جار جديد ليرث المسار نحو تلك الوجهة. عندما يكون المسار في هذه الحالة فهو خارج الخدمة ولا يُمكن استخدامه.
سطر 829:
=== إعادة الحساب ===
 
عند حصول تغيير في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]]، تُصبح الشبكة غير مُستقرّة، أي تملك [[راوتر (حوسبة)|المُوجّهات]] فيها وجهاتٍ لا يمكن بلوغها، و[[إعادة الحساب (شبكات)|إعادة الحساب]] (Convergence) هي العمليّة التي يتمّ فيها إيجاد مسارات جديدة نحو تلك الوجهات أو حذفها من [[جدول توجيه|جدول التوجيه]]، وتُنجز عمليّة إعادة الحساب عندما يملك كل مُوجّه في الشبكة مساراتٍ فعّالة نحو كل الوجهات، ويُسمّى الزمن المُستغرق لإنجاز عملية إعادة الحساب بزمن إعادة الحساب.<ref name="Web-72">{{مرجع ويب
| المؤلفمؤلف = Lance Cockcroft
| التاريختاريخ = 24 يوليو 2001
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.techrepublic.com/article/understanding-the-protocols-underlying-dynamic-routing/
| تاريخ الأرشيفأرشيف = 30 ديسمبر 2017
| المسارمسار= https://www.techrepublic.com/article/understanding-the-protocols-underlying-dynamic-routing/
| العنوانعنوان= Understanding the protocols underlying dynamic routing
| الموقعموقع= CBS Interactive.
| اللغةلغة= en
| تاريخ الوصول= 31 ديسمبر 2017}}</ref>
 
يُنجز بروتوكول التوجيه المُحسّن (EIGRP) شكلين من أشكال إعادة الحساب، الأول هو إعادة الحساب السريعة، وتحصل عندما يفشل الوارث ولكن المسار يملك وارثاً ملائماً، فيتمّ الانتقال من الوارث إلى الوارث الملائم بشكلٍ مُباشر، ولا تستغرق العملية زمناً يُذكر، أمّا الشكل الثاني، فهو إعادة الحساب البطيئة، وتحصل عند فشل الوارث، وعدم وجود وارثٍ مُلائم له، ولابد عندها من اللجوء إلى رسائل الاستعلام لحساب المسار الجديد، إنّ العامل الأساسيّ في تسريع عمليّة إعادة الحساب لمسارٍ ما هو وجود وارثٍ مُلائم له.<ref name="Web-71">{{مرجع ويب
| المؤلفمؤلف = John Tiso
| التاريختاريخ = 8 ديسمبر 2011
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=1763921&seqNum=5
| تاريخ الأرشيفأرشيف = 30 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=1763921&seqNum=5
| العنوانعنوان= Designing Cisco Network Service Architectures (ARCH): Developing an Optimum Design for Layer 3 (CCDP)
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 31 ديسمبر 2017}}</ref>
 
تُقسّم عملية إعادة الحساب في بروتوكول التوجيه المُحسّن إلى 3 مراحل وظيفياً هي:<ref name="Web-70">{{مرجع ويب
| التاريختاريخ = 2005
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/en/US/technologies/tk648/tk365/tk207/technologies_white_paper0900aecd80243fe7.html
| تاريخ الأرشيفأرشيف = 30 ديسمبر 2017
| المسارمسار= https://www.cisco.com/en/US/technologies/tk648/tk365/tk207/technologies_white_paper0900aecd80243fe7.html
| العنوانعنوان= Bidirectional Forwarding Detection for EIGRP
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 31 ديسمبر 2017}}</ref>
# مرحلة اكتشاف الفشل، وتتحدد بسرعة التجهيرات في اكتشاف حصول الفشل وتفاعلُها معه.
سطر 869:
|الأخير2= Lancaster
|الأول2= D.
|journalصحيفة = Advances in Communications, Computing, Networks and Security
|العنوانعنوان= Routing Protocol Convergence Comparison using Simulation and Real Equipment
|السنةسنة= 2013
|volumeالمجلد = 10
|الصفحةصفحة= 186-194
| الناشرناشر = University of Plymouth Press
| isbn = 1841023582
| المسارمسار = https://www.cscan.org/download/?id=926
}}</ref>
 
سطر 883:
=== ترويسة البروتوكول ===
 
[[ملف:EIGRP Packet - ar.png|تصغير|300بك|[[ترويسة (حوسبة)|ترويسة]] بروتوكول التوجيه المحسن (EIGRP).]]
 
تتكون [[ترويسة (حوسبة)|ترويسة]] بروتوكول التوجيه المُحسن (EIGRP) من 8 حقول أساسيّة، بالإضافة إلى عدد من الثلاثيّات التي يتكون كل منها من ثلاث حقول هي حقل نوع الثلاثيّة، وحقل طول الثلاثيّة وحقل القيمة. إنّ الحقول الثمانيّة الأساسيّة في الترويسة هي:<ref name="Web-16">{{مرجع ويب
| المؤلفمؤلف = Yap Chin Hoong
|| التاريختاريخ = 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/promo/share_the_wealth_contest/finalists/Yap_Chin_Hoong_bsci05_-_EIGRP.pdf
| تاريخ الأرشيفأرشيف = غير معروف
| المسارمسار= https://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/promo/share_the_wealth_contest/finalists/Yap_Chin_Hoong_bsci05_-_EIGRP.pdf
| العنوانعنوان= Chapter 5 EIGRP
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 24 ديسمبر 2017}}</ref>
* ''' حقل الإصدار:''' (Version): طوله (8) [[بت]]، وهو يحتوي على رقم الإصدار الحالي، وهو الإصدار الثاني.
سطر 920:
| 8001 حتى FFFF || مجال محجوز
|}
* '''حقل التحقق الجمعي''' (Checksum): طوله (16) بت، يُستخدم للتحقق من صحة محتويات الترويسة بعد نقلها. إذا لم تتجاوز الترويسة اختبار [[مجموع تدقيق المجموع|التحقق الجمعيّ]] يتم التخلّص من [[رزمة بيانات|الرزمة]].
* '''أعلام''': بطول (32) بت، ويحتوي على أربع أعلام:<ref name="Web-43">{{مرجع ويب
| التاريختاريخ = 27 نوفمبر 2012
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/49175
| تاريخ الأرشيفأرشيف = 26 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/49175
| العنوانعنوان= debug eigrp packets! meaning of flags???
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
** علم الابتداء (INIT-Flag)، وهو البت رقم (1)، ويستخدم في عملية اكتشاف الجيران.<ref name="Web-44">{{مرجع ويب
| التاريختاريخ = 16 يوليو 2003
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/other-network-infrastructure/eigrp-init-flag/td-p/162007
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/other-network-infrastructure/eigrp-init-flag/td-p/162007
| العنوانعنوان= EIGRP Init Flag
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
** علم نمط الاستقبال الشرطي (CR (Conditionally Received)-Flag)، وهو البت رقم (2).
سطر 945:
* '''رقم إشعار تأكيد الوصول''' (Acknowledgment Number): وهو حقل بطول (32) بت، ويستخدم لحمل رقم تتابع لرزمة ما، يُراد تأكيدُ استقبالِها.
* '''مُعرّف المُوجّه الافتراضي''' (Virtual Router Identifier VRID): بطول (16) بت، يُستخدم لتحديد عائلة العناوين المُستعملة. إنّ قيم الثوابت الخاصّة بهذا الحقل مُحددة في مواصفات البروتوكول.
* '''رقم النظام المستقل''' (Autonomous System Number): بطول (16) بت، وهو رقم صحيح مُوجب يتراوح بين (1) و (65,535) يُمثّل مُعرّفاً للنظام الذي أُرسلت منه الرزمة. إنّ تطابق رقم [[نظام مستقل (إنترنت)|النظام المُستقل]] في الرزمة مع رقم النظام المُستقل في [[راوتر (حوسبة)|راوتر]]الذي يستقبلها هو شرطٌ أساسيّ لقبول الرسائل من أيّ جار، وإلا فسيتمّ التخلص من الرزمة.<ref name="Web-9">{{مرجع ويب
| التاريختاريخ = 9 يناير 2015
| مسار الأرشيفأرشيف =http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/wan-routing-and-switching/eigrp-neighbors-with-different-as-numbers/m-p/2746756#M255676
| تاريخ الأرشيفأرشيف = 20 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/wan-routing-and-switching/eigrp-neighbors-with-different-as-numbers/m-p/2746756#M255676
| العنوانعنوان= EIGRP neighbors with different AS numbers
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 21 ديسمبر 2017}}</ref>
* '''ثُلاثيّات (النوع-الطول-القيمة)''' (Type-Length-Value TLV): الثُلاثيّة هي عدد من [[بايت|البايتات]] مُختلفة الطول، مُقسّمة إلى ثلاثة حقول، هم حقل نوع الثُلاثيّة، وحقل طول الثُلاثيّة وحقل القيمة، الذي يختلف طوله بحسب الثُلاثيّة نفسِها، وهو يضمّ بدوره عدداً من الحقول المُختلفة التي تتعلق بنوع الثلاثُيّة. يُمكن أن تضمّ الرزمة أكثر من ثُلاثيّة مُختلفة في نفس الوقت.
تسمح الثُلاثيّات بإضافة إمكانيّات جديدة لبروتوكول التوجيه المُحسّن، أو لدعم ميّزات مُضافة غير موجودة حاليّاً،<ref name="Web-75">{{مرجع ويب
| التاريختاريخ = 25 مايو 2009
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/5834
| تاريخ الأرشيفأرشيف = 19 أوكتوبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/5834
| العنوانعنوان= EIGRP-TLV vs. Header Fields
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 21 أوكتوبر 2017}}</ref> ويتم ترميز نوع الثُلاثيّة بحسب الترميز التالي:
:* يُستخدم البايت الأول من حقل النوع لترميز [[بروتوكول توجيه#البروتوكولات المُوجّه:|البروتوكول المُوجّه:]]
::# عام (لجميع البروتوكولات المُوجّهة): (0x00).
::# [[آي بي في4|الإصدار الرابع من بروتوكول الإنترنت]] (IPv4) يكون : (0x01).
::# [[عنوان آي بي في6|الإصدار السادس من بروتوكول الإنترنت]] (IPv6) يكون : (0x04).
:* يُستخدم البايت الثاني من حقل النوع لترميز نوع الثلاثية من أجل البروتوكول الذي تم تحديده في البايت الأول:<ref name="Web-76">{{مرجع ويب
| الأول = Ravi
| الأخير = Kashyap
| التاريختاريخ = 25 مايو 2009
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.itcertnotes.com/2011/11/eigrp-packet-format.html
| تاريخ الأرشيفأرشيف = 8 ديسمبر 2017
| المسارمسار= http://www.itcertnotes.com/2011/11/eigrp-packet-format.html
| العنوانعنوان= EIGRP Packet Format
| الموقعموقع= Blogspot
| اللغةلغة= en
| تاريخ الوصول= 1 يناير 2018}}</ref>
 
سطر 983:
::# ثلاثية [[مصادقة|مُصادقة]]: (0x02)
::# ثلاثية إصدار البرمجية: (0x04)
::# ثلاثية تتابع [[بث مجموعاتيمتعدد|البثّ المجموعاتيّ]] (0x05)
 
فيما يلي نماذج عن بعض الثلاثيات التي يستخدمها بروتوكول التوجيه المُحسن (EIGRP):<ref name="ietf-1"/>
سطر 996:
 
=== اكتشاف الجيران ===
[[ملف:EIGRP Neighbor Discovery sequence diagram - ar.png|تصغير|300بك|[[مخطط التتابع]] لإنشاء علاقة الجيران بحسب بروتوكول التوجيه المُحسّن (EIGRP). تجري العملية بحسب الخطوات التالية: (1) يُرسل [[راوتر (حوسبة)|المُوجّه]] الأول رسالة تعارف على شكل رسالة [[بث متعدد|بث مجموعاتي]]. (2) يرسل المُوجّه الثاني رسالة تعارف على شكل رسالة بثّ مجموعاتي. (3) يرسل المُوجّه الأول رسالة تحديث فارغة، مع رفع علم الابتداء. (4) يُرسل المُوجّه الثاني رسالة تحديث فارغة، مع رفع علم الابتداء، يُؤكّد فيها استقباله للرسالة في الخطوة الثالثة. (5) يُرسل المُوجّه الثاني كامل معلومات التوجيه، برسالة [[بث منفردفريد|فريدة]]، يُؤكّد أيضاً استقباله للرسالة المُرسلة في الخطوة الرابعة. (6) يُرسل المُوجّه الأول كامل معلومات التوجيه، برسالة فريدة، ويُؤكّد أيضاً استقباله للرسالة المُرسلة في الخطوة الخامسة، لكن الرسالة تٌفقد في الشبكة. (7) بعد 5 ثواني، وبسبب عدم استقباله إشعار تأكيد الوصول، يُعيد الموجّه الثاني الخطوة الخامسة.(8) يستقبل المُوجّه الأول نفس الرسالة للمرة الثانية، فيتخلّص منها، ويعيد إرسال الرسالة في الخطوة السادسة.]]
 
تحصل عمليّة اكتشاف الجيران بين طرفين، هما [[راوتر (حوسبة)|موجّهان]] أو [[عقدة (شبكات)|عُقدتان]] تُشغّلان بروتوكول التوجيه المُحسّن (EIGRP)، بعد تبادل رسائل التعارف، وكنتيجة لنجاح هذه العلاقة يقوم كل مُوجّه بإضافة الطرف الآخر إلى جدول الجيران الخاصّ به،<ref name="Web-36">{{مرجع ويب
| التاريختاريخ =10 مايو 2016
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.computernetworkingnotes.com/ccna-study-guide/eigrp-neighborship-requirements-and-conditions.html
| تاريخ الأرشيفأرشيف = 24 ديسمبر 2017
| المسارمسار= https://www.computernetworkingnotes.com/ccna-study-guide/eigrp-neighborship-requirements-and-conditions.html
| العنوانعنوان= EIGRP Neighborship Requirements And Conditions
| الموقعموقع= Computer Networking Basic Tutorials and Study Guides
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref> بعد ذلك تبدأ مرحلة تبادل معلومات التوجيه، ثُمّ يتمّ الحفاظ على علاقات الجيران فعّالة من خلال استمرار تبادل رسائل التعارف، إن غياب رسائل التعارف لفترة زمنيّة يُحددها مؤقت الانتظار يعني فشل علاقة الجيران.<ref name="Web-38">{{مرجع ويب
| الأول= Kevin
| الأخير = Wallace
| التاريختاريخ = 9 يناير 2017
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://kwallaceccie.mykajabi.com/blog/understanding-eigrp-part-3-eigrp-timers
| تاريخ الأرشيفأرشيف = 23 ديسمبر 2017
| المسارمسار= https://kwallaceccie.mykajabi.com/blog/understanding-eigrp-part-3-eigrp-timers
| العنوانعنوان= Understanding EIGRP – Part 3 (EIGRP Timers)
| الموقعموقع= Kevin Wallace Training, LLC
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
 
لتنجح علاقة الجيران، يجب أن تتطابق المُحددات التالية بين الطرفين:<ref name="Web-34">{{مرجع ويب
| المؤلفمؤلف= Zaheer Aziz, Johnson Lui, Abe Martey, Faraz Shamim.
| التاريختاريخ =26 يوليو 2002
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=27839
| تاريخ الأرشيفأرشيف = 24 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=27839
| العنوانعنوان= Troubleshooting EIGRP
| الموقعموقع= Cisco Systems, Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
# رقم [[نظام مستقل (إنترنت)|النظام المستقل]].
# قيم مُعاملات حساب [[وزن (شبكات)|الوزن]].
# عناوين الشبكة، أي يجب أن يستضيف الطرفان عناوين تنتمي إلى نفس الشبكة، لكن يُستثنى هذا الشرط عندما يكون [[بروتوكول توجيه#البروتوكولات المُوجّهة|البروتوكول المُوجّه]] هو [[عنوان آي بي في6|الإصدار السادس من بروتوكول الإنترنت]] (IPv6).<ref name="Web-39">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/113267-eigrp-ipv6-00.html
| تاريخ الأرشيفأرشيف = 25 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/113267-eigrp-ipv6-00.html
| العنوانعنوان= EIGRP IPv6 Configuration Example
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
 
قد تسبب بعض القضايا الأخرى عدم استقرارٍ في علاقة الجيران، مثل عدم تطابق [[وحدة النقل الأعظمية]] (MTU)، أو بسبب مشاكل تتعلّق بدعم [[بث منفردفريد|البث الفردي]] أو [[بث مجموعاتيمتعدد|البث المجموعاتيّ]] في الشبكة، أو مشاكل تتعلق بجودة الوصلة أو بفشل عملية [[مصادقة]] أو بسبب مشاكل ترتبط بالتهيئة.<ref name="Web-35">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/118974-technote-eigrp-00.html
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/118974-technote-eigrp-00.html
| العنوانعنوان= Troubleshoot Common EIGRP Issues
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref> إنّ عدم تطابق المُؤقّتات ليس شرطاً أساسيّاً لنجاح علاقة الجيران في بروتوكول التوجيه المُحسن، لكنّ الاختيار غير المدروس للقيم قد يسبب فشلاً أو عدم استقرار في علاقة الجيران.<ref name="Web-37">{{مرجع ويب
| التاريختاريخ = 31 مارس 2012
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/41463
| تاريخ الأرشيفأرشيف = 23 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/41463
| العنوانعنوان= EIGRP Neighborship
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 28 ديسمبر 2017}}</ref>
 
تبدأ العملية عندما يتمّ تشغيل البروتوكول في [[راوتر (حوسبة)|مُوجّه]] جديد مُتصل مع شبكة تحتوي موجه آخر يُشغل البروتوكول ويرسل رسائل التعارف فيها، لغرض تبسيط العملية، يُطلق على المُوجّه الجديد اسم الطرف الأول، وعلى الموجه الآخر اسم الطرف الثاني، وتتمّ عملية اكتشاف الجيران وفق الخطوات التالية:<ref name="ietf-1"/>
# يُرسل الطرفان الأول والثاني رسائل تعارف دوريّة، بفواصل زمنيّة يُحددها مُؤقّت التعارف.
# يستقبل كل من الطرفين رسالة التعارف التي أرسلها الطرف الآخر، ويعني ذلك اكتشاف الجار، ويتمّ التحقق من شروط إنشاء علاقة الجيران.
سطر 1٬066:
 
يدعم بروتوكول التوجيه المُحسّن خاصية المنافذ السلبيّة (Passive Interface)، ويعني تفعيل هذه الخاصيّة على المنفذ استمرار تشغيل البروتوكول فيه، ولكن مع إيقاف إرسال أو استقبال رسائل التعارف، بالتالي منع تشكيل علاقات الجيران عبره. ولهذه الميزة استخدامات أمنيّة.<ref name="Web-55">{{مرجع ويب
| التاريختاريخ = 21 يونيو 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/14962
| تاريخ الأرشيفأرشيف = 28 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/14962
| العنوانعنوان= Passive-interface EIGRP command
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref><ref name="Web-56">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13675-16.html
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13675-16.html
| العنوانعنوان= How Does the Passive Interface Feature Work in EIGRP?
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>
 
=== بروتوكول النقل الموثوق ===
 
إنّ بروتوكول النقل الموثُوق (Reliable Transport Protocol RTP) هو جزء من بروتوكول التوجيه المُحسّن (EIGRP)، وهو المسؤول عن تأمين النقل [[وثوقية (شبكات)|الموثوق]]، من خلال اعتماده على حقلي رقم التتابع ورقم إشعار التأكيد الموجُودين في [[ترويسة (حوسبة)|ترويسة]] البروتوكول.<ref name="Web-28">{{مرجع ويب
| الأول= Jeremy
| الأخير = Stretch
| التاريختاريخ = 17 يناير 2009
| http://webcache.googleusercontent.com/search?q=cache:http://packetlife.net/blog/2009/jan/17/rtp-eigrp/
| تاريخ الأرشيفأرشيف = 22 ديسمبر 2017
| المسارمسار= http://packetlife.net/blog/2009/jan/17/rtp-eigrp/
| العنوانعنوان= RTP in EIGRP
| الموقعموقع= Packet life
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017| مسار الأرشيفأرشيف = https://web.archive.org/web/20181017062912/http://packetlife.net:80/blog/2009/jan/17/rtp-eigrp/ }}</ref> لا يستطيع بروتوكول التوجيه المُحسّن الاستفادة من خدمات بروتوكولات [[طبقة النقل]] التي تقدّم هذه [[خدمة (شبكات)|خدمة]] النقل الموثوق لأنّه يعمل في الطبقة التي تسبقُها، وهذا هو سبب اعتماده على بروتوكول مُستقل لإنجاز النقل الموثوق.<ref name="Web-41"/>
 
يُحدد بروتوكول النقل الموثوق مجموعة القواعد التي تضمن وصول رزم البروتوكول بترتيب إرسالها إلى جميع الجيران، وهو يدعم [[بث منفردفريد|البث الفردي]] و[[بث مجموعاتيمتعدد|المجموعاتي]]. يتمّ وضع رقم تتابع خاص بكل [[رزمة بيانات|رزمة]] يجري إرسالُها، ويجب على الجار أن يضع هذا الرقم في حقل رقم إشعار التأكيد في رسالة لاحقة لتأكيد الاستقبال، إذا أُرسلت رزمة موثوقة لبروتوكول التوجيه المُحسّن ولم يصل [[إشعار تأكيد|إشعار لتأكيد]] وصولها، فإنّ البروتوكول يقوم بإعادة إرسالها مرة أخرى نحو نفس الوجهة، ويتحدد زمن انتظار الردّ بمؤقّت خاص هو مؤقت إعادة الإرسال (Retransmission Timeout RTO)، الذي يتمّ حساب قيمته من أجل كل جار اعتماداً على زمن الجولة السلس (Smooth Round-Trip Time SRTT).<ref name="Web-73">{{مرجع ويب
| مسار الأرشيفأرشيف = httphttps://web.archive.org/web/20171231174311/http://routingpacket.blogspot.fr/p/reliable-transport-protocol.html
| تاريخ الأرشيفأرشيف = 31 ديسمبر 2017
| المسارمسار= http://routingpacket.blogspot.fr/p/reliable-transport-protocol.html
| العنوانعنوان= Reliable Transport Protocol
| الموقعموقع= Blogspot
| اللغةلغة= en
| تاريخ الوصول= 31 ديسمبر 2017}}</ref>
 
سطر 1٬110:
|الأخير= Garcia-Lunes-Aceves
|الأول= J. J.
|journalصحيفة = IEEE/ACM Transactions on Networking
|العنوانعنوان= Loop-free routing using diffusing computations
|volumeالمجلد= 1
|issueالعدد = 1
|السنةسنة= 1993
|الشهرشهر= فبراير
|الصفحةصفحة= 130-141
| الناشرناشر = IEEE Press
| doi = 10.1109/90.222913
}}</ref> تُستخدم هذه الخورازمية من أجل بناء المسارات الأقل [[وزن (شبكات)|وزناً]] نحو كل الوجهات المُتاحة، تتعامل هذه الخوارزمية مع [[شبكة حاسوب|الشبكة]] على أنها [[مخططنظرية (رياضيات)المخططات|مُخطط بياني]] مُكوّن من [[رأس (نظرية المخططات)|عُقد]] ووصلات، وهي تضمن إيجاد مسارات خالية من [[مشكلة حلقات التوجيه|الحلقات]] من كل عقدة نحو كل العُقد الأخرى، ويشمل ذلك فترات [[إعادة الحساب (شبكات)|إعادة الحساب]] وعند حصول تغيّرات في [[طوبولوجيا الشبكةشبكة|الطوبولوجيا]]. باستعمال هذه الخوارزمية، يُنجز البروتوكول عملية إعادة حساب سريعة وخالية من الحلقات مع عدم وجود حاجة لتبادل كميّة كبيرة من المعلومات، وهي الأسرع في بعض الحالات مُقارنة [[بروتوكول توجيه عامل بخوارزمية حالة الوصلة|ببروتوكولات التوجيه العاملة بخوازميّة حالة الوصلة]].<ref name="Web-78">{{مرجع ويب
| التاريختاريخ = 28 يوليو 2010
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/wan-routing-and-switching/ospf-eigrp/td-p/1446336
| تاريخ الأرشيفأرشيف = 30 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/wan-routing-and-switching/ospf-eigrp/td-p/1446336
| العنوانعنوان= Small Enterprise Design Profile Reference Guide
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 2 يناير 2018}}</ref>
 
سطر 1٬138:
 
يسمح استخدام وحدات البروتوكول غير المُستقلة لبروتوكول التوجيه المُحسّن بالعمل مع مُختلف البروتوكولات المُوجّهة، تشرف كل وحدة بروتوكول غير مُسستقلة على الأعمال التالية:<ref name="Web-60">{{مرجع ويب
| التاريختاريخ = 8 مايو 2016
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://learningnetwork.cisco.com/thread/97093
| تاريخ الأرشيفأرشيف = 20 ديسمبر 2017
| المسارمسار= https://learningnetwork.cisco.com/thread/97093
| العنوانعنوان= Protocol-Dependent Modules in EIGRP
| الموقعموقع= Cisco System Inc.
| اللغةلغة= en
| تاريخ الوصول= 30 ديسمبر 2017}}</ref>
 
# الحفاظ على جدولي جيران وطوبولوجيا من أجل بروتوكول مُوجّه مُحدد.
# بناء [[رزمة بيانات|الرزم]] الخاصّة ببروتوكول التوجيه المُحسّن بشكلٍ يتوافق مع مُتطلبات بروتوكول مُوجّه مُحدد.
# الربط بين عمل {{وإووصلة إنترويكي|خوارمية نشر التحديثات|Diffusing update algorithm|en|خوارمية نشر التحديثات}}.وجدول التوجيه الخاصّ ببروتوكول مُوجّه مُحدد. بعبارة أخرى، إضافة المسارات التي تختارها الخوارزميّة إلى جدول التوجيه بالشكل المُلائم.
# حساب [[وزن (شبكات)|الأوزان]] وتمريرُها إلى خوارزميّة نشر التحديثات.
# التعامل مع [[قائمة التحكم بالوصول|قوائم التحكّم بالوصول]] الخاصّة ببروتوكول مُوجّه مُحدد.
سطر 1٬156:
=== توزيع الحمل من أجل المسارات غير المتساوية الأوزان ===
 
يمكن للموجه أن يحصل على معلومات التوجيه من أكثر من مصدر، [[توجيه يدوي|كالتوجيه اليدوي،]] أو آليّاً عبر واحد أو أكثر من [[بروتوكول توجيه|بروتوكولات التوجيه]]. في الحالة التي يتعرّف فيها [[راوتر (حوسبة)|المُوجّه]] على مسارين نحو نفس الوجهة، ولكن من مصدرين مختلفين، فإنّه يختار المسار صاحب [[وزن إشرافي (شبكات)|الوزن الإشرافي]] الأقل ويضيفه إلى [[جدول توجيه|جدول التوجيه]]. في الحالة التي يتعرف فيها المُوجّه على مسارين مختلفين نحو نفس الوجهة، ولكن من مصدر واحد، أي في حالة تساوي الوزن الإشرافي، فإنّه يختار المسار صاحب الوزن الأدنى، ويتم تعريف [[وزن (شبكات)|الوزن]] في مُحددات البروتوكول. وفي حال تساوي الوزن الإشرافي ثم تساوي الوزن التقليدي، فإنّ هناك إمكانية لاستخدام كلا المسارين معاً، و[[توزيع حمل (حوسبة)|توزيع الحمل]] فيما بينهما، بدلاً من استخدام مسار واحد فقط، ويسمى ذلك توزيع الحمل بين المسارات متساوية الأوزان، وهي ميزة يدعمها بروتوكول التوجيه المُحسّن.<ref name="Web-4">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html
| تاريخ الأرشيفأرشيف = 18 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html
| العنوانعنوان= How Does Load Balancing Work?
| الموقعموقع= Cisco sytems Inc.
| اللغةلغة= en
| تاريخ الوصول= 19 ديسمبر 2017}}</ref>
 
سطر 1٬168:
| الأول= Petr
| الأخير = Lapukhov
| التاريختاريخ = 1 مايو 2011
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/
| تاريخ الأرشيفأرشيف = 22 ديسمبر 2017
| المسارمسار= http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/
| العنوانعنوان= Understanding Unequal-Cost Load-Balancing
| الموقعموقع= INE, Inc
| اللغةلغة= en
| تاريخ الوصول= 26 ديسمبر 2017}}</ref>
 
لتحقيق ذلك تُستخدم قيمة عدديّة تُسمى عامل التنوع (Variance)، ويكون المجال الخاص بقيم الأوزان المقبولة مُمتداً بين قيمة أفضل وزن وقيمة جداء عامل التنوع معه. إنّ القيمة الإفتراضية لعامل التنوع هي (1)، ويُمكن أي يتمّ ضبطه إلى أي قيمة صحيحة من المجال [128,1].<ref name="Web-5">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html
| تاريخ الأرشيفأرشيف = 18 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html
| العنوانعنوان= How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?
| الموقعموقع= Cisco sytems Inc.
| اللغةلغة= en
| تاريخ الوصول= 19 ديسمبر 2017}}</ref> على سبيل المثال، إذا اكتشف البروتوكول (3) مسارات نحو شبكة ما، وكانت أوزان هذه المسارات هي بالترتيب: (25) و(80) و(110). إنّ أفضل مسار هو المسار صاحب الوزن الأدنى وهو المسار ذو الوزن (25). ستجعل اختيار قيمة عامل التنوع لتكون (4)، أكبر قيمة في مجال القيم المقبولة هي (25x4 =100) وسيكون مجال القيم هو [100,25]، إنّ وزن المسار الثاني يقع ضمن هذا المجال، وسيتم بالتالي توزيع الحمل بين المسارين صاحبي الوزنين (25) و (80) على الترتيب.
 
سطر 1٬189:
 
تستخدم [[مصادقة|المُصادقة]] من قبل بروتوكول التوجيه المُحسّن (EIGRP) كخيار أمنيّ، والسبب الرئيسي من استخدامها هو حماية البروتوكول من استقبال رسائل تحديث من مصادر غير موثوقة، وتسمح هذه الميزة بالتحقق من هوية الطرف الذي يريد إنشاء علاقة الجيران،<ref name="Web-52">{{مرجع ويب
| التاريختاريخ = 25 ديسمبر 2006
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:http://www.ciscopress.com/articles/article.asp?p=687478&seqNum=4
| تاريخ الأرشيفأرشيف = 14 ديسمبر 2017
| المسارمسار= http://www.ciscopress.com/articles/article.asp?p=687478&seqNum=4
| العنوانعنوان= Configuring EIGRP Authentication
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref> بدون استخدام المُصادقة من الممكن أن يتمّ العبث بمحتويات [[جدول توجيه|جدول التوجيه]] من خلال تعريف [[راوتر (حوسبة)|المُوجّه]] بمسارات غير صحيحة بهدف توجيه [[حركة البيانات]] نحو موقع مُعيّن، إمّا [[هجمات الحرمان من الخدمات|لحجب الخدمة]]<ref name="US-CERT">{{مرجع ويب
| الأخير= McDowell
| الأول= Mindi
| التاريختاريخ= 2009
| السنةسنة= 2009
| المسارمسار= https://www.us-cert.gov/ncas/tips/ST04-015
| العنوانعنوان= Security Tip (ST04-015), Understanding Denial-of-Service Attacks
| الموقعموقع= United States Coomputer Emergency Readiness Team (US-CERT)
| اللغةلغة= en
| تاريخ الوصول= 31 يوليو 2017| مسار الأرشيفأرشيف = https://web.archive.org/web/20190522174119/https://www.us-cert.gov/ncas/tips/ST04-015 | تاريخ الأرشيفأرشيف = 22 مايو 2019 }}</ref> أو للإطلاع على محتواها ثُمّ إعادة إرسالها إلى هدفها.
 
يدعم بروتوكول التوجيه المُحسّن [[إم دي5|خوارزمية هضم الرسالة الخامسة]] (MD5) من أجل إنجاز عملية المُصادقة، ولنجاح العملية يجب تزويد الموجه بسلسلة من المفاتيح لتُستخدم في عملية هضم الرسالة،<ref name="Web-51">{{مرجع ويب
| التاريختاريخ = 22 يونيو 2009
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://supportforums.cisco.com/t5/network-infrastructure-documents/configuring-eigrp-authentication/ta-p/3132683
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= https://supportforums.cisco.com/t5/network-infrastructure-documents/configuring-eigrp-authentication/ta-p/3132683
| العنوانعنوان= Configuring EIGRP Authenticatio
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref> يتطلب نجاح تهيئة المصادقة تزامن المُوجّهات على ساعة واحدة، كما يجب الانتباه إلى أن تهيئة المُصادقة على أحد المُوجّهات دون البقية سيسبب فشلاً في علاقة الجيران لحين إتمام تهيئة المصادقة في بقية الشبكة.<ref name="Web-50">{{مرجع ويب
| مسار الأرشيفأرشيف = http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/82110-eigrp-authentication.html
| تاريخ الأرشيفأرشيف = 27 ديسمبر 2017
| المسارمسار= https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/82110-eigrp-authentication.html
| العنوانعنوان= EIGRP Message Authentication Configuration Example
| الموقعموقع= Cisco Systems Inc.
| اللغةلغة= en
| تاريخ الوصول= 29 ديسمبر 2017}}</ref>
 
سطر 1٬237:
 
== وصلات خارجية ==
* [http://webcache.googleusercontent.com/search?q=cache:https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13669-1.html مدخل إلى بروتوكول التوجيه المُحسن (EIGRP)]، مقالة من فريق الدعم التقني في [[سيسكو سيستمز|شركة سيسكو]].
* [httphttps://web.archive.org/web/20160404093326/https://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/Advances_In_EIGRP.pdf عرض تقديمي عن الميزات المتقدمة في بروتوكول التوجيه المُحسّن].
* التعرّف على بروتوكول التوجيه المُحسّن (EIGRP)، مجموعة مقالات ([http://webcache.googleusercontent.com/search?q=cache:http://kwallaceccie.mykajabi.com/blog/understanding-eigrp-part-1 1]،[http://webcache.googleusercontent.com/search?q=cache:http://kwallaceccie.mykajabi.com/blog/understanding-eigrp-part-2 2]،[http://webcache.googleusercontent.com/search?q=cache:https://kwallaceccie.mykajabi.com/blog/understanding-eigrp-part-3-eigrp-timers 3]) بقلم كيفن والاس.
{{بروتوكولات الإنترنت}}