أستكشاف أخطاء جيران OSPF التي تعذر الوصول إليها في حالة Exstart/Exchange وإصلاحها

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء الحالات وإصلاحها التي يكون فيها جيران فتح أقصر مسار أولا (OSPF) عالقين في حالات Exstart و Exchange. 

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

المتطلبات

يوصى بأن يكون المستخدم على دراية بعملية OSPF الأساسية وتكوينها، لا سيما الحالات المجاورة OSPF.

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

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

• الموجهات طراز 2503 من Cisco

• برنامج IOS^® الإصدار 12.2(24a) من Cisco للتشغيل على كلا الموجهين

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

الاصطلاحات

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

معلومات أساسية

توجد حالات OSPF لتكوين التجاور هناك في وضع أسفل و init و 2 إتجاه و exstart و exchange وتحميل و full. يمكن أن يكون هناك عدد من الأسباب التي تجعل جيران فتح أقصر مسار أولا (OSPF) عالقين في حالة Exstart/Exchange. يركز هذا المستند على عدم تطابق MTU بين جيران OSPF مما يؤدي إلى حالة Exstart/Exchange. للحصول على مزيد من التفاصيل حول كيفية أستكشاف أخطاء OSPF وإصلاحها، ارجع إلى أستكشاف المشاكل الشائعة وإصلاحها باستخدام OSPF.

حالة Exstart

بعد أن يقوم موجهات OSPF المجاورين بإنشاء اتصال ثنائي الإتجاه واستكمال انتخاب DR/BDR (على شبكات الوصول المتعدد)، تنتقل الموجهات إلى حالة Exstart. في هذه الحالة، تقوم الموجهات المجاورة بإنشاء علاقة أساسية/تابعة وتحديد رقم التسلسل الأولي لواصف قاعدة البيانات (DBD) لاستخدامه أثناء تبادل حزم DBD.

حالة التبادل

بمجرد التفاوض على Primary/Subordinate العلاقة (يصبح الموجه الذي يحتوي على أعلى معرف موجه هو الأساسي)، تنتقل الموجهات المجاورة إلى حالة Exchange. في هذه الحالة، تتبادل الموجهات حزم DBD، والتي تصف قاعدة بيانات حالة الارتباط الخاصة بها بالكامل. تقوم الموجهات أيضا بإرسال حزم طلب حالة الارتباط، والتي تطلب المزيد من إعلانات حالة الارتباط الحديثة (LSA) من الجيران.

على الرغم من انتقال جيران OSPF من خلال حالات Exstart/Exchange أثناء عملية بناء تجاور OSPF العادية، إلا أنه ليس من الطبيعي أن يعلق جيران OSPF في هذه الحالة. يصف القسم التالي السبب الأكثر شيوعا لوقوع جيران OSPF في هذه الحالة. ارجع إلى فهم الدول المجاورة ل OSPF لمعرفة المزيد حول حالات OSPF المختلفة.

الجيران عالقون في حالة Exstart/Exchange

تحدث المشكلة غالبا عندما تحاول تشغيل OSPF بين موجه Cisco وموجه مورد آخر. تحدث المشكلة عندما لا تتطابق إعدادات وحدة الإرسال القصوى (MTU) لواجهات neighboring الموجه. إذا كان الموجه صاحب وحدة الحد الأقصى للنقل (MTU) الأعلى يرسل حزمة أكبر من الحزمة التي قامت وحدة الحد الأقصى للنقل (MTU) بتعيينها على الموجه المجاور، فإن الموجه المجاور يتجاهل الحزمة. عندما تحدث هذه المشكلة، يعرض إخراجshow ip ospf neighborالأمر مخرجات مماثلة لما هو موضح في هذا الشكل.

يصف هذا القسم الترفيه الفعلي لهذه المشكلة.

يتم توصيل الموجه 6 والموجه 7 في هذا الشكل عبر ترحيل الإطارات، وقد تم تكوين الموجه 6 باستخدام 5 مسارات ثابتة أعيد توزيعها في OSPF. تحتوي الواجهة التسلسلية على الموجه 6 على وحدة الحد الأقصى للنقل (MTU) الافتراضية طراز 1500، بينما تحتوي الواجهة التسلسلية على الموجه 7 على وحدة الحد الأقصى للنقل (MTU) بسعة 1450. يتم عرض تكوين كل موجه في الجدول (يتم عرض معلومات التكوين الضرورية فقط):

interface Serial2

!--- MTU is set to its default value of 1500.

 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
 ip address 10.170.10.6 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 101
!
router ospf 7
 redistribute static subnets
 network 10.170.10.0 0.0.0.255 area 0
!
ip route 192.168.0.10 255.255.255.0 Null0
ip route 192.168.10.10 255.255.255.0 Null0
ip route 192.168.10.0 255.255.255.0 Null0
ip route 192.168.37.10 255.255.255.0 Null0
ip route 192.168.38.10 255.255.255.0 Null0

interface Serial0
 mtu 1450
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 frame-relay lmi-type ANSI
!
interface Serial0.6 point-to-point
 ip address 172.16.7.11 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 110
!
router ospf 7
 network 172.16.11.6 0.0.0.255 area 0

إخراج الأمر show ip ospf neighbor لكل موجه هو:

router-6#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.7.11      1   EXCHANGE/  -    00:00:36    172.16.7.11    Serial2.7
router-6#

router-7#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.170.10.6      1   EXSTART/  -     00:00:33    10.170.10.6    Serial0.6
router-7#

تحدث المشكلة عندما يرسل الموجه 6 حزمة DBD أكبر من 1450 بايت (وحدة الحد الأقصى للنقل (MTU) للموجه 7) أثناء حالة التبادل. أستخدم debug ip packet debug ip ospf adj الأوامر و على كل موجه لرؤية عملية تجاور OSPF كما تحدث. المخرج من الموجه 6 و 7 من الخطوات 1 إلى 14 هو:

1. إخراج تصحيح الأخطاء للموجه 6:

   <<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
   
   00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
   Serial2.7 is dead
   00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
   Serial2.7 is dead, state DOWN

2. إخراج تصحيح أخطاء الموجه 7:

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

3. إخراج تصحيح الأخطاء للموجه 6:

   <<<ROUTER 6 SENDING HELLOS>>>
   
   00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), len 64, sending broad/multicast, proto=89
   00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), Len 64, sending broad/multicast, proto=89

4. إخراج تصحيح أخطاء الموجه 7:

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

5. إخراج تصحيح أخطاء الموجه 7:

   <<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
   
   00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5 
   (Serial0.6), Len 64, sending broad/multicast, proto=89
   00:17:44: OSPF: Build router LSA for area 0, 
   router ID 172.16.7.11, seq 0x80000001

6. إخراج تصحيح الأخطاء للموجه 6:

   <<<RECEIVE HELLO FROM ROUTER7>>>
   
   00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
   Len 64, rcvd 0, proto=89
   00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from 
   Serial2.7 172.16.7.11
   00:04:04: OSPF: End of hello processing

7. إخراج تصحيح الأخطاء للموجه 6:

   <<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
   
   00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), Len 68, sending broad/multicast, proto=89

8. إخراج تصحيح أخطاء الموجه 7:

   <<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
   
   00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
   Len 68, rcvd 0, proto=89
   00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from 
   Serial0.6 10.170.10.6
   00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on 
   Serial0.6, state 2WAY

9. إخراج تصحيح أخطاء الموجه 7:

   <<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
   
   00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
   seq 0x13FD opt 0x2 flag 0x7 Len 32
   00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5 
   (Serial0.6), Len 52, sending broad/multicast, proto=89
   00:17:53: OSPF: End of hello processing

10. إخراج تصحيح الأخطاء للموجه 6:

    <<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
    
    00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on 
    Serial2.7, state 2WAY

11. إخراج تصحيح الأخطاء للموجه 6:

    <<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE NEGOTIATION - ROUTER 6 IS SUBORDINATE)>>>
    
    00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 
    00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
    Len 52, sending broad/multicast, proto=89 
    00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

12. إخراج تصحيح أخطاء الموجه 7:

    <<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
    
    00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU 

13. إخراج تصحيح الأخطاء للموجه 6:

    <<<SINCE ROUTER 6 IS SUBORDINATE SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>
    
    00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472 
    00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
    Len 1492, sending broad/multicast, proto=89

14. إخراج تصحيح أخطاء الموجه 7:

    <<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
    
    00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5 
    (Serial0.6), Len 68, sending broad/multicast, proto=89
    00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
    Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]

عند هذه النقطة، يستمر الموجه 6 في محاولة الحصول على الحزمة الأولية DBD من الموجه 7.

00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from
Serial2.7 172.16.7.11
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

لا يحصل الموجه 7 أبدا على ACK من الموجه 6 لأن حزمة DBD من الموجه 7 كبيرة جدا بالنسبة للموجه 7 MTU. يرسل الموجه 7 بشكل متكرر حزمة DBD.

0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [2]

00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from
Serial0.6 10.170.10.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [3]

00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

نظرا لأن الموجه 6 يحتوي على وحدة الحد الأقصى للنقل (MTU) أعلى، فإنه يستمر في قبول حزمة DBD من الموجه 7، ويحاول الاعتراف بها، ويظل في حالة Exchange.

نظرا لأن الموجه 7 يحتوي على وحدة الحد الأقصى للنقل (MTU) أقل، فإنه يتجاهل حزم DBD مع ACK من الموجه 6، ويستمر في إعادة إرسال حزمة DBD الأولية، ويظل في حالة Exstart.

في الخطوة 9 و 11، يرسل الموجه 7 والموجه 6 أول حزم DBD خاصة بهم مع تعيين العلم 0x7 كجزء من التفاوض الأساسي/التابع. بعد Primary/Subordinate التحديد، يتم إختيار الموجه 7 كأساسي بسبب المعرف الأعلى للموجه الخاص به. تظهر العلامات في الخطوة 13 و 14 بوضوح أن الموجه 7 أساسي (العلامة 0x7) والموجه 6 تابع (العلامة 0x2).

في الخطوة 10، يستقبل الموجه 6 الحزمة الأولية ل DBD طراز Router 7 ويحول حالته إلى الاتجاهين.

في الخطوة 12، يستلم الموجه 7 الحزمة الأولية DBD للموجه 6 ويتعرف على عدم تطابق MTU. (يمكن أن يتعرف الموجه 7 على عدم تطابق وحدة الحد الأقصى للنقل (MTU) لأن الموجه 6 يتضمن وحدة الحد الأقصى للنقل (MTU) الخاصة به في حقل وحدة الحد الأقصى للنقل (MTU) للواجهة لحزمة DBD). يتم رفض الموجه 6 DBD الأولي بواسطة الموجه 7. يرسل الموجه 7 الحزمة الأولية DBD.

توضح الخطوة 13 أن الموجه 6، subordinateas، يعتمد رقم التسلسل Router 7 ويرسل حزمة DBD الثانية الخاصة به التي تحتوي على رؤوس مناطق LSA الخاصة به، والتي تزيد من حجم الحزمة. ومع ذلك، لا يستقبل الموجه 7 أبدا حزمة DBD هذه لأنها أكبر من الموجه 7 MTU.

بعد الخطوة 13، يستمر الموجه 7 في إعادة إرسال الحزمة الأولية DBD إلى الموجه 6، بينما يستمر الموجه 6 في إرسال حزم DBD التي تلتزم برقم التسلسل الأساسي. تستمر هذه الحلقة إلى أجل غير مسمى، مما يمنع أي من الموجهات من الانتقال خارج حالة exstart/exchange.

الحل

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

ملاحظة: قام الإصدار 12.0(3) من برنامج Cisco IOS Software بتقديم اكتشاف عدم تطابق وحدة الحد الأقصى للنقل (MTU) للواجهة. يتضمن هذا الكشف OSPF الذي يعلن عن وحدة الحد الأقصى للنقل (MTU) للواجهة في حزم DBD، والتي تكون وفقا ل OSPF RFC 2178، الملحق g.9. عندما يستقبل الموجه حزمة DBD يتم الإعلان عنها، وحدة الحد الأقصى للنقل (MTU) أكبر من الموجه الذي يمكن إستلامه، فإن الموجه يتجاهل حزمة DBD وتظل الحالة المجاورة في Exstart. وهذا يمنع تكوين التجاور. لحل هذه المشكلة، تأكد من أن وحدة الحد الأقصى للنقل (MTU) هي نفسها على كلا طرفي الرابط.

في البرنامج Cisco IOS Software 12.01(3)، تم إدخال أمر تكوين الواجهة ip ospf mtu-ignore أيضا لإيقاف تشغيل اكتشاف عدم تطابق MTU، ومع ذلك، لا يلزم هذا إلا في حالات نادرة، كما هو موضح في هذا المخطط:

يوضح المخطط السابق منفذ واجهة البيانات الموزعة عبر الألياف (FDDI) على Cisco Catalyst 5000 مع وحدة نمطية للتحويل والتوجيه (RSM) متصلة بواجهة FDDI على الموجه 2. الشبكة المحلية الظاهرية (VLAN) على RSM هي واجهة إيثرنت افتراضية مع وحدة الحد الأقصى للنقل (MTU) رقم 1500، وواجهة FDDI على الموجه 2 لديها وحدة الحد الأقصى للنقل (MTU) رقم 4500. عندما إستلمت ربط على ال FDDI ميناء من المفتاح، هو يذهب إلى اللوحة الخلفية وال FDDI إلى إثرنيت يقع تحويل/تجزئة ضمن المفتاح نفسه. هذا إعداد صالح، ولكن باستخدام ميزة اكتشاف عدم تطابق MTU، لا يتم تكوين تجاور OSPF بين الموجه و RSM. ونظرا لاختلاف FDDI و Ethernet MTU، فإن هذا الأمر ip ospf mtu-ignore يكون مفيدا على واجهة VLAN الخاصة ب RSM لإيقاف اكتشاف OSPF لعدم تطابق MTU وتشكيل التجاور.

من المهم ملاحظة أن عدم تطابق MTU، على الرغم من أنه الأكثر شيوعا، ليس هو السبب الوحيد الذي يجعل جيران OSPF عالقين في حالة Exstart/Exchange. تحدث المشكلة في معظم الأحيان بسبب عدم القدرة على تبادل حزم DBD بنجاح. ومع ذلك، قد يكون السبب الجذري أي مما يلي:

• عدم تطابق MTU

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

  • تخطيط الدائرة الظاهرية (VC) الخطأ في وضع النقل غير المتزامن (ATM) أو بيئة ترحيل الإطارات في شبكة عالية التكرار.

  • مشكلة MTU، مما يعني أن الموجهات يمكنها فقط إختبار اتصال حزمة ذات طول معين.

  • تمنع قائمة الوصول حزمة البث الأحادي.

  • nat يركض على المسحاج تخديد ويترجم ال unicast ربط.

• جار بين PRI و BRI/المتصل.

• يحتوي كلا الموجهين على نفس معرف الموجه (mis-configuration).

بالإضافة إلى ذلك، يشير RFC 2328 الخاص ب OSPF، القسم 10.3، إلى أن عملية Exstart/Exchange قد بدأت لأي من هذه الأحداث (قد يكون أي منها ناجما عن مشاكل برامج داخلية):

• رقم التسلسل غير متطابق.

  • رقم تسلسل DD غير متوقع.

  • تم تعيين البت "I" بشكل غير متوقع.

  • حقل "الخيار" مختلف عن حقل "الخيار الأخير" الذي تم تلقيه في حزمة DBD.

• BadLSReq

  • يرسل الجار LSA غير معروف أثناء عملية التبادل.

  • طلب الجار LSA أثناء عملية التبادل التي لا يمكن العثور عليها.

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

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

• فهم الدول المجاورة ل OSPF
• استكشاف مشكلات الجهاز المجاور لبروتوكول OSPF وإصلاحها
• الدعم الفني والتنزيلات من Cisco