Доброго часу, панове.
Зараз ми розглянемо досить цікаву тему, яка називається route reflector.
Але спочатку давайте поступово до неї підійдемо.
Є у нас дуже багато роутерів, а BGP говорить про те, що повинна бути Full Mesh.
Уявімо що у нас 20 роутерів, Full Mesh, це скільки повинно бути у нас прописано TCP сесій? Формула проста: n * (n-1) / 2, разом: 190 сесій, багато, чи не так?
Так само мінусом в такій мережі є те, що дуже багато дуплікатний роут трафіку.
Все це вирішується двома механізмами:
- Route Reflector
- Confederation (sub-AS)
Розглянемо і те й інше, але почнемо з рефлекторів.
IBGP Split horizon говорить, що якщо ми отримуємо маршрут по IBGP, то ми нікому цей маршрут більше не посилаємо, а навіщо? у нас же Full Mesh. Значить нам це потрібно змінити 🙂
Є у нас купа роутерів, нам потрібно вибрати один роутер, і зробити його сервером (дзеркалом), кожен роутер матиме тільки один лінк до цього сервера, такі роутери називаються клієнтами. Такий сервер (reflector) і клієнти в сукупності називаються кластерами.
Тепер, отримуючи маршрут Route Reflector відправляє своїм клієнтам цей маршрут, клієнт отримує і не відправляє нікому, адже у нього немає лінків більше ні з ким.
Таким чином очнь істотно скорочується кількість настройки і звичайно ж TCP сесій між бенкетами.
В нашій AS може бути 1 RR (Route reflector), може бути кілька, а може вобще ієрархічно, давайте подивимося на правила кожного:
Якщо маршрут був отриманий від свого клієнта, то такий маршрут буде перенаправлений не клієнт і своїм клієнтам.
Якщо RR отримав маршрут від не клієнт (від IBGP бенкету), то такий маршрут буде розісланий тільки своїм клієнтам.
Якщо RR отримав маршрут від EBGP сусіда, то він відсилає цей маршрут всім не клієнтам і всім клієнтам.
Всі RR потрібно конфігурувати з одним Cluster_ID
Всі RR з однаковим Cluseter_ID повинні бути Full MEsh
RR клієнт повинен бути full mesh з усіма RR цього Cluster_ID
Всі роутери повинні бути налаштовані з однаковим CLUSTER_ID
RR клієнти повинні бути full mesh з RR
RR не повинні бути Full-Mesh між собою в разі ієрархічності, ієрархічність не має обмежень по глибині.
Теоретично, використовуючи RR, можна отримати петлі, BGP надає два механізму захисту від петель, це origitator_id і cluster_list.
Наприклад, у нас є кілька кластерів, для того щоб відстежити петлі, необхідний атрибут, який відзначав би через які кластера проходить маршрут (схоже на AS-PATH), це відстежується через cluster-list, RR дивиться і іщіт там свій CLUSTER_ID, якщо він його там знаходить, то маршрут нікому не надсилається, просто відкидається.
ORIGINATOR_ID це не транзитивний атрибут, цей атрибут є ROUTER_ID маршрутизатора який створив цей маршрут, якщо оновлення прийшло від кого-то і роутер бачити той же у вигляді originator_id себе, то такий маршрут відкидається.
Тобто cluster_list це захист від петель між кластерами, а originator_id всередині кластера. Сенс роботи однаковий.
Потенційні проблеми, які можуть виникнути при використанні RR:
Якщо клієнт не підключений до всіх RR в кластері, то не будуть отримані всі IBGP маршрути.
Якщо клієнт підключений до декількох RR різних кластерів, то будуть приходити дупликатов.
Якщо клієнт кластера підключений ще до інших клієнтів, то будуть приходити так само дупликатов.
При правильному налаштуванні RR і правильному плануванні таких проблем виникати не повинно.