Проблемный тикет BGP: неявный deny all в prefix-list

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

Проблема: Вы администратор BGP-автономной системы 65501. Пользователи в сетях 10.1.1.0/26 и 10.1.1.64/26 сообщили, что не могут получить доступ к ресурсам, расположенным по адресу 10.1.5.5. Однако они могут получить доступ к локальным ресурсам.

Вы начинаете диагностику, выполняя два ping на R1 до 10.1.5.5 с указанием источника: 10.1.1.1 и 10.1.1.65. Как показано в Примере 1, ping-запросы не проходят.

Пример 1. Проверка проблемы с помощью ping (Verifying Issue with a Ping)

R1#ping 10.1.5.5 source 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.5.5, timeout is 2 seconds: Packet sent with a source address of 10.1.1.1 ..... Success rate is 0 percent (0/5) R1#ping 10.1.5.5 source 10.1.1.65 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.5.5, timeout is 2 seconds: Packet sent with a source address of 10.1.1.65 ..... Success rate is 0 percent (0/5)

Вы подтверждаете с помощью команды show ip route 10.1.5.5 на R1, как показано в Примере 2, что маршрут к 10.1.5.5 существует через R2, изученный через BGP.

Пример 2. Подтверждение наличия маршрута к 10.1.5.5 на R1

R1#show ip route 10.1.5.5 Routing entry for 10.1.5.0/24 Known via "bgp 65501", distance 20, metric 3328 Tag 65502, type external Last update from 2.2.2.2 00:12:35 ago Routing Descriptor Blocks: * 2.2.2.2, from 2.2.2.2, 00:12:35 ago Route metric is 3328, traffic share count is 1 AS Hops 1 Route tag 65502 MPLS label: none

Вы хотите увидеть, как далеко проходят пакеты, чтобы примерно понять, где они могут теряться. Поэтому вы решаете выполнить расширенный traceroute, чтобы собрать дополнительную информацию. В Примере 3 видно, что трассировка обрывается на next-hop маршрутизаторе (R2).

Пример 3. Определение того, как далеко проходят пакеты до отказа

R1#traceroute 10.1.5.5 source 10.1.1.1 Type escape sequence to abort. Tracing the route to 10.1.5.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.12.2 40 msec 44 msec 28 msec 2 * * * 3 * * * 4 * * * ...выходные данные опущены... R1#traceroute 10.1.5.5 source 10.1.1.65 Type escape sequence to abort. Tracing the route to 10.1.5.5 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.12.2 44 msec 48 msec 36 msec 2 * * * 3 * * * 4 * * * ...выходные данные опущены...

Вы немного сбиты с толку, поэтому садитесь и обдумываете то, что знаете. Вы подтвердили, что R1 знает о 10.1.5.5 через R2. Следовательно, R1 может маршрутизировать пакеты в сторону этого адреса. Однако трассировка обрывается на R2. Возможно ли, что R2 не знает, как достичь 10.1.1.0/26 или 10.1.1.64/26, чтобы ответить на трассировку? Возможно ли, что 10.1.5.5 тоже не знает об этих сетях и не может ответить на ping? Вы решаете сосредоточиться на своих мыслях о R2. R2 должен знать о маршрутах 10.1.1.0/26 и 10.1.1.64/26, чтобы успешно ответить на трассировку. Следовательно, R1 должен анонсировать эти сети с помощью команды network mask в BGP.

На R1 вы выполняете команду show bgp ipv4 unicast , чтобы проверить, находятся ли 10.1.1.0/26 и 10.1.1.64/26 в BGP-таблице. Как показано в Примере 4, они там. Поскольку они в BGP-таблице и помечены как valid и best, они могут быть анонсированы соседям.

Пример 4. Проверка BGP-таблицы R1

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.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 ?

Вы выполняете команду show bgp ipv4 unicast summary , чтобы проверить BGP-соседей. Судя по выводу в Примере 5, вы подтверждаете, что и R2, и R3 являются BGP-соседями, потому что в колонке PfxRcd есть число.

Пример 5. Проверка BGP-соседей R1

R1#show bgp ipv4 unicast summary BGP router identifier 1.1.1.1, local AS number 65501 BGP table version is 10, main routing table version 10 9 network entries using 1296 bytes of memory 10 path entries using 800 bytes of memory 4/4 BGP path/bestpath attribute entries using 544 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 2664 total bytes of memory BGP activity 19/10 prefixes, 54/44 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 38 39 10 0 0 00:30:05 1 10.1.13.3 4 65502 7 6 10 0 0 00:02:06 1

Далее вы выполняете команды show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes и show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes, чтобы проверить, какие маршруты анонсируются на R2 и R3. Как подтверждено в Примере 6, никакие маршруты не анонсируются соседям.

Пример 6. Проверка анонсируемых маршрутов R1

R1#show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes Total number of prefixes 0 R1#show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes Total number of prefixes 0

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

«Total number of prefixes 0» означает, что R1 не отправляет ни одного маршрута соседям. При этом в BGP-таблице (Пример 4) маршруты есть и помечены как best ( *> ). Это аномалия — маршруты есть, но не анонсируются. Причина — исходящий фильтр (prefix-list), который будет найден далее.

Что может помешать маршруту, который является valid и best в BGP-таблице, быть анонсированным eBGP-соседу? Фильтр? Вы решаете проверить вывод команды show ip protocols , чтобы определить, применён ли фильтр к BGP-автономной системе. Как показано в Примере 7, фильтр не применён.

Пример 7. Проверка наличия BGP-фильтров на R1

R1# show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "bgp 65501" 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 Redistributing: connected Unicast Aggregate Generation: 10.1.1.0/24 Neighbor(s): Address FiltIn FiltOut DistIn DistOut Weight RouteMap 2.2.2.2 10.1.13.3 Maximum path: 1 Routing Information Sources: Gateway Distance Last Update 2.2.2.2 20 00:37:02 10.1.13.3 20 21:12:13 Distance: external 20 internal 200 local 200

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

show ip protocols показывает только distribute-list и filter-list. Он не показывает prefix-list, применённый к соседу. Это важный нюанс: если вы проверяете только эту команду, вы не увидите проблему.

Чтобы найти prefix-list, нужно использовать show bgp ipv4 unicast neighbors | include prefix (см. Пример 8) или show run | section router bgp (см. Пример 9).

Но подождите — вы помните из своих исследований TSHOOT, что prefix-list фильтр не отображается в выводе show ip protocols . Он отображается только в выводе BGP-соседей. Поэтому вы выполняете команду show bgp ipv4 unicast neighbors | i prefix , чтобы увидеть, применён ли вообще какой-либо prefix-list. В выводе Примера 8 вы можете видеть один и тот же prefix-list под названием BGP_FILTER, применённый дважды в исходящем направлении.

Пример 8. Проверка наличия prefix-list фильтров на R1

R1#show bgp ipv4 unicast neighbors | i prefix Outgoing update prefix filter list is BGP_FILTER prefix-list 27 0 Outgoing update prefix filter list is BGP_FILTER prefix-list 27 0

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

Команда show bgp ipv4 unicast neighbors | i prefix показывает все строки, содержащие слово prefix . В выводе видно, что prefix-list BGP_FILTER применён к двум соседям (R2 и R3) в направлении out.

Строка prefix-list 27 0 — это счётчик (27 — количество проверок, 0 — количество совпадений). Это не ошибка.

Теперь вы чувствуете, что на правильном пути. Поэтому вы выполняете команду show run | section router bgp , как показано в Примере 9, чтобы изучить конфигурацию BGP на R1 и найти виновника. Вы сразу замечаете, что prefix-list BGP_FILTER применён к соседям 2.2.2.2 и 10.1.13.3 в исходящем направлении.

Пример 9. Проверка конфигурации BGP на R1

R1#show run | section router bgp router bgp 65501 bgp log-neighbor-changes network 10.1.1.0 mask 255.255.255.192 network 10.1.1.64 mask 255.255.255.192 network 10.1.1.128 mask 255.255.255.192 network 10.1.1.192 mask 255.255.255.192 aggregate-address 10.1.1.0 255.255.255.0 redistribute connected neighbor 2.2.2.2 remote-as 65502 neighbor 2.2.2.2 password CISCO neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2 prefix-list BGP_FILTER out neighbor 10.1.13.3 remote-as 65502 neighbor 10.1.13.3 prefix-list BGP_FILTER out

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

neighbor 2.2.2.2 prefix-list BGP_FILTER out — это исходящий фильтр для R2.

neighbor 10.1.13.3 prefix-list BGP_FILTER out — это исходящий фильтр для R3.

Именно этот фильтр блокирует анонс маршрутов 10.1.1.0/26 и 10.1.1.64/26.

Теперь вы хотите изучить prefix-list, поэтому выполняете команду show ip prefix-list BGP_FILTER, как показано в Примере 10. Вы сразу замечаете, что 10.1.1.128/26 и 10.1.1.192/26 запрещены (deny). Следовательно, они не анонсируются на R2 или R3. Вы проверяете свою документацию, и в ней указано, что 10.1.1.128/26 и 10.1.1.192/26 не должны анонсироваться в BGP-автономную систему 65502 — и этот prefix-list выполняет эту задачу.

Пример 10. Проверка prefix-list на R1

R1#show ip prefix-list BGP_FILTER ip prefix-list BGP_FILTER: 2 entries seq 5 deny 10.1.1.128/26 seq 10 deny 10.1.1.192/26

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

В prefix-list две записи: deny 10.1.1.128/26 и deny 10.1.1.192/26 .

Проблема: в конце prefix-list действует неявный запрет (implicit deny all). Это означает, что все остальные маршруты (включая 10.1.1.0/26 и 10.1.1.64/26 ) тоже блокируются.

Решение: добавить явное разрешение для всех остальных маршрутов.

Вы обдумываете эту проблему немного больше, и тут вас осеняет. Неявный запрет (implicit deny all) в конце prefix-list блокирует все остальные маршруты. Вы предлагаете добавить запись ip prefix-list BGP_FILTER permit 0.0.0.0/0 le 32 , как показано в Примере 11, на R1, что разрешит все остальные маршруты — в данном случае 10.1.1.0/26 и 10.1.1.64/26. Команда show ip prefix-list BGP_FILTER подтверждает, что запись добавлена.

Пример 11. Изменение prefix-list на R1

R1#config t Enter configuration commands, one per line. End with CNTL/Z. R1(config)# ip prefix-list BGP_FILTER permit 0.0.0.0/0 le 32 R1(config)# end %SYS-5-CONFIG_I: Configured from console by console R1#show ip prefix-list BGP_FILTER ip prefix-list BGP_FILTER: 3 entries seq 5 deny 10.1.1.128/26 seq 10 deny 10.1.1.192/26 seq 15 permit 0.0.0.0/0 le 32

Чтобы принудительно обновить BGP-информацию, отправляемую соседям R1, вы выполняете команду clear bgp ipv4 unicast * soft out . Затем вы выполняете команды show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes и show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes , чтобы подтвердить, что маршруты теперь анонсируются соседям R1. Вывод Примера 12 подтверждает, что 10.1.1.0/26 и 10.1.1.64/26 теперь анонсируются.

Пример 12. Проверка маршрутов, анонсируемых соседям R1

R1#show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes BGP table version is 10, local router ID is 1.1.1.1 ...выходные данные опущены... 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.64/26 0.0.0.0 0 32768 i ...выходные данные опущены... R1# show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes BGP table version is 10, local router ID is 1.1.1.1 ...выходные данные опущены... 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.64/26 0.0.0.0 0 32768 i ...выходные данные опущены...

Однако вы всё ещё хотите подтвердить, что проблема решена. Могут ли пользователи в сетях 10.1.1.0/26 и 10.1.1.64/26 достичь 10.1.5.5? Чтобы подтвердить, что проблема решена, вы снова выполняете ping 10.1.5.5 с 10.1.1.1 и 10.1.1.65. Как показано в Примере 13, проблема решена.

Заголовок H2

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

text

ПРИМЕЧАНИЕ

Термины "порт коммутатора" и "интерфейс коммутатора" являются синонимами.

Параметр	Описание
Text	Text
Text	Text

Рис. 1.

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