لب عملی: پیکربندی BGP Multihop و احراز هویت eBGP

این لب عملی یک جلسه eBGP بین دو آدرس loopback که نیازمند چند گام روتر است را با استفاده از ebgp-multihop برای برقراری آن پیکربندی می‌کند، سپس احراز هویت MD5 برای امن‌کردن جلسه حاصل اضافه می‌کند.

پیکربندی eBGP Multihopهمسایگی مبتنی‌بر-Loopbackاحراز هویت MD5 در BGP

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

هدف لب

پیکربندی یک جلسه eBGP بین آدرس‌های loopback دو روتر به‌جای اینترفیس‌های مستقیماً-متصلشان، فعال‌کردن ebgp-multihop برای اجازه‌دادن به جلسه در سراسر بیش از یک گام روتر، سپس افزودن احراز هویت MD5 و تأیید اینکه یک رمز عبور نامنطبق از برقراری جلسه جلوگیری می‌کند.

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

هر جلسه eBGP پوشش‌داده‌شده پیش‌تر در این مجموعه از آدرس‌های اینترفیس مستقیماً-متصل استفاده کرد، که به‌طور پیش‌فرض eBGP را به یک TTL برابر ۱ محدود می‌کند — مناسب برای یک لینک مستقیم اما ناکافی وقتی همسایگی نیاز دارد بین آدرس‌های loopback که فقط از طریق یک گام میانی دسترس‌پذیرند رخ دهد. احراز هویت، در همین حین، از هر جلسه BGP — eBGP یا iBGP — در برابر یک همتای جعل‌شده که تلاش می‌کند اطلاعات مسیریابی نادرست تزریق کند محافظت می‌کند.

توپولوژی لب

R1 (AS 65110) ---- گام میانی ---- R2 (AS 65120)

R1 Loopback0: 1.1.1.1/32
R2 Loopback0: 2.2.2.2/32
(دسترس‌پذیر از طریق مسیرهای ایستا یا یک IGP،
از قبل پیکربندی‌شده، نیازمند ۲ گام)

وظیفه ۱: تلاش برای همسایگی استاندارد eBGP بین Loopback ها

یک عبارت neighbor با استفاده از آدرس‌های loopback بدون ebgp-multihop پیکربندی کن، و مشاهده کن جلسه در برقراری شکست می‌خورد.

وظیفه ۲: فعال‌کردن eBGP Multihop

ebgp-multihop را روی هر دو روتر با یک مقدار TTL کافی برای تعداد گام واقعی پیکربندی کن.

وظیفه ۳: پیکربندی Update-Source

هر روتر را طوری پیکربندی کن که بسته‌های BGP‌اش را از اینترفیس loopback خودش منشأ کند، مورد نیاز برای درست‌کارکردن همسایگی مبتنی‌بر-loopback.

وظیفه ۴: تأیید برقراری جلسه

تأیید کن رابطه همسایه eBGP به حالت Established می‌رسد.

وظیفه ۵: افزودن احراز هویت MD5 و تأیید شکست عدم‌تطابق

رمزهای عبور MD5 منطبق را روی هر دو روتر پیکربندی کن، تأیید کن جلسه پایدار باقی می‌ماند، سپس عمداً رمز عبور یک سمت را نامنطبق کن و مشاهده کن جلسه شکست می‌خورد.

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

R1(config)# router bgp 65110
R1(config-router)# neighbor 2.2.2.2 remote-as 65120

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   0       0        Idle
-- گیرکرده در Idle -- eBGP استاندارد به‌طور
-- پیش‌فرض TTL برابر ۱ دارد، که برای رسیدن به
-- یک loopback دو گام دورتر ناکافی است

R1(config)# router bgp 65110
R1(config-router)# neighbor 2.2.2.2 ebgp-multihop 3
R1(config-router)# neighbor 2.2.2.2 update-source loopback0

R2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 ebgp-multihop 3
R2(config-router)# neighbor 1.1.1.1 update-source loopback0

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   8       7        0
-- Established (PfxRcd عددی)، که تأیید می‌کند
-- جلسه multihop اکنون به‌درستی کار می‌کند

R1(config)# router bgp 65110
R1(config-router)# neighbor 2.2.2.2 password BgpSecure2026

R2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 password BgpSecure2026

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   9       8        0
-- همچنان Established، رمزهای عبور منطبق
-- هیچ اخلالی ایجاد نکردند

R2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 password WrongPassword999

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   0       0        Idle
-- جلسه کاملاً وقتی رمزهای عبور نامنطبق شوند
-- می‌افتد -- خود TCP اتصال را رد می‌کند چون
-- امضای MD5 روی سگمنت‌های ورودی دیگر تأیید
-- نمی‌شود

نکته کلیدی

TTL پیش‌فرض ۱ eBGP یک پیش‌فرض عمدی امنیت-محور است که اتصال مستقیم را فرض می‌کند، و ebgp-multihop ترکیب‌شده با update-source جفت استاندارد مورد نیاز هروقت آن فرض برقرار نیست، مانند همسایگی مبتنی‌بر-loopback است — احراز هویت MD5 در لایه TCP زیر خود BGP عمل می‌کند، که چرایی این است که یک عدم‌تطابق رمز عبور از تشکیل خود جلسه TCP زیربنایی اصلاً جلوگیری می‌کند به‌جای صرفاً رد‌شدن پس از شروع تبادل پیام خود 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 پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه