تصویر: این کد رو فقط خدا میدونه!

این کد رو فقط خدا میدونه!

وقتی این کد رو زدم، فقط خودم و خدا میدونستیم که چیه و چیکار میکنه.

الان فقط خدا میدونه 🙂

روزمره: کسی packet هایی که مقصد رسوندین رو یادش نمی مونه

حتماً برای شما هم بارها و بارها پیش اومده که مشکلات اپلیکیشن یا سیستم های مختلف رو میندازن گردنِ شبکه. اصلاً انگار دیواری کوتاه تر از شبکه و شبکه کار ها نیست.
بحث سر این قضیه زیاد هست که هم برنامه نویس ها باید آشنائی با شبکه داشته باشن هم شبکه کارها با برنامه نویسی.

اغلب اینجور مشکلات از سه مورد بوجود میاد:

  • عدم آگاهی developer ها نسبت به شبکه
  • پیاده سازی اپلیکیشن های پیچیده یا نیازهای شبکه ای عجیب
  • پیچیدگی بیش از حد در شبکه که گاهی امکان پیداکردن مشکل و یا اثبات بی‌گناه بودنِ شبکه رو سخت میکنه.

به توئیت جالبی برخوردم که حیفم اومد به اشتراک نگذارم.

“هیجکس اون packet هایی که شما باعث به مقصد رسیدنشون بودین رو بیاد نمیاره”

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

Ray Ozzie گفته:

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

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

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

پیچیدگی شبکه

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

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

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

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

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

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

به هر حال، برای بررسی بهتر پیچیدگی در شبکه معمولا دو مدل ۳ و ۴ ضلعی پیشنهاد شده، که مدل ۳ ضلعی آن معمول‌تر می باشد: ادامه خواندن “پیچیدگی شبکه کشنده است!”

سفر به اعماق پروتکل های مسیریابی: 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 بخش اول”

روزمره: مسیریابی بین اینترانت ملی و اینترنت

سلام.
امروز یکی از دوستان سوال زیر رو پرسیدند:

همانطور که می دونید مخابرات سرویس اینترانت ملی میده و روش آی پی های invalid عمدتا از رنج ۱۰ هستن
حالا چرا و چگونه این آی پی ها از طریق اینترنت ping می شوند؟
چه نوع پیاده سازی و با چه روشی اینکار انجام می شود ؟

این اتفاق در ایران بعلت این هست که شبکه ی اینترانت ملی و بستر لایه ۳ ای که ترافیک اینترنت کشور روی اون جریان داره با هم ارتباط دارند. هیچ تکنولوژی خاصی نیست و صرفاً ارتباط روتینگ بین دو شبکه هست.
اگر اشتباه نکنم روی روترهای Core اصلی بستر اینترانت، Default Route به سمت بستر زیرساخت هست که اینترنت در اون جریان داره و نهایتاً یک IP اینترانتی و یک Valid IP در داخل کشور نسبت بهم reachable هستن.

اگر دوستان بحث یا سوال جالبی در گروه های موجود دیدند و علاقه داشتند که در رابطه با اون مطلب یا مقاله ای کوتاه در وبلاگ نوشته بشه، شدیداً استقبال میکنیم.
همچنین اگر فردی با سبکی که تابحال در وبلاگ مطلب نوشته شده (مفهومی و فارغ از بحث configuration یا فقط یک vendor خاص)، علاقه به همکاری دارند، بسیار خوشحال میشیم تا مارو در جریان بگذارند.