BGP Route Reflectors

Схема сети

Схема кластеров RR

Если вкратце, то RR работает схоже с Backbone Area в OSPF, распространяя маршруты, полученные от других iBGP-пиров. Однако, кластеры можно настраивать иерархически, как показано на рисунке выше. Т.е. RT.SPB.OBV будет являться одновременно RR для кластера 10.0.0.201 и клиентом кластера 10.0.0.202.

Таким образом, иерархически, сеть RR будет выглядеть вот так:

                              RT.SPB.MIR
                             /          \
                   RT.SPB.OBV            RT.SPB.LNX
                  /          \
             RT.SPB.STL   RT.SPB.K12

Настройка RT.SPB.MIR:

[e-mail]# edit protocols bgp group rr-BGP 

[edit protocols bgp group rr-BGP]
[e-mail]# set local-address 10.0.0.202 

[edit protocols bgp group rr-BGP]
[e-mail]# set type internal 

[edit protocols bgp group rr-BGP]
[e-mail]# set cluster 10.0.0.202 

[edit protocols bgp group rr-BGP]
[e-mail]# set neighbor 10.0.0.201 

[edit protocols bgp group rr-BGP]
[e-mail]# 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:

[e-mail]# edit protocols bgp group rr-BGP 

[edit protocols bgp group rr-BGP]
[e-mail]# set local-address 10.0.0.201 

[edit protocols bgp group rr-BGP]
[e-mail]# set type internal 

[edit protocols bgp group rr-BGP]
[e-mail]# set cluster 10.0.0.201 

[edit protocols bgp group rr-BGP]
[e-mail]# set neighbor 10.0.0.200     

[edit protocols bgp group rr-BGP]
[e-mail]# set neighbor 10.0.0.203    

[edit protocols bgp group rr-BGP]
[e-mail]# top 

[e-mail]# edit protocols bgp group rr-client 

[edit protocols bgp group rr-client]
[e-mail]# set type internal 

[edit protocols bgp group rr-client]
[e-mail]# set local-address 10.0.0.201 

Далее соответственно настраиваем клиентов как клиентов, просто указывая Loopback'и соседей.

Но, в данной топологии есть проблема - это один единственный RR в кластере 10.0.0.201. Как пример можно посмотреть что будет если отключить RT.SPB.OBV и AS8001 в общей топологии сети. До отключения AS8000:

[e-mail].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:

[e-mail].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:

[e-mail].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

Т.е. нам необходим резервный RR. Пусть им станет RT.SPB.LNX. Для того, чтобы в сети был ещё один RR, необходимо прописать ему тот же кластер, что и другого. Также между RReflector´ами в одном кластере должна быть Full-Mesh топология, при этом другой RR должен быть в той же группе, где указан кластер ID. Только в таком случае не будет петель, так как в RFC4456 сказано, что RR при получении маршрута от другого RR в этом же кластере отбросит маршрут.

Донастроим топологию:

[e-mail]# set protocols bgp group rr-BGP neighbor 10.0.0.204     

[e-mail]# edit protocols bgp group rr-BGP 

[edit protocols bgp group rr-BGP]
[e-mail]# set neighbor 10.0.0.201 

[edit protocols bgp group rr-BGP]
[e-mail]# set neighbor 10.0.0.203    

[edit protocols bgp group rr-BGP]
[e-mail]# set neighbor 10.0.0.200    

[edit protocols bgp group rr-BGP]
[e-mail]# set type internal 

[edit protocols bgp group rr-BGP]
[e-mail]# set local-address 10.0.0.204 

[edit protocols bgp group rr-BGP]
[e-mail]# set cluster 10.0.0.201 

[e-mail]# 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;
+    }

[e-mail].K12# set protocols bgp group rr-client neighbor 10.0.0.204 

[e-mail]# set protocols bgp group rr-client neighbor 10.0.0.204 

Теперь заново отключим AS8000 и посмотрим маршруты:

[e-mail].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:

[e-mail].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

Как видно всё работает. Теперь схема выглядит так:

                              RT.SPB.MIR
                             /          \
                   RT.SPB.OBV————————————RT.SPB.LNX
                  /     \                   /      \
        RT.SPB.STL   RT.SPB.K12        RT.SPB.STL   RT.SPB.K12

Также нужно настроить iBGP внутри AS9002, сделать это можно просто указав в качестве neighbor'ов - IP интерфейсов ge-0/0/0, а type для этих групп указать interal. Больше можно ничего не указывать, чтобы не настраивать лишее. Это будет не совсем правильно, но для связности между ними пойдёт.

Почему нельзя делать один и тот же cluster-id

Если мы укажем себя как клиента и как route-reflector в одном кластере, то сработает защита от петель и мы не получим маршруты на нашем RR в том же кластере, что и другой RR.

Пример конфига (IP каждого роутера можно узнать по Local-Address):

[e-mail]# show protocols bgp group iBGP
type internal;
local-address 192.168.0.7;
export iBGP-export;
neighbor 192.168.0.4 {
    cluster 192.168.0.5;
}
neighbor 192.168.0.6 {
    cluster 192.168.0.5;
}
neighbor 192.168.0.8;
neighbor 192.168.0.5 {
    cluster 192.168.0.5;
}

neighbor 192.168.0.5 - это тоже RR, который работает в том же самом кластере:

[e-mail]# show protocols bgp group iBGP
type internal;
local-address 192.168.0.5;
export iBGP-export;
neighbor 192.168.0.4 {
    cluster 192.168.0.5;
}
neighbor 192.168.0.6 {
    cluster 192.168.0.5;
}
neighbor 192.168.0.8;
neighbor 192.168.0.7 {
    cluster 192.168.0.5;
}

В данном случае мы увидим на RT.SPB.LNX следующую таблицу маршрутизации (маршруты от RT.SPB.LNX не приняты):

[e-mail]# 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 на уникальный:

[e-mail]# show | compare
[edit protocols bgp group iBGP neighbor 192.168.0.4]
-     cluster 192.168.0.5;
+     cluster 192.168.0.7;
[edit protocols bgp group iBGP neighbor 192.168.0.6]
-     cluster 192.168.0.5;
+     cluster 192.168.0.7;
[edit protocols bgp group iBGP neighbor 192.168.0.5]
-     cluster 192.168.0.5;
+     cluster 192.168.0.7;

Результат:

[e-mail]# 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