تغییر رفتار پیش‌فرض eBGP با RFC8212

پیرو Route Leakage‌های مختلفی که در دنیای اینترنت رخ داده‌است، و همینطور نیاز مبرم Service Providerها، از اواسط سال ۲۰۱۵، در IETF گروه GROW بحثی شروع شد مبنی بر طراحی یک رفتار پیش‌فرض BGP در رابطه با تبادل روت‌ها با همسایگان خارجی (eBGP).
همانطور که می‌دانید در RFCهای مرتبط با BGP، علی‌الخصوص RFC4271، تابحال توضیحی در رابطه با رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها زمانی که Policy خاصی اعمال نشده، ارائه نشده است، و این امر باعث شده که هر وِندوری رفتار سلیقه‌ای داشته باشد.

فارغ از جزئیات، بعنوان نمونه می‌توان به مدل‌های پیاده‌سازی زیر اشاره کرد:

  • بطور پیش‌فرض دو همسایه eBGP، زمانی که Policy خاصی روی ارتباطات eBGP تنظیم نشده باشد، روت‌های انتخاب‌شده در BGP Table خود را به یکدیگر ارسال می‌کنند و از یکدیگر قبول می‌کنند.
  • هیچ روتی ارسال نمی‌شود و هیچ روتی قبول نمی‌شود (discard) مگر اینکه Policy متناسبی تنظیم شده باشد.
  • برخی پیاده‌سازی‌ها هیچ روتی قبول نمی‌کنند و فقط روت‌های مربوط به AS خود را advertise می‌کنند.

مثلاً در حالت مثال اول، یکی از مخاطرات ممکن زمانی است که یک AS ناخواسته ترانزیت ارتباط بین ASهای دیگر می‌شود (در RFC7908 توضیح خوبی درباره‌ی Lateral ISP-ISP-ISP Leak همراه با دو بررسی دقیق در قسمت منابع، ارائه شده) ادامه خواندن “تغییر رفتار پیش‌فرض eBGP با RFC8212”

سفر به اعماق پروتکل های مسیریابی: EIGRP بخش اول

سلام به همراهان عزیز. بعد از شناختی که از سرزمین های هدفمون به دست آواردیم قصد داریم سفرمون رو شروع کنیم و پا به این سرزمین ها بذاریم. همونطور که در آخر قسمت قبل هم بیان کردم میخوایم به سراغ عضوی از سرزمین Distance Vector بریم که در حقیقت عضو این سرزمین بوده و هست ولی خیلیا اون رو دو رگه خطاب می کنن. شاید حدس زده باشید، بله منظورم پروتکل Cisco EIGRP هست 🙂 اما قبل از این که به سراغ این پروتکل بریم باید این رو عنوان کنم که از اینجا به بعد منبع ما برای بررسی پروتکل ها RFC هست. نه با زبان سخت و ثقیل RFC ها بلکه با زبان خودمون. اون چه که از این بعد قراره با هم بررسی کنیم پروتکلی که روی دستگاه یک وندور پیاده سازی شده نیست، بلکه هدف ما بررسی ذات حقیقی پروتکل های مسیریابی و آشنایی با نحوه ی عملکرد اصلی اون هاست. شاید خیلیا این کار و بیهوده و فقط مفید برای توسعه دهندگان پروتکل ها خطاب کنن اما خیلی وقتا مشکلات در پیاده سازی یک پروتکل مسیریابی از عدم درک درست عملکرد اون پروتکل نشات میگیره. بنابراین باز هم این رو تکرار میکنم که همیشه مشکلات سخت و پیچیده از جایی نشات می گیرن که ما ساده ترین مفاهیم رو فراموش کردیم 🙂 اما بیان بالاخره دل و به دریا بزنیم و وارد سرزمین Distance Vector بشیم.

معرفی پروتکل EIGRP:
ممکنه از خودتون بپرسید که چرا من شایسته ترین عضو سرزمین Distance Vector یعنی RIP رو برای شروع سفرم انتخاب نکردم. در جوابش باید بگم که هدفم بیشتر بررسی پروتکل هایی هست که در آینده ی نه چندان دور شاید تنها پروتکل های مسیریابی از نسلی باشن که من و شما می شناسیم (حتی ممکنه در آینده همین EIGRP هم دیگه جوابگو نباشه) اما اگر دوست داشتید که راجع به RIP هم صحبت کنیم و اون رو هم بیشتر بشناسیم خوشحال میشم حتما نظرتون رو در قسمت نظرات عنوان کنید 🙂

اما شاید باز از خودتون بپرسید که در اول این متن من بیان کردم که هدف ما بررسی پروتکل هایی فارغ از وندور هست ولی EIGRP که یک پروتکل برای شرکت سیسکو محسوب میشه و بنابراین نباید اینجا مطرح بشه. افرادی که کمی پیگیر جریان پروتکل ها هستن خوب می دونن که نهایتا در ماه مه سال ۲۰۱۶، RFC 7868 تحت عنوان ” Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP)” منتشر شد. به عقیده ی خیلیا این RFC معرفی کننده ی EIGRP اصیلی که روی دستگاه های شرکت سیسکو پیاده سازی شده نیست. اما قصد ما اینه که با رفتار این پروتکل متناسب با RFC آشنا بشیم اما اون بخشی از عملکرد این پروتکل که در RFC لحاظ نشده هم سعی می کنیم نهایتا با هم بررسی کنیم.

***

برای معرفی EIGRP باید به زمانی برگشت که توسعه دهندگان پروتکل IGRP که یک پروتکل اختصاصی شرکت سیسکو بود تصمیم بر توسعه ی این پروتکل گرفته و در صدد تبدیل آن به یک پروتکل Classless برآمدند. اما همزمان با تلاش برای بهبود قابلیت های عملکردی پروتکل IGRP، بر آن شدند تا از الگوریتم های آکادمیکی که در رابطه با بهبود زمان همگرایی بودند نیز در راستای این توسعه کمک گیرند. در نتیجه آن ها نه تنها به هدف خود یعنی ارتقای IGRP دست پیدا کردند بلکه سبب ایجاد پروتکل مسیریابی جدیدی شدند که با وجود برخی شباهت ها در رفتار به IGRP، یک پروتکل کاملا مجزا محسوب می شود.

اگر از قسمت اول این سری به خاطر داشته باشید، بیان شد که Distance Vector ها از الگوریتم مشهور Bellman-Ford برای پیدا کردن کوتاهترین مسیر استفاده می کنند، اما برخلاف آنها، EIGRP از یک سیستم محاسباتی جدید با نام Defusing Computation بهره می گیرد.
از سوی دیگر همانطور که در قسمت اول هم بیان گردید Distance Vector ها آپدیت های خود را به صورت دوره ای بعد از گذشت یک مدت زمان مشخص ارسال می کنند و نوع گزارش مسیرها نیز به صورت برداری از direction/distance می باشد. EIGRP هم از فرمول Direction/Distance برای گزارش مسیرها استفاده میکند اما آپدیت هایش دیگر به صورت دوره ای نیست بلکه دارای سه ویژگی است:

۱- غیر دوره ای (یا همان non-periodic)
۲- جزیی ( یا همان Partial)
۳- محدود (یا همان Bounded)

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: EIGRP بخش اول”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۳)

سلام به همه ی همراهان عزیز. در دو قسمت قبلی سعی کردیم تا در رابطه با این که در پروتکل های link state روترها چطور همسایه هاشون رو پیدا می کنن و با اونها ارتباط همسایگی تشکیل میدن و این که چطور خودشون رو به همسایه هاشون معرفی می کنن، توضیح بدیم. در این قست قصد داریم تا با هم بررسی کنیم، بعد از این که روتری معرفی نامه ی سایر روترها در ساختار رو دریافت کرد، اون ها رو کجا ذخیره می کنه و بعد چطور با استفاده از این اطلاعات جدول روت خودش رو می سازه.

Link State Database
بعد از این که روترها معرفی نامه ی خودشون رو در قالب Link State Information ها ارسال کردند، این اطلاعات در دیتابیسی به اسم Link State Database ذخیره میشه. هر Link State Information باید دارای اطلاعاتی باشه که به کمک اون ها روتر توانایی محاسبه ی کوتاهترین مسیر رو داشته باشه. حداقل این اطلاعات عبارتند از: شناسه ای از روتر تولید کننده ی Link State Information، شناسه ای از همسایه ی متصل به این روتر و Cost یا همون هزینه از روتر تولید کننده ی Link State Information تا همسایش.
خوب فرض کنید یک ساختار ساده مثل تصویر زیر داریم:

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۳)”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۲)

سلام به همه ی همراهان عزیز. اگر از مطلب قبل یادتون باشه، گفتیم که پیچیده ترین و مهم ترین بخش عملکرد Link State ها مربوط می شد به جریان Link State Information ها در ساختار. و گفتیم برای این که این جریان درست انجام بشه از فیلدهایی داخل فرمت Link State Information (اگر براتون سواله که چرا من از لفظ Link State Information استفاده می کنم، در قسمت قبل این موضوع رو توضیح دادم 🙂 ) استفاده می شد که یکی از اون ها Sequence Number بود. طراحی عملکرد این فیلد تاثیر زیادی بر نحوه ی فلودینگ Link State Information ها میذاشت. به همین دلیل مدل های مختلفی برای نحوه ی عملکرد این فیلد معرفی شد که عبارت بودند از : Linear , Circular و Lollipop. قصد داریم تا در این مطلب، با هم این مدل ها رو بررسی کنیم.

***

  • در نظر گرفتن فضای خطی برای Sequence Number:

در این مدل تصمیم بر آن شد که مقدار فیلد Sequence Number در یک بازه ی خطی متناهی از اعداد مثبت قرار داشته باشد. بنابراین اینطور در نظر گرفته شد که اگر Sequence Number، یک فیلد N بیتی باشد مثلا ۳۲ بیتی، حداکثر مقداری که می تواند در آن قرار گیرد: ۴,۲۹۳,۹۶۷,۲۹۶=۲۳۲ ‏‎ خواهد بود. ‏پس بازه ی خطی از ۰ شروع شده و تا ‏‎۴,۲۹۳,۹۶۷,۲۹۶ ادامه می یابد و شمارش Sequence Number هم از صفر شروع شده تا به حداکثر این بازه برسد.

Linear Sequence Number

در این روش اگر چند Link State Information یکسان با Sequence Number های مختلف دریافت می گردید، Link State Information با Sequence Number بزرگتر جدیدتر در نظر گرفته می شد. اما این مدل دو مشکل بزرگ داشت: اول این که در این مدل، بازه به صورت متناهی در نظر گرفته شده بود و  زمان طراحی این مدل فرض بر این بود که مقدار حداکثر بازه، آنقدر بزرگ است که روتر ‏به این مقدار حداکثر نمی رسد. اما این موضوع در نظر گرفته نشد که روتر یک دستگاه است و ممکن است دچار تداخل در عملکرد شده و همین امر باعث شود که مقدار Sequence Number به حداکثر مقدار تعیین شده برای آن برسد. در این صورت اتفاقی که رخ می داد آن بود که کل فرآیند از ‏کار می افتاد و آنقدر منتظر می ماند تا ‏Age‏ آنLink State Information ‎  در تمام ‏دیتابیس ها منقضی شده و حذف شود و حال فرآیند می توانست نمونه ی جدیدی از آنLink State Information ‎  با مقدار حداقل برای Sequence Number را تولید و ارسال نماید. ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۲)”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۱)

سلام به همه ی همراهان عزیز. اگر با موفقیت از سرزمین Distance Vector عبور کنیم، سرزمین بعدی که بهش خواهیم رسید ‏Link State‏ نام داره. زمانی که از  Link State Routing Protocol ها یاد میشه، اون ها رو ‏هوشمند ولی پر از رمز و راز و پیچیدگی معرفی می کنن. بهتره پیش از ورود به این سرزمین، ‏کمی با خصوصیات این روتینگ پروتکل ها آشنا بشیم!  🙂

***

تاریخچه ی مختصری از تکنولوژی مسیریابی ‏Link State
برخلاف Distance Vector ها که فقط مسیرها را تبلیغ می کنند و هیچ  دیدی از کل شبکه در اختیار قرار نمی دهند، در ‏link state‏ ها روتر، مسیر تبلیغ نمی کند بلکه اطلاعاتی راجع به لینک های متصل به خود، وضعیت این لینک ها و همسایه ‏هایی که به این لینک ها متصل می باشند را به همسایه های خود تبلیغ می کند. روترها تا زمانی که این اطلاعات را از ‏همسایه های خود دریافت نکنند مسیری را برای رسیدن به مقصدی انتخاب نمی کنند. پس می توان اینگونه بیان کرد که:

Link State Routing Protocol

اگر Distance Vector ‏ها حکم یک تابلو سر دو راهی را دارند، Link State ها در حکم یک نقشه ی کامل می باشند.

اما نحوه ی عملکرد ‏link state‏ ها به طور کلی به اینصورت است که:‏

  • تشکیل رابطه ی ‏adjacency‏ یا مجاورت با همسایه ها
  •  معرفی خود به همسایه ها
  • ساخت دیتابیسی از اطلاعاتی که از همسایه ها فراگرفته شده
  • ساخت جدول روت بر اساس اطلاعات دیتابیس تشکیل شده

    ‏تمام عملکرد ‏Link State‏ ها در این چهار خط خلاصه می شود. اما این فقط ظاهر امر می باشد، بیایید دقیق تر بررسی کنیم و ببینیم ‏پشت هر کدام از این موارد چه اتفاقی در حال رخ دادن است.‏

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۱)”