تصور کنید در ساعات اوج ترافیک کاری، ارتباط دیتاسنتر اصلی با شعب سازمان قطع شده و ترمینالِ سیستم شما (روی روتر یا سوییچ سیسکو) پر از ارورهای نامفهوم OSPF است. در این لحظات پراسترس، وارد کردن کدهای تصادفی و آزمونوخطا نه تنها کمکی نمیکند، بلکه ممکن است یک قطعی کوچک را به یک فاجعه تبدیل کند. شما زمان ندارید تا کتابهای چندصد صفحهای سیسکو را ورق بزنید؛ بلکه به یک ساختار ذهنی دقیق نیاز دارید تا بفهمید چرا روترها در وضعیت ExStart قفل شدهاند یا اصلاً به هم سلام نمیکنند. در این راهنمای کاربردی، ما از تئوریهای خستهکننده عبور میکنیم و یک مسیر قدمبهقدم برای عیبیابی OSPF در سیسکو در اختیار شما میگذاریم تا در سریعترین زمان ممکن، پایداری را به شبکه برگردانید.
پیشنیازهای تشکیل همسایگی در OSPF
برای درک بهتر فرآیند «همسایگی» (Adjacency) در OSPF، بیایید آن را شبیه به امضای یک قرارداد همکاری بین دو شرکت در نظر بگیریم. قبل از اینکه این دو شرکت (روترها) اطلاعات مهم و محرمانه خود (جداول مسیریابی) را با هم به اشتراک بگذارند، ابتدا باید مطمئن شوند که زبان مشترکی دارند و روی قوانین پایهای توافق کردهاند.
در شبکههای OSPF، این توافق اولیه با ارسال پیامهای احوالپرسی به نام Hello انجام میشود. وقتی دو روتر با کابل به هم متصل میشوند، ابتدا فرمهای Hello خود را برای یکدیگر میفرستند تا تنظیمات هم را چک کنند.
قانون طلایی OSPF: روترها به شدت قانونمدار هستند. اگر حتی یکی از پارامترهای حیاتی در این فرمها با هم مطابقت نداشته باشد، روترها به هم اعتماد نکرده، فرآیند همسایگی در همان قدم اول متوقف میشود و شبکه دچار اختلال میگردد.
در جدول زیر، این «شروط الزامی» را بررسی کردهایم. برای داشتن یک ارتباط سالم، تنظیمات زیر در دو سر لینک باید دقیقاً یکسان باشند:
| پارامتر (شرط توافق) | دلیل اهمیت آن چیست؟ | اگر یکسان نباشد چه میشود؟ |
|---|---|---|
| تایمرها | روترها باید دقیقاً توافق کنند که هر چند ثانیه یکبار به هم سلام کنند و بعد از چند ثانیه بیخبری، همسایه را «قطع شده» در نظر بگیرند. | ارتباط اصلاً شکل نمیگیرد و وضعیت در حالت Down میماند. |
| (Area ID) شناسه ناحیه | مثل این است که دو نفر در دو کشور مختلف باشند. روترهایی که با کابل به هم متصلاند حتماً باید عضو یک «ناحیه» (Area) مشترک باشند. | روترها پیامهای هم را نادیده میگیرند. |
| (Subnet Mask) ماسک شبکه | در شبکههای کابلی (مثل اترنت)، هر دو روتر باید دقیقاً در یک رِنجِ آیپی (زیرشبکه) باشند تا بتوانند پیامهای گروهی (Multicast) یکدیگر را بشنوند. | همسایگی در همان مراحل اولیه متوقف میشود. |
| (MTU) سایز بسته | نشاندهنده ظرفیت انتقال دیتاست. اگر ظرفیت انتقال یک روتر کمتر از دیگری باشد، بستههای بزرگ اطلاعاتی در مسیر جا نمیشوند و میریزند (Drop میشوند). | روترها در مرحله تبادل اطلاعات (وضعیت ExStart) گیر میکنند. |
| (Authentication) احراز هویت | اگر برای امنیت شبکه رمز گذاشتهاید، بدیهی است که نوع قفل (مثلاً MD5) و خودِ رمز عبور باید در هر دو سمت موبهمو یکی باشد. | اجازه ورود داده نمیشود و ارتباط قطع میگردد. |
| (Stub Area Flag) نوع ناحیه | روترها باید قبول کنند که ناحیهشان از چه نوعی است (مثلاً آیا یک ناحیه بنبست یا Stub است یا خیر). | پیامهای Hello به عنوان دیتای نامعتبر رد میشوند. |
تسلط بر این ۶ پیشنیاز، به شما کمک میکند تا در زمان قطعی شبکه، به جای سردرگمی، مستقیماً به سراغ چک کردن پارامترهای بالا بروید و مشکل را در سریعترین زمان ممکن ریشهیابی کنید.
عیبیابی مرحلهبهمرحله پروتکل مسیریابی OSPF
وارد کردن تصادفی دستورات روی روترها نه تنها کمکی به حل مشکل نمیکند، بلکه ممکن است باعث قطعیهای گستردهتری شود.
در این بخش، جریان کاری استاندارد برای ریشهیابی و رفع خطای Adjacency OSPF را در قالب یک سناریوی عملی بررسی میکنیم.
از پایینترین لایه شروع کنید؛ بررسی وضعیت اینترفیسها (Layer 1 & 2)
پیش از آنکه به سراغ جداول مسیریابی و پیچیدگیهای لایه ۳ بروید، باید از سلامت فیزیکی مسیر مطمئن شوید. اگر اینترفیس شما در لایه فیزیکی (کابلکشی) یا لایه دیتا-لینک (پروتکلهای خط) دچار مشکل باشد، پردازش هرگونه ترافیک OSPF در همان نقطه متوقف میشود و عملاً بحث درباره تایمرها یا Area بیمعنی است.
برای بررسی سریع این لایه، از دستور پایه زیر استفاده کنید:
در این خروجی، ستون Status و Protocol باید هر دو در وضعیت Up باشند.
نکته: اگر پورت در وضعیت Administratively Down است، با ورود به محیط پیکربندی اینترفیس و اجرای دستور no shutdown آن را فعال کنید. اما اگر با وضعیت Down/Down مواجه شدید، پیش از هرگونه تغییر در پیکربندی OSPF سیسکو، به بررسی فیزیکی کابلها، ماژولهای SFP، پورت سوییچ متصل به روتر و احتمال وجود مشکل لینک یکطرفه (Unidirectional Link) بپردازید.
عیبیابی تضاد در Hello/Dead Timers؛ شایعترین دلیل قطعی
زمانبندیها، ضربان قلب پروتکل OSPF هستند. روترها برای اطمینان از حضور همسایه خود، در فواصل زمانی مشخصی بستههای Hello را ارسال میکنند. یکی از پیشنیازهای قطعی برای تشکیل همسایگی این است که تایمرهای Hello و Dead در دو سر لینک دقیقاً با یکدیگر تطابق داشته باشند. این مشکل معمولاً زمانی رخ میدهد که مدیر شبکه برای تسریع همگرایی، تایمرهای یک روتر را بهینهسازی میکند اما تغییرات سمت مقابل را فراموش میکند. در این حالت، روترها بستههای یکدیگر را نادیده گرفته و همسایگی هرگز شکل نمیگیرد.
ارور لاگ واقعی سیسکو (از طریق Debug)
OSPF: Rcv hello from 10.1.1.2 area 0 from GigabitEthernet0/0 mismatched Hello timer
نکته: با دستور show ip ospf interface تایمرهای فعال روی پورت خود را بخوانید. اگر متوجه تضاد شدید، وارد اینترفیس مربوطه شده و تایمرها را با روتر مقابل همگام کنید یا به حالت پیشفرض برگردانید:
Router(config-if)# ip ospf dead-interval 40
محصول پیشنهادی جهت خرید سوئیچ سیسکو
تلههای پنهان؛ تحلیل ارور MTU و تضاد در Area ID
یکی از گیجکنندهترین چالشها در دستورات عیبیابی OSPF، زمانی است که همسایگی تشکیل میشود اما در میانه راه متوقف میماند.
تحلیل ارور MTU در OSPF: پروتکل OSPF برای تبادل اطلاعات جداول مسیریابی خود از بستههای بزرگی به نام DBD (Database Description) استفاده میکند. اگر پیکربندی MTU (حداکثر واحد انتقال) در دو سمت لینک متفاوت باشد، روتر با MTU کوچکتر نمیتواند بستههای بزرگتر سمت مقابل را پردازش کند و آنها را Drop میکند. در این شرایط، وضعیت همسایگی دقیقاً در مرحله تبادل دیتابیس (وضیعت ExStart یا Exchange) گیر میکند.
ارور لاگ واقعی (MTU Mismatch)
نکته حرفهای: همواره با دستور show interfaces مقدار MTU هر دو روتر را چک کنید. بهترین راهحل، یکسانسازی MTU با دستور ip mtu <size> در سطح اینترفیس است. در سناریوهای اضطراری که روتر مقابل در کنترل شما نیست (مثلاً تجهیزات یک وندور دیگر)، میتوانید با دستور زیر از این خطا چشمپوشی کنید.
تحلیل خطای Area ID Mismatch: روترهای متصل به یک لینک باید حتماً در یک Area مشترک قرار داشته باشند. در غیر این صورت، بستههای Hello به عنوان اطلاعات نامعتبر رد میشوند.
ارور لاگ واقعی (Area ID Mismatch)
نکته حرفهای: تنظیمات بلوک router ospf را مرور کنید. بررسی کنید که دستور network یا دستورات پیکربندی سطح اینترفیس، پورت مورد نظر را به اشتباه در Area دیگری قرار نداده باشند.
چالشهای امنیتی؛ بررسی مشکلات احراز هویت
در شبکههای سازمانی حساس، ایمنسازی تبادلات مسیریابی یک استاندارد الزامی است. OSPF از روشهای مختلفی مانند Plaintext (متن ساده) و MD5 (رمزنگاری شده) پشتیبانی میکند. عدم تطابق در نوع احراز هویت یا اشتباه تایپی در کلمه عبور، باعث میشود روترها نتوانند هویت یکدیگر را تایید کنند و در نتیجه، رفع مشکل همسایگی OSPF به بنبست میخورد.
ارور لاگ واقعی (Authentication Failure)
%OSPF-4-ERRRCV: Received invalid packet: mismatch authentication key
نکته حرفهای: اگر از روش امنترِ MD5 استفاده میکنید، به یاد داشته باشید که علاوه بر یکسان بودن رمز عبور، شناسه کلید (Key ID) نیز باید دقیقاً در دو سر لینک برابر باشد. با دستور show run interface <id> وضعیت پورت را بررسی کرده و فرمت دستور را به شکل زیر اصلاح کنید:
تحلیل وضعیتهای روتر در OSPF
درک چرخه حیات همسایگی و وضعیتهای OSPF در سیسکو، قطبنمای شما در مسیر عیبیابی OSPF در سیسکو است. فرآیند تشکیل همسایگی از یک مسیر خطی و مشخص عبور میکند و هر وضعیت، نشاندهنده یک فاز دقیق از مذاکرات بین دو روتر است.
آگاهی از اینکه توقف و گیر کردن در هر مرحله چه معنایی دارد، زمان کشف و رفع خطای Adjacency OSPF را به حداقل میرساند. در ادامه، تمامی ۷ وضعیت OSPF و نشانههای گیر کردن در آنها را بررسی میکنیم:
وضعیت Down (قطع کامل)
شرح وضعیت: در این حالت، روتر هیچ بسته Helloای از سمت همسایه خود دریافت نکرده است. البته روتر همچنان در حال ارسال بستههای Hello به آدرس Multicast است تا شاید همسایهای پیدا کند.
گیر کردن در این مرحله نشانه چیست؟ معمولاً نشاندهنده قطعی در لایه ۱ یا ۲، عدم تطابق کامل تنظیمات پایه (مثل متفاوت بودن Subnet)، یا فعال بودن قابلیت passive-interface روی روتر مقابل است که مانع از ارسال پیام Hello میشود.
وضعیت Init (دریافت اولیه)
شرح وضعیت: روتر یک بسته Hello از همسایه دریافت کرده است، اما هنوز Router ID خودش را در لیست همسایههای داخل آن بسته Hello نمیبیند. یعنی ارتباط هنوز یکطرفه است.
گیر کردن در این مرحله نشانه چیست؟ گیر کردن در حالت Init یک هشدار جدی برای وجود لینک یکطرفه (Unidirectional Link) است؛ به این معنی که روتر مقابل بستههای شما را دریافت نمیکند یا یک Access-List (ACL) در مسیر، ترافیک برگشتی OSPF را مسدود کرده است.
وضعیت 2-Way (ارتباط دوطرفه کامل)
شرح وضعیت: روتر اکنون Router ID خود را در بسته Hello همسایه میبیند و ارتباط دوطرفه (Bi-directional) تایید شده است. در شبکههای Multi-Access (مثل اترنت)، در همین مرحله است که انتخابات DR (Designated Router) و BDR انجام میشود.
گیر کردن در این مرحله نشانه چیست؟
حالت طبیعی: اگر هر دو روتر در شبکه اترنت نقش DROther (روترهای معمولی) را داشته باشند، توقف در این مرحله کاملاً طبیعی است و خطایی محسوب نمیشود (آنها با هم تبادل دیتابیس نمیکنند تا ترافیک شبکه کاهش یابد).
حالت خطا: اگر این اتفاق روی یک لینک Point-to-Point بیفتد، یا روترها باید DR/BDR شوند اما در 2-Way گیر کردهاند، نشاندهنده این است که Priority تمام روترهای آن سگمنت روی 0 تنظیم شده است و هیچ روتری حاضر نیست نقش DR را بپذیرد.
وضعیت ExStart (بحرانیترین فاز)
شرح وضعیت: ارتباطات اولیه شکل گرفته و روترها آماده تبادل اطلاعات جداول خود هستند. در این مرحله، دو روتر با یکدیگر مذاکره میکنند تا مشخص شود کدام روتر نقش Master (شروعکننده ارسال اطلاعات) و کدام نقش Slave را بر عهده میگیرد. این انتخاب بر اساس بالاترین Router ID انجام میشود.
گیر کردن در این مرحله نشانه چیست؟ توقف ممتد در وضعیت ExStart قطعیترین و معروفترین نشانه برای ارور MTU در OSPF است. اگر MTU در دو سر لینک برابر نباشد، مذاکرات Master/Slave و ارسال بستههای سنگین دیتابیس با شکست مواجه شده و روترها در همین نقطه متوقف میشوند.
وضعیت Exchange (تبادل سرآیندها)
شرح وضعیت: روترها در حال تبادل بستههای DBD (مخفف Database Description) هستند که حاوی خلاصهای (Header) از جداول مسیرهایشان (LSA) است.
گیر کردن در این مرحله نشانه چیست؟ مشابه وضعیت ExStart، گیر کردن در این مرحله نیز عمدتاً به دلیل MTU Mismatch رخ میدهد؛ بهویژه زمانی که بستههای DBD آنقدر بزرگ میشوند که از ظرفیت MTU تنظیمشده فراتر رفته و در طول مسیر دراپ (Drop) میشوند.
وضعیت Loading (بارگذاری جزئیات)
شرح وضعیت: روترها خلاصههای دیتابیس یکدیگر را خواندهاند و اکنون با ارسال درخواست (LSR)، جزئیات کامل مسیرهایی (LSU) را که ندارند، از همسایه طلب میکنند.
گیر کردن در این مرحله نشانه چیست؟ گیر کردن در حالت Loading نادر است اما معمولاً به دلیل مشکلات حافظه (Memory/RAM) روتر در پردازش جداول بسیار بزرگ LSA، یا خراب شدن بستهها (Corruption) در سطح لینک فیزیکی اتفاق میافتد.
وضعیت Full (همگرایی کامل و ایدهآل)
شرح وضعیت: دیتابیس (LSDB) هر دو روتر اکنون دقیقاً سینک و یکپارچه است و فرآیند رفع مشکل همسایگی OSPF با موفقیت به پایان رسیده است. در این حالت، الگوریتم SPF برای محاسبه بهترین مسیرها وارد عمل میشود.
دستورات نجاتبخش OSPF (Diagnostic Commands)
شناخت تئوری وضعیتها و تایمرهای OSPF تنها نیمی از مسیر است؛ نیمه دیگر، تسلط بر ابزارهایی است که به شما نشان میدهند درون پردازنده روتر دقیقاً چه میگذرد. در لحظات بحرانی قطعی شبکه، وارد کردن دستورات اشتباه یا ناتوانی در تفسیر خروجیها میتواند زمان طلایی بازیابی (Downtime) را افزایش دهد.
دستورات تشخیصی در سیستمعامل سیسکو (IOS)، چشم و گوش یک متخصص شبکه برای ریشهیابی و رفع خطای Adjacency OSPF هستند.
تحلیل خروجی show ip ospf neighbor
این دستور، مهمترین و پرکاربردترین ابزار شما در عیبیابی OSPF در سیسکو است. خروجی این دستور یک نمای کلی از وضعیت فعلی تمام همسایههای کشفشده به شما میدهد.
نمونه خروجی واقعی CLI
Neighbor ID Pri State Dead Time Address Interface
10.255.255.2 1 FULL/BDR 00:00:34 192.168.12.2 GigabitEthernet0/0
10.255.255.3 0 2-WAY/DROTHER 00:00:31 192.168.12.3 GigabitEthernet0/0
192.168.50.1 1 EXSTART/- 00:00:37 10.1.1.2 Serial0/1/0
تشریح:
- Neighbor ID: این ستون Router ID همسایه را نشان میدهد (نه لزوماً آیپی اینترفیس متصل به شما).
- Pri (Priority): اولویت روتر همسایه در انتخابات DR/BDR را نشان میدهد. اگر این عدد 0 باشد، یعنی روتر همسایه هرگز نمیتواند DR یا BDR شود (مانند روتر دوم در خروجی بالا).
- State: این ستون ترکیب دو مفهوم است: وضعیت فعلی همسایگی و نقش روتر در شبکه (DR/BDR/DROther). مثلاً FULL/BDR یعنی همسایگی کامل است و روتر مقابل نقش Backup Designated Router را دارد. اگر علامت – را دیدید (مثل EXSTART/-)، یعنی شبکه از نوع Point-to-Point است و انتخاباتی در کار نیست.
- Dead Time: شمارش معکوس تایمر انقضا. با دریافت هر بسته Hello، این تایمر ریست میشود.
- Address: آیپی لایه ۳ اینترفیسی که همسایه از طریق آن به شما متصل است.
نکته حرفهای:
اگر خروجی دستور show ip ospf neighbor کاملاً خالی بود، یعنی یا در لایه ۱ و ۲ قطعی دارید، یا تایمرها تضاد دارند، یا دستور passive-interface روی پورت مورد نظر فعال شده و ارسال Hello متوقف شده است. برای بررسی دقیقتر بلافاصله show ip ospf interface را چک کنید.
محصول پیشنهادی جهت خرید سوئیچ سیسکو
استفاده از debug ip ospf adj
زمانی که دستورات show اطلاعات کافی به شما نمیدهند (مثلاً همسایه اصلاً در لیست دیده نمیشود یا در وضعیت خاصی گیر کرده است)، باید سراغ بررسی لاگهای زنده (Real-time) بروید. دستور debug ip ospf adj تمامی رویدادهای مربوط به تشکیل همسایگی، از جمله دریافت و ارسال بستههای Hello، تطابق تایمرها، احراز هویت و ارورهای MTU را مستقیماً روی ترمینال چاپ میکند.
نمونه لاگ واقعی (عدم تطابق پسورد در MD5)
OSPF adjacency events debugging is on
%OSPF-4-ERRRCV: Received invalid packet: mismatch authentication key from 192.168.1.2, GigabitEthernet0/0
هشدار امنیتی و فنی بسیار مهم:
اجرای دستورات debug در محیطهای عملیاتی و روی روترهای Core که ترافیک و پردازش بالایی دارند، بسیار خطرناک است. فرآیند دیباگ بالاترین اولویت را در پردازنده (CPU) روتر دارد. اگر شبکه شما شلوغ باشد، چاپ کردن صدها خط لاگ در ثانیه باعث درگیری ۱۰۰ درصدی CPU (اصطلاحاً CPU Spike)، از کار افتادن پروتکلهای مسیریابی و در نهایت Crash کردن کامل روتر و قطعی کل دیتاسنتر میشود.
نکته حرفهای: برای استفاده ایمن از دیباگ در شبکههای حساس:
۱. ابتدا یک Access-List بنویسید که فقط آیپی همسایه مشکلدار را شامل شود access-list 10 permit 192.168.1.2.
۲. دیباگ را محدود به آن ACL کنید: debug ip ospf adj 10.
۳. حتماً انگشتتان روی کیبورد آماده باشد تا به محض دیدن ارور (مثلاً ارور MTU یا Auth)، بلافاصله دستور u all (مخفف undebug all) را برای متوقف کردن پروسه وارد کنید.
بررسی سناریوها و چالشهای پیچیده OSPF
در شبکههای بزرگ ، پروتکل OSPF معمولاً با تکنولوژیهای لایه ۲ و تونلینگ ترکیب میشود. این ترکیبها میتوانند باعث بروز رفتارهای غیرقابل پیشبینی شوند که نیازمند عیبیابی پیشرفته هستند.
۱. چالشهای لینکهای WAN: تونلهای GRE و خطای MTU
یکی از سناریوهای به شدت درگیرکننده، اجرای OSPF بر روی تونلهای GRE یا لینکهای ارتباطی WAN (مانند ارتباطات بین استانی) است. هدر GRE دقیقاً ۲۴ بایت (۲۰ بایت IP و ۴ بایت GRE) به بسته اضافه میکند. اگر پروتکل OSPF بخواهد LSAهای بزرگی را تبادل کند، حجم بستههای DBD از MTU تونل (معمولاً ۱۴۷۶ بایت) فراتر رفته و به دلیل عدم تطابق با MTU اینترفیس فیزیکی (۱۵۰۰ بایت)، بستهها Drop میشوند. نتیجه این امر، توقف فرآیند در وضعیت ExStart است.
ارور لاگ واقعی
نکته حرفهای:
راهحل اول (اصولی): سایز MTU تونل را در هر دو سمت تنظیم کنید.
Router(config-if)# ip tcp adjust-mss 1360
راهحل دوم: از دستور نادیده گرفتن خطای MTU استفاده کنید. همچنین، برای جلوگیری از ترافیک اضافی انتخابات DR/BDR روی تونل، حتماً نوع شبکه را به Point-to-Point تغییر دهید:
Router(config-if)# ip ospf network point-to-point
۲. مشکلات OSPF در شبکههای Multi-Access؛ چالشهای DR/BDR
در شبکههای اترنت، OSPF برای جلوگیری از ترافیک عظیم و Full-Mesh شدن همه روترها، یک روتر را به عنوان نماینده (DR) و دیگری را به عنوان پشتیبان (BDR) انتخاب میکند.
سناریوی بحرانی:
اگر مدیر شبکه برای جلوگیری از DR شدن روترهای ضعیف، ip ospf priority 0 را روی تمامی روترهای یک سگمنت تنظیم کند، هیچ روتری نقش DR را نمیپذیرد. در نتیجه، همه روترها در وضعیت 2-Way گیر میکنند و هیچ تبادل دیتابیسی (LSDB) شکل نمیگیرد. شبکه کاملاً قطع میماند.
همچنین، اگر روتری با پردازنده ضعیف به اشتباه DR شود (به دلیل روشن شدن زودتر یا Router ID بالاتر)، زیر بار پردازش LSAهای شبکه به شدت کند شده و ممکن است Crash کند.
نکته حرفهای
برای کنترل دقیق انتخابات، روی اینترفیسِ قویترین روتر شبکه (Core Switch/Router)، بالاترین Priority را ست کنید (مثلاً ۲۵۵):
سپس برای اعمال تغییرات بدون نیاز به ریبوت سختافزاری، پروسه OSPF را مجدداً راهاندازی کنید:
چکلیست عیبیابی سریع (برای مدیران شبکه)
در لحظه قطعی، استرس بالا مانع از تصمیمگیری درست میشود. این چکلیست گامبهگام به شما کمک میکند تا رفع خطای Adjacency OSPF را در کمتر از ۵ دقیقه انجام دهید.
| گام | اقدام کنترلی (Action) | دستور تشخیصی (Command) | هدف از بررسی |
|---|---|---|---|
| ۱ | بررسی وضعیت لایه فیزیکی | show ip interface brief | اطمینان از Up/Up بودن پورت متصل به همسایه. |
| ۲ | پینگ لایه ۳ (ارتباط مستقیم) | ping | آیا پورت مقابل اصلاً در دسترس است؟ |
| ۳ | بررسی ارسال/دریافت OSPF | show ip ospf interface | بررسی تطابق Hello/Dead Timer و بررسی Area ID. |
| ۴ | مشاهده وضعیت همسایهها | show ip ospf neighbor | کشف وضعیت فعلی (آیا در Init، ExStart یا 2-Way گیر کرده؟). |
| ۵ | بررسی تنظیمات MTU | show interfaces | مقایسه MTU دو سمت لینک در صورت توقف در ExStart. |
| ۶ | دیباگ زنده ترافیک (با احتیاط) | debug ip ospf adj | کشف خطاهای پنهان مثل Authentication Failure. |
| ۷ | بررسی جدول روتینگ | show ip route ospf | آیا مسیرهای OSPF دریافت و نصب شدهاند؟ |
سوالات متداول
❓ آیا OSPF از طریق پورتهای ترانک (Trunk) رد میشود؟
بله، کاملاً. OSPF به لایه ۲ وابستگی ندارد. در سوئیچهای لایه ۳، اگر اینترفیسهای مجازی (SVI/VLAN Interface) دارای آیپی باشند و دستور ip routing در سوئیچ فعال باشد، بستههای مالتیکست OSPF (با آیپی 224.0.0.5 و 224.0.0.6) به راحتی از پورتهای Trunk عبور کرده و بین سوییچها یا روترها همسایگی تشکیل میدهند.
❓ همسایگی OSPF من در وضعیت 2-Way متوقف شده است؛ آیا این یک خطاست؟
نه لزوماً. در شبکههای اترنت، روترهایی که نقش DR یا BDR را ندارند (به آنها DROther میگویند)، با یکدیگر تنها تا وضعیت 2-Way بالا میآیند تا از افزونگی ترافیک جلوگیری کنند. این رفتار کاملاً طبیعی است. اما اگر این اتفاق روی یک لینک Point-to-Point افتاد، نشاندهنده یک مشکل است.
❓ ارور Too many retransmissions و گیر کردن در ExStart چگونه برطرف میشود؟
این قطعیترین نشانه برای ارور MTU در OSPF است. بستههای DBD بیش از حد بزرگ هستند و دراپ میشوند. با استفاده از دستور ip mtu سایز پورتها را یکسان کنید یا در سطح اینترفیس از دستور نجاتبخش ip ospf mtu-ignore استفاده نمایید.
❓ در دستورات عیبیابی OSPF، تفاوت clear ip ospf process با خاموش/روشن کردن پورت چیست؟
دستور clear ip ospf process دیتابیس (LSDB) پروتکل OSPF را روی همان روتر پاک کرده و جداول را مجبور به محاسبه مجدد (SPF) میکند. این کار بدون ایجاد قطعی فیزیکی در پورت انجام میشود، اما به هر حال باعث قطعی موقت چند ثانیهای در مسیریابی شبکه میشود. خاموش کردن پورت، تمامی پروتکلها و ترافیک عبوری را قطع میکند.
کلام آخر
پروتکل OSPF با تمام هوشمندی و سرعت بالای خود، به شدت قانونمدار است. همانطور که در این راهنما دیدیم، بیشتر قطعیها نه به دلیل باگهای عجیب نرمافزاری، بلکه به خاطر خطاهای انسانی در تنظیم تایمرها، تضاد در سایز MTU یا اشتباهات تایپی در رمز عبور رخ میدهند. موفقیت در عیبیابی OSPF در سیسکو نیازمند حفظ آرامش در لحظه قطعی و پیروی از یک جریان کاری (Workflow) لایهای است.
