پروتکل STP قسمت اول
تو این فصل میخوایم راجع به مفاهیم spanning-tree و بحثهای مربوط به configuration و customization این پروتکل صحبت کنیم.
قبل از اینکه وارد بحثهای STP بشیم میخوایم در مورد Redundancy صحبت کنیم. اصلا Redundancy چیه؟ اونچیزیکه ما به اسم ایجاد افزونگی میشناسیمش و در واقع Redundancy یه مفهومیه که همیشه فقط توی نتورک یا توی مهندسی نیست و دقت نمیکنید که تو جاهای دیگه هم هست. مثلا فرض کنید که من برای اینکه از طبقه اول برم طبقه دهمِ یک ساختمون از آسانسور استفاده میکنم. در کنار این آسانسور یه راه پله ای هم هستش. چرا؟ آسانسور خوبه ولی اگه از کار بیفته مسیر راه پله میتونه جایگزینش باشه. خیلی وقتا ممکنه ما پله اضطراری هم بزاریم. یعنی سه تا مسیر مختلف بزاریم برای اینکه اگه یکی ازکار افتاد دومی بتونه جایگزین باشه. باز این مثال رو میشه زد که مثلا فرض کنید شما میخواید یه پروژه ای رو یجایی present کنید. یک لپ تاپ با خودتون میبرید و یه لپ تاپ دیگه هم با خودتون میبرید که اگه لپ تاپ اول به هر دلیلی کار نکرد دومی بتونه جایگزینش بشه. اینا یعنی Redundancy . حالا ممکنه بعضی وقتا ماژولهای پاور رو ببینیم (طبق شکل سمت چپ بالا ) که دوتا ورودی برق دارن برای اینکه دوتا ورودی برق متفاوت بهش وصل کنیم که یکی قطع شد اونیکی بتونه جاشو نیگهداره. یا توی سوئیچهای شاسی Base هم همینجوره (طبق شکل سمت راست بالا) و میتونم دوتا ماژول مختلف پاور داشته باشم یا مثلا بیام Supervisor engine های موازی بزارم برای اینکه یکیش ازکار افتاد بعدی بتونه کارشو انجام بده.
پس در کل میتونم بگم ایده لینکهای موازی هم بعنوان Backup برای یک لینک خوبه. یعنی اگه من این دوتا سوئیچ رو (طبق شکل) بجای یک لینک با دو لینک وصل کنم اگه یکیش قطع شد اونیکی میتونه جایگزین بشه. این ایده خوبیه ولی دردسرهایی رو برامون ایجاد میکنه که دردسراش از مزایاش بیشتره. ببینید چطوری این اتفاق میفته. مثلا فرض کنید کامپیوتر A میاد یه برادکست ارسال میکنه. برادکستی که کامپیوتر A ارسال میکنه باید به تمامی اینترفیسهای SW1 ارسال بشه. حالا SW2 دوتا برادکست گرفته. برادکست اولش رو روی اینترفیس 1 گرفته و باید روی همه اینترفیسهاش ارسال کنه (از اینترفیس 2 تا 6). این براکست از اینترفیسِ 2 سوئیچِ SW2 میاد و میرسه به سوئیچ SW1 . حالا SW1 چیکار باید بکنه؟ باید روی همه اینترفیسهاش ارسال کنه(همینطور روی اینترفیس 6). دوباره SW2 روی اینترفیسِ 1 خودش یه برادکست دریافت میکنه و باید روی همه اینترفیسهاش ارسال کنه (از 2 تا 6). حالا اون برادکستی که SW2 روی اینترفیسِ 2 خودش دریافت میکنه هم میاد روی اینترفیسهاش ارسال میکنه و از اینترفیسِ 1 خودش یه برادکست ارسال میکنه به SW1 و SW1 هم روی اینترفیس 6 خودش یه برادکست دریافت میکنه و اونو روی همه اینترفیسهاش ارسال میکنه. به این مشکل اصطلاحا میگن (Broadcast Storm). پس Broadcast Storm یکی از مشکلاتی هستش که میتونه برای ما ایجاد بشه. نکته بعدی که بعنوان مشکل میتونم بهش اشاره کنم اینه که فرض کنید اگه بخوام جدول مکِ SW2 رو ببینم اونوقت SW2 کامپیوترِ A رو روی چند تا پورت لِرن کرده (پورت 1 و 2). مثلا کامپیوتر A یه بسته میخواد از کامپیوتر E بگیره ولی دوتا بسته دریافت میکنه (بخاطر وجود دو لینکی که بین سوئیچها قرار داره) یکی رو پورت 6 و یکی روی پورت 5 (بهش میگن Multiple Frame transmission). کپی های بیشتر از حدِ نیاز داره از یک فریم دریافت میکنه که یکبار بگیره کافیه ولی داره دریافت میکنه. یا حالت بعدی رو بهش میگن (Mac table instability) یا (ناپایداری Mac table ). سوئیچِ SW2 یکبار که کامپیوتر A بسته میفرسته روی پورت 1 لِرنِش میکنه و میره توی Mac table خودش میزارتش روی پورت 1 . دفعه دوم که داره بسته رو دریافت میکنه روی لینک دوم روی پورت 2 اینو لرن میکنه و قبلی رو (همون بسته قبلی) پاک میکنه و میزاره روی پورت 2 . دوباره روی پورت 1 لرن میکنه و قبلی رو پاک میکنه و اینو توی Mac table میزاره روی پورت 1 . یعنی میخوام بگم توی Mac table ناپایداری وجود داره.
پس در واقع میتونم بگم این سه تا مشکل (Switching loop) میشناسیم. در گذشته به اسم Bridging loop میشناختن. خب پس با این حساب میگیم استفاده کردن از لینکهای موازی با این دردسرهایی که برامون میسازه اصلا نمی ارزه.
پروتکل Spanning-tree اومده این مشکلات رو حل کنه تا من بتونم از لینکهای موازی هم استفاده کنم. پس یعنی پروتکل Spanning-tree توی نتورک برای این کاربرد داره که من چه لینک موازی رو عمدا ایجاد کنم و چه اینکه ساختار نتورک من یه ساختاری بشه که باعث ایجاد یک طراحی موازی بشه و بتونه جلوی Switching loop رو برامون بگیره.
توی این شکل میتونید Broadcast Storm رو از این دید هم ببینید که چطوری برادکستی که ارسال میشه باعث میشه دائم در حال چرخش باشه و تمامی این کلاینتها هم درگیر این برادکست هستن و توی مباحث Fundamental دیدید که بسته ای که کلاینت دریافت میکنه تا لایه 2 میبره جلو و پروسس میکنه و دور میریزه. یعنی عملا تمام نتورم شما درگیر Broadcast Storm هستش.
پس Spanning-tree protocol یه استاندارد IEEE802.1D هستش و یه پروتکل لایه 2 هستش که اومده یه نتورک بدون Loop ایجاد کنه. چطوری اینکارو میکنه؟ اینو دقت کنید که اگه Loop ایجاد بشه هیچکاری نمیتونید بکنید. یعنی مثلا (مثل شکل قبلی 5) Loop ایجاد شد و Broadcast Storm هم وجود داره حالا چیکار کنم؟ باید فقط بصورت فیزیکی مثلا لینک بین SW2 و SW3 قطع بشه. پس چیزی جلوش رو نمیتونه بگیره وقتی اتفاق بیفته. میشه ازش جلوگیری کرد. چطوری؟ Spanning-tree-protocol میاد یکسری از لینکهای Redundant رو disable نگه میداره که عملا باعث ایجاد Loop نشه. در صورتی که لازم باشه که لینکِ Redundant بیاد توی کار دوباره از disable درش میاره.
اینجارو ببینید. Spanning-tree-protocol میاد میگه من این لینک رو بین (SW2 و SW3) بلاک نگه میدارم. پس هیچوقت برادکست اینجا برنمیگرده. پس اون Loop و Broadcast Storm ایجاد نمیشه و قشنگیش اینه که میگه اگه مثلا ارتباط SW3 تا SW1 قطع بشه من این لینک بین (SW2 و SW3) رو میتونم دوباره up کنم و برگردونمش تو مسیر.
اینجا میخوایم ببینیم که Spanning-tree-protocol چطوری کار میکنه؟ من قبل از اینکه بیام صحبت کنم ترجیح میدم که اول بهتون نشون بدم و ببینید که Spanning-tree-protocol بدون configuration منِ ادمین هم میتونه همون نتیجه ای که میخواد توی نتورک بگیره.
من میخوام دوتا ساختار بچینم که هر دوتا ساختار باعث ایجاد Loop توی نتورک من باشه. توی یه سناریو میخوام سه تا سوئیچ رو بهم وصل کنم و توی یه سناریوی دیگه میخوام بین دوتا سوئیچ چندتا لینک موازی بزارم.
وقتی لینکها رو وصل میکنید اولش نارنجی هستش و زمان میبره تا up بشن و این از کجا میاد؟ این مدت زمانی هستش که
STP (Spanning-tree-protocol) داره فکر میکنه که کدوم اینترفیس رو من باید up کنم و کدوم اینترفیس رو باید down کنم. رو همین حساب عملا رو همچین ساختارهایی که داریم صحبت میکنیم STP بعد از مدت زمانیکه این همگرائیش طول میکشه نتیجه میگیره که باید چطور لینکها رو توی نتورک up نگهداره یا down نگهداره. الان توی ساختار بالا (عکس سمت چپ) STP همگرا شد و تشخیص داد که این اینترفیس باید قطع باشه (اینترفیس fa0/2 از SW3) که باعث ایجاد Loop توی نتورک نشه.
من هنوز هیچکاری نکردم و کانفیگی انجام ندادم. STP وقتی روی یه دیوایس فعال باشه خود به خود اینکارو انجام میده. پس تصمیم گرفت که این لینک down باشه تا توی نتورک شما Loop ایجاد نشه. حالا توی اونیکی ساختار(دوتا سوئیچ) تصمیم گرفت دوتا لینک رو down نگه داره (fa0/2 و fa0/3 از SW4) . حالا قشنگی کار در اینه که وقتی من یه لینکِ اصلی رو قطع کنم (مثلا در ساختار سه تایی لینک بین SW1 و SW3 رو قطع میکنم) (یا توی ساختار دوتایی لینک fa0/1 بین دو سوئیچ رو قطع میکنم یعنی همون لینکی که up هستش) حالا STP باید تصمیم بگیره که الان با این شرایطی که بوجود اومده (این لینک دوباره باید سبز بشه). کدوم لینک؟ (منظورم در ساختار سه تایی هستش). Fa0/2 از SW3 که down شده بود و در ساختار دوتایی هم بین دوتا نارنجی یعنی fa0/2 و fa0/3 در SW4 یکیش باید سبز بشه. حالا جلوتر درباره مدت زمانیکه طول میکشه و چرا اینقدر طول میکشه و توی این زمان چه اتفاقاتی میفته صحبت میکنیم. این زمانِ تغییرِ رنگِ نارنجی به سبز بین 30 تا 50 ثانیه طول میکشه. صبر میکنیم تا سبز بشه. حالا در ساختار دوتایی fa0/2 در SW4 سبز شد و در ساختار 3 تایی اون لینک نارنجی هم سبز شد (fa0/2 از SW3). یعنی STP در نهایت تصمیم میگیره که این fa0/2 در SW3 رو برگردونه. اینارو برای این گفتم که چندتا نکته رو بدونید. یکی اینکه بدون هیچ کانفیگی STP داره توی نتورک من کار میکنه. نکته بعدی اینه که فرض کنید در ساختار سه تایی من دوباره SW1 رو به SW3 وصل کنم و STP دوباره مراحل همگرائیش رو طی کنه و دوباره به این نتیجه برسه که لینک fa0/2 از SW3 باید down بشه. باید ببینیم معیارهاش برای اینکار چیه؟ چرا fa0/2 از SW3 رو down میکنه و لینک دیگه ای رو down نمیکنه. اگه این لینکِ بین SW1 و SW2 1G باشه و لینک بین SW2 و SW3 10G باشه خب من ترجیح میدم 1G down بشه نه 10G . نکته بعدی اینه که وقتی fa0/2 از SW3 down میشه یعنی این لینک وجود نداره پس ترافیک SW2 و SW3 از SW1 رد میشه. خب اگه SW3 یه سوئیچ 6500 باشه و SW2 هم یه سوئیچ 6500 باشه و SW1 یه سوئیچ 2960 باشه خب SW1 نمیتونه اینهمه حجم ترافیک رو تحمل کنه و بخواد ترافیک اینارو ردوبدل کنه. باید ببینیم آیا ملاکهای انتخابش منطقی هستش؟ من بهتون میگم نیست. چون STP وظیفش این نیست که بهترین Performance رو به شما توی نتورک بده. STP وظیفش اینه که کاری کنه که توی نتورکتون Loop ایجاد نشه و ساختارهای ایجاد Loop رو بشکنه. پس عملا اگه بخوام بهش بگم که STP چرا لینکِ 10G منو down کردی میگه من وظیفم این نیست که حواسم به اینچیزا باشه من وظیفم اینه که توی نتورک Loop ایجاد نشه و من وظیفم رو انجام دادم. حالا اگه تو بعنوان ادمین نگرانی بیا کانفیگش کن. پس دقت کنید که درسته STP بصورت دیفالت کانفیگ نمیخواد ولی ما برای اینکه بتونیم بهترین Performance رو توی نتورکمون بگیریم نیازمند این هستیم که Customize کنیم. نیازمند این هستیم که بعضی اوقات زمانهای همگرائیش رو Optimize کنیم و بهینه کنیم تا بتونیم به اونچیزیکه توی نتورکمون میخوایم برسیم. حالا با این دیدی که پیدا کردیم میخوایم ببینیم اصلا STP چجوری کار میکنه و چیکار میکنه که تشخیص میده که باید اینکارا رو انجام بده و در نهایت ببینیم که چطوری میتونیم توی تصمیم گیریهاش دخالت کنیم.
حالا برمیگردیم به اسلاید 8 که ببینیم STP چجوری کار میکنه. STP به اینصورت کار میکنه که ابتدا درعکس شماره 1 ازین اسلاید (6 تا عکس در این اسلاید داریم) فرض کنید یه نتورکِ شلوغ داریم و لینکهاشو بهم وصل کردم. اول از همه STP میاد میگه که من یکی از این سوئیچهات رو باید بعنوان Root Bridge انتخاب کنم. میاد چیکار میکنه؟ مثلا فرض کردم که الان این سوئیچ شده Root Bridge در عکس شماره 2 اسلاید. چرا این شد Root Bridge (RB) و معیار انتخاب RB چی هستش و اینارو جلوتر میبینیم. فعلا فرض کردیم که این سوئیچ RB باشه. پس Step اول انتخاب RB هستش. Step دوم انتخابِ Designated port (DP) های RB هستش. یعنی تمامی اینترفیسهای RB به DP تغییر میکنن. حالا جلوتر درباره DP صحبت میکنم. فقط خواستم بهتون یه Overview یی بدم. STP وقتی شروع به همگرایی میکنه بعداز اینکه RB رو انتخاب میکنه میره دنبال دو مدل پورت بگرده (Root Port و Designated Port) . چرا میره دنبال این اینترفیسها میگرده؟ چون اینترفیس DP و RP هستن که باید Forward باشن. یعنی اینطوری بگم بهتره که اگه اینترفیسی بعنوان RP یا DP انتخاب نشه در نهایت باید Block بشه. پس در اولین Step همه اینترفیسهای RB میشن DP . چرا ؟ چون RB باید همه اینترفیسهاش فعال باشه و ترافیک اصلی میخواد از RB رد بشه. توی Step بعدی (یعنی عکس شماره 3 از اسلاید 8) میاد میگه من تا الان دوتا کار کردم. یکی اینکه RB رو انتخاب کردم و دیگه اینکه همه پورتهای RB رو کردم DP و Forward . حالا میام روی سوئیچهای غیر از RB (در عکس شماره 3) (یعنی من تا الان 4 تا سوئیچ Non RB دارم) و روی این 4 تا سوئیچ non RB اینترفیسهای مختلفی هستش. مثلا این سوئیچ SW2 روی خودش 4 تا اینترفیس داره و روی هر 4 تا اینترفیس خودش میتونه RB رو ببینه. مثلا میتونه از لینک SW2 به SW1 ببینه RB رو. یا از SW2 به SW3 به SW1 ببینه. یا از SW2 به SW5 به SW3 به SW1 ببینه RB رو. یا از SW2 به SW4 به SW5 به SW3 به SW1 ببینه. از مسیرهای مختلف میتونه به RB برسه ولی یکی ازین اینترفیسها به نسبت بقیه به RB نزدیکتره (یا میشه گفت یکی ازین مسیرها). پس توی Step سوم میاد میگه من توی سوئیچهای non RB میام از بین همه اینترفیسهام یک اینترفیس روکه به RB نزدیکتره رو بعنوان Root Port انتخاب میکنم. پس تا الان چه چیزایی انتخاب شد؟ DP های روی RB و RP های روی سوئیچهای non RB . در (عکس شماره 4 از اسلاید 8) توی Step بعدی میاد میگه حالا نتورکم رو سِگمِنت بندی میکنم. کالیژن دامِین ها (Collision Domain) رو بعنوان سگمنتها در نظر میگیره (یعنی لینک ارتباطی بین هر سوئیچ رو بعنوان سگمنت درنظر میگیره) و توی هر سگمنت دوتا سوئیچ درگیره. از بین هر دوتا سوئیچی که توی یه سگمنت هستش مثلا(سگمنت یا لینک بین SW2 و SW5) یک سوئیچ به RB نزدیکتره. اسم اون سوئیچی که به RB نزدیکتره رو بهش میگن Designated Bridge . یعنی چی نزدیکتره به RB ؟ اینرو بعدا صحبت میکنیم و درباره معیار انتخاب نزدیکترین هم بعدا صحبت میشه. در عکس 3 از اسلاید 8 فرض کردیم که کدوم سوئیچها نزدیکتر به RB هستش و به اینصورت فرض شده که بین SW2 و SW3 و SW4 و SW5 ، سوئیچ SW2 نزدیکتره به RB . و بین SW3 و SW4 و SW5 سوئیچ SW3 نزدیکتره و بین SW4 و SW5 سوئیچ SW4 نزدیکتره به RB و بین SW2 و SW5 سوئیچ SW5 نزدیکتره به RB (این انتخابها بر مبنای فرض بوده) . حالا بین مثلا (دوتا سوئیچ SW2 و SW5) قراره یک سوئیچ بعنوان Designated Bridge (DB) انتخاب بشه. فرض میکنیم بین SW2 و SW5 سوئیچ SW2 ، DB هستش. این سوئیچ نزدیکتره به RB . برای همین توی سگمنتِ (SW2 و SW5) اینترفیسِ مربوط به SW2 میشه DP . پس بهتره اینطوری بگم که توی هر سگمنت میاد انتخاب میکنه که بین دوتا سوئیچ کدوم نزدیکتره به RB . معیارش رو نگاه میکنم و فرض میکنم بین (SW4 و SW5) میگم SW4 به RB نزدیکتره. پس بین SW4 و SW5 پورت SW4 میشه DP . توی هر سگمنت میاد DP رو انتخاب میکنه. الانم مشخصه که چرا همه پورتهای RB میاد DP میشه چون توی هر سگمنتی که یکطرفش RB باشه قطعا RB به خودش ار همه نزدیکتره. پس همونطور که میبینید در عکس (شماره 5 از اسلاید 8) DP های RB در اومد و DP های سایر سوئیچها توی هر سگمنت انتخاب شد. هر اینترفیسی که توی این مراحل بعنوان DP یا RP انتخاب نشه باید Block بشه. یعنی مثل اینترفیس بین (SW2 و SW3 پورتِ SW3) یا اینترفیس بین (SW3 و SW5 پورت SW5) و یا اینترفیس بین (SW4 و SW5 پورت SW5) . اینا یعنی در نهایت STP داره ساختار نتورک من رو به این شکل تغییر میده. یعنی اون پورتهایی که بلاک شده در عمل ساختار نتورکم رو به اینصورت درآورده.
در این شکل بالا دقت کنید. دلایلی که اینترفیس باید Forward یا Block باشه رو آورده. اولی میگه که RB همه پورتهاش چون Designated میشه در نهایت Forward میشه. بعدی میگه همه سوئیچهای غیره RB (non RB) ، RP هاشون Forward میشه و همه DP های روی هر سوئیچِ غیره RB (non RB) توی هر سگمنت هم Forward میشه و مابقی اینترفیسها باید Block بشه.
تا اینجا توی اسلاید قبلی کلیت رو به اینصورت گفتم که مثلا فلان سوئیچ میشه RB یا این میشه نزدیکترین پورت و امثال این. حالا میخوایم تو این قسمت نگاه کنیم که معیارهای STP برای انتخاب RB چیه؟ وقتی میگم اون سوئیچ بشه RB چرا اون سوئیچ میشه RB ؟ STP در واقع چطوری میاد جلوی ایجاد Loop رو میگیره؟ Loop برای این ایجاد میشه چون سوئیچها از وضعیت همدیگه خبر ندارن. STP باعث میشه تا سوئیچها از حالِ هم خبر داشته باشن. اینا باهم صحبت میکنن. چطوری صحبت میکنن؟ با ارسال بسته هایی صحبت میکنن. یعنی بسته هایی رو برادکست میکنه به اسم (BPDU) Bridge Protocol Data Unit . ما دو مدل BPDU داریم : یه مدل رو میگن Hello BPDU یا Configuration BPDU یه مدل دیگه رو میگن TCN . آخرِ این مبحث TCN رو یاد میگیرید. من فعلا میخوام راجع به Hello BPDU صحبت کنم.
داخل BPDU یچیزی هستش به اسم BridgeID . یعنی میتونم بگم توی STP هر سوئیچی برای خودش یک Identifier داره که مشخص کننده اون سوئیچ هستش . این Identifier ترکیب دوتا پارامتره : STP Priority و Switch Mac Address . STP Priority مقداریه که از 0 تا 65545 تغییر میکنه. دیفالتش روی 32768 هستش. پس دقت کنید اگه من دخالت توی Configuration انجام ندم BridgeID یِ سوئیچهای من همشون Priority شون 32768 هستش با ادامه مک آدرس. حالا میخوام ببینم BridgeID یِ داخلِ BPDU چطوری میتونه توی انتخاب RB دخیل باشه.
قبل از اینکه برم این سوال رو جواب بدم این جدول بالا رو ببینید. فیلدهایی که توی Hello BPDU ارسال میشه BridgeID یِ RB هستش. BridgeID یِ اون سوئیچی هستش که داره اون BPDU رو Forward میکنه. ممکنه RB باشه و ممکنه یه سوئیچ دیگه باشه که داره BPDU رو Forward میکنه. از فیلدهای دیگه هزینه برای اینکه برسه به RB هستش. منه سوئیچ وقتی دارم BPDU رو میفرستم میگم که چقدر فاصه دارم تا RB . از فیلدهای دیگه ای که توی Hello BPDU هستش یکسری Value یِ تایمرهایی هستش که جلوتر تو بحث های همگراییِ STP باهم میبینیم.
BPDU یی که BridgeID یش کمتر باشه (یعنی BPDU یی که BridgeID یِ RB توش کمتر باشه) بهش میگن BPDU یِ بهتر. پس دقت کنید که BPDU چطوری BridgeID یش کمتر میشه ؟ یا Priority یش دیفالته ، مک آدرسشه که حرف میزنه (مک آدرسِ کمتر) و یا Priority یش رو من دستکاری میکنم. چرا ؟ چون میخوام خودم انتخاب کنم RB رو. پس دیدیم که این انتخاب بر اساس Performance نیست. اگه من 10 تا سوئیچ دارم و میدونم که دوتا ازین سوئیچهام از بقیه سوئیچها گرونتره و Performance بالاتری دارن امکان داره اونا RB نشن پس من خودم میرم دخالت میکنم و Priority اونارو پایین تر میارم.
این مثال بالا رو نگاه کنید. فرض کنید SW1 و SW2 و SW3 رو روشن کردیم. همون ابتدای STP هر سوئیچی ادعا میکنه که RB هستش. برای اثبات ادعاش BPDU ارسال میکنه و اینکارو ادامه میده تا زمانیکه RB واقعی پیدا شه. سوئیچِ SW1 ادعا میکنه RB هستش و BPDU1 رو میفرسته. ببینیم چی توی BPDU1 داره میگه. میگه Root Bridge منم و این هم BridgeID یم هستش. Sender BridgeID یعنی این BPDU رو خودم دارم ارسال میکنم و اینم BridgeID هستش و هزینه برای اینکه بخودم برسم صفره. BPDU2(SW2) و BPDU(SW3) هم همینو میگن. تا کی؟ ببینید کدوم یکی از BridgeID ها از همه کمتره. وقتی Priority هاشون یکی هستش باید مک آدرسها رو نگاه کنیم. SW1 و SW3 با f شروع میشن ولی SW2 با e شروع میشه. پس توی این نتورک BPDU یی که SW2 داره ارسال میکنه BPDU یِ بهتره. SW1 وقتی خودش BPDU میفرسته و BPDU یِ بهتر میگیره دیگه BPDU فرستادن خودش رو قطع میکنه. در عوض BPDU یِ SW2 رو Forward میکنه. SW3 وقتی BPDU میفرسته و BPDU ی بهتر میگیره اونوقت BPDU یِ خودش رو قطع میکنه و BPDU یِ سوئیچِ SW2 رو Forward میکنه. پس از یجایی به بعد وقتی RB توی نتورک مشخص میشه بقیه سوئیچها ارسال BPDU رو قطع میکنن و در عوض BPDU یِ RB رو بهمدیگه Forward میکنن. یعنی بعداز اینکه SW2 توی این انتخاب برنده میشه.
با توجه به شکل بالا الان دیگه SW2 BPDU میفرسته و همچنان میگه که RB منم و BridgeID یم اینه و خودم دارم ارسال میکنم و هزینه برای اینکه بخودم برسم صفره ولی SW1 BPDU1 رو میفرسته. توی BPDU1 چی میگه؟ میگه RB سوئیچ SW2 هستش. BridgeID یش اینه. منه SW1 دارم این BPDU رو میفرستم با این BridgeID و هزینه برای رسیدن به RB ، 19 هستش(یعنی منه SW1 برسم به RB). سوئیچِ SW3 هم همینطور. میگه RB سوئیچ SW2 هستش با این BridgeID و منه SW3 دارم اینو میفرستم و هزینه برای اینکه برسم به RB ، 19 هستش. پس دقت کنید به این ترتیب تو همون ابتدا هر 2 ثانیه یکبار ارسال BPDU انجام میشه. پس میتونم بگم توی این نتورک همون ابتدا مشخص میشه که اینوسط کی باید RB باشه. دقت کنید که انتخاب RB بصورت رقابتی هستش. یعنی اگه شما هر لحظه توی نتورکتون سوئیچی رو وارد کنید که این سوئیچ BPDU یِ بهتری بخواد توی نتورکتون ارسال کنه توی این رقابت برنده میشه و اون بعنوان RB جدید انتخاب میشه.
پس دیدیم که پارامتری که تو انتخاب RB تاثیر میزاره مقدار BridgeID یِ داخل BPDU هستش. اون مقدار، خودش تاثیر گرفته از دوتا پارامتر دیگه مثل STP Priority و Mac Address هستش. حالا جلوتر میبینیم ما برای اینکه توی انتخاب RB تاثیر بزاریم میایم با Priority بازی میکنیم و Priority رو کمتر از حدِ دیفالت میزاریم که RB ما انتخاب بشه. بعداز اینکه RB انتخاب میشه ما باید بریم سراغ انتخاب RP و DP . برای انتخاب RP و DP از مقدار Cost استفاده میشه. تو مثال قبل دیدیم Cost رو 19 میگفت. حالا چرا Cost رو 19 میگفت ؟ چون اینترفیس Speed ش 100Mb بود. اینترفیسهای 100Mb Cost شون 19 هستش. 1Gb Cost ش 4 هستش. قدیمترها چون فکر نمیکردن به سرعت 10Gb نیاز پیدا کنن Cost های 1Gb و 10Gb یکسان میشد ولی بعدا IEEE اینرو Revise (بازنگری) کرد و قسمت Revised شده Cost های جدید هستش و اینارو یاد بگیرید. تا اینجا فهمیدیم که توی STP هر اینترفیس برای خودش یه Cost داره. از طرف دیگه BPDU یی که داره ارسال میشه توی نتورک ، هر سوئیچی که این BPDU رو میگیره Cost ِ اینترفیسِ خودش رو با Cost یی که داخلِ BPDU هستش رو جمع میزنه و بعد ارسال میکنه. یعنی چی؟
به شکل بالا نگاه کنید. فرض کنید تو این شکل RB انجام شده و ما فهمیدیم که SW1 شده RB . Cost های هر اینترفیس هم مشخصه. RB میاد BPDU ارسال میکنه و میگه RB منم. خودم دارم ارسال میکنم و Cost م صفره. حالا SW2 اینوسط یه BPDU با Cost ِ صفر میگیره ولی روی اینترفیسی که Cost تِش 4 هستش. پس وقتی میخواد BPDU رو بفرسته پایین (سمت SW4) میاد میگه که RB (SW1) هستش . من دارم ارسال میکنم و Cost ِ من برای اینکه برسم به RB 4 هستش. حالا SW4 میگه من یه BPDU یی با Cost ِ 4 روی اینترفیسی گرفتم که Cost تِش 19 هستش. پس عملا Cost ِ من (یعنی SW4) تا RB 23 هستش و اگه SW4 بخواد اینو اعلام کنه با Cost ِ 23 اعلام میکنه. خب الان دقیقا مشخصه که چطوری داره انتخاب RP و DP انجام میشه. اینجارو ببینید. الان لینک بین (SW1 و SW2) SW2 روی پورت خودش BPDU یی که دریافت میکنه Cost تِش 4 هستش. حالا اگه BPDU رو از مسیرِ (SW1 به SW3 به SW5 به SW2) دریافت کنه اونوقت Cost تِش چقدره؟ (19+19+4) . حالا اگه ازین مسیر (SW1 به SW3 به SW5 به SW4 به SW2) BPDU دریافت کنه Cost تِش چقدره؟ (19+19+19+4). SW2 قطعا داره روی همه اینترفیسهاش BPDU دریافت میکنه ولی BPDU یی که روی اون پورتی که به سمت SW1 دریافت میکنه Cost تِش از همه کمتره. پس در SW2 بین سه تا اینترفیسی که داره اون اینترفیسش که بسمتِ SW1 هستش به RB نزدیکتره. خب پس RP انتخاب شد. DP چی بود؟ لینک بین SW2 و SW5 مثلا یه سگمنت داریم و میخوایم ببینیم DB کدوم سوئیچ هستش؟ سوئیچ SW2 با چه Cost یی میفرسته؟ و SW5 با چه Cost یی میفرسته؟ بررسی میکنیم. SW2 با Cost ِ 4 داره BPDU رو میفرسته و SW5 داره با Cost ِ 23 میفرسته. پس بین 4 و 23 (SW2 میشه DB) و اون پورتش به سمتِ SW5 میشه DP . پس دقت کنید که DP و RP از طریق این Cost ها انتخاب میشن.
نویسنده
مهندس جواد هدایتی
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.