چرا OSPF Neighbor در MikroTik به Full نمی‌رسد؟ عیب‌یابی Hello، MTU و Area

اگر OSPF Neighbor در MikroTik به Full نمی‌رسد، نخست وضعیت همسایه را با /routing/ospf/neighbor/print detail بخوانید؛ سپس Hello/Dead، Area، Network Type، Router ID، MTU و عبور بسته‌های OSPF را در هر دو روتر بررسی کنید. ماندن در Init معمولاً نشانه مشکل ارتباط دوطرفه Hello است؛ ExStart و Exchange می‌توانند با MTU یا تبادل Database Description مرتبط باشند. توجه: روی شبکه Broadcast، وضعیت 2-Way بین دو روتر DROTHER الزاماً خطا نیست.

سناریو و پیش‌نیازها

دو روتر RouterOS v7 با IPهای 10.20.30.1/30 و 10.20.30.2/30 روی ether2 قرار دارند و باید در OSPFv2، Area 0.0.0.0 همسایه شوند. نام Interface، IP و شماره Template در دستورات نمونه‌اند؛ پیش از تغییر با شبکه واقعی تطبیق دهید. برای مرور مفاهیم، مبانی پروتکل OSPF و تشکیل همسایگی را ببینید.

هشدار عملیاتی: تغییر OSPF، MTU یا Firewall ممکن است مسیر مدیریت روتر را قطع کند. قبل از هر تغییر Export بگیرید، از Safe Mode در Terminal/WinBox استفاده کنید و دسترسی مستقل به روتر داشته باشید. اطلاعات حساس Export را محرمانه نگه دارید.

/export file=before-ospf-troubleshooting
/system/resource/print
/interface/print detail
/ip/address/print detail

مرحله اول: وضعیت Neighbor و OSPF Interface را بخوانید

/routing/ospf/neighbor/print detail
/routing/ospf/interface/print detail
/routing/ospf/interface-template/print detail
/routing/ospf/instance/print detail
/routing/ospf/area/print detail

در خروجی Neighbor، فیلدهای state، router-id، address، interface و area را با سمت مقابل تطبیق دهید. در Interface و Template، type، hello-interval، dead-interval و passive را ببینید. اگر Neighbor اصلاً نمایش داده نمی‌شود، ابتدا بررسی کنید Interface در Template فعال Match شده و Passive نیست.

تفسیر درست Stateها

• Down / بدون Neighbor: Hello دریافت نشده؛ Interface، Template، لایه ۲ و فایروال را بررسی کنید.
• Init: Hello رسیده اما ارتباط دوطرفه کامل نشده؛ Multicast، فیلتر و مسیر برگشت مشکوک‌اند.
• 2-Way: ارتباط دوطرفه برقرار است. در Broadcast بین دو DROTHER ممکن است وضعیت نهایی طبیعی باشد؛ برای Point-to-Point معمولاً Full انتظار می‌رود.
• ExStart / Exchange: تبادل اطلاعات پایگاه داده در جریان یا متوقف است؛ MTU، Network Type و افت بسته را بررسی کنید.
• Loading: روتر هنوز LSAهای لازم را درخواست یا دریافت می‌کند؛ توقف طولانی می‌تواند نشانه مشکل ارتباط باشد.
• Full: همسایگی کامل است؛ ولی باید نصب Route و مسیر واقعی نیز جداگانه تأیید شود.

مرحله دوم: Hello/Dead، Area و Router ID را تطبیق دهید

مطابق راهنمای MikroTik، Hello معمولاً ۱۰ ثانیه و Dead معمولاً ۴۰ ثانیه است؛ اما این‌ها پیش‌فرض‌اند و مقادیر واقعی دو سمت باید خوانده شوند. Area ID، نسخه OSPF، تنظیمات احراز هویت در صورت استفاده و Network Type نیز باید سازگار باشند. router-id هر روتر باید یکتا باشد؛ Router ID با IP Interface الزاماً یکسان نیست.

/routing/ospf/interface/print detail
/routing/ospf/interface-template/print detail
/routing/ospf/area/print detail
/routing/ospf/instance/print detail

اگر دو سمت Hello/Dead متفاوت دارند، فقط Template درست را اصلاح کنید. در نمونه زیر 0 صرفاً شماره فرضی Template است و باید با شماره واقعی خروجی print جایگزین شود:

/routing/ospf/interface-template/set 0 hello-interval=10s dead-interval=40s

مقادیر قبلی را قبل از اجرا یادداشت کنید. اگر مشکل Area یا Multicast باشد، تغییر Timer به‌تنهایی کافی نیست. روی شبکه Broadcast، Subnet و Mask دو سمت را نیز بررسی کنید؛ در Point-to-Point قواعد تطبیق Mask متفاوت است.

مرحله سوم: آیا 2-Way واقعاً مشکل است؟

در type=broadcast روترها DR و BDR انتخاب می‌کنند. دو روتر DROTHER ممکن است با یکدیگر در 2-Way باقی بمانند، چون لازم نیست همه جفت‌ها مستقیماً به Full برسند. قبل از تغییر به type=ptp نقش DR/BDR و توپولوژی را ببینید. روی لینک واقعاً دوطرفه با فقط دو روتر، PTP می‌تواند مناسب باشد؛ اما هر دو سمت باید سازگار تنظیم شوند.

/routing/ospf/neighbor/print detail
/routing/ospf/interface/print detail

به فیلدهای dr و bdr و نوع شبکه دقت کنید. وضعیت 2-Way را بدون این بررسی «خراب» اعلام نکنید.

مرحله چهارم: ExStart/Exchange و بررسی MTU

اگر Neighbor در ExStart یا Exchange می‌ماند، MTU دو Interface و مسیر میانی را مقایسه کنید. اختلاف MTU می‌تواند تبادل Database Description را مختل کند؛ ولی هر ExStart الزاماً به‌معنای MTU mismatch نیست. افت بسته، Network Type و تجهیزات واسط نیز باید بررسی شوند.

/interface/print detail
/interface/ethernet/print detail
/ip/address/print detail
/routing/ospf/neighbor/print detail

در مسیر VLAN، MTU رابط فیزیکی، VLAN و Encapsulation را با هم بسنجید. اگر مشکل در عبور Tagged/Untagged یا PVID است، عیب‌یابی Bridge VLAN Filtering و PVID در MikroTik کمک می‌کند علت لایه ۲ را جدا کنید. بدون شواهد، MTU همه رابط‌ها را تغییر ندهید.

مرحله پنجم: فایروال، IP Protocol 89 و Multicast

OSPFv2 از IP Protocol 89 استفاده می‌کند، نه پورت TCP یا UDP. روی شبکه‌های Broadcast باید عبور Multicast مرتبط با OSPF نیز بررسی شود. فیلترهای ورودی روتر، ACL تجهیزات میانی، NAT و تنظیمات Bridge/VLAN را در دو جهت ببینید.

/ip/firewall/filter/print detail
/ip/firewall/nat/print detail
/interface/bridge/vlan/print detail
/tool/sniffer/quick interface=ether2 ip-protocol=89 duration=10s

اگر نسخه RouterOS مقدار عددی فیلتر Sniffer را نپذیرفت، با Help/Tab مقدار مجاز همان نسخه را پیدا کنید. دریافت Hello فقط از یک سمت، مسیر برگشت یا فیلتر سمت مقابل را مشکوک می‌کند. Hardware Offload ممکن است بر بسته‌های قابل‌مشاهده در Sniffer اثر بگذارد؛ نتیجه را با Counter و تست سمت مقابل تطبیق دهید.

در FAQ رسمی MikroTik، Router ID تکراری، فیلتر شدن OSPF یا Multicast، تغییر بسته‌ها توسط NAT و ضعف انتقال Multicast روی برخی لینک‌های لایه ۲/بی‌سیم از علل رایج Init یا Flapping معرفی شده‌اند. فقط اگر این محدودیت واقعاً اثبات شد، Network Typeهایی مانند NBMA و Static Neighbor را با مستندات و سازگاری دو سمت بررسی کنید؛ NBMA درمان عمومی هر خطایی نیست.

مرحله ششم: OSPF روی MikroTik CHR یا سرور مجازی

اگر Peer شما RouterOS CHR روی بستر مجازی است، علاوه بر تنظیمات خود RouterOS، مسیر IP واقعی بین همسایه‌ها، سیاست عبور Protocol 89، رفتار Multicast و دسترسی مدیریتی هنگام اختلال را بررسی کنید. برای تصمیم درباره میزبانی CHR می‌توانید سرور مجازی میکروتیک وان‌سرور را بررسی کنید و قبل از سفارش، درباره پشتیبانی دقیق توپولوژی و سیاست شبکه خود سؤال کنید. انتخاب VPS جدید به‌تنهایی خطای OSPF را رفع نمی‌کند و نباید قابلیت‌هایی مثل Tagged VLAN/Trunk یا عبور Multicast خاص را بدون تأیید تضمین‌شده فرض کرد.

تأیید رفع مشکل و بررسی Routeها

پس از هر تغییر، در هر دو روتر وضعیت همسایه و مسیر را بررسی کنید و چند دوره Hello/Dead منتظر بمانید. در لینک Point-to-Point باید Neighbor پایدار به Full برسد؛ روی Broadcast معیار را با نقش DR/BDR تفسیر کنید.

/routing/ospf/neighbor/print detail
/routing/ospf/interface/print detail
/ip/route/print detail
/ping 10.20.30.2 count=5

Full شدن به‌تنهایی تضمین نمی‌کند همه مقصدها Route صحیح دارند؛ جدول Routing، VRF، Filter و مسیر برگشت را هم بررسی کنید. برای مسیرهایی که با جدول یا Rule اشتباه انتخاب می‌شوند، راهنمای عیب‌یابی Policy Routing در MikroTik را بخوانید. Ping فقط ارتباط همان مقصد را می‌سنجد.

خطاهای رایج و Rollback امن

• فرض خرابی تمام همسایه‌های 2-Way بدون بررسی DR/BDR.
• تغییر هم‌زمان MTU، Area، Timer و Firewall و از دست دادن امکان تشخیص علت.
• ساختن Interface Template تکراری یا تغییر اشتباه Template شماره 0.
• خاموش‌کردن کامل Firewall یا تغییر بدون Safe Mode روی روتر راه‌دور.
• فرض اینکه OSPF از TCP/UDP Port استفاده می‌کند یا همه VPSها Multicast یکسان دارند.

در صورت اختلال، در Safe Mode تغییرات را برگردانید یا همان مقدار قبلی Template/Interface را بازنشانی کنید. فایل Export تهیه‌شده را برای مقایسه نگه دارید؛ کل فایل را بدون بررسی روی روتر عملیاتی Import نکنید، چون ممکن است تنظیمات دیگر را نیز تغییر دهد. پس از Rollback دوباره Neighbor، Route و دسترسی مدیریت را بررسی کنید.

منابع رسمی

جزئیات فنی با راهنمای Neighbor Relationship در MikroTik RouterOS و FAQ رسمی OSPF تطبیق داده شده‌اند. نام فیلدها و رفتار برخی فرمان‌ها ممکن است بین نسخه‌های RouterOS متفاوت باشد؛ پیش از تغییر، Help همان نسخه را بررسی کنید.