Если вкратце, то RR работает схоже с Backbone Area в OSPF, распространяя маршруты, полученные от других iBGP-пиров. Однако, кластеры можно настраивать иерархически, как показано на рисунке выше. Т.е. RT.SPB.OBV будет являться одновременно RR для кластера 10.0.0.201 и клиентом кластера 10.0.0.202.
Таким образом, иерархически, сеть RR будет выглядеть вот так:
root@RT.SPB.MIR# edit protocols bgp group rr-BGP
[edit protocols bgp group rr-BGP]
root@RT.SPB.MIR# set local-address 10.0.0.202
[edit protocols bgp group rr-BGP]
root@RT.SPB.MIR# set type internal
[edit protocols bgp group rr-BGP]
root@RT.SPB.MIR# set cluster 10.0.0.202
[edit protocols bgp group rr-BGP]
root@RT.SPB.MIR# set neighbor 10.0.0.201
[edit protocols bgp group rr-BGP]
root@RT.SPB.MIR# set neighbor 10.0.0.204
В данном случае мы настроили одну единственную группу с указанием кластера. На RT.SPB.OBV необходимо будет указать 2 группы. Одна группа без кластера, в которой RT.SPB.OBV будет просто клиентом кластера RT.SPB.MIR, а другую, где он сам будет являться RR для клиентов. Роутер RT.SPB.LNX же будет просто клиентом RT.SPB.MIR.
Настройка RT.SPB.OBV:
root@RT.SPB.OBV# edit protocols bgp group rr-BGP
[edit protocols bgp group rr-BGP]
root@RT.SPB.OBV# set local-address 10.0.0.201
[edit protocols bgp group rr-BGP]
root@RT.SPB.OBV# set type internal
[edit protocols bgp group rr-BGP]
root@RT.SPB.OBV# set cluster 10.0.0.201
[edit protocols bgp group rr-BGP]
root@RT.SPB.OBV# set neighbor 10.0.0.200
[edit protocols bgp group rr-BGP]
root@RT.SPB.OBV# set neighbor 10.0.0.203
[edit protocols bgp group rr-BGP]
root@RT.SPB.OBV# top
root@RT.SPB.OBV# edit protocols bgp group rr-client
[edit protocols bgp group rr-client]
root@RT.SPB.OBV# set type internal
[edit protocols bgp group rr-client]
root@RT.SPB.OBV# set local-address 10.0.0.201
Далее соответственно настраиваем клиентов как клиентов, просто указывая Loopback'и соседей.
Но, в данной топологии есть проблема - это один единственный RR в кластере 10.0.0.201. Как пример можно посмотреть что будет если отключить RT.SPB.OBV и AS8001 в общей топологии сети. До отключения AS8000:
root@RT.SPB.K12# run show route 8.0.0.0
inet.0: 45 destinations, 47 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/16 *[BGP/170] 00:27:56, localpref 100, from 10.0.0.201
AS path: (65001) 8000 I, validation-state: unverified
> to 10.0.0.10 via ae0.0
[BGP/170] 03:38:26, localpref 100
AS path: 9001 8001 8000 I, validation-state: unverified
> to 9.1.1.0 via ge-0/0/4.0
После отключения AS8000:
root@RT.SPB.K12# run show route 8.0.0.0
inet.0: 43 destinations, 43 routes (43 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/16 *[BGP/170] 00:29:46, localpref 100, from 10.0.0.201
AS path: (65001) 8000 I, validation-state: unverified
> to 10.0.0.10 via ae0.0
Теперь предположим, что у нас упал RR - RT.SPB.OBV:
root@RT.SPB.K12# run show route 8.0.0.0
inet.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 05:04:33, metric 0, tag 0
> to 10.0.0.15 via ae1.0
Донастроим топологию:
root@RT.SPB.OBV# set protocols bgp group rr-BGP neighbor 10.0.0.204
root@RT.SPB.LNX# edit protocols bgp group rr-BGP
[edit protocols bgp group rr-BGP]
root@RT.SPB.LNX# set neighbor 10.0.0.201
[edit protocols bgp group rr-BGP]
root@RT.SPB.LNX# set neighbor 10.0.0.203
[edit protocols bgp group rr-BGP]
root@RT.SPB.LNX# set neighbor 10.0.0.200
[edit protocols bgp group rr-BGP]
root@RT.SPB.LNX# set type internal
[edit protocols bgp group rr-BGP]
root@RT.SPB.LNX# set local-address 10.0.0.204
[edit protocols bgp group rr-BGP]
root@RT.SPB.LNX# set cluster 10.0.0.201
root@RT.SPB.LNX# show | compare
[edit protocols bgp]
group rr-client { ... }
+ group rr-BGP {
+ type internal;
+ local-address 10.0.0.204;
+ cluster 10.0.0.201;
+ neighbor 10.0.0.201;
+ neighbor 10.0.0.203;
+ neighbor 10.0.0.200;
+ }
root@RT.SPB.K12# set protocols bgp group rr-client neighbor 10.0.0.204
root@RT.SPB.STL# set protocols bgp group rr-client neighbor 10.0.0.204
Теперь заново отключим AS8000 и посмотрим маршруты:
root@RT.SPB.K12# run show route 8.0.0.0
inet.0: 38 destinations, 40 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/16 *[BGP/170] 00:12:15, localpref 100, from 10.0.0.201
AS path: (65001) 8000 I, validation-state: unverified
> to 10.0.0.10 via ae0.0
[BGP/170] 00:02:37, localpref 100, from 10.0.0.204
AS path: (65001) 8000 I, validation-state: unverified
> to 10.0.0.10 via ae0.0
Видно, что маршрут получен от 10.0.0.201 (RT.SPB.OBV) и 10.0.0.204 (RT.SPB.LNX). Теперь выключим RT.SPB.OBV:
root@RT.SPB.K12# run show route 8.0.0.0
inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/16 *[BGP/170] 00:02:43, localpref 100, from 10.0.0.204
AS path: (65001) 8000 I, validation-state: unverified
> to 10.0.0.10 via ae0.0
Как видно всё работает. Теперь схема выглядит так:
Также нужно настроить iBGP внутри AS9002, сделать это можно просто указав в качестве neighbor'ов - IP интерфейсов ge-0/0/0, а type для этих групп указать interal. Больше можно ничего не указывать, чтобы не настраивать лишее. Это будет не совсем правильно, но для связности между ними пойдёт.
Почему нельзя делать один и тот же cluster-id
Если мы укажем себя как клиента и как route-reflector в одном кластере, то сработает защита от петель и мы не получим маршруты на нашем RR в том же кластере, что и другой RR.
Пример конфига (IP каждого роутера можно узнать по Local-Address):
В данном случае мы увидим на RT.SPB.LNX следующую таблицу маршрутизации (маршруты от RT.SPB.LNX не приняты):
root@RT.SPB.LNX# run show route protocol bgp
inet.0: 36 destinations, 36 routes (33 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
80.0.0.0/24 *[BGP/170] 00:16:23, localpref 100, from 192.168.0.4
AS path: (65000) 8000 I, validation-state: unverified
> to 10.0.0.14 via ae0.0
to 10.0.0.18 via ae2.0
100.8.0.0/24 *[BGP/170] 00:16:23, localpref 100, from 192.168.0.4
AS path: (65000) 8000 I, validation-state: unverified
to 10.0.0.14 via ae0.0
> to 10.0.0.18 via ae2.0
Единственное решение - поменять cluster для любого RR на уникальный:
root@RT.SPB.LNX# run show route protocol bgp
inet.0: 36 destinations, 38 routes (33 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
80.0.0.0/24 *[BGP/170] 00:00:02, localpref 100, from 192.168.0.5
AS path: (65000) 8000 I, validation-state: unverified
> to 10.0.0.14 via ae0.0
[BGP/170] 00:00:10, localpref 100, from 192.168.0.4
AS path: (65000) 8000 I, validation-state: unverified
> to 10.0.0.14 via ae0.0
to 10.0.0.18 via ae2.0
100.8.0.0/24 *[BGP/170] 00:00:02, localpref 100, from 192.168.0.5
AS path: (65000) 8000 I, validation-state: unverified
> to 10.0.0.14 via ae0.0
[BGP/170] 00:00:10, localpref 100, from 192.168.0.4
AS path: (65000) 8000 I, validation-state: unverified
to 10.0.0.14 via ae0.0
> to 10.0.0.18 via ae2.0
Т.е. нам необходим резервный RR. Пусть им станет RT.SPB.LNX. Для того, чтобы в сети был ещё один RR, необходимо прописать ему тот же кластер, что и другого. Также между RReflector´ами в одном кластере должна быть Full-Mesh топология, при этом другой RR должен быть в той же группе, где указан кластер ID. Только в таком случае не будет петель, так как в сказано, что RR при получении маршрута от другого RR в этом же кластере отбросит маршрут.
