BGP Session Culling و انتزاع رخنه‌گر

زمانی که عنوان این مطلب را می‌نوشتم، برای خودم نیز خیلی سخت بود اما حس کردم این عنوان عجیب شاید بیشتر در ذهن بماند. امیدوارم در انتهای مطلب شاید کمی تعریف آن مشخص شود.

طرح مسئله

اگر دو روتر BGP مستقیما بطور فیزیکی متصل باشند و یا از مکانیزم‌های Fault-detection مانند BFD استفاده کنند، زمانی که یک peer از دسترس خارج شود، این قطعی بلافاصله به Control Plane اطلاع داده شده و همسایگی BGP قطع می‌شود و نهایتاً مسیرهایی که روتر همسایه مسئول آن‌ها بوده تغییر می‌کنند.

اما فرض کنید که BGP Speaker ها در یک بستر لایه 2 مانند یک IXP به یکدیگر متصل هستند و به دلایلی استفاده از مکانیزمی مانند BFD وجود ندارد.
در محیط‌ های IXP به تعدد پیش می‌آید که یکی از اعضا قصد تغییر تجهیز، بروزرسانی نرم‌افزار روتر خود، تغییر پورت یک peering و … را داشته باشد. در چنین شرایطی، همسایگان این روتر از این قطعی بلافاصله مطلع نمی‌شوند و در نتیجه بسته‌هایی که به سمت این روتر از طریق BGP مسیردهی می‌شدند، پس از سپری شدن Hold Timer (که معمولا زمانی بین 90 تا 180 ثانیه هست) از BGP Table حذف خواهند شد.
در واقع در این زمان ترافیک به اصطلاح blackhole شده است. در نظر داشته باشید که برخی IXP ها در دنیا سهم مهمی در وجود اینترنت دارند و blackhole شدن ترافیک ممکن است منجر به تأثیرات زیادی در دنیای اینترنت شود.

راه‌کار BGP Session Culling

پس از صحبت های فراوانی که در بین جماعت IXP ها و Service Provider ها وجود داشت، دیروز یک BCP Draft جهت پیشنهاد یکسری سیاست برای جلوگیری از این امر آماده شد که احتمالاً در IETF98 توسط اعضا گروه Global Routing Operations معروف به GROW بررسی خواهد شد.

بطور خلاصه، این Draft دو راهکار پیشنهاد می‌دهد که جهت عملیات نگهداری در محیطها و شرایط ذکر شده، قبل از ایجاد اختلال برای Data Plane، بدرستی Control Plane را در یک حالت کنترل شده متوقف کرد:

• مسئول روتری که قصد یک تغییر دارد، از قبل BGP Session را قطع کرده تا با ارسال Notification message به روترهای همسایه، روت های اشاره کننده به این روتر از BGP Table همسایگان حذف گردند و نهایتاً پس از چند دقیقه که ترافیک ورودی متوقف شد، اقدام به عملیات کند.
• مسئول بستر شبکه، مثلاً نگهدارنده‌ی زیرساخت IXP، از طرف عضوی که قصد تغییر دارد، روی پورت لایه 2 آن عضو، با استفاده از مکانیزم‌های موجود جلوی هرگونه ترافیک ورودی و خروجی به سمت TCP/179 را بگیرد.

تحلیل

روی این راه‌کار میتوان به چند نکته اشاره کرد (قبل از ادامه پیشنهاد میکنم ابتدا draft را مطالعه کنید):

• شخصاً فکر می‌کنم بسیار ایده‌ی خوبی است چرا که تأثیرات آن را به دستِ اول تجربه کرده‌ام؛ جالب اینجاست که در حال حاضر بسیاری از اپراتورها از همین راهکار استفاده می‌کنند، اما تابحال تبدیل یه یک مستند رسمی نشده بود.
• در قسمتی از Draft، همانطور که بنده نیز در ابتدای مطلب اشاره کردم، بیان شده که با استفاده از مکانیزم‌های Fault Detection، همسایه بلافاصله تغییر مسیر را انجام می‌دهد. متاسفانه هنوز تجهیزات فراوانی در دنیا استفاده می‌شوند که BFD یا مکانیزم‌های Fall-over را پشتیبانی نمی‌کنند، یا Control-plane آن‌ها بسیار کند عمل می‌کند، علی الخصوص زمانی که تجهیز به DFZ متصل باشد. لذا معتقدم این روش نه فقط در محیط‌ های Telecommunication و IXP ها، بلکه در تمام IP Network ها بایست استفاده شود.
• معمولاً قطع شدن کامل ترافیک ورودی شاید بین 3 تا 5 دقیقه طول بکشد، اما مواردی هم مشاهده شده که حدود 30 دقیقه پس از Down Notification کماکان ترافیک ادامه داشته است.

در این لینک یک ارائه‌ی مرتبط و تقریباً قدیمی از RIPE67 موجود می باشد که دیدن و مطالعه آن خالی از لطف نیست.

و اما انتزاع رخنه‌گر

جدا از بحث فنی راهکار پیشنهاد شده و کلاً بحث IXP ها و BGP، نکته‌ای که بنده قصد اشاره بدان را دارم، مفهومی در دنیای IT است که معروف به Leaky Abstraction (یا با ترجمه‌ای ثقیل “انتزاع رخنه‌گر”) می‌باشد. منظور از این امر در دنیای شبکه این است که هرگاه به بررسی یک طراحی یا یک ساختار یا تکنولوژی، یا پیاده‌سازی یک راه‌کار می‌پردازیم، فراموش نکنیم که عمل و تصمیم ما ممکن است در نقاطی که در ظاهر به چشم نمی‌آیند، تاثیرات منفی بگذارند. مثلاً در مسئله‌ی این BCP، یک تغییر در لایه 2، می‌تواند منجر به اختلال موضعی و موقت در دنیای اینترنت شود و لذا باید راهکاری برای جلوگیری و بهینه‌سازی این امر درنظر گرفته شود.

همخوان کنید

نویسنده: محمّد مقدّس

مسافر. عکاس تفریحی طبیعت. فرشته‌سرمایه‌گذار. هواخواه #رمزارز و Blockchain. ساکن اینترنت. معمار و مشاور شبکه/امنیت در AT&T. در حال ساختِ زیگ. دیدن همه‌ی نوشته‌های محمّد مقدّس