STP یا Spanning Tree Protocol در شبکه از اهمیت و کارکرد فوق‌العاده بالایی برخوردار است. سوئیچ‌های Cisco Small Business از این پروتکل در انواع مختلف خود پشتیبانی میکنند. در این مقاله نسبتا طولانی، مفهوم و عملکرد STP را شرح می‌دهیم. انجام تنظیمات STP در سوئیچ در مقالات دیگری آمده است که از لیست زیر می‌توانید به آنها دسترسی پیدا کنید:
STP پروتکلی لایه دو-ای است که وظیفه شکستن Loop در این لایه یا LAN را در تکنولوژی‌های مبتنی بر Ethernet دارد. این پروتکل به صورت پیش فرض فعال است و به خوبی وظایف خود را انجام داده و اجازه ایجاد لوپ را نمی‌دهد. البته برای کسب بالاترین میزان بازدهی و رسیدن به کمترین قطعی نیاز به بهینه سازی این پروتکل است.
بهتر است قبل از همه چیز با مفهوم Loop در لایه ۲ آشنا شویم و بدانیم که در چه زمان و شرایطی رخ میدهد.
Loop چیست؟
در هدر IP فیلدی به نام TTL یا Time To Live قرار دارد که در مبدا بر اساس نوع سیستم عامل مقداردهی میشود. به عنوان مثال در مایکروسافت ۱۲۸ و در لینوکس ۶۴ و حتی در سیسکو ۲۵۵ است. به ازای هر بار Route شدن بسته، روترها اجازه کم کردن یک واحد از آن مقدار را دارند تا Packet ها برای همیشه در دنیای WAN سرگردان نباشند. مثلا اگر سیستم عامل شما لینوکس است و به مقصدی نامعلوم ولی Routable بسته ارسال کنید بعد از عبور ۶۴، روتر بسته را Drop می کند. به زبان دیگر بعد از ۶۴ بار روت شدن Packet، و به علت صفر شدن TTL یا تمام شدن عمر Packet، بسته دور ریخته میشود.
حالا این وضعیت را در LAN در نظر بگیرید. آیا در هدر Ethernet ما TTL داریم؟! نه!
پس همیشه تمامی بسته‌های ما در LAN زنده هستند و Loop میشوند؟! باز هم نه!!
سوئیچ بسته‌های Broadcast، Multicast و Unknown Unicast را روی تمامی اینترفیس‌های با شماره VLAN ارسال کننده و البته به غیر از اینترفیس ارسال کننده Flood میکند. اینجاست که مشکل اصلی خود را نشان میدهد.
به شکل زیر دقت کنید. هیچ تنظیماتی روی سوئیچ‌ها انجام نشده و تمامی اینترفیس‌ها در VLAN 1 قرار دارند.
مرحله اول
فرض کنید که PC یک بسته DHCP Discover یا ARP Request که هر دو از نوع Broadcast است را به SW-1 ارسال کند. این سوئیچ ابتدا عمل Learning را که با خواندن مقدار Source MAC فریم است انجام میدهد که در این سناریو آدرس مک PC را روی اینترفیس Fa0/3 خود Learn میکند و آن را در MAC Address Table خود قرار میدهد. حالا سوئیچ باید عمل Forwarding را انجام دهد که این کار را با نگاه کردن فیلد Destination MAC فریم انجام میدهد. چون از نوع Broadcast یا FFFF.FFFF.FFFF است آن را روی اینترفیس‌های Fa0/1 و Fa0/2 فوروارد میکند. یا بهتر بگوییم Flood میکند.
مرحله دوم
حالا فریم روی اینترفیس Fa0/1 از SW-2 و اینترفیس Fa0/2 از SW-3 میرسد. اول برویم سراغ SW-2.
این سوئیچ بعد از Learn کردن MAC آدرس PC روی اینترفیس Fa0/1 به DST MAC بسته در هدر Ethernet نگاه میکند و چون Broadcast است فریم را روی اینترفیس Fa0/2 فوروارد می‌نماید.
سوئیچ SW-3 یک فریم از SW-1 روی اینترفیس Fa0/2 خود قبلا گرفته بود و باز بعد از Learn کردن MAC آدرس PC روی اینترفیس Fa0/2 خود و خواندن DST MAC فریم، بسته را روی Fa0/1 فوروارد میکند.
مرحله سوم
حالا یک فریم از SW-2 به اینترفیس Fa0/1 از SW-3 رسیده و یک فریم از SW-3 به اینترفیس Fa0/2 از SW-2 رسیده است. حال به سراغ SW-3 برویم.
وقتی فریم وارد اینترفیس Fa0/1 از SW-3 میشود، اول عمل Learning صورت میگیرد و SRC MAC از هدر Ethernet را می‌خواند. ولی قبلا این آدرس مک که برای PC است را روی اینترفیس Fa0/2 خود Learn کرده و سوئیچ مجبور به Flush کردن تمامی آدرس‌های MAC-ای که روی این دو اینترفیس یاد گرفته در MAC address table خود است. زیرا سوئیچ هیچ وقت آدرس مک یکسان را روی دو اینترفیس خود Learn نمیکند.
پس بعد از Learning، سوئیچ بسته را روی اینترفیس Fa0/2 خود فوروارد میکند، چون نوع بسته Broadcast بود.
دقیقا همین اتفاق در SW-2 می‌افتد و این سوئیچ مجبور به Flush کردن MAC address Table خود و فوروارد کردن بسته روی Fa0/1 است.
مرحله چهارم
SW-1 فریم یکسان را روی اینترفیس‌های Fa0/1 و Fa0/2 دریافت میکند. دقیقا همان فریمی که چند لحظه پیش خودش روی Fa0/1 و Fa0/2 فوروارد کرده بود.
SW-1 فریمی که روی اینترفیس Fa0/1 خود دریافت میکند را روی اینترفیس‌های Fa0/2 و Fa0/3 فوروارد و فریمی که روی اینترفیس Fa0/2 خود از SW-2 دریافت کرده را روی اینترفیس‌های Fa0/1 و Fa0/3 ارسال میکند.
مشکل دقیقا همین جا است! اگر دقت کنید متوجه میشوید که در اینجا به مرحله یک برگشتیم. دوباره بسته ها به SW-2 و SW-3 رسیدند و دوباره فوروارد کردن فریم‌ها و… این داستان می تواند تا ابد ادامه داشته باشد.
حالا فرض کنید از این فریم‌ها میلیون‌ها عدد داشته باشیم!! چه اتفاقی سر شبکه ما می‌آید؟ چه حجمی از پردازش می‌بایست توسط سوئیچ برای فوروارد کردن فریم‌های Broadcast یا Multicast انجام شود؟! علاوه بر این، سوئیچ می‌بایست پی در پی MAC Address Table خود را Flush کند.
در کنار این، حتی کامپیوترهای ما هم این بسته‌ها را دریافت میکنند. می‌دانیم که تمامی دستگاه‌های شبکه ملزم به باز کردن بسته‌های Broadcast و تحلیل آن در لایه‌های بالاتر هستند. بنابراین باید این بسته ها را تحلیل کنند. نه تنها کامپیوترها، بلکه سوئیچ‌ها هم باید بسته‌های Broadcast را در لایه‌های بالاتر تحلیل کنند. (ممکن است سوئیچ ARP Reply را در جواب ARP Request یک کامپیوتر بدهد. یعنی PC آدرس مک سوئیچ را ARP بزند. سوئیچ برای اینکه بداند PC به دنبال آدرس مک مثلا اینترفیس مجازی VLAN 1 آن است یا نه، بعد از باز کردن بسته در لایه دو و دیدن بسته به عنوان Broadcast مجبور به باز کردن بسته در لایه بالایی که هدر ARP است می‌باشد)
با این توضحیات اکنون می دانیم که نیاز به پروتکلی برای شکستن Loop داریم. STP و پروتکل‌هایی از این خانواده برای ما این کار را به صورت پیش فرض انجام میدهند.
مثلا در شکل بالا اگر یکی از اینترفیس‌های بین سوئیچ ها در حالت Forward قرار نمی‌گرفت و Block بود، Loop شکسته شده بود!
سوال: همیشه طراحی‌های شبکه مانند مثال‌های زیر Loop است؟!
جواب خیر است.
باید دقت کنید که اینترفیس‌های سوئیچ‌ها نمی‌توانند تمامی ترافیک‌ها را از خود عبور دهند و فقط مجوز عبور ترافیک‌های یک VLAN را دارند. (به غیر از Trunk)
به شکل زیر نگاه کنید:
در مثال‌های بالا هیچ گونه Loop-ای وجود ندارد.
یا مثلا ممکن است فقط برای یک سری VLAN لوپ داشته باشیم. مانند مثال‌های زیر که فقط برای VLAN 1 لوپ داریم.
قبل و بعد از شروع کار پروتکل STP
پروتکل STP چیست؟
پروتکل STP یا Spanning-Tree یک پروتکل لایه دو-ای برای شکستن Loop در شبکه LAN است که IEEE آن را استاندارد کرده است. به دلیل اینکه سوئیچ‌های شرکت سیسکو از VLANing پشتیبانی میکنند، سیسکو STP را به صورت به ازای هر VLAN یک STP جداگانه اجرا میکند که به آن PVST گویند.
البته این را هم اضافه کنیم امروزه به دلیل ضعف پروتکل STP که وابستگی کامل به زمان دارد از پروتکل پیشرفته‌تر آن یعنی Rapid STP استفاده میشود که Timer Base نبوده و استاندارد IEEE است. البته سیسکو از پروتکل Rapid PVST استفاده میکند.
در این مقاله قصد تشریح پروتکل STP با استاندارد ۸۰۲.۱d را داریم.
STP در تمام مدت سعی دارد که یک ارتباط لایه دو-ای پایدار را در کمترین زمان ممکن بدون Loop ایجاد کند.
STP چگونه کار میکند؟
در ابتدا وقتی سوئیچ روشن میشود، ادعای Root Bridge شدن میکند و Bridge-ID خود را در غالب بسته BPDU به بقیه اعلام می‌نماید. زمانی که یک BPDU Superior دریافت کند، یعنی سوئیچی باشد که Bridge-ID آن کمتر باشد، یا بهتر بگوییم BPDU با شرایط بهتر دریافت کند، آن سوئیچ را به عنوان Root Bridge قبول میکند و دیگر ادعای Root Bridge نمیکند.
Bridge-ID از دو قسمت Priority و Base MAC Address تشکیل شده است و هر چه مقدارش کمتر باشد بهتر است.
Priority یک عدد دو بایتی است که میتواند از صفر تا ۶۵۵۳۵ باشد که مقدار پیشفرض آن در سوییچ ها ۳۲۷۶۸ است.
Base Mac Address نیز در سوییچ های مختلف متفاوت است یعنی ممکن یک سوییچ مقدار آن را از آدرس فیزیکی یا MAC Address اینترفیس مجازی VLAN 1 بردارد که به صورت پیشفرض در سوئیچ‌ها ساخته شده است و یا ممکن است Minimum مقدار MAC-Address اینترفیس های فیزیکی خود و یا حتی Maximum آنها.
منظور از Extended System ID همان شماره VLAN ID است.
می دانیم سوییچ های سیسکو از قابلیت VLANing پشتیبانی میکنند. و می دانیم که STP به ازای هر VLAN جداگانه انجام میشود.
Per VLAN STP یعنی در سوئیچی که سه VLAN دارد سه STP Process جدا از هم کار میکند و ممکن است سه Root Bridge مختلف به ازای هر VLAN داشته باشیم.
سیسکو مقدار Extended System ID را قرار داده تا مقدار Bridge-ID های VLAN های مختلف مقدار یکسان نشود. یعنی مقدار Priority که پیشفرض ۳۲۷۶۸ است را با VLAN ID جمع میکند. مثلا در VLAN 101 مقدار Bridge-ID برای VLAN 101 میشود ۳۲۷۶۸+۱۰۱.
پس سوئیچی که کمترین مقدار Bridge-ID را دارد به عنوان سوئیچ ریشه یا Root Bridge انتخاب میشود.
بعد از انتخاب Root Bridge سوئیچ ریشه هر دو ثانیه (Default Hello Time 2s) از اینترفیس‌های خود BPDU ارسال میکند تا دیگر سوئیچ ها بر اساس آن بتوانند Role یا نقش پورت های خود را در بازی STP مشخص کنند. پایداری شبکه کاملا بستگی دارد به BPDU ای که Root Bridge ارسال میکند.
انواع Role ها در STP سنتی شامل Designated Port, Root Port و Block Port یا Non-DP می باشد.
Designated Port
این پورت وظیفه ارسال BPDU در سوئیچ ها را دارد و هر Segment حتما یک Designated Port دارد.
مثلا در مثال بالا که یک Segment داریم، یکی از اینترفیس‌ها باید DP شود. حالا کدام میشود؟! بستگی به موارد زیادی دارد.
نکته: تمامی پورت‌های سوئیچ ریشه یا Root Bridge در حالت DP هستند و سوئیچ ریشه هیچ پورت Block ای ندارد.
Root Port
پورتی است که کمترین هزینه را دارد که سوئیچ را به Root Bridge می‌رساند.
همیشه اولین کاری که سوئیچ ها بعد از انتخاب Root Bridge میکنند با توجه به مقدار Cost Root Path داخل BPDU که از پورت‌های مختلف خود دریافت میکنند، Root Port را انتخاب میکنند. یعنی اینترفیسی را RP میکنند که کمترین Cost برای رسیدن به Root Bridge را داشته باشد.
مقدار Cost وقتی زیاد میشود که BPDU وارد اینترفیس شود و کاملا با تکنولوژی اینترفیس رابطه مستقیم دارد.
مثلا اینترفیس ۱۰۰Mbps مقدار Cost آن ۱۹ و یا اینترفیس Gig مقدار Cost آن ۴ است.
نکته: با تغییر Speed در اینترفیس روی مقدار Cost تاثیر می‌گذارید. ولی تاثیری روی کارایی یا Rate اینترفیس ندارد. یعنی اگر اینترفیس ۱۰۰Mbps یا همان Fast Ethernet دارید، مقدر Cost آن ۱۹ است و اگر با دستور Speed در مد اینترفیس، مقدار Speed را ۱۰ قرار دهید، مقدار Cost آن ۱۰۰ میشود. ولی اینترفیس همچنان با Rate صد مگابیت بر ثانیه ترافیک‌ها را ارسال و دریافت میکند.
نکته: اگر گروهی از اینترفیس‌ها را با هم Etherchannel کنیم روی STP تاثیر دارد. یعنی STP آنها را به عنوان یک اینترفیس در نظر میگیرد و البته مقدار Cost آن کمتر میشود.
Non-DP یا Block Port
پورتی که Block است BPDU دریافت میکند ولی BPDU ارسال نمیکند.
نکته: اگر BPDU سوئیچ ریشه به دست آن نرسد، به علت قطعی یک لینک یا اختلال آن، سوئیچ ادعای Root Bridge میکند .
منظور از BPDU سوییچ ریشه چیست؟!
بسته BPDU را سوئیچ ریشه از روی اینترفیس‌های خود که نقش DP را دارند ارسال میکند. این بسته به سوئیچ همسایه میرسد. سوئیچ Non Root Bridge بسته BPDU را دریافت و Role اینترفیس‌های خود را بر اساس Cost مشخص میکند. حالا باید این بسته را به دیگر Non Root Bridge ها ارسال کند. یعنی در مثال زیر Switch 3 و Switch 2 باید در ابتدا از هر دو اینترفیس خود BPDU دریافت کنند تا بتوانند Role اینترفیس‌های خود را مشخص کنند. (زیرا اساس کار مقایسه است). برای این کار هر دو سوئیچ ۲ و ۳ باید به یکدیگر BPDU ارسال کنند که اطلاعات Root Bridge و اطلاعات خود را در آن قرار دهند. (منظور از در ابتدا یعنی هنوز Role اینترفیس‌ها مشخص نشده زیرا بعد از مشخص شدن Role ها پورتی که بلاک شود BPDU ارسال نمیکند)
در این سناریو Switch1 به عنوان Root Bridge انتخاب شده است. به دلیل Priority بهتر و تمامی اینترفیس‌های خود را DP میکند. Switch 2 و Switch 3 اینترفیس Gig0/0 خود را Root میکنند. زیرا وضعیت بهتری نسبت به Gig0/1 دارد و این نتیجه را بر اساس BPDU ای که از یکدیگر گرفته‌اند و اطلاعات Root Bridge در آن قرار داشت فهمیدند. چون Switch 2 از Switch 1 مقدار Priority بهتری دارد Switch 3 اینترفیس Gig0/1 خود را Block میکند. چون باید در هر Segment یک DP داشته باشیم، Switch 2 اینترفیس Gig0/1 خود را DP میکند.
حالا برویم سراغ نکته‌ای که برایش سناریو ترتیب دادیم.
الان در مثال بالا Switch1 از gig0/0 و gig 0/1 خود BPDU می‌فرستد که به شکل زیر است:
BPDU خروجی Switch 1 از اینترفیس Gig0/0
BPDU خروجی Switch 1 از اینترفیس Gig0/1
همان طور که مشخص است فقط در قسمت هدر لایه دو یعنی Ethernet تفاوت دارند. زیرا آدرس Source را از اینترفیسی که BPDU ارسال میشود برداشته شده و آدرس مقصد برای تمامی بسته BPDU ثابت یعنی Multicast است.
نکته: سوئیچ‌ها بسته‌های Multicast را Flood میکنند. ولی یک سری از آدرس‌های مالتی کست را سوئیچ‌ها باز میکنند. مانند بسته‌های برادکست. یعنی در جدول MAC-Table سوئیچ مثلا جلوی آدرس مک مالتی کست نوشته CPU. یعنی این بسته توسط CPU تحلیل شود. مانند بسته‌های BPDU که باید سوئیچ‌ها در لایه بالایی بسته را تحلیل کنند و نباید آن را Flood کند. حتی اگر دقت کنید سوئیچ‌ها بسته‌های CDP یا Cisco Discovery Protocol را دریافت و ارسال میکنند که سوئیچ‌ها باید این بسته‌ها را بعد از باز کردن هدر Ethernet آن را در لایه بالایی که هدر CDP هست تحلیل کنند. پس باید آدرس مک مقصد در هدر Ethernet را توسط CPU خود در MAC-Address Table یاد بگیرد تا Flood نکند.
Switch2 و Switch 3 این بسته BPDU را تحویل می‌گیرند و بعد از باز کردن هدر Ethernet متوجه میشوند که باید بسته در لایه بالایی تحلیل شود.
می‌دانیم سوئیچ‌ها از اینترفیس‌های DP خود BPDU ارسال میکنند. پس Switch2 باید از اینترفیس gig0/1 خود به سمت Switch 3 بسته BPDU بفرستد. ولی اینترفیس Gig0/1 از Switch 3 هیچ BPDU به سمت Switch 2 ارسال نمیکند زیرا اینترفیس‌های بلاک، BPDU ارسال نمیکنند.
برویم BPDU ای که Switch 2 به Switch 3 از اینترفیس Gig0/1 خود ارسال میکند را باز کنیم.
اگر دقت کنید این BPDU با BPDU ای که Root Bridge ارسال میکرد روی اینترفیس Gig0/0 و Gig0/1 به غیر از هدر Ethernet در هدر STP نیز تفاوت دارد.
خب در هدر Ethernet همیشه آدرس مک Source همان آدرس مک اینترفیسی است که BPDU از آن ارسال میشود و آدرس مک گیرنده همیشه ثابت است. طبیعی است که آدرس مک ارسال کننده Switch 1 و Switch 2 یکی نیست.
نکته اینجاست که در هدر STP دو قسمت مهم داریم: Root Identifier و Bridge Identifier. در فیلد Root Identifier اطلاعات Root نوشته شده است و این قسمت در هر ۳ هدر بسته BPDU ای که ما Capture کردیم و نمایش دادیم یکسان است. اطلاعات Switch 1 که Root Bridge است در آن قرار دارد. البته مقدار Root Path Cost تغییر میکند. وابسته به تکنولوژی اینترفیسی که BPDU را دریافت میکند و چون دو بسته اول را Root Bridge ارسال کرده بود مقدارش صفر ولی BPDU ای که Switch 2 به Switch 3 ارسال کرد بر اساس Cost Gig0/0 که BPDU دریافت کرد از Root Bridge مقدار ۴ را اضافه کرد ۰+۴ و به Switch 3 اعلام کرد. چون Switch 3 از هر دو اینترفیس خود BPDU میگیرد مقدار Cost هر دو را مقایسه می کند و تصمیم میگیرد Gig0/0 خود را Root Port کند. زیرا Cost کمتری روی آن دریافت کرده.
ولی در فیلد بعدی Bridge Identifier اطلاعات سوئیچی که BPDU را ارسال می کند نمایش داده میشود و به سوئیچ همسایه اعلام می شود که صد در صد وابسته به سوئیچی است که BPDU را ارسال می کند. سوئیچ مقابل از اطلاعات این فیلد استفاده هایی در انتخاب Root Port یا پورت Block میکند.
پس حالا بهتر متوجه میشوید وقتی میگوییم Root Bridge بسته BPDU ارسال میکند یعنی چی.
به این منظور نیست دیگر سوئیچ ها به یک دیگر BPDU نفرستند. چون در BPDU ای که Non Root Bridge ها به هم ارسال می کنند، اطلاعات Root Bridge در هدر STP قرار دارد و سوئیچ های Non Root Bridge بر اساس Cost ای که مبدا و معیار آن Root Bridge هست وضعیت خود را مشخص می کنند.
سناریو زیر را در نظر بگیرید. ما در این سناریو مقدار Priority در SW-1 را صفر قرار دادیم تا Root Bridge شود.
سوئیچ ۱ و ۲ بر اساس BPDU هایی که روی اینترفیس‌های خود دریافت کردند به این نتیجه رسیدند که پورت Fa0/1 خود را Root Port کنند با Cost 19. زیرا وقتی BPDU از ریشه تولید میشود و از هر دو دست خود ارسال میکند، Cost اولیه را صفر قرار میدهد. مثلا در SW-2 از دو اینترفیس خود BPDU را میگیرد. وقتی BPDU از Fa0/1 وارد میشود مقدار Cost میشود ۰+۱۹ و روی اینترفیس Fa0/2 مقدار ۰+۱۹+۱۹. پس Fa 0/1 وضع بهتری دارد. بنابرین Root Port میشود.
نکته: وقتی SW-3 می‌خواهد BPDU را به SW-2 ارسال کند، از روی پورت Fa0/2 هدر لایه دو را عوض میکند و با SRC MAC آدرس فیزیکی Fa0/2 و Dst Mac را آدرس مالتی کست Spanning-tree می‌گذارد و در هدر STP مقدار Cost را مقدار هزینه خود تا ریشه را می‌گذارد، یعنی ۱۹. وقتی SW-3 بسته را دریافت میکند بر اساس Fa0/2 نوزده واحد به Cost اضافه میکند و با BPDU که روی دست Fa0/1 دریافت کرده مقایسه می‌نماید.
حالا SW-2 و SW-3 پورت Root خود را به دست آوردند و تصمیم گرفتند که پورت Fa0/2 از SW-2 را Block کنند و Loop را از بین ببرند.
سوال: چرا در Segment X سوئیچ ۲ پورت خود را Block کرد چرا سوییچ ۳ پورت Fa0/2 خود را Block نکرد؟!
اینجا بین دو سوییچ دعوا میشود که پورت خود را Block نکنند.
په کسی برنده این دعواست؟!
- آن که Cost to Root Bridge کمتری دارد. در این سناریو مقدار هزینه برای رسیدن به ریشه در هر دو سوئیچ ۱۹ است.
- آن که Bridge-ID کمتری دارد. در این سناریو مقدار Priority هر دو سوئیچ ۳۲۷۶۸ است. ولی آدرس MAC سوئیچ SW-3 کمتر از SW-2 است. پس سوئیچ SW-2 پورت خود را Block و چون هر Segment نیاز به DP دارد پورت Fa0/2 در SW-3 نقش DP میگیرد.
در سناریو زیر با اینکه Bridge-ID سوئیچ SW-3 بهتر از SW-2 است، ولی پورت Fa0/1 خود را Block کرده. زیرا هزینه SW-3 برای رسیدن به Root Bridge برابر با ۱۹ است. ولی SW-2 با توجه به این که Uplink از نوع Gigabit Ethernet دارد هزینه ۴ برای رسیدن به Root Bridge دارد. به همین دلیل SW-3 باید اینترفیس خود را Block کند.
آیا SW-2 و SW-3 هر در دو BPDU می‌گیرند؟!
در آخرین سناریو ما، چون پورت Fa0/1 از SW-3 بلاک است و پورت Block هیچ BPDU ارسال نمی کند، پس SW-2 فقط از اینترفیس Gig0/1 خود BPDU دریافت میکند، ولی SW-3 از هر دو اینترفیس خود BPDU میگیرد.
سناریو زیر را در نظر بگیرید:
چرا SW-4 پورت Fa0/2 خود را Root Port کرده است؟!!
چرا SW-5 پورت Fa0/1 خود را Root Port کرده است؟!!
چرا در Segment X سوئیچ SW-4 پورت خود را Block کرده؟!
چرا در Segment Y سوئیچ SW-5 پورت خود را Block کرده؟!
نکته: همیشه در سناریو های بزرگ ابتدا در هر سوئیچ دنبال Root Port بگردید. زیرا در STP اگر سوئیچ حتی یک پورت داشته باشد آن پورت Root Port است.
چرا SW-4 پورت Fa0/2 خود را Root Port کرده است؟!!
جواب: این سوئیچ مقدار Cost ای که از دست های Fa0/1 و Fa0/2 دریافت میکند برای رسیدن به Root Bridge برابر با ۳۸ است .
دوباره دعوا شده ولی اینبار بین دو سوئیچ نه! بین دو پورت از یک سوئیچ برای Root Port شدن
برنده دعوا کیست؟!
- Cost: خب مقدار Cost در هر دو پورت ۳ است. اصلا چون برابر بود دعوا شده است
- Sender Bridge-ID
BPDU ای که روی دست Fa0/1 و Fa0/2 دریافت میکند سوئیچ SW-4 یکی نیست، روی دست Fa0/1 سوئیچ SW-2 و روی دست Fa0/2 سوئیچ SW-3 بسته BPDU دریافت میکند.
یعنی Sender BPDU روی Fa0/1 سوئیچ SW-2 است ولی Sender BPDU روی Fa0/2 سوئیچ SW-3 است.
حالا SW-4 نگاه میکند به Sender Bridge-ID ها که مشخص است Priority سوئیچ SW-2 بهتر از SW-3 است. پس SW-4 پورت Fa0/1 خود را Root Port میکند.
چرا SW-5 پورت Fa0/1 خود را Root Port کرده است؟!!
جواب: در این سوئیچ هم دعوا شده بین دو پورت Fa0/1 و Fa0/2
برنده دعوا کیست؟!
- Cost: خب مقدار Cost در هر دو پورت ۵۷ است. پس این مورد کمکی به ما نکرد.
- Sender Bridge-ID: روی هر دو پورت Sender BPDU سوئیچ SW-4 است. پس این مورد هم کمکی به ما نمیکند تا مقایسه کنیم.
- Sender Port-Priority: هر پورت در STP دارای یک Priority است که عددی بین ۰ تا ۲۲۴ است که می تواند ضریب ۱۶ یا ۳۲ باشد و هر چه کمتر باشد بهتر است. مقدار پیش فرض آن ۱۲۸ است. هر سوئیچ در هدر STP خود به سوییچ دیگر ارسال میکند. دقت داشته باشید که Port-Priority در یک Segment معنی دارد. یعنی اگر ما روی Fa0/4 از SW-4 مقدار Port-Priority را به ۶۴ تغییر دهیم با دستور زیر، در SW-5 اینترفیس Fa0/2 وضعیت بهتری نسبت به Fa0/1 دارد و Root Port می شود. در سناریو ما مقدار Port-Priority را در SW-4 تغییر نداده ایم پس این مورد نیز کمکی به ما نمی کند.
- Interface Num: صد در صد در مورد چهارم سوئیچ می تواند Root Port را مشخص کند. بین اینترفیس Fa0/1 و Fa0/2 شماره یا ID کدام اینترفیس کمتر است؟ بله اینترفیس Fa0/1. چون در STP مقدار کمتر بهتر است مانند Priority پس اینترفیس Fa0/1 را Root Port میکند.
برویم سراغ سوال بعدی.
چرا در Segment X سوئیچ SW-4 پورت خود را Block کرده؟! زیرا Cost to Root Bridge در SW-3 مقدارش کمتر است.
چرا در Segment Y سوئیچ SW-5 پورت خود را Block کرده؟! زیرا Cost to Root Bridge در SW-4 مقدارش کمتر است.
در قسمت اول مقاله نحوه کار پروتکل STP در شبکه های Ethernet و همچنین چگونگی انتخاب سوئیچ ریشه یا Root Bridge آشنا شدیم. البته دانستیم که سوئیچ چگونه نقش یا Role های اینترفیس های خود را مشخص می کند.
اما در این اینجا می خواهیم موردی را بررسی کنیم که از اهمیت بالای در STP 802.1d برخوردار است که آن مدت زمان Convergence شدن STP است.
انواع وضعیت یا State ها
Block
پورتی که سوئیچ بعد از دریافت BPDU از همسایه های خود تصمیم به بلاک کردن آن گرفته و هیچ Frame ای از این پورت ارسال و یا دریافت نمی شود. البته باید ذکر کرد که سوئیچ روی این اینترفیس از همسایگان خود BPDU دریافت می کند، ولی ارسال BPDU روی این اینترفیس ندارد.
Disable
پورتی که به صورت دستی در حالت Shutdown می باشد و هیج تاثیری روی STP ندارد.
Listening
زمانی که پورت در وضعیت Listening قرار می گیرد بوسیله BPDU وضعیت سوئیچ Root Bridge و همچنین نقش خود را تعیین میکند. روی این اینترفیس هیچ گونه MAC-Address ای Learn نمیشود و به صورت موقت اینترفیس در این حالت می باشد تا نقش خود را در STP مشخص کند. تنها Frame های از جنس BPDU را ارسال میکند و به صورت پیش فرض مدت زمان آن ۱۵ ثانیه است.
Learning
این وضعیت نیز موقت و گذرا است و زمان آن به صورت پیش فرض ۱۵ ثانیه است. در این وضعیت سوئیچ روی آن اینترفیس شروع به یاد گرفتن یا Learn کردن MAC-Address میکند و Frame های از جنس BPDU را میتواند ارسال کند. ولی همچنان فریم های هاست ها را ارسال نمیکند.
Forwarding
در این وضعیت سوئیچ بعد از مشخص کردن نقش اینترفیس های خود تصمیم به Forward کردن اینترفیس کرده است و فقط در این حالت Frame های یوزر ها را Forward میکند.
همان طور که میبینید حداقل باید ۳۰ ثانیه زمان بگذرد تا یک اینترفیس وضعیت خود را به حالت فوروارد تغییر دهد و بتواند Frame ها را ارسال و دریافت کند. این مدت زمانی بسیار زیادی است در شبکه که اصلا مناسب نیست.
به این مدت زمان ۳۰ ثانیه یعنی ۱۵ ثانیه Listening و ۱۵ ثانیه Learning به اصطلاح Forwarding Delay می گویند.
سوئیچ هیچ وقت نمی تواند از این ۳۰ ثانیه صرف نظر کند. زیرا تصمیمات STP خود را در این مدت زمان میگیرد. اگر قرار باشد پورتی را بلاک کند در این ۳۰ ثانیه با توجه به BPDU های دریافتی آن پورت را بلاک میکند تا Loop شکسته شود.
برای بهبود این وضع می توانیم کاری کنیم.
سوال: آیا مراحل Learning و Listening برای جلوگیری از Loop می باشد؟!! بله
آیا روتر یا حتی کامپیوترها در حالت عادی میتوانند شبکه را در حالت Loop قرار دهند؟!! خیر. مگر اینکه روتر یا کامپیوتر دو اینترفیس داشته و این دو را در حالت Bridge قرار دهد و هر دو را به سوییچ متصل کند. البته خیلی به ندرت از این قبیل کارها انجام میشود.
پس روی اینترفیس هایی که به سمت کامپیوتر یا روتر می باشد نیازی نیست این ۳۰ ثانیه معطلی برای Forward شدن را داشته باشیم. یعنی می توانیم از این ۳۰ ثانیه فقط در این اینترفیس ها صرف نظر کرد. به عبارتی پورت از حالت Disable، مستقیم به وضعیت Forward برود.
این کار را با Portfast انجام میدهند.
با این کار تا حدی وضعیت STP را بهبود دادیم.
Topology Change
توضیح این بخش را با طرح یک سوال آغاز می‌کنیم: اگر سوئیچ Root Bridge دچار اختلال شود و یا لینک بین یک سوئیچ تا Root Bridge قطع شود و اصلا یک لینک direct و یا indirect قطع شود، در STP چه اتفاقی می افتد؟؟!!!
به صورت عادی هر سوئیچ هر دو ثانیه باید حداقل روی یکی از اینترفیس خود BPDU دریافت کند. حالا می تواند مستقیم از Root Bridge باشد و یا سوئیچ های دیگر وضعیت Root Bridge را در BPDU خود اعلام کنند.
Topology Change Notification
هر سوئیچ در بازی STP اگر هر تغییری روی اینترفیس خود احساس کند، یعنی اینترفیس خاموش شود یا اینترفیس جدیدی UP شود، STP را ازحالت پایداری به حالت ناپایداری تغییر می دهد.
حالت پایداری یعنی تمامی سوئیچ‌ها Root Bridge خود را می شناسند و حداقل یک BPDU دریافت می کنند و تمامی Role ها و وضعیت اینترفیس های خود را می دانند.
این حالت می تواند با قطع شدن یک لینک یا از دست دادن Root Bridge به وضعیت ناپایداری تغییر کند.
وقتی هر یک از اتفاقات بالا رخ دهد ابتدا سوئیچ یک بسته BPDU که معروف به BPDU TCN است فقط روی Root Port خود به همسایه اعلام میکند که این بسته در هدر Spanning-tree خود فقط مقدار BPDU Type را Topology change notification قرار می دهد. یعنی این BPDU از نوع BPDU Configuration نمی باشد.
سپس همسایه به سوئیچی که این بسته را ارسال کرده BPDU TCA می دهد که همان Acknowledgment است و در هدر STP در فیلد BPDU Flags قسمت Topology Change Acknowledgment را Set میکند. اینجا به او اعلام میکند که TCN تو را دریافت کردم سپس همین سوئیچ دوباره BPDU TCN از روی Root Port خود ارسال می کند. این کار تا انجا ادامه دارد که این بسته به Root Bridge برسد.
سوئیچ ریشه یا Root با دیدن BPDU TCN متوجه تغییر در Topology می شود و بسته BPDU TC که در هدر STP در قسمت BPDU Flags مقدار Topology Change را Set میکند و از تمام اینترفیس های خود که در وضعیت DP هستند ارسال می کند تا تمامی سوئیچ ها این BPDU را دریافت کنند و دیگر سوئیچ ها با گرفتن این BPDU مدت زمان Aging-Time خود یا همان زمان آپدیت Mac-Table خود را از ۳۰۰ ثانیه به ۱۵ ثانیه کاهش می دهند.
نکته: سوئیچ ریشه یا Root بسته BPDU TC را به مدت ۱۵+۲۰ یعنی ۳۵ ثانیه ارسال می کند. (۲۰ ثانیه Max-Age و ۱۵ ثانیه نصف Forwarding Delay است)
حالا متوجه شدیم که با هر تغییری روی اینترفیس ها روند بالا اتفاق می افتد و در نهایت Aging-Time به ۱۵ ثانیه کاهش می یابد و بعد از ۳۵ ثانیه دوباره به ۳۰۰ تغییر می کند.
این اتفاق بالا خیلی خوب است ولی با هر قعطی باید این اتفاق بیفتد؟؟!!
مثلا کامپیوتری به سوئیچ متصل است که مشکل کانکتوری دارد و پشت سر هم قطع و وصل می شود و اگر سوئیچ بخواهد به ازای هر بار این اتفاق BPDU TCN ارسال کند، باید برای همیشه تمامی سوئیچ ها Aging-time معادل ۱۵ثانیه داشته باشند که اصلا مناسب نیست. برای همین دلیل سوئیچ روی اینترفیس های که Portfast می باشند و یا Type آنها Shared است با تغییر روی این اینترفیس ها BPDU TCN ارسال نمی کند.
پس حالا برای استفاده از Portfast دو دلیل داریم که مطرح شد.
انواع اینترفیس ها در STP
P2P و Shared
سوئیچ با Negotiate کردن روی Duplex اینترفیس متوجه این موضوع میشود.
یعنی اگر اینترفیس سوئیچ به یک دستگاهی متصل باشد که Full Duplex است، آن اینترفیس را P2P می داند. مانند سوئیچ به کامپیوتر یا سوئیچ به سوئیچ، یا حتی سوئیچ به روتر.
ولی وقتی اینترفیس سوئیچ به یک دستگاه Half Duplex متصل باشد Type اینترفیس را Shared در نظر میگیرد.
قبول دارید که اکنون حالتی از STP را داریم که اوضاع بهتری دارد؟ زیرا با تغییرات روی اینترفیس های Portfast وضیعت را به عنوان ناپایدار نمی داند که بخواهد BPDU TCN ارسال کند.
ولی هنوز در STP مشکل داریم
به مثال زیر دقت کنید: تمامی اینترفیس ها در VLAN 1 می باشد. یعنی فقط STP را برای یک VLAN داریم.
در مثال بالا SW-1 به دلیل Priority بهتر Root Bridge شده است. همچنین اینترفیس Fa0/2 از SW-3 به علت اینکه Priority بدتری نسبت به SW-2 دارد، SW-3 اینترفیس Fa0/2 خود را بلاک و Fa0/2 از SW-2 نقش DP و وضعیت Forward را دارد.
همچنین در سوئیچ‌های ۲ و ۳ روی اینترفیس های Fa0/3 خود Portfast را فعال کرده ایم به دلایلی که بالا مطرح کردیم.
در این هنگام STP در حالت پایدار است و PC-1 و PC-2 می توانند با یکدیگر ارتباط داشته باشند. زیرا آدرس های مک هر دو PC در سوئیچ ها Learn شده و ترافیک بین این دو PC با توجه به شبکه ما از SW-1 عبور میکند.
حالا فرض کنید که اینترفیس Fa0/1 از SW-3 یا اینترفیس Fa0/1 از SW-1 دچار ایراد شود.
در این هنگام هر دو PC نمی توانند با یکدیگر ارتباط داشته باشند. زیرا ترافیک های این دو PC از SW-1 عبور میکرد و اینترفیس Fa0/2 از SW-3 در وضعیت بلاک قرار داشته است.
SW-3 با از دست دادن روت پورت خود (Fa0/1) سریعا Fa0/2 خود را که نقش یا Role آن بلاک یا (Alternate) بود را Root Port میکند. (سوئیچ باید Root Port داشته باشد حتی اگر یک اینترفیس داشته باشد) (اگر چندین اینترفیس داشته باشد آن اینترفیسی که هزینه کمتری دارد برای رسیدن به Root Bridge را روت پورت میکند) وبعد از Root Port کردن Fa0/2، فریم BPDU TCN را از روی همان اینترفیس ارسال میکند تا تغییرات Topology را به دیگر سوئیچ ها مخصوصا Root Bridge اعلام کند که در نهایت باعث می شود Root Bridge بسته BPDU TC ارسال کند که Aging-Time همه سوئیچ ها ۱۵ ثانیه شود. بعد از این که Fa0/2 نقش Root Port را می گیرد وضعیت آن به Listening و سپس Learning تغییر می کند مراحل Listening و Learning جمعا ۳۰ ثانیه طول میکشد و بعد از ۳۰ ثانیه اینترفیس در وضعیت Forward قرار میگیرد. یعنی ۳۰ ثانیه دو PC نمی توانند ترافیک برای هم ارسال کنند و حتی اگر SW-1 به روتری متصل باشد و آن روتر به اینترنت وصل باشد، PC-2 تا ۳۰ ثانیه نمی تواند به اینترنت وصل شود تا زمانی که اینترفیس Fa0/2 فوروارد شود.
نکته: دقت داشته باشید که در این هنگام SW-1 یا ریشه با دیدن BPDU TCN فریم BPDU TC را ارسال کرده و سوئیچ ها Aging-Time خود را به ۱۵ ثانیه کاهش داده اند.
به هدف کاهش دادن آن ۳۰ ثانیه در SW-3 برای فوروارد کردن Fa0/2 خود بعد از دست دادن Root Port خود سیسکو از Uplink Fast استفاده میکنند. یعنی در سوئیچ های لایه Access و با فعال سازی آن SW-3 با از دست دادن Root Port خود اینترفیس Fa0/2 خود را بلافاصله Root Port و فوروارد می کند (یک جور بکاپ برای Root Port) و مراحل Listening و Learning را سپری نمیکنند.
حتی سوئیچ های سیسکو این قابلیت را دارند که Frame هایی تولید کنند که آدرس Source آنها آدرس هایی باشد که قبلا MAC-Table خود Learn کرده اند. مثلا در مثال بالا خود SW-3 یک فریم با Source MAC-address کامپیوتر ۲ که BBBB.BBBB.BBBB است و با آدرس مک مقصد مالتی کست تولید می کند و به SW-2 می فرستد تا SW-2 که تا قبل از قعطی آدرس مک PC-2 را از اینترفیس Fa0/1 خود Learn کرده بود را در MAC-Table خود آپدیت کرده و از اینترفیس Fa0/2 یاد بگیرد و همچنین SW-1 آدرس مک PC-2 را از Fa0/2 یاد بگیرد.
نکته: Uplink Fast را روی سوئیچ های Access فعال کنید زیرا بعد از اجرا آن روی سوئیچ به صورت اتوماتیک Priority سوئیچ به ۴۹۱۵۲ تغییر کرده و به مقدار Cost اینترفیس ها ۳۰۰۰ واحد اضافه میکند.
نکته: دقت داشته باشید با قعطی اینترفیس Fa0/1 از SW-3 باز این سوئیچ BPDU روی Fa0/2 خود دریافت می کرد و ادعای Root Bridge شدن نکرد.
حال به به مثال زیر دقت کنید که شرایطی مانند مثال بالا را دارد.
تمامی اینترفیس ها در VLAN 1 می باشند. یعنی فقط STP را برای یک VLAN داریم.
حالا فرض کنید اینترفیس Fa0/2 از SW-1 یا اینترفیس Fa0/1 از SW-2 دچار ایراد شود.
این بار قضیه فرق دارد. زیرا تا قبل از قعطی SW-3 از اینترفیس Fa0/2 خود هیچ BPDU ای به SW-2 ارسال نمی کرد چون پورت بلاک BPDU ارسال نمی کند.
این بار هم PC-1 و PC-2 نمی توانند با یکدیگر ارتباط داشته باشند و PC-1 دسترسی به اینترنت را از دست داده زیرا هر دو این ترافیک ها از اینترفیس Fa0/2 از SW-2 به SW-1 ارسال میشد که الان قطع می باشد.
این قطعی ۵۰ ثانیه طول میکشد!!
چرا؟؟؟ چه فرقی دارد با قعطی قبلی؟؟!!
در این مدل قعطی ها SW-2 هیچ BPDU ای دریافت نمی کند و بلافاصله ادعای Root Bridge شدن به SW-3 میکند. حالا SW-3 بعد از ۲۰ ثانیه (Max-Age) یا بهتر بگوییم بعد دریافت ۱۰ پیغام ادعای روت شدن SW-3 پیغام RLQ یا Root Link Query ارسال میکند تا از وضعیت Root Bridge اصلی یعنی SW-1 با خبر می شود.
SW-3 که همچنان دارد BPDU بهتری از SW-1 دریافت می کند و متوجه ادعای کذب SW-2 میشود اینترفیس Fa0/2 خود را از وضعیت بلاک به وضعیت Listening و Learning و سپس Forward قرار میدهد تا SW-2 بتواند BPDU های SW-1 را دریافت کند و بعد از گذشت ۳۰ ثانیه SW-2 اینترفیس Fa0/2 خود را Root Port میکند.
جمع این قعطی ۵۰ ثانیه است. یعنی SW-2 ادعای Root Bridge میکند و وقتی SW-3 ادعای آن را دریافت میکند بعد از ۲۰ ثانیه به حرف آن گوش می دهد و با RLQ وضعیت Root Bridge را چک میکند و بعد از اطمینان از زنده بودن Root Bridge پورت خود را از حالت Block به وضعیت Listening و Learning می برد.
در سیسکو این زمان را با فعال سازی Backbone Fast روی تمام سوئیچ ها تا ۳۰ ثانیه میتوان کاهش داد. با فعال سازی آن مرحله Max-Age را در SW-3 نظر نمیگیرد. یعنی با اولین ادعای SW-2 برای Root Bridge شدن SW-3 بلافاصله اینترفیس Fa0/2 خود را از بلاک در می آورد و به وضعیت Listening و Learning قرار می دهد تا SW-2 از وجود Root Bridge واقعی با خبر شود و سپس اینترفیس Fa0/2 از SW-2 فوروارد میشود و ترافیک های PC-1 توسط SW-3 به SW-1 میرسد.
Backbone Fast با حذف Max-Age مدت زمان Convergence شدن شبکه را تا ۳۰ ثانیه کاهش می دهد.
نکته: در اینجا نیز سوئیچ ها BPDU TCN ارسال می کنند از روی Root Port خود و سوئیچ ریشه با دیدن BPDU TCN فریم BPDU TC می فرستد تا Aging-Time را به ۱۵ ثانیه برساند. با هر تغییر این پیغام BPDU TC باید در شبکه پخش شود که این کار را Root Bridge با گرفتن BPDU TCN از دیگر سوئیچ ها انجام میدهد.
به طور کلی می توان بزرگترین ضعف پروتکل STP 802.1d را وابستگی به زمان دانست که البته با استفاده از ابزار هایی مانند Portfast, Uplinkfast و BackboneFast در سیسکو می توان این وابستگی را کم کرد.
دلیل این که امروزه از پروتکل Rapid STP استفاده می کنند به دلیل اینکه این پروتکل وابستگی به زمان ندارد.
PVST
PVST یا همان Per VLAN STP است. یعنی ما بازی STP را برای هر VLAN کاملا جدا از هم داریم یا بهتر بگیم به ازای هر VLAN یک STP داریم.
به شکل زیر دقت کنید:
در مثال بالا ما ۳ عدد سوئیچ داریم که روی هر سه سوئیچ VLAN های یک تا سه ساخته شده است و لینک بین تمامی سوئیچ ها Trunk می باشد.
در این مثال سه Process پروتکل STP در هر سوئیچ جدا از هم کار می کند.
مثلا ممکن است برای VLAN با شماره یک SW-3 سوئیچ ریشه یا Root Bridge باشد و برای VLAN با شماره دو ، سوئیچ یک Root Bridge باشد و برای VLAN با شماره سه SW-2 سوئیچ ریشه باشد.
یا حتی برای تمامی VLAN ها یک سوئیچ Root Bridge باشد.
به مثال زیر دقت کنید:
لازم به ذکر است در مثال بالا چون لینک Trunk بین SW-1 و SW-3 فقط ترافیک های VLAN یک را عبور میدهد پس برای VLAN های ۲ و ۳ هیچ Loop ای شبکه را (فعلا) تهدید نمی کند. حتی می توان برای جلوگیری از BPDU های اضافی این VLAN ها در شبکه STP را برای آن ها در تمامی سوئیچ ها غیر فعال کرد
دقت داشته باشید که اگر PVST داریم هر سوئیچ به ازای VLAN ای که در Database خود دارد و اگر Active باشد و اینترفیسی در آن VLAN عضو داشته باشد باید یا خودش برای آن VLAN سوئیچ ریشه باشد یا برای آن VLAN یک Root Bridge داشته باشد .
سوئیچی را تصور کنید که سه VLAN فعال دارد و به ازای هر سه VLAN ، این سوئیچ Root Bridge است. این سوئیچ باید هر دو ثانیه از اینترفیس های Trunk خود (Hello Time Default 2s) به ازای هر VLAN جدا از هم BPDU ارسال کند.
در PVST نقش یا Role های اینترفیس چگونه است؟!
در PVST اینترفیس Trunk چون تمامی VLAN ها را از خود عبور می دهد می تواند به ازای هر VLAN یک نقش داشته باشد مثلا برای VLAN 1 نقش اینترفیس Root Port باشد. ولی همان اینترفیس برای VLAN 2 بلاک و برای VLAN 3 پورت Designated باشد.
دقت داشته باشید که اگر از PVST استفاده می کنید تمامی مباحث STP مانند قبل است. مانند نحوه انتخاب Root Bridge یا چگونگی مشخص شدن نقش های اینترفیس ها و یا حتی Time ها.
می توان گفت مانند STP در PVST ما وضعیت های Disable, Block, Listening, Learning و Forwarding داریم ولی به ازای هر VLAN جدا از هم.
نکته: Potfast, Uplinkfast و Backbonefast نیز در PVST عینا مانند STP است.
به طور کلی PVST تماما از STP اطاعت میکند ولی به ازای هر VLAN یک STP داریم.
به شکل زیر خوب دقت کنید:
هر سه سوئیچ یک Base MAC-address دارند که دربسته های BPDU خود که برای هر سه VLAN یک تا سه می سازد از آن استفاده میکند.
یعنی سوئیچ ها برای هر VLAN نیاز به BPDU جداگانه دارند که Bridge-ID خود را به بقیه اعلام کند. می دانیم که Bridge-ID از دو قسمت Priority و MAC-Address تشکیل شده است و سوئیچ ها در BPDU های تمامی VLAN خود از یک آدرس مک یعنی Base MAC-Address استفاده می کنند که می تواند بزرگترین آدرس مک اینترفیس های فیزیکی باشد یا آدرس مک اینترفیس VLAN یک.
سیسکو برای اینکه مقدار Priority برای تمامی VLAN ها یکی و یکسان نشود مقدار Priority را که ادمین مشخص می کند را با مقدار sys-id-ext جمع میکند و آن را در بسته های BPDU خود تبلیغ میکند که این مقدار sys-id-ext دقیقا از روی شماره VLAN برداشته شده است.
یعنی اگر ادمین مقدار Priority را برای VLAN بیست، ۴۰۹۶ در نظر گرفته باشد در نهایت مقدار Priority برای آن VLAN عدد ۴۰۹۶+۲۰ یعنی ۴۱۱۶ میشود.
هدف از این کار این است که سیسکو قصد داشته مقدار نهایی Priority ها برای VLAN های مختلف حتی با در نظر گرفتن Priority برابر برای تمامی VLAN ها ، یکسان نشود.
بر این اساس و با توجه به مقدار اولیه Priority برای هر VLAN در سه سوئیچ که ادمین در مثال بالا در نظر گرفته می توان Bridge-ID هر سه سوئیچ را اینگونه در نظر گرفت:
برای SW-1
BID For VLAN 1 = (1 , 0050.0f32.d4ee)
BID For VLAN 2 = (4098 , 0050.0f32.d4ee)
BID For VLAN 3 = (8192 , 0050.0f32.d4ee)
که عدد اول در پرانتز مقدار نهایی Priority و عدد دوم Base MAC-Address می باشد که برای همه VLAN ها یکی است.
برای SW-2
BID For VLAN 1 = (8193 , 0002.1687.59e0)
BID For VLAN 2 = (2 , 0002.1687.59e0)
BID For VLAN 3 = (4099 , 0002.1687.59e0)
و برای SW-3
BID For VLAN 1 = (4097 , 00e0.a3aa.5aeb)
BID For VLAN 2 = (8194 , 00e0.a3aa.5aeb)
BID For VLAN 3 = (3, 00e0.a3aa.5aeb)
نکته: می دانیم که تاثیر Priority در انتخاب Root Bridge بیشتر از MAC-Address است زیرا در بیت پر ارزش تر قرار دارد.
بر این اساس میتوان فهمید که SW-1 برای VLAN یک و SW-2 برای VLAN دو، و SW-3 برای VLAN سه سوئیچ ریشه یا Root Bridge شده اند یعنی سه سوئیچ و سه Root Bridge .
حالا برویم سر Role یا نقش اینترفیس ها در PVST که هر اینترفیس سه نقش (به ازای هر VLAN)
نقش اینترفیس ها مانند STP مشخص می شود یعنی Root Port, Designated Port و Alternate Port) Block)
اول برویم سراغ Root Port ها
بهتر است هر VLAN را جداگانه بررسی کرد. ابتدا VLAN 1
برای VLAN یک، SW-1 سوئیچ ریشه یا Root Bridge است. پس تمامی اینترفیس های SW-1 برای VLAN یک در نقش DP را دارند.
علت اینکه SW-2 اینترفیس Fa0/2 خود را بلاک کرد نه SW-2، این بود که Priority برای VLAN 1 در SW-3 بهتر از SW-3 بود.
برویم سراغ VLAN دو.
برای این VLAN سوییچ دو Root Bridge است به دلیل Bridge-ID بهتر پس داریم:
دلیل اینکه SW-3 اینترفیس Fa0/1 خود را بلاک کرده این است که Priority برای VLAN دو در سوئیچ یک بهتر از SW-3 است.
برای این VLAN سوئیچ شماره سه Root Bridge می باشد. در نهایت برای VLAN 3 داریم:
دلیل اینکه SW-1 اینترفیس Fa0/1 خود را بلاک کرده این است که Priority سوئیچ دو بهتر از SW-1 است.
همان طور که مشاهده کردید هر اینترفیس فقط یک نقش ندارد و به ازای VLAN های مختلف نقش های مختلفی دارد. مثلا اینترفیس Fa0/1 از SW-1 برای VLAN یک DP است. برای VLAN دو ، Root Port است. و برای VLAN سه ، Block است.
نکته: به دلیل اینکه اینترفیس ها یک نقش مشترک در سه VLAN را ندارند، نرم افزار Cisco Packet Tracer تمامی اینترفیس های را با LED سبز نشان داده است.
اگر یک اینترفیس برای تمامی VLAN ها بلاک باشد، LED اینترفیس نارنجی است و این اتفاق معمولا زمانی رخ میدهد که یک سوئیچ به ازای تمامی VLAN ها Root Bridge باشد، نه مثل مثال ما که به ازای هر VLAN یک Root Bridge جدا داشته باشیم.
شاید یکی از زیباترین و به صرفه ترین استفاده های PVST در سیسکو Load sharing در کناره HA یا همان High availability است.
منظور از Load Sharing همان پخش کردن ترافیک است تا از ماکسیموم ظرفیت شبکه استفاده کامل کنیم.
به سناریو زیر دقت کنید:
در مثال بالا MLS-1 را به برای VLAN های یک و دو سوئیچ ریشه قرار دادیم. این سوئیچ برای VLAN های سه و چهار Root Secondary شده است.
همان طور که مشاهده می کنید MLS-1 برای VLAN های ۱, ۲ و MLS-2 برای VLAN های سه و چهار Root Bridge هستند و هر دو Backup همدیگر برای Root Bridge شدن هستند.
نکته: با این کانفیک MLS-1 و MLS-2 هیچ پورت بلاکی برای هیچ VLAN ای ندارند زیرا هر دو سوئیچ Bridge-ID بهتری نسبت به SW-1 برای تمامی VLAN ها دارند.
همان طور که مشاهده می کنید نقش اینترفیس های Fa0/1 و Fa0/2 در SW-1 برای VLAN های یک و دو دقیقا مانند یکدیگر است. یعنی اینترفیس Fa0/1 روت پورت و Fa0/2 بلاک شده است. دلیل این موضوع کاملا مشخص است زیرا Root Bridge برای این دو VLAN یک سوئیچ یعنی MLS-1 است.
همان طور که مشاهده می کنید نقش اینترفیس های Fa0/1 و Fa0/2 در SW-1 برای VLAN های سه و چهار دقیقا مانند یکدیگر است. یعنی اینترفیس Fa0/2 روت پورت و Fa0/1 بلاک شده است. دلیل این موضوع نیز کاملا واضح است، زیرا Root Bridge برای این دو VLAN یک سوئیچ یعنی MLS-2 است.
یعنی می توان نتیجه گرفت که ترافیک PC های داخل VLAN یک و دو از اینترفیس Fa0/1 در SW-1 ارسال می شود و ترافیک اینترفیس های PC های VLAN سه و چهار از اینترفیس Fa0/2 در SW-1 ارسال می شود و ما از ظرفیت شبکه کامل بهره بردیم.
اگر در این سناریو برای تمامی VLAN ها یک سوئیچ لایه Distribution سوئیچ ریشه یا Root Bridge میشد تمامی ترافیک ها فقط از یک لینک در SW-1 ارسال می شد که آن وقت هیچگونه Load Sharing ای در کار نبود.
نکته: شما می توانید در این سناریو با زدن دستور Portfast در SW-1 بر روی اینترفیس های Fa0/3 تا Fa0/6 به هر چه بهتر کار کردن PVST کمک کنید. همچنین می توانید دستور Uplinkfast را در SW-1 بزنید تا در صورت قطع شدن هر یک از اینترفیس های Fa0/1 یا Fa0/2 سوئیچ SW-1 سریعا Root Port جدید خود را برای آن VLAN فوروارد یا FWD کند.
