ستتحدث هذه المقالة عن EIGRP وتناقش كيفية عمل هذا البروتوكول. EIGRP هو بروتوكول ناقل المسافة ، في بعض الأحيان يقال أنه هجين ، لكنه ليس كذلك. اقرأ
بداية المقالة على OSPF وسوف تفهم لماذا EIGRP هو بروتوكول ناقل عن بعد. EIGRP هو بروتوكول توجيه ديناميكي متقدم للمسافات تم تطويره بواسطة Cisco. دعنا نحصل على حق. سنستخدم الطوبولوجيا التالية:
قم بتشغيل EIGRP على vIOS1 و vIOS2 ، انظر كيف يتم نقل المعلومات بين أجهزة التوجيه. بمجرد تنشيط EIGRP على جهاز التوجيه ، يبدأ جهاز التوجيه في إرسال حزم Hello. نقوم أيضًا بإدراج أنواع أخرى من الرسائل المستخدمة في EIGRP.
- مرحبًا - تستخدم أجهزة التوجيه حزم ترحيب لاكتشاف الجيران. يتم إرسال حزم الإرسال المتعدد ولا تتطلب تأكيد الاستلام.
- تحديث - يحتوي على معلومات حول تغيير المسارات. يتم إرسالها فقط إلى أجهزة التوجيه المتأثرة بالتحديث. يمكن إرسال هذه الحزم إلى جهاز توجيه محدد (أحادي الإرسال) أو مجموعة من أجهزة التوجيه (الإرسال المتعدد). يتم تأكيد استلام حزمة التحديث عن طريق إرسال ACK.
- استعلام - عندما يحسب جهاز التوجيه المسار وليس له خلف عملي ، فإنه يرسل حزمة استعلام إلى جيرانه لتحديد ما إذا كان لديهم خلف عملي لهذه الوجهة. عادة ، يتم إرسال حزم الاستعلام عن طريق الإرسال المتعدد ، ولكن قد يكون هناك أحادي الإرسال. يتم تأكيد استلام حزمة الاستعلام عن طريق إرسال ACK بواسطة مستقبل الحزمة.
- رد - يرسل جهاز التوجيه حزمة رد استجابة لحزمة الاستعلام. يتم إرسال حزم الرد أحادية الإرسال إلى الشخص الذي أرسل حزمة الاستعلام. يتم تأكيد تلقي حزمة الرد عن طريق إرسال ACK.
- ACK - حزمة تؤكد استلام حزم التحديث والاستعلام والرد. يتم إرسال حزم ACK أحادية الإرسال وتحتوي على رقم إقرار. في الواقع ، هذه حزم مرحب بها لا تنقل البيانات. يتم استخدام التسليم غير المضمون.
هناك أيضًا حزم SIA ، لكننا سنتحدث عنها أدناه.
يتم إرسال الحزم إلى عنوان الإرسال المتعدد 224.0.0.10 كل 5 ثوانٍ (Hello Timer) ، ويكون Hold Timer 15 ثانية = 3 فواصل مرحبًا ، وإذا لم يتم استلام حزم ترحيب من أحد الجيران خلال هذا المؤقت ، فسيتم إزالة الجار من قائمة الجيران. تبدو الحزمة كما يلي:
تحتوي الحزمة على معلمات المعاملات (K1 ، K2 ، K3 ، K4 ، K5 ، K6) ، وتعليق الموقت ورقم النظام المستقل. تُستخدم المعاملات (K1 ، K2 ، K3 ، K4 ، K5 ، K6) في حساب المقياس ، وسنتحدث عنها لاحقًا ، بالإضافة إلى مؤقتات EIGRP. من المهم الآن التحدث عن النظام المستقل (AS). لتنشيط EIGRP ، يجب تعيين عملية EIGRP معينة لرقم ، كما هو الحال في OSPF. ولكن على عكس OSPF ، لا يمكن تحديد هذا الخيار بشكل عشوائي لكل جهاز توجيه ، يجب أن يكون هو نفسه لجميع أجهزة التوجيه. إذا تلقى جهاز التوجيه حزمة Hello مع AS مختلفة عن ذلك ، فلن تكون هناك علاقة جوار.
لكي تصبح أجهزة التوجيه جيرانًا ، يجب استيفاء الشروط التالية:
- يجب مصادقة أجهزة التوجيه ،
- يجب أن تكون أجهزة التوجيه في نفس AS ،
- يجب إنشاء علاقات الجوار على العناوين الأساسية (عند وصول حزمة مرحبا ، يتحقق الموجه مما إذا كان عنوان المرسل للشبكة ينتمي إلى العنوان الأساسي للواجهة) ،
- يجب أن تتطابق قيم المعاملات K.
لكي تصبح أجهزة التوجيه جوارًا لـ EIGRP ، لا يجب أن تتطابق مع Hello and Hold time. يستخدم جهاز التوجيه قيم المؤقت التي تم تلقيها من الجار. إذا تم تغيير مؤقت Hello أو Hold على أحد أجهزة التوجيه ، فسيستخدم جيران هذا الموجه هذه القيم. لكي يستخدم جهاز التوجيه قيمًا أخرى ، من الضروري تغيير المؤقت على الواجهة المجاورة للجار. بعد تبادل حزم Hello ، يتم إرسال حزمة تحديث ، لكنها لا تحتوي بعد على مسارات ، وتحتوي على علامة Init ، والتي تخبر أجهزة التوجيه عن بدء تبادل المعلومات حول المسارات. يتم إرسال هذه الحزمة مباشرة إلى عنوان جهاز التوجيه. بعد تبادل هذه الرسائل ، يرسل كل موجه حزمة تحديث مع توجيهات إلى عنوان الإرسال المتعدد 224.0.0.10:
كما ترى ، لا تحتوي حزمة التحديث على أي مقياس ، ولكن فقط معلومات مثل عرض النطاق الترددي والتأخير و MTU وما إلى ذلك. بعد تلقي هذه المعلومات ، يقوم جهاز التوجيه نفسه بحساب المقياس باستخدام معاملات K1-K6. يمكن إرسال هذه الحزم إما إلى جهاز توجيه محدد أو الإرسال المتعدد. بشكل عام ، هناك ثلاثة أنواع من التحديثات:
- غير دورية (غير دورية) - لا يتم إرسال التحديثات على فترات منتظمة ، ولكن عندما يتغير الهيكل أو القياس ؛
- جزئي (جزئي) - لا يتم نقل جميع المعلومات من جدول التوجيه في التحديثات ، ولكن فقط التغييرات ؛
- مقيد - يتم إرسال التحديثات فقط إلى أجهزة التوجيه المعنية.
تبدو الأحياء على مستوى الحزمة كما يلي:
قد تلاحظ أنه بالإضافة إلى Hello و Update المدرجين من قبلنا ، هناك أيضًا Hello (ACK) والرقم يساوي عدد حزم التحديث المرسلة إلى عنوان الإرسال المتعدد. الأمر كله يتعلق ببروتوكول RTP. يتحكم بروتوكول RTP في عملية إرسال حزم EIGRP ويوفر:
- تسليم الطرود مضمون.
- الحفاظ على ترتيب الحزم.
هذه هي الأشياء. ماذا لدينا؟ تبادلت التوجيهات حزم التحديث ، والآن حان الوقت لإنشاء جدول توجيه. تتم معالجة كل تحديث واستبدال البيانات (عرض النطاق الترددي ، والتأخير ، وما إلى ذلك) في صيغة خاصة ، يتم حساب المقياس:
تبدو هذه الصيغة رائعة ، لكن أفضل شيء عنها هو أنك قد لا تعرفها ، فقط اعلم أن شيئًا من هذا القبيل موجود. والحيلة الرائعة الأخرى هي أن معاملات EIGRP الافتراضية هي:
- K1 = 1
- K2 = 0
- K3 = 1
- K4 = 0
- K5 = 0
وتتحول الصيغة فقط إلى متري = عرض النطاق الترددي + تأخير. لذلك ، من المهم جدًا أن تكون المعاملات على جميع أجهزة التوجيه هي نفسها ، بحيث لا توجد مشاكل بسبب اختلاف المقاييس على أجهزة التوجيه. لنتحدث عن البيانات في التحديث بمزيد من التفاصيل.
- عرض النطاق الترددي - يتم تحديد الحد الأدنى للقيمة بين قنوات النطاق الترددي المؤدي إلى الشبكة وإرسالها إلى التحديث.
- Delay - يلخص تأخير جميع القنوات المؤدية إلى هذه الشبكة.
- الموثوقية - أسوأ مقياس للموثوقية على طول الطريق ، استنادًا إلى المحافظة على الحياة
- تحميل - أسوأ مؤشر لتحميل الرابط على طول الطريق ، بناءً على معدل الحزم وعرض النطاق الترددي المكون على الواجهة
- MTU هو أصغر MTU على طول الطريق. على الرغم من حقيقة أنه مستخدم في التحديث ، إلا أنه لا يشارك في حساب المقياس نفسه.
كما ذكر أعلاه ، يتم استخدام النطاق الترددي والتأخير بشكل افتراضي. نادرًا ما تكون المعلمات المتبقية ضرورية عند الحاجة ، ولكن بمساعدة منها يمكن إجراء تعديل أدق للمقياس. وبالتالي ، في حزمة التحديث ، يمرر جهاز التوجيه المسار والبيانات المرتبطة به ، ولا يرسل المقياس نفسه. يحسب جهاز التوجيه الذي تلقى التحديث المقياس وفقًا للصيغة ، ويقرر بناءً على المقاييس ما إذا كان سيتم توجيه المسار إلى جدول التوجيه أم لا. من المهم أيضًا ملاحظة أن
جهاز التوجيه يرسل فقط تلك المسارات التي يستخدمها. دعونا نرى كيفية بناء جدول الطوبولوجيا.
جدول الطوبولوجيا - قائمة بالطرق المستفادة من كل جار. يخزن جدول الهيكل أيضًا المقياس الذي يقوم كل جار بالإبلاغ عنه لكل مسار (AD) والمقياس الذي سيستخدمه الموجه المحلي للوصول إلى المسار عبر الجوار (FD).
من الضروري شرح ما هي م و FD. سنقوم بتكوين EIGRP على جميع أجهزة التوجيه الخاصة بنا. أيضًا ، لتجنب الأعداد المركبة في القياس ، نقوم بتغيير المعاملات من K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0 إلى K1 = 0 K2 = 0 K3 = 1 K4 = 0 K5 = 0. وبالتالي ، سيكون لدينا 256 * صيغة التأخير وأيضًا نحصل على طريقة سهلة لمعالجة المقاييس عن طريق تغيير معلمة التأخير على الواجهات. مع الأخذ في الاعتبار أن التأخير في الواجهات = ثانية واحدة ، فإن كل ارتباط ، إذا كنت تستخدم مصطلحات OSPF ، يكلف 256. لنرى ما هو جدول الهيكل على vIOS1:
عرض vIOS1 # طوبولوجيا ip eigrp
جدول طوبولوجيا EIGRP-IPv4 لـ AS (1) / ID (192.168.1.1)
الرموز: P - سلبي ، A - نشط ، U - تحديث ، Q - استعلام ، R - رد ،
ص - رد الحالة ، حالة sia
ص 192.168.3.0/24 ، 1 خلفا ، FD هو 512
عبر 192.168.13.3 (512/256) ، GigabitEthernet0 / 0
ص 192.168.2.0/24 ، 1 خلفا ، FD هو 512
عبر 192.168.12.2 (512/256) ، GigabitEthernet0 / 3
ص 192.168.25.0/24 ، 1 خلفا ، FD هو 512
عبر 192.168.12.2 (512/256) ، GigabitEthernet0 / 3
ص 192.168.35.0/24 ، 1 خلفا ، FD هو 512
عبر 192.168.13.3 (512/256) ، GigabitEthernet0 / 0
ص 192.168.12.0/24 ، 1 خلفا ، FD 256
عبر Connected ، GigabitEthernet0 / 3
ص 192.168.45.0/24 ، 1 خلفا ، FD هو 512
عبر 192.168.14.4 (512/256) ، GigabitEthernet0 / 2
ص 192.168.0.0/24 ، 1 خلفا ، FD 256
عبر Connected ، GigabitEthernet0 / 1
ص 192.168.13.0/24 ، 1 خلفا ، FD 256
عبر Connected ، GigabitEthernet0 / 0
ص 192.168.14.0/24 ، 1 خلفا ، FD 256
عبر Connected ، GigabitEthernet0 / 2
ص 192.168.5.0/24 ، 3 خلفا ، FD هو 768
عبر 192.168.12.2 (768/512) ، GigabitEthernet0 / 3
عبر 192.168.13.3 (768/512) ، GigabitEthernet0 / 0
عبر 192.168.14.4 (768/512) ، GigabitEthernet0 / 2
إذا نظرت ، على سبيل المثال ، إلى الشبكة - 192.168.5.0/24 ، ستلاحظ ثلاثة مسارات من خلال vIOS2 و vIOS3 و vIOS4 بنفس المقاييس. بالنسبة إلى 192.168.5.0/24 FD ، تكون جميع المسارات متساوية - 768 و AD - 512. فلنقدم تعريفًا من مقال آخر ونحاول شرح:
- المسافة المُعلنة (AD) ، والمعروفة أيضًا بالمسافة المُبلغ عنها (RD) ، هي تكلفة المسافة بين جهاز التوجيه المجاور الذي يعلن عن المسار وشبكة الوجهة.
- مسافة مناسبة (FD) - تكلفة المسافة من جهاز التوجيه المحلي إلى الشبكة الوجهة = م ، التي تعلن عن جهاز التوجيه المجاور + تكلفة المسافة بين جهاز التوجيه المحلي وجهاز التوجيه المجاور.
P 192.168.5.0/24 ، 3 خلفاء ، FD هو 768 عبر 192.168.14.4 (768/512) ، GigabitEthernet0 / 2
دعونا نفحص هذا الصف من جدول الهيكل على vIOS1. علمت vIOS1 عن الطريق من vIOS4 (192.168.14.4). نظرًا لأن vIOS1 يفصل ثلاثة روابط من 192.168.5.0/24 ، فإن مقياس FD مع إعداداتنا سيكون 3 * 256 = 768. و AD هو مقياس المسار نسبة إلى جهاز التوجيه (vIOS4) الذي أعلن عن هذه الشبكة. م هو مقياس FD لهذا الطريق على vIOS4. دعونا نلقي نظرة على جدول الطوبولوجيا على vIOS4:
P 192.168.5.0/24 ، 1 خلفا ، FD هو 512 عبر 192.168.45.5 (512/256) ، GigabitEthernet0 / 1
م على vIOS1 = FD على vIOS4. صمت محير ، لكن حاول أن تشرح منطق العمل. يرسل جهاز التوجيه الذي يعلن المسار المعلمات (Bandwithd ، Delay ، إلخ) للمسار في رسالة التحديث دون مراعاة الارتباط بين جهاز التوجيه الذي يتم الإعلان عنه. أي أن vIOS4 يأخذ فقط في الاعتبار معلمات رابطين: vIOS4 Gi0 / 1 - vIOS5 Gi0 / 1 و vIOS5 Gi0 / 0 - VPC. بعد تلقي التحديث ، vIOS1 ، استبدال المعلمات التي تم الحصول عليها في الصيغة ، يحسب ماذا؟ هذا صحيح - م = 512. بعد أن تأخذ معلمات الارتباط من أين جاء المسار ، vIOS1 Gi0 / 2 - vIOS4 Gi0 / 2 واستبدالها في الصيغة مرة أخرى. تحسب ، تحصل على الرقم 256 وتضيفه مع م (512) ، نحصل على FD - 768. هذه هي الأشياء! لكن لماذا كل هذه الطقوس؟
وكل ذلك من أجل خلق قاعدة خاصة تسمى
حالة الجدوى ، وهي إحدى وسائل الحماية ضد تكوين الحلقات والتقارب السريع.
دعنا نحدد المصطلحات التالية:
- اللاحقة هو جهاز توجيه مجاور مع مسار خالٍ من الحلقات وأقل تكلفة إلى الشبكة الوجهة.
- خلف قابل للتطبيق - موجه نسخ احتياطي بمسار بدون حلقات (يجب أن يكون اللاحق المجدي أقل من FD للمسار اللاحق الحالي).
- الشرط المجدي - يجب أن يكون الخليط المجدي للإعلان أقل من FD للمسار اللاحق الحالي.
لتوضيح كيفية عمل كل شيء وإظهار التفاصيل الدقيقة ، تحتاج إلى تغيير بعض المقاييس. لنفعل ما يلي ، قم بتغيير التأخير حتى يكون لدينا مقاييس الارتباط هذه:
يتم ذلك باستخدام أمر تأخير على الواجهة. الآن قلنا - تأخير = 1 والمقياس 256. لنرى المقاييس التي نحصل عليها للشبكة 192.168.5.0/24 على جهاز التوجيه vIOS1:
- عبر vIOS2 - FD = 2304 ، AD = 1280
- عبر vIOS4 - FD = 1024 ، AD = 768
- عبر vIOS3 - FD = 1536 ، AD = 768
نظرًا لأننا نرى أن أفضل FD سيكون للطريق عبر vIOS4 ، فستتم إضافته إلى جدول التوجيه العام ، ويسمى هذا المسار
Successor :
vIOS1 # تظهر eigrp مسار IP
الرموز: L - محلي ، C - متصل ، S - ثابت ، R - RIP ، M - محمول ، B - BGP
D - EIGRP ، EX - EIGRP خارجي ، O - OSPF ، IA - OSPF
N1 - OSPF NSSA النوع الخارجي 1 ، N2 - OSPF NSSA النوع الخارجي 2
E1 - النوع الخارجي OSPF 1 ، E2 - النوع الخارجي OSPF 2
i - IS-IS ، su - ملخص IS-IS ، L1 - IS-IS المستوى 1 ، L2 - IS-IS المستوى 2
ia - المنطقة الداخلية IS-IS ، * - افتراضي المرشح ، U - المسار الثابت لكل مستخدم
o - ODR ، P - مسار ثابت يتم تنزيله دوريًا ، H - NHRP ، l - LISP
أ - طريق التطبيق
+ - طريق منسوخ ،٪ - تجاوز المرحلة التالية ، p - تجاوزات من PfR
لم يتم تعيين بوابة الملاذ الأخير
D 192.168.2.0/24 [90/512] عبر 192.168.12.2، 06:01:31، GigabitEthernet0 / 3
D 192.168.3.0/24 [90/1024] عبر 192.168.13.3، 06:01:28، GigabitEthernet0 / 0
D 192.168.5.0/24 [90/1024] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
D 192.168.25.0/24 [90/1024] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
D 192.168.35.0/24 [90/1024] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
D 192.168.45.0/24 [90/768] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
ماذا سيحدث للطريقتين الأخريين - سيتم فحصهما لمعرفة حالة FS (حالة قابلة للتنفيذ). يمر المسار عبر vIOS3 بهذا الشرط AD (عبر vIOS3) = 768 <1024 = FD (عبر vIOS1). لذلك ، هذا المسار ، على الرغم من أنه لن يتم إضافته إلى جدول التوجيه العام ، سيتم تخزينه في جداول الهيكل:
عرض vIOS1 # طوبولوجيا ip eigrp
جدول طوبولوجيا EIGRP-IPv4 لـ AS (1) / ID (192.168.1.1)
الرموز: P - سلبي ، A - نشط ، U - تحديث ، Q - استعلام ، R - رد ،
ص - رد الحالة ، حالة sia
ص 192.168.3.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.13.3 (1024/256) ، GigabitEthernet0 / 0
ص 192.168.2.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.12.2 (1024/256) ، GigabitEthernet0 / 3
ص 192.168.25.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.14.4 (1024/768) ، GigabitEthernet0 / 2
عبر 192.168.13.3 (1536/768) ، GigabitEthernet0 / 0
ص 192.168.35.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.14.4 (1024/768) ، GigabitEthernet0 / 2
عبر 192.168.13.3 (1280/512) ، GigabitEthernet0 / 0
ص 192.168.12.0/24 ، 1 خلفا ، FD هو 768
عبر Connected ، GigabitEthernet0 / 3
ص 192.168.45.0/24 ، 1 خلفا ، FD هو 768
عبر 192.168.14.4 (768/512) ، GigabitEthernet0 / 2
ص 192.168.0.0/24 ، 1 خلفا ، FD هو 512
عبر Connected ، GigabitEthernet0 / 1
ص 192.168.13.0/24 ، 1 خلفا ، FD هو 768
عبر Connected ، GigabitEthernet0 / 0
ص 192.168.14.0/24 ، 1 خلفا ، FD 256
عبر Connected ، GigabitEthernet0 / 2
ص 192.168.5.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.14.4 (1024/768) ، GigabitEthernet0 / 2
عبر 192.168.13.3 (1536/768) ، GigabitEthernet0 / 0
لا يحتوي على مقياس أفضل مسار ، أي أنه ليس خلفًا ، ولكنه يلعب دور مسار احتياطي ، وإذا خسر الخلف ، فسيحل مكانه على الفور. هذا يحقق تقارب سريع للغاية للبروتوكول ، ولكن أكثر من ذلك لاحقًا. يسمى هذا المسار
خليفة عملي . وماذا سيحدث للطريق الثالث؟ لا شيء ، لا يفي بشرط FC (1280> 1024) ولن يؤخذ في الاعتبار لحمايته من التكرار. يمكن رؤية جميع المسارات التي تم تلقيها من خلال التحديث ولكن لم يتم اختبارها بواسطة FC باستخدام الأمر show ip eigrp topology all-links. ليس من الواضح لماذا تحمي حالة FS من تكوين الحلقات ، فلنحاول الآن شرح ذلك. من المهم أن تعرف أنه عند دراسة بروتوكول EIGRP ، من الضروري فهم مبدأ حالة FC والغرض الذي يتم استخدامه من أجله. خذ بعين الاعتبار طوبولوجيا معدلة قليلاً (إضافة رابط بين vIOS2 و vIOS4) ، واستخدم أيضًا أكثر المقاييس بدائية:
سيكون المسار إلى الشبكة 192.168.5.0/24 هو نفسه مع AD و FD:
- vIOS4 - عبر vIOS5 ، AD = 5 ، FD = 10.
- vIOS1 - عبر vIOS4 ، AD = 10 ، FD = 11.
- vIOS3 - عبر vIOS1 ، AD = 11 ، FD = 12.
ولكن سيتلقى vIOS4 تحديثًا من vIOS2 ، والذي سيحتوي على الطريق إلى الشبكة 192.168.5.0/24 عبر vIOS2 بالمقياس - AD = 12 ، FD = 15. من الواضح أنه لا يمكن أن يكون خليفة ، إذا اختير هذا المسار فجأة من قبل خليفة عملي ، ثم إذا وقع الخلف في vIOS4 ثم اختار الخلف هذا المسار ، فستحدث حلقة. لكن FC لن يسمح بتعيين هذا المسار كـ FS كـ AD = 12> 10 = FD. يحتوي المسار إلى vIOS2 على المسار عبر vIOS4 ، وعلى أي حال ، يتضمن إعلان AD أيضًا FD vIOS4. أي أن م على vIOS2 يحتوي على الروابط التالية:
12 = AD على vIOS2 = Gi0 / 3 vIOS3 + Gi0 / 2 vIOS4 + Gi0 / 1 vIOS5 + eth0 VPC5 ، حيث Gi0 / 1 vIOS5 + eth0 VPC5 = FD = 10 - هذا هو FD vIOS4 ومن المستحيل أن يكون AD <FD أقل.
وبالتالي ، يفحص الشرط FC المسار لوجود نفسه في هذا الطريق. فقط المسارات التي تفي بهذا الشرط يمكن أن تضمن عدم وجود حلقات. قد تكون هناك حالات عندما لا يخلق المسار حلقة ، ولكن في نفس الوقت لا يفي بشرط FC ، فلن نستخدمه ، وفي مثل هذه الحالات نختار استقرار الشبكة. إذا كنت تتعمق ، فإن الحالة بسيطة للغاية وبديهية. تسمى الخوارزمية التي تحدد أفضل المسارات في بروتوكول EIGRP
DUAL . لننظر الآن في بروتوكول EIGRP لمسألة التقارب في فقدان الطريق الرئيسي. دعونا نعود إلى طوبولوجيانا الكبيرة القديمة ونتخيل أن vIOS4 قد انتهى. اعتمادًا على كيفية اختفاء vIOS4 ، سيكون السلوك مختلفًا قليلاً ، ولكنه سيختلف عند انطلاق المشغل. إذا عطلنا ، على سبيل المثال ، واجهة Gi 0/2 على vIOS1 ، ثم اكتشف vIOS1 على الفور فقدان أحد الجيران وبدأ في التمثيل ، إذا اختفى الجار دون سابق إنذار ، فسيعمل Hold Timer بعد عدم تلقي حزم Hello لمدة 15 ثانية:
D 192.168.2.0/24 [90/512] عبر 192.168.12.2، 06:01:31، GigabitEthernet0 / 3
D 192.168.3.0/24 [90/1024] عبر 192.168.13.3، 06:01:28، GigabitEthernet0 / 0
D 192.168.5.0/24 [90/1024] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
D 192.168.25.0/24 [90/1024] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
D 192.168.35.0/24 [90/1024] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
D 192.168.45.0/24 [90/768] عبر 192.168.14.4، 06:01:28، GigabitEthernet0 / 2
ص 192.168.3.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.13.3 (1024/256) ، GigabitEthernet0 / 0
ص 192.168.2.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.12.2 (1024/256) ، GigabitEthernet0 / 3
ص 192.168.25.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.14.4 (1024/768) ، GigabitEthernet0 / 2
عبر 192.168.13.3 (1536/768) ، GigabitEthernet0 / 0
ص 192.168.35.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.14.4 (1024/768) ، GigabitEthernet0 / 2
عبر 192.168.13.3 (1280/512) ، GigabitEthernet0 / 0
ص 192.168.12.0/24 ، 1 خلفا ، FD هو 768
عبر Connected ، GigabitEthernet0 / 3
ص 192.168.45.0/24 ، 1 خلفا ، FD هو 768
عبر 192.168.14.4 (768/512) ، GigabitEthernet0 / 2
ص 192.168.0.0/24 ، 1 خلفا ، FD هو 512
عبر Connected ، GigabitEthernet0 / 1
ص 192.168.13.0/24 ، 1 خلفا ، FD هو 768
عبر Connected ، GigabitEthernet0 / 0
ص 192.168.14.0/24 ، 1 خلفا ، FD 256
عبر Connected ، GigabitEthernet0 / 2
ص 192.168.5.0/24 ، 1 خلفا ، FD هو 1024
عبر 192.168.14.4 (1024/768) ، GigabitEthernet0 / 2
عبر 192.168.13.3 (1536/768) ، GigabitEthernet0 / 0
لقد أحضرت جدول التوجيه والهيكل مرة أخرى للراحة ، حتى تتمكن من فهم كيفية عمل جهاز التوجيه في كل مسار ، تحتاج إلى معرفة الحالة التي كانت عليها من قبل. على سبيل المثال ، المسار الذي ناقشناه سابقًا ، سيتم فقد المسار 192.168.5.0/24 ، ولكن كان يحتوي على FS في جدول الهيكل ، وبالتالي ، بمجرد فقدان المسار الرئيسي ، سيأخذ مكانه في جدول التوجيه. سؤال مثير للاهتمام هو ما الذي سيحدث للطرق بدون FS. لكن القليل من الأجهزة:
يمكن أن تكون الإدخالات في جدول الهيكل في حالتين: نشطة وسلبية. يكون المسار في حالة سلبية عندما يكون المسار مستقرًا ولا يتم البحث عن أفضل مسار. في حالة نشطة - إذا كنت تبحث عن أفضل طريق. يتم إجراء بحث عن المسار عندما لا يكون هناك خلف مجدي للشبكة الوجهة. يقوم جهاز التوجيه ، بحثًا عن مسار أفضل ، بإرسال طلب (إرسال حزمة استعلام) إلى كل جهاز توجيه مجاور. إذا كان الجار لديه طريق إلى الشبكة الوجهة ، فإنه يجيب (يرسل حزمة رد) ، إذا لم يكن هناك طريق ، يرسل الجار طلبًا إلى جيرانه. يقارن جهاز التوجيه جميع FDs للوصول إلى شبكة معينة ، ويحدد المسار بأصغر FD ، ويضعه في جدول التوجيه. يمكن لجدول الهيكل تخزين 6 مسارات لشبكة المستلم (الأساسي والنسخ الاحتياطي).
المسارات التي فقدت ولم يكن لديها FS ستنتقل إلى Active و vIOS1 سيبدأ بالسؤال عن جيرانهم المتبقين. يتم ذلك باستخدام رسائل الاستعلام.
سيرسل vIOS1 رسائل الاستعلام إلى موجهات vIOS2 و vIOS3 ، حيث سيوضح بشكل صريح المسارات التي يحتاجها - في حالتنا ، ستكون هذه المسارات 192.168.14.0/24 ، 192.168.45.0/24. بهذه الرسالة ، يقوم vIOS1 أيضًا بإعلام أجهزة التوجيه التي توجه عبر vIOS1 إلى هذه الشبكات بأنها غير قابلة للاستخدام. يتم ذلك عن طريق تحديد معلمة Delay: Infifnity في مقياس هذا المسار ، أي أن المقياس كبير بشكل لا نهائي. بمجرد تلقي أجهزة التوجيه مثل هذه الرسائل ، سيتم حذف هذه المسارات من خلال vIOS1. هذه التكنولوجيا تسمى Poison Reverse.. يستخدم Poison Reverse أيضًا لتحديث الرسائل ، سأتحدث عن ذلك لاحقًا. بعد تلقي استعلام مع طلب المسارات 192.168.14.0/24 و 192.168.45.0/24 ، سيرى vIOS2 و vIOS3 ما إذا كان لديهم هذه المسارات ، والتي يستخدمونها ، إن وجدت ، سيرسلون على الفور ردًا بمقاييس جديدة لهذه المسارات. vIOS2 و vIOS3 كما نعلم لم يفقدوا طريقهم ، لذا سيرسلون الرد على الفور. إذا لم يكن الموجه المطلوب أيضًا لديه هذا المسار ، فسيتم إعادة توجيه الاستعلام إلى جيرانه وما إلى ذلك. ستنتظر vIOS1 الرد من vIOS2 و vIOS3 ثم يدخل Active Timer إلى المشهد ، والذي يبدأ بمجرد إرسال الاستعلام:Timer Active- الفترة الزمنية التي يمكن خلالها أن يظل المسار في الحالة النشطة. إذا انتهت صلاحية المؤقت قبل تلقي جميع الردود من الجيران (رد) ، فإن جهاز التوجيه يضع المسار في حالة عالقة. بالإضافة إلى ذلك ، تم قطع علاقات الحي مع الجيران الذين لم يتلقوا أي رد. بشكل افتراضي ، هذا المؤقت هو 3 دقائق.أي ، إذا لم يتم تلقي الرد في غضون 3 دقائق ، على الرغم من حزم Hello ، فسيتم تقسيم الحي وهذا سيئ جدًا. على الرغم من حقيقة أن 3 دقائق مثل الخلود لمثل هذه البروتوكولات ، مثل هذه الحالات ممكنة مع طوبولوجيا كبيرة. للحماية من القطع الخاطئ لعلاقة الجوار ، تم اختراع رسائل خاصة - SIA-Query و SIA-Reply.لتحسين استجابة جهاز التوجيه لحالة المسار النشط ، يتم تقديم نوعين من الرسائل بالإضافة إلى ذلك:- استعلام SIA - يتم إرساله بعد 1.5 دقيقة (افتراضي) للتحقق من حالة جهاز توجيه متصل مباشرة. من أجل ذلك ، إذا فُقد المسار خلف الجار (بينما كان الاتصال مع الجار طبيعيًا) ، فلن تتم إعادة تعيين علاقات الجوار مع جهاز التوجيه المتصل مباشرةً. لا يتطلب تأكيد الاستلام. بعد إرسال ثلاث رسائل وعدم تلقي رد ، يتم اعتبار الجار لأسفل وإزالة المسار من جدول الهيكل.
- رد SIA - تم إرساله ردًا على استعلام SIA. لا يتطلب تأكيد الاستلام.
بعد 1.5 دقيقة ، إذا لم يتم تلقي الرد على أي استعلام ، فسيتم إرسال SIA-Query ، الأمر الذي لا يتطلب مسارًا جديدًا ، ولكن يحتاج فقط إلى إرسال SIA-Reply ، للتأكد من أن الجار منظم ، ببساطة لا يمكن العثور على الإجابة الصحيحة الطريققلنا عن كيفية رد فعل جهاز التوجيه على فقدان المسار في حالة وجود FS أو لا ، قلنا بما فيه الكفاية. من الضروري فقط إجراء تغييرات على ما يلي. لم نقدم بشكل صحيح تمامًا تعريفًا لـ FD ، وهو المقياس الذي نحسبه وفقًا للصيغة عندما نتلقى مسارًا لأول مرة أو عندما تتغير حالة المسار بشكل أكبر ، سيكون من الصحيح استدعاء CD - المسافة المحسوبة.FD هو أفضل مؤشر لطريق معين تم الحصول عليه على الإطلاق ، وهو الذي يشارك في فحص FC. في معظم الأحيان ، FD = CD هو أفضل طريق ، ولكن دعونا نرى كيف تغير FD بعد انهيار الحي باستخدام vIOS4:P 192.168.5.0/24، 1 خلفاء، FD هو 1024
عبر 192.168.13.3 ( 1536 /768)، GigabitEthernet0 / 0
لم يعد لدينا مسار به CD = 1024 ، وأفضل طريق عبر vIOS3 هو CD = 1536 ، ولكن كما ترى ، FD = 1024 ، والذي تم إصلاحه عندما كان هناك طريق عبر vIOS4. سيتم تحديث FD فقط عندما ينتقل هذا المسار إلى الحالة النشطة. حتى تتغير الحالة من سلبي إلى نشط ، فلن تتغير FD أيضًا. تحديثات منتظمة لا تنطبق عليه. ملاحظة أخرى. لنقم بهذه التجربة: قم بإعادة الجوار باستخدام vIOS4 والأقراص المضغوطة من خلال vIOS3 = 1536 ومن خلال vIOS2 = 2048. نحن نزيد من تأخير القناة بين vIOS1 و vIOS3 بحيث يصبح أكبر من القرص المضغوط vIOS2:P 192.168.5.0/24، 1 خلفاء، FD 1024
عبر 192.168.14.4 (1024/768)، GigabitEthernet0 / 2
عبر 192.168.13.3 ( 2304 /768)، GigabitEthernet0 / 0
كما نرى القرص المضغوط من خلال vIOS3 = 2304 ، لكنه ظل FS لأن AD لم يتغير وتم استيفاء شرط FC ، كما كان من قبل. نسأل أنفسنا سؤالًا: ماذا يحدث عندما يتم فقدان الطريق من خلال vIOS2؟ الإجابة المتوقعة والمنطقية ، كما علمنا ، هي FS بدلاً من ذلك ، ولكن لا! نظرًا لأنه لا يزال هناك طريق من خلال vIOS2 مع CD = 2048 <2304 ، فإن المسار سوف ينتقل إلى الحالة النشطة ويعيد حساب المقياس الخاص به ويختار أفضل مسار على الرغم من أنه يحتوي على مسار احتياطي. ننظر إلى جدول الطوبولوجيا ونحصل على:P 192.168.5.0/24 ، 1 خلفا ، FD هو 2048
عبر 192.168.12.2 (2048/1280) ، GigabitEthernet0 / 3
عبر 192.168.13.3 (2304/768) ، GigabitEthernet0 / 0
سيتم استخدام المسار عبر vIOS2 ، وكما لاحظته FD ، فقد تغيرت أيضًا بسبب انتقال المسار إلى الحالة النشطة. والطريق عبر vIOS3 يشترك مرة أخرى في مصير الغيار.تقسيم الأفق وقواعد عكس السم في EIGRP
كما هو الحال في RIP ، تستخدم EIGRP قاعدة Split Horizon - إذا كان المسار يمكن الوصول إليه من خلال واجهة معينة ، فلن يتم تضمين هذا المسار في التحديث الذي يتم إرساله من خلال هذه الواجهة.على سبيل المثال ، إذا تلقى vIOS4 مسارًا إلى الشبكة 192.168.0.0/24 من vIOS1 ، فلن يرسل هذا التوجيه إلى Update من خلال الواجهة التي يتصل بها vIOS1. لنكون أكثر دقة ، تخيل أن vIOS1 بدأ يتحدث عن شبكة 192.168.0.0/24. لقد أرسلت تحديثًا إلى vIOS4 ، وسيقوم vIOS4 بتلقيه ، وكقاعدة عامة ، يجب ألا ترسل Split Horizon تحديثها مع هذا المسار إلى vIOS1 ، ولكنها في الواقع سترسله بمقياس لا نهائي. كما لو أن vIOS4 يقول vIOS1- "لا تجرؤ على استخدام الطريق إلى الشبكة 192.168.0.0/24 من خلالي ، لقد حصلت على هذا المسار منك وإذا كنت تستخدمه ، فسيكون هناك حلقة."عكس السم - يشير إلى مسار لا يمكن الوصول إليه باستخدام مقياس عند فقده. في EIGRP ، يتم ذلك باستخدام معلمة Delay. لقد أشرنا أعلاه إلى كيفية استخدام هذه التكنولوجيا عندما فقد vIOS1 الاتصال بـ vIOS4. من ما سبق حول Split Horizon ، يمكننا أن نستنتج أن تقنية Poison Reverse لا تستخدم فقط في رسائل Query ، ولكن أيضًا في Update. أيضًا ، قد ينتهك Poison Reverse قاعدة Split Horizon ويرسل تحديثًا بمقاييس لانهائية من الواجهة التي تلقى منها هذا التحديث. توفر هاتان القاعدتان ، جنبًا إلى جنب مع شرط FC ، حماية بروتوكول EIGRP من الحلقات.أجهزة التوجيه كعب
للتحسين ، تم تقديم دور خاص لأجهزة التوجيه في البروتوكول - Stub. شيء مثل منطقة Stub في OSPF ، ولكن هنا مبدأ تشغيل مختلف قليلاً. عند تكوين جهاز التوجيه في وضع كعب الروتين ، فإنه يبلغ على الفور في حزم Hello إلى جاره عن حالة كعب الروتين ، ويمكنه ، اعتمادًا على وضع كعب الروتين ، إرسال أنواع معينة من المسارات:vIOS5 # eigrp stub [متصل | خريطة التسرب | استقبال فقط | المعاد توزيعها | ثابت | ملخص]
خيارات أمر Eigrp كعب الروتين:- بدون خيارات (افتراضي) - متصل وملخص ؛
- متصل - يسمح لموجه كعب الروتين بإرسال المسارات المتصلة ، ولكن فقط للواجهات التي توجد عناوينها على الشبكات المحددة بواسطة أمر الشبكة ؛
- خريطة التسرب - السماح بالبادئات الديناميكية استنادًا إلى خريطة التسرب ؛
- الاستلام فقط - يمنع جهاز التوجيه من إرسال أي مسارات ؛
- redistributed — stub redistributed ;
- static — stub static , , ;
- summary — stub ( ).
ولكن الميزة الرئيسية لهذا الإعداد هي أنه إذا كان جهاز التوجيه يعرف أن جاره في دور Stub ، فلن يرسل الاستعلام إليه للمسارات التي أصبحت نشطة. على سبيل المثال ، إذا قمنا بتكوين vIOS5 على أنه Stub ، فإن vIOS2-4 سيكتشف هذا الأمر وإذا فقدت المسارات ، فلن تسمم Query. بالنظر إلى المشكلات التي قد تنشأ في حالة عدم وجود رد ، سيكون من الجيد إرسال "الاستعلام" فقط في المكان المناسب. هذا مهم في الطوبولوجيا الكبيرة حيث يمكن أن يكون التقارب عملية معقدة. لذلك ، إذا كان هناك جهاز توجيه نهائي ولم يتم ربطه إلا بشبكات المستخدمين (بشكل نسبي ، فإنه يحتوي على جار واحد فقط) ، فمن الأفضل التفكير في إعداده على أنه كعب روتين.بضع كلمات حول المؤقتات
تحدثنا عن بعضها ، إذا نظرت إلى ناتج الأمر show ip eigrp neighbor ، فسنرى ما يلي:vIOS1 # show ip eigrp Neighbours
EIGRP-IPv4 Neighbours for AS (1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.14.4 Gi0 / 2 11 00:48:43 23 138 0 168
0 192.168.12.2 Gi0 / 3 12 02:31:12 6100 0258
1 192.168.13.3 Gi0 / 0 10 2d13h
7100 0291 vIOS1 #
فيما يلي المؤقتات التي تتطلب شرحًا. إذا ، ردًا على إرسال أي حزمة بث متعدد تتطلب تأكيد الاستلام ، لم يتم إرسال إقرار (ACK) ، فسيتم إرسال الحزمة الأحادية الإرسال إلى الجار الذي لا يستجيب. إذا لم يتم استلام التأكيد حتى بعد إرسال 16 حزمة أحادية الإرسال ، فسيتم اعتبار الجار غير نشط.- الوقت السلس ذهابًا وإيابًا (SRTT) - الوقت بين إرسال حزمة إلى أحد الجيران وتلقي تأكيد منه. يقاس بالمللي ثانية. صيغة الحساب هي ملكية.
- مؤقت تدفق البث المتعدد - القيمة القصوى للفاصل الزمني بالثواني التي ينتظر خلالها جهاز التوجيه حزمة ACK بعد إرسال حزمة EIGRP إلى عنوان الإرسال المتعدد قبل التبديل إلى الإرسال الأحادي. يتم حسابه على أساس SRTT ، صيغة الحساب نفسها هي ملكية.
- مهلة إعادة الإرسال (RTO) - الفاصل الزمني بين إرسال حزم أحادية الإرسال. يتم حسابه على أساس SRTT ، صيغة الحساب نفسها هي ملكية.
على هذا أعتقد أن أنهى المقال. يوجد أدناه رابط مفيد: