لماذا يستمر OSPF Demand Circuit في إظهار الارتباط

المقدمة

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

لمزيد من المعلومات حول دائرة الطلب، ارجع إلى ميزة دائرة طلب OSPF.

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

المتطلبات

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

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

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

الاصطلاحات

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

نموذج الشبكة

يتم وصف المشكلة المذكورة أعلاه مع الرسم التخطيطي للشبكة والتكوين التاليين.

interface BRI1/1
 ip address 192.158.254.13 255.255.255.252
 ip ospf demand-circuit

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

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

في المخطط أعلاه، يقوم الموجهان 1 و 2 بتشغيل دائرة طلب OSPF عبر إرتباط ISDN. يستمر الرابط بين الموجهين 1 و 2 في الاقبال، مما ينقص الغرض من دائرة طلب OSPF. يظهر إخراج الأمر show dialer أن الارتباط ظهر بسبب حزمة "مرحبا للبث المتعدد" الخاصة ب OSPF.

Router1# show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=224.0.0.5)

يمكن اثارة هذا الرابط لعدة أسباب. نستكشف أدناه العديد من الحالات الشائعة ونقدم حلولا لها.

السبب 1: التغيير في مخطط الشبكة

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

الحل

لتحديد ما إذا كان الارتباط قد تم عرضه بسبب تغيير في مخطط الشبكة، أستخدم الأمر debug ip ospf monitor. وهو يوضح أي منطقة هبوط السوائل تتغير، كما هو موضح أدناه:

Router1# debug ip ospf monitor
OSPF: Schedule SPF in area 0.0.0.0
      Change in LS ID 192.168.246.41, LSA type R,
OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s

يوضح الإخراج أعلاه وجود تغيير في LSA للموجه مع معرف الموجه 192.168.246.41، وهو ما يتسبب في إعادة مزامنة قاعدة البيانات. إذا كانت الشبكة مستقرة، فلن يظهر إخراج تصحيح الأخطاء هذا أي شيء.

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

السبب 2: نوع الشبكة المعرف كبث

عند تكوين دائرة طلب على إرتباط، يجب تعريف نوع الارتباط كنقطة إلى نقطة أو نقطة إلى عدة نقاط. قد يتسبب أي نوع إرتباط آخر في ظهور الارتباط بشكل غير ضروري لأن حالة OSPF لا يتم كبحها إذا كان نوع الشبكة أي شيء غير من نقطة إلى نقطة أو من نقطة إلى نقطة متعددة. فيما يلي نموذج تكوين لتوضيح هذه المشكلة على الموجهين 1 و 2.

interface BRI1/1
 ip address 192.158.254.13 255.255.255.252
 ip ospf network broadcast

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 ip ospf network broadcast
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

مع تعريف نوع الشبكة على أنه بث، يجلب OSPF الرابط إلى أعلى في كل فترة Hello. يظهر إخراج متصل العرض أن آخر مرة تم فيها إظهار الارتباط كانت بسبب مرحبا ب OSPF.

Router1# show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=224.0.0.5)
Interface bound to profile Di1
Current call connected 00:00:08
Connected to 57654 (R2)

الحل

لحل هذه المشكلة، قم بتغيير نوع الشبكة إلى نقطة إلى نقطة أو من نقطة إلى عدة نقاط. هنا نقوم بإزالة بث نوع الشبكة بحيث يتم تكوينه بشكل افتراضي من نقطة إلى نقطة.

interface BRI1/1
 ip address 192.158.254.13 255.255.255.252

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

من خلال تغيير نوع الشبكة إلى نقطة إلى نقطة أو من نقطة إلى نقطة متعددة، يتم منع إرتباط OSPF على الارتباط، كما يتوقف إرتباط الدائرة المطلوبة عن التدفق.

السبب 3: موجه واحد أو أكثر لا يفهم دائرة الطلب

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

السبب 4: تتم إعادة توزيع مسار المضيف في قاعدة بيانات OSPF

دعنا نأخذ الرسم التخطيطي للشبكة التالي كمثال:

الارتباط بين الموجهين 1 و 2 هو 131.108.1.0/24، وتم تكوين دائرة الطلب بين الموجهين 1 و 2. يقوم الموجه 1 بإعادة توزيع مسارات بروتوكول معلومات التوجيه (RIP) إلى OSPF.

router ospf 1
 redistribute rip subnets
 network 131.108.1.0 0.0.0.255 area 1
!
router rip
 network 131.108.0.0

بما أن نوع تضمين الارتباط هو PPP، يقوم كلا الموجهين بتثبيت مسار مضيف للجانب الآخر من الارتباط كما هو موضح أدناه.

Router1# show ip route 131.108.1.2
Routing entry for 131.108.1.2/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via BRI1/1
      Route metric is 0, traffic share count is 1

بروتوكول توجيه العبارة الداخلية (IGRP) و RIP هما بروتوكولات توجيه مصنفة، وبالتالي فإن بيان الشبكة في التكوين هو لشبكة مصنفة من 131.108.0.0. ولهذا السبب، يعتبر مسار المضيف 131.108.1.2/32 منشأ من قبل RIP ويعاد توزيعه على OSPF كمسار خارجي كما هو موضح أدناه.

Router1# show ip ospf database external 131.108.1.2

       OSPF Router with ID (131.108.3.1) (Process ID 1)


                Type-5 AS External Link States

  LS age: 298
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 131.108.1.2 (External Network Number )
  Advertising Router: 131.108.3.1
  LS Seq Number: 80000001
  Checksum: 0xDC2B
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

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

الحل 1: إستخدام الأمر no peer neighbor-route

تحت واجهة BRI التي تقوم بتشغيل دائرة الطلب، قم بتكوين no peer-route. يؤدي ذلك إلى منع تثبيت قناع /32. يمكنك إستخدام التكوين الموضح أدناه على الموجه 1 فقط، ولكننا نوصي بتكوين هذا الأمر على كلا الجانبين لتحقيق التناسق.

R1# configure terminal
R1(config)# interface BRI1/1
R1(config-if)# no peer neighbor-route

الحل 2: إستخدام الأمر route-map

عند إعادة التوزيع من RIP إلى OSPF، أستخدم الأمر route-map و deny /32 حتى لا يتم حقنه في قاعدة بيانات OSPF. يتطلب أمر التكوين هذا فقط على الموجه الذي يقوم بإعادة التوزيع، والذي في المثال الخاص بنا هو الموجه 1.

علينا أولا إنشاء قائمة وصول لمطابقة قناع /32. ثم نقوم بتطبيق قائمة الوصول هذه على خريطة المسار واستخدام خريطة المسار عند تطبيق الأمر redistribution كما هو موضح أدناه.

R1# configure terminal
R1(config)# access-list 1 deny host 131.108.1.2
R1(config)# access-list 1 permit any

R1# configure terminal
R1(config)# route-map rip-ospf
R1(config-route-map)# match ip address 1

R1(config)# router ospf 1
R1(config-router)# redistribute rip subnets route-map rip-ospf

الحل 3: إستخدام شبكة رئيسية مختلفة

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

أصبح مجال RIP الآن تحت شبكة 141.108.0.0 بينما يكون مجال OSPF (وارتباط دائرة الطلب) تحت شبكة 131.108.0.0.

السبب 5: تم تكوين دائرة طلب OSPF عبر واجهة غير متزامنة

عندما تقوم بتكوين دائرة طلب عبر واجهة غير متزامنة (غير متزامنة)، ثم عندما تنزل الطبقة 2، فإن الواجهة الفعلية تنتقل إلى الأسفل. يؤدي هذا إلى تشغيل تغيير في قاعدة بيانات OSPF ثم تعود الواجهة غير المتزامنة مرة أخرى لتبادل قاعدة البيانات. تنزل الطبقة 2 مرة أخرى، وهذا سوف يشعل التغيير في قاعدة البيانات مرة أخرى، لذلك تستمر هذه العملية في تكرار نفسها.

يستخدم السيناريو التالي لإعادة إنتاج المشكلة المذكورة أعلاه.

يتم إستخدام التكوين التالي للسيناريو المذكور أعلاه.

interface Async 1
 ip address 192.158.254.13 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer in-band
 async default routing
 async mode dedicated
 ppp authentication chap
 ppp chap hostname Router1
 ppp chap password 7 13061E010803
!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

interface Async 1
 ip address 192.158.254.14 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer in-band
 dialer map ip 192.158.254.13 broadcast 12345
 dialer-group 2
 async default routing
 async mode dedicated
 ppp authentication chap callin
!
 dialer-list 2 protocol ip permit
!  
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

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

Rouer1# show ip ospf interface Async1
 Async1 is up, line protocol is up (spoofing)
   Internet Address 192.158.254.13/32, Area 1
   Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:869
   Transmit Delay is 1 sec, State POINT_TO_POINT,
   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:02
   Index 1/2, flood queue length 0
   Next 0x0(0)/0x0(0)
   Last flood scan length is 0, maximum is 1
   Last flood scan time is 0 msec, maximum is 0 msec
   Neighbor Count is 0, Adjacent neighbor count is 0
   Suppress hello for 0 neighbor(s)

الحل

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

interface Async 1
 no ip address 
 encapsulation ppp
 async default routing
 async mode dedicated
 dialer in-band
 dialer rotary-group 0 
!
interface Dialer0
 ip address 192.158.254.13 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 ppp authentication chap
 ppp chap hostname Router1
 ppp chap password 7 13061E010803
!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface Async 1
 no ip address 
 encapsulation ppp
 async default routing
 async mode dedicated
 dialer in-band
 dialer rotary-group 0 
!
interface Dialer0
 ip address 192.158.254.14 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer map ip 192.158.254.13 broadcast 12345
 dialer-group 2
 ppp authentication callin
!
dialer-list 2 protocol ip permit
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

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

السبب 6: تم تكوين دائرة طلب OSPF عبر PPP متعدد الارتباطات

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

يستخدم السيناريو التالي لإعادة إنتاج المشكلة المذكورة أعلاه.

يتم إستخدام التكوين التالي للسيناريو المذكور أعلاه.

interface Multilink1 
 ip address 192.158.254.1 255.255.255.0 
 no cdp enable 
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
interface Serial0/1/0:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/1:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/2:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 

!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

interface Multilink1 
 ip address 192.158.254.2 255.255.255.0 
 no cdp enable 
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
interface Serial0/1/0:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/1:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/2:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 

!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

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

Router1# show ppp multilink   
 Multilink1, bundle name is Router2 
   Bundle up for 00:05:35 
   Bundle is Distributed 
   0 lost fragments, 0 reordered, 0 unassigned 
   0 discarded, 0 lost received, 3/255 load 
   0x1226 received sequence, 0x1226 sent sequence 
   Member links: 3 active, 0 inactive (max not set, min not set) 
     Serial1/0/0:0, since 00:05:35, no frags rcvd 
     Serial1/0/1:0, since 00:05:35, no frags rcvd 
     Serial1/0/2:0, since 00:05:35, no frags rcvd

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

Router1# show interface multilink 1 
Multilink1 is up, line protocol is up 
  Hardware is multilink group interface 
  Internet address is 192.168.254.1/24 
  MTU 1500 bytes, BW 5952 Kbit, DLY 100000 usec, 
     reliability 255/255, txload 3/255, rxload 3/255 
  Encapsulation PPP, loopback not set 
  Keepalive set (10 sec) 
  DTR is pulsed for 2 seconds on reset 
  LCP Open, multilink Open 
  Open: IPCP 
  Last input 00:00:00, output never, output hang never 
  Last clearing of "show interface" counters 00:06:39 
  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 
  Queueing strategy: fifo 
  Output queue :0/40 (size/max) 
  5 minute input rate 241000 bits/sec, 28 packets/sec 
  5 minute output rate 241000 bits/sec, 28 packets/sec 
     6525 packets input, 9810620 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     6526 packets output, 9796112 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     0 carrier transitions

يعرض إخراج واجهة show ip ospf تكلفة OSPF الحالية، وهي 16.

Router1# show ip ospf interface multilink 1
      Multilink1 is up, line protocol is up 
        Internet Address 192.158.254.13/24, Area 1
       Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:16
       Transmit Delay is 1 sec, State POINT_TO_POINT,
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
        Hello due in 00:00:02
       Index 1/2, flood queue length 0
       Next 0x0(0)/0x0(0)
       Last flood scan length is 0, maximum is 1
       Last flood scan time is 0 msec, maximum is 0 msec
       Neighbor Count is 0, Adjacent neighbor count is 0
       Suppress hello for 0 neighbor(s)

الآن الرابط ينزل إلى الأسفل و نستطيع أن نرى ذلك في السجل:

Router1# show log | include down 
 
%LINK-3-UPDOWN: Interface Serial1/0/0:0, changed state to down 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:0, changed state to down

إذا فحصنا عرض النطاق مرة أخرى سيكون مختلفا عما رأيناه سابقا. الآن هو عرض 3968 والحزمة لها فقط إثنان قارن بدلا من ثلاثة لأن واحد قارن سقطت. ملاحظة أسفل الواجهة ما زالت قيد التشغيل:

Router1# show ppp multilink   
 Multilink1, bundle name is Router2 
   Bundle up for 00:05:35 
   Bundle is Distributed 
   0 lost fragments, 0 reordered, 0 unassigned 
   0 discarded, 0 lost received, 3/255 load 
   0x1226 received sequence, 0x1226 sent sequence 
   Member links: 2 active, 1 inactive (max not set, min not set) 
     Serial1/0/1:0, since 00:05:35, no frags rcvd 
     Serial1/0/2:0, since 00:05:35, no frags rcvd 
     Serial1/0/0:0 (inactive)

كما أن إرتباط PPP المتعدد لا يزال يظهر، ولكن تم تغيير تكلفة OSPF الآن إلى 25 نظرا لانقطاع إرتباط واحد

Router1# show ip ospf interface multilink 1
      Multilink1 is up, line protocol is up 
        Internet Address 192.158.254.13/24, Area 1
       Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:25
       Transmit Delay is 1 sec, State POINT_TO_POINT,
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
        Hello due in 00:00:02
       Index 1/2, flood queue length 0
       Next 0x0(0)/0x0(0)
       Last flood scan length is 0, maximum is 1
       Last flood scan time is 0 msec, maximum is 0 msec
       Neighbor Count is 0, Adjacent neighbor count is 0
       Suppress hello for 0 neighbor(s)

وهذا ما سوف يؤدي إلى تشغيل عملية حساب عامل الأمان (SPF)، وسوف يعمل OSPF على رفع دائرة الطلب. إذا استمر الارتباط في التدفق، فقد نرى دائرة الطلب تستمر في التدفق لأن التكلفة ستتغير في كل مرة يتم فيها إضافة إرتباط أو يتم حذفه من حزمة PPP متعددة الارتباطات.

الحل

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

interface Multilink1 
 ip address 192.158.254.1 255.255.255.0 
 no cdp enable  
 ip ospf cost 10
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

interface Multilink1 
 ip address 192.158.254.2 255.255.255.0 
 no cdp enable  
 ip ospf cost 10
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

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

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

• صفحة دعم OSPF
• الدعم الفني - Cisco Systems