То же верно для маршрутов других операторов связи в вашей таблице: есть внешний маршрут - трафик уходит, нет - нет. В последнем случае есть исключение - маршрут 0.0.0.0/0, он же default route, он же маршрут по умолчанию. В общем случае, defaul route - маршрут для всего трафика, для которого нет отдельных записей в таблице маршрутизации.

Что делать, когда, вроде бы, BGP работают, анонсы уходят, а трафика нет? Здесь - про диагностику исходящих маршрутов по BGP протоколу. По шагам.

Записи в БД RIPE

Как ни странно, настройка BGP начинается ещё до того, как вы открыли консоль на бордер.

При BGP-взаимодействии операторы связи строят фильтры принимаемых от вас маршрутов. В первую очередь держим в голове то, что аплинк фильтрует от вас маршруты.

Какие именно записи нужны в БД RIPE (или другой региональной регистратуре) читайте в статье RIPE: Набор записей для BGP анонсов.

Отсутствие корректного набора записей в БД RIPE может дать весьма странные результаты. Например: маршрут у ваших аплинков есть, у некоторых соседей есть, а магистральные операторы анонс сети не видят или пользуются маршрутом 0.0.0.0/0 для отправки трафика к вашей сети.

Проверьте записи!

Диагностика BGP сессии

BGP state: Established

Первое: проверяем в каком состоянии BGP-сессия - должна быть в Established. Все остальные состояния (Active, OpenSent, OpenConfirm, Down, Never, AdminDown и другие) - не являются рабочим состоянием, маршруты не передаются.

Проверка: show ip bgp summ, команда показывает состояния всех настроенных сессий:

Cisco#sh ip bgp summary 
BGP router identifier 195.209.62.233, local AS number 12722
....

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.1.253      4       209030   13220   13950 183080937    0    0 4d10h           0
10.20.15.32     4        12722       0       0        1    0    0 never    Idle
195.209.44.241  4       202764  269463 18916699 183080937    0    0 11w4d           2
195.209.45.236  4        12722 34737931  263735 183081185    0    0 11w6d      542769
195.209.45.240  4        12722 17862348  263739 183081185    0    0 11w6d      443071
M9-F0-ASR3_h3649#

Выделен сосед, сессия с которым никогда не устанавливалась (по крайней мере, после последней перезагрузки). Во всех остальных случая будет обозначено время с последнего изменения сессии

Juniper> show bgp summary 
195.209.34.170        49598      29298    5403742       0      10 1w2d 7:47:58 4/5/4/0              0/0/0/0
195.209.34.227       205824      84203      81865       0       6 3w5d 19:20:43 1/1/1/0              0/0/0/0
195.209.34.241        13238     537237     572825       0       2 4w1d 22:53:11 34/34/34/0           0/0/0/0
195.209.37.42         51916          0          0       0       0 18w0d 1:18:23 Idle  
195.209.37.138        51916          0          0       0       0 18w0d 1:18:23 Connect
195.209.42.139       198770     406525   63214068       0       0 18w0d 1:18:11 12/12/12/0           0/0/0/0
195.209.42.140       198770      71268   10959622       0       0 3w1d 2:25:37 0/0/0/0              0/0/0/0
195.209.44.58         61293     569271   17057775       0       3 4w5d 17:37:52 1/1/1/0              0/0/0/0

Анонсы маршрутов по BGP сессии

Далее - что именно вы анонсируете со своего оборудования конкретному BGP-соседу.

ВАЖНО: анонсируемые сети должны быть /24 и крупнее!

Исключение: маршруты /32 для blackhole, которые должны быть отмечены специальными community или оформлены по другим правилам, предоставляемым вашим аплинком.

То есть /24, /23…. /19… /8… - подходят.

Теоретически можно анонсировать аплинку /25, /26 и ещё более мелкие. Через некоторых аплинков такие сети могут попасть в глобальные магистрали. Но их работа может быть нестабильной. Обычно операторы не принимают анонсы с маской /25 и длиннее.

Команды проверки BGP анонсов на Cisco

h3649#show ip bgp neighbors 195.209.45.240 advertised-routes 
BGP table version is 170689245, local router ID is 195.209.62.233
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   5.45.80.240/32   172.31.255.1            20         32768 ?
 *>   5.45.83.119/32   172.31.255.1            20         32768 ?
 *>   37.252.1.115/32  172.31.255.1            20         32768 ?
 *>   91.105.232.6/32  172.31.255.1            20         32768 ?
 *>   95.181.161.66/32 172.31.255.1            20         32768 ?
 *>   109.248.224.0/24 195.209.44.241                180      0 202764 i
 *>   188.64.168.110/32
                      172.31.255.1            20         32768 ?
 *>   188.64.168.242/32
                      172.31.255.1            20         32768 ?
 *>   188.64.168.243/32
                      172.31.255.1            20         32768 ?
 *>   188.64.168.244/32
                      172.31.255.1            20         32768 ?
 *>   188.130.222.0/24 195.209.44.241                180      0 202764 i
 *>   195.209.40.3/32  172.31.255.1            20         32768 ?
 *>   195.209.50.190/32
                      172.31.255.1             0         32768 ?
 *>   195.209.52.47/32 172.31.255.1            20         32768 ?

Total number of prefixes 14 
h3649#

Здесь - анонсы маршрутизируемых сетей /24 плюс анонсы нескольких маршрутов /32 для blackhole.

NB: в целях мониторинга можно хоть график строить по Total:

h3649#sh ip bgp neighbors 195.209.45.240 advertised-routes | include Total
Total number of prefixes 14 

Команда проверки BGP анонсов для Juniper

pvasiliev@J1-M9-F0> show route advertising-protocol bgp 185.1.153.0 

inet.0: 949835 destinations, 5057153 routes (949834 active, 83 holddown, 6 hidden)
  Prefix		  Nexthop	       MED     Lclpref    AS path
  2.59.48.0/24            Self                                    I
  5.182.116.0/24          Self                                    I
* 5.183.153.0/24          Self                                    49598 ?
  31.222.240.0/24         Self                                    212667 I
... <cut> ...
  45.15.255.0/24          Self                                    I
  45.80.120.0/22          Self                                    I
* 45.82.216.0/24          Self                                    208274 I
  45.85.64.0/24           Self                                    I
  45.85.67.0/24           Self                                    I

Тут, кстати, Total нету, но можно погрепать по слешику и посчитать количество строчек:

pvasiliev@J1-M9-F0> show route advertising-protocol bgp 185.1.153.0 | match / | count 
Count: 155 lines

pvasiliev@J1-M9-F0> 

Команды проверки BGP анонсов на Huawei

<Huawei>display bgp routing-table peer 195.209.44.225 advertised-routes

 BGP Local router ID is 195.209.50.0
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete

 Total Number of Routes: 11
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   46.22.55.0/26      195.209.44.229  0                     0      3.7198i
 *>   46.22.55.64/27     195.209.44.229  0                     0      3.7198i
 *>   195.209.48.0       195.209.44.229  0                     0      3.7198i
 *>   195.209.50.0/25    195.209.44.229  11                    0      3.7198i
 *>   195.209.50.128/27  195.209.44.229  0                     0      3.7198i

* В случае Huawei приведен реальный пример анонсов сетей /25 и более мелких. Именно в данном случае - это нормально, так как на стороне аплинка производится суммаризация маршрутов в один большой. Это НЕ является стандартным поведением, настраивается по согласованию с аплинком.

BGP Looking Glass: проверка анонсов в глобальной Сети

BGP Looking Glass у вашего аплинка

Попросите у вашего аплинка ссылку на его страницу BGP Looking Glass. Если такой ресурс в сети оператора есть - пользуйтесь. Часто это сильно ускоряет процесс решения проблем.

У некоторых операторов Looking Glass закрыт паролем, ACL-ями или доступ регулируется каким-то ещё образом. Поэтому лучший вариант - спросить есть ли у оператора LG-сервис и как получить к нему доступ.

Мировые Looking Glass

В сети достаточно много общедоступных ресурсов BGP Looking Glass. Найти LG нужного оператора, магистрального оператора, регионального оператора в конкретной стране и тд можно:

1. Попытаться найти через поисковик, например: “bgp Looking Glass Telia”

2. в списках BGP Looking Glass, например:
   - LookinGlass.org
   - www.bgplookingglass.com
   - bgp4.as
   …

3. В базе PeeringDB.com: в описании автономной системы есть отдельное поле “Looking Glass URL”

Выбрав случайным образом сторонний Looking Glass в Сети вы можете проверить проходит ли ваш анонс какому-то третьему оператору, не связанному с вами или вашим аплинком. Другими словами, есть ли ваш маршрут в глобальной таблице маршрутизации, правильная ли у него маска, AS и тд.

Например, проверка маршрута 195.209.32.0/19 в сети AS6453 TATA Telecom:

В данном случае - да, сеть видна в таблице, маска правильная, анонсирует AS12722.

Таким образом можно:

• достоверно проверить работу своего оборудования

• достоверно узнать как работают анонсы у вашего аплинка (через общение с NOC)

• с высокой долей вероятности узнать как распространяются ваши маршруты в сети Интернет

Причем последний пункт более показательный - так как на сторонних ресурсах можно проверить как ваши маршруты выглядят у не-аффилированных операторов, то есть - в стандартной таблице маршуртизации, без “ручных подкручиваний”. Что есть наиболее достоверный вариант.

Важно: обратите внимание на специфику анонсов через IX (Internet eXchange, точки обмена трафиком). Особенно если вы не понимаете откуда у вас взялись “лишние” аплинки.

Подробнее - в статье про IX-ы.

Здесь и далее пойдёт речь про базу данных RIPE. Но это же верно и для других RIR: ARIN, APNIC, AFRINIC, LACNIC.

Зачем это нужно?

При внешнем сетевом взаимодействии нужно учитывать некоторые особенности:

1. Принято, что операторы принимают друг от друга блоки адресов с маской /24 и короче (короче маска - больше размер сети).

2. Операторы строят фильтры принимаемых сетей от других операторов.

3. Фильтры строятся автоматически - скриптами, поэтому данные о сетях всегда должны быть актуальны.

4. Скрипты берут информацию из общедоступных баз данных (в России - БД RIPE).

Другими словами, ДО начала настройки BGP-сессии с другим оператором связи у вас должны быть:

1. Номер автономной системы

2. Блок IP-адресов

3. Блок должен быть /24 (256 адресов) или крупнее.

4. В БД RIPE должны быть созданы необходимые объекты.

Объекты в БД RIPE

inetnum

Этот объект описывает ваш диапазон адресов. Например:

inetnum:         195.209.32.0 - 195.209.63.255
netname:         RU-RCN-19960719
country:         RU
org:             ORG-RL441-RIPE
admin-c:         RA10008-RIPE
tech-c:          REC-RIPE
status:          ALLOCATED PA
mnt-by:          RECONN-MNT
mnt-by:          RIPE-NCC-HM-MNT
created:         2020-03-11T10:37:10Z
last-modified:   2020-05-04T09:06:03Z
source:          RIPE

Объект описывает диапазон адресов 195.209.32.0 - 195.209.63.255, принадлежащий компании ORG-RL441-RIPE.

Это полный диапазон адресов, сеть /19. Эта сеть может быть анонсирована как единым блоком, так и разделена на несколько более мелких блоков, вплоть до /24.

aut-num

Номер автономной системы. Этот объект не только показывает какой именно номер вам выделен, но описывает взаимодействие этой ASn с другими операторами. Кстати, RIPE при выделении номера автономной системы сразу просит указать номера AS не менее чем двух других операторов (ведь при подключении только к одному оператору фактически не требуется отдельный ASn - можно использовать номер вашего единственного апстрима).

aut-num:         AS12722
as-name:         RECONN
org:             ORG-RL441-RIPE
import:          from AS31500 accept ANY
export:          to AS31500 announce AS12722
import:          from AS210359 accept ANY
export:          to AS210359 announce AS12722
admin-c:         RA10008-RIPE
tech-c:          REC-RIPE
status:          ASSIGNED
mnt-by:          RIPE-NCC-END-MNT
mnt-by:          RECONN-MNT
created:         2011-02-14T11:14:43Z
last-modified:   2022-11-01T08:16:57Z
source:          RIPE# Filtered

Этот объект описывает номер автономной системы 12722 и двух апстримов - 31500 и 210359, от которых принимается полная таблица маршрутизации и анонсируются только маршруты AS12722.

route

Объект route, который связывает диапазон IP-адресов и номер автономной системы.

route:           195.209.32.0/19
descr:           RECONN network
origin:          AS12722
mnt-by:          RECONN-MNT
created:         2015-05-11T13:18:34Z
last-modified:   2015-05-11T13:18:34Z
source:          RIPE

В данном случае - весь диапазон IP-адресов будет анонсироваться одним блоком /19 от автономной системы 12722.

Пожалуй, это ключевой объект - именно он показывает какой именно маршрут будет анонсироваться автономной системой.

as-set

Не всегда нужны, но важный объект.

Используется в тех случаях, когда к вам подключены другие операторы связи со своими автономными системами. В этом случае все номера анонсируемых вами автономных систем объединяются в одну группу - AS-SET. В неё включается номер вашей AS и номера автономных систем ваших клиентов либо их группы AS-SET:

as-set:          AS-RECONN
descr:           RECONN Group Network
members:         AS6870  # номера AS ваших клиентов
members:         AS8441
members:         AS12722   # свой номер AS
members:         AS29634
members:         AS35594
members:         AS39678
members:         AS49598
members:         AS51916
members:         AS56425
members:         AS59459
members:         AS61269
members:         AS61293
members:         AS198770
members:         AS199278
members:         AS202764
members:         AS203806
members:         AS205824
members:         AS208274
members:         AS210359
members:         AS212667
members:         AS-FENIX    #группы AS других операторов
members:         AS-ATSCOM
tech-c:          REC-RIPE
admin-c:         REC-RIPE
mnt-by:          RECONN-MNT
created:         2015-04-16T14:46:15Z
last-modified:   2022-11-01T08:04:36Z
source:          RIPE

В случае использования AS-SET-ов необходимо несколько иначе описывать объект as-num:

aut-num:         AS12722
as-name:         RECONN
org:             ORG-RL441-RIPE
import:          from AS31500 accept ANY
export:          to AS31500 announce AS-RECONN
import:          from AS210359 accept ANY
export:          to AS210359 announce AS-RECONN
admin-c:         RA10008-RIPE
tech-c:          REC-RIPE
status:          ASSIGNED
mnt-by:          RIPE-NCC-END-MNT
mnt-by:          RECONN-MNT
created:         2011-02-14T11:14:43Z
last-modified:   2022-11-01T08:16:57Z
source:          RIPE# Filtered

В этом случае, при взаимодействии с аплинками мы анонсируем все маршруты, включенные в группу AS-RECONN (as-set).

Как строятся BGP фильтры

При настройке BGP-сессии с другим оператором связи ваш аплинк, скорее всего, будет выполнять настройку фильтров маршрутов, которые от вас принимает. Построение фильтров - процесс автоматический, он может выполняться различными скриптами (bgpq, ratoolset, rtconfig…). В любом случае, эти скрипты откуда-то должны взять исходную информацию. Именно эта информация описывается перечисленными объектами.

Фильтры могут быть как по AS-номерам, так и по списку префиксов.

Пример фильтра по AS-номерам:

ip as-path access-list LISTNAME permit ^12722(_12722)*$
ip as-path access-list LISTNAME permit ^12722(_[0-9]+)*_(6870|8441|23456|29634)$
ip as-path access-list LISTNAME permit ^12722(_[0-9]+)*_(35594|39678|49598|51538)$
ip as-path access-list LISTNAME permit ^12722(_[0-9]+)*_(51916|56425|58095|59459)$
ip as-path access-list LISTNAME permit ^12722(_[0-9]+)*_(60904|61269|61293)$

Пример фильтра по префиксам:

ip prefix-list LISTNAME permit 2.59.48.0/24
ip prefix-list LISTNAME permit 5.45.80.0/22
ip prefix-list LISTNAME permit 5.182.116.0/24
ip prefix-list LISTNAME permit 5.183.153.0/24
...
ip prefix-list LISTNAME permit 195.209.32.0/19
...

Или даже каким-то комбинированным вариантом.

Как именно будет строиться фильтр - определяет владелец AS.

В качестве исходных данных для построения фильтра задаётся номер автономной системы ASn, as-set и формат фильтра.

Итог: набор необходимых объектов и данных

Итого, перечислим необходимый набор объектов в БД RIPE для описания межпровайдероского взаимодействия:

1. inetnum - блок ваших IP-адресов (не менее /24 или 256 адресов одним блоком)

2. aut-num - объект, описывающий номер вашей автономной системы ASn и её взаимодействия с вашими аплинками (обязательно указать номера AS ваших аплинков)

3. route - объект, описывающий каким / какими блоками вы будете анонсировать ваши адреса. Блок должен быть привязан к номеру вашей AS.

4. (опционально) as-set - если вы анонсируете не только свою автономку, но и ещё кого-то транзитом.

Что будет если не все объекты есть в БД RIPE?

В случае отсутствия информации, отсутствия объектов, неактуальной информации и тд - построение фильтров вашими аплинками будет некорректным.

Учитывая то, что каждый оператор строит фильтры такие, которые считает нужными и этот процесс не стандартизирован, можно сказать, что у всех фильтры разные.

Мало того, есть операторы, которые вообще не выполняют фильтрацию. Обычно это весьма смелые, крупные транзитные операторы.

Получается, что несмотря на то, что вы честно анонсируете все необходимые маршруты и диагностика BGP-сессии на маршрутизаторе показывает, что всё хорошо, вы получаете потенциальную возможность непрохождения анонсов в произвольном месте сети - как на прямой сессии с вашим аплинком, так и где-то дальше, при взаимодействии с другими операторами.

Настроили бордер, подняли BGP-сессии с двумя разными операторами. По обеим сессиям анонсируем одинаковый набор префиксов. Интернет работает, Looking Glass-ы показывают, что маршрут есть, всё хорошо.

При проведении технических работ отключаем одного из операторов, считая что второй оператор возьмёт на себя всю нагрузку и проблем не возникнет.

Однако, сеть тут же встаёт полностью - нет вообще никакой связи!

Разобрались. Оказалось, что из-за некорректного описания взаимодействия в aut-num-объекте второй оператор построил фильтр, который просто запрещал приём всех префиксов. Нам полную таблицу анонсировал, а от нас префиксы не принимал.

Случай из жизни.