سیسکو BGP Route Reflector چیست ؟

قانون اصلی iBGP این است که روتر، مسیری را که از یک همسایه iBGP یاد گرفته، به همسایه iBGP دیگر اعلام نمی‌کند. این قانون جلوی loop را می‌گیرد، اما نتیجه‌اش این است که همه روترهای BGP یک AS باید با همه دیگران همسایه باشند (Full Mesh). با ۵ روتر یعنی ۱۰ نشست؛ با ۲۰ روتر ۱۹۰ نشست، و هر روتر جدید یعنی تغییر کانفیگ روی همه. BGP Route Reflector راه‌حل استاندارد این مشکل است.

در این مطلب قانون Split Horizon در iBGP ، نقش‌های Route Reflector و Client ، قواعد Reflect کردن، سازوکار جلوگیری از loop (Originator-ID و Cluster-List) ، کانفیگ کامل، افزونگی با دو RR و خطاهای رایج طراحی را مرور می‌کنیم.

BGP Route Reflector سیسکو — BGP Route Reflector

BGP Route Reflector در یک نگاه

مسئله	Full Mesh در iBGP ؛ تعداد نشست‌ها n(n-1)/2
راه‌حل	یک یا چند RR ؛ هر Client فقط با RRها همسایه است
استاندارد	RFC 4456
دستور	`neighbor X route-reflector-client` فقط روی RR
جلوگیری از loop	Attributeهای ORIGINATOR_ID و CLUSTER_LIST
توصیه	حداقل دو RR برای افزونگی

فهرست مطالب

مسئله Full Mesh
قواعد Reflect کردن
جلوگیری از Loop
کانفیگ
افزونگی با دو RR
نکته‌های طراحی
بررسی
پرسش‌های متداول

مسئله Full Mesh

iBGP Full Mesh بدون Route Reflector — iBGP بدون RR : همه روترها باید با هم همسایه باشند

تعداد روتر iBGP	نشست‌ها در Full Mesh	نشست‌ها با یک RR
5	10	4
10	45	9
20	190	19
50	1225	49

با Route Reflector ، هر روتر فقط با RR همسایه می‌شود و RR مسیرها را برای بقیه «منعکس» (Reflect) می‌کند. اضافه کردن روتر جدید فقط یک خط کانفیگ روی RR می‌خواهد.

iBGP با Route Reflector — iBGP با RR : هر روتر فقط با Route Reflector همسایه است

قواعد Reflect کردن

RR سه نوع همسایه دارد: Client ، Non-Client (همسایه iBGP عادی) و eBGP. رفتار RR با مسیر دریافتی بسته به منبع آن:

مسیر از	به Clientها	به Non-Clientها	به همسایه‌های eBGP
همسایه eBGP	بله	بله	بله
Client	بله (به‌جز خود فرستنده)	بله	بله
Non-Client	بله	خیر	بله

یعنی فقط مسیری که از یک Non-Client آمده به Non-Clientهای دیگر منعکس نمی‌شود؛ پس Non-Clientها همچنان باید بین خودشان Full Mesh باشند. نکته مهم: RR فقط بهترین مسیر خودش را منعکس می‌کند و Attributeها (از جمله Next-Hop) را تغییر نمی‌دهد.

جلوگیری از Loop

وقتی قانون Split Horizon شکسته می‌شود، باید روش دیگری جلوی loop را بگیرد. RFC 4456 دو Attribute اضافه می‌کند:

ORIGINATOR_ID : Router-ID روتری که مسیر را اول به داخل AS آورده. اگر روتری مسیری با ORIGINATOR_ID خودش ببیند، آن را دور می‌ریزد.
CLUSTER_LIST : فهرست Cluster-IDهای RRهایی که مسیر از آن‌ها عبور کرده. اگر RR شناسه خودش را در این فهرست ببیند، مسیر را دور می‌ریزد.

کانفیگ

در شکل زیر R2 نقش RR را دارد و R1 و R3 Client هستند. توجه کنید دستور route-reflector-client فقط روی RR زده می‌شود و Clientها پیکربندی معمولی iBGP دارند.

مثال پیاده‌سازی BGP Route Reflector — نمونه: R2 به‌عنوان RR ، و R1 و R3 به‌عنوان Client

! ---------- R2 : Route Reflector ----------
router bgp 65000
 bgp router-id 10.255.0.2
 neighbor 10.255.0.1 remote-as 65000
 neighbor 10.255.0.1 update-source Loopback0
 neighbor 10.255.0.3 remote-as 65000
 neighbor 10.255.0.3 update-source Loopback0
 address-family ipv4
  neighbor 10.255.0.1 activate
  neighbor 10.255.0.1 route-reflector-client
  neighbor 10.255.0.3 activate
  neighbor 10.255.0.3 route-reflector-client
!
! ---------- R1 : Client ----------
router bgp 65000
 bgp router-id 10.255.0.1
 neighbor 10.255.0.2 remote-as 65000
 neighbor 10.255.0.2 update-source Loopback0
 address-family ipv4
  neighbor 10.255.0.2 activate
  network 192.168.1.0 mask 255.255.255.0

برای شبکه‌ای با تعداد زیاد Client ، از peer-group یا peer-template استفاده کنید تا کانفیگ کوتاه و یکدست بماند:

router bgp 65000
 neighbor RR-CLIENTS peer-group
 neighbor RR-CLIENTS remote-as 65000
 neighbor RR-CLIENTS update-source Loopback0
 neighbor 10.255.0.1 peer-group RR-CLIENTS
 neighbor 10.255.0.3 peer-group RR-CLIENTS
 address-family ipv4
  neighbor RR-CLIENTS route-reflector-client
  neighbor 10.255.0.1 activate
  neighbor 10.255.0.3 activate

افزونگی با دو RR

با یک RR ، خرابی آن یعنی قطع کل iBGP. همیشه دست‌کم دو RR داشته باشید و هر Client با هر دو همسایه باشد. دو رویکرد رایج:

Cluster-ID یکسان (bgp cluster-id 1.1.1.1 روی هر دو): مصرف حافظه کمتر، چون RRها مسیرهای منعکس‌شده یکدیگر را دور می‌ریزند؛ اما دو RR باید نشست مستقیم با هم داشته باشند.
Cluster-ID جدا (پیش‌فرض، برابر Router-ID): افزونگی بیشتر در برابر خرابی‌های جزئی، با کمی حافظه بیشتر. رویکرد پیش‌فرض و توصیه‌شده در بیشتر طراحی‌های امروزی.

نکته‌های طراحی

Next-Hop: چون RR ، Next-Hop را عوض نمی‌کند، Clientها باید بتوانند به Next-Hop اصلی (معمولاً IP همسایه eBGP) برسند. روی روتر مرزی neighbor … next-hop-self را برای همسایه‌های iBGP بزنید، یا لینک eBGP را در IGP اعلام کنید.
RR خارج از مسیر ترافیک: RR فقط کنترل‌پلن است و لازم نیست ترافیک از آن عبور کند؛ حتی می‌تواند یک روتر مجازی (مثل Catalyst 8000V) باشد.
انتخاب مسیر غیربهینه: چون RR بهترین مسیر را از دید خودش منعکس می‌کند، Clientی که جای دیگری از شبکه است ممکن است مسیر غیربهینه بگیرد. قابلیت‌هایی مثل BGP Add-Path و BGP Optimal Route Reflection برای همین ساخته شده‌اند.
همین طراحی در EVPN هم به کار می‌رود؛ در فابریک VXLAN ، spineها نقش RR را برای leafها دارند؛ ببینید آشنایی با سیسکو VXLAN.

بررسی

R2# show ip bgp summary
R2# show ip bgp neighbors 10.255.0.1 | include Route-Reflector
  Route-Reflector Client
R1# show ip bgp 192.168.3.0
  Originator: 10.255.0.3, Cluster list: 10.255.0.2

پرسش‌های متداول

Client باید بداند که Client است؟
نه؛ Client کانفیگ عادی iBGP دارد و فقط RR می‌داند چه کسی Client است.

RR جایگزین Confederation است؟
هر دو مشکل Full Mesh را حل می‌کنند. RR ساده‌تر و رایج‌تر است؛ Confederation AS را به چند زیر-AS تقسیم می‌کند و بیشتر در شبکه‌های خیلی بزرگ یا ادغام دو شبکه دیده می‌شود.

مسیر از RR به Client رسید ولی نصب نمی‌شود.
تقریباً همیشه Next-Hop غیرقابل دسترس است؛ show ip bgp را ببینید و next-hop-self یا مسیر IGP به Next-Hop را اضافه کنید.

منابع

مطالب مرتبط: پیاده‌سازی BGP AS Prepend روی روتر سیسکو و BOGON و فیلتر BGP.

مشاوره با AKA NET

برای طراحی BGP در شبکه‌های سازمانی و اپراتوری، Route Reflector و سیاست‌های مسیریابی با آکانت (AKA NET) تماس بگیرید.

تلفن: 09121308444 | ایمیل: aka@aka.ir | aka.ir

سیسکو

آموزش سیسکو معرفی و فروش تجهیزات سیسکو