طوفان برادکست یا Broadcast Storm

گاهی وقتا این فریاد زدن‌ها یا همون ارسال پیام‌های برادکست لازمه. مثلا وقتی یک کامپیوتر جدید به شبکه وصل میشه، یه جورایی داد میزنه و میگه: «سلام به همگی، من اینجام، کسی می‌تونه به من یک آدرس بده؟». این یک استفاده خوب و مفید از برادکسته. اما حالا تصور کنید که یک نفر بلندگو رو برداره و شروع کنه به فریاد زدن یک کلمه، و بعد بقیه هم همون کلمه رو تکرار کنن و دوباره فریاد بزنن. چند ثانیه بعد، کل سالن پر میشه از همهمه و فریادهای تکراری و دیگه هیچ‌کس صدای هیچ‌کس دیگه‌ای رو نمی‌شنوه. مکالمه‌های عادی و دونفره کاملا غیرممکن میشه.

این دقیقا همون بلاییه که طوفان برادکست سر یک شبکه کامپیوتری میاره. بهش «تشعشع برادکست» (Broadcast Radiation) هم میگن. این اتفاق زمانی میفته که حجم پیام‌های برادکست و یه نوع دیگه از پیام به اسم مالتی‌کست (Multicast) – که مثل صدا زدن یک گروه خاص از آدم‌ها توی اون سالنه – اون‌قدر زیاد میشه که شبکه رو به مرز فلج شدن می‌رسونه. این طوفان منابع شبکه، مثل پهنای باند و قدرت پردازش دستگاه‌ها، رو جوری مصرف می‌کنه که دیگه جایی برای ترافیک عادی و روزمره باقی نمی‌مونه. در نتیجه، شبکه شما عملا از کار میفته و دیگه نمی‌تونه داده‌های معمولی رو جابجا کنه.

جالبه بدونید که بعضی وقتا به اون بسته‌ یا پکت اولیه‌ای که باعث شروع این جهنم میشه، یک لقب خاص دادن: «پکت چرنوبیل» (Chernobyl packet). این اسم‌گذاری به خاطر فاجعه اتمی چرنوبیل انجام شده، چون این پکت هم مثل اون اتفاق، یک واکنش زنجیره‌ای فاجعه‌بار رو توی شبکه شروع می‌کنه که کنترل کردنش خیلی سخته.

فصل دوم: مقصر اصلی کیه؟ رایج‌ترین دلیل طوفان

خب، حالا که فهمیدیم طوفان برادکست چیه، سوال اصلی اینه که چی باعثش میشه؟ در بیشتر موارد، مقصر اصلی یک اشتباه ساده در ساختار فیزیکی شبکه است که بهش میگن «لوپ سوییچینگ» (Switching Loop).

سوییچ چیه و لوپ چطور به وجود میاد؟

برای اینکه بفهمیم لوپ چیه، اول باید بدونیم سوییچ (Switch) چیه. سوییچ‌ها دستگاه‌های جعبه‌مانندی هستن که توی هر اداره، مدرسه یا شرکتی پیدا میشن و کلی پورت شبکه دارن. وظیفه اصلی سوییچ اینه که کامپیوترها، پرینترها و بقیه دستگاه‌های توی یک شبکه محلی (LAN) رو به هم وصل کنه. وقتی کامپیوتر شما می‌خواد یک فایل برای پرینتر بفرسته، اون فایل اول میره به سوییچ. سوییچ مثل یک مامور پست هوشمنده. نگاه می‌کنه ببینه مقصد این بسته کجاست و اون رو فقط و فقط به پورت پرینتر می‌فرسته، نه به بقیه کامپیوترها.

اما داستان برای پیام‌های برادکست فرق می‌کنه. وقتی یک سوییچ یک پیام برادکست دریافت می‌کنه، وظیفه‌اش اینه که اون پیام رو از «تمام پورت‌هاش» به جز پورتی که پیام ازش اومده، بفرسته بیرون. اینجاست که مشکل شروع میشه.

یک لوپ سوییچینگ یعنی ما بین دو تا دستگاه توی شبکه، بیش از یک مسیر ارتباطی ایجاد کنیم. ساده‌ترین مثالش اینه: یک کابل شبکه بردارید و دو سرش رو به دو تا پورت مختلف روی «همون یک سوییچ» وصل کنید. شاید به نظرتون احمقانه بیاد، ولی این اتفاق خیلی بیشتر از چیزی که فکر می‌کنید میفته، مخصوصا توی شبکه‌های بزرگ که کلی کابل اینور و اونور ریخته.

حالا ببینیم با وصل کردن این کابل چه اتفاقی میفته:

1. یک کامپیوتر یک پیام برادکست (مثلا همون پیام «سلام به همگی») رو به سوییچ می‌فرسته.
2. سوییچ طبق وظیفه‌اش، این پیام رو از تمام پورت‌هاش کپی و ارسال می‌کنه. دو تا از این پورت‌ها، همون پورت‌هایی هستن که شما با یک کابل به هم وصلشون کردید.
3. پس پیام برادکست از پورت شماره ۱ خارج میشه، وارد کابل لوپ میشه و از طریق همون کابل، دوباره به پورت شماره ۲ «وارد» سوییچ میشه.
4. حالا سوییچ فکر می‌کنه یک پیام برادکست جدید از پورت شماره ۲ گرفته! پس دوباره طبق وظیفه‌اش، اون رو از تمام پورت‌های دیگه‌اش، از جمله پورت شماره ۱، می‌فرسته بیرون.
5. این پیام دوباره وارد کابل لوپ میشه و برمی‌گرده به پورت شماره ۲.
6. این چرخه تا ابد ادامه پیدا می‌کنه. هر بار که این پیام توی این حلقه می‌چرخه، یک کپی جدید ازش ساخته و در کل شبکه پخش میشه.

ظرف چند میلی‌ثانیه، شبکه شما با میلیون‌ها کپی از یک پیام برادکست یکسان پر میشه. این همون طوفان برادکسته.

چرا این بسته‌ها برای همیشه می‌چرخن؟

شاید بپرسید مگه بسته‌های شبکه یک تاریخ انقضا ندارن که بعد از مدتی از بین برن؟ سوال خیلی خوبیه. بسته‌هایی که بین شبکه‌های مختلف (مثلا در اینترنت) جابجا میشن و روترها اونها رو مدیریت می‌کنن، یک چیزی به اسم (Time to Live (TTL دارن. این TTL یک عدده که با عبور از هر روتر، یکی ازش کم میشه. وقتی این عدد به صفر برسه، اون بسته از بین میره تا برای همیشه در اینترنت سرگردان نمونه.

اما مشکل اینجاست که ما اینجا داریم در مورد لایه ۲ (Layer 2) شبکه صحبت می‌کنیم، یعنی ارتباطات داخل یک شبکه محلی که توسط سوییچ‌ها مدیریت میشه. فریم‌های اترنت (Ethernet frames) که در این لایه کار می‌کنن، توی هدر یا سربرگشون چیزی به اسم TTL ندارن. در نتیجه، وقتی یک فریم توی یک توپولوژی حلقه‌ای یا لوپ‌دار گیر میفته، هیچ مکانیسمی برای از بین بردنش وجود نداره و می‌تونه تا ابد به چرخیدن ادامه بده. این دقیقا مثل یک قطار روی یک ریل دایره‌ای شکله که هیچ‌وقت متوقف نمیشه.

فصل سوم: وقتی طوفان عمدی به پا میشه! (حملات DoS)

تا اینجا در مورد طوفان‌هایی صحبت کردیم که معمولا به خاطر یک اشتباه انسانی یا یک مشکل سخت‌افزاری به وجود میان. اما گاهی وقتا، یک نفر عمدا یک طوفان برادکست راه میندازه تا یک شبکه رو از کار بندازه. به این نوع حملات میگن حملات «منع سرویس» یا (Denial of Service – DoS). هدف این حملات اینه که یک سرویس یا یک شبکه رو اون‌قدر مشغول کنن که دیگه نتونه به کاربران واقعی سرویس بده.

دو تا از معروف‌ترین حملاتی که از این تکنیک استفاده می‌کنن، حمله اسمرف (Smurf Attack) و حمله فراگل (Fraggle Attack) هستن. این حملات از یک تکنیک هوشمندانه به اسم «تقویت بسته» (packet amplification) استفاده می‌کنن. بیاید ببینیم چطوری کار می‌کنه:

1. انتخاب قربانی: اول از همه، مهاجم یک قربانی رو انتخاب می‌کنه. این قربانی می‌تونه یک سرور، یک وب‌سایت یا حتی یک کامپیوتر شخصی باشه.
2. جعل آدرس منبع: مهاجم شروع به ارسال یک عالمه بسته به یک شبکه بزرگ می‌کنه. اما یک حقه کثیف میزنه: آدرس «فرستنده» یا منبع (source address) این بسته‌ها رو به جای آدرس خودش، آدرس کامپیوتر «قربانی» جا میزنه. به این کار میگن (Spoofing).
3. ارسال به آدرس برادکست: مهاجم این بسته‌های جعلی رو به جای اینکه به یک کامپیوتر خاص بفرسته، به آدرس برادکست (broadcast address) اون شبکه می‌فرسته. این آدرس مثل یک آدرس پستی عمومیه که وقتی نامه‌ای بهش فرستاده بشه، به تمام خانه‌های اون محله تحویل داده میشه.
4. شروع طوفان: حالا چی میشه؟ وقتی این بسته‌ها به شبکه مقصد می‌رسن، «تمام» کامپیوترهای اون شبکه فکر می‌کنن که یک نفر (که به اشتباه فکر می‌کنن همون قربانیه) ازشون یک درخواستی داشته. پس همگی با هم شروع می‌کنن به جواب دادن به اون درخواست. اما این جواب‌ها رو برای کی می‌فرستن؟ برای آدرس منبعی که توی بسته‌ها دیده بودن، یعنی آدرس کامپیوتر «قربانی».

فرض کنید توی اون شبکه ۱۰۰ تا کامپیوتر وجود داشته باشه. مهاجم فقط «یک» بسته می‌فرسته، اما در جواب، «صد تا» بسته به سمت قربانی سرازیر میشه. به همین خاطر بهش میگن حمله تقویتی. مهاجم با ارسال حجم زیادی از این درخواست‌ها، یک طوفان عظیم از جواب‌ها رو به سمت قربانی هدایت می‌کنه.

مکانیزم دقیق‌تر حمله اسمرف

در حمله اسمرف، بسته‌ای که مهاجم می‌فرسته از نوع ICMP Echo Request هست. این همون درخواستیه که وقتی شما از دستور ping استفاده می‌کنید، فرستاده میشه. مثل اینه که شما داد بزنید «هی، اونجایی؟» و منتظر جواب «آره، اینجام» باشید. مهاجم یک عالمه درخواست پینگ با آدرس جعلی قربانی به آدرس برادکست یک شبکه می‌فرسته. در نتیجه، تمام کامپیوترهای اون شبکه شروع می‌کنن به پینگ کردن قربانی. این سیل عظیم ترافیک باعث میشه:

• پهنای باند شبکه قربانی کاملا پر بشه.
• پردازنده یا CPU کامپیوتر قربانی درگیر پردازش این همه جواب بشه.
• و در نهایت، ممکنه سیستم قربانی کاملا از کار بیفته یا به اصطلاح کرش کنه.

حمله فراگل هم دقیقا همین ساختار رو داره، با این تفاوت که به جای بسته‌های ICMP، از بسته‌های UDP استفاده می‌کنه.

طوفان در دنیای بی‌سیم (Wi-Fi)

این حملات فقط مخصوص شبکه‌های سیمی نیستن. توی شبکه‌های وایرلس هم میشه یک نوع حمله DoS بر پایه برادکست راه انداخت. یکی از این حملات، حمله برادکست قطع اتصال (Disassociation Broadcast Attack) نام داره.

مکانیزمش اینطوریه:
توی یک شبکه وای‌فای، دستگاهی که اینترنت رو پخش می‌کنه اکسس پوینت (Access Point) نام داره. وقتی یک کامپیوتر یا موبایل می‌خواد از شبکه جدا بشه، یک بسته به اسم «بسته قطع اتصال» (disassociation packet) برای اکسس پوینت می‌فرسته.
حالا مهاجم می‌تونه یک بسته قطع اتصال بسازه، آدرس فرستنده‌اش رو جعل کنه و آدرس اکسس پوینت رو به جاش بذاره. بعد این بسته جعلی رو به آدرس برادکست شبکه وای‌فای می‌فرسته.
نتیجه چی میشه؟ تمام دستگاه‌هایی که به اون وای‌فای وصل هستن، این پیام رو دریافت می‌کنن و فکر می‌کنن که خود اکسس پوینت بهشون دستور داده که اتصالشون رو قطع کنن. در نتیجه، همه کامپیوترها و موبایل‌ها یک‌دفعه از وای‌فای قطع میشن. این کار باعث یک هرج و مرج بزرگ در شبکه بی‌سیم میشه.

فصل چهارم: چطور جلوی طوفان رو بگیریم؟ (راهکارهای پیشگیری و کنترل)

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

۱. مقابله با لوپ‌های سوییچینگ

همونطور که گفتیم، لوپ‌ها مقصر اصلی طوفان‌های اتفاقی هستن. برای مقابله با اونها، پروتکل‌ها و تکنولوژی‌های هوشمندی طراحی شدن:

• پروتکل درخت پوشا (Spanning Tree Protocol – STP): این پروتکل یک جورایی پلیس راهنمایی و رانندگی شبکه‌های لایه ۲ هست. وقتی STP روی سوییچ‌ها فعال باشه، سوییچ‌ها با هم حرف می‌زنن و یک نقشه کامل از شبکه تهیه می‌کنن. اگه ببینن که بین دو نقطه، چند تا مسیر مختلف وجود داره (یعنی لوپ)، هوشمندانه یکی از مسیرها رو به صورت موقت «مسدود» یا بلاک می‌کنن. این کار باعث میشه که همیشه فقط یک مسیر فعال برای رسیدن به هر مقصدی وجود داشته باشه و جلوی به وجود اومدن حلقه گرفته بشه. البته همونطور که جلوتر در یک داستان واقعی خواهیم دید، بعضی از مدیران شبکه به خاطر پیچیدگی‌ها یا مشکلاتی که در گذشته باهاش داشتن، از فعال کردنش خودداری می‌کنن.
• تکنولوژی‌های جدیدتر: به جز STP، راهکارهای مدرن‌تری هم وجود داره. مثلا agregación de enlaces (Link Aggregation) به شما اجازه میده چند تا کابل فیزیکی رو با هم ترکیب کنید تا به عنوان یک لینک منطقی و پرسرعت‌تر کار کنن که این کار هم به مدیریت بهتر مسیرها کمک می‌کنه. پروتکل Shortest Path Bridging هم یک جایگزین پیشرفته برای STP هست که مسیرها رو بهینه‌تر انتخاب می‌کنه.
• حفاظت در شبکه‌های خاص (Metro Ethernet): در شبکه‌های بزرگ شهری که به صورت حلقه‌ای (Ring) طراحی میشن، از پروتکل‌های خاصی مثل Ethernet Ring Protection Switching (ERPS) یا Ethernet Automatic Protection System (EAPS) استفاده میشه که مخصوص جلوگیری از لوپ در این نوع معماری‌ها هستن.

۲. استفاده از تجهیزات لایه ۳ (روترها)

یک راه حل اساسی برای محدود کردن دامنه طوفان، استفاده از روترها (Routers) هست. یادتونه گفتیم سوییچ‌ها در لایه ۲ کار می‌کنن و روترها در لایه ۳؟ یک تفاوت کلیدی بین این دو اینه که روترها به طور پیش‌فرض پیام‌های برادکست رو از خودشون عبور نمیدن.

یک سوییچ وقتی پیام برادکست می‌گیره، اون رو برای همه پورت‌هاش می‌فرسته. اما یک روتر وقتی یک پیام برادکست از یک شبکه (مثلا شبکه داخلی شرکت شما) دریافت می‌کنه، اون رو به شبکه دیگه (مثلا اینترنت) ارسال نمی‌کنه. هر شبکه‌ای که به یک پورت روتر وصل میشه، یک «دامنه برادکست» (Broadcast Domain) جداگانه محسوب میشه. طوفان برادکست فقط می‌تونه توی همون دامنه‌ای که به وجود اومده پخش بشه و نمی‌تونه از روتر عبور کنه و به شبکه‌های دیگه سرایت کنه.
پس با تقسیم کردن یک شبکه بزرگ به چند تا شبکه کوچیک‌تر و وصل کردن اونها به هم از طریق روتر، می‌تونیم تاثیر یک طوفان رو خیلی محدود کنیم. بعضی از سوییچ‌های پیشرفته هم هستن که می‌تونن کارهای شبیه روتر انجام بدن و بهشون (Brouter) میگن.

۳. تقسیم‌بندی منطقی شبکه با VLAN

شاید خریدن کلی روتر برای تقسیم کردن شبکه خیلی پرهزینه باشه. یک راه حل منطقی و ارزان‌تر، استفاده از VLAN یا (Virtual LAN) هست. VLAN به شما اجازه میده که یک سوییچ فیزیکی بزرگ رو به چند تا سوییچ مجازی و کوچیک‌تر تقسیم کنید.

فرض کنید یک سوییچ ۴۸ پورت دارید. می‌تونید پورت‌های ۱ تا ۱۲ رو عضو VLAN شماره ۱۰ (مثلا مخصوص بخش مالی) کنید، پورت‌های ۱۳ تا ۲۴ رو عضو VLAN شماره ۲۰ (مخصوص بخش فروش) و به همین ترتیب. با اینکه همه این پورت‌ها روی یک دستگاه فیزیکی هستن، اما کامپیوترهای بخش مالی فقط می‌تونن با هم حرف بزنن و کامپیوترهای بخش فروش هم فقط با هم. این دو گروه کاملا از هم ایزوله هستن، انگار که به دو تا سوییچ جدا وصل شدن.
مهم‌ترین نکته اینه که هر VLAN یک دامنه برادکست جداگانه برای خودش ایجاد می‌کنه. پس اگه توی VLAN بخش مالی یک طوفان برادکست به وجود بیاد، این طوفان فقط و فقط همون ۱۲ تا پورت رو درگیر می‌کنه و به VLAN بخش فروش یا بقیه قسمت‌های شبکه سرایت نمی‌کنه. این کار مثل اینه که به جای یک سالن بزرگ، چند تا اتاق کوچیک و ضدصدا درست کنیم. همهمه توی یک اتاق، مزاحم بقیه اتاق‌ها نمیشه.

۴. کنترل طوفان روی خود سوییچ‌ها

خیلی از سوییچ‌های مدیریتی (Managed Switches) یک قابلیت خیلی به درد بخور به اسم «کنترل طوفان برادکست» (Broadcast Storm Control) دارن. این قابلیت مثل یک فیوز یا قطع‌کننده مدار عمل می‌کنه.

شما می‌تونید برای سوییچ یک آستانه یا (Threshold) تعریف کنید. مثلا بهش بگید: «اگه دیدی بیشتر از ۲۰ درصد از پهنای باند یک پورت رو ترافیک برادکست اشغال کرده، حتما یه کاسه‌ای زیر نیم‌کاسه است». وقتی سوییچ این وضعیت رو تشخیص بده، به طور موقت ارسال تمام ترافیک برادکست از اون پورت رو متوقف می‌کنه یا به شدت محدودش می‌کنه.

این کار مشکل اصلی (مثلا اون کابل لوپ) رو حل نمی‌کنه، اما شدت طوفان رو کنترل می‌کنه. این به مدیر شبکه فرصت میده که نفس راحتی بکشه، به تجهیزات شبکه وصل بشه (چون شبکه کاملا از کار نیفتاده) و با آرامش دنبال منبع اصلی مشکل بگرده و اون رو برطرف کنه.

۵. پیکربندی روترها و فایروال‌ها برای حملات عمدی

برای مقابله با حملات DoS مثل اسمرف، میشه روترها و فایروال‌ها رو جوری تنظیم کرد که این نوع ترافیک‌های مخرب رو تشخیص بدن و جلوشون رو بگیرن. مثلا میشه به روتر دستور داد که بسته‌هایی که از بیرون شبکه میان ولی آدرس فرستنده‌شون یکی از آدرس‌های داخل شبکه است رو دور بریزه، چون این بسته‌ها به احتمال زیاد جعلی یا (Spoofed) هستن.

۶. یک مورد خاص: شبکه‌های موبایلی Ad Hoc

در شبکه‌های خاصی مثل MANET یا (Mobile Ad Hoc Network) که دستگاه‌ها (مثلا موبایل‌ها) بدون نیاز به اکسس پوینت مستقیما به هم وصل میشن، پیدا کردن مسیر برای ارسال داده یک چالش بزرگه. برای این کار، دستگاه‌ها بسته‌هایی به اسم RREQ یا (Route Request) رو به صورت برادکست ارسال می‌کنن تا بهترین مسیر به مقصد رو پیدا کنن. این بسته‌ها هم می‌تونن باعث طوفان برادکست بشن و با بسته‌های داده واقعی برای استفاده از کانال ارتباطی رقابت کنن. یک راه حل برای این مشکل اینه که الگوریتم‌هایی طراحی بشه که جلوی بازپخش (rebroadcasting) بی‌مورد این بسته‌ها رو توسط همه دستگاه‌ها بگیره تا از افزونگی و تصادم کم بشه.

فصل پنجم: داستان یک روز جهنمی در مدرسه (یک مطالعه موردی واقعی)

تئوری کافیه، بیاید بریم سراغ یک داستان واقعی که برای یک مدیر شبکه به اسم «دن» اتفاق افتاده. این داستان در یک فروم اینترنتی به اسم Spiceworks Community مطرح شده و به ما نشون میده که یک طوفان برادکست در دنیای واقعی چقدر می‌تونه گیج‌کننده و وحشتناک باشه.

صحنه جرم: یک مدرسه بزرگ

محل وقوع داستان یک مدرسه است با حدود ۹۰۰ دستگاه کامپیوتری و تقریبا ۶۰ تا سوییچ شبکه. بیشتر این سوییچ‌ها از برند Netgear و مدل‌های GS724T، GSM7224 و GSM7328S هستن. این مدرسه برای شبکه وای‌فای خودش هم از سیستم Meru و چند تا سوییچ PoE (که برق رو از طریق کابل شبکه منتقل می‌کنن) استفاده می‌کنه.
دن، مدیر شبکه، میگه که در حال فعال‌سازی قابلیتی به اسم IGMP Snooping بوده (که برای مدیریت بهتر ترافیک مالتی‌کست استفاده میشه) اما هنوز روی همه سوییچ‌ها فعالش نکرده. یک نکته خیلی مهم هم میگه: «ما پروتکل STP رو روشن نکردیم، چون بهمون گفته بودن که می‌تونه باعث مشکلات دیگه‌ای بشه.» این تصمیم، همونطور که می‌بینیم، قراره براشون گرون تموم بشه.

شروع فاجعه: اولین روز مدرسه

داستان از اولین روز بازگشایی مدارس شروع میشه. همه چیز عادیه. بچه‌ها رمزهاشون رو فراموش کردن، بعضی کامپیوترها به خاطر نقاشی کلاس‌ها قطع شدن و تیم IT مشغول حل این مشکلات روزمره است. همه چیز خوب پیش میره تا اینکه… ناگهان، ۱۰ دقیقه قبل از ناهار، کل شبکه مدرسه قطع میشه!
فکرش رو بکنید، دقیقا موقعی که صندوق‌های فروش غذای سلف مدرسه (که اونها هم به شبکه وصل بودن) بیشترین کار رو دارن. حتی سیستم تلفن مدرسه که برای مدیریت از راه دور به شبکه وصل بود هم از کار میفته (البته سیستم تلفن از نوع استاندارد بوده نه VOIP).
دن یک صحنه عجیب رو توصیف می‌کنه: چراغ‌های تمام ۶۰ تا سوییچ شبکه، همگی با هم، با یک ریتم ثابت و یکنواخت در حال چشمک زدن بودن. این یکی از کلاسیک‌ترین علائم یک طوفان برادکست تمام‌عیاره. انگار که تمام دستگاه‌های شبکه داشتن با هم فریاد می‌زدن.

تحقیقات کارآگاه «دن»

دن که یک مدیر شبکه باتجربه است، سریع دست به کار میشه. اولین فکرش اینه که یک طوفان برادکست اتفاق افتاده. پس میره سراغ ابزاری به اسم (Wireshark). وایرشارک مثل یک دستگاه شنود برای شبکه است. هر بسته‌ای که از کارت شبکه شما رد میشه رو ضبط می‌کنه و بهتون نشون میده. دن انتظار داشت که با یک سیل از بسته‌های برادکست مواجه بشه و شاید بتونه آدرس IP کامپیوتری که این طوفان رو شروع کرده پیدا کنه.

اما چیزی که می‌بینه خیلی عجیب‌تره: به جای بسته‌های برادکست عادی، وایرشارک یک سیل عظیم از بسته‌های ICMPv6 رو نشون میده. این خیلی عجیبه، چون دن میگه: «ما فقط از IPv4 استفاده می‌کنیم…».

• توضیح سریع: IPv4 و IPv6 دو نسخه از پروتکل اینترنت هستن. IPv4 از آدرس‌های ۳۲ بیتی (مثل 192.168.1.10) استفاده می‌کنه و IPv6 از آدرس‌های ۱۲۸ بیتی که خیلی طولانی‌تر و پیچیده‌ترن. بیشتر شبکه‌ها هنوز از IPv4 استفاده می‌کنن، اما سیستم‌عامل‌های جدید به طور پیش‌فرض IPv6 رو هم فعال دارن.

دیدن این همه ترافیک IPv6 روی یک شبکه IPv4، دن رو به شک میندازه. آیا ممکنه این یک حمله DoS باشه؟ اون تا حالا از نزدیک یک حمله واقعی ندیده بود و این سناریو براش جدید بود.

تلاش برای مهار طوفان

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

خودش و مدیر ارشد شبکه هم سعی می‌کنن منبع مشکل رو پیدا کنن. اونها با قطع کردن کابل‌های فیبر نوری اصلی که بخش‌های مختلف مدرسه رو به هم وصل می‌کرد، سعی داشتن طوفان رو به یک قسمت از مدرسه محدود کنن. اما نتیجه باز هم گیج‌کننده بود: «وقتی یک لینک فیبر نوری رو قطع می‌کردیم، تفاوت زیادی توی چشمک زدن چراغ‌های دو طرف لینک نمی‌دیدیم. چطور ممکنه یک طوفان برادکست روی دو نیمه جدا شده از شبکه تاثیر بذاره؟» این سوال خیلی مهمیه. تنها توضیح منطقی این بود که در هر دو نیمه جدا شده از مدرسه، یک لوپ جداگانه وجود داشته باشه که خیلی بعید به نظر می‌رسید.

راه‌حل نهایی: خاموشی بزرگ!

تیم شبکه که حسابی کلافه شده بود، به یک احتمال دیگه فکر می‌کنه. اونها قبلا دیده بودن که بعد از قطع و وصل شدن برق، بعضی وقتا یکی دو تا از سوییچ‌هاشون قاطی می‌کنن و همین‌طور چراغ‌هاشون چشمک می‌زنه و با یک ری‌استارت ساده درست میشن. اما این بار مشکل در سطح کل شبکه بود و گزارش‌های UPS (منبع برق اضطراری) هم هیچ نوسان برقی رو نشون نمی‌داد.
با این حال، به عنوان یک تیر در تاریکی، تصمیم می‌گیرن سوییچ‌های یک رک (که ۴-۵ تا سوییچ توش بود) رو ری‌استارت کنن. اما فایده‌ای نداشت. به محض اینکه سوییچ‌ها بالا اومدن، چشمک زدن هماهنگ چراغ‌ها دوباره شروع شد.

در نهایت، به تنها راه‌حل باقی‌مونده متوسل شدن: خاموش کردن «تمام» سوییچ‌های شبکه.
بعد از خاموش کردن همه چیز، شروع کردن به روشن کردن سوییچ‌ها، اما با یک ترتیب خاص: اول از همه سوییچی که به گیت‌وی اصلی (default gateway) یا راه خروج شبکه به اینترنت وصل بود، و بعد رک به رک و لایه به لایه به سمت پایین. در تمام این مدت، یک پینگ مداوم به سمت گیت‌وی اصلی در جریان بود تا ببینن کی ارتباط برقرار میشه.
بعد از اینکه آخرین رک هم روشن شد، همه چیز به حالت عادی برگشت. چراغ‌های سوییچ‌ها نرمال شدن و شبکه دوباره کار می‌کرد. پینگ هم حتی یک بار قطع نشد.

یک پایان باز و دلهره‌آور

دن دوباره وایرشارک رو باز می‌کنه و با فیلتر «ip.proto == ICMPv6» دنبال اون بسته‌های عجیب می‌گرده، اما حتی یک بسته هم پیدا نمی‌کنه. البته تا اون موقع خیلی از کامپیوترها خاموش شده بودن.
داستان دن با یک نگرانی بزرگ تموم میشه: «نگرانی من اینه که فردا صبح وقتی همه کامپیوترها روشن بشن، ممکنه دقیقا همین مشکل دوباره برامون پیش بیاد.»
این داستان به ما نشون میده که پیدا کردن ریشه یک طوفان برادکست چقدر می‌تونه سخت و طاقت‌فرسا باشه و حتی بعد از حل موقتی مشکل، هیچ تضمینی برای برنگشتنش وجود نداره، مگر اینکه علت اصلی پیدا و رفع بشه.

فصل ششم: وقتی طوفان از دنیای مجازی میاد! (مشکلات در محیط‌های مجازی‌سازی)

تا الان در مورد شبکه‌های فیزیکی با کابل و سوییچ‌های واقعی صحبت کردیم. اما دنیای امروز پر از سرورهای قدرتمندیه که ده‌ها ماشین مجازی (Virtual Machine – VM) رو هم‌زمان اجرا می‌کنن. ماشین مجازی یعنی یک کامپیوتر کامل (با سیستم‌عامل و نرم‌افزار) که به جای اینکه یک کیس سخت‌افزاری جدا داشته باشه، به صورت نرم‌افزاری داخل یک سرور فیزیکی بزرگ اجرا میشه. این محیط‌های مجازی هم شبکه خودشون رو دارن که بهش میگن سوییچ مجازی (virtual switch). و بله، طوفان برادکست می‌تونه از این دنیا هم شروع بشه.

بیاید یک مورد واقعی دیگه رو بررسی کنیم که در فروم پشتیبانی سیسکو (Cisco Community) مطرح شده.

صحنه جرم: یک دیتاسنتر پیشرفته

محیط این داستان یک دیتاسنterه که از تجهیزات پیشرفته سیسکو به اسم UCS استفاده می‌کنه. اونها دو تا دستگاه اصلی به اسم Fabric-Interconnect 9296 دارن که مثل مغز متفکر شبکه برای سرورها عمل می‌کنن. روی سرورهای تیغه‌ای (Blade Servers) اونها، نرم‌افزار مجازی‌سازی ESXi نصبه و کلی ماشین مجازی روشون در حال اجراست.

شروع مشکل: مقصر، یک ماشین مجازی بود!

یک روز، شبکه این شرکت دچار مشکلات جدی میشه. بعد از دو ساعت عیب‌یابی و بررسی، تیم شبکه به یک نتیجه باورنکردنی می‌رسن: منبع کل مشکلات یک ماشین مجازی بوده که روی یکی از سرورهای ESXi نصب شده بود.
این ماشین مجازی جوری پیکربندی شده بود که خودش مثل یک «سوییچ مجازی» عمل می‌کرد. یک تنظیم اشتباه یا یک باگ در این VM باعث شده بود که شروع به تولید و پخش حجم وحشتناکی از ترافیک برادکست در کل اون زیرشبکه (subnet) بکنه. این ترافیک اون‌قدر زیاد بود که کل شبکه رو مختل کرده بود.
راه‌حل فوری چی بود؟ اونها به سادگی اون ماشین مجازی رو خاموش کردن (Power Off). به محض خاموش شدن VM، همه چیز به حالت عادی برگشت.

سوال اصلی: چطور در آینده جلوی این اتفاق رو بگیریم؟

حالا مدیر شبکه یک سوال مهم می‌پرسه: «چطور می‌تونیم جلوی تکرار همچین اتفاقی رو در آینده بگیریم؟ من می‌دونم که روی تجهیزات شبکه فیزیکی، ما دستوری مثل BPDU Guard روی پورت‌های کاربرا فعال می‌کنیم تا جلوی لوپ رو بگیره، اما اینجا توی محیط مدیریت سیسکو UCSM چی کار می‌تونم بکنم؟»

پاسخ‌های یک متخصص به اسم «کرک» (Kirk) خیلی آموزنده است و به ما نشون میده که مدیریت شبکه در دنیای مجازی چالش‌های خاص خودش رو داره.

توصیه‌های متخصص برای محیط‌های مجازی

کرک چند تا نکته کلیدی رو توضیح میده:

1. مکانیسم‌های داخلی UCSM کافی نیستن: کرک میگه که خود سیستم‌های UCSM/FI سیسکو به طور پیش‌فرض مکانیسم‌هایی برای جلوگیری از لوپ دارن، مثل deja vu check و RPF check. این سیستم‌ها جلوی ایجاد لوپ‌های ساختاری در شبکه رو می‌گیرن. اما، اگه یک ماشین مجازی خودش شروع به تولید سیل‌آسای ترافیک برادکست بکنه (که بهش میگن هاست یا میزبان بدرفتار – misbehaving host)، تجهیزات Fabric Interconnect تقصیری ندارن. وظیفه اونها اینه که فریم‌ها رو با حداکثر سرعت تحویل بدن. پس اگه یک VM شروع به فریاد زدن کنه، FI هم اون فریادها رو خیلی سریع و کارآمد در کل شبکه پخش می‌کنه!
2. راه‌حل مستقیم وجود نداره: هیچ تنظیم مستقیمی روی کارت شبکه مجازی (vNIC) یک VM وجود نداره که بتونه جلوی ایجاد لوپ یا بریج (bridging) در سطح سیستم‌عامل اون VM رو بگیره. اگه شما داخل یک ویندوز سرور مجازی، دو تا کارت شبکه مجازی رو به هم بریج کنید، یک لوپ ایجاد کردید و تجهیزات بیرونی به سادگی نمی‌تونن جلوش رو بگیرن.
3. بهترین راهکارها (Best Practices): به جای یک دکمه جادویی، باید روی طراحی درست و پیکربندی صحیح تمرکز کرد:
   1. محدود کردن VLANها: یکی از بهترین کارها اینه که روی کارت شبکه‌های مجازی، فقط و فقط VLANهایی رو مجاز کنید که اون ماشین مجازی واقعا بهشون احتیاج داره. کرک میگه خیلی از مشتری‌ها در ابتدای طراحی، چون دقیقا نمی‌دونن هر سرور به چه VLANهایی نیاز داره، همه VLANها رو روی پروفایل سرورها مجاز می‌کنن. این کار خیلی خطرناکه. چون اگه یک طوفان در یک VLAN اتفاق بیفته، این ترافیک به تمام سرورهایی که اون VLAN روشون مجازه ارسال میشه، حتی اگه بهش نیازی نداشته باشن. این کار سطح حمله و تاثیر طوفان رو به شدت افزایش میده. محدود کردن VLANها مثل اینه که به جای دادن شاه‌کلید ساختمون به هر کارمند، فقط کلید اتاق خودش رو بهش بدید.
   2. پیدا کردن منبع با وایرشارک: دوباره اسم وایرشارک به میون میاد. کرک تاکید می‌کنه که باید ترافیک رو ضبط و تحلیل کنید تا بفهمید دقیقا چه نوع ترافیکیه، آدرس MAC منبع دقیقش چیه، و در کدوم VLAN داره اتفاق میفته.
   3. مراقب تنظیمات پیچیده باشید: چیزهایی مثل تنظیمات اشتباه در الگوریتم‌های تیمینگ (teaming) سوییچ مجازی، پیکربندی نادرست شبکه‌های لایه ۲ مجزا (disjoint layer 2)، یا مشکلات در سوییچ‌های فیزیکی بالادستی، همگی می‌تونن باعث بشن یک ماشین مجازی نتونه آدرس MAC دستگاه دیگه‌ای رو پیدا کنه و در نتیجه به طور مداوم شروع به ارسال درخواست‌های ARP (که یک نوع برادکسته) بکنه و یک طوفان ARP راه بندازه.
4. UCS برای سرعت ساخته شده، نه فیلترینگ: کرک یک نکته مهم دیگه رو هم میگه. تجهیزاتی مثل UCSM طوری طراحی شدن که مثل یک کامپیوتر میزبان (end host) رفتار کنن: حداکثر توان عملیاتی (throughput) و سوییچینگ سریع (cut-through switching). این دستگاه‌ها برای فیلتر کردن یا تحلیل عمیق بسته‌ها طراحی نشدن. قابلیت‌هایی مثل Storm Control معمولا روی سوییچ‌ها و روترهای دیگه پیدا میشه، نه روی این تجهیزات مرکزی. پس راه‌حل در طراحی صحیح شبکه است، نه در انتظار داشتن یک قابلیت خاص روی این دستگاه.

فصل هفتم: یک داستان مجازی دیگر، طوفان ARP و NSX-T

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

مشکل: طوفان ARP و فلج شدن روتر

این کاربر میگه که شرکتشون با یک طوفان ARP مواجه شده. ARP یا (Address Resolution Protocol) پروتکلیه که کامپیوترها برای پیدا کردن آدرس فیزیکی (MAC Address) یکدیگر از روی آدرس منطقی (IP Address) استفاده می‌کنن. درخواست‌های ARP به صورت برادکست ارسال میشن.
در این مورد، چندین ماشین مجازی با هم شروع به ارسال درخواست‌های ARP با نرخ بسیار بالا کردن. این سیل درخواست‌ها به روتر اصلی یا گیت‌وی بالادستی اونها میرسه و پردازنده روتر اون‌قدر درگیر میشه که شروع به انداختن بسته‌های ARP (dropping ARP) می‌کنه.

این اتفاق یک اثر دومینویی وحشتناک داشت:

• چون روتر دیگه نمی‌تونست به درخواست‌های ARP جواب بده، تمام VLANها تحت تاثیر قرار گرفتن. چرا؟ چون قابلیتی که روی روتر ترافیک رو کنترل می‌کرد (policer) برای یک VLAN خاص تنظیم نشده بود و کل ترافیک ARP رو محدود می‌کرد.
• حتی روی پروتکل‌های مسیریابی داینامیک هم تاثیر گذاشت. وقتی دو تا روتر می‌خوان با هم اطلاعات مسیرها رو رد و بدل کنن، اول باید آدرس MAC همدیگه رو پیدا کنن. وقتی جدول ARP روتر به خاطر طوفان به هم می‌ریخت، این ارتباط هم مختل می‌شد.

مظنون جدید: NSX-T

این کاربر یک نکته خیلی جالب رو مطرح می‌کنه. اونها به تازگی در محیط مجازی‌شون از NSX-T (یک پلتفرم مجازی‌سازی شبکه از شرکت VMware) استفاده کرده بودن و ماشین‌های مجازی که این طوفان رو ایجاد کرده بودن، همگی روی پورت‌گروپ‌های NSX-T قرار داشتن.
فرضیه اونها این بود که شاید یک باگ در NSX-T وجود داره. به نظر می‌رسید که ماشین‌های مجازی به دلایلی جواب ARP رو از گیت‌وی دریافت نمی‌کردن، و به خاطر همین به طور دیوانه‌واری و با یک نرخ خیلی تهاجمی (aggressive rate) به ارسال درخواست ARP ادامه می‌دادن تا بالاخره جواب بگیرن.

راه‌حل‌های پیاده‌سازی شده

این تیم هم برای مهار مشکل دست به کار شد:

1. فعال کردن Storm-Control: اونها روی سوییچ‌های فیزیکی‌شون قابلیت storm-control رو با پایین‌ترین حد ممکن فعال کردن. هرچند این حد هنوز از آستانه کنترلر ARP روی روتر اصلیشون (یک Nexus 7K) بالاتر بود، ولی تا حدی جلوی شدت طوفان رو می‌گرفت.
2. طراحی یک Policer سفارشی: قدم بعدی و هوشمندانه‌تر اونها این بود که یک کنترلر ترافیک (policer) سفارشی روی روتر نکسوس خودشون بنویسن. این policer طوری طراحی میشه که به طور خاص، ترافیکی که از آدرس‌های MAC متعلق به محیط VMWare میاد رو با یک آستانه پایین‌تر محدود کنه. این یک راه‌حل هدفمند برای کنترل ترافیک از سمت محیط مجازی، بدون تاثیر گذاشتن روی بقیه قسمت‌های شبکه است.

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

فصل هشتم: پرسش و پاسخ

سوال ۱: پس طوفان برادکست یه جورایی مثل اسپم یا هرزنامه توی شبکه است، درسته؟

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

سوال ۲: چرا اصلا این پیام‌های برادکست رو به طور کامل از شبکه‌ها حذف نمی‌کنن تا این مشکلات پیش نیاد؟

جواب: سوال خیلی خوبیه. دلیلش اینه که برادکست‌ها یک ابزار ضروری و حیاتی برای عملکرد صحیح یک شبکه هستن. بدون اونها، خیلی از کارهای پایه‌ای شبکه غیرممکن میشه. مثلا:

• پیدا کردن آدرس‌ها (ARP): وقتی کامپیوتر شما می‌خواد با کامپیوتر دیگه‌ای توی همون شبکه حرف بزنه، فقط آدرس IP اون رو می‌دونه. اما برای ارسال واقعی داده روی کابل، به آدرس سخت‌افزاری یا MAC اون نیاز داره. پس یک پیام برادکست به کل شبکه می‌فرسته و می‌پرسه: «هی، کی آدرس IP فلان رو داره؟ لطفا آدرس MAC خودت رو به من بگو.»
• گرفتن آدرس IP (DHCP): وقتی شما کامپیوترتون رو روشن می‌کنید و به شبکه وصل میشید، کامپیوتر شما هنوز آدرس IP نداره. پس یک پیام برادکست می‌فرسته و داد میزنه: «سلام، من جدیدم، آیا یک سرور DHCP اینجا هست که به من یک آدرس IP بده؟»

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

سوال ۳: فرق اصلی بین یک طوفان اتفاقی (مثل کابل لوپ شده) و یک حمله DoS عمدی چیه؟ از نظر فنی چه تفاوتی دارن؟

جواب: از نظر تاثیری که روی شبکه میذارن، هر دو می‌تونن فاجعه‌بار باشن و کل شبکه رو از کار بندازن. اما از نظر فنی و انگیزشی، تفاوت‌های اساسی دارن:

• منبع: در یک لوپ، ترافیک از خود شبکه نشات می‌گیره. یک بسته عادی وارد یک حلقه میشه و بی‌پایان تکرار میشه. در یک حمله DoS مثل اسمرف، ترافیک مخرب توسط یک مهاجم از «بیرون» شبکه تولید میشه و به سمت شبکه شما هدایت میشه.
• هدف: در لوپ، هیچ هدف و نیت بدی وجود نداره. یک اشتباه انسانی یا سخت‌افزاریه. در حمله DoS، یک نیت مخرب برای از کار انداختن یک قربانی خاص وجود داره.
• نوع ترافیک: در یک لوپ، معمولا یک یا چند نوع فریم برادکست عادی (مثل ARP یا DHCP) به طور مکرر کپی میشن. در حمله اسمرف، ترافیک به طور خاص از نوع ICMP Echo Request با آدرس جعلیه. در داستان مدرسه، دیدیم که اونها به یک حمله DoS شک کردن چون نوع ترافیک (ICMPv6) خیلی غیرعادی و مشکوک بود.
• راه‌حل: برای حل مشکل لوپ، باید اون حلقه فیزیکی یا منطقی رو پیدا و حذف کنید (یا از پروتکلی مثل STP استفاده کنید). برای مقابله با حمله DoS، باید ترافیک مخرب رو روی روترها یا فایروال‌های لب مرز شبکه شناسایی و فیلتر کنید.

سوال ۴: توی داستان مدرسه، چرا واقعا خاموش و روشن کردن ترتیبی سوییچ‌ها کار کرد؟ آیا این یعنی مشکل برای همیشه حل شد؟

جواب: این یکی از اون سوال‌های میلیون دلاریه! خاموش و روشن کردن ترتیبی سوییچ‌ها به این دلیل کار کرد که حافظه موقت (RAM) و جداول آدرس MAC تمام سوییچ‌ها رو پاک کرد. وقتی همه چیز خاموش میشه، اون طوفان بی‌نهایت از بسته‌ها که در حال چرخیدن بودن، از بین میرن. با روشن کردن ترتیبی از مرکز به سمت لبه‌های شبکه، سوییچ‌ها فرصت پیدا می‌کنن که به آرامی بالا بیان، جدول آدرس‌هاشون رو از نو و به درستی بسازن و با همسایه‌هاشون ارتباط برقرار کنن، بدون اینکه از همون اول با یک سیل ترافیک مواجه بشن.
اما آیا مشکل برای همیشه حل شد؟ به احتمال خیلی زیاد، نه! این کار مثل ری‌استارت کردن کامپیوتریه که هنگ کرده. شما مشکل فعلی رو حل کردید، اما اگه علت اصلی هنگ کردن یک مشکل نرم‌افزاری یا سخت‌افزاری باشه، اون مشکل دوباره برمی‌گرده. در مورد مدرسه، علت اصلی (که می‌تونست یک کابل لوپ شده، یک کارت شبکه خراب، یک دستگاه بدرفتار یا حتی یک باگ نرم‌افزاری باشه) هنوز پیدا و رفع نشده. به همین دلیله که «دن» نگران بود که فردا صبح با روشن شدن همه کامپیوترها، اون عامل هرچی که هست دوباره فعال بشه و طوفان رو از نو راه بندازه. راه‌حل واقعی، پیدا کردن اون «پکت چرنوبیل» و منبعشه.

سوال ۵: آیا اینکه یک ماشین مجازی کل شبکه رو از کار بندازه یک چیز عادیه؟ چطور یک برنامه نرم‌افزاری می‌تونه همچین بلایی سر سخت‌افزار بیاره؟

جواب: این اتفاق شاید «عادی» نباشه، اما قطعا «ممکنه» و با افزایش استفاده از مجازی‌سازی، بیشتر هم دیده میشه. دلیلش اینه که مرز بین نرم‌افزار و سخت‌افزار در شبکه‌های مدرن خیلی کم‌رنگ شده.
یک ماشین مجازی، هرچند نرم‌افزاریه، اما از طریق کارت شبکه مجازی و سوییچ مجازی به شبکه فیزیکی وصله. اگه این ماشین مجازی (به خاطر یک باگ یا تنظیم اشتباه) شروع به تولید ترافیک شبکه با نرخ بسیار بالا بکنه، از دید سوییچ فیزیکی هیچ فرقی با یک کامپیوتر فیزیکی که همین کار رو می‌کنه نداره. سوییچ فیزیکی فقط یک جریان عظیم از بسته‌ها رو از پورتی که به اون سرور فیزیکی وصله دریافت می‌کنه و طبق وظیفه‌اش، اونها رو در شبکه پخش می‌کنه.
فکرش رو بکنید، یک سرور فیزیکی مدرن می‌تونه یک اتصال ۱۰ یا حتی ۴۰ گیگابیت بر ثانیه به شبکه داشته باشه. یک ماشین مجازی با یک باگ نرم‌افزاری می‌تونه به راحتی بخش بزرگی از این پهنای باند رو با ترافیک برادکست بی‌فایده پر کنه و یک طوفان عظیم راه بندازه. پس بله، یک «برنامه» می‌تونه کل شبکه «سخت‌افزاری» رو به زانو دربیاره، چون در نهایت این برنامه‌ها هستن که ترافیک شبکه رو تولید می‌کنن.

سوال ۶: اگه بخواید فقط یک توصیه، یعنی مهم‌ترین توصیه رو برای جلوگیری از این طوفان‌ها به ما بکنید، اون چیه؟

جواب: اگه قرار باشه فقط یک چیز بگم، اون اینه: «شبکه‌تون رو هوشمندانه تقسیم‌بندی کنید.»
یک شبکه بزرگ و مسطح (Flat Network) که همه دستگاه‌ها توی یک دامنه برادکست بزرگ قرار دارن، مثل یک انبار باروت می‌مونه. یک جرقه کوچیک (یک لوپ یا یک دستگاه خراب) می‌تونه کل انبار رو منفجر کنه.
اما اگه شما با استفاده از VLANها و روترها، این شبکه بزرگ رو به چندین جزیره کوچیک و ایزوله تقسیم کنید، تاثیر هر مشکلی به همون جزیره‌ای که توش اتفاق افتاده محدود میشه. این کار بهش میگن «تقسیم‌بندی شبکه» یا (Network Segmentation). این اصل، نه تنها جلوی گسترش طوفان برادکست رو می‌گیره، بلکه از نظر امنیتی هم فوق‌العاده مهمه، چون جلوی حرکت جانبی هکرها در شبکه رو هم می‌گیره.
پس به جای داشتن یک سالن بزرگ و پرهمهمه، چندین اتاق کوچک و آرام داشته باشید. این بهترین و پایه‌ای‌ترین قدم برای ساختن یک شبکه پایدار و قابل اطمینانه. البته فعال کردن پروتکل‌هایی مثل STP هم در کنارش حیاتیه، اما تقسیم‌بندی درست، معماری شبکه شما رو از پایه محکم می‌کنه.