رسالة الخطأ "٪TUN-5-RECURDOWN" ورفرفة جيران EIGRP/OSPF/BGP عبر نفق GRE

خيارات التنزيل

  • PDF     (341.2 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (92.4 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (106.0 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:١١ سبتمبر ٢٠١٨
معرّف المستند:22327

لغة خالية من التحيز

تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

المقدمة

ال ٪TUN-5-RECURDOWN: Tunnel0 معطل مؤقتا بسبب رسالة خطأ التوجيه المتداخل يعني أن موجه نفق التوجيه العام (GRE) اكتشف مشكلة توجيه متداخل. وعادة ما يكون هذا الشرط راجعا إلى أحد هذه الأسباب:

  • تكوين خاطئ يتسبب في أن يحاول الموجه التوجيه إلى عنوان وجهة النفق باستخدام واجهة النفق نفسها (التوجيه المتكرر)

  • عدم إستقرار مؤقت ناجم عن إرتطام المسار في مكان آخر من الشبكة

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

من الأعراض الأخرى لهذه المشكلة رفرفة بروتوكول توجيه العبارة الداخلي المحسن (EIGRP) بشكل مستمر، أو فتح أقصر مسار أولا (OSPF)، أو جيران بروتوكول العبارة الحدودية (BGP)، عندما يكون الجيران عبر نفق GRE.

يبدي هذا وثيقة مثال من يتحرى يتذبذب نفق قارن أن يركض EIGRP.

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

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

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

لا يقتصر هذا المستند على إصدارات برامج أو أجهزة معينة.

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

الاصطلاحات

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

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

يتم توصيل الموجه 1 (R1) والموجه 3 (R3) بالموجه 2 (R2). الاتصال بالشبكة قد يجعل R1 قادرا على الوصول إلى واجهة الاسترجاع R3 من خلال R2 والعكس. يعمل EIGRP عبر واجهة النفق على R1 و R3. لا يعد R2 جزءا من مجال EIGRP.

gre_flap_01.gif

التكوينات

R1 
hostname R1
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Tunnel0
 ip address 192.168.1.1 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.3.3.3
!
interface Serial0
 ip address 172.16.15.1 255.255.255.0
 encapsulation ppp
!
router eigrp 1
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.16.15.2

R3 
hostname R3
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.0
!
interface Tunnel0
 ip address 192.168.1.3 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.1.1.1
!
interface Serial1
 ip address 172.16.25.3 255.255.255.0
!
router eigrp 1
 network 10.3.3.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.16.25.2

رصد

لاحظ رسائل الخطأ هذه على R1 و R3. تتأرجح حالة واجهة النفق باستمرار بين أعلى وأسفل.

01:11:39: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:11:48: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:11:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down
01:12:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:12:58: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:12:59: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down

ملاحظة: يظهر كل سطر محدد بختم الوقت لمخرجات سابقة على سطر واحد في المخرج الفعلي.

استكشاف الأخطاء وإصلاحها

هذا هو المسار إلى وجهة النفق 10.3.3.3 على R1 قبل زيادة واجهة النفق:

R1# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Loopback0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

يأخذ غاية النفق 10.3.3.3 المسار الافتراضي عبر 172.16.15.2 (تسلسلي 0).

الآن، لاحظ جدول التوجيه بعد زيادة واجهة النفق، كما هو موضح هنا:

R1# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.25.0/24 [90/297756416] via 192.168.1.3, 00:00:00, Tunnel0
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 2 subnets
D       10.3.3.0 [90/297372416] via 192.168.1.3, 00:00:00, Tunnel0
C       10.1.1.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

يتم التعرف على المسار إلى وجهة النفق 10.3.3.3 من خلال EIGRP، بينما تكون المرحلة التالية هي نفق الواجهة 0.

في هذه الحالة، يكون المسار الأفضل لوجهة النفق من خلال واجهة النفق؛ ومع ذلك، يحدث هذا:

  1. تم وضع الحزمة في قائمة انتظار الإخراج لواجهة النفق.

  2. تضيف واجهة النفق رأس GRE إلى الحزمة وتقف في قائمة الانتظار الحزمة إلى بروتوكول النقل الموجه إلى عنوان الوجهة لواجهة النفق.

  3. يبحث IP عن المسار إلى عنوان الوجهة ويعلم أنه من خلال واجهة النفق، والتي ترجع الحزمة إلى الخطوة 1 أعلاه؛ وبالتالي، هناك حلقة توجيه متكررة.

الحل

قم بتكوين المسارات الثابتة لوجهة النفق على كل من R1 و R3.

R1(config)# ip route 10.3.3.3 255.255.255.255  serial 0
R3(config)# ip route 10.1.1.1 255.255.255.255 serial 1

الآن، لاحظ مسار IP على R1، كما هو موضح أدناه.

R1# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.25.0/24 [90/297756416] via 192.168.1.3, 00:01:08, Tunnel0
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S       10.3.3.3/32 is directly connected, Serial0
D       10.3.3.0/24 [90/297372416] via 192.168.1.3, 00:01:08, Tunnel0
C       10.1.1.0/24 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

يفضل مسار ثابت أكثر تحديدا (10.3.3.3/32) على المسار الأقل تحديدا الذي تم تعلمه من EIGRP (10.3.3.0/24) لوجهة النفق. ويتجنب هذا المسار الثابت الأكثر تحديدا حلقة التوجيه العودية، وواجهة نفق التوهج، وبالتالي، إرتشاح جيران EIGRP.

R1# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 192.168.1.1/24
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (10 sec)
  Tunnel source 10.1.1.1 (Loopback0), destination 10.3.3.3

٪تحذير: الميزة غير معتمدة في الجهاز. سيتم تبديل حزم النفق بواسطة البرامج

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

يمكن حل هذه المشكلة إذا كنت تستخدم عناوين ثانوية على واجهة إسترجاع أو إذا كنت تستخدم واجهات إسترجاع متعددة لعناوين مصدر النفق.

يتم إرسال حزمة ترحيب OSPF بواسطة موجه عبر نفق GRE ولكنها لا تصل إلى الطرف الآخر من النفق.

في شبكة تم تمكين OSPF عليها، يرسل الموجه R1 حزمة ترحيب OSPF عبر نفق GRE ولكن لا يتم استقبالها بواسطة الموجه R3. أستخدم الأمر debug ip ospf hello لتصحيح أخطاء أحداث Hello. 

R1#debug ip ospf hello
May 31 13:58:29.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1
May 31 13:58:39.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1
May 31 13:58:49.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1


R3#debug ip ospf hello
May 31 15:02:07 ADT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.3
May 31 15:02:09 ADT: OSPF: Rcv hello from 172.16.15.1 area 0.0.0.12 from Tunnel0 192.168.1.1
May 31 15:02:09 ADT: OSPF: Send immediate hello to nbr 172.16.15.3, src address 192.168.1.3, on Tunnel0
May 31 15:02:09 ADT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.3

!--- The previous output shows that the hello packets !--- re sent by R1 but not received by R3.

الحل

قم بتكوين الأمر tunnel key على نفق الواجهة 10 على كلا الموجهين. يمكن هذا الأمر البث المتعدد على GRE.

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

محفوظات المراجعة

المراجعة تاريخ النشر التعليقات
1.0
11-Sep-2018
الإصدار الأولي

هل كان هذا المستند مفيدًا؟

Feedbackالتعليقات

اتصل بنا