المحتويات

المقدمة

الخلفية

المشكلة

الحل

المقدمة

يصف هذا المستند المشكلة مع معالجة قياس مسار بروتوكول توجيه العبارة الداخلي المحسن (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 في تخفيف المشكلة.

- قم بتكوين قياس مطلق أعلى عند إجراء المعالجة المترية.