مقياس IGRP

المقدمة

يضيف بروتوكول توجيه العبارة الداخلية (IGRP) معا قيم مرجحة لخصائص مختلفة من الارتباط بالشبكة المعنية لحساب مقياس. تتمثل خصائص الارتباط التي يقوم IGRP من خلالها بحساب القياس المركب في النطاق الترددي والتأخير والحمولة والموثوقية ووحدة الإرسال القصوى (MTU). وبشكل افتراضي، يقوم بروتوكول IGRP باختيار المسار استنادا إلى النطاق الترددي والتأخير.

المتطلبات الأساسية

المتطلبات

يجب أن يكون لدى قراء هذا المستند معرفة بالمواضيع التالية:

• بروتوكول العبارة الداخلية (IGRP) والميزات ذات الصلة

  ملاحظة: راجع مقدمة عن IGRP للحصول على مزيد من المعلومات.

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية:

• برنامج IOS® الإصدار 12.2(24a) من Cisco

• الموجّهات من السلسلة 2500 من Cisco

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

الاصطلاحات

للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.

البحث عن مقياس IGRP

يستخدم هذا القسم مثالا لتوضيح كيفية العثور على القياس عندما يكون IGRP هو بروتوكول التوجيه.

الرسم التخطيطي للشبكة

يتم توفير الرسم التخطيطي للسيناريو المحدد هنا:

هنا الصيغة المستخدمة لحساب القياس المركب ل IGRP:

متري = [K1 * النطاق الترددي + (K2 * النطاق الترددي)/(256 حمل) + K3*التأخير] * [K5/(الموثوقية + K4)]

القيم الافتراضية الثابتة هي K1 = K3 = 1 و K2 = K4 = K5 = 0.

إذا كانت K5 = 0، لا يتم إستخدام المصطلح [K5/(الموثوقية + K4)]. لذلك، بافتراض القيم الافتراضية ل K1 حتى K5، فإن حساب القياس المركب المستخدم من قبل IGRP يقلل إلى القياس = النطاق الترددي + التأخير.

قيم K في هذه الصيغ هي ثوابت يمكنك تعريفها باستخدام أمر تكوين الموجه، أوزان القياس tos k1 k2 k3 k4 k5 .

ملاحظة: تقترح Cisco بشدة عدم تغيير معلمات K الافتراضية.

للعثور على عرض النطاق الترددي، ابحث عن أصغر عرض من بين جميع عروض النطاق الترددي العريض في كيلوبت/ثانية من الواجهات الصادرة وقسم 10،000،000 على هذا الرقم. (يتم تغيير حجم النطاق الترددي بمقدار 10،000،000 كيلوبت في الثانية).

للعثور على التأخير، قم بإضافة كافة التأخيرات (بالميكروثانية) من الواجهات الصادرة وقسم هذا الرقم على 10. (التأخير يكون بعشر الميكرو ثانية.)

تذكر، المسار ذو المقياس الأصغر هو أفضل مسار.

تظهر المخرجات المختلفة لأوامر show لكلا الموجهين هنا:

Venus# show interfaces ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0060.5cf4.a9a8 (bia 0060.5cf4.a9a8)
Internet address is 12.1.1.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set

Venus# show interfaces serial 0
Serial0 is up, line protocol is up
Hardware is HD64570     
Internet address is 172.16.10.2/24     
MTU 1500 bytes, BW 784 Kbit, DLY 20000 usec,     
reliability 255/255, txload 1/255, rxload 1/255     
Encapsulation FRAME-RELAY, loopback not set     
Keepalive set (10 sec)     
LMI enq sent 981, LMI stat recvd 330, LMI upd recvd 0, DTE LMI up     
LMI enq recvd 340, LMI stat sent 0, LMI upd sent 0     
LMI DLCI 1023 LMI type is CISCO frame relay DTE
 
Saturn# show interfaces serial 1     
Serial0 is up, line protocol is up     
Hardware is HD64570     
Internet address is 172.16.10.1/24     
MTU 1500 bytes, BW 224 Kbit, DLY 20000 usec,     
reliability 255/255, txload 1/255, rxload 1/255     
Encapsulation FRAME-RELAY, loopback not set     
Keepalive set (10 sec)     
LMI enq sent 167, LMI stat recvd 168, LMI upd recvd 0, DTE LMI up     
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0     
LMI DLCI 1023 LMI type is CISCO frame relay DTE
 
Saturn# show interfaces ethernet 0     
Ethernet0 is up, line protocol is up     
Hardware is Lance, address is 0060.5cf4.a955 (bia 0060.5cf4.a955)     
Internet address is 172.17.10.1/16     
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,     
reliability 255/255, txload 1/255, rxload 1/255     
Encapsulation ARPA, loopback not set

يمكنك عرض القيم المترية التي يتم حسابها بواسطة IGRP باستخدام الأمر show ip route:

Venus# show ip route 172.17.10.1
Routing entry for 172.17.0.0/16
Known via "igrp 100", distance 100, metric 14855
Redistributing via igrp 100
Advertised by igrp 100 (self originated)
Last update from 172.16.10.1 on serial0, 00:00:13 ago
Routing Descriptor Blocks:
  * 172.16.10.1, from 172.16.10.1, 00:00:13 ago, via Serial0
      Route metric is 14855, traffic share count is 1
      Total delay is 21000 microseconds, minimum bandwidth is 784 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 0

والحسابات المقابلة هي:

القياس = النطاق الترددي + التأخير = 10000000/784 + (20000 + 1000)/10 = 14855

Saturn# show ip route 12.1.1.1
Routing entry for 12.0.0.0/8
Known via "igrp 100", distance 100, metric 46742
Redistributing via igrp 100
Advertised by igrp 100 (self originated)
Last update from 172.16.10.2 on serial1, 00:00:43 ago
Routing Descriptor Blocks:
  * 172.16.10.2, from 172.16.10.2, 00:00:43 ago, via Serial1
      Route metric is 46742, traffic share count is 1
      Total delay is 21000 microseconds, minimum bandwidth is 224 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 0

والحسابات المقابلة هي:

القياس = النطاق الترددي + التأخير = 10000000/224 + (20000 + 1000)/10 = 46742

كم مرة يتم حساب الحمل؟

القيم الافتراضية الثابتة للk2 إلى صفر. إذا تم تعيين K2 على 1، يصبح التحميل متغير يستخدم في التوجيه. يبدو أن المشكلة هي إذا قفز الحمل. إذا قفزت التكلفة المترية في بداية جلسة FTP، فمن الممكن أن يتم تحويل المسار إلى رفض بسبب الزيادة. كم مرة يتم حساب الحمل؟

الحمل هو متوسط ترجيحي أسيا لمدة خمس دقائق يتم تحديثه كل خمس ثوان.

ما هي السرعة التي يمكن أن ترتفع بها قيمة الحمل؟

هل من الممكن أن ترتفع قيمة الحمل بالسرعة الكافية لجعل المسار غير مستقر؟

نعم، هو كذلك. والأسوأ من ذلك، عندما ينخفض الحمل، ينخفض القياس. يتسبب هذا الفشل في تحديث Flash.

هل يمكن تكوين IGRP لاستخدام المسار الأسرع من خلال سحابة الشبكة؟

بما أن تكلفة القياس المركب لموقع معين يتم تحديدها بواسطة أبطأ إرتباط في المسار وأبطأ إرتباط هو عادة خط الوصول في السحابة، كيف يمكن تكوين IGRP لاستخدام أسرع مسار من خلال سحابة الشبكة؟

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

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

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

ما هو المقياس الذي يجب إستخدامه عند إعادة توزيع المسارات إلى بروتوكول IGRP؟

قم بإصدار الأمر default-metric لتعيين القياس للمسارات التي تمت إعادة توزيعها. هذا البيان مناسب لمعظم الحالات:

Venus(config)# router igrp 100             
  Venus(config-router)# default-metric 10000 100 255 1 1500

حيث 10000 = النطاق الترددي، 100 = التأخير، 255 = الموثوقية، 1 = التحميل، و 1500 = وحدة الحد الأقصى للنقل (MTU).

معلومات ذات صلة

• كيف يعمل موازنة مسار التكلفة غير المتكافئة (التباين) في IGRP و EIGRP؟
• مقدمة عن بروتوكول العبارة الداخلية (IGRP)
• صفحة دعم IGRP
• صفحة دعم تقنية توجيه IP
• الدعم الفني - Cisco Systems