مدت زمان ایجاد درخت جدید spanning tree

0
3299

در مباحث قبلی در خصوص مباحث spanning tree و چگونگی محاسبه آن توضیح دادیم. چنانچه تغییری در درخت ایجاد شود، به عنوان مثال پورتی غیرفعال شود، مراحل تشکیل درخت از ابتدا انجام می‌شود. می‌خواهیم بررسی کنیم، مدت زمان ایجاد درخت جدید spanning tree چقدر است. با ما همراه باشید.

در صورتی که در درخت spanning-tree پورتی فعالی قطع شود، باعث از بین رفتن اتصال کامل درخت می‌شود.

این قطعی در درخت توسط STP پس از گذشت زمان‌های مشخص در فرآیند، شناسایی و برطرف می‌شود.

قطعی ها به دو صورت هستند: مستقیم (Direct topology changes) – غیر مستقیم (Indirect topology change).

بسته به نوع قطعی، مدت زمان 30 ثانیه (در قطعی های مستقیم با سوئیچ root) تا 50 ثانیه (در قطعی های غیر مستقیم با سوئیچ root) زمان صرف بر سر تغییرات درخت خواهد شد.

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

در قطعی غیر مستقیم، به دلیل اینکه سوئیچ root از قطعی در سوئیچ دیگر خبر ندارد، به اندازه ی max age بسته BPDU (20 ثانیه، معادل 10 بسته hello)، منتظر دریافت اطلاعات برای بروزرسانی وضعیت خود با سوئیچ قطع می‌ماند. زمانی که hello دریافت نشود، سوئیچ root متوجه قطعی ارتباطش در ساختار درخت شده و سپس اقدام به ارسال configuration BPDU می‌کند.

پس از دریافت configuration BPDU، یکی از سوئیچ‌ها اجازه‌ دریافت می‌کند تا پورتی که پیش از این قطع بوده را به حالت forward تبدیل کند.

فرآیند تغییر حالت block به forward

با توجه به اینکه انتخاب وضعیت پورت‌ها (block یا forward بودنشان) در همان ثانیه اول اتفاق می‌افتد (زیرا با ارسال BPDU ها توسط سوئیچ‌ها در شبکه، ساختار درخت مشخص می‌شود) با این حال سوئیچ‌ها دو زمان 15 ثانیه برای تغییر وضعیت ها پورت‌ها صرف می‌کنند تا از ایجاد loop در شبکه جلوگیری شود، این دو 15 ثانیه همان زمان های listening و learning اند.

به همین علت، می‌توان گفت، اگر پورتی بخواهد از block به forward برود در ابتدا به وضعیت listening سپس به وضعیت learning و نهایتا به حالت forward خواهد رفت.

بررسی چگونگی ایجاد loop با استفاده از جدول‌های قدیمی

سناریو زیر را در نظر بگیرید

در حین کار کردن دستگاه‌ها، یکی از ارتباطات، مانند تصویر زیر، قطع می‌شود.

در این حالت، پورت شماره 5 از سوئیچ پایین اجازه‌ی به حالت forward رفتن را پیدا کرده و می‌تواند تغییر وضعیت می‌دهد. فرض می‌کنیم زمان 30 ثانیه به سوئیچ‌ها برای تغییر جدول خود داده نشده و تا زمان دریافت اطلاعات جدید از همان جدولی قدیمی خود استفاده می‌کنند.

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

سوئیچ مجاور و متصل سمت راست، آدرس A را در جدول خود دارد. به همین علت آدرس رسیدن به سیستم A در سوئیچ سمت چپ، از پورت 3 به پورت 2 تغییر می‌کند. سوئیچ سمت چپ ترافیک به مقصد A را برای سوئیچ سمت راست ارسال می‌کند.

سوئیچ سمت راست، مسیر رسیدنش به سیستم A از طریق پورت 3 است

راه حل از بین بردن loop اصلاح جدول‌هاست.

برای اصلاح جدول‌های یکی از راه حل ها این است که تمام جدول‌های پاک شده و مجدداً پر شوند. این کار باعث بالا رفتن ترافیک شده و قسمت هایی که در جدول درست بوده و احتیاج به اصلاح نداشته پاک می‌شود.

راه حل دیگر این است که 300 ثانیه منتظر بمانیم تا عمر ردیف های مختلف جدول تمام شوند. با این کار احتیاجی به پر شدن کامل جدول نیست و فقط قسمت هایی که نیاز به اصلاح دارند تغییر خواهد نمود. اما باید 5 دقیقه زمان صرف شود تا تمام جدول‌ها بروز شوند که زمان زیادی است. برای کم کردن زمان 5 دقیقه، باید عمر جدول کم شود.

روال کم کردن عمر جدول

هر سوئیچی که به صورت مستقیم با قطعی در ارتباط است، پیغامی برای root bridge ارسال می کند. به این پیغام TCN-BPDU (Topology change notification) گفته می‌شود. با این پیغام RB متوجه می‌شود که جایی در شبکه قطع شده است. به همین علت در پکت های BPDU configuration با تغییر وضعیت بیت tcn-BPDU، سوئیچ‌های دیگر را متوجه می‌کند که باید عمر جدول شان را از 300 ثانیه به 15 ثانیه تغییر دهند.

در این مدت زمان اگر کسی با ارسال data ردیف مربوط به خودش را update نمود عمر آن ردیف مجددا به 300 ثانیه افزایش داده می‌شود. ردیف هایی که نمی‌توانند خودشان را update کنند (بعلت اینکه ترافیکی ارسال نکرده‌اند) پس از 15 ثانیه از جدول پاک خواهند شد.

علت این که زمان listening و learning 15 ثانیه در نظر گرفته شده است:

در اکثر منابع آموزشی ذکر شده به علت وجود یکسری متدها که با این اعداد کار می‌کنند مدت زمان 15 ثانیه در نظر گرفته شده و این اعداد را تغییر ندهید. بر طبق best practice ها (نمونه های موفق اجرایی) مدت زمان 15 ثانیه با قطر گراف ارتباط دارد.

قطر گراف: بیشترین فاصله بین دو نود.

عمق گراف: بیشترین فاصله از ریشه تا نود.

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

زمان 15 ثانیه برای عدد قطر 7 در نظر گرفته شده است. اگر قطر گراف کمتر و یا بیشتر شود می‌توان مدت زمان بهینه را محاسبه نمود. در سوئیچ‌های سیسکو، می‌توان قطر گراف شبکه را داد تا زمان مورد نظر به صورت خودکار تنظیم شود.

 

ارسال یک پاسخ

لطفا دیدگاه خود را وارد کنید!
لطفا نام خود را در اینجا وارد کنید