Spanning-Tree چیست؟ و چگونه کار می کند

زمان مطالعه: ۵ دقیقه

Spanning-Tree چیست؟ پاسخ کوتاه به این سوال این است که: اترنت (Ethernet) در توپولوژی های redundant کار نمی کند زیرا Loop های اترنت نیز layer-2 loop یا broadcast storms نامیده می شوند. بدون فناوری که LAN را با لینک های redundant به توپولوژی بدون loop تقسیم کند، فریم های BUM (که شامل broadcast, unknown-unicast, and multicast) به طور نامحدود دور می زنند تا زمانی که لینک یا دستگاهی فقط خراب شود. این امر به دلیل شیوه ای است که سوئیچ ها فریم های BUM را ارسال می کنند.

نکته: تکنولوژی اترنت در توپولوژی های سوئیچ دارای loop مانند اتصال مثلثی سوئیچ های متصل به هم کار نمی کند. باید از تکنیکی استفاده شود که توپولوژی را به صورت loop-free ایجاد کند. (مانند Spanning-Tree).

سوئیچ ها و فریم های BUM

هنگامی که یک سوئیچ یک فریم را دریافت می کند، آدرس MAC مقصد را در جدول MAC خود بررسی می کند و اگر ورودی منطبق وجود نداشته باشد، فریم را از همه پورت ها به جز پورت ورودی ارسال می کند. این فرایند flooding نامیده می شود و فریمی که مقصد MAC آن ناشناخته است یک unknown unicast نامیده می شود.

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

سوئیچ ها همچنین دو نوع فریم دیگر را flood می کنند:

Broadcast: آنهایی که مقصد آدرس اترنت FF-FF-FF-FF-FF-FF هستند
Multicast: مواردی که برای آدرس MAC تعیین می شوند که با بیت های ۱۱۱۰ شروع می شود.

شکل زیر نمونه ای را نشان می دهد که در آن PC1 یک فریم broadcast ارسال می کند. بر اساس آدرس MAC مقصد، سوئیچ ۱ می داند که broadcast می شود و بنابراین یک کپی از آن به همه پورت های به جز ورودی ارسال می کند. بنابراین یک کپی از فریم به SW2 و SW3 می رود که منطق یکسانی را انجام می دهند. در نهایت، هر نود node در این broadcast domain یک نسخه از این پکت را دریافت می کند.

همه چیز در توپولوژی LAN فوق خوب کار می کند با این تفاوت که در صورت خرابی هیچ افزونگی وجود ندارد. بیایید ببینیم اگر یک پیوند اضافی بین SW2 و S3 معرفی کنیم، چه اتفاقی می افتد.

حلقه های اترنت (Broadcast storms)

اگر یک توپولوژی سوئیچینگ حلقه ای مانند آنچه در شکل زیر نشان داده شده است وجود داشته باشد و درخت Spanning-Tree اجرا نشود، سه مشکل اصلی رخ می دهد:

مشکل ۱ – حتی یک looping frame باعث broadcast storm می شود.

این امر زمانی اتفاق می افتد که یک فریم BUM دور سوئیچ ها به طور نامحدود بچرخد. broadcast storm ادامه می یابد تا زمانی که لینکی بیش از حد اشباع شود و یا خراب شود یا سوئیچ به دلیل استفاده زیاد از CPU از کار بیفتد. برای کمک به تجسم این مفهوم، ما انیمیشن نشان داده شده در شکل زیر را ایجاد کرده ایم. توجه داشته باشید که همه LED های پورت به سرعت چشمک می زنند، معمولاً همزمان و سوئیچ ها با CPU بسیار بالا کار می کنند. این روند تا زمانی ادامه می یابد که چیزی خراب شود و یا حلقه شکسته شود. بیایید ببینیم چرا این اتفاق می افتد؟

منطق اترنت به سوئیچ ها می گوید که فریم BUM را در همه پورت ها به جز رابط ورودی flood کنند. اگر از این منطق برای مثال خود در شکل بالا۲ استفاده کنیم، بیایید ببینیم چه اتفاقی می افتد:

SW1 یک فریم broadcast روی لینک SW1-SW2 دریافت می کند، و یک کپی از همه آن را به همه پورت های خود (به SW3 و PC1) به جز لینک ورودی (پیوند SW1-SW2) ارسال می کند.

SW3 فریم broadcast را دریافت می کند و از همان منطق استفاده می کند. این سوئیچ نیز یک کپی از آن را به همه پورت های خود به جز پورت فریم را ارسال می کند. بنابراین broadcast را به SW2 و PC3 ارسال می کند.

SW2 فریم را دریافت می کند، یک کپی از تمام پورت های خود به جز پیوند ورودی SW3-SW2 ارسال می کند. بنابراین broadcast را به SW1 و PC2 ارسال می کند.

و این روند تکرار می شود و به طور نامحدود ادامه می یابد.

همچنین توجه داشته باشید که همان حلقه در جهت مخالف اتفاق می افتد.

مشکل ۲ – storm باعث مشکل دیگری به نام بی ثباتی جدول MAC می شود.

اگر فرایند یادگیری MAC را به خاطر بیاوریم، هنگامی که یک سوئیچ یک فریم را دریافت می کند، یک ورودی در جدول آدرس MAC برای آدرس منبع و پورت ورودی ایجاد می کند. اما در صورت وقوع broadcast storm، چندین نسخه از یک فریم مشابه loop می شوند و سوئیچ آن را در چندین اینترفیس دریافت می کند. اما یک آدرس MAC تنها می تواند فقط به یک اینترفیس سوئیچ متصل شود. بنابراین سوئیچ مدام در حال بازنویسی ورودی آدرس MAC منبع با اینترفیس های و در نتیجه ناپایداری است.

در خروجی زیر می بینید که در حالی که یک حلقه وجود دارد ، هربار که جدول آدرس MAC یک سوئیچ را بررسی می کنیم ، آدرس MAC برجسته به پورت دیگری متصل می شود.

SW1#show mac address-table

Mac Address Table

——————————————-

Vlan Mac Address Type Ports

—- ———– ——– —–

۱ ۰۰۰۲.۱۷۱d.6702 DYNAMIC Fa0/2

۱ ۰۰۰b.be01.b603 DYNAMIC Fa0/3

۱ ۰۰d0.979a.eb83 DYNAMIC Fa0/3

SW1#show mac address-table

Mac Address Table

——————————————-

Vlan Mac Address Type Ports

—- ———– ——– —–

۱ ۰۰۰۲.۱۷۱d.6702 DYNAMIC Fa0/2

۱ ۰۰۰b.be01.b603 DYNAMIC Fa0/3

۱ ۰۰d0.979a.eb83 DYNAMIC Fa0/2

SW1#show mac address-table

Mac Address Table

——————————————-

Vlan Mac Address Type Ports

—- ———– ——– —–

۱ ۰۰۰۲.۱۷۱d.6702 DYNAMIC Fa0/2

۱ ۰۰۰b.be01.b603 DYNAMIC Fa0/3

۱ ۰۰d0.979a.eb83 DYNAMIC Fa0/3

مشکل ۳ – دستگاه های پایانی چندین نسخه از یک فریم را دریافت می کنند.

آخرین مسئله ای که در مورد یک حلقه رخ می دهد این است که کلاینت های نهایی کپی های متعددی از فریم های حلقه را بارها و بارها دریافت می کنند در حالی که broadcast storm فعال است. در نتیجه ، مشتریان نهایی ممکن است CPU بالایی را تجربه کنند و برنامه های حیاتی ممکن است از کمبود منابع از کار بیفتند.

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

خلاصه مقاله Spanning-Tree:

برای مهندسان شبکه مهم است که بفهمند اترنت در توپولوژی های سوئیچ های دارای loop کار نمی کند. به همین دلیل ما به پروتکلی نیاز داریم که بتواند توپولوژی حلقه را به یک پروتکل بدون حلقه تبدیل کند.