لب عملی: پیکربندی BFD برای تشخیص سریع شکست

این لب عملی جلسات BFD را بین دو روتر پیکربندی می‌کند و BFD را به یک فرآیند OSPF از‌قبل-در-حال-اجرا پیوند می‌دهد، و زمان تشخیص شکست را در مقایسه با تکیه صرف بر مکانیزم تایمر hello/dead خود OSPF از پیش‌تر در این مجموعه به‌طور چشمگیری کاهش می‌دهد.

پیکربندی BFDتشخیص شکست زیر-ثانیه‌اییکپارچگی پروتکل BFD

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

هدف لب

پیکربندی جلسات BFD بین دو روتر، پیوند‌دادن BFD به یک فرآیند OSPF از‌قبل-برقرار، و مقایسه زمان تشخیص شکست با استفاده از BFD در برابر مکانیزم تایمر hello/dead پیش‌فرض خود OSPF از پیش‌تر در این مجموعه.

هدف لب (چرا مهم است)

تایمر dead پیش‌فرض ۴۰ ثانیه‌ای OSPF، به‌طور گسترده پیش‌تر در این مجموعه بحث شد، برای بسیاری شبکه‌های مدرن که failover زیر-ثانیه‌ای انتظار می‌رود بسیار آهسته است. به‌جای تنظیم تهاجمی تک‌تک تایمرهای هر پروتکل مسیریابی جداگانه، BFD یک مکانیزم تشخیص شکست واحد، سبک، و مستقل-از-پروتکل فراهم می‌کند که چند پروتکل مسیریابی می‌توانند به اشتراک بگذارند.

توپولوژی لب

R1 ---- Gi0/0 ------------------ Gi0/0 ---- R2

192.168.230.1/24            192.168.230.2/24

OSPF از قبل بین R1 و R2 برقرار شده، تایمرهای
پیش‌فرض (hello 10، dead 40)

وظیفه ۱: تأیید زمان تشخیص شکست خط‌مبنای OSPF

یک شکست لینک را بدون BFD شبیه‌سازی کن و یادداشت کن OSPF تقریباً چقدر طول می‌کشد تا آن را تشخیص دهد و همسایه را حذف کند.

وظیفه ۲: پیکربندی BFD روی هر دو اینترفیس

BFD را روی اینترفیس‌های مشترک Gi0/0 روی هر دو روتر، با یک بازه تهاجمی، فعال کن.

وظیفه ۳: پیوند‌دادن BFD به فرآیند OSPF

OSPF را طوری پیکربندی کن که از BFD برای تشخیص شکست روی این اینترفیس استفاده کند، به‌جای تکیه صرف بر تایمرهای hello/dead خودش.

وظیفه ۴: تأیید فعال‌بودن جلسه BFD

تأیید کن یک جلسه BFD بین دو روتر مستقل از حالت همسایه خود OSPF برقرار می‌شود.

وظیفه ۵: شبیه‌سازی مجدد یک شکست و مقایسه زمان تشخیص

همان شکست لینک را شبیه‌سازی کن و تشخیص به‌طور چشمگیری سریع‌تر و حذف همسایه OSPF را مشاهده کن.

راه‌حل و تأیید

-- آزمایش خط‌مبنا: شکست لینک بدون BFD

R1(config)# interface gigabitethernet0/0
R1(config-if)# shutdown

-- (تقریباً ۴۰ ثانیه بعد، بر اساس تایمر dead
--  پیش‌فرض)
R1# show ip ospf neighbor
-- (همسایه فقط پس از گذشت تقریباً ۴۰ ثانیه
--  ناپدید می‌شود)

R1(config-if)# no shutdown

R1(config)# interface gigabitethernet0/0
R1(config-if)# bfd interval 150 min_rx 150 multiplier 3

R2(config)# interface gigabitethernet0/0
R2(config-if)# bfd interval 150 min_rx 150 multiplier 3

-- بازه ۱۵۰ میلی‌ثانیه‌ای با یک ضریب ۳ یعنی
-- یک شکست در طول تقریباً ۴۵۰ میلی‌ثانیه
-- تشخیص داده می‌شود، به‌طور چشمگیری سریع‌تر
-- از تایمر dead ۴۰-ثانیه‌ای خود OSPF

R1(config)# router ospf 1
R1(config-router)# bfd all-interfaces

R2(config)# router ospf 1
R2(config-router)# bfd all-interfaces

R1# show bfd neighbors

NeighAddr        LD/RD    RH/RS    State   Int
192.168.230.2    1/1      Up/Up    Up      Gi0/0
-- جلسه BFD به‌طور مستقل برقرار شد -- این
-- جلسه سلامت لینک را مستقیماً نظارت می‌کند،
-- جدا از تبادل hello خود OSPF

R1(config)# interface gigabitethernet0/0
R1(config-if)# shutdown

-- تشخیص اکنون در طول تقریباً نیم ثانیه رخ می‌دهد

R1# show ip ospf neighbor
-- (همسایه از‌قبل رفته، تأیید‌شده با بررسی
--  تقریباً بلافاصله پس از shutdown، به‌جای
--  انتظار برای چیزی نزدیک به ۴۰ ثانیه)

نکته کلیدی

BFD به‌عنوان یک جلسه مستقل و سبک عمل می‌کند که OSPF (یا هر پروتکل یکپارچه‌شده-با-BFD) صرفاً از آن سؤال می‌کند، به‌جای اینکه هر پروتکل مسیریابی نیاز به تایمرهای hello/dead تهاجمی-تنظیم‌شده خودش داشته باشد — این جداسازی یعنی همان جلسه BFD می‌تواند هم‌زمان تشخیص شکست را برای چند پروتکل در حال اجرا روی همان لینک (OSPF، EIGRP، BGP) تسریع کند بدون نیاز به پیکربندی جداگانه تایمرهای تهاجمی در هر پروتکل جداگانه.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

لب عملی: پیکربندی مسیریابی Stub در EIGRP

این لب عملی یک روتر شعبه را به‌عنوان یک stub در EIGRP پیکربندی می‌کند، و تأیید می‌کند فقط مسیرهای متصل و خلاصه خودش را تبلیغ می‌کند در حالی که روتر hub به‌درستی از پرس‌وجوکردن stub در طول یک تغییر توپولوژی در جای دیگری از شبکه اجتناب می‌کند.

ادامه

لب عملی: پیکربندی حالت Named در EIGRP

این لب عملی یک پیکربندی EIGRP کلاسیک موجود را به حالت named EIGRP بازپیکربندی می‌کند، و عبارات network و پیکربندی خاص-اینترفیس را در یک سلسله‌مراتب address-family ساختاریافته‌تر سازمان‌دهی می‌کند، و تعادل عملکردی با سبک پیکربندی کلاسیک استفاده‌شده در سراسر لب‌های EIGRP قبلی این مجموعه را تأیید می‌کند.

ادامه

لب عملی: پیکربندی ERSPAN در سراسر یک شبکه مسیریابی‌شده

این لب عملی Encapsulated RSPAN (ERSPAN) را برای آینه‌کردن ترافیک در سراسر یک شبکه مسیریابی‌شده-لایه-۳ به‌جای یک ترانک لایه ۲ واحد پیکربندی می‌کند، و مفهوم RSPAN از لب قبلی را فراتر از مرزهای یک VLAN یا دامنه سوئیچ‌شده واحد گسترش می‌دهد.

ادامه

لب عملی: پیکربندی RSPAN در سراسر سوئیچ‌ها

این لب عملی Remote SPAN (RSPAN) را با استفاده از یک VLAN RSPAN اختصاصی حمل‌شده در سراسر یک ترانک پیکربندی می‌کند، و اجازه می‌دهد ترافیک آینه‌شده روی یک سوئیچ توسط یک دستگاه گرفتن متصل به یک سوئیچ کاملاً متفاوت نظارت شود، و مفهوم SPAN محلی پوشش‌داده‌شده در یک لب قبلی را در سراسر شبکه گسترش می‌دهد.

ادامه

لب عملی: پیکربندی In-Service Software Upgrade (ISSU) روی یک Stack

این لب عملی یک In-Service Software Upgrade را در سراسر یک stack StackWise انجام می‌دهد، و ایمیج IOS هر عضو را یکی‌یکی ارتقا می‌دهد در حالی که stack در سراسر آن به فوروارد‌کردن ترافیک ادامه می‌دهد، و صفر خرابی را در مقایسه با رویکرد مخل reload استفاده‌شده در لب‌های ارتقای IOS قبلی تأیید می‌کند.

ادامه

لب عملی: پیکربندی Stacking سنتی StackWise در Catalyst

این لب عملی stacking سنتی Catalyst (StackWise) را در سراسر سه سوئیچ با استفاده از کابل‌های stack پیکربندی می‌کند، و نیازمندی تک-لایه و مجاورت فیزیکی‌اش را با جفت StackWise Virtual پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه