لب عملی: پیکربندی Community در BGP

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

ویژگی Community در BGPتطبیق Route-Map مبتنی‌بر-CommunitySend-Community

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

هدف لب

پیکربندی یک route-map روی یک روتر لبه که یک مسیر خاص را با یک مقدار community BGP تگ‌گذاری می‌کند، فعال‌کردن انتشار community به یک همسایه iBGP، و پیکربندی آن همسایه پایین‌دست برای تطبیق فقط با مقدار community برای اعمال یک سیاست متمایز.

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

هر تکنیک دست‌کاری مسیر پوشش‌داده‌شده پیش‌تر در این مجموعه — weight، local preference، AS-path prepending، MED — نیازمند دوباره-تطبیق همان معیار اصلی (یک ACL، یک prefix list) در هر نقطه از شبکه که یک تصمیم سیاست نیاز است. Community ها این را با تگ‌گذاری یک مسیر یک‌بار در لبه با یک برچسب دلخواه حل می‌کنند، و اجازه می‌دهند هر روتر پایین‌دست تصمیمات سیاست را کاملاً بر اساس آن برچسب بگیرد بدون نیاز به دانستن یا بازپیاده‌سازی منطق تطبیق اصلی.

توپولوژی لب

R1 (روتر لبه، مسیرها را از یک شریک از طریق
    eBGP یاد می‌گیرد) ---- iBGP ---- R2 (روتر
                              هسته، یک سیاست
                              مبتنی‌بر-community
                              اعمال می‌کند)

R1 192.168.60.0/24 را از یک شریک خارجی یاد
می‌گیرد و می‌خواهد آن را به‌عنوان "customer-route"
برای مدیریت ویژه در جای دیگری از شبکه تگ‌گذاری کند

وظیفه ۱: پیکربندی یک Route-Map که یک Community روی مسیرهای ورودی تنظیم می‌کند

روی R1، یک route-map که 192.168.60.0/24 را تطبیق می‌دهد و یک مقدار community خاص روی آن تنظیم می‌کند پیکربندی کن.

وظیفه ۲: اعمال Route-Map روی جلسه eBGP ورودی

route-map را ورودی روی جلسه R1 با شریک خارجی اعمال کن.

وظیفه ۳: فعال‌کردن انتشار Community به‌سمت R2

جلسه iBGP R1 با R2 را طوری پیکربندی کن که واقعاً ویژگی‌های community را بفرستد، چون این به‌طور پیش‌فرض فعال نیست.

وظیفه ۴: تأیید دریافت Community توسط R2

تأیید کن R2 مقدار community متصل به مسیر را می‌بیند.

وظیفه ۵: پیکربندی R2 برای اعمال یک سیاست صرفاً بر اساس Community

روی R2، یک route-map که فقط با مقدار community (نه پیشوند اصلی) تطبیق دارد پیکربندی کن و یک local preference متمایز روی آن اعمال کن.

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

R1(config)# ip prefix-list CUSTOMER-ROUTE permit 192.168.60.0/24

R1(config)# route-map TAG-CUSTOMER permit 10
R1(config-route-map)# match ip address prefix-list CUSTOMER-ROUTE
R1(config-route-map)# set community 65050:100
R1(config-route-map)# exit
R1(config)# route-map TAG-CUSTOMER permit 20
-- توالی ۲۰ بدون match/set هر چیز دیگر را
-- بدون‌تغییر عبور می‌دهد

R1(config)# router bgp 65050
R1(config-router)# neighbor [آدرس شریک] route-map TAG-CUSTOMER in

R1(config-router)# neighbor [آدرس R2] send-community

-- مقادیر community به‌طور پیش‌فرض در
-- به‌روزرسانی‌های BGP فرستاده نمی‌شوند --
-- send-community باید صراحتاً روی هر جلسه‌ای
-- که ویژگی نیاز دارد منتشر شود فعال شود

R2# show ip bgp 192.168.60.0

BGP routing table entry for 192.168.60.0/24
  65099
    [آدرس R1] from [آدرس R1] (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 65050:100
-- R2 به‌درستی تگ community متصل‌شده توسط R1 را
-- دریافت کرد، بدون نیاز R2 به دانستن هیچ‌چیزی
-- درباره منطق تطبیق prefix-list اصلی که آن را
-- ساخت

R2(config)# ip community-list standard CUSTOMER-COMM permit 65050:100

R2(config)# route-map APPLY-CUSTOMER-POLICY permit 10
R2(config-route-map)# match community CUSTOMER-COMM
R2(config-route-map)# set local-preference 150
R2(config-route-map)# exit
R2(config)# route-map APPLY-CUSTOMER-POLICY permit 20

R2(config)# router bgp 65050
R2(config-router)# neighbor [آدرس R1] route-map APPLY-CUSTOMER-POLICY in

R2# show ip bgp 192.168.60.0

BGP routing table entry for 192.168.60.0/24
  65099
    [آدرس R1] from [آدرس R1] (1.1.1.1)
      Origin IGP, metric 0, localpref 150, valid, internal, best
      Community: 65050:100
-- local preference 150 صرفاً با تطبیق تگ
-- community اعمال شد، کاملاً مستقل از هر
-- آگاهی از خود پیشوند 192.168.60.0/24

نکته کلیدی

Community ها عمل طبقه‌بندی یک مسیر را از عمل اعمال سیاست روی آن جدا می‌کنند — یک مسیر یک‌بار تگ‌گذاری می‌شود، معمولاً در لبه شبکه جایی که معیار طبقه‌بندی اصلی به‌طور طبیعی وجود دارد، و هر روتر پایین‌دست سیاست خودش را صرفاً با تطبیق آن تگ اعمال می‌کند، و نیاز به تکرار prefix list ها یا ACL ها در هر نقطه سیاست در سراسر یک شبکه بزرگ را حذف می‌کند؛ send-community باید صراحتاً روی هر جلسه‌ای که تگ نیاز دارد از آن عبور کند پیکربندی شود، چون هرگز به‌طور پیش‌فرض منتشر نمی‌شود.

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

مقالات مرتبط

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

ادامه