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

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

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

В этом тикете: весь трафик из автономной системы 65502 идёт через R3 по резервному линку, хотя должен идти через R2. Причина — неверный local preference (50 вместо 150) в route-map TSHOOT_BGP_FILTER на R2.

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

Проблема: Вы сетевой администратор 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.1 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.1 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.

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

R2#show run | section router bgp router bgp 65502 bgp log-neighbor-changes network 10.1.5.0 mask 255.255.255.0 neighbor TSHOOT_IBGP_NEIGHBORS peer-group neighbor TSHOOT_IBGP_NEIGHBORS transport connection-mode passive neighbor TSHOOT_IBGP_NEIGHBORS update-source Loopback0 neighbor TSHOOT_IBGP_NEIGHBORS next-hop-self neighbor TSHOOT_IBGP_NEIGHBORS route-map TSHOOT_BGP_FILTER out neighbor 1.1.1.1 remote-as 65501 neighbor 1.1.1.1 password CISCO neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 65502 neighbor 3.3.3.3 peer-group TSHOOT_IBGP_NEIGHBORS neighbor 4.4.4.4 remote-as 65502 neighbor 4.4.4.4 peer-group TSHOOT_IBGP_NEIGHBORS neighbor 5.5.5.5 remote-as 65502 neighbor 5.5.5.5 peer-group TSHOOT_IBGP_NEIGHBORS

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

neighbor TSHOOT_IBGP_NEIGHBORS route-map TSHOOT_BGP_FILTER out — route map применён к peer group в направлении out.

neighbor 5.5.5.5 peer-group TSHOOT_IBGP_NEIGHBORS — R5 входит в эту peer group.

Следовательно, route map применяется ко всем маршрутам, анонсируемым R5.

Пример 7. Просмотр route map на R2

R2#show route-map TSHOOT_BGP_FILTER route-map TSHOOT_BGP_FILTER, permit, sequence 10 Match clauses: Set clauses: local-preference 50 Policy routing matches: 0 packets, 0 bytes

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

set local-preference 50 — route map понижает local preference до 50.

Проблема: согласно документации, local preference должен быть 150.

Следствие: маршруты, анонсируемые R2, имеют local preference = 50, а маршруты от R3 — 100. Поэтому R5 выбирает R3.

Вы изменяете route map на R2, как показано в Примере 8, чтобы решить проблему. Вы подтверждаете, что изменения применены, с помощью команды show route-map TSHOOT_BGP_FILTER. Local preference был успешно изменён на 150. Чтобы ускорить изменения BGP, вы выполняете команду clear bgp ipv4 unicast * soft out.

Пример 8. Изменение значения local preference в route map

R2#config t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#route-map TSHOOT_BGP_FILTER 10 R2(config-route-map)#set local-preference 150 R2(config-route-map)#end %SYS-5-CONFIG_I: Configured from console by console R2#show route-map TSHOOT_BGP_FILTER route-map TSHOOT_BGP_FILTER, permit, sequence 10 Match clauses: Set clauses: local-preference 150 Policy routing matches: 0 packets, 0 bytes

Вы возвращаетесь на R5 и выполняете трассировку и подтверждаете, что путь через R2 теперь используется, как показано в Примере 9.

Пример 9. Подтверждение того, что проблема решена

R5#traceroute 10.1.1.1 source 10.1.5.1 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 28 msec 44 msec 8 msec 2 10.1.24.2 40 msec 40 msec 40 msec 3 10.1.12.1 [AS 65501] 64 msec 56 msec 100 msec R5#traceroute 10.1.1.65 source 10.1.5.1 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 28 msec 44 msec 24 msec 2 10.1.24.2 32 msec 56 msec 48 msec 3 10.1.12.1 [AS 65501] 68 msec 36 msec 56 msec

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

Второй прыжок теперь 10.1.24.2 — это R2 (а не R3, как было раньше).

Третий прыжок 10.1.12.1 — это R1.

Вывод: трафик теперь идёт через R4 → R2 → R1 (основной путь), а не через R4 → R3 → R1 (резервный).