Доброго времени, господа.
Сейчас мы рассмотрим достаточно интересную тему, которая называется 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), может быть несколько, а может вобще иерархично, давайте посмотрим на правила каждого:
— 1 RR
Если маршрут был получен от своего клиента, то такой маршрут будет перенаправлен не клиентам и своим клиентам.
Если RR получил маршрут от не клиента (от IBGP пира), то такой маршрут будет разослан только своим клиентам.
Если RR получил маршрут от EBGP соседа, то он отсылает этот маршрут всем не клиентам и всем клиентам.
— 2 и более RR
Все RR нужно сконфигурировать с одним Cluster_ID
Все RR с одинаковым Cluseter_ID должны быть Full MEsh
RR клиент должен быть full mesh со всеми RR этого Cluster_ID
— Иерархичные RR
Все роутеры должны быть настроены с одинаковым 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 и правильном планировании таких проблем возникать не должно.
