مسابقه ۱ – Static Routing

سلام.
تصمیم داریم هر از گاهی مسابقه‌ای برگزار کنیم و با طرح سوالات مفهومی (نه بر اساس سناریوی configuration یا تکنولوژی Vendor خاصی)، و به بهترین پاسخ‌ها جایزه‌ی ناقابلی تقدیم کنیم. سوالات هم مختلف خواهد بود، گاهی احتمالاً خیلی ساده اما پایه‌ای، گاهی هم ممکنه مربوط به مباحث پیشرفته و جدید، یا حتی از مطالب وبلاگ.
امیدواریم که با پیش‌بردن این وبلاگ و اینگونه موارد اندک قدمی در راستای تعالی شبکه‌ها! در کشور عزیزمان داشته باشیم.

این مسابقه به اتمام رسیده و پاسخ سوالات با توضیحات زیر هر سوال درج شده است.
جهت اطلاع از مسابقات آتی لطفاً عضو خبرنامه وبلاگ و کانال تلگرام شبکه‌ها! شوید.

و اما اولین مسابقه:

  1. آیا بهتر است روت Static به سمت next-hop نوشته شود و یا به سمت Interface؟ چرا؟
    عرف پیاده‌سازی Static Routing به سه صورت است:

    • استفاده از Interface خروجی: در این حالت، در پیاده‌سازی اغلب وندورها روتر فرض را بر Connected بودن مقصد گذاشته و  در جدول مسیریابی Route را با Administrative Distance صفر درج می‌کند که در Best Practice های امروز اتفاق جالبی نیست.
      مهم تر از همه، استفاده از پورت خروجی، باعث ARP lookup های متعدد شده و در لینک‌های Broadcast منجر به پخش شدن بیهوده‌ی ترافیک ARP می‌شود. فرض کنید برای یک subnet بزرگ مثل ۱۰٫۰٫۰٫۰/۸، که احتمالاً شامل host های متعددی خواهد بود، روتر برای هر host یک lookup کند، و یک entry در ARP Table اضافه کند؛ این امر نه تنها باعث استفاده غیربهینه از Memory شده، بلکه تاثیر بسازیی در افزایش CPU Utilization تجهیز خواهد داشت.
    • استفاده از next-hop: در این حالت نسبت به مورد قبل، صرفاً یک ARP Entry برای یک Subnet بزرگ ثبت می‌شود اما فرض کنیم که به دلیلی پورتی که next-hop توسط آن reachable بود down شود؛ در این حالت درصورت وجود یک route برای آن next-hop، روت از جدول مسیریابی حذف نمی‌شود چرا که روتر بصورت recursive عمل مسیریابی به مقصد اصلی را انجام می‌دهد (که معمولاً اینکار ناخواسته هست، چرا که در این شرایط احتمالاً استفاده از Dynamic Routing Protocol ها استفاده می‌شد).
      این امر حتی ممکن است برخلاف سیاست‌های امنیتی باشد چرا که مثلاً ممکن است در مسیر next-hop، یک IPS یا فایروال یا هر تجهیزی که در لایه‌ی Network Interface (لایه ۲ OSI) عملی روی packet انجام می‌داده bypass شود. همچنین در چنین شرایطی، روتر می‌بایست دائماً برای پیدا کردن next-hop جدول مسیریابی را بررسی کند که امری ناخواسته است. (نکته: فرض کنید در شبکه‌ای که بدرستی طراحی نشده، next-hop پس از down شدن interface، در Routing Table بصورت recursive با یک route دیگر match شود و packet به جایی فرستاده شود، که نباید!)
    • ترکیبی از هر دو مورد: در این حالت حتی اگر interface مرتبط با next-hop به هردلیلی down شود و next-hop توسط یک مسیر دیگر بصورت recursive قابل دسترسی باشد، Route از Routing Table حذف می‌شود و هیچکدام از معایب روش‌های قبل رخ نمی‌دهد. ضمناً این نوع تنظیم، در پیاده‌سازی اغلب وندورها همچون مورد قبل دارای Administrative Distance یک خواهد بود. این مورد نکته‌ی اصلی سوال و جواب مدنظر ما بود که کمتر به آن اشاره شد.
  2. فرض کنید در شبکه‌ی زیر، روی روتر R0 قصد دارید یک Static Route برای ۱۰٫۰٫۰٫۰/۸ تنظیم کنید. بهینه‌ترین حالت تنظیم این روت چگونه خواهد بود؟

مسابقه1 - Static Routingدر این سوال با توجه به ترسیم ساختار بصورت point-to-point، حتی با اینکه پورت xe یعنی ۱۰GigabitEthernet، اما استفاده از هر سه حالت از لحاظ عملکرد و بار روی تجهیز تفاوتی ایجاد نخواهد کرد (بجز یک ARP Entry درصورت استفاده از interface که در دنیای امروز قابل چشم‌پوشی است)؛ اما شاید از دیدگاه نگهداری و مدیریت configuration، استثنائاً در این حالت استفاده از Next-hop به تنهایی بهتر باشد؛ شاید در شرایطی Network Engineer مسئول این شبکه، مجبور شد پورت تجهیز را تعویض کند، و لذا با توجه به استفاده از Next-hop، نیازی به پاک کردن و تنظیم روت جدید نخواهد بود. البته هر سه پاسخ قابل قبول است.
برخی دوستان اشاره کرده بودند که استفاده از /۳۱ اشتباه است چرا که در این حالت Net ID و Broadcast Address درنظر گرفته نشده است. این تصور متاسفانه اشتباه هست. اینجا یک مطلب خوب در اینباره نوشته شده است. کلاً استفاده از /۳۱ در این شکل هیچ دلیل خاصی نداشت و صرفاً جهت آشنایی و شاید اضافه کردن نمک به سوال بود 🙂

لطفاً پاسخ خود به هردو سوال را بعنوان نظر درج کنید. نظرات بمدت ۴۸ ساعت از زمان انتشار مطلب منتشر نخواهند شد.
به اولین پاسخ کامل جایزه‌ی ناقابلی تعلق خواهد گرفت.

بروزرسانی ۳۰ آبان

فکر می‌کنم شروع خوبی داشتیم و استقبال مناسبی شد، برای همین اول از همه از ۳۴ عزیزی که در مسابقه شرکت کردند تشکر می‌کنیم.
برخی از پاسخ‌ها طولانی و حقیقتاً فاصله‌دار از جوابی بود که مدنظر ما بود. برخی از پاسخ‌ها نیز کلاً در رابطه با Static Routing و موارد دیگر توضیح داده اند اما به نکات اصلی سوال و یا جواب سوال دوم اشاره‌ای نشده بود.
پاسخ سوال همراه با توضیحات مناسب با رنگ سبز زیر هر سوال درج شده اند.

سه پاسخ نزدیک بهم و تقریباً درست دریافت کردیم، که باعث سخت شدن انتخاب بود، اما نهایتاً این پاسخ از آقای Mahmood Sebtonabi صحیح‌تر از دیگران بود و ایشون برنده‌ی اولین مسابقه‌ی شبکه‌ها هستن که با ایشون توسط ایمیل مکاتبه می‌کنیم.

بروزرسانی ۱۶ آذر

در تصویر زیر آقای محمود سبط النبی برنده این مسابقه رو در کنار یادگاریِ خیلی خیلی ناقابل مسابقه می‌بینین.

شبکه ها - برنده مسابقه اول

ضمناً برای مطلع شدن از مسابقات بعدی فراموش نکنین که عضو خبرنامه وبلاگ و کانال تلگرام شبکه‌ها! بشین 🙂

خواندنی: پروتکل‌های جدید باید IPv6 محور باشند

روز به روز تاکید بر مهاجرت به IPv6 داره بیشتر میشه؛ طبق آمار گوگل حدود ۱۴.۶ درصد ترافیک جستجوها تحت IPv6 هست.

گروه IAB هم IETF رو ملزوم کرده که در طراحی پروتکل های جدید وابستگی به IPv4 زیاد مدنظر نباشه و تمرکز بر طراحی حول محور IPv6 باشه.

IAB Statement on IPv6

IPv4 is OVER. Really. So quit relying on it in new protocols, sheesh

خلاصه ای کوتاه درباره‌ی حملات DDoS در چندین ماه اخیر

حتماً در جریان هستین که طی ماه های اخیر حملات DDoS نه تنها قوی تر و طولانی تر، بلکه هوشمندتر شدن. یکی از بدترین انواع اون تقریباً زمانی بود که زیرساخت DNS شرکت Dyn رو تحت تاثیر قرار داد.
البته عمده ی این قطعی ها صرفاً در شمال آمریکا حس میشد چون شرکت Dyn در اقصی نقاط دنیا DNS Server داره و خب جوری طراحی شده که مثلا کاربران آسیا از نزدیک ترین DNS Server جواب میگیرن (Anycast).

میدونیم که DNS مثه دفترچه تلفن اینترنت هست و با توجه به اینکه Dyn یکی از بزرگترین DNS Provider ها هست، خیلی از وبسایت های مهم دنیا هم طی این حملات از دسترس خارج شدن.
نکته ی خیلی بد درمورد این وبسایت ها این بود که فقط از یک DNS Provider استفاده می کردن که به نوعی SPoF محسوب میشه. البته عدم استفاده از چند DNS Provider هم دلایل خاص خودش رو داره که مهمترینش بنظرم سخت شدن نگهداری و مدیرت هست چون باید همیشه مطمئن باشید که هردو Provider رکوردهای یکسان دارند. و خب چه بسی با پیشرفته تر شدن حملات، همزمان چند DNS Provider تحت حمله قرار بگیرن.

نکته‌ی جالب در رابطه با این حمله استفاده از “چیزهای متصل به اینترنت” بود (Internet of Things). شخصاً همیشه از Internet of Things ترس داشتم و هیچوقت بهش مطمئن نبودم و اینبار خودش رو نشون داد. نمیدونم، اما امیدوارم یک روز این اتفاقات جنبه‌ی خطرات انسانی پیدا نکنه. فکر میکنم بهتره اگر خودمون از اینگونه اشیاء استفاده میکنم سعی کنیم از امنیتشون مطمئن بشیم و اگر در توسعه و تولید این اشیاء نقش داریم روی مباحث امنیتیشون بیشتر و دقیق تر کار کنیم.

یک موضوع مرتبط با این قضیه هم قراری هست تحت عنوان MANRS که مخفف Mutually Agreed Norms for Routing Security هست. هدف MANRS این هست که پروایدر در کنار هم روی یکسری مکانیزم های امنیتی در روتینگ تفاهم داشته باشن. پیشنهاد میکنم حتماً در اینباره مطالعه کنین.

خوش و بشی با داکر (Docker)

مبحثی که در موردش میخایم شروع به صحبت کنیم، در مورد Container ها و علی الخصوص داکر (Docker) هستش که به صورت کلی و مختصر به تعریف و توضیح کوتاهی در موردشون می پردازیم.

لازم به گفتن میدونم که بعضی از تعاریف برای سادگی به شکل دیگه ای بیان میشه و سعی میکنم زیاد ریز بینانه وارد نشم تا مبحث ویژگی فهم عمومی داشته باشه.

Container چیست؟

Docker Container - داکر

خب اول از همه بریم سراغ Container و ببینیم چی هست و کجا استفاده مون میشه.
به زبان خیلی ساده میشه گفت Container به گروهی از پروسس ها میگن که داخل یک فضای ایزوله شده‌ قرار گرفته‌اند (البته ما در docker سراغ این میریم که microprocess ها رو داشته باشیم و در هر کانینر یک پروسس اصلی رو اجرا کنیم). از نگاهی دیگه میشه گفتش که مدلی از مجازی سازی در لایه ی سیستم عامل هستش که هسته ی سیستم عامل این قابلیت رو به ما میده که تعدادی فضای ایزوله رو کاربر بتونه ایجاد کنه.

اینجا سؤال پیش میادش که فضای ایزوله ای که ازش اسم بردیم چی هستش؟ چه قابلیتی از سیستم عامل هستش که این ویژگی رو به ما داده؟

در سیستم عامل لینوکس، یکی از مزیت‌های هسته، Namespace هستش که منابع سیستمی رو برای ما به صورتی کاملاً مجزا جدا و شبیه سازی میکنن. مثلاً Process ID، دسترسی شبکه یا حتی فایل سیستم و یا ارتباطات داخلی پروسس ها.
پس اینطوری ما با استفاده از Namespace یک فضای ایزوله برای کارمون ایجاد کردیم.

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

داکِر (Docker)

Docker Logo - داکر

وقتش رسیده که بریم سراغ Docker و ببینیم نهنگ آبی و خندون داکر کی هستش و چی هست و رسالتش چیه.

هسته‌ی داکر که میتونیم بهش Docker Engine بگیم، یک نرم‌افزار متن باز هستش که روی سیستم عامل نصب میشه و به ما اجازه ی ساخت، پیاده‌سازی و مدیریت Container ها رو میده. این برنامه توسط تیم داکر و یا dotCloud نوشته شده و در اختیار من و شما قرار گرفته. Docker به ما این قابلیت رو میده که برنامه‌های خودمون رو به صورت اتوماتیک پیاده‌سازی کنیم و در قالب microprocess هر container رو دربیاریم و استفاده کنیم.

بزرگترین مزیتی که Docker بهمون ارایه میده این هستش که به سرعت میتونین کار development خودتون رو باهاش تست کنین، جلو ببرین و به حالت production برسونینش. ازین باحال تر این هستش که دیگه مثله نیازمندی های KVM، VMware و … به سیستم عجیب و غریبی نیاز نداریم؛ در واقع بسادگی میتونین روی سیستمی که دارین (که شاید RAM و CPU بالایی نداشته باشه)، داکِر رو نصب و ازش استفاده کنین.

موارد کاربردی داکر

در مورد مزیتی که اول گفتم (تسریع در Development) بگذارین یک مثال تجربیِ کوچیک بزنم:
امروز میخاستم یک اسکریپت کامپایل Nginx با OpenSSL ورژن ۱٫۰٫۲j و یک سری enable/disable کردن‌های دیگه درست کنم. روال کار برای من اینجوری بودش:

  1. نصب پیش نیاز ها
  2. دانلود nginx و openssl
  3. کامپایل openssl
  4. کامپایل nginx

اگه تا به حال کامپایل انجام داده باشین، متوجه میشین بعضی وقتا حوصله سَربَر میشه، مخصوصاً زمانی که بخواین پکیج رو کم و زیاد کنین یا موقغی که بلا به دور با نقص پیش نیاز مواجه بشین.

۲ تا حالت رو با هم بررسی میکنیم. یکی حالت معمولی و روی یک سیستم عامل معمولی که میخایم یک template تر و تمیز بسازیم. و حالت بعدی استفاده از docker که میخایم یک کانتینر ازش بسازیم. ادامه خواندن “خوش و بشی با داکر (Docker)”

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