بسیاری از دوستان وقتی به سناریوی Redistribution می‌رسند، آن را یک «اتصال ساده» می‌بینند. اما اجازه دهید صادقانه بگویم؛ در شبکه‌های سازمانی بزرگ، Redistribution جایی است که «خطای انسانی» به فاجعه تبدیل می‌شود. من شاهد بوده‌ام که تنها با یک اشتباه کوچک در Redistribution، کل جدول مسیریابیِ یک سازمان در کمتر از ۱۰ ثانیه دچار Loop شد و ترافیک بین دیتا‌سنترها کاملاً فلج گردید.
تفاوت مهندس معمولی با معمار شبکه در این است:
- مهندس معمولی: فقط می‌خواهد «ارتباط برقرار شود» (Connectivity).
- معمار شبکه: فکر می‌کند که «این ارتباط چگونه می‌تواند شبکه را زمین بزند؟» (Stability).
Route Tagging چیست و چگونه از Routing Loop جلوگیری می‌کند؟
وقتی شما مسیری را از OSPF به BGP یا برعکس می‌برید، شما فقط مسیر را منتقل نمی‌کنید؛ بلکه اطلاعات هویتی مسیر را هم تغییر می‌دهید.
- مسئله Metric: در OSPF متریک بر اساس Cost (پهنای باند) است، در BGP بر اساس Attributes. وقتی مسیری وارد یک پروتکل دیگر می‌شود، پروتکل مقصد نمی‌داند این مسیر چقدر قابل اعتماد است.
- خطر Routing Loop: تصور کنید مسیر A از طریق Redistribution از OSPF به BGP می‌رود و از سمت دیگر دوباره از BGP به OSPF بازمی‌گردد. شبکه دچار یک لوپ کلاسیک می‌شود.
- راهکار حرفه‌ای (Route Tagging): هرگز Redistribution را بدون Route-Map انجام ندهید. استفاده از Tagها (برچسب‌گذاری) حیاتی است. شما به هر مسیری که از یک پروتکل وارد دیگری می‌شود، یک عدد (Tag) می‌زنید. سپس در سمت دیگر شبکه با فیلتر به روتر می‌گویید: «اگر مسیری دیدی که تگ X دارد، آن را دوباره Redistribution نکن.» این یعنی «دیپلماسیِ مسیریابی».
Seed Metric در Redistribution چیست و چرا اهمیت دارد؟
وقتی مسیری را Redistribution می‌کنید، باید به آن متریک بدهید. اگر این کار را نکنید، روتر به‌صورت پیش‌فرض (در تجهیزات سیسکو) متریکِ «صفر» یا «نامحدود» در نظر می‌گیرد.
تجربه میدانی: همیشه Seed Metric را بر اساس «کمترین پهنای باندِ مسیر اصلی» تنظیم کنید. اگر متریک را بیش از حد بزرگ بگیرید، مسیر اصلی شما (که پایداری بالاتری دارد) از جدول خارج شده و مسیر Redistribute شده جایگزین می‌شود. این یعنی ایجاد «سیاهچاله ترافیکی» (Blackhole).
تفاوت Underlay و Overlay در معماری Spine-Leaf
تفاوت Underlay و Overlay در معماری Spine-Leaf چیست؟
BGP فقط یک پروتکل نیست؛ BGP زبانِ مذاکره بین روترهاست. در دیتاسنترهای مدرن (Spine-Leaf)، ما BGP را به دو لایه اصلی تقسیم می‌کنیم:
- لایه Underlay: وظیفه‌اش ایجاد Reachability فیزیکی بین دستگاه‌هاست (معمولاً با OSPF یا IS-IS).
- لایه Overlay: وظیفه‌اش حمل ترافیک مشتری یا سرویس‌هاست (با استفاده از MP-BGP و VXLAN).
بزرگ‌ترین اشتباه در اینجا، تلاش برای استفاده از BGP به‌عنوان یک پروتکل IGP است. BGP برای مقیاس‌پذیری (Scale) طراحی شده، نه برای سرعت همگرایی (Convergence). بنابراین، انتظار نداشته باشید که در صورت قطع شدن یک کابل، BGP در میلی‌ثانیه همگرا شود. برای سرعت روی IGP حساب کنید و برای پایداری و مهندسی ترافیک روی BGP.
مدیریت ترافیک ورودی و خروجی با BGP و حل مشکل Asymmetric Routing
یک مهندس معمولی می‌پرسد: «آیا مسیر وجود دارد؟»
یک معمار شبکه می‌پرسد: «آیا این مسیر، بهترین مسیر برای این نوع ترافیک هست؟»
در شبکه‌های بزرگ، مسئله پیدا کردن مسیر (Reachability) حل شده است؛ چالش اصلی، انتخاب مسیر بهینه است.
مدیریت ترافیک ورودی و خروجی در BGP با Attributes
BGP یکی از پیچیده‌ترین پروتکل‌هاست، چون تصمیماتش بر اساس سلسله‌مراتب (Hierarchy) ویژگی‌هاست:
- Local Preference (LP): ابزار اصلی شما برای مدیریت ترافیک خروجی (Outbound Traffic) است. اگر دو ISP دارید و می‌خواهید ترافیک سنگین دیتاسنتر از ISP-A خارج شود، LP را روی روتر متصل به ISP-A بالا ببرید.
- AS-Path Prepending: ابزار شما برای مدیریت ترافیک ورودی (Inbound Traffic) است. وقتی نام AS خود را در مسیر یکی از ISPها چند بار تکرار می‌کنید (Prepending)، به دنیای بیرون می‌گویید: «این مسیر طولانی‌تر است، از مسیر دیگر استفاده کنید!»
- MED (Multi-Exit Discriminator): اگر با یک ISP در دو نقطه مختلف (مثلاً تهران و تبریز) اتصال دارید، MED به آن ISP می‌گوید که از کدام نقطه وارد شبکه شما شود.
Asymmetric Routing چیست و چرا برای شبکه خطرناک است؟
یکی از بزرگ‌ترین کابوس‌های مهندس شبکه، ترافیکی است که از یک مسیر می‌رود اما از مسیر دیگری برمی‌گردد.
- چرا خطرساز است؟ اگر در شبکه از تجهیزات Stateful (مانند فایروال یا IPS) استفاده می‌کنید، این عدم تقارن باعث قطعی می‌شود. فایروال مقصد، پکت‌های بازگشتی را می‌بیند اما چون پکت‌های ارسالی را در جدول Session خود ندارد، آن‌ها را به عنوان حمله مشکوک بلاک می‌کند.
- نکته معمارانه: همیشه در طراحی لایه Routing، سعی کنید «مسیر رفت و برگشت» را همگام (Synchronize) کنید.
CoPP چگونه ترافیک شبکه را برای محافظت از CPU مدیریت می‌کند؟
ما تا اینجا درباره مسیریابی داده‌ها (Data Plane) صحبت کردیم؛ یعنی پکت‌هایی که با سرعت گیگابیت جابجا می‌شوند. اما لایه بسیار حساس‌تری به نام Control Plane وجود دارد که مغز روتر است و پروتکل‌های مسیریابی در آن اجرا می‌شوند.
اگر این مغز زیر بار ترافیک بیهوده یا حملات اشباع شود، کل شبکه از هم می‌پاشد. روتر دیگر نمی‌تواند پیام‌های Hello را ارسال کند، همسایه‌هایش (Neighbors) را از دست می‌دهد و کل جدول مسیریابی فرو می‌ریزد.
مفاهیم پیشرفته مسیریابی شبکه و جلوگیری از لوپ در Redistribution
نقش CoPP (Control Plane Policing) در حفاظت از CPU روتر
در محیط‌های High-End، ما از تکنیک CoPP استفاده می‌کنیم که یک فیلتر هوشمند در سطح CPU است:
- ترافیک BGP و SSH: با اولویت بسیار بالا و پهنای باند اختصاصی عبور داده می‌شود.
- ترافیک ICMP (پینگ): محدود می‌شود تا کسی نتواند با Ping زیاد CPU را درگیر کند.
- سایر ترافیک‌های غیرمدیریتی: به سمت IP خود روتر محدود یا Drop می‌شوند.
تجربه میدانی: بارها دیده‌ام که یک اشتباه در پیکربندی سوئیچ لایه Access، باعث ایجاد طوفان Broadcast و هجوم به CPU روترهای Core شده است. بدون CoPP، آن روترها در عرض چند ثانیه Unreachable می‌شوند.
چگونه مشکلات Routing و BGP را در شبکه عیب‌یابی کنیم؟
بزرگ‌ترین اشتباه یک مهندس شبکه این است که به اولین علامت خطا اعتماد کند.
مثلاً وقتی یک BGP Neighbor Down می‌شود، خیلی‌ها فوراً می‌گویند «BGP مشکل دارد». در حالی که ریشه‌ی مشکل ممکن است در Layer 1 باشد: یک ماژول SFP ناسازگار، CRC error، یا حتی یک مشکل ساده‌ی Duplex/Speed mismatch.
بررسی یک سناریوی واقعی Routing Loop در Redistribution بین OSPF و BGP
فرض کنید در یک دیتاسنتر، بین دو دامنه متفاوت، Redistribution بین OSPF و BGP انجام شده است. یک Route-Map ناقص باعث می‌شود مسیرهای دریافتی از OSPF دوباره از BGP به OSPF برگردند.
پیامدهای سناریو:
- ایجاد Route Duplication و Route Oscillation
- افزایش شدید مصرف CPU روترها
- ایجاد Blackhole یا Loop در برخی مسیرها
گام‌های حل مسئله:
- بررسی Route Tagging: کنترل کنید که آیا مسیرهای redistributed دارای Tag هستند یا خیر.
- بازبینی Policy از دو طرف: علاوه بر Input Policy، حتماً Return Path Policy را هم چک کنید.
- بررسی Seed Metric: از صحیح بودن مقدار متریک اولیه اطمینان حاصل کنید.
- مقایسه جدول Routing: جداول هر دو پروتکل را کنار هم تحلیل کنید.
- نگاه مبتنی بر PDU/Packet: تفکر خود را از دستورات صرف (show) به مسیر واقعی حرکت پکت تغییر دهید.
کاربرد Route Map در جلوگیری از Routing Loop بین OSPF و BGP
چک لیست مهم قبل و بعد از تغییرات مسیریابی شبکه
قبل از اعمال تغییرات مسیریابی:
- آیا مسیر رفت و برگشت ترافیک تحلیل شده است؟
- آیا اثر این تغییر روی Control Plane مشخص است؟
- آیا Policy مربوط به Redistribution تست شده است؟
- آیا رفتار شبکه در زمان قطع لینک (Failover Behavior) مشخص است؟
- آیا میزان MTU در کل مسیر (End-to-End) یکسان است؟
- آیا Route Tag و مکانیزم‌های Loop Prevention تعریف شده‌اند؟
- آیا برنامه بازگشت به تنظیمات قبلی (Rollback Plan) وجود دارد؟
بعد از اعمال تغییرات مسیریابی:
- آیا Adjacencyهای پروتکل‌ها پایدار مانده‌اند؟
- آیا میزان مصرف CPU روترها طبیعی است؟
- آیا نوسان مسیر (Route Oscillation) وجود دارد؟
- آیا تقارن ترافیک (Traffic Symmetry) حفظ شده است؟
- آیا Sessionهای Stateful روی فایروال‌ها سالم هستند؟
جمع‌بندی؛ تفاوت مهندس شبکه و معمار شبکه در مسیریابی
در نهایت باید گفت Routing هنرِ کنترلِ رفتارِ شبکه است، نه فقط پیدا کردنِ کوتاه‌ترین مسیر.
- دیدگاه مهندس معمولی: «Route در جدول هست، پس شبکه سالم است.»
- دیدگاه معمار شبکه: «Route هست، اما آیا این مسیر پایدار است؟ آیا برگشت آن درست است؟ آیا Control Plane در امنیت کامل قرار دارد؟»
