سرعت در spanning-tree

توسط

5 مرداد 1399

2225

گفتیم در صورت بروز هر گونه تغییر در درخت، محاسبات بایستی مجدد انجام شود، که این امر بعضا باعث بروز تاخیرهای 30 تا 50 ثانیه‌ای برای محاسبه و ایجاد مجدد درخت زمان خواهد برد. می‌خواهیم سرعت در spanning-tree را بررسی کنیم.

اختلال 50 ثانیه‌ای شاید در بسیاری از سازمان‌ها خللی در روند کار ایجاد نکند، اما مسلما در بسیاری دیگر تاثیرات منفی بزرگی در کیفیت و میزان رضایت کاربران خواهد داشت. باتوجه به اینکه گفته شد که این زمان‌ها بایستی وجود داشته باشد، آیا راهی برای کم کرد زمان ایجاد درخت یا کم کردن تعداد دفعات نیاز به بازسازی درخت وجود دارد؟

شرکت سیسکو برای سریعتر کردن فرآیند spanning-tree سه روش را معرفی کرده است:

Port-fast
Uplinkfast
Backbonefast

Port-Fast

یکی از روش‌های کم کردن تعداد دفعات نیاز به بازسازی درخت، خارج کردن END-USERها از محاسبات STP است. با توجه به اینکه دستگاه‌های END-USER (مانند سیستم‌ها، پرینترها، دوربین‌ها و …) ایجاد loop نمی‌کنند، به ازای قطع و وصل شدن پورت نیازی به ارسال TCN-BDPU برای بقیه سوئیچ‌ها نیست.

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

این ویژگی به صورت پیش فرض غیر فعال است. برای فعال نمودن این ویژگی از دو روش می‌توان اقدام نمود.

در روش اول می‌توان این ویژگی را بروی تمام پورت‌ها (در محیط global configuration) تعریف نمود و پورت‌هایی را که نمی‌خواهیم این ویژگی بروی آنها وجود داشته باشد خارج کنیم.

در روش دوم می‌توان تنظیمات را به روی interface های مورد نظر به صورت تک تک یا گروهی اعمال کنیم. با این دستور اگر پورت به حالت access برود به صورت خودکار ویژگی Portfast اش فعال می‌شود.

هنگام فعال کردن این ویژگی، سوئیچ پیغام می‌دهد که با فعال کردن ویژگی portfast بروی interface، امکان loop افتادن (به دلیل عدم اجرای spanning-tree) وجود خواهد داشت.

پس از اجرای این ویژگی امکان بوجود آمدن مشکلی در شبکه وجود خواهد داشت. فرض کنید به اشتباه، دو پورت به حالت portfast شده‌ی سوئیچ به همدیگر متصل شوند. (فرض کنید کابل شبکه‌ی بلندی که ابتد و انتهایش نیز مشخص نیست، از یک طرف به نود شبکه و از طرف دیگر به لپ تاپ کاربری متصل است. کاربر پس از اتمام کارش، کابل شبکه را از سیستم خود جدا کرده و کابل شبکه را بروی زمین رها می‌کند. یکی از کارشناسان در تصور اینکه کابل شبکه سیستم یکی از همکاران است آنرا به نود دیگری از شبکه متصل می‌کند.) این کار باعث ایجاد loop در شبکه خواهد شد. برای جلوگیری از این اتفاق و برای محافظت از پورت END-USERای که به حالت portfast برده شده است، از ویژگی دیگری به نام BPDU-gaurd استفاده می‌شود.

اگر حالتی که در بالا مثال زده شد، یا اگر سوئیچی به پورتی که BPDU-Guardاش فعال شده باشد وصل شود به دلیل دریافت BPDU، پورت را غیرفعال می‌کند (به حالت error disable می برد.).

برای فعال کردن BPDUguard نیز می‌توان از همان دو روش بالا (در محیط global و یا interface) استفاده نمود. با استفاده از دستور زیر تمام پورت‌هایی که portfast باشند BPDUguard شان نیز فعال میشد.

این ویژگی فقط بروی پورتی اعمال می‌شود که portfast برویش اعمال شده باشد.

Uplinkfast

روش دیگری برای سرعت بخشیدن به ایجاد درخت STP استفاده می‌شود و در ارتباط سوئیچ‌های لایه‌های مختلف مانند access و distribution می‌توان به کار برد، Uplinkfast است.

یک سوئیچ لایه access را در نظر بگیرید که با 2 uplink به یکی از سوئیچ‌های لایه distribution متصل شده است.

به صورت معمول یکی از این دو لینک down و دیگری در وضعیت forward است.

در صورتیکه لینک اصلی از کار بیافتد، تا 50 ثانیه زمان صرف می‌شود که ارتباط این سوئیچ با سوئیچ‌های لایه access برقرار شود. ویژگی uplinkfast بروی سوئیچ‌های انتهایی درخت spanning-tree زمانی که آنها چند لینک ارتباط root port، بلاک شده دارند، امکان اتصال فوری در صورت قطع شدن لینک اصلی را فراهم می آورد.

در این روش، پیش بینی قطع شدن پورت اصلی می‌شود. قبل از این که پورت اصلی قطع شود، پورتی که قرار است در صورت قطعی جایگزین پورت اصلی شده و به حالت forward در بیاید انتخاب می‌شود. بروی پورتی که block است و می‌خواهد forward شود، بسته هایی با source سیستم هایی که به سوئیچ متصلند و با مقصد multicast ایی (که انحصاری سیسکو است: 0100.0ccd.cdcd) ارسال می‌شود. در این حالت مشکل کامل کردن جدول سوئیچ‌های دیگر و خود سوئیچ در کمتر 1 تا 2 ثانیه حل می‌شود.

مشکلی که این ویژگی ایجاد می‌کند در شبکه‌های بزرگ است جایی که تعداد زیاد این multicast ها می‌تواند بار شبکه را افزایش دهد. برای جلوگیری از این مشکل برای Uplinkfast، rate تنظیم می‌کنند (به عنوان مثال 10 پکت در ثانیه). تنظیم rate به میزان بزرگی جدول بستگی دارد.

دستور uplinkfast بروی interface اعمال نمی‌شود. (بسیاری در این موضوع اشتباه می‌کنند) چون خود سوئیچ تشخیص می‌دهد کدام پورت را بایستی به عنوان پورت جایگزین پورت اصلی در نظر بگیرد.

باید توجه داشت که Uplinkfast بروی root bridge اعمال نمی‌شود. به این علت که uplinkfast از بین root port ها برای فعال کردن دنبال پورتی می گردد که به root bridge نزدیکتر است در حالیکه root bridge، root port ایی ندارد که بخواهد انتخاب شود.

با وجود تمام این پیش‌بینی‌ها، در این روش نمی‌توان جلوی 20 ثانیه تاخیر اعلام قطعی های غیرمستقیم را گرفت.

Backbonefast

در لایه core متد متفاوتی برای کوتاه کردن زمان همگرایی STP استفاده می‌شود.

روش Backbonefast بطور دائم در حال بررسی وجود مسیر جایگزین به سمت root bridge است تا در صورت تشخیص یک قطعی غیرمستقیم بتواند به سرعت مسیر جایگزین را انتخاب کند. در Backbonefast سوئیچ زمانی متوجه قطعی غیرمستقیم می‌شود که inferior BPDU را از سوئیچ غیر root بروی هر پورتی (چه root port و یا blocked port) دریافت کند.

Inferior BPDU

Inferior BPDU زمانی ایجاد می‌شود که یک سوئیچ uplink اش قطع شده و خود را به عنوان RB معرفی می‌کند.

پکت BPDU در دو حالت inferior در نظر گرفته می‌شود:

1- حاوی اطلاعاتی درباره root bridge ایی است که بدتر (bridge ID بالاتر) از وضعیت پورت‌های ذخیره شده حال حاضر باشد.

2- BPDU فاصله بیشتری برای رسیدن به root bridge جاری دارد ( این موضوع را با افزایش متریک RIP مقایسه کنید.).

به صورت پیش فرض هر سوئیچ بایستی inferior BPDU ها را ignore کند تا زمانیکه BPDU ذخیره شده جاری انقضاء یابد.

در حالت کلی می‌توان گفت، سوئیچی که ارتباط خود را با root bridge از دست می‌دهد، این بسته را به تمام interface های دیگر خود ارسال نموده و خود را به عنوان root bridge معرفی می‌کند. سوئیچ‌های دیگر تا زمانی که با root bridge اصلی ارتباط داشته باشند این بسته ها را ignore می‌کنند.

پس از دریافت پکت inferior BPDU و قطع ارتباط با root، در حالت عادی سوئیچ بایستی به اندازی Max Age پیش از پاسخ دادن به inferior BPDU منتظر بماند. هر چند، در همین حین، BackboneFast شروع به مشخص نمودن راه های جایگزین دیگر برای دسترسی به root bridge، توسط انواع حالت‌های دریافت inferior BPDU می‌کند:

• اگر inferior BPDU بروی پورتی در حالت block به سوئیچ برسد. سوئیچ root port و بقیه پورت‌های block را به عنوان گزینه های جایگزین به root bridge در نظر می گیرد.

• اگر inferior BPDU بروی root port وارد شود. سوئیچ تمام پورت‌های block را به عنوان مسیرهای جایگزین به root bridge در نظر می گیرد.

• اگر inferior BPDU بروی root port به سوئیچ رسیده و هیچ پورتی block نباشد سوئیچ ارتباط خود با root bridge را قطع در نظر می‌گیرد. در این حالت، سوئیچ خود را root bridge فرض کرده و BackboneFast به آن اجازه می‌دهد این کار را قبل از اتما زمان Max Age انجام دهد.

تشخیص مسیرهای جایگزین به root شامل یک فرآیند تعاملی با بقیه سوئیچ‌هاست. اگر سوئیچی پورت‌های block داشته باشد، BackboneFast شروع به استفاده از پروتکل Root Link Query (RLQ) برای بررسی اینکه آیا سوئیچ‌های لایه های بالاتر ارتباط پایدار به root bridge دارند یا خیر می‌کند.

در ابتدا RLQ Request ارسال می‌شود. اگر سوئیچی RLQ Request را دریافت کند و root bridge باشد یا ارتباط خود را با root از دست داده باشد RLQ Reply را ارسال می‌کند. در غیر اینصورت RLQ Request به سوئیچ‌های دیگر تا زمان دریافت RLQ Reply انتشار داده می‌شود.

در سوئیچ local اگر بروی همان پورت یک RLQ Reply دریافت شود مسیر به root bridge سالم و پایدار است. اگر از پورتی غیر از root port دریافت شود یک مسیر جایگزین root بایستی انتخاب شود. در صورت پیدا شدن root port جدید زمان Max Age سریعا صفر می‌شود.

کار این ویژگی کاستن 20 ثانیه قطعی غیر مستقیم است.

برای اجرای این دستور باید بروی همه سوئیچ‌ها اعمال شود تا سوئیچ‌ها بتوانند با همدیگر تعامل کنند.