قابلیت های پیشرفته STP (بخش سوم)

نویسنده: حسنا حسن نژاد
2 ماه پیش

قابلیت های پیشرفته STP (بخش سوم)

در مقالات پیشین، قابلیت های پیشرفته STP (بخش اول) و (بخش دوم)، قابلیت هایی از جمله PortFast ،BPDU Guard ،BPDU Filter ،Root Guard ،Loop Guard و UDLD در PVST معرفی شد. در این مقاله به بررسی دو قابلیت دیگر در PVST یعنی UplinkFast و BackboneFast پرداخته می شود.

UplinkFast

ویژگی UplinkFast با هدف کاهش زمان لازم در STP برای فعال سازی مجدد توپولوژی پس از Direct Link Failure (قطع لینک مستقیم) مورد استفاده قرار می گیرد. برای مثال در شکل زیر SW1 که در لایه Access قرار دارد را در نظر بگیرید که دارای اتصالات Redundant Uplink به دو سوئیچ لایه Core است. به طور معمول، یکی از پورت های آن در حالت Forwarding و دیگری در حالت Blocking خواهد بود. در صورت قطع شدن لینک مابین سوئیچ های Core1 و SW1، حداکثر 30 ثانیه طول می کشد تا SW1 از Redundant Uplink خود استفاده کند.

سوئیچ های Access (مانند SW1) با استفاده از قابلیت UplinkFast می توانند در صورت تغییر توپولوژی ناشی از Direct Link Failure، پورت Block خود را بلافاصله در وضعیت Forward قرار داده و Root Port کند.

شایان ذکر است که Up شدن سریع پورت Block کافی نیست، زیرا باید 300 ثانیه زمان بگذرد تا جدول MAC در سوئیچ ها Update شود و مسیر جدید جایگزین در جدول MAC قرار گیرد. برای رفع این مشکل سوئیچی که در آن Direct Link Failure رخ داده، تعدادی Dummy Multicast Frame را از طریق Root Port جدید خود به سمت سوئیچ مقابل ارسال می کند. در این بسته ها، سوئیچ MAC هایی را که از سایر پورت های خود یاد گرفته است را به عنوان Source MAC و 0100.0ccd.cdcd را به عنوان Destination MAC قرار می دهد. سوئیچ مقابل با دریافت این بسته ها، جدول MAC خود را Update کرده و بسته ها بلافاصله از مسیر جدید عبور خواهند کرد. سایر سوئیچ ها نیز با استفاده از بسته های TCN ارسال شده، جدول MAC خود را Update می کنند.

نکته: MAC Table در دو صورت Update می شود:

  1. زمانی که Age-Time آن به پایان برسد و سوئیچ هیچ بسته ای از MAC یاد گرفته شده در جدول خود دریافت نکند.
  2. زمانی که MAC های یاد گرفته شده در جدول MAC از طریق یک لینک جدید یاد گرفته شود.

شایان ذکر است در صورت فعال شدن لینک Fail شده به اندازه 2xForward-Delay (Listening و Learning) طول می کشد تا Root Port قبلی بازیابی گردد.

UplinkFast

این قابلیت تنها به صورت Globally فعال شده و بر روی تمامی VLAN ها اعمال می شود. از UplinkFast در سوئیچ های Root Bridge، ترانزیت و آن هایی که امکان Root Bridge شدن دارند، استفاده نمی شود. زمانی که در یک سوئیچ این ویژگی فعال می شود Priority Bridge به 49152 افزایش می یابد تا امکان Root Bridge شدن برای این سوئیچ وجود نداشته باشد. همچنین Cost تمامی پورت های سوئیچ به 3000 افزایش می یابد تا امکان Root Port شدن این پورت ها برای سوئیچ های لایه های پایین تر فراهم نشود.

Backbonefast

ویژگی BackboneFast با هدف کاهش زمان لازم در STP برای فعال سازی مجدد توپولوژی پس از Indirect Link Failure (قطع لینک غیرمستقیم) مورد استفاده قرار می گیرد. برای مثال در شکل زیر سوئیچ های SW1 و SW2 که در لایه Access قرار دارند را در نظر بگیرید که دارای اتصالات Redundant Uplink به دو سوئیچ لایه Core می باشند. یکی از پورت های آن ها در حالت Forwarding و دیگری در حالت Blocking خواهد بود. در صورت قطع شدن لینک بین دو سوئیچ Core1 و Core2 حداکثر 50 ثانیه طول می کشد تا SW1 و SW2 از Redundant Uplink خود استفاده کنند. یک سوئیچ (غیر از Root Bridge) با قابلیت BackboneFast می تواند در صورت تغییر توپولوژی ناشی از Indirect Link Failure، بلافاصله  پورت بلاک شده خود را در وضعیت Learn ،Listen و در نهایت Forward قرار داده و Root Port کند.

نکته: زمانی که برای سوئیچ های غیر از Indirect Link Failure ،Root Bridge رخ دهد بر روی پورت بلاک این سوییچ ها Inferior BPDU دریافت می شود. زمانی که ارتباط یک سوئیچ (Core2) با Root Bridge (Core1) از طریق Root Port قطع شود، به پورت سوئیچ مقابل خود (SW1 و SW2) که در وضعیت Block قرار دارد بسته ای به نام Inferior BPDU ارسال می کند و در آن خود را به عنوان Root Bridge معرفی کرده تا پورت مقابل که در وضعیت Block قرار دارد به Forward تغییر وضعیت دهد.

در این حالت اگر اتصال سوئیچ های دیگر (SW1 و SW2) با Root Bridge اصلی (Core1) در شبکه قطع نشده باشد نباید Root Port آن ها تغییر کند، و پورت Block آن ها تنها بعد از مدت 2xForward-Delay (Listening و Learning) به عنوان Designated Port انتخاب می شود اما اگر اتصال سوئیچ های دیگر (SW1 و SW2) با Root Bridge اصلی (Core1) در شبکه قطع شده باشد، باید Root Port آن ها تغییر کند و پورت Block آن ها تنها بعد از مدت 2xForward-Delay (Listening و Learning) به عنوان Root Port انتخاب شود. با استفاده از بسته هایی به نام RLQ (Root Link Query) Request و Role ،RLQ Response پورت Block به عنوان Root Port و یا Designated Port مشخص می شود.

نحوه کار به این صورت خواهد بود که با قطع شدن ارتباط یک سوئیچ (Core2) از طریق Root Port با Root Bridge (Core1)، سوئیچ شروع به ارسال بسته های Inferior BPDU بر روی Designated Port های خود می کند و خود را به عنوان Root Bridge جدید در شبکه اعلام می نماید (Step1). با دریافت این بسته ها بر روی پورت های Block سوئیچ های دیگر (SW1 و SW2)، این سوئیچ ها باید بررسی کنند آیا واقعا ارتباط آن ها با Root Bridge اصلی (Core1) از طریق Root Port از بین رفته است و یا اینکه تنها ارتباط سوئیچی که بسته های Inferior BPDU را ارسال کرده است با (Core2) Root Bridge از بین رفته است. به این منظور این سوئیچ ها (SW1 و SW2) اقدام به ارسال بسته های RLQ Request بر روی تمامی پورت های Block و Root Port (تمامی UpStream Port ها) می کنند که حاوی BID مربوط به خود و BID مربوط به Root Bridge ای است که از قبل آن را شناسایی کرده اند (Step2). این بسته ها از طریق تمامی سوئیچ هایی که خود را به عنوان Root Bridge در شبکه می دانند، توسط بسته RLQ Response از طریق تمامی Designated Port های خود (تمامی DownStream Port ها) پاسخ داده می شوند.

RLQ Response ها به دو دسته تقسیم می شوند: Posetive RLQ Response و Negetive RLQ Response. در صورتی که بسته RLQ Request به دست Root Bridge اصلی (Core1) برسد با مقایسه BID خود با BID موجود در بسته RLQ Request، حضور خود را با ارسال بسته Posetive RLQ Response از طریق Designated Port های خود اعلام می کند (Step3). در صورتی که بسته RLQ Request به دست سوئیچی برسد که ادعا می کند Root Bridge جدید (Core2) است، با مقایسه BID خود با BID موجود در بسته RLQ Request، بسته Negetive RLQ Response را از طریق Designated Port های خود ارسال می کند (Step3).

Backbonefast

اگر سوئیچی که RLQ Request را ارسال کرده است (SW1 و SW2) از روی حداقل یکی از پورت های خود Posetive RLQ Response دریافت کند، متوجه می شود که ادعای سوئیچی که خود را به عنوان Root Bridge جدید معرفی کرده است اشتباه است و تنها ارتباط همان سوئیچ با Root Bridge اصلی قطع شده است، در نتیجه پورت Block خود را بدون انتظار برای پایان زمان Max Age، در وضعیت Learn ،Listen و در نهایت Forward قرار می دهد و به عنوان Designated Port انتخاب می کند و سوئیچ Root Port قبلی خود را حفظ می نماید. اما در صورتی که روی هیچ کدام از پورت های خود Posetive RLQ Response دریافت نکند، متوجه می شود که Root Bridge اصلی Down شده است و باید سوئیچی که خود را به عنوان Root Bridge جدید (Core2) معرفی کرده است، بپذیرد. در نتیجه پورت Block خود را بدون انتظار برای پایان زمان Max Age، در وضعیت Learn ،Listen و در نهایت Forward قرار داده و به عنوان Root Port جدید انتخاب کرده و Root Port قبلی خود را در وضعیت Block قرار می دهد.

پیکربندی این قابلیت تنها به صورت Globally انجام می پذیرد. قابل ذکر است که در صورت استفاده از BackboneFast، این قابلیت را باید بر روی تمامی سوئیچ های شبکه فعال نمود. زیرا BackboneFast برای اطلاع از پایداری Root Path سوئیچ ها، به مکانیسم RLQ Request و RLQ Response نیاز دارد. پروتکل RLQ تنها با فعال سازی قابلیت BackboneFast روی سوئیچ فعال می شود.

40
0
1
نظرات