آموزش میکروتیک MTCNA؛ شب ۱۰: Bridge، پورت‌ها و جلوگیری از Loop
فهرست نوشته
Bridge چند پورت را در یک دامنهٔ لایهٔ دوم قرار می‌دهد. امشب LAN را گسترش می‌دهیم، جدول یادگیری MAC را می‌خوانیم و نشان می‌دهیم چرا یک کابل اضافه می‌تواند شبکه را مختل کند.
این نوشته بخشی از دورهٔ MTCNA در ۳۰ شب است. مبنای مثال‌ها RouterOS 7 و آزمایشگاه ایزولهٔ دوره است؛ پیش از تغییر، Snapshot و دسترسی Console داشته باشید.
تصمیم Bridge با تصمیم Router فرق دارد#
Bridge فریم را بر اساس MAC و پورت عبور می‌دهد؛ Router مقصد IP را با Route تطبیق می‌دهد. قرار دادن IP شبکهٔ LAN روی Bridge منطقی است، چون آدرس متعلق به Segment است، نه یک پورت عضو آن.
R1 از شب چهارم Bridge با نام bridge-lan و ether2 دارد. ether1 WAN و ether4 Transit هستند و نباید عضو LAN شوند. پیش از افزودن ether3، مطمئن شوید IP یا سرویس مستقلی روی آن ندارید.
/interface bridge print detail
/interface bridge port print detail
/interface bridge port add bridge=bridge-lan interface=ether3
/interface bridge set [find name="bridge-lan"] protocol-mode=rstp
/interface bridge host print
/interface bridge monitor bridge-lan once
کلاینت B را از شبکهٔ مجازی مشترک ether2 به Segment متصل به ether3 منتقل کنید. ارتباط A و B در همان Subnet باید برقرار بماند. MAC هرکدام در جدول Host باید روی پورت مربوط دیده شود.
آزمایشگاه Loop روی Clone#
به یک Switch آزمایشگاهی ایزوله، دو اتصال از Bridge بدهید. پیش از اتصال دوم RSTP فعال و Capture یا مانیتورینگ آماده باشد. Role و State پورت‌ها را مشاهده کنید؛ یکی ممکن است برای جلوگیری از حلقه Forward نکند. صرف دیدن Carrier روی هر دو کابل، مجوز عبور داده از هر دو نیست.
این تمرین را روی LAN واقعی یا Bridge فاقد STP انجام ندهید. Broadcast storm می‌تواند Console شبکه‌ای و Hypervisor را هم درگیر کند. برای بازگشت، کابل اضافی را جدا کنید؛ صرف Reboot کردن روتر با Loop باقی‌مانده مشکل را رفع نمی‌کند.
Hardware offload و فایروال#
Flag مربوط به Hardware offload را در Bridge Port بخوانید. فعال بودن گزینهٔ hw تضمین نمی‌کند هر سخت‌افزار یا هر ویژگی Offload شود. CHR را برای نتیجه‌گیری دربارهٔ Switch chip روتر فیزیکی معیار نگیرید.
ترافیک دو کلاینت در یک Bridge الزاماً از IP Firewall forward عبور نمی‌کند. گزینهٔ use-ip-firewall مسیر پردازش و عملکرد را تغییر می‌دهد؛ آن را فقط برای آزمایش جدا فعال کنید، نه به‌عنوان تنظیم همیشگی همهٔ Bridgeها. در بخش Wireless، همین مفهوم را روی AP و Station Bridge ادامه می‌دهیم.
شواهد و خودآزمایی#
جدول MAC به پورت، Roleهای RSTP و آدرس IP Bridge را ثبت کنید. با حذف موقت ether3 از Bridge، فقط B باید از LAN جدا شود؛ با افزودن دوباره، اتصالش برگردد.
چرا یک WAN اشتباهاً عضو Bridge می‌تواند DHCP بالادست را به LAN برساند؟ چرا Rule forward روتر لزوماً ارتباط A و B را نمی‌بیند؟ RSTP چه چیزی را حل می‌کند و چه چیزی را، مانند Loop خارج از دامنهٔ کنترل، تضمین نمی‌کند؟