با عرض سلام و وقت به خیر خدمت همه ی TheWays های عزیز مخصوصا دوستان علاقمند به سیسکو و زیرساخت
در خدمتتون هستم با سومین قسمت از بحث Spanning Tree . در مقاله های قبلی راجع به مفاهیم اولیه ی پروتکل STP و چگونگی انتخاب Root Port و Root Bridge اشنا شدیم.در این مقاله قصد داریم تا این پروتکل سنتی را کمی بهینه ترش کنیم تا Reliability و Efficiency شبکه مان بالاتر برود و شبکه مان Stable تر بشود.
سوال مهمی که مطرح میشود این است که STP تغییر توپولوژی را چطور مدیریت میکند؟چون که خود توپولوژی روشنه و داره کار میکنه این مهمه که هنگام تغییر(مثلا قطعی و وصلی کابل و …)چطور عمل میکند؟
سناریوی زیر را در نظر بگیریم:
فرض کنیم سیستم A میخواد سیستم B را Ping کند خب بدیهی است که اول باید ARP بزند تا Mac ها در دست های سوییچ های مختلف LRN شوند. حالا این که ARP از کدام مسیر به مقصد برسد به تکنولوژی حال حاضر و اینکه STP کدام پورت ها را BLK و FW کرده ارتباط مستقیم دارد با توجه به توپلوژی حال مشخص است که ARP از کدام مسیر میرود…
میدانیم که زمانی که مک ها در Mac Address Table میمانند ۳۰۰ ثانیه است که با کامند زیر هم قابل مشاهده است:
حالا فرض کنیم مانند شکل زیر کابلی قطع میشود:..
خب با قطع شدن این کابل توپولوژی تغییر میکند و به صورت مستقیم دو سوییچ این قطعی را تشخیص میدهند سوییچ A و سوییچ C چون مستقیم به آنها وصل بوده و پروتکل آن Down میشود خب تا قبل از قطعی کابل مسیر از سوییچ A بود تا سوییچ D اما بعد از قطعی کابل ۵۰ ثانیه طول میکشد تا پورتی که BLK بوده UP شود اما سوییچ های دیگر از کجا باید متوجه شوند تا توپولژی عوض شده؟ تا آنها متوجه نشوند چون قبلا MAC را در دست ها طبق توپولژی قبل LRN کردند باز با توجه به Mac Address Table شان میخواهند از همان مسیرترافیک را بفرستند اما خب به دلیل اینکه قطع شده طبق توپولوژی جدید بسته ها Drop میشود و تا Mac Address Table آپدیت نشود ترافیک بعد از ۵۰ ثانیه روی دستی که UN Block شده نمیفتد و این یعنی در بدترین شرایط ۵ دقیقه قطعی شبکه!!! و این اصلا خوشایند نیست!
اما باید بگوییم به کمک بسته های TCN این اتفاق رخ نمیدهد.حالا به چه صورت؟
TCN—->Topology Change Notification
TCA—–>Topology Change Acknowledge
TC—–>Topology Change
به این صورت که اون سوییچ هایی که مستقیم پروتوکلشان DOWN میشود به کمک STP یک سری بسته به نام TCN تولید میکنند و از طریق Root Port به سوییچ های دیگر میفرستد.خب حالا چرا Root Port ؟چون هدف اون سوییچ ها رساندن این بسته سوییچ به سوییچ به Root Bridge است و این مهم از طریق Root Port امکان پذیر است.هر سوییچی که این بسته TCN را دریافت میکند موظف است که یک بسته دیگر با نام TCA که تاییدیه دریافت است به سوییچ فرستنده برگرداند تا برسد دست Root Bridge.
خب ریشه وقتی TCN دریافت میکند (اصلا کاری ندارد از چه کسی گرفته است فقط بهش خبر میرسد که توپولژی عوض شده است) یک بسته به نام TC میسازد و به همه میفرستد.
حالا همه از ریشه پیغام TC گرفته اند که خیلی پیغام مهمی است و همه بعد از دریافت این بسته موظف هستند Age Time 300 ثانیه ای را در هر جا که باشد به ۱۵ ثانیه کاهش دهد.تا مک های قبلی Flush شود و Mac Address Table اپدیت شود.
ما گفتیم هر قطعی و وصلی را سوییچ TCN میفرستد یعنی اگر یک PC هم وصل باشد به سوییچ و قطع و وصل شود این بسته ارسال میشود و ارسال این بسته سربار پردازشی برای سوییچ ها دارد پس بهتر است کاری کنیم پورت هایی که به Device وصل هستند این بسته را نفرستند و راهش این است که Port Fast را روی اون دست ها بزنیم.
خب این اولین روش برای بهینه تر کردن STP هنگام Change Topology بود حالا میریم سراغ روش بعد:
Up link Fast
Backbone Fast
برای یادگیری این دو باید در ارتباط باقطعی و وصلی در STP با دو اصطلاح آشنا شویم:
Indirect Link Failure
Direct Link Failure
قبل از توضیح باید بدانیم که این دو اصطلاح در مقابل سوییچ خاص قرار میگیرد و کلی نیست یعنی یک ارتباط در مقایسه با یک سوییچ ممکن است Indirect باشد و همان در ارتباط با سوییچ دیگر Direct .
خب سناریوی زیر را در نظر میگیریم:
در سوییچ سمت چپ فرض کنیم کابل Direct که از قضا به Root Port سوییچ هم خورده قطع میشود خب به طور معمول ۵۰ (۲۰+۱۵+۱۵) ثانیه طول میکشد تا سوییچ پورتی که الان BLK است قطع شود خب ما با فعال کردن Uplink Fast کاری میکنیم دیگر ۲۰ ثانیه که BPDU میفرستد را در نظر نگیرد و در ۳۰ ثانیه UP شود.
این کامند فقط باید روی سوییچ های Non Root که Root Port دارند بخورد پس بهتر است برای تسریع کار توپولوژی این کامند روی تمام این سوییچ ها بخورد.
پس UPLINK Fast کامند خیلی خوبی است فقط یک مشکل دارد و اون این است که طبق صحبت قبلیمون این پورت فقط پورتی که قبلا ریشه نبوده را به علت اینکه ریشه را از دست داده سریع آپ میکند اما بحث Mac Address Table همچنان باقیست و تا Table اپدیت نشود ترافیک روی لینک جدید نمی افتد یعنی باز ۱۵ ثانیه طول میکشد LRN کند!!!اما اینطور نیست برای این که این مقدار طول نکشد سوییچی که لینکش قطع شده مقدار زیادی بسته الکی و به اصطلاح Dummy Frame تولید میکند و از طریق همان لینکی که تازه از BLK خارج شده به صورت MultiCast به سوییچ بعدی میفرستد که در این بسته Mac های اون سوییچ وجود دارد و اون سوییچ متوجه میشود و Mac Address Table خود را Update میکند.
-
پس کامند Up link Fast برای کاهش Convergence Time در زمان Direct Link Failure است.
- Backbone Fast
حالا فرض کنیم لینک روبرویی قطع شود یعنی Indirect برای سوییچ مورد نظر ما خب این جا یکم کار سخت میشه زیرا سوییچی که Direct به این لینک قطع شده وصل هست(سوییچ چپ) Root پورتش را از دست میدهد یعنی سوییچ ریشه دیگه از بالا نمیتونه BPDU بفرسته و از اونجایی که پورت بلاک فقط BPDU میگیرد و نمیتواند بفرستد پس نمیتواند از سمت مقابل BPDU بفرستد در اینصورت سوییچ B چون هیچ BPDU دریافت نمیکند فکر میکند ریشه است و شروع میکند به BPDU فرستادن به سوییچ C تا بگوید من ریشه هستم البته سوییچ C میداند ریشه اصلی سوییچ A است و گولش را نمیخورد که اصطلاحا به این BPDU های الکی یا فیک Inferior BPDU میگویند و در مقابل به BPDU که از ریشه درست ارسال میشود Superior BPDU میگویند خب با این شرایط طبق روال چون سوییچ C میبیند BPDU نمیگیرد ۲۰ ثانیه صبر میکند و پورت بلاک را UP میکند و مسیر برعکس میشود. حالا اگر ما روی سوییچ های Indirect کامند Backbone Fast هم بزنیم سوییچ C دیگر Inferior BPDU را بیشتر بهش توجه میکند و میگوید خب حتما یه اتفاقی افتاده که این سوییچ دارد Inferier میفرستد پس حتما مسیرش را به ریشه از دست داده است پس متوجه قضیه میشود و دیگر ۲۰ ثانیه را صبر نمیکند.
البته از اونجایی که این احتمال وجود دارد که خود سوییچ ریشه قطع شده باشد سوییچ C تا Inferior BPDU را دریافت میکند برای اینکه مطمئن شود خود ریشه هست یک کوئری به ریشه میفرستد و از سلامت آن با خبر میشود. حالا به این کوئری RLQ یا Root Link Query میگویند و ریشه هم Reply را با RLQR میفرستد.
پس کل این توضیحات و زدن این دو کامند برای این بود که با ۲۰ ثانیه جلو بیفتیم و لینک جای ۵۰ ثانیه در ۳۰ ثانیه UP شود.
-
پس کامند Backbone Fast برای کاهش Convergence Time در زمان INDirect Link Failure است.
خب دوستان عزیز این قسمت از بحث STP هم به پایان رسید و تلاش کردیم این پروتکل سنتی کمی بهینه تر شود.به امید خدا در مقالات بعد با پروتکل های مدرن تر که برای Loop Prevention هستند آشنا میشویم.
عالی بسیار عالی ، یعنی آدم کیف میکنه وقتی مقاله کامل ، تمیز و اینقدر پرمحتوا را میخونه ، دست شما درد نکنه و مرسی از وقتی که میزارین مهندس
خواهش میکنم مهندس جان.خیلی خوشحالم که مورد توجهتون قرار گرفته امیدوارم برای همه دوستان مفید واقع بشه.
بسیار عالی
تشکر
خواهش میکنم.