المحتويات

المقدمة

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

المتطلبات

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

الاصطلاحات

نموذج الشبكة

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

الحل

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

الحل

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

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

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

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

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

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

الحل

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

الحل

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

المقدمة

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

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

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

المتطلبات

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

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

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

الاصطلاحات

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

نموذج الشبكة

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

الموجه 1

الموجه 2

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.

الموجه 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)

الحل

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

الموجه 1

الموجه 2

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.

الموجه 1

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 مرة أخرى، وهذا سوف يشعل التغيير في قاعدة البيانات مرة أخرى، لذلك تستمر هذه العملية في تكرار نفسها.

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

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

الموجه 1

الموجه 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، عندما تنهار إحدى القنوات، تبقى الواجهة مرتفعة (في وضع الانتحال). لحل المشكلة، يجب تكوين واجهة المتصل لأنها لا تنخفض أبدا. تظل واجهة المتصل قيد التشغيل (في وضع الانتحال).

الموجه 1

الموجه 2

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) متعدد الارتباطات. عندما يتم دمج روابط متعددة، سيتغير النطاق الترددي لواجهة الربط المتعدد.

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

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

الموجه 1

الموجه 2

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 يدويا باستخدام الأمر التالي.

الموجه 1

الموجه 2

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