Я чув, як тут термін "сервер маршрутів" і "переглядає скло". Що вони, і чому я повинен дбати?

(Зауважте, що ці два терміни часто використовуються взаємозамінно, що може призвести до певної плутанини.)

Дивлячись окуляри

Оглядове скло - це звичайно веб-сайт (найчастіше CGI), який взаємодіє з маршрутизаторами, якими володіє і управляється одним провайдером або іншим мережевим оператором. Більшість випадків вони є загальнодоступними, але можуть бути випадки, коли їх немає. Оглядове скло забезпечує перегляд (у формі веб-сайту) таблиці BGP певного маршрутизатора в мережі оператора. Найчастіше оглядові скляні реалізації включатимуть і інші утиліти, наприклад, можливість запустити трасування в пункт призначення, як ніби він запускався з самого маршрутизатора оператора мережі. Окуляри корисні, оскільки вони надають перспективу таблиці BGP вище за течією. Рівень 3, відомий американський перевізник першого рівня, має доступні окуляри. Це широко використовувані засоби усунення несправностей.

Маршрутні сервери

Термін "сервер маршрутів" перетворився на два різних аспекти, які будуть пояснені. Я визначаю два "підтипи" сервера маршрутів, які повинні зробити розрізнення більш чітким. Ці визначення є моїми власними і використовуються лише для того, щоб спробувати розвіяти будь-яку можливу плутанину. Насправді сервер загальнодоступних маршрутів також зазвичай називають "колекціонером маршрутів" або "сервером перегляду маршрутів" (останній походить від проекту " Університети штату Орегон" .

Загальнодоступний сервер маршрутів

Це системи (як правило, маршрутизатори, але деякі існують із запуском демонів маршрутизації з відкритим кодом), які є загальнодоступними, часто через Telnet, і одна також здатна запускати пінг, трасерувати та "показувати ip bgp" (також є пара Juniper сервери маршрутів там, не хвилюйтесь!). Різниця між сервером загальнодоступних маршрутів і оглядовим склом (окрім LG, який має чудовий CGI) полягає в тому, що широкий спектр мереж (включаючи деякі оператори першого рівня) приглядаються до маршрутного сервера, тому існує "загальна" більша картина які префікси надходять із яких ASN. Політика авторизації команд залежить від сервера маршрутів до сервера маршрутів. Ось список серверів маршрутів IPv4 . Вони також мають окрему сторінку з маршрутизаторами IPv6.маршрутний сервер , можна розглядати оглядовий стакан як передній перехід до сервера маршрутів, будь то сам сервер маршрутів загальнодоступним або приватним.

Ви не можете запустити оглядовий стакан на загальнодоступному сервері маршрутів?

Ви можете, але зазвичай люди, які працюють в окулярах, - це ті, які можуть дозволити собі працювати та підтримувати сервери, на яких працюють окуляри. З сервером загальнодоступних маршрутів все, що вам потрібно - це маршрутизатор (або сервер, на якому працює демон маршрутизації з відкритим кодом), хороша політика AAA та деякі люди, які готові надати вам канали BGP. Також важливо зазначити, що деякі мережеві оператори також розміщують загальнодоступні сервери маршрутів, і ви можете навіть натрапити на деяких операторів, які керують сервером маршрутів на додаток до окуляру.

Сервер маршрутів IXP

Ця версія сервера маршрутів дещо відрізняється. Що стосується спільних тканин для пірінгу на IXP, то бар'єр для вступу в організацію для початку пірінгу нижчий. У вас є один порт (який вам продає IXP), підключений до локальної мережі IXP, і вам надається IP-адреса IXP. Тепер ви можете заглянути на тканину з ким-небудь ще; порівняти це з PNI, який передбачає окремий виділений фізичний зв'язок між вами та іншою сутністю. Підключившись до однорангової локальної мережі IXP, окрім того, що ваш єдиний порт є вузьким місцем, вам доведеться вручну налаштувати сеанси eBGP з тим, з ким ви хочете заглянути. Це називається двостороннім взаємозв'язком- один сеанс між вами та однолітками, і лише ви та повідомлення про обмін одноранговими. Якщо IXP має багато членів, це може стати громіздким. У цьому випадку маршрутний сервер, як правило, розгортається на IXP для того, щоб він був «єдиним списком» для організації, яка створила сеанс eBGP, щоб отримувати префікси від того, хто ще заглядає з сервером маршруту. Це називається багатостороннім взаємозв’язком . Один сеанс BGP між вами та сервером маршруту, і ви отримуєте анонси всіх інших, які також співпадають із сервером маршрутів.

Деякі організації будуть розраховувати на сеанси маршрутів eBGP на сервері маршрутів, а інші використовуватимуть його як резервну копію для своїх існуючих eBGP-пирингів на тканині IXP. Більшість IXP матимуть надлишкові маршрутизатори і пропонують організаціям одночасно обидві, якщо вони взагалі вглядаються з серверами маршрутів.

Що з BGP?

Багатосторонній пірінг із використанням маршрутних серверів приносить цікаві проблеми щодо BGP. Сам маршрутний сервер є динаміком eBGP, однак повинні бути конкретні міркування щодо маршрутного сервера та багатостороннього BGP-пирінгу. Деякі з цих правил будуть нагадувати відображення маршруту iBGP, і подібності дійсно багато. Нещодавно була проведена робота зі стандартизації поведінки маршрутного сервера, коли мова йде про ці особливості. Тут слід зазначити наступні застереження:

• Атрибут NEXT_HOP - Цей атрибут повинен передаватися немодифікованим між сервером маршруту та його клієнтами. Хоча сама реалізація сервера маршрутів не змінює цей атрибут, все-таки найкраща практика встановити "next-hop-self" на сесіях eBGP з вашого маршрутизатора на сервер маршрутів.
• Атрибут AS_PATH - знову ж таки, оскільки сервер маршрутів призначений бути прозорим і не брати участі в будь-яких рішеннях про маршрутизацію, а зміна цього атрибута може вплинути на процес кращого прийняття рішень щодо клієнтів маршрутного сервера, реалізація сервера маршрутів не повинна змінювати цей атрибут. Крім того, маршрутний сервер не надсилатиме власним оновленням ASN у оновленнях BGP своїм клієнтам, тому потрібно встановити на маршрутизаторі клієнта "не bgp примусово-перше-як" (специфічне для Cisco), щоб дозволити сеансу eBGP форми між клієнтом та сервером маршрутів.
• Атрибут MULTI_EXIT_DISC - MED - це ще один атрибут, який слід поширювати на клієнтів сервера маршрутів без зміни сервера маршрутів, оскільки він також може впливати на кращий процес вибору шляху.
• Атрибути спільнот - їх не слід змінювати сервером маршрутів, якщо спільнота (або спільноти) не призначені для обробки самим сервером маршрутів. Зазвичай спільноти використовуються реалізаціями сервера маршрутизації IXP, щоб дозволити колегам сервера маршрутів маніпулювати оновленнями маршрутизації для інших однорангових серверів маршрутів.

Важливо пам’ятати два відмінності щодо реалізації сервера маршрутизації IXP:

• Маршрутний сервер не бере участі ні в маршрутизації, ні в переадресації. Він повинен бути максимально прозорим.
• Клієнти сервера маршрутів залежать від сервера маршрутів для здійснення фільтрації вихідних даних для них.

Параметри реалізації сервера маршрутизації IXP

Зазвичай оператори IXP розгортають демон маршрутизації з відкритим кодом у якості серверів маршрутів. Є три популярні варіанти:

1. Quagga, конкретно bgpd . Працює на Linux та BSD. Це було довше, і, мабуть, є найбільше доступної інформації. Протягом багатьох років було декілька вил Quagga , серед яких поїзд зі спонсорованою розробкою EuroIX , поїзд, розроблений групою маршрутизації з відкритим кодом (яка більше спрямована на поліпшення функціональності IGP за допомогою OSPF та ISIS), і Quagga-RE (випуск Інженерний) поїзд, який має експериментальні особливості. Google також створив власну вилку Quagga. Quagga bgpd підтримує як IPv6, так і IPv4, проте більшість операторів IXP (і навіть деякі технічні працівники Quagga) не рекомендують використовувати "основний" потяг Quagga для роботи маршрутного сервера на IXP.

2. ПТІЧКА . Працює на Linux та BSD. BIRD здобув досить велику популярність завдяки своїй стабільності та потужній мові та можливостям фільтрації, на додаток до дуже хорошої системи планування. Опубліковано декілька опублікованих порівнянь та масштабних тестів між Quagga та BIRD. Загалом, BIRD, як правило, більш стабільний і не такий сприйнятливий до процесора та пам'яті, як Quagga. І BIRD, і Quagga є однопотоковими, однак це навмисно. Крім того, хоча BIRD підтримує і IPv4, і IPv6, він вимагає двох різних процесів (компільованих бінарних файлів) для IPv4 і IPv6.

3. OpenBGPD . Тільки BSD . OpenBGPD - єдиний багатопотоковий демон з відкритим кодом BGP. Відомо, що вона досить стабільна під навантаженням, проте підтримка TCP MD5 дещо погана.

Окрім демонів з відкритим кодом, Cisco також пропонує реалізацію маршрутного сервера для IOS-XE , який працює на платформі ASR. На момент написання цього документа Juniper не пропонує реалізацію маршрутного сервера на своєму апаратному чи операційній системі, але це може змінитися в майбутньому.

З точки зору оцінки демона маршрутизації з відкритим кодом, що стосується керування пам'яттю та архітектури, можна сміливо припустити, що BIRD> OpenBGPD> Quagga, однак, як повідомляється, платформа ASR та IOS-XE також набагато більш здатні до масштабів порівняно з відкритими Доступні параметри демона-джерела.

Я сподіваюся, що це проливає трохи світла на маршрутні сервери / окуляри загалом.