پیچیدگی شبکه کشنده است!

Ray Ozzie گفته:

پیچدگی کشنده است:

• چون زندگیِ Developer ها را مشقت بار می‌کند
• و برنامه‌ریزی، تولید و تست محصول را سخت!

صحبت بالا فقط برای دنیای نرم‌افزار نیست، بلکه به طراحی و پیاده‌سازی شبکه و الِمان‌های شبکه هم مربوط می‌شود. به زبان شبکه می‌توان گفت:
پیچیدگی شبکه کشنده است:
– چون زندگی Network Engineer ها را مشقت بار می‌کند.
– و طراحی، پیاده‌سازی، نگهداری و توسعه شبکه را سخت!

پیچیدگی شبکه چیست؟
یک شبکه‌ی پیچیده چگونه است؟

این سوال جواب دقیقی ندارد اما حاصل تحقیقات NCRG از موارد زیر نام می‌بَرد:

• خودمختاری: در یک شبکه، پروتکل‌ها و روال‌ها بدون کنترلی خارجی (انسانی) درحال فعالیت هستند؛ مثل یک پروسه‌ی روتینگ، یا مکانیزم‌های خودکار Failover. فعل و انفعالات بین این مکانیزم‌ها ممکن است منجر به یک رفتار و نتیجه‌ی پیچیده در شبکه شود.
• غیرقابل پیش‌بینی بودن: امکان بروز پیامدی وسیع حتی در اثر یک تغییر کوچک. مثلاً، در یک شبکه‌ی پیچیده، دست و دلِ Engineer در تغییرات می‌لرزد چون یک تغییر خیلی کوچک در یک روتر محلی، ممکن است منجر به لوپ، قطعی طولانی و خسارت‌های فراوان شود.
• شکنندگی: مشابه مورد قبل؛ یک تغییر یا ورودی خاص می‌تواند منجر به ریزش کل یا بخش عظیمی از سیستم شود.
• مشهود بودن: رفتار هر جزء شبکه، به نحوی متفاوت با چیزی است که شبکه بعنوان یک سیستم بزرگ عمل می‌کند. مثلاً تفاوت پروتکل مسیریابی در نقاط مختلف شبکه، و عدم consistency در سیاست‌های شبکه در نقاط مختلف با کاربرد مشابه مانند شعب کاملاً مشابه در یک شبکه‌ی بانکی
• غیر خطی بودن: به معنی اینکه خروجیِ یک ورودی/تغییر در شبکه، خطی نخواهد بود.

اینترنت را می‌شود شبکه‌ای پیچیده، اما بزرگ و تنومند دانست، از این لحاظ که، مثلاً اگر برای یک روتر Edge در یک ISP محلی (Tier 4) مشکلی پیش آید، احتمالاً هیچ اثری در کلیت اینترنت نخواهد داشت، اما ماهیت اینترنت در برابر حملات اینترنتی مثل DDoS های پیشرفته شکننده است. حتی در رابطه با شبکه‌ای به وسعت اینترنت، واقعیت این است که نمی‌توان همه‌ی نکات مثبت را بدون هیچ زیانی بدست آورد (سبک/سنگین کردن بین توسعه‌پذیری و ثبات (Stability) یا شکننده بودن)

چگونه پیچیدگی شبکه را بررسی کنیم؟

برای بررسی و اندازه‌گیری پیچیدگی، راهکارها و حتی فرمول‌های متعددی پیشنهاد شده، مثل NetComplex اما هیچ مدل و فرمولی نیست که قادر به ارائه‌ی یک Index صحیح از پیچیدگی شبکه باشد، چرا که عوامل متعددی درگیر این پیچیدگی هستند که قابل اندازه‌گیری نمی‌باشند، مثل عوامل انسانی. و از جنبه‌ی دیگر، خیلی از مواقع ریاضیات در درک واقعیات یک شبکه قاصر است چراکه مبناگذاری محاسبات بر اساس هدفِ کابردیِ یک شبکه، به احتمال زیاد شدنی نیست.

به هر حال، برای بررسی بهتر پیچیدگی در شبکه معمولا دو مدل 3 و 4 ضلعی پیشنهاد شده، که مدل 3 ضلعی آن معمول‌تر می باشد:

• Surface: بمعنی چگونگی ارتباط و تبادل اطلاعات بین تجهیزات متصل، و متکی‌ بودن آنها به یکدیگر؛ مثلا استفاده از پروتکل‌ Tunneling جهت پوشش یک Tunnel دیگر (Overlay) مثل یک GRE Tunnel روی بستر MPLS (بله، MPLS نوعی Tunneling محسوب می‌شود)، و یا ارتباط و وابستگی Control Plane و Data Plane روی یک روتر
• State: بمعنی حالت و میزان تغییر حالت ها در شبکه؛ هر پروتکلی که در شبکه و بین تجهیزات مختلف اجرا می‌شود، باعث افزایش حالت در Control Plane می‌گردد، بعنوان مثال OSPF و تغییر وضعیت همسایگی بین روترها
  در واقع می‌توان گفت State متشکل است از مجموع تمام اطلاعاتی که در شبکه توسط Control Plane جمع‌آوری می‌شود. حال هر ذره‌ای از اطلاعات که به CP اضافه شود، مثل یک روت /32، یک Policy مثل PBR، تونل، VRF و … هر کدام باعث افزایش State و نتیجتاً پیچیدگی می‌شود، که نهایتاً این پیچیدگی منجر به سخت‌تر شدن درک، ماینتورینگ و مدیریت شبکه می‌گردد.
  البته باید درنظر داشت بیشتر بودن این اطلاعات (State)، باعث بهینه‌تر بودن ارسال (روتینگ) packet ها در شبکه خواهد بود. با Aggregate یا Summary کردن، میزان این اطلاعات کم می‌شود اما ممکن است باعث عدم انتخاب مسیر بهینه شود. (سبک/سنگین کردن بین کوتاه‌ترین/بهترین مسیر ممکن یا مسیر قابل قبول – شکل زیر)
• Optimization: بمعنی بهینه‌گی، و استفاده‌ی متناسب از منابع شبکه و توسعه‌پذیری؛ مثلا اگر در حال بررسی استفاده از MPLS هستیم، یکی از مزیت های مختلفی که بدست خواهیم آورد، سادگی مهندسی ترافیک با استفاده از MPLS Label ها در Segment Routing هست.

در تصویر بالا، اگر روی R2 و R3 از Aggregation استفاده نکنیم و هردو روتر بدون تغییری در Metric ها، روت 192.168.1.0/24 را به R1 تبلیغ کنند، مسیری که با زرد هایلایت شده بهترین/کوتاه‌ترین مسیر خواهد بود (با فرض یکسان بودن شرایط و عدم وابستگی Aggregation Metric به روت 192.168.1.0/24).

درواقع با Aggregate کردن 192.168.0.0/16:

1. احتمالاً ترافیک از دو مسیر به سمت R6 هدایت می‌شود
2. Information Hiding اتفاق می‌افتد
3. جدول مسیریابی کوچکتر و در نتیجه State کمتر می‌شود

انتخاب اینکه State را زیاد کنیم تا Traffic Engineering دقیق‌تری داشته باشیم یا کم کنیم تا پیچیدگیِ کمتر، بستگی به شرایط دارد. برخی Complexity ها ممکن است لازم و مفید باشند. مهم تشخیص و تصمیم‌گیری صحیح متناسب با شرایط است.

نکته‌ی کنکوری: در تصویر بالا R2 و R3 مرز Failure Domain هستند. چرا؟ پاسخ با شما 🙂

می‌توان روی همین تصویر جزئیات زیادی اضافه کرد تا بحث گسترده‌تر شود، که از حوصله‌ی این مطلب خارج بوده و در آینده به آن پرداخته خواهد شد.

اِلمان‌های پیچیدگی شبکه

اگر بخواهیم اِلمان‌های پیچیدگی شبکه را به طور جزئی نام ببریم می‌توان به موارد زیر اشاره کرد:

• تجهیرات و اتصالات بین آن‌ها: مثلاً اضافه کردنِ یک لینک Redundant بین دو روتر Complexity را افزایش داده اما در عوض دسترسی‌پذیری بیشتری خواهیم داشت.
• الگوریتم‌ها: بجر موجودیت تجهیزات، الگوریتم‌ها نیز سهم بسزایی در تعیین رفتار یک شبکه دارند. مثل الگوریتم‌های استفاده‌شده در پروتکل‌های مسیریابی، رمزنگاری و …
• حالت در شبکه: چگونگی برخورد هر جزء شبکه با ترافیک، بر اساس State مشخص می‌شود؛ تعریف State را می‌توان در تنظیمات، وضعیت لایه 2 شبکه (OSI)، وضعیت پرونکل‌های مسیریابی، سیاست‌های امنیتی، و … جستجو کرد.
• میزان تغییرات: این پارامتر نمایانگر سرعت عکس‌العمل نسبت به رخدادهای ناخواسته در شبکه، مانند قطع شدن یک لینک می‌باشد. بعنوان مثال شرایطی را درنظر بگیرید که R1 برای مدتی خیلی کوتاه تحت CPU Utilization زیادی است و قادر به پاسخ‌گویی به چند Heartbeat (یا Hello packet یا هر بسته‌ای که تجهیزات جهت اطلاع از وضعیت یکدگیر تبادل می‌کنند) می‌باشد؛ در این شرایط R2 (روتر همسایه) سریعاً وضعیت R1 را به Down تغییر داده و احتمالاً مسیر را تغییر می‌دهد؛ بعد از گذشت چند لحظه، R1 مجدداً شروع به پاسخ می‌کند و R2 وضعیت R1 را Up می‌کند. در این سناریو انتخاب بین ثبات (Stability) و سرعت عکس‌العمل مدنظر است. لذا سنجش میزان تغییرات و علت آنها بسیار حائز اهمیت است.
• دانش راهبری: همانطور که از روند مقاله پیداست، پیچیدگی ارتباط مستقیمی با عوامل انسانی و دانش راهبری آنها دارد. مثلاً، هر چه یک پروتکل مسیریابی پارامترهای بیشتری داشته باشد، معمولاً طراحی، پیاده‌سازی، نگهداری و رفع اشکال آن پیچیده‌تر است. در این مورد، سبک/سنگین کردن، بین راهبری بهتر و ساده‌تر، و بدست آوردن مزایا، مدنظر است.

چه کنیم؟ چه نکنیم؟

در RFC1925، معروف به 12 حقیقت شبکه، مضمون قانون آخر این است که:
وقتی دیگر ویژگی‌ای برای اضافه کردن باقی نمانده، به این معنی نیست که طراحی [پروتکل] به کمال رسیده؛ بلکه زمانی که دیگر چیزی برای کم‌کردن نیست به نقطه‌ی کامل‌بودن نزدیک شده است.

خیلی اوقات، با در نظر گرفتن zone های بسیار زیاد، یا استفاده از پروتکل‌های encapsulation متعدد،  و یا زیاده‌روی Redistribution و Filtering و…، به مرحله‌ای می‌رسیم که دیگر چیزی مشخص نیست و ساعت 3 صبح با زنگ خوردن تلفن پشتیبانی، مشخص نیست Troubleshooting از کجا بایست شروع شود!

دقت کنیم منظور از پیچیدگی، سخت بودن پروتکل/تکنولوژی یا پیچیدگی پیاده‌سازی نیست؛ منظور پیچیده‌کردن توسعه و نگهداری است، پیچیده کردنِ درک این موضوع که در شبکه چه میگذرد، پیچیده کردن درک Traffic Flow ها و …
و دقت کنیم، نه برای شخص ثالثی که بیرون از شبکه ما است؛ نه، اصلا قرار نیست این افراد از وضعیت شبکه‌ی ما اطلاعی داشته باشند تا از آن سوءاستفاده کنند؛ منظور خودمان هستیم که نگهداری شبکه را بعهده داریم، منظور مشاور سازمان است، منظور همکار جدید تیم NOC است. (اگر مخالف این هستید که همکاران، یا مشاور سازمان متوجه کارِ شما شوند، پیشنهاد میکنم بحثی که اینجا شده را مطالعه کنید و نظر خود را را به اشتراک بگذارید)

معتقدم باید به این نقطه برسیم که وقتی درخواست اضافه‌کردن یک پیچیدگی می‌شود، بتوانیم بخوبی مخالفت کنیم:

میتونم این کار عجیب‌قریب رو انجام بدم، اتفاقاً مجانی بدون هیچ هزینه‌ای؛ اما چندوقت دیگه، موقع قطعی‌ها و پیچیدگی راهبری باید هزینه‌های زیاد بپردازین!

اگر هزینه‌ای که شرکتِ ما/سازمانِ ما/مشتریِ ما/مملکتِ ما متحمل میشه، اگر وقت گرانبهای خودمون برامون ارزشمند هست، سعی کنیم از پیچیدگی‌های بی‌مورد فاصله بگیریم.

معروف است که:

خوب، سریع، ارزان. فقط دوتارو انتخاب کن!

برای همین باید سبک-سنگین کرد و دید چه چیزی بهتره.

در ایران دوستی می‌گفت بین دو روتر دو لینک یکسان دارند، اما به دلایلی میخوان بصورت Active/Standby استفاده کنن. پروتکل مسیریابی رو EIGRP انتخاب کردند و با استفاده از تنظیم پارامتر maximum-path 1 به هدفشون رسیدن 🙂

راهکار این دوستمون من رو یاد امتحانات CCIE میندازه؛ این امتحانات و مدارک خیلی ارزشمند هستن و حقیقتاً اینکه کسی ازخودگذشتگی و پشتکاری میذاره که به این هدف برسه واقعاً خیلی قشنگ و خوبه. اما یکی از انتقاداتی که من همیشه به این امتحانا دارم اینه که بعلت نحوه ی سناریوها و trick هایی که در امتحان هست، بطور ناخوداگاه شخص رو به سمت راهکارهای پیچیده هدایت می‌کنه.

پیشنهاد می‌کنم این مقاله قدیمی از آقای Dijikstra رو بخونین.
ممکنه خوندن یک مطلب قدیمی رو دوست نداشته باشین، اما RFC7980 که اخیراً بصورت Informational منتشر شده چطور؟

عضویت در کانال تلگرام شبکه‌ها و خبرنامه وبلاگ رو فراموش نکنین 🙂