nocip.ssh@mail.ru
Главная  >  Cisco Routing

Диагностика BGP-маршрутов (Troubleshooting BGP Routes)

Создана 15.09.2026
Отредактирована 24.09.2026
Как только BGP-соседство (BGP adjacency) установлено, BGP-маршрутизаторы обмениваются своими BGP-маршрутами (BGP routes) друг с другом. Однако существуют различные причины, по которым BGP-маршруты могут отсутствовать либо в BGP-таблице (BGP table), либо в таблице маршрутизации (routing table). В этом обзоре объясняются эти причины и то, как мы можем выявить их с помощью наших методов диагностики (troubleshooting methods).
Как уже обсуждалось, пиры (peers) — это основа для обмена BGP-информацией. Если у нас нет пиров, мы не будем изучать BGP-маршруты. Итак, помимо отсутствия пиров, каковы могут быть причины отсутствия маршрутов (missing routes) в BGP-сети? Ниже приведен список некоторых распространённых причин, по которым BGP-маршруты могут отсутствовать либо в BGP-таблице, либо в таблице маршрутизации:
📌 Ключевая тема
  • Отсутствующая или неверная команда network mask: Для анонсирования маршрутов (advertise routes) необходима точная команда network.
  • Next-hop маршрутизатор недостижим: Чтобы использовать BGP-маршрут, следующий шлюз (next hop) должен быть достижим.
  • Правило разделения горизонтов BGP (BGP split-horizon rule): Маршрутизатор, который изучает BGP-маршруты через iBGP-пиринг (iBGP peering), не будет делиться этими маршрутами с другим iBGP-пиром.
  • Лучший источник информации: Если точно такая же сеть (exact same network) изучена из более надёжного источника (more reliable source), она используется вместо информации, изученной через BGP.
  • Фильтрация маршрутов: Может быть настроен фильтр, который препятствует распространению маршрута соседям (neighbors) или его изучению от соседей.
Для проверки (verify) BGP-маршрутов, изученных через IPv4 Unicast, или маршрутов, локально внедрённых (locally injected) в BGP-таблицу, используется команда show bgp ipv4 unicast (она же старая команда show ip bgp), как показано в Примере 1. Маршруты появятся в этой таблице по следующим причинам:
  • Другой BGP-маршрутизатор анонсировал (advertises) их локальному маршрутизатору.
  • Команда network mask совпадает с маршрутом в локальной таблице маршрутизации.
  • Команда redistribute используется для импорта маршрута из другого локального источника.
  • Команда summary-address используется для создания суммарного маршрута (summary route).
Нелегко определить точные источники (exact sources) для всех сетей, просматривая только BGP-таблицу. Просмотр команд в текущей конфигурации (running configuration) вместе с выводом BGP-таблицы даст вам наиболее точную информацию. Однако в BGP-таблице сеть с Next hop, отличным от 0.0.0.0, указывает на то, что маршрутизатор изучил её от пира (peer). Если Next hop равен 0.0.0.0, это означает, что локальный маршрутизатор инициировал (originated) этот маршрут. Если столбец Path заканчивается на ? , можно сделать вывод, что маршрут был перераспределён (redistributed) в BGP-процесс в какой-то момент. Если столбец Path заканчивается на  i , это означает, что маршрут был внедрён с помощью команды summary-address или network mask.
Пример 1. Просмотр BGP-таблицы 
R1#show bgp ipv4 unicast
BGP table version is 10, local router ID is 1.1.1.1
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       0.0.0.0                  0         32768 ?
 *>  10.1.1.0/26      0.0.0.0                  0         32768 i
 *>  10.1.1.0/24      0.0.0.0                  0         32768 i
 *>  10.1.1.64/26     0.0.0.0                  0         32768 i
 *>  10.1.1.128/26    0.0.0.0                  0         32768 i
 *>  10.1.1.192/26    0.0.0.0                  0         32768 i
 *   10.1.5.0/24      10.1.13.3            3328         0 65502 i
 *>                   2.2.2.2              3328         0 65502 i
 *>  10.1.12.0/24     0.0.0.0                  0         32768 ?
 *>  10.1.13.0/24     0.0.0.0                  0         32768 ?
* Если используете VRF, команда для просмотра BGP-таблицы будет выглядеть так: show ip bgp vpnv4 vrf <имя_VRF>
Для отображения таблицы маршрутизации (routing table) используется команда show ip route. Чтобы просмотреть только BGP-маршруты, выполните команду show ip route bgp, как показано в Примере 2. Все BGP-маршруты отображаются с кодом  B  в начале записи.
Пример 2. Просмотр BGP-маршрутов в таблице маршрутизации 
R2#show ip route bgp
 ...выходные данные опущены...
 Gateway of last resort is 10.1.12.1 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
 B     10.1.1.0/24 [20/0] via 1.1.1.1, 00:19:11
 B     10.1.1.0/26 [20/0] via 1.1.1.1, 00:41:04
 B     10.1.1.64/26 [20/0] via 1.1.1.1, 00:36:45
 B     10.1.1.128/26 [20/0] via 1.1.1.1, 00:36:15
 B     10.1.1.192/26 [20/0] via 1.1.1.1, 00:36:15
 B     10.1.13.0/24 [20/0] via 1.1.1.1, 00:20:23
* Если используете VRF, команда для просмотра BGP-маршрутов в таблице маршрутизации будет выглядеть так: show ip route vrf <имя_VRF> bgp
Давайте рассмотрим каждую из причин по отдельности и определим, как мы можем распознать их в процессе диагностики (troubleshooting process).
💡 Дополнительное пояснение
Как читать BGP-таблицу (Пример 1)
Поле
Что означает
*
Маршрут valid (действительный)
>
Маршрут best (наилучший) — будет установлен в таблицу маршрутизации
i
Маршрут изучен через iBGP (internal)
?
Маршрут redistributed (перераспределён) в BGP
Next Hop 0.0.0.0
Маршрут locally originated (инициирован локально)
Next Hop X.X.X.X
Маршрут изучен от пира (соседа)
Path заканчивается на i
Маршрут внедрён через network или summary-address
Path заканчивается на ?
Маршрут перераспределён (redistributed)
Как читать таблицу маршрутизации (Пример 2)
Поле
Что означает
B
Маршрут изучен через BGP
[20/0]
Административная дистанция (AD) = 20, метрика = 0
via 1.1.1.1
Next hop (следующий шлюз)
00:19:11
Время с момента изучения маршрута
⚠️ Важное предупреждение (Caution)
BGP-таблица и таблица маршрутизации — это не одно и то же!
  • BGP-таблица (show bgp ipv4 unicast) содержит все BGP-маршруты, включая те, которые не стали наилучшими (best).
  • Таблица маршрутизации (show ip route bgp) содержит только те BGP-маршруты, которые были выбраны как наилучшие (best) и установлены в RIB (Routing Information Base).
Если маршрут есть в BGP-таблице, но отсутствует в таблице маршрутизации — это может быть связано с:
  • Наличием лучшего источника (better source) — например, статического маршрута или маршрута от IGP.
  • Административной дистанцией (AD) — BGP имеет AD = 20 (eBGP) или 200 (iBGP), и если другой протокол предлагает маршрут с меньшей AD, он побеждает.
  • Фильтрацией (route filtering) на этапе установки в RIB.
💡 Дополнительное пояснение про VRF
В сетях без VRF все маршруты находятся в единой глобальной таблице маршрутизации (global routing table), поэтому для просмотра только BGP-маршрутов достаточно команды show ip route bgp. В сетях с VRF (Virtual Routing and Forwarding - виртуальная маршрутизация и перенаправление) каждый экземпляр VRF имеет собственную изолированную таблицу маршрутизации (routing table), и для просмотра BGP-маршрутов внутри неё необходимо явно указать имя VRF:  show ip route vrf <имя_VRF> bgp . Без этого уточнения команда show ip route bgp покажет (или не покажет) только глобальную таблицу и не увидит маршруты внутри VRF.
Что это значит на практике:
VRF позволяет создать несколько независимых таблиц маршрутизации на одном физическом маршрутизаторе. Каждый VRF — это как отдельный виртуальный маршрутизатор внутри одного устройства.
Зачем нужен VRF:
  • Изоляция клиентов (например, у провайдера — каждый клиент в своём VRF).
  • Разделение трафика (например, гостевая сеть и корпоративная — в разных VRF).
  • MPLS L3VPN — основа для предоставления VPN-услуг.

Отсутствующая или неверная команда network mask (Missing or Bad network mask Command)

Команда network mask используется для анонсирования маршрутов (advertise routes) в BGP. Если вы запомните только одну вещь об этой команде, запомните, что она крайне придирчива (extremely picky). В следующем списке описано, почему эта команда такая придирчивая:
📌 Ключевая тема
  • Сеть/префикс (network/prefix), который вы хотите анонсировать через BGP, должен присутствовать в таблице маршрутизации (routing table) из какого-либо другого источника (connected, static или другой протокол маршрутизации).
  • Команда network mask должна точно совпадать (perfect match) с сетью/префиксом, указанным в таблице маршрутизации.
Если эти два требования не выполнены, префикс/сеть не будет анонсирован. Просмотрите Пример 3 и определите, будет ли сеть 10.1.1.0/26 анонсирована.
Пример 3. Определение того, будет ли сеть 10.1.1.0/26 анонсирована 
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 65501
R1(config-router)#network 10.1.1.0 mask 255.255.255.192
R1(config-router)#end
R1#show ip route
...выходные данные опущены...
Gateway of last resort is not set
     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 10.1.12.2
     10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
C       10.1.1.0/26 is directly connected, GigabitEthernet0/0.1
L       10.1.1.1/32 is directly connected, GigabitEthernet0/0.1
C       10.1.1.64/26 is directly connected, GigabitEthernet0/0.2
L       10.1.1.65/32 is directly connected, GigabitEthernet0/0.2
C       10.1.1.128/26 is directly connected, GigabitEthernet0/0.3
L       10.1.1.129/32 is directly connected, GigabitEthernet0/0.3
C       10.1.1.192/26 is directly connected, GigabitEthernet0/0.4
L       10.1.1.193/32 is directly connected, GigabitEthernet0/0.4
C       10.1.12.0/24 is directly connected, GigabitEthernet1/0
L       10.1.12.1/32 is directly connected, GigabitEthernet1/0
C       10.1.13.0/24 is directly connected, GigabitEthernet2/0
L       10.1.13.1/32 is directly connected, GigabitEthernet2/0
* Если используете VRF, команда для просмотра всей таблицы маршрутизации будет выглядеть так: show ip route vrf <имя_VRF>
В Примере 3 сеть 10.1.1.0/26 будет анонсирована, потому что в таблице маршрутизации есть точное совпадение (exact match) с командой network.

exact match [ɪgˈzækt mæʧ] точное совпадение

Теперь просмотрите Пример 4. Будет ли команда network mask успешно анонсировать указанный маршрут?
Пример 4. Определение того, будет ли сеть  анонсирована
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 65501
R1(config-router)#network 10.1.1.0 mask 255.255.255.0
R1(config-router)#end
R1#show ip route
...выходные данные опущены...
Gateway of last resort is not set
     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 10.1.12.2
     10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
C       10.1.1.0/26 is directly connected, GigabitEthernet0/0.1
L       10.1.1.1/32 is directly connected, GigabitEthernet0/0.1
C       10.1.1.64/26 is directly connected, GigabitEthernet0/0.2
L       10.1.1.65/32 is directly connected, GigabitEthernet0/0.2
C       10.1.1.128/26 is directly connected, GigabitEthernet0/0.3
L       10.1.1.129/32 is directly connected, GigabitEthernet0/0.3
C       10.1.1.192/26 is directly connected, GigabitEthernet0/0.4
L       10.1.1.193/32 is directly connected, GigabitEthernet0/0.4
C       10.1.12.0/24 is directly connected, GigabitEthernet1/0
L       10.1.12.1/32 is directly connected, GigabitEthernet1/0
C       10.1.13.0/24 is directly connected, GigabitEthernet2/0
L       10.1.13.1/32 is directly connected, GigabitEthernet2/0
В данном случае команда network mask — это 10.1.1.0/24. Хотя 10.1.1.0/24 как суммарный маршрут (summary) включал бы 10.1.1.0/26, 10.1.1.64/26, 10.1.1.128/26 и 10.1.1.192/26, команда network mask требует анонсировать именно эту сеть (10.1.1.0/24). Поскольку 10.1.1.0/24 отсутствует в таблице маршрутизации, ничего не анонсируется.
Важно, чтобы вы могли распознать неверную или отсутствующую команду network mask как причину отсутствия маршрутов (missing routes). Если маршрутизатор не изучает BGP-маршрут, который должен, и вы проследили его до самого источника, просмотрите текущую конфигурацию (running configuration), чтобы увидеть, есть ли команда network mask, анонсирующая сеть, и есть ли соответствующее совпадение в таблице маршрутизации.
💡 Дополнительное пояснение
Почему команда network mask такая «придирчивая»?
BGP не анонсирует маршруты просто потому, что вы указали команду network. Для успешного анонсирования должны быть выполнены два условия:
1. Маршрут должен быть в таблице маршрутизации (из любого источника: connected, static, OSPF, EIGRP).
2. Команда network должна точно совпадать с этим маршрутом (по адресу сети и по маске).
Пример: что работает, а что нет
Команда network
Маршрут в таблице
Анонсируется?
Почему
network 10.1.1.0 mask 255.255.255.192
C 10.1.1.0/26
✅ Да
Точное совпадение
network 10.1.1.0 mask 255.255.255.0
C 10.1.1.0/26
❌ Нет
/24 ≠ /26
network 10.1.1.0 mask 255.255.255.0
C 10.1.1.0/24
✅ Да
Точное совпадение
Как проверить, что анонсируется
R1#show bgp ipv4 unicast
Если маршрут есть в BGP-таблице с next hop 0.0.0.0 — он анонсируется. Если нет — проверьте:
  • Есть ли маршрут в show ip route?
  • Совпадает ли маска в команде network с маской в таблице маршрутизации?
⚠️ Важное предупреждение
Команда network mask — это не то же самое, что network в OSPF или EIGRP!
  • В OSPF/EIGRP команда network включает интерфейсы в процесс маршрутизации.
  • В BGP команда network анонсирует уже существующий маршрут из таблицы маршрутизации.
Если маршрута нет в таблице маршрутизации — BGP не будет его анонсировать, даже если вы указали команду network.
📊 Сводная таблица: как диагностировать проблему с network mask
Шаг
Команда
Что проверить
1
show ip route <префикс>
Есть ли маршрут в таблице?
2
show run | section router bgp
Есть ли команда network?
3
Сравнить маску
Совпадает ли маска в network с маской в таблице?
4
show bgp ipv4 unicast
Есть ли маршрут в BGP-таблице?

Next-hop маршрутизатор недостижим (Next-Hop Router Not Reachable)

Если вы видите BGP-маршруты в BGP-таблице, но они не появляются в таблице маршрутизации, маршрутизатор может быть не в состоянии достичь next hop (следующего шлюза). Чтобы BGP-маршрутизатор установил BGP-маршрут в таблицу маршрутизации, он должен иметь возможность достичь адреса next hop, указанного для этой сети. В Примере 5 показан вывод команды show bgp ipv4 unicast на R5. Давайте сосредоточимся на сети 10.1.1.0/26. Обратите внимание, что после * отсутствует символ >. Символы * > указывают на то, что это действительный наилучший путь (valid best path) для достижения этой сети, и он был установлен в таблицу маршрутизации. В данном случае путь действителен, но не является наилучшим, и как результат — не помещён в таблицу маршрутизации.
Пример 5. Выявление проблем с next hop в BGP (Identifying BGP Next-Hop Issues)
R5#show bgp ipv4 unicast
BGP table version is 2, local router ID is 5.5.5.5
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.1.1.1/32       1.1.1.1                  0    100      0 65501 ?
 * i 10.1.1.0/26      1.1.1.1                  0    100      0 65501 i
 * i 10.1.1.0/24      1.1.1.1                  0    100      0 65501 i
 * i 10.1.1.64/26     1.1.1.1                  0    100      0 65501 i
 * i 10.1.1.128/26    1.1.1.1                  0    100      0 65501 i
 * i 10.1.1.192/26    1.1.1.1                  0    100      0 65501 i
 r>i 10.1.5.0/24      10.1.24.4             3328    100      0 i
 * i 10.1.12.0/24     1.1.1.1                  0    100      0 65501 ?
 * i 10.1.13.0/24     1.1.1.1                  0    100      0 65501 ?
* BGP-таблица (все BGP-маршруты, включая те, что не стали наилучшими).
📌 Ключевая тема
Причина, по которой маршрут не используется, заключается в том, что адрес next hop недостижим. В Примере 6 команда ping 1.1.1.1 завершается неудачей, что доказывает недостижимость next hop.
Пример 6. Проверка достижимости next hop (Verifying Next-Hop Reachability) 
R5#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
* Если используете VRF, команда ping будет выглядеть так: ping vrf <имя_VRF> <IP-address>
Обратитесь к Рисунку 1. Обратите внимание, где находится адрес next hop 1.1.1.1 относительно R5. Next hop для BGP-маршрутов за пределами автономной системы (autonomous system) — это IP-адрес маршрутизатора, анонсирующего маршрут в локальную автономную систему. Маршрутизатор, получающий анонс (R2 в данном случае), не изменяет next hop по умолчанию, потому что BGP основан на переходах между автономными системами (autonomous system-by-autonomous system hops), а не на переходах между маршрутизаторами (router-by-router hops). Следовательно, next hop — это IP-адрес маршрутизатора, анонсирующего сеть из следующей автономной системы.
Рисунок 1. Диагностика поведения адреса next hop (Troubleshooting Next-Hop Address Behavior)
Существует множество различных способов решить эту проблему. Ключ в том, чтобы научить R5, как добраться до next hop. Следующий список содержит несколько примеров:
  • Создать статический маршрут по умолчанию (static default route) на R2 и R3; анонсировать его в протокол IGP-маршрутизации.
  • Создать статический маршрут по умолчанию (static default route) на R5.
  • Создать статический маршрут (static route) на R5.
  • Анонсировать адрес next hop в протокол IGP-маршрутизации (Interior Gateway Protocol).
Кроме того, BGP имеет встроенную опцию, которую вы можете использовать. Это команда neighbor ip_address next-hop-self. Эта команда позволяет, например, R2 изменить адрес next hop на свой собственный адрес перед анонсированием маршрута пиру (peer). В Примере 7 R2 был настроен с командой neighbor 5.5.5.5 next-hop-self, которая изменяет next hop на 2.2.2.2, когда R2 анонсирует маршруты на R5. В Примере 8 показана BGP-таблица на R5, в которой теперь next hop для 10.1.1.0/26 — это 2.2.2.2, и теперь присутствует символ >, поэтому маршрут является наилучшим (best) и установлен в таблицу маршрутизации.
Пример 7. Изменение адреса next hop (Modifying Next-Hop Address)
R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 65502
R2(config-router)#neighbor 5.5.5.5 next-hop-self
Пример 8. Проверка адреса next hop в BGP-таблице (Verifying Next-Hop Address in BGP Table)
R5#show bgp ipv4 unicast
BGP table version is 13, local router ID is 5.5.5.5
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 1.1.1.1/32       2.2.2.2                  0    100      0 65501 ?
 *>i 10.1.1.0/26      2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.0/24      2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.64/26     2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.128/26    2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.192/26    2.2.2.2                  0    100      0 65501 i
 r>i 10.1.5.0/24      2.2.2.2               3328    100      0 i
 r>i 10.1.12.0/24     2.2.2.2                  0    100      0 65501 ?
 r>i 10.1.13.0/24     2.2.2.2                  0    100      0 65501 ?
* BGP-таблица (все BGP-маршруты, включая те, что не стали наилучшими).
💡 Дополнительное пояснение
Как читать символы BGP-таблице
Поле
Что означает
*
Маршрут valid (действительный)
>
Маршрут best (наилучший) — будет установлен в таблицу маршрутизации
i
Маршрут изучен через iBGP (internal)
* >
Маршрут valid и best — установлен в RIB
* (без >)
Маршрут valid, но не best — не установлен в RIB
r
RIB-failure — маршрут не установлен в RIB (например, из-за недостижимого next hop)
RIB (Routing Information Base - база маршрутной информации) — это таблица маршрутизации, которая содержит все маршруты, известные маршрутизатору, из всех источников: Connected (подключённые сети), Static (статические маршруты), OSPF, EIGRP, BGP, и другие.
Почему next hop не меняется?
BGP — это протокол между автономными системами (AS-by-AS), а не между маршрутизаторами.
Поэтому:
  • Когда R2 (AS 65502) получает маршрут от R1 (AS 65501), next hop = 1.1.1.1 (адрес R1).
  • R2 не меняет next hop по умолчанию, когда анонсирует маршрут R5 (тоже AS 65502).
  • R5 видит next hop = 1.1.1.1, но не знает, как до него добраться (нет маршрута в IGP).
  • Результат: маршрут valid, но не best → не установлен в RIB.
Как исправить
Способ
Команда
Где применять
next-hop-self
neighbor X.X.X.X next-hop-self
На R2 (для R5)
Статический маршрут
ip route 1.1.1.1 255.255.255.255 <next-hop>
На R5
Default route
ip route 0.0.0.0 0.0.0.0 <next-hop>
На R5
Анонс в IGP
network 1.1.1.1 (в OSPF/EIGRP)
На R1 или R2
⚠️ Важное предупреждение
Символ  r  (RIB-failure) — это ключевой индикатор проблемы!
Если вы видите  r  в BGP-таблице, это означает, что маршрут не был установлен в таблицу маршрутизации. Наиболее частая причина — недостижимый next hop.

failure [ˈfeɪljə] неудача, провал, сбой.

Как диагностировать:
1. show bgp ipv4 unicast — найдите маршрут с  r .
2. show ip route <next-hop> — есть ли маршрут к next hop?
3. ping <next-hop> — достижим ли next hop?
4. Если нет — настройте next-hop-self или добавьте маршрут.
📊 Сводная таблица: как диагностировать проблему с next hop
Шаг
Команда
Что проверить
1
show bgp ipv4 unicast
Есть ли  *  без  >  или  r ?
2
show ip route <next-hop>
Есть ли маршрут к next hop?
3
ping <next-hop>
Достижим ли next hop?
4
show run | section router bgp
Настроен ли  next-hop-self ?
5
show ip route bgp
Установлен ли маршрут в RIB?

Правило расщепления горизонта BGP (BGP Split-Horizon Rule)

Правило расщепления горизонта BGP (BGP split-horizon rule) гласит: BGP-маршрутизатор, получивший BGP-маршрут через iBGP-пиринг (iBGP peering), не должен анонсировать этот маршрут другому маршрутизатору, который является iBGP-пиром (iBGP peer). Важно запомнить это правило наизусть. Благодаря этому вы сможете распознать, когда именно эта причина приводит к отсутствию маршрутов (missing routes). На Рисунке 2 показаны текущие BGP-пиринги (BGP peerings). Обратите внимание, что R2 имеет iBGP-пиринг с R4, а R4 имеет iBGP-пиринг с R5. Когда R2 анонсирует сеть 10.1.1.0/26 (в качестве примера) на R4, это происходит через iBGP-пиринг. Поскольку R4 и R5 являются iBGP-пирами, R4 не будет анонсировать сеть 10.1.1.0/26 на R5 из-за правила расщепления горизонта BGP.
Рисунок 2. BGP-пиринги, демонстрирующие правило расщепления горизонта BGP (BGP Peerings Enforcing the BGP Split-Horizon Rule)
Чтобы R5 узнал о сети 10.1.1.0/26, он должен быть iBGP-пиром с маршрутизатором, который узнал этот маршрут от eBGP-пира (eBGP peer), или он должен быть пиром с отражателем маршрутов (route reflector), что выходит за рамки этого обзора. На Рисунке 3 показано, какими должны быть iBGP-пиринги, чтобы гарантировать, что и R4, и R5 узнают о 10.1.1.0/26 (а также о других сетях). Это также обеспечивает оптимизацию избыточности (redundancy) в BGP-AS.
Рисунок 3. Правильные BGP-пиринги для избежания правила расщепления горизонта BGP (Proper BGP Peerings to Avoid the BGP Split-Horizon Rule)
📌 Ключевая тема
Использование команды show bgp ipv4 unicast summary (если используете VRF, команда будет выглядеть так: show ip bgp vpnv4 vrf <vrf-name> summary) на всех маршрутизаторах для выявления пирингов (peerings), а затем рисование ваших пирингов на бумаге даст вам представление о том, вызывает ли правило расщепления горизонта BGP (BGP split-horizon rule) отсутствие маршрутов (missing routes), при условии, что вы помните следующее: BGP-маршрутизатор, получивший BGP-маршрут через iBGP-пиринг (iBGP peering), не должен анонсировать этот маршрут другому маршрутизатору, который является iBGP-пиром (iBGP peer).
💡 Дополнительное пояснение
Почему существует правило расщепления горизонта?
Правило расщепления горизонта BGP (BGP split-horizon rule) существует для предотвращения петель маршрутизации (routing loops) внутри автономной системы (AS).
Как это работает:
  • iBGP-маршруты не изменяют атрибут AS_Path (в отличие от eBGP).
  • Если бы R4 анонсировал маршрут, полученный от R2, обратно на R5, а R5 — обратно на R2, могла бы возникнуть петля.
  • Чтобы этого избежать, BGP запрещает повторный анонс iBGP-маршрутов другим iBGP-пирам.
Как обойти правило расщепления горизонта?
Способ
Описание
Полносвязная топология (Full Mesh)
Каждый iBGP-маршрутизатор имеет пиринг с каждым другим iBGP-маршрутизатором
Отражатели маршрутов (Route Reflectors)
Специальный маршрутизатор, который отражает маршруты iBGP-пирам
Конфедерации (Confederations)
Разделение AS на под-AS для упрощения полносвязной топологии
В рамках этого обзора рассматривается только полносвязная топология (Full Mesh) — именно поэтому на Рисунке 3 показано, что R5 должен иметь iBGP-пиринг напрямую с R2 (маршрутизатором, который узнал маршрут от eBGP-пира).
⚠️ Важное предупреждение
Правило расщепления горизонта — одна из самых частых причин отсутствия маршрутов в iBGP!
Если вы видите, что:
  • Сессия iBGP установлена (show bgp ipv4 unicast summary — состояние Established).
  • Маршрут есть в BGP-таблице на одном маршрутизаторе, но отсутствует на другом iBGP-пире.
Проверьте:
1. Полносвязная ли у вас топология iBGP? (Каждый с каждым?).
2. Если нет — это ожидаемое поведение (правило расщепления горизонта).
3. Решение: настроить полносвязную топологию или использовать отражатели маршрутов (route reflectors).
📊 Сводная таблица: диагностика проблемы расщепления горизонта
Шаг
Команда
Что проверить
1
show bgp ipv4 unicast summary
Все ли iBGP-пиры установлены?
2
show bgp ipv4 unicast
Есть ли маршрут в BGP-таблице?
3
Нарисовать топологию iBGP-пирингов
Полносвязная ли топология?
4
Проверить на другом iBGP-пире
Есть ли маршрут там?
5
Если нет — это split-horizon
Настроить full mesh или route reflector
* Если используете VRF, команда show bgp ipv4 unicast summary будет выглядеть так: show ip bgp vpnv4 vrf <имя_VRF> summary
Пример: как выглядит полносвязная топология (Full Mesh)
   ❌ Проблемная топология (не полносвязная):

   R2 (iBGP) ──── R4 (iBGP) ──── R5 (iBGP)
        │                              │
        └────────── ? ─────────────────┘
              (нет прямого пиринга)

   R4 не анонсирует маршруты от R2 на R5 (split-horizon)


   ✅ Правильная топология (Full Mesh):

   R2 (iBGP) ──── R4 (iBGP)
        │              │
        │              │
        └──── R5 (iBGP)┘

   Каждый iBGP-маршрутизатор имеет пиринг с каждым другим
   → Правило расщепления горизонта не применяется

Лучший источник информации (Better Source of Information)

Маршруты, изученные от eBGP-пиров (eBGP peers), имеют административную дистанцию (administrative distance, AD) 20, а маршруты, изученные от iBGP-пиров, — 200. Почему такая огромная разница? BGP предназначен для обмена маршрутами между разными автономными системами. Следовательно, если вы изучаете маршрут из другой автономной системы через eBGP, iBGP или EIGRP, вы хотите, чтобы маршрут, изученный через eBGP, был лучшим источником информации (best source of information) по сравнению со всеми другими протоколами динамической маршрутизации. Например, обратитесь снова к Рисунку 3. R1 анонсирует 10.1.1.0/26 на R2 через eBGP и на R3 через eBGP. R3, поскольку у него есть iBGP-пиринг с R2, анонсирует этот маршрут на R2 через iBGP. Кроме того, предположим, что на R3 мы перераспределили (redistribute) маршрут 10.1.1.0/26, изученный через eBGP, в EIGRP, и R2 изучил его через EIGRP-обновление (EIGRP update). Теперь R2 знает об одной и той же сети из трёх разных источников: eBGP (20), iBGP (200) и EIGRP (170). В результате выбирается путь eBGP, потому что у него наименьшая AD. Если бы не меньшая AD у eBGP, мы получили бы субоптимальную маршрутизацию (suboptimal routing), так как использовался бы другой источник, и трафик сначала шёл бы на R3, прежде чем покинуть сеть, вместо того чтобы идти напрямую от R2 к R1.
В Примере 9 показан вывод IPv4 Unicast BGP-таблицы на R5 с помощью команды show bgp ipv4 unicast. В таблице вы заметите, что сети 10.1.5.0/24, 10.1.12.0/24 и 10.1.13.0/24 являются best (установлены в таблицу маршрутизации), на что указывает символ  > , однако они не valid. Они помечены как имеющие RIB failure (отказ RIB), на что указывает символ  r . RIB failure означает, что BGP-маршрут не смог быть установлен в таблицу маршрутизации, однако вы ясно видите, что маршрут есть в таблице маршрутизации благодаря символу  > . Будьте внимательны здесь. В данном случае маршрут в таблице маршрутизации — от лучшего источника (better source).
Пример 9. Проверка BGP-маршрутов (Verifying BGP Routes)
R5#show bgp ipv4 unicast
BGP table version is 10, local router ID is 5.5.5.5
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.1.1.1/32       3.3.3.3                  0    100      0 65501 ?
 *>i                  2.2.2.2                  0    100      0 65501 ?
 * i 10.1.1.0/26      3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.0/24      3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.64/26     3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.128/26    3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.192/26    3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 r i 10.1.5.0/24      3.3.3.3               3328    100      0 i
 r>i                  2.2.2.2               3328    100      0 i
 r i 10.1.12.0/24     3.3.3.3                  0    100      0 65501 ?
 r>i                  2.2.2.2                  0    100      0 65501 ?
 r i 10.1.13.0/24     3.3.3.3                  0    100      0 65501 ?
 r>i                  2.2.2.2                  0    100      0 65501 ?
Использование команды show ip route 10.1.5.0 255.255.255.0, как показано в Примере 10, указывает на то, что 10.1.5.0/24 изучен через connected. В том же примере вы также можете увидеть вывод команды show ip route 10.1.12.0 255.255.255.0, который указывает на то, что маршрут был изучен через EIGRP. Connected — всегда самый надёжный источник; следовательно, он всегда используется вместо другой маршрутной информации. Что касается сети 10.1.12.0/24, вывод команды show bgp ipv4 unicast 10.1.12.0 в Примере 11 указывает на то, что маршрут был изучен от R2 и R3 через iBGP (internal), у которого AD = 200, что намного выше, чем у EIGRP.
Пример 10. Проверка AD маршрутов в таблице маршрутизации (Verifying AD of Routes in Routing Table)
R5#show ip route 10.1.5.0 255.255.255.0
Routing entry for 10.1.5.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  ...выходные данные опущены...

R5#show ip route 10.1.12.0 255.255.255.0
Routing entry for 10.1.12.0/24
  Known via "eigrp 100", distance 90, metric 3328, type internal
  ...выходные данные опущены...
* Если используете VRF, команда для проверки AD маршрутов будет выглядеть так: show ip route vrf <имя_VRF> 10.1.5.0 255.255.255.0
Пример 11. Проверка деталей BGP-маршрутов (Verifying Details of BGP Routes)
R5#show bgp ipv4 unicast 10.1.12.0
BGP routing table entry for 10.1.12.0/24, version 50
Paths: (2 available, best #2, table default, RIB-failure(17))
  Not advertised to any peer
  Refresh Epoch 2
  65501
    3.3.3.3 (metric 131072) from 3.3.3.3 (3.3.3.3)
      Origin incomplete, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  65501
    2.2.2.2 (metric 131072) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
* Если используете VRF, команда для проверки деталей BGP-маршрутов будет выглядеть так: show ip bgp vpnv4 vrf <имя_VRF> 10.1.12.0
Вы можете проверить, почему маршрут испытывает RIB failure, с помощью команды show bgp ipv4 unicast rib-failure, как показано в Примере 12. В этом примере все три RIB failure вызваны тем, что BGP-маршрут имеет более высокую AD.
Пример 12. Проверка RIB-отказов (Verifying RIB Failures)
R5#show bgp ipv4 unicast rib-failure
Network          Next Hop                   RIB-failure   RIB-NH Matches
10.1.5.0/24      2.2.2.2          Higher admin distance              n/a
10.1.12.0/24     2.2.2.2          Higher admin distance              n/a
10.1.13.0/24     2.2.2.2          Higher admin distance              n/a
* Если используете VRF, команда для проверки RIB-отказов будет выглядеть так: show ip bgp vpnv4 vrf <имя_VRF> rib-failure
Ключевые термины, сохраненные в скобках:
Термин
Пояснение
Administrative distance (AD)
Административная дистанция
Better source of information
Лучший источник информации
Suboptimal routing
Субоптимальная маршрутизация
RIB failure
Отказ RIB (маршрут не установлен в таблицу)
Redistribute
Перераспределить (маршруты)
Best / Valid
Наилучший / действительный
Connected
Подключенный (directly connected)
💡 Дополнительное пояснение
Административная дистанция (AD): почему это важно
Источник маршрута
AD
Приоритет
Connected
0
Наивысший
Static
1
Высокий
eBGP
20
Высокий (для внешних маршрутов)
EIGRP
90
Средний
OSPF
110
Средний
iBGP
200
Низкий
Логика: eBGP (20) имеет меньшую AD, чем iBGP (200), потому что маршруты, изученные из других автономных систем, считаются более надёжными, чем маршруты, переданные внутри своей AS через iBGP.

Что такое RIB failure (r)?

RIB failure означает, что BGP-маршрут не был установлен в таблицу маршрутизации (RIB), потому что другой источник предложил маршрут к той же сети с меньшей AD.
Пример из текста:
  • 10.1.12.0/24 изучен через EIGRP (AD = 90).
  • Тот же маршрут изучен через iBGP (AD = 200).
  • EIGRP побеждает → BGP-маршрут получает RIB failure ( r ).
  • Но в BGP-таблице он всё равно помечен как  >  (best), потому что среди BGP-маршрутов он лучший.

Как читать символы r и > вместе

Комбинация
Что означает
r>
Маршрут best в BGP, но не установлен в RIB (из-за лучшего источника)
*>
Маршрут valid и best, установлен в RIB
* (без >)
Маршрут valid, но не best
r (без >)
Маршрут не best и не установлен в RIB
⚠️ Важное предупреждение
Не путайте  r  (RIB failure) с проблемой next hop!
  •  r  из-за next hop — next hop недостижим (см. предыдущий раздел).
  •  r  из-за лучшего источника — другой протокол (connected, static, EIGRP) предложил маршрут с меньшей AD.
Как различить:
show bgp ipv4 unicast rib-failure
Если в колонке RIB-failure указано Higher admin distance — проблема в AD, а не в next hop.
📊 Сводная таблица: диагностика RIB failure
Шаг
Команда
Что проверить
1
show bgp ipv4 unicast
Есть ли символ  r ?
2
show bgp ipv4 unicast rib-failure
Причина:  Higher admin distance  или  Next Hop ?
3
show ip route <префикс>
Какой источник выиграл?
4
Сравнить AD
AD источника < AD BGP?

Фильтрация маршрутов (Route Filtering)

Объём контроля, который вы имеете над маршрутами в BGP, невероятен — настолько, что мы могли бы посвятить целую главу управлению BGP-маршрутами. Однако это вышло бы за рамки обзора и экзамена TSHOOT. Что мы хотим уметь делать при диагностике отсутствующих маршрутов (missing routes) — это определить, применён ли фильтр маршрутов (route filter) и является ли он причиной отсутствия маршрутов. В Примере 13 показана BGP-таблица на R5 с помощью команды show bgp ipv4 unicast. Обратите внимание, что отсутствует запись для 10.1.13.0/24
Пример 13. Проверка отсутствующих маршрутов на R5 (Verifying Missing Routes on R5)
R5#show bgp ipv4 unicast
BGP table version is 10, local router ID is 5.5.5.5
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.1.1.1/32       3.3.3.3                  0    100      0 65501 ?
 *>i                  2.2.2.2                  0    100      0 65501 ?
 * i 10.1.1.0/26      3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.0/24      3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.64/26     3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.128/26    3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 * i 10.1.1.192/26    3.3.3.3                  0    100      0 65501 i
 *>i                  2.2.2.2                  0    100      0 65501 i
 r i 10.1.5.0/24      3.3.3.3               3328    100      0 i
 r>i                  2.2.2.2               3328    100      0 i
 r i 10.1.12.0/24     3.3.3.3                  0    100      0 65501 ?
 r>i                  2.2.2.2                  0    100      0 65501 ?
Однако давайте проверим, получаем ли мы маршрут от R2 или R3, используя команду show bgp ipv4 unicast neighbors ip_address routes, как показано в Примере 14. Вывод ясно показывает, что мы не изучаем 10.1.13.0/24. Но подождите — эта команда отображает маршруты, изученные после применения локальных фильтров. Поэтому давайте проверим, анонсируют ли R2 или R3 маршрут 10.1.13.0/24, прежде чем проверять фильтры. Как показано в Примере 15, где отображается вывод команды show bgp ipv4 unicast neighbors ip_address advertised-routes, R2 и R3 анонсируют сеть 10.1.13.0/24 на R5.
Пример 14. Проверка того, получаются ли маршруты на R5 (Verifying Whether Routes Are Being Received on R5)
R5#show bgp ipv4 unicast neighbors 2.2.2.2 routes
BGP table version is 9, local router ID is 5.5.5.5
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 1.1.1.1/32       2.2.2.2                  0    100      0 65501 ?
 *>i 10.1.1.0/26      2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.0/24      2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.64/26     2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.128/26    2.2.2.2                  0    100      0 65501 i
 *>i 10.1.1.192/26    2.2.2.2                  0    100      0 65501 i
 r>i 10.1.5.0/24      2.2.2.2               3328    100      0 i
 r>i 10.1.12.0/24     2.2.2.2                  0    100      0 65501 ?

Total number of prefixes 8

R5#show bgp ipv4 unicast neighbors 3.3.3.3 routes
BGP table version is 9, local router ID is 5.5.5.5
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.1.1.1/32       3.3.3.3                  0    100      0 65501 ?
 * i 10.1.1.0/26      3.3.3.3                  0    100      0 65501 i
 * i 10.1.1.0/24      3.3.3.3                  0    100      0 65501 i
 * i 10.1.1.64/26     3.3.3.3                  0    100      0 65501 i
 * i 10.1.1.128/26    3.3.3.3                  0    100      0 65501 i
 * i 10.1.1.192/26    3.3.3.3                  0    100      0 65501 i
 r i 10.1.5.0/24      3.3.3.3               3328    100      0 i
 r i 10.1.12.0/24     3.3.3.3                  0    100      0 65501 ?

Total number of prefixes 8
* Если используете VRF, команда будет выглядеть так: show ip bgp vpnv4 vrf <имя_VRF> neighbors 2.2.2.2 routes
Пример 15. Проверка того, отправляются ли маршруты на R5 (Verifying Whether Routes Are Being Sent to R5)
R2#show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes
BGP table version is 10, local router ID is 2.2.2.2
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>  1.1.1.1/32       1.1.1.1                  0              0 65501 ?
 *>  10.1.1.0/26      1.1.1.1                  0              0 65501 i
 *>  10.1.1.0/24      1.1.1.1                  0              0 65501 i
 *>  10.1.1.64/26     1.1.1.1                  0              0 65501 i
 *>  10.1.1.128/26    1.1.1.1                  0              0 65501 i
 *>  10.1.1.192/26    1.1.1.1                  0              0 65501 i
 *>  10.1.5.0/24      10.1.24.4            3328          32768 i
 r>  10.1.12.0/24     1.1.1.1                  0              0 65501 ?
 *>  10.1.13.0/24     1.1.1.1                  0              0 65501 ?

Total number of prefixes 9

R3#show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes
BGP table version is 10, local router ID is 3.3.3.3
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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       10.1.13.1                0              0 65501 ?
 *>  10.1.1.0/26      10.1.13.1                0              0 65501 i
 *>  10.1.1.0/24      10.1.13.1                0              0 65501 i
 *>  10.1.1.64/26     10.1.13.1                0              0 65501 i
 *>  10.1.1.128/26    10.1.13.1                0              0 65501 i
 *>  10.1.1.192/26    10.1.13.1                0              0 65501 i
 *>  10.1.5.0/24      10.1.34.4            3328          32768 i
 *>  10.1.12.0/24     10.1.13.1                0              0 65501 ?
 r>  10.1.13.0/24     10.1.13.1                0              0 65501 ?

Total number of prefixes 9
* Если используете VRF, команда будет выглядеть так: show ip bgp vpnv4 vrf <имя_VRF> neighbors 5.5.5.5 advertised-routes
📌 Ключевая тема
Выполнение команды show ip protocols, как показано в Примере 16, отображает входящий фильтр (incoming filter), применённый к BGP-автономной системе. Это distribute list, использующий prefix list под названием FILTER_10.1.13.0/24, как показано в Примере 16. Prefix list, как также показано в Примере 16, запрещает (deny) 10.1.13.0/24 и разрешает (permit) все остальные маршруты.
Пример 16. Проверка того, применены ли фильтры на R5 (Verifying Whether Filters Are Applied to R5)
R5#show ip protocols
...выходные данные опущены...
Routing Protocol is "bgp 65502"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is (prefix-list) FILTER_10.1.13.0/24
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn   FiltOut  DistIn   DistOut  Weight  RouteMap
    2.2.2.2
    3.3.3.3
  Maximum path: 1
  Routing Information Sources:
  ...выходные данные опущены...

R5#show ip prefix-list
ip prefix-list FILTER_10.1.13.0/24: 2 entries
   seq 5 deny 10.1.13.0/24
   seq 10 permit 0.0.0.0/0 le 32

R5#show run | include bgp 65502|distribute-list
router bgp 65502
 distribute-list prefix FILTER_10.1.13.0/24 in
* Если используете VRF, команда для проверка того, применены ли фильтры будет выглядеть так: show ip protocols vrf <имя_VRF>
Пример, который мы только что рассмотрели, был посвящён фильтру, применённому ко всему BGP-процессу. Следовательно, независимо от того, от какого маршрутизатора мы получаем маршрут 10.1.13.0/24, он будет запрещён. Однако вы можете применить фильтр непосредственно к соседу (neighbor), используя любую из следующих команд:
  • neighbor ip_address distribute-list access_list_number { in | out }
  • neighbor ip_address prefix-list prefix_list_name { in | out }
  • neighbor ip_address route-map map_name { in | out }
  • neighbor ip_address filter-list access_list_number { in | out }
Как проверить, применён ли фильтр маршрутов (route filter) конкретно к соседу? Вы проверяете фильтры теми же командами show, что и раньше. Просто нужно смотреть в другое место вывода. Обратитесь к Примеру 17. В этом примере входящий distribute list (inbound distribute list) применён непосредственно к соседу 2.2.2.2, как показано в выводе show ip protocols. Обратите внимание, что отображаются только первые шесть символов ACL. Затем мы просматриваем текущую конфигурацию (running configuration) и видим, что distribute list использует ACL с именем FILTER_10.1.13.0/24. Использование команды show ip access-list подтверждает, что маршрутизатор запрещает сеть 10.1.13.0/24 от 2.2.2.2, но разрешает все остальные сети.
Пример 17. Проверка distribute list, применённого к соседу (Verifying a Distribute List Applied to a Neighbor)
R5#show ip protocols
...выходные данные опущены...

Routing Protocol is "bgp 65502"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn   FiltOut  DistIn   DistOut  Weight  RouteMap
    2.2.2.2          FILTER
    3.3.3.3
  Maximum path: 1
  Routing Information Sources:
  ...выходные данные опущены...

R5#show run | include bgp 65502|distribute-list
router bgp 65502
 neighbor 2.2.2.2 distribute-list FILTER_10.1.13.0/24 in

R5#show ip access-lists
Standard IP access list FILTER_10.1.13.0/24
  10 deny 10.1.13.0, wildcard bits 0.0.0.255
  20 permit any
Как отмечалось ранее, вы также можете применить route map, prefix list и filter list непосредственно к команде neighbor. Filter list появится в колонке FiltIn и FiltOut в show ip protocols, а route map появится в колонке RouteMap в выводе show ip protocols. Если prefix list применён непосредственно к оператору neighbor, он не появляется в выводе show ip protocols. Вам нужно будет просмотреть вывод show bgp ipv4 unicast neighbors. Однако, как вы помните, это крайне подробный (extremely verbose) вывод. Поэтому вот короткий путь, который вы, возможно, захотите запомнить для диагностики фильтров маршрутов (route filters):
show bgp ipv4 unicast neighbors ip_address | include prefix|filter|Route map
В Примере 18 показан образец того, что появилось бы в выводе show bgp ipv4 unicast neighbors на R5 на основе различных фильтров, применённых к соседям R2 и R3 и от них. В выводе вы можете видеть, что входящий prefix list (inbound prefix list) применён непосредственно к соседу 3.3.3.3 под названием FILTER_10.1.13.0/24, также есть исходящий route map (outbound route map) под названием FILTER_10.1.5.0/24 для маршрутов, отправляемых соседу 3.3.3.3.
Что касается соседа 2.2.2.2, к оператору neighbor применён входящий "network filter" (distribute list), использующий ACL под названием FILTER_10.1.13.0/24, а также входящий ACL  (AS path ACL) под названием  25 .
Пример 18. Проверка фильтров, применённых к операторам neighbor (Verifying Filters Applied to the neighbor Statements)
R5#show bgp ipv4 unicast neighbors 3.3.3.3 | include prefix|filter|Route map
  Incoming update prefix filter list is FILTER_10.1.13.0/24
  Route map for outgoing advertisements is FILTER_10.1.5.0/24

R5#show bgp ipv4 unicast neighbors 2.2.2.2 | include prefix|filter|Route map
  Incoming update network filter list is FILTER_10.1.13.0/24
  Incoming update AS path filter list is 25
Ключевые термины, сохраненные в скобках:
Термин
Пояснение
Транскрипция
Route Filtering
Фильтрация маршрутов
[ruːt ˈfɪltərɪŋ]
Missing routes
Отсутствующие маршруты
[ˈmɪsɪŋ ruːts]
Route filter
Фильтр маршрутов
[ruːt ˈfɪltə]
Distribute list
Список распределения (фильтр)
[dɪsˈtrɪbjut lɪst]
Prefix list
Список префиксов
[ˈpriːfɪks lɪst]
Route map
Карта маршрутов
[ruːt mæp]
Filter list
Список фильтров
[ˈfɪltə  lɪst]
Access list (ACL)
Список контроля доступа
[ˈækses  lɪst]
Advertised-routes
Анонсированные маршруты
[ˈædvətaɪzd ruːts]
Neighbor
Сосед (BGP-пир)
[ˈneɪbə]
💡 Дополнительное пояснение

Как диагностировать фильтрацию маршрутов: пошаговый алгоритм

Шаг
Команда
Что проверить
1
show bgp ipv4 unicast
Есть ли маршрут в BGP-таблице?
2
show bgp ipv4 unicast neighbors <IP> routes
Получаем ли мы маршрут от соседа?
3
show bgp ipv4 unicast neighbors <IP> advertised-routes
Анонсирует ли сосед маршрут нам?
4
show ip protocols
Есть ли фильтр на весь BGP-процесс?
5
show run | include bgp|distribute-list
Есть ли фильтр на конкретного соседа?
6
show ip prefix-list / show ip access-lists
Что именно запрещает/разрешает фильтр?
7
show bgp ipv4 unicast neighbors <IP> | include prefix|filter|Route map
Какие фильтры применены к соседу?

Разница между «routes» и «advertised-routes»

Команда
Что показывает
Когда использовать
neighbors <IP> routes
Маршруты, полученные от соседа (после локальных фильтров)
Проверить, что мы изучили
neighbors <IP> advertised-routes
Маршруты, отправленные соседу
Проверить, что сосед анонсирует нам
Логика диагностики:
1. Если маршрут есть в  advertised-routes , но нет в  routes  → проблема в локальном фильтре (входящем).
2. Если маршрут нет в  advertised-routes  → проблема на соседе (исходящий фильтр или отсутствие маршрута).
⚠️ Важное предупреждение
Prefix list, применённый к соседу, НЕ отображается в  show ip protocols !
  • Distribute list → отображается в  show ip protocols  (колонка DistIn).
  • Filter list → отображается в  show ip protocols  (колонка FiltIn).
  • Route map → отображается в  show ip protocols  (колонка RouteMap).
  • Prefix list → НЕ отображается в show ip protocols!
Как найти prefix list, применённый к соседу:
show run | include bgp|prefix-list
show bgp ipv4 unicast neighbors  | include prefix|filter|Route map
📊 Сводная таблица: где искать применённые фильтры
Тип фильтра
Где искать
Колонка
Distribute list
 show ip protocols 
DistIn / DistOut
Filter list
 show ip protocols 
FiltIn / FiltOut
Route map
 show ip protocols 
RouteMap
Prefix list
 show run  или  show bgp ... neighbors 
 —