لب عملی: پیکربندی فیلترینگ مسیر BGP با Prefix List ها

این لب عملی فیلترهای prefix-list ورودی و خروجی را روی یک جلسه BGP پیکربندی می‌کند تا دقیقاً کنترل کند کدام مسیرها پذیرفته یا تبلیغ می‌شوند، و تأیید می‌کند فیلترها پیشوندهای ناخواسته را مسدود می‌کنند در حالی که موارد مورد نظر را عبور می‌دهند.

فیلترینگ Prefix-List در BGPکنترل مسیر ورودی و خروجیجایگزین Distribute-List

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

هدف لب

پیکربندی یک prefix list که فقط شبکه‌های خاص را مجاز می‌کند، اعمال آن به‌عنوان یک فیلتر ورودی روی یک جلسه BGP برای رد‌کردن مسیرهای ناخواسته، سپس پیکربندی یک prefix list خروجی جداگانه که محدود می‌کند کدام شبکه‌های خود روتر محلی تبلیغ می‌شوند.

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

Community ها، پوشش‌داده‌شده در لب قبلی، سیاست را پس از پذیرفته‌شدن مسیرها به فرآیند BGP کنترل می‌کنند. Prefix list ها چیزی بنیادین‌تر را کنترل می‌کنند: اینکه آیا یک مسیر اصلاً پذیرفته یا تبلیغ می‌شود — ضروری برای جلوگیری از تزریق مسیرهای ناخواسته توسط یک همتای نادرست‌پیکربندی‌شده یا مخرب، یا برای عمداً نگه‌داشتن برخی شبکه‌های داخلی از تبلیغ‌شدن خارجی.

توپولوژی لب

R1 (AS 65080) ---- eBGP ---- R2 (AS 65090)

R2 سه شبکه را تبلیغ می‌کند:
203.0.113.0/24 (مشروع)
10.0.0.0/8 (باید رد شود -- فضای خصوصی، هرگز
            نباید در eBGP از یک همتای مشروع
            ظاهر شود)
198.51.100.0/24 (مشروع)

R1 دو شبکه داخلی دارد:
192.168.80.0/24 (باید تبلیغ شود)
192.168.99.0/24 (فقط-داخلی، نباید خارجی
                 تبلیغ شود)

وظیفه ۱: تأیید پذیرفته‌شدن هر سه مسیر در ابتدا

تأیید کن R1 در حال حاضر هر سه شبکه را از R2 می‌پذیرد، شامل 10.0.0.0/8 مسئله‌ساز.

وظیفه ۲: پیکربندی یک Prefix List ورودی که فضای خصوصی را رد می‌کند

یک prefix list که صراحتاً 10.0.0.0/8 را رد می‌کند در حالی که هر چیز دیگر را مجاز می‌کند بساز، و آن را ورودی اعمال کن.

وظیفه ۳: تأیید رد‌شدن اکنون مسیر خصوصی

تأیید کن 10.0.0.0/8 دیگر در جدول BGP R1 ظاهر نمی‌شود، در حالی که دو مسیر مشروع همچنان می‌شوند.

وظیفه ۴: پیکربندی یک Prefix List خروجی که یک شبکه داخلی را نگه می‌دارد

یک prefix list که فقط 192.168.80.0/24 را مجاز می‌کند بساز و آن را خروجی به‌سمت R2 اعمال کن.

وظیفه ۵: تأیید دریافت فقط شبکه مورد نظر توسط R2

تأیید کن R2 192.168.80.0/24 را می‌بیند اما هرگز 192.168.99.0/24 را.

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

R1# show ip bgp

   Network              Next Hop        Path
*> 10.0.0.0/8           [via R2]        65090 i
*> 198.51.100.0/24      [via R2]        65090 i
*> 203.0.113.0/24       [via R2]        65090 i
-- هر سه مسیر در ابتدا پذیرفته شدند، شامل
-- بازه خصوصی مسئله‌ساز

R1(config)# ip prefix-list BLOCK-PRIVATE seq 5 deny 10.0.0.0/8
R1(config)# ip prefix-list BLOCK-PRIVATE seq 10 permit 0.0.0.0/0 le 32

-- deny صریح اول می‌آید، سپس یک permit-همه
-- هر چیز دیگر را می‌گیرد -- prefix list ها،
-- مانند ACL ها، یک deny ضمنی در انتها دارند،
-- پس این خط permit نهایی مورد نیاز است

R1(config)# router bgp 65080
R1(config-router)# neighbor [آدرس R2] prefix-list BLOCK-PRIVATE in

R1# clear ip bgp [آدرس R2] soft in

R1# show ip bgp

   Network              Next Hop        Path
*> 198.51.100.0/24      [via R2]        65090 i
*> 203.0.113.0/24       [via R2]        65090 i
-- 10.0.0.0/8 دیگر ظاهر نمی‌شود -- دو شبکه
-- مشروع تحت‌تأثیر باقی نمی‌مانند

R1(config)# ip prefix-list ADVERTISE-ONLY seq 5 permit 192.168.80.0/24

R1(config)# router bgp 65080
R1(config-router)# neighbor [آدرس R2] prefix-list ADVERTISE-ONLY out

R2# show ip bgp

   Network              Next Hop        Path
*> 192.168.80.0/24      [via R1]        65080 i
-- فقط شبکه مورد نظر ظاهر می‌شود -- 192.168.99.0/24
-- اصلاً هرگز تبلیغ نشد، چون prefix list خروجی
-- هیچ عبارت permit منطبقی با آن نداشت، پس به
-- deny ضمنی افتاد

نکته کلیدی

Prefix list های ورودی و خروجی چیزی اساساً متفاوت از ابزارهای مبتنی‌بر-ویژگی پوشش‌داده‌شده در لب‌های قبلی کنترل می‌کنند: به‌جای تأثیرگذاری روی اینکه کدام‌یک از چند مسیر از‌قبل-پذیرفته‌شده ترجیح داده می‌شود، تصمیم می‌گیرند آیا یک مسیر اصلاً پذیرفته یا تبلیغ می‌شود — یک خط دفاع اولیه ضروری در برابر یک همتای eBGP بدرفتار یا نادرست‌پیکربندی‌شده، و ابزار درست هروقت شبکه‌های داخلی خاص هرگز نباید AS محلی را ترک کنند صرف‌نظر از هر پیکربندی سیاست دیگر.

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

مقالات مرتبط

لب عملی: پیکربندی مسیریابی 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 پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه