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

هدف لب

پیکربندی یک روتر به‌عنوان یک route reflector BGP با دو همتای کلاینت، تأیید اینکه reflector یک مسیر یادگرفته‌شده از یک کلاینت را به دیگری دوباره تبلیغ می‌کند با وجود اینکه هیچ جلسه مستقیمی بین آن دو کلاینت وجود ندارد، و تأیید اینکه این دقیقاً شکست انتشار مشاهده‌شده در لب قبلی را حل می‌کند.

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

لب قبلی نشان داد قانون شبیه-split-horizon iBGP یک mesh کامل از جلسات برای تضمین انتشار مسیر نیاز دارد، که با رشد تعداد روترها در یک AS غیرعملی می‌شود. یک route reflector به‌طور خاص از آن قانون برای کلاینت‌های تعیین‌شده‌اش معاف است، و اجازه می‌دهد یک طراحی iBGP hub-and-spoke به‌جای یک full mesh استفاده شود.

توپولوژی لب

R2 (route reflector) ---- R1 (کلاینت)
R2 (route reflector) ---- R3 (کلاینت)

جلسه مستقیم R1 ---- R3 عمداً پیکربندی‌نشده،
که mesh ناقص لب قبلی را منعکس می‌کند

همه روترها در AS 65010
LAN R1: 192.168.220.0/24

وظیفه ۱: پیکربندی R2 به‌عنوان یک Route Reflector

روی R2، هم R1 و هم R3 را به‌عنوان کلاینت‌های route reflector درون همان جلسات iBGP از قبل برقرار پیکربندی کن.

وظیفه ۲: تبلیغ شبکه R1

LAN R1 را به BGP تبلیغ کن، دقیقاً مانند لب قبلی.

وظیفه ۳: تأیید دریافت مسیر توسط R2

تأیید کن R2 مسیر را از R1 مانند قبل یاد می‌گیرد.

وظیفه ۴: تأیید یادگیری مسیر توسط R3 اکنون بدون یک جلسه مستقیم R1

تأیید کن R3 این‌بار مسیر را دریافت می‌کند، با وجود اینکه همچنان هیچ جلسه مستقیمی با R1 ندارد.

وظیفه ۵: تأیید ویژگی‌های مسیر بازتاب‌شده

مسیر روی R3 را برای ویژگی‌های originator ID و cluster list که آن را به‌عنوان رله‌شده-توسط-reflector علامت‌گذاری می‌کنند بررسی کن.

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

R2(config)# router bgp 65010
R2(config-router)# neighbor 10.1.1.1 route-reflector-client
R2(config-router)# neighbor 10.2.2.2 route-reflector-client

-- هر دو جلسه موجود از لب قبلی صرفاً به‌عنوان
-- کلاینت پرچم‌گذاری می‌شوند -- بدون جلسات
-- جدید یا حذف‌شده، فقط یک تغییر رفتاری در
-- اینکه R2 چگونه مسیرهای دریافتی از این
-- همتایان را رفتار می‌کند

R1(config)# router bgp 65010
R1(config-router)# network 192.168.220.0 mask 255.255.255.0

R2# show ip bgp

   Network             Next Hop        Metric  LocPrf  Weight  Path
*>i 192.168.220.0/24   10.1.1.1        0       100         0   i
-- R2 مسیر را از R1 یاد می‌گیرد، بدون تغییر
-- نسبت به قبل

R3# show ip bgp

   Network             Next Hop        Metric  LocPrf  Weight  Path
*>i 192.168.220.0/24   10.1.1.1        0       100         0   i
-- برخلاف لب قبلی، R3 اکنون با موفقیت مسیر را
-- یاد می‌گیرد، با وجود اینکه هیچ جلسه مستقیمی
-- با R1 ندارد -- نقش route reflector R2 اجازه
-- داد این مسیر یادگرفته‌شده-توسط-iBGP را به
-- کلاینت دیگرش، R3، فوروارد کند

R3# show ip bgp 192.168.220.0 255.255.255.0

BGP routing table entry for 192.168.220.0/24
  Refresh Epoch 1
  Local
    10.1.1.1 (metric 0) from 10.2.2.1 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.1.1.1, Cluster list: 2.2.2.2
-- Originator تأیید می‌کند مسیر واقعاً در
-- ابتدا از R1 (1.1.1.1) آمده، و Cluster list
-- نشان می‌دهد R2 (2.2.2.2) reflectorای است
-- که آن را رله کرده -- این ویژگی‌ها به‌طور
-- خاص برای جلوگیری از حلقه‌های مسیریابی
-- بازتاب‌شده در توپولوژی‌های چند-reflector
-- پیچیده‌تر وجود دارند

نکته کلیدی

کلاینت‌های یک route reflector اصلاً نیازی به جلسه با یکدیگر ندارند — فقط با خود reflector — و آنچه در غیر این صورت یک نیازمندی full-mesh N-مجذور می‌بود را به یک طراحی hub-and-spoke ساده تقلیل می‌دهند؛ ویژگی‌های originator ID و cluster list دقیقاً به این دلیل وجود دارند که این شل‌سازی قانون split-horizon پتانسیل حلقه را در استقرارهای بزرگ‌تر با چند reflector دوباره معرفی می‌کند، و این ویژگی‌ها چیزی هستند که BGP از آن‌ها برای تشخیص و جلوگیری از آن استفاده می‌کند.