# BGP Session Attributes
## Local Preference Attribute
Этот атрибут указывает маршрутизаторам внутри AS как из неё выйти. Например, RT.SPB.MIR получает такие маршруты:
```
root@RT.SPB.MIR# 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:
```
root@RT.MSK.M8# set protocols bgp group intra-Sub-AS local-preference 200
```
Т.е. мы iBGP пирам экспортировали принимаемые от eBGP-пиров маршуты с LocalPref=200. Результат:
```
root@RT.SPB.MIR# 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, вообще:
```
root@RT.SPB.MIR# 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 остался прежний:
```
root@RT.MSK.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:
```
root@RT.VVK.NOV# 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;
+ }
+ }
+ }
```
До коммита:
```
root@RT.SPB.OBV# 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
```
После:
```
root@RT.SPB.OBV# 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 ситуация также изменилась:
```
root@RT.VVK.NOV# 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;
}
```
Результат:
```
root@RT.MSK.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]
root@RT.MSK.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 и получем такое:
```
root@RT.MSK.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]
root@RT.MSK.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 довольно просто передать:
```
root@RT.MSK.M34# set protocols bgp group eBGP metric-out 8
root@RT.MSK.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:
```
root@RT.MSK.M34# set protocols bgp group eBGP metric-out igp
root@RT.MSK.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-пиров и от аплинков на соответствующих роутерах:
```
root@RT.VVK.NOV# 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 ];
```
{% hint style="danger" %}
Тут стоит отметить, что не стоит принимать любые префиксы от всех клиентов, лучше ограничивать принимаемые префиксы на приём пулом клиентских адресов. Исключение разве что - это пиринг с каким-нибудь магистральным провайдером, который является сам аплинком для клиентов с PI IP-адресами.
{% endhint %}
И экспортируем маршрут на стороне клиента:
```
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:
```
root@RT.VVK.NOV# 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:
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
```
Также стоит заметить, что можно немного отредактировать политику для импорта и применить её на экспорт наших аплинков:
```
root@RT.MSK.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:
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 не доступен по всей сети.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://netlabs.gitbook.io/juniper/5-bgp/untitled.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.