معالجة EIGRP من القياسات الأعلى إلى القياسات الأدنى

المقدمة

يصف هذا المستند المشكلة مع معالجة قياس مسار بروتوكول توجيه العبارة الداخلي المحسن (EIGRP) حيث لا يدخل المقياس المعدل حيز التنفيذ بسبب سلوك EIGRP المعروف.

الخلفية

لوحظت المشكلة في أحد عمليات نشر شبكة WAN الذكية (IWAN) حيث حاول مشغل الشبكة التأثير على تفضيل مسار حركة المرور باستخدام قياس تأخير EIGRP على موجهات الفرع. تأثر تفضيل المسار ب distribute-list ضمن تكوين EIGRP وبتعديل قياس التأخير. افحص الطبولوجيا الموضحة في الشكل 1.

الشكل 1 - طبولوجيا شبكة الاتصال واسعة النطاق (IWAN)

في هذا المخطط، يحاول مشغل الشبكة إجراء معالجة المسار باستخدام distribute-list على جميع موجهات الفروع في كل من مركزي البيانات لتوفير تفضيل للبادئات لاتخاذ إرتباط معين كمسار مفضل. على سبيل المثال، البادئة 10.2.0.0/16 في DC2 هي المسار المفضل على الموجه المتصل في تسلسل الأفضلية هذا: DC2-BR2، DC2-BR1، DC1-BR2، DC1-BR1. بمعنى آخر، يكون تفضيل المسار لإرسال حركة مرور البيانات للموجه المتصل، على سبيل المثال Talk-1، هو أولا موجه DC2-BR2، ثم موجه DC2-BR1، ثم نحو DC1-BR2، وأخيرا موجه DC1-BR1. كما أن مشغل الشبكة لديه تأخير EIGRP تم تكوينه على واجهة DCI على عقدة DC1-SW1.

يتم عرض نموذج تكوين من موجه DC1-BR1 لمعالجة مقياس EIGRP هنا:

! Configuration from DC1-BR1 router
router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 100
 !
 af-interface default
 passive-interface
 exit-af-interface
 !
 af-interface Tunnel100
 summary-address 10.0.0.0 255.0.0.0
 summary-address 10.2.0.0 255.255.0.0
 no passive-interface
 no split-horizon
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/1
 no passive-interface
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/3
 no passive-interface
 exit-af-interface
 !
 topology base
 distribute-list route-map set-metric-Gig out GigabitEthernet0/0/1
 distribute-list route-map set-metric-tag-all out Tunnel100
 exit-af-topology
 network 10.1.2.0 0.0.0.255
 network 10.1.10.0 0.0.0.3
 network 10.1.123.0 0.0.3.255
 eigrp router-id 10.1.0.11
 exit-address-family 
!
route-map set-tag-all deny 10
 match tag 102 201 202
!
route-map set-tag-all permit 100
 match ip address prefix-list set-spoke-delay-4000
 set metric 100000 4000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 300
 match ip address prefix-list set-spoke-delay-1000
 set metric 100000 1000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 400
 match ip address prefix-list set-spoke-delay-2000
 set metric 100000 2000 255 1 1500
 set tag 101
 
!
ip prefix-list set-spoke-delay-4000 seq 100 permit 10.2.0.0/16
. . . 
! 

النفق 100 هو نفق Dynamic Multipoint VPN (DMVPN) تجاه الموجه الموجه عبر إرتباط INET. في التكوين السابق، يتم تعيين البادئة 10.2.0.0/16 مع تأخير 4000. وبالمثل، يتم تعيين التأخير على 1000 و 2000 و 3000 على عقد DC2-BR2 و DC2-BR1 و DC1-BR2 على التوالي لنفس البادئة لتعيين ترتيب الأفضلية. على الرغم من أن المثال يستخدم نفق DMVPN لأغراض العرض التوضيحي، إلا أن المشكلة لا تعتمد على الواجهة.

المشكلة

تظهر المشكلة في الواقع على الموجهات ذات الصلة، حيث يتم رؤية البادئة 10.2.0.0/16 بمقاييس مختلفة عند استقبالها من موجهات فرع DC2 ولكنها تحتوي على نفس المقياس عند استقبالها من موجهات فرع DC1. يوضح هذا الإخراج من الموجه الذي يتحدث هذا السلوك:

Spoke-1# show ip eigrp topology 10.2.0.0/16 | in delay
        Total delay is 60000000000 picoseconds  (from DC 2 BR2)
        Total delay is 100020000000 picoseconds  (From DC 1 BR1)
        Total delay is 70000000000 picoseconds  (From DC 2 BR1)
        Total delay is 100020000000 picoseconds  (From DC 1 BR2)

يتسبب هذا السلوك في عدم إعطاء التفضيل بالتسلسل للمسارات المستلمة من موجهات DC1-BR1 و DC1-BR2.

الحل

السبب الرئيسي للمشكلة هو أن مشغل الشبكة حاول تعيين مقياس إلى قيمة مطلقة أقل (قياس أقل) من القيمة المستلمة. يمكن التحقق من هذا مع show ip eigrp events على الموجهات الفرعية طراز DC1. يوضح الإخراج أن خريطة المسار تحاول معالجة القياس إلى قيمة أقل من الموجود بالفعل للبادئة.

DC1-BR1# show ip eigrp events
. . .
06:47:11.891 Can't reduce rtmap metric, old/new: metric(2950430720) metric(1972633600)
. . .

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

• قم بتقليل قيمة التأخير في المسار للبادئة المستلمة. في الحالة السابقة، ساعد تقليل قيمة تأخير EIGRP على واجهة DCI في تخفيف المشكلة.
• قم بتكوين قياس مطلق أعلى عند إجراء المعالجة المترية.