BGP Session Attributes

Local Preference Attribute

Этот атрибут указывает маршрутизаторам внутри AS как из неё выйти. Например, RT.SPB.MIR получает такие маршруты:

[e-mail]# run show route 101.0.0.1                             

inet.0: 52 destinations, 64 routes (52 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

101.0.0.0/24       *[BGP/170] 00:12:15, localpref 100, from 10.0.0.201
                      AS path: 9001 8001 I, validation-state: unverified
                    > to 10.0.0.13 via ae1.0
                    [BGP/170] 00:12:15, localpref 100, from 10.0.0.204
                      AS path: 9001 8001 I, validation-state: unverified
                    > to 10.0.0.13 via ae1.0
                    [BGP/170] 06:08:52, localpref 100
                      AS path: (65003) 9001 8001 I, validation-state: unverified
                    > to 10.2.2.1 via ae2.0

Предположим, что мы хотим, чтобы мы ходили к этому маршруту через RT.MSK.M8:

[e-mail].M8# set protocols bgp group intra-Sub-AS local-preference 200

Т.е. мы iBGP пирам экспортировали принимаемые от eBGP-пиров маршуты с LocalPref=200. Результат:

[e-mail]# run show route 101.0.0.1    

inet.0: 52 destinations, 62 routes (52 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

101.0.0.0/24       *[BGP/170] 00:00:22, localpref 200, from 10.0.0.201
                      AS path: (65001) 8000 8001 I, validation-state: unverified
                    > to 10.0.0.8 via ae0.0
                    [BGP/170] 00:00:22, localpref 200, from 10.0.0.204
                      AS path: (65001) 8000 8001 I, validation-state: unverified
                    > to 10.0.0.8 via ae0.0

Только вот дело в том, что это повлияло на все маршруты, полученные по eBGP маршрутизатором RT.MSK.M8, вообще:

[e-mail]# run show route protocol bgp 

inet.0: 52 destinations, 62 routes (52 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.0.0.0/16         *[BGP/170] 00:02:54, localpref 200, from 10.0.0.201
                      AS path: (65001) 8000 I, validation-state: unverified
                    > to 10.0.0.8 via ae0.0
                    [BGP/170] 00:02:54, localpref 200, from 10.0.0.204
                      AS path: (65001) 8000 I, validation-state: unverified
                    > to 10.0.0.8 via ae0.0
8.1.0.0/16         *[BGP/170] 00:02:54, localpref 200, from 10.0.0.201
                      AS path: (65001) 8000 8001 I, validation-state: unverified
                    > to 10.0.0.8 via ae0.0
                    [BGP/170] 00:02:54, localpref 200, from 10.0.0.204
                      AS path: (65001) 8000 8001 I, validation-state: unverified
                    > to 10.0.0.8 via ae0.0

Тогда нам нужно настроить отдельную политику уже для импорта одного маршрута с определённым LocalPref. Команда, которая указана выше работает как export-policy. Т.е. на M8 LocalPref остался прежний:

[e-mail].M8# run show route 101.0.0.0 

inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

101.0.0.0/24       *[BGP/170] 00:35:57, localpref 100
                      AS path: 8000 8001 I, validation-state: unverified
                    > to 8.0.0.0 via ge-0/0/4.0

Соответственно удалим тот конфиг и настроим отдельную политику. Допустим мы хотим, чтобы трафик до 102.0.0.0/24 ходил только через VVK и только через AS900:

[e-mail]# show | compare 
[edit protocols bgp group eBGP]
-    import [ 9000:666-import BGPimport ];
+    import [ 9000:666-import BGPimport Attr-BGP ];
[edit policy-options]
+   policy-statement Attr-BGP {
+       term localpref {
+           from {
+               next-hop 9.2.2.0;
+               route-filter 102.0.0.0/24 exact;
+           }
+           then {
+               local-preference 200;
+               accept;
+           }
+       }
+   }

До коммита:

[e-mail]# run show route 102.0.0.0/24    

inet.0: 49 destinations, 49 routes (49 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

102.0.0.0/24       *[BGP/170] 00:00:06, localpref 100, from 10.0.0.203
                      AS path: 9001 I, validation-state: unverified
                    > to 10.0.0.5 via ae0.0
                      to 10.0.0.7 via ae1.0

После:

[e-mail]# run show route 102.0.0.0/24    

inet.0: 49 destinations, 50 routes (49 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

102.0.0.0/24       *[BGP/170] 00:00:03, localpref 200, from 10.0.0.204
                      AS path: (65003) 9002 9001 I, validation-state: unverified
                    > to 10.0.0.7 via ae1.0
                      to 10.0.0.9 via ae2.0
                    [BGP/170] 00:00:03, localpref 200, from 10.0.0.202
                      AS path: (65003) 9002 9001 I, validation-state: unverified
                    > to 10.0.0.7 via ae1.0
                      to 10.0.0.9 via ae2.0

На самом VVK ситуация также изменилась:

[e-mail]# run show route 102.0.0.0/24 

inet.0: 30 destinations, 42 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

102.0.0.0/24       *[BGP/170] 03:06:50, localpref 200
                      AS path: 9002 9001 I, validation-state: unverified
                    > to 9.2.2.0 via ge-0/0/1.0
                    [BGP/170] 07:03:23, localpref 100
                      AS path: 9001 I, validation-state: unverified
                    > to 9.1.1.2 via ge-0/0/0.0

Origin

Немного поменяем политику экспорта на AS8001:

[edit policy-options policy-statement exportBGP]
root@AS8001# show | compare 

[edit policy-options policy-statement exportBGP]
root@AS8001# show    
from {
    protocol static;
    route-filter 8.1.0.0/16 exact;
    route-filter 101.0.0.0/8 upto /24;
}
then {
    origin egp;
    accept;
}

Результат:

[e-mail].M34# run show route 8.1.0.0               

inet.0: 23 destinations, 28 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

8.1.0.0/16         *[BGP/170] 00:01:11, localpref 200, from 10.1.1.201
                      AS path: 8000 8001 E, validation-state: unverified
                    > to 10.1.1.1 via ae0.0
                    [BGP/170] 00:01:11, localpref 100
                      AS path: 8000 8001 E, validation-state: unverified
                    > to 8.0.0.2 via ge-0/0/1.0

[edit]
[e-mail].M34# run show route 101.0.0.0             

inet.0: 23 destinations, 28 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

101.0.0.0/24       *[BGP/170] 00:01:17, localpref 200, from 10.1.1.201
                      AS path: 8000 8001 E, validation-state: unverified
                    > to 10.1.1.1 via ae0.0
                    [BGP/170] 00:01:17, localpref 100
                      AS path: 8000 8001 E, validation-state: unverified
                    > to 8.0.0.2 via ge-0/0/1.0

Аналогично поменяем на incomplete и получем такое:

[e-mail].M34# run show route 101.0.0.0   

inet.0: 23 destinations, 28 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

101.0.0.0/24       *[BGP/170] 00:00:04, localpref 200, from 10.1.1.201
                      AS path: 8000 8001 ?, validation-state: unverified
                    > to 10.1.1.1 via ae0.0
                    [BGP/170] 00:00:04, localpref 100
                      AS path: 8000 8001 ?, validation-state: unverified
                    > to 8.0.0.2 via ge-0/0/1.0

[edit]
[e-mail].M34# run show route 8.1.0.0      

inet.0: 23 destinations, 28 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

8.1.0.0/16         *[BGP/170] 00:00:08, localpref 200, from 10.1.1.201
                      AS path: 8000 8001 ?, validation-state: unverified
                    > to 10.1.1.1 via ae0.0
                    [BGP/170] 00:00:08, localpref 100
                      AS path: 8000 8001 ?, validation-state: unverified
                    > to 8.0.0.2 via ge-0/0/1.0

MED Attribute (Multiple Exit Discriminator)

Слабый атрибут. Удобнее всего будет проверить на стыке AS9000 и AS8000. Посмотрим как мы можем достичь 200.0.0.1 из AS9002:

root@AS8000# run show route 200.0.0.1  

inet.0: 18 destinations, 30 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.0.0/24       *[BGP/170] 02:42:42, localpref 100, from 8.0.0.3
                      AS path: 9000 I, validation-state: unverified
                      to 8.0.0.3 via ge-0/0/1.0
                    > to 8.0.0.1 via ge-0/0/4.0
                    [BGP/170] 02:42:28, localpref 100
                      AS path: 9000 I, validation-state: unverified
                    > to 8.0.0.1 via ge-0/0/4.0
                    [BGP/170] 01:28:52, localpref 100
                      AS path: 8001 9001 9000 I, validation-state: unverified
                    > to 8.1.1.0 via ge-0/0/2.0

Собственно MED в другую AS довольно просто передать:

[e-mail].M34# set protocols bgp group eBGP metric-out 8      
[e-mail].M8# set protocols bgp group eBGP metric-out 6

Результат:

root@AS8000# run show route 200.0.0.0    

inet.0: 18 destinations, 30 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.0.0/24       *[BGP/170] 00:00:06, MED 6, localpref 100
                      AS path: 9000 I, validation-state: unverified
                    > to 8.0.0.1 via ge-0/0/4.0
                    [BGP/170] 00:01:20, MED 8, localpref 100
                      AS path: 9000 I, validation-state: unverified
                    > to 8.0.0.3 via ge-0/0/1.0
                    [BGP/170] 04:03:57, localpref 100
                      AS path: 8001 9001 9000 I, validation-state: unverified
                    > to 8.1.1.0 via ge-0/0/2.0

Стоит заметить, что если настроить MED только на одном из маршрутизаторов, то скорее всего выберется маршрут без указания MED, т.к. по-умолчанию MED равен 0. Также можно настроить MED=IGP Metric:

[e-mail].M34# set protocols bgp group eBGP metric-out igp            
[e-mail].M8# set protocols bgp group eBGP metric-out igp  

Результат:

root@AS8000# run show route 200.0.0.0 active-path 

inet.0: 18 destinations, 30 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.0.0/24       *[BGP/170] 00:09:44, MED 6, localpref 100
                      AS path: 9000 I, validation-state: unverified
                      to 8.0.0.3 via ge-0/0/1.0
                    > to 8.0.0.1 via ge-0/0/4.0

BGP Communities (Blackhole)

Предположим клиенту необходимо будет заблекхолить один из его адресов в сети. Как пример можно взять 40.0.0.0.2. Чтобы его заблекхолить нам нужно настроить Blackhole community. Обычно это ASN:666.

Импортируем политику со стороны провайдера от клиента, iBGP-пиров и от аплинков на соответствующих роутерах:

[e-mail]# show | compare 
[edit protocols bgp group intra-Sub-AS]
+    import 9000:666-import;
[edit protocols bgp group eBGP]
+    import [ 9000:666-import BGPimport ]; # Импортируем префиксы от аплинков
[edit protocols bgp group ip-transit] # Применяем политику на импорт именно в таком
+    import [ 9000:666-import BGPimport ]; # виде. Порядок важен (как и в terms).
[edit policy-options]
+   policy-statement 9000:666-import {
+       from {
+           community Blackhole; # Принимаем маршруты только с 666 community
+           route-filter 0.0.0.0/0 prefix-length-range /32-/32; # И только /32
+       }
+       then {
+           next-hop discard;
+           accept;
+       }
+   }
[edit policy-options]
+   community Blackhole members 9000:666; # Наш community, а ниже наших аплинков
+   community Blackhole-Uplinks members [ 9001:666 9002:666 8000:666 8001:666 ];

Тут стоит отметить, что не стоит принимать любые префиксы от всех клиентов, лучше ограничивать принимаемые префиксы на приём пулом клиентских адресов. Исключение разве что - это пиринг с каким-нибудь магистральным провайдером, который является сам аплинком для клиентов с PI IP-адресами.

И экспортируем маршрут на стороне клиента:

root@BGP-Client# show | compare 
[edit routing-options static]
     route 40.0.0.0/24 { ... }
+    route 40.0.0.2/32 {
+        discard;
+        tag 666; # тегируем маршрут 
+    }
[edit policy-options]
+   policy-statement Blackhole {
+       from {
+           protocol static; # Если статика
+           tag 666;         # И 666 тэг
+       }
+       then {
+           community set Blackhole; # То Анонсируем с community 9000:666
+           accept;
+       }
+   }
[edit policy-options]
+   community Blackhole members 9000:666;
[edit protocols bgp group ISP]
+    export [ BGPexport Blackhole ];

Устанавливаем маршрут с тэгом блэкхола:

root@BGP-Client# set routing-options static route 40.0.0.2 discard tag 666

Получаем следующий результат на RT.VVK.NOV, как и на всех остальных роутерах в AS:

[e-mail]# run show route 40.0.0.2/32 detail       

inet.0: 30 destinations, 35 routes (30 active, 0 holddown, 0 hidden)
40.0.0.2/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Discard
                Address: 0x92c4a24
                Next-hop reference count: 3
                State: <Active Ext>
                Local AS: 65003 Peer AS:   500
                Age: 30:33 
                Validation State: unverified 
                Task: BGP_500.50.0.0.1+51231
                Announcement bits (4): 0-KRT 4-Aggregate 5-BGP_RT_Background 6-Resolve tree 1 
                AS path: 500 I
                Communities: 9000:666
                Accepted
                Localpref: 100
                Router ID: 40.0.0.1

Также стоит заметить, что можно немного отредактировать политику для импорта и применить её на экспорт наших аплинков:

[e-mail].M34# show | compare 
[edit protocols bgp group eBGP]
+    export 9000:666-export;
[edit policy-options]
+   policy-statement 9000:666-export {
+       from {
+           community Blackhole;
+           route-filter 0.0.0.0/0 prefix-length-range /32-/32;
+       }
+       then {
+           community add Blackhole-Uplinks; # Добавляем к маршруту community всех
+           accept;                          # аплинков из списка 
+       }                                    # community Blackhole-Uplinks
+   }

В принципе дальше всё более ли менее одинаково. На аплинках примерно те же политики импорта-экспорта. По итогу, после настройки всех устройств, на AS8001 получаем следующее:

root@AS8001# run show route 40.0.0.2 detail active-path 

inet.0: 16 destinations, 20 routes (15 active, 0 holddown, 1 hidden)
40.0.0.2/32 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Discard
                Address: 0x92c4a24
                Next-hop reference count: 7
                State: <Active Ext>
                Local AS:  8001 Peer AS:  9001
                Age: 1:00:34 
                Validation State: unverified 
                Task: BGP_9001.8.1.1.3+59089
                Announcement bits (2): 0-KRT 2-BGP_RT_Background 
                AS path: 9001 9000 500 I
                Communities: 8000:666 8001:666 9000:666 9001:666 9002:666
                Accepted
                Localpref: 100
                Router ID: 102.0.0.1

Т.е. Blackhole от клиента передался всем вышестоящим провайдерам и теперь 40.0.0.2 не доступен по всей сети.