בפרוטוקול OSPF (Open Shortest Path First), כל נתב מחשב את הנתיב הקצר ביותר לרשת על סמך המידע המתקבל מהשכנים המחוברים ישירות שלו.

תצורת OSPF כרוכה בדרך כלל בנתבים המחליפים מידע על Link State Advertisements (LSA) רק עם נתבים אחרים שהם שכנים ישירים באותה רשת מקומית (LAN) או רשתות משנה רחבות (WAN).

בעיות בהגדרת שכנים OSPF שאינם מחוברים ישירות

1. הפרת אזור OSPF: OSPF נועד לעבוד עם שכנים שנמצאים באותו אזור. ניסיון ליצור קשר סמיכות עם נתב שאינו נמצא באותו אזור מחובר ישירות יכול לגרום לבעיות ניתוב, מכיוון שאזורי OSPF חייבים להיות רציפים.
2. כשל בהקמת סמיכות: OSPF משתמש בתהליך "שלום" כדי ליצור ולתחזק קשרי סמיכות עם נתבים אחרים. תהליך זה תלוי בכך שהנתבים יוכלו לתקשר ישירות זה עם זה. אם תנסה להגדיר שכן OSPF שאינו מחובר ישירות, סביר להניח שהמנות "שלום" לא יגיעו לנתב השני, וימנעו היווצרות של סמיכות.
3. מבול LSA: למרות שניתן מבחינה טכנית להגדיר מנהרות או VPN לחיבור שני נתבי OSPF שאינם מחוברים ישירות ולנסות ליצור סמיכות, הדבר עלול להוביל להצפה של LSA לא יעילה או להפצת מסלולים לא הולמת, מכיוון ש-OSPF לא נועד להתמודד עם סוגים אלה של תצורות באופן מקורי.
4. מסלולים לא אופטימליים ולולאות ניתוב: קביעת תצורה של שכן OSPF שאינו מחובר ישירות עלולה להוביל ליצירת מסלולים לא אופטימליים ולולאות ניתוב פוטנציאליות, במיוחד אם הרשת הבסיסית אינה מוגדרת לטפל כראוי במצבים אלו.

פתרונות וחלופות

• השתמש בנתיבים סטטיים או בפרוטוקולים של ניתוב שכבת תחבורה: במקום לכפות מערכת יחסים של OSPF עם נתב שאינו מחובר ישירות, תוכל לשקול שימוש בנתיבים סטטיים (אם זה אפשרי מבחינה מנהלתית) או להשתמש בפרוטוקולי ניתוב אחרים שנועדו לטפל בחיבורים ברשתות גדולות יותר, כגון BGP.
• VPN ו-OSPF על GRE: אם אתה צריך לגרום לשני אתרים מרוחקים להיראות מחוברים ישירות עבור OSPF, שקול להגדיר מנהרת GRE דרך IPsec. OSPF יכול לדרוס את GRE ותתייחס למנהרה כאל קישור ישיר, המאפשר הפצה של LSAs ותחזוקה של סמיכות.

לסיכום, ניסיון להגדיר שכנה OSPF שאינו מחובר ישירות ללא אמצעים נוספים כגון מנהרות עשוי להוביל לכשלים והתנהגות בלתי צפויה בתוך MikroTik או כל רשת אחרת המשתמשת ב-OSPF.

מומלץ לעקוב אחר נוהלי התכנון הסטנדרטיים של OSPF כדי למנוע בעיות אלו.