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

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

Создана 26.09.2026
Отредактирована 26.09.2026
В этом разделе представлены различные проблемные тикеты (trouble tickets), относящиеся к темам, рассмотренным ранее в этой главе. Цель этих тикетов — дать вам процесс, которому вы можете следовать при диагностике (troubleshooting) в реальном мире или на экзамене. Все тикеты в этом разделе основаны на топологии, изображённой на Рисунке 1.
Рисунок 1. Топология проблемных тикетов BGP (BGP Trouble Tickets Topology)

Тикет 1 (Trouble Ticket 1)

Проблема: Вы администратор 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 ?
💡 Пояснение к Примеру 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). В 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
text
Текст

Заголовок H2

Частные адреса не используются в глобальной сети Интернет. 

text
Параметр
Описание
Text
Text
Text
Text 
Страница в разработке