Проблемный тикет BGP: неверный local preference в route-map

Создана 26.09.2026
Отредактирована 27.09.2026

Проблема: Вы администратор BGP-автономной системы 65502. Отчёты о трафике показывают, что весь трафик из автономной системы идёт через R3 и по резервному линку. Это нежелательно, если только линк между R2 и R1 не упал.

Чтобы проверить проблему, вы используете traceroute с R5. Как показано в Примере 1, трассировка до 10.1.1.1 и 10.1.1.65 идёт через R3, чтобы достичь автономной системы 65501.

Пример 1. Проверка проблемы (Verifying the Issue)

R5#traceroute 10.1.1.1 source 10.1.5.5 Type escape sequence to abort. Tracing the route to 10.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.45.4 48 msec 40 msec 28 msec 2 10.1.34.3 64 msec 32 msec 60 msec 3 10.1.13.1 [AS 65501] 72 msec 52 msec 48 msec R5#traceroute 10.1.1.65 source 10.1.5.5 Type escape sequence to abort. Tracing the route to 10.1.1.65 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.45.4 48 msec 40 msec 28 msec 2 10.1.34.3 64 msec 32 msec 60 msec 3 10.1.13.1 [AS 65501] 72 msec 52 msec 48 msec

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

Первый прыжок 10.1.45.4 — это R4 (сосед R5).

Второй прыжок 10.1.34.3 — это R3.

Третий прыжок 10.1.13.1 — это R1 (AS 65501).

Вывод: трафик идёт через R4 → R3 → R1, а не через R4 → R2 → R1. Это и есть проблема — трафик использует резервный путь вместо основного.

На R5 вы выполняете команды show ip route 10.1.1.1 и show ip route 10.1.1.65 , чтобы проверить маршруты. Как показано в Примере 2, маршруты были изучены через iBGP и достижимы через 3.3.3.3 (это R3).

Пример 2. Проверка маршрутов на R5

R5#show ip route 10.1.1.1 Routing entry for 10.1.1.0/26 Known via "bgp 65502", distance 200, metric 0 Tag 65501, type internal Last update from 3.3.3.3 00:01:09 ago Routing Descriptor Blocks: * 3.3.3.3, from 3.3.3.3, 00:01:09 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 65501 MPLS label: none R5#show ip route 10.1.1.65 Routing entry for 10.1.1.64/26 Known via "bgp 65502", distance 200, metric 0 Tag 65501, type internal Last update from 3.3.3.3 00:02:10 ago Routing Descriptor Blocks: * 3.3.3.3, from 3.3.3.3, 00:02:10 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 65501 MPLS label: none

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

distance 200 — это административная дистанция (AD) для iBGP.

type internal — маршрут изучен через iBGP.

from 3.3.3.3 — маршрут получен от R3.

* 3.3.3.3 — этот путь выбран как лучший для установки в RIB.

Изучаются ли маршруты от R2? Вы выполняете команду show bgp ipv4 unicast , чтобы изучить BGP-таблицу. Согласно BGP-таблице в Примере 3, 10.1.1.0/26 и 10.1.1.64/26 также изучены через R2. Так почему же R5 предпочитает R3 как лучший путь? Теперь вы должны изучить процесс выбора пути BGP между next hop 2.2.2.2 и 3.3.3.3.

Пример 3. Просмотр BGP-таблицы R5

R5#show bgp ipv4 unicast BGP table version is 613, 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 50 0 65501 ? *>i 10.1.1.0/26 3.3.3.3 0 100 0 65501 i * i 2.2.2.2 0 50 0 65501 i *>i 10.1.1.64/26 3.3.3.3 0 100 0 65501 i * i 2.2.2.2 0 50 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 50 0 i r>i 10.1.12.0/24 3.3.3.3 0 100 0 65501 ? r i 2.2.2.2 0 50 0 65501 ? r>i 10.1.13.0/24 3.3.3.3 0 100 0 65501 ? r i 2.2.2.2 0 50 0 65501 ?

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

Для 10.1.1.0/26 и 10.1.1.64/26 есть два пути: через R3 (3.3.3.3) и через R2 (2.2.2.2).

Путь через R3 ( *>i ) — best, потому что Local Preference = 100.

Путь через R2 ( * i ) — не best, потому что Local Preference = 50.

Local Preference — это атрибут, который влияет на выбор пути внутри AS. Чем выше значение, тем предпочтительнее путь.

Прежде всего, может ли R5 достичь 2.2.2.2 и 3.3.3.3? Очевидно, 3.3.3.3 достижим, потому что R5 использует его в данный момент. Однако команда show ip route 2.2.2.2, как показано в Примере 4, подтверждает, что 2.2.2.2 также достижим. Это важно, потому что путь никогда не будет использован, если next hop недостижим.

Пример 4. Подтверждение достижимости 2.2.2.2

R5#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "eigrp 100", distance 90, metric 131072, type internal Redistributing via eigrp 100 Last update from 10.1.45.4 on GigabitEthernet1/0, 22:33:44 ago Routing Descriptor Blocks: * 10.1.45.4, from 10.1.45.4, 22:33:44 ago, via GigabitEthernet1/0 Route metric is 131072, traffic share count is 1 Total delay is 5020 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2

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

2.2.2.2 достижим через EIGRP (AD = 90, метрика = 131072).

Next hop — 10.1.45.4 (R4).

Вывод: путь через R2 достижим, но не выбирается из-за более низкого Local Preference.

Далее вы изучаете weight, как показано в Примере 3. Он равен 0 для обоих путей — и через 2.2.2.2, и через 3.3.3.3. Следовательно, совпадение (tie) означает проверку следующего атрибута — local preference. В данном случае путь через 2.2.2.2 имеет 50, а путь через 3.3.3.3 — 100. Local preference имеет значение по умолчанию 100, и чем выше, тем лучше. Именно поэтому 3.3.3.3 предпочтительнее — у него более высокий local preference. Похоже, что путь через 2.2.2.2 изменил local preference либо когда он был анонсирован R2, либо когда он был получен R5.

💡 Пояснение к выбору пути:

Weight — одинаковый (0), проверяем следующий атрибут.

Local Preference — разный (50 vs 100). 100 > 50, поэтому путь через R3 выигрывает.

Причина: на R2 настроен route-map, который понижает local preference до 50 для маршрутов, анонсируемых R5.

Вы изучаете конфигурацию BGP на R5 с помощью команды show run | section router bgp . Как показано в Примере 5, нет указаний на то, что local preference изменяется. Если бы это было так, мы увидели бы route map, применённый к оператору neighbor для 2.2.2.2.

Пример 5. Просмотр конфигурации BGP на R5

R5#show run | section router bgp router bgp 65502 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 65502 neighbor 2.2.2.2 update-source Loopback0 neighbor 3.3.3.3 remote-as 65502 neighbor 3.3.3.3 update-source Loopback0

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

На R5 нет route-map, который изменял бы local preference.

Значит, проблема на стороне R2 — именно R2 анонсирует маршруты с пониженным local preference.

Далее вы переходите на R2 и выполняете команду show run | section router bgp . Сразу замечаете route map под названием TSHOOT_BGP_FILTER, применённый в исходящем направлении для peer group под названием TSHOOT_IBGP_NEIGHBORS, как показано в Примере 6. Вы также замечаете, что R5 входит в эту peer group. Следовательно, route map применяется к R5. Теперь вам нужно изучить route map, поэтому вы выполняете команду show route-map TSHOOT_BGP_FILTER. Как показано в Примере 7, route map устанавливает local preference в 50. Вы изучаете сетевую документацию, и в ней указано, что local preference должен быть 150.

text

Страница в разработке