BGP Route Reflectors
Если вкратце, то RR работает схоже с Backbone Area в OSPF, распространяя маршруты, полученные от других iBGP-пиров. Однако, кластеры можно настраивать иерархически, как показано на рисунке выше. Т.е. RT.SPB.OBV будет являться одновременно RR для кластера 10.0.0.201 и клиентом кластера 10.0.0.202.
Таким образом, иерархически, сеть RR будет выглядеть вот так:
Настройка RT.SPB.MIR:
В данном случае мы настроили одну единственную группу с указанием кластера. На RT.SPB.OBV необходимо будет указать 2 группы. Одна группа без кластера, в которой RT.SPB.OBV будет просто клиентом кластера RT.SPB.MIR, а другую, где он сам будет являться RR для клиентов. Роутер RT.SPB.LNX же будет просто клиентом RT.SPB.MIR.
Настройка RT.SPB.OBV:
Далее соответственно настраиваем клиентов как клиентов, просто указывая Loopback'и соседей.
Но, в данной топологии есть проблема - это один единственный RR в кластере 10.0.0.201. Как пример можно посмотреть что будет если отключить RT.SPB.OBV и AS8001 в общей топологии сети. До отключения AS8000:
После отключения AS8000:
Теперь предположим, что у нас упал RR - RT.SPB.OBV:
Т.е. нам необходим резервный RR. Пусть им станет RT.SPB.LNX. Для того, чтобы в сети был ещё один RR, необходимо прописать ему тот же кластер, что и другого. Также между RReflector´ами в одном кластере должна быть Full-Mesh топология, при этом другой RR должен быть в той же группе, где указан кластер ID. Только в таком случае не будет петель, так как в RFC4456 сказано, что RR при получении маршрута от другого RR в этом же кластере отбросит маршрут.
Донастроим топологию:
Теперь заново отключим AS8000 и посмотрим маршруты:
Видно, что маршрут получен от 10.0.0.201 (RT.SPB.OBV) и 10.0.0.204 (RT.SPB.LNX). Теперь выключим RT.SPB.OBV:
Как видно всё работает. Теперь схема выглядит так:
Также нужно настроить iBGP внутри AS9002, сделать это можно просто указав в качестве neighbor'ов - IP интерфейсов ge-0/0/0, а type для этих групп указать interal. Больше можно ничего не указывать, чтобы не настраивать лишее. Это будет не совсем правильно, но для связности между ними пойдёт.
Почему нельзя делать один и тот же cluster-id
Если мы укажем себя как клиента и как route-reflector в одном кластере, то сработает защита от петель и мы не получим маршруты на нашем RR в том же кластере, что и другой RR.
Пример конфига (IP каждого роутера можно узнать по Local-Address):
neighbor 192.168.0.5 - это тоже RR, который работает в том же самом кластере:
В данном случае мы увидим на RT.SPB.LNX следующую таблицу маршрутизации (маршруты от RT.SPB.LNX не приняты):
Единственное решение - поменять cluster для любого RR на уникальный:
Результат:
Last updated