Проблемный тикет BGP: разбор реального кейса с неправильным AS

Создана 25.09.2026
Отредактирована 28.09.2026

Этот тикет (где тикет, это заявка о проблеме, поступившая в отдел NOC (отдел сетевого администрирования)) — часть серии «Проблемные тикеты BGP» (BGP Trouble Tickets), основанной на общей топологии (Рисунок 1). Цель серии — показать процесс диагностики (troubleshooting process), который вы можете применить в реальной работе или на экзамене.

В этом тикете: линк между R1 и R2 упал, и трафик должен был пойти через R3, но этого не произошло. Причина — неправильный номер AS в операторе neighbor remote-as на R3.

Рисунок 1. Топология BGP

Проблема: Вы сетевой администратор BGP-автономной системы 65502. Пока вы были в отпуске, линк (канал) между R1 и R2 упал. Когда линк между R1 и R2 падает, линк между R1 и R3 должен перенаправлять трафик в BGP-автономную систему 65501. Однако этого не произошло, пока вас не было. Ваш коллега был вынужден восстановить связность между R1 и R2, пока жалобы от пользователей в сети 10.1.5.0/24 о недоступности сетей 10.1.1.0/24 продолжали поступать.

На данный момент связность в порядке. Вы подтверждаете это, выполняя ping с ПК в сети 10.1.5.0/24 до 10.1.1.10. В Примере 1 ping успешен. Поскольку сейчас середина дня, вы не можете отключить линк между R1 и R2, чтобы воссоздать проблему, потому что это нарушит работу пользователей сети. Следовательно, вам нужно проявить креативность в диагностике.

Пример 1. Проверка связности (Verifying Connectivity)

C:\>ping 10.1.1.10

Pinging 10.1.1.10 with 32 bytes of data:

Reply from 10.1.1.10: bytes=32 time=1ms TTL=128
Reply from 10.1.1.10: bytes=32 time=1ms TTL=128
Reply from 10.1.1.10: bytes=32 time=1ms TTL=128
Reply from 10.1.1.10: bytes=32 time=1ms TTL=128

Ping statistics for 10.1.1.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Чтобы R5 знал о сетях в автономной системе 65501, они должны быть анонсированы ему. Лучшее место, чтобы увидеть, изучает ли R5 маршруты — это BGP-таблица R5. Основываясь на топологии сети, R5 должен изучать сети от R2 и R3. В Примере 2 показан вывод команды show bgp ipv4 unicast. Как видно из колонки Next-hop, все действительные маршруты к сетям 10.1.1.x/26 — через next hop 2.2.2.2 (это R2). Записей от R3 (3.3.3.3), действительных для этих сетей, нет.

Пример 2. Просмотр BGP-таблицы R5 (Examining R5's BGP Table)

R5#show bgp ipv4 unicast BGP table version is 56, 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.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 3.3.3.3 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 ?

💡 Примечание: На старых версиях IOS команда show bgp ipv4 unicast недоступна. Используйте аналог: show ip bgp vpnv4 vrf <имя_VRF> . Он предназначен для отображения таблицы VPNv4 — маршрутов внутри VRF, обычно связанных с MPLS L3VPN.

💡 Пояснение к Примеру 2

r>i 10.1.5.0/24 и r i 3.3.3.3 — это одна и та же сеть (10.1.5.0/24), но с двумя next hop: 2.2.2.2 (R2) и 3.3.3.3 (R3). В Cisco IOS, если сеть совпадает, она не повторяется (вы видите пустое место) во второй строке — вместо неё просто указан новый next hop.

Символ r (RIB failure) означает, что маршрут не установлен в таблицу маршрутизации. Причина — сеть 10.1.5.0/24 является connected на R5 (AD = 0), поэтому BGP-маршрут (AD = 200) проигрывает.

Символ > в первой строке ( r>i ) означает, что среди BGP-маршрутов этот путь — best, но в RIB он всё равно не установлен из-за RIB failure.

Далее вы хотите подтвердить, получает ли R5 вообще маршруты от R3. Поэтому вы выполняете команды show bgp ipv4 unicast neighbors 2.2.2.2 routes и show bgp ipv4 unicast neighbors 3.3.3.3 routes, чтобы определить, какие маршруты получаются, и сравнить, что анонсируется от R2 и от R3. Вывод в Примере 3 ясно показывает, что R5 не получает никаких маршрутов о сетях 10.1.1.x/26 от R3. Это и есть причина, по которой связность была потеряна, когда линк между R1 и R2 упал. У R5 нет никакой информации о маршрутах от R3.

Пример 3. Проверка маршрутов, полученных от R2 и R3

R5#show bgp ipv4 unicast neighbors 2.2.2.2 routes BGP table version is 56, local router ID is 5.5.5.5 ...выходные данные опущены... 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.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 ? Total number of prefixes 8 R5#show bgp ipv4 unicast neighbors 3.3.3.3 routes BGP table version is 56, local router ID is 5.5.5.5 ...выходные данные опущены... Network Next Hop Metric LocPrf Weight Path r i 10.1.5.0/24 3.3.3.3 3328 100 0 i Total number of prefixes 1

💡 Примечание: На старых версиях IOS команда show bgp ipv4 unicast neighbors <ip-адрес> routes недоступна. Используйте аналог: show ip bgp vpnv4 vrf <имя_VRF> neighbors <ip-адрес> routes . Она предназначена для отображения маршрутов, полученных от конкретного соседа внутри VRF — обычно связанных с MPLS L3VPN.

Вы заходите на R3 и выполняете команду show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes, чтобы определить, какие маршруты (если вообще) R3 отправляет на R5. В Примере 4 видно, что нет маршрутов, связанных с сетями 10.1.1.x/26, анонсируемых на R5. Возникает вопрос: а знает ли R3 об этих сетях вообще?

Пример 4. Проверка маршрутов, полученных от R2 и R3

R3#show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes BGP table version is 108, local router ID is 3.3.3.3 ...выходные данные опущены... Network Next Hop Metric LocPrf Weight Path *> 10.1.5.0/24 10.1.34.4 3328 32768 i Total number of prefixes 1

💡 Примечание: На старых версиях IOS команда show bgp ipv4 unicast neighbors <ip-адрес> advertised-routes недоступна. Используйте аналог: show ip bgp vpnv4 vrf <имя_VRF> neighbors <ip-адрес> advertised-routes. Она предназначена для отображения маршрутов, анонсированных конкретному соседу внутри VRF — обычно связанных с MPLS L3VPN.

На R3 вы выполняете команду show ip route 10.1.1.0 255.255.255.0 longer-prefixes, как показано в Примере 5, и подтверждаете, что сети изучены через BGP. Однако вы также замечаете кое-что странное. AD = 200, что соответствует маршрутам, изученным через iBGP, а next hop — через 2.2.2.2 (это R2). AD должна быть 20 для eBGP, а next hop в этом случае должен быть IP-адресом R1.

💡 Пояснение к Примеру 5:

AD = 200 означает, что маршруты к 10.1.1.x/26 изучены через iBGP (от R2), а не через eBGP (от R1). Если бы маршруты приходили от R1 через eBGP, AD была бы 20, а next hop — 10.1.13.1 (IP-адрес R1).

Next hop = 2.2.2.2 (R2) — это аномалия: R3 должен был получить эти маршруты напрямую от R1 через eBGP, но получает их от R2 через iBGP. Это и есть корень проблемы — R3 не имеет eBGP-соседства с R1.

Пример 5. Проверка маршрутов, полученных от R2 и R3

R3#show ip route 10.1.1.0 255.255.255.0 longer-prefixes ...выходные данные опущены... Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks B 10.1.1.0/26 [200/0] via 2.2.2.2, 00:09:07 B 10.1.1.64/26 [200/0] via 2.2.2.2, 00:09:07 B 10.1.1.128/26 [200/0] via 2.2.2.2, 00:09:07 B 10.1.1.192/26 [200/0] via 2.2.2.2, 00:09:07

💡 Примечание: На старых версиях IOS команда show ip route 10.1.1.0 255.255.255.0 longer-prefixes показывает маршруты только из глобальной таблицы. Чтобы увидеть маршруты внутри конкретного VRF, добавьте параметр vrf: show ip route vrf <имя_VRF> 10.1.1.0 255.255.255.0 longer-prefixes . Это особенно важно при работе с MPLS L3VPN, где маршруты изолированы по VRF.

Вы выполняете команду show bgp ipv4 unicast на R3, чтобы проверить BGP-таблицу, как показано в Примере 6. Судя по выводу, только R2 и R4 являются next hop для маршрутов. R1 не является next hop ни для одного из них.

Пример 6. Просмотр BGP-маршрутов в BGP-таблице R3

R3#show bgp ipv4 unicast BGP table version is 108, local router ID is 3.3.3.3 ...выходные данные опущены... 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 * i 10.1.5.0/24 2.2.2.2 3328 100 0 i *> 10.1.34.4 3328 32768 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 ?

💡 show ip bgp vpnv4 vrf <имя_VRF>

Выполнение команды show bgp ipv4 unicast neighbors 10.1.13.1 routes на R3 подтверждает, что никакие маршруты не получаются от R1, как показано в Примере 7.

Пример 7. Проверка маршрутов, изученных от R1

R3#show bgp ipv4 unicast neighbors 10.1.13.1 routes Total number of prefixes 0

💡 show ip bgp vpnv4 vrf <имя_VRF> neighbors <ip-адрес> routes

Поскольку R1 не в вашей автономной системе, вы не можете получить к нему доступ для диагностики. Следовательно, вам нужно позвонить администратору в автономной системе 65501. Однако не делайте этого пока. Мы можем проверить много других вещей на R3. Например, чтобы изучать BGP-маршруты, нужно BGP-соседство. Чтобы подтвердить, что R3 является соседом с R1, вы выполняете команду show bgp ipv4 unicast summary, как показано в Примере 8.

Судя по выводу, R1 и R3 не являются соседями, потому что состояние указано как idle. Вы думаете, что нашли проблему.

Пример 8. Проверка соседства между R1 и R3

R3#show bgp ipv4 unicast summary BGP router identifier 3.3.3.3, local AS number 65502 BGP table version is 108, main routing table version 108 9 network entries using 1296 bytes of memory 10 path entries using 800 bytes of memory 5/4 BGP path/bestpath attribute entries using 680 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 2800 total bytes of memory BGP activity 17/8 prefixes, 71/61 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 34 34 108 0 0 00:24:29 9 4.4.4.4 4 65502 47 48 108 0 0 00:39:00 0 5.5.5.5 4 65502 5 6 108 0 0 00:00:18 0 10.1.13.1 4 65510 0 0 1 0 0 never Idle

💡 show ip bgp vpnv4 vrf <имя_VRF> summary

💡 Пояснение к Примеру 8:

4.4.4.4 с State/PfxRcd = 0 — соседство с R4 установлено (сессия работает), но от R4 не получено ни одного префикса. Это может быть связано с тем, что R4 не анонсирует маршруты или они отфильтрованы. В данном тикете это не является проблемой — проблема в соседе 10.1.13.1.

10.1.13.1 с AS = 65510 — это неправильный AS. Согласно документации (Рисунок 1), R1 находится в AS 65501, а не 65510. Из-за этого соседство не устанавливается (состояние Idle).

5.5.5.5 с State/PfxRcd = 0 — соседство с R5 установлено, но от R5 не получено префиксов (R5 не анонсирует маршруты, потому что он получатель).

Сравнивая вывод в Примере 8 с вашей сетевой документацией (Рисунок 1), вы замечаете, что номер автономной системы неверен для 10.1.13.1. Он указан как 65510, хотя должен быть 65501. Чтобы исправить проблему, вы удаляете текущий оператор neighbor remote-as и добавляете правильный, как показано в Примере 9. После внесения изменений соседство (neighbor relationship) устанавливается.

Пример 9. Изменение оператора neighbor remote-as

R3#config t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router bgp 65502
R3(config-router)#no neighbor 10.1.13.1 remote-as 65510
R3(config-router)#neighbor 10.1.13.1 remote-as 65501
%BGP-5-ADJCHANGE: neighbor 10.1.13.1 Up
R3(config-router)#

Чтобы подтвердить, что всё в порядке, вы заходите на R5 и выполняете команду show bgp ipv4 unicast и подтверждаете, что маршруты от R2 и R3 теперь перечислены в BGP-таблице, как показано в Примере 10. Проблема решена. После рабочего дня вы отключите линк между R1 и R2 и подтвердите, что трафик успешно проходит между R3 и R1.

Пример 10. Подтверждение, что R5 знает маршруты от R2 и R3

R5#show bgp ipv4 unicast BGP table version is 56, local router ID is 5.5.5.5 ...выходные данные опущены... 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.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 bgp vpnv4 vrf <имя_VRF>

💡 Пояснение к Примеру 10:

r i 10.1.5.0/24 и r>i — маршрут к 10.1.5.0/24 имеет RIB failure ( r ), потому что эта сеть является connected на R5 (AD = 0). BGP-маршрут (AD = 200) проигрывает, но остаётся в BGP-таблице как best среди BGP-маршрутов.

r i 10.1.12.0/24 и r>i — аналогично: сеть 10.1.12.0/24, вероятно, является connected на R5, поэтому BGP-маршрут не установлен в RIB.

r i 10.1.13.0/24 и r>i — то же самое для сети 10.1.13.0/24.

Маршруты к 10.1.1.x/26 теперь имеют два пути: от R3 (3.3.3.3) и от R2 (2.2.2.2). Путь от R2 помечен > (best) — вероятно, из-за более низкого RID или другого атрибута.

Имея немного свободного времени, вы решаете проверить лог-файлы R3. Вы замечаете следующее сообщение BGP, появляющееся много раз:

%BGP-3-NOTIFICATION: sent to neighbor 10.1.13.1 passive 2/2 (peer in wrong AS) 2 bytes FFDD

Syslog-сообщение ясно указывает, что пир (peer) находится в неправильной автономной системе. Никогда не забывайте проверять лог-файлы перед началом диагностики. Это может сэкономить вам ценное время.