چرا iBGP از ابتدا به یک Full Mesh نیاز دارد
BGP یک قانون جلوگیری-از-حلقه خاص برای iBGP شامل میشود، که پیشتر در این مجموعه بحث شد: یک روتر هرگز یک مسیر یادگرفتهشده از طریق iBGP را به یک همتای iBGP دیگر دوباره تبلیغ نمیکند. این قانون وجود دارد چون مسیرهای iBGP هیچ تغییر AS pathای درون همان AS ندارند، که پیشتر در این مجموعه درباره ویژگی AS path بحث شد، پس BGP نمیتواند به تشخیص حلقه AS path به همان شیوهای که بین سیستمهای خودمختار متفاوت انجام میدهد متکی باشد.
پیامد این قانون: تا هر روتر در یک AS واقعاً
هر مسیر را یاد بگیرد، هر روتر باید یک جلسه
iBGP مستقیم با هر روتر دیگر در آن AS داشته
باشد -- چون یک مسیر نمیتواند از میان یک
همتای iBGP میانی رله شودمسئله مقیاسبندی درجهدوم
تعداد جلسات iBGP مورد نیاز برای full mesh:
n(n-1)/2، جایی که n تعداد روترهاست
۴ روتر: ۶ جلسه
۱۰ روتر: ۴۵ جلسه
۵۰ روتر: ۱٬۲۲۵ جلسه
۱۰۰ روتر: ۴٬۹۵۰ جلسهفراتر از صرفاً بار اداری پیکربندی و نگهداری این تعداد عظیم جلسات منفرد، هر جلسه واقعاً حافظه و منابع CPU روی هر روتر مصرف میکند، چون هر روتر باید وضعیت کامل هر یک از بسیاری رابطه همسایه خودش را ردیابی کند -- این واقعاً غیرعملی میشود بسیار پیش از رسیدن به هرجایی نزدیک صد روتر.
Route Reflector ها: شلکردن ایمن قانون جلوگیری-از-حلقه
یک Route Reflector (RR) این را با عملکردن بهعنوان یک استثنای تعیینشده به قانون استاندارد iBGP حل میکند: روترهای خاص پیکربندی میشوند تا مسیرهای یادگرفتهشده-iBGP را به سایر کلاینتهای iBGPشان "منعکس" (دوبارهتبلیغ) کنند، و نیاز آن کلاینتها به همتاسازی مستقیم با هر روتر دیگری در AS را حذف میکنند.
Route-Reflector(config)# router bgp 65001
Route-Reflector(config-router)# neighbor 10.0.0.2 remote-as 65001
Route-Reflector(config-router)# neighbor 10.0.0.2 route-reflector-client
Route-Reflector(config-router)# neighbor 10.0.0.3 remote-as 65001
Route-Reflector(config-router)# neighbor 10.0.0.3 route-reflector-client
-- کلیدواژه route-reflector-client فقط روی خود
-- route reflector اعمال میشود، و مشخص میکند
-- کدام همسایگان کلاینتهای آن هستند -- خود
-- کلاینتها هیچ پیکربندی خاصی فراتر از یک
-- جلسه iBGP کاملاً معمولی نیاز ندارندتعداد جلسه حاصل با یک route reflector:
کلاینتها فقط یک جلسه بهازای هرکدام نیاز دارند،
به RR، بهجای یک جلسه مستقیم با هر روتر دیگر --
که کاهش میدهد آنچه میتوانست دهها یا صدها
جلسه باشد را به صرفاً تعداد کمی بهازای هر کلاینتClient، Non-Client، و نقش خود RR
اصطلاحات Route Reflector:
Client: یک روتر صراحتاً پیکربندیشده با
route-reflector-client، که مسیرهای منعکسشده
را از RR بدون نیاز به جلسات با هر روتر دیگر
دریافت میکند
Non-Client: یک روتر با یک جلسه iBGP معمولی به RR،
اما بدون کلیدواژه client -- این روتر همچنان
به full mesh سنتی با هر روتر non-client دیگر
نیاز دارد، چون RR مسیرها را به non-client ها
از سایر non-client ها منعکس نمیکند
Cluster: RR همراه با همه کلاینتهایش، شناساییشده
با یک Cluster ID مورد استفاده برای تشخیص
حلقههای انعکاس در طراحیهای پیچیدهتر با
چند route reflector افزونهجلوگیری از حلقه درون انعکاس مسیر
از آنجا که انعکاس مسیر عمداً قانون استاندارد "هرگز مسیرهای iBGP را به همتایان iBGP دوباره تبلیغ نکن" را میشکند، دو ویژگی جدید BGP بهطور خاص برای جلوگیری از حلقههایی که این شلسازی در غیر این صورت میتوانست معرفی کند وجود دارند.
Originator ID: شناسه روتر منبع اصلی یک مسیر
درون AS را شناسایی میکند -- اگر یک روتر
یک مسیر منعکسشده با شناسه روتر خودش بهعنوان
Originator ID دریافت کند، این را بهعنوان
یک حلقه تشخیص میدهد و دور میریزد
Cluster List: از نظر مفهومی مشابه با ویژگی
AS Path، که پیشتر در این مجموعه بحث شد،
اما ردیابی اینکه یک مسیر از میان کدام
خوشههای route reflector عبور کرده -- اگر
یک route reflector Cluster ID خودش را از
قبل حاضر در این لیست ببیند، مسیر را بهعنوان
یک حلقه دور میریزدتأیید عملیات Route Reflector
Route-Reflector# show ip bgp neighbors 10.0.0.2 | include reflector
Route-Reflector Client, for the address family: IPv4 Unicast
Client-Router# show ip bgp 192.168.5.0
BGP routing table entry for 192.168.5.0/24
Local
10.0.0.5 from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.0.0.5, Cluster list: 10.0.0.1حضور یک Originator و Cluster list در جزئیات مسیر تأیید میکند از طریق انعکاس یادگرفته شده بهجای یک جلسه iBGP مستقیم و سنتی — تأیید مفید هنگام تأیید اینکه یک طراحی route reflector واقعاً مسیرها را همانطور که مورد نظر بود منتشر میکند.
Confederation ها: یک رویکرد جایگزین
BGP Confederations همان مسئله مقیاسبندی full-mesh را از طریق یک مکانیزم اساساً متفاوت حل میکنند: تقسیم یک AS بزرگ به چند سیستم خودمختار زیرمجموعه کوچکتر، با جلسات شبیه-eBGP (هرچند با استفاده از یک نوع خاص آگاه-از-confederation) بین sub-AS ها، در حالی که کل confederation همچنان بهعنوان یک AS واحد به دنیای خارج ظاهر میشود.
Router(config)# router bgp 65501
Router(config-router)# bgp confederation identifier 65001
Router(config-router)# bgp confederation peers 65502 65503
-- 65501، 65502، 65503 شمارههای sub-AS خصوصی
-- هستند، فقط قابلمشاهده درون شبکه خود این سازمان
-- 65001 شماره AS واحدی است که دنیای خارج
-- واقعاً وقتی از طریق eBGP معمولی با این سازمان
-- همتا میشود میبیندچرا این نیازمندی مش را کاهش میدهد:
full mesh همچنان مورد نیاز است، اما فقط درون
هر sub-AS کوچکتر، نه در سراسر کل AS بزرگ اصلی --
تقسیم ۱۰۰ روتر به ۴ sub-AS با ۲۵ روتر هرکدام
تعداد کل جلسات مش را از n(n-1)/2 برای ۱۰۰ روتر
به فقط ۴ مش جداگانه با ۲۵ روتر هرکدام کاهش
میدهد، یک تعداد کلی بهطور چشمگیر کوچکترمقایسه Route Reflector ها و Confederation ها
Route Reflector ها:
- پیادهسازی سادهتر روی یک شبکه موجود، چون
فقط نیازمند تغییرات پیکربندی روی خود روترهای
reflector تعیینشده است
- روترهای کلاینت اساساً هیچ پیکربندی خاصی
نیاز ندارند
- رایجترین راهحل مستقر در شبکههای
بزرگمقیاس دنیای واقعی
Confederation ها:
- نیازمند دوباره-شمارهگذاری روترها به گروههای
sub-AS است، یک تلاش بازطراحی قابلتوجهتر
- یک تقسیم بصری/اداری روشنتر فراهم میکند که
میتواند با ساختار داخلی خود یک سازمان
هماهنگ باشد (مثلاً sub-AS جداگانه بهازای
هر منطقه یا مرکز داده)
- کمتر رایج مستقر میشود نسبت به route
reflector ها در عمل، بهدلیل تلاش
بازپیکربندی بیشتر درگیرچرا هر دو راهحل همان محدودیت بنیادین را برطرف میکنند
هم route reflector ها و هم confederation ها بهطور خاص وجود دارند تا همان قانون جلوگیری-از-حلقه iBGP زیربنایی بحثشده در ابتدای این مقاله را دور بزنند، با استفاده از مکانیزمهای کاملاً متفاوت — یکی قانون انتشار را برای روترهای تعیینشده شل میکند، دیگری خود AS را به قطعات کوچکتری بازساختاردهی میکند که full mesh در آنها بهطور محلی عملی باقی میماند. درک این علت ریشهای مشترک، بهجای صرفاً حفظکردن نحو پیکربندی هر راهحل، چیزی است که به یک مهندس اجازه میدهد بهدرستی تشخیص دهد کدام رویکرد بهترین تناسب را با توپولوژی موجود و ساختار اداری یک شبکه خاص دارد وقتی full mesh استاندارد iBGP نگهداشتنش غیرعملی شده است.