Маршрут есть, но next-hop недостижим
В таблице маршрутизации префикс выглядит корректно: выбран best-path, указан next-hop, метрики нормальные.
Но трафик не проходит, потому что маршрут до самого next-hop не резолвится. Такое часто происходит в сетях с BGP и IGP, где next-hop объявляется через один протокол, а достижимость обеспечивается другим.
Сначала смотрят, какой next-hop используется для префикса:
Затем проверяют, есть ли реальный маршрут до этого next-hop:
Даже если маршрут присутствует, важно убедиться, что он запрограммирован в data-plane:
Если next-hop не может быть разрешён через ARP или adjacency, forwarding не происходит. Это можно увидеть через:
N.A.
В таблице маршрутизации префикс выглядит корректно: выбран best-path, указан next-hop, метрики нормальные.
Но трафик не проходит, потому что маршрут до самого next-hop не резолвится. Такое часто происходит в сетях с BGP и IGP, где next-hop объявляется через один протокол, а достижимость обеспечивается другим.
Сначала смотрят, какой next-hop используется для префикса:
show ip bgp <prefix>
Затем проверяют, есть ли реальный маршрут до этого next-hop:
show ip route <next-hop>
Даже если маршрут присутствует, важно убедиться, что он запрограммирован в data-plane:
show ip cef <prefix> detail
Если next-hop не может быть разрешён через ARP или adjacency, forwarding не происходит. Это можно увидеть через:
show adjacency detail
N.A.
👍9❤1
ECMP: почему трафик «неравномерно» распределяется по линкам
Даже когда таблица маршрутизации показывает несколько next-hop для префикса, data-plane может отдавать большинство потоков через один линк.
Если сессий мало или все они попадают в один bucket, трафик концентрируется на одном пути. Асимметричные маршруты и аппаратные ограничения ASIC по количеству ECMP-бакетов усиливают эффект.
Для диагностики сначала смотрим, какие next-hop выбраны и как они запрограммированы в CEF:
Далее проверяем, как трафик реально распределяется по линкам:
На некоторых платформах полезно посмотреть ECMP hash table:
N.A.
Даже когда таблица маршрутизации показывает несколько next-hop для префикса, data-plane может отдавать большинство потоков через один линк.
Причина не в маршрутах, а в том, как работает hashing для ECMP: большинство платформ используют 5-tuple hash (src/dst IP, src/dst port, protocol).
Если сессий мало или все они попадают в один bucket, трафик концентрируется на одном пути. Асимметричные маршруты и аппаратные ограничения ASIC по количеству ECMP-бакетов усиливают эффект.
Для диагностики сначала смотрим, какие next-hop выбраны и как они запрограммированы в CEF:
show ip route <prefix> detail
show ip cef <prefix> detail
Далее проверяем, как трафик реально распределяется по линкам:
show interface <interface> counters
show interface <interface> statistics
На некоторых платформах полезно посмотреть ECMP hash table:
show platform hardware forwarding ecmp table
N.A.
👍9❤2
Silent packet drops на L3
В routing table маршрут есть, интерфейсы подняты, ping проходит, но часть трафика теряется или «тает» в пути.
Проблема кроется не в маршрутах, а в data-plane: ACL, CEF adjacency, рекурсивное разрешение next-hop или MTU mismatch. Даже когда control-plane полностью сходится, пакеты могут тихо дропаться на уровне forwarding.
Для диагностики сначала проверяем, как маршрут запрограммирован в CEF:
Если next-hop не резолвится через ARP или adjacency, пакеты не будут пересылаться:
Проверяем, нет ли ACL, которые silently дропают трафик:
И для MTU mismatch используем Path MTU тест:
N.A.
В routing table маршрут есть, интерфейсы подняты, ping проходит, но часть трафика теряется или «тает» в пути.
Проблема кроется не в маршрутах, а в data-plane: ACL, CEF adjacency, рекурсивное разрешение next-hop или MTU mismatch. Даже когда control-plane полностью сходится, пакеты могут тихо дропаться на уровне forwarding.
Для диагностики сначала проверяем, как маршрут запрограммирован в CEF:
show ip cef <prefix> detail
Если next-hop не резолвится через ARP или adjacency, пакеты не будут пересылаться:
show adjacency detail
show ip arp <next-hop>
Проверяем, нет ли ACL, которые silently дропают трафик:
show access-lists
И для MTU mismatch используем Path MTU тест:
ping <destination> size 1500 df-bit
N.A.
👍4
DNS работает, но приложения не резолвят хосты
Дело часто не в самом DNS, а в сети между клиентом и сервером: ACL блокирует UDP/53 или TCP/53, NAT ломает исходящие сессии, неправильно настроен DHCP/DNS relay, работает split-horizon DNS, или же асимметричные маршруты приводят к падению stateful соединений.
Для диагностики сначала проверяем, что сервер реально резолвит имена:
Далее проверяем путь трафика и возможные ограничения ACL:
Если используется relay, важно убедиться, что клиент видит правильный DNS:
Для asymmetric routing проверяем путь туда и обратно:
N.A.
Ping до IP проходит, DNS-сервер отвечает на запросы, но приложения (HTTP, LDAP, почта) не могут резолвить имена.
Дело часто не в самом DNS, а в сети между клиентом и сервером: ACL блокирует UDP/53 или TCP/53, NAT ломает исходящие сессии, неправильно настроен DHCP/DNS relay, работает split-horizon DNS, или же асимметричные маршруты приводят к падению stateful соединений.
Для диагностики сначала проверяем, что сервер реально резолвит имена:
nslookup example.com <dns-server>
dig example.com @<dns-server>
Далее проверяем путь трафика и возможные ограничения ACL:
show access-lists
show ip nat translations
show ip route <client-ip>
Если используется relay, важно убедиться, что клиент видит правильный DNS:
show ip helper-address
Для asymmetric routing проверяем путь туда и обратно:
traceroute <dns-server>
traceroute <client-ip> <router>
N.A.
👍7
LACP bundle под нагрузкой ведёт себя криво
Несмотря на то что LACP показывает все линки поднятыми, часть трафика может «схлопываться» на один или два интерфейса, особенно под высокой нагрузкой.
Asymmetric paths и аппаратные ограничения ASIC (количество ECMP/aggregation-бакетов) усиливают проблему.
Для диагностики сначала проверяем состояние bundle:
Затем оцениваем распределение трафика по линкам:
На некоторых платформах можно посмотреть hash-table напрямую:
N.A.
Несмотря на то что LACP показывает все линки поднятыми, часть трафика может «схлопываться» на один или два интерфейса, особенно под высокой нагрузкой.
Причины в том, как работает hashing по 5-tuple (src/dst IP, src/dst port, protocol): если потоков мало, почти все попадают в один bucket.
Asymmetric paths и аппаратные ограничения ASIC (количество ECMP/aggregation-бакетов) усиливают проблему.
Для диагностики сначала проверяем состояние bundle:
show etherchannel summary
show lacp neighbor
Затем оцениваем распределение трафика по линкам:
show interface <port-channel> counters
show interface <member-interface> statistics
На некоторых платформах можно посмотреть hash-table напрямую:
show platform hardware forwarding hash <port-channel>
N.A.
👍4❤1
Как проверить, что BGP-маршрут анонсируется, но не используется
Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём.
Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB.
1️⃣ Проверяем, что маршрут вообще пришёл по BGP
Сначала убеждаемся, что апстрим реально его отдал.
Cisco:
Важно смотреть:
• есть ли несколько путей
• какой помечен как *> (best)
Если маршрута нет, дальше можно не копать.
2️⃣ Сравниваем BGP vs routing table
Маршрут может быть в BGP, но не установлен в основную таблицу.
Если вместо BGP стоит: static, OSPF или connected, то BGP просто проиграл по административной дистанции.
Смотрим атрибуты best path
Часто маршрут есть, но проигрывает по атрибутам.
Обращаем внимание на:
⏺ Local Preference (самая частая причина)
⏺ AS_PATH (длиннее — хуже)
⏺ MED
⏺ Weight (Cisco)
Даже разница в LocalPref 100 vs 200 полностью меняет путь.
4️⃣ Проверяем policy: route-map / filter
Маршрут может быть принят, но «искажён» политикой.
Иногда route-map не режет маршрут, но меняет LocalPref или MED.
5️⃣ Проверяем CEF / FIB
Бывает, BGP и RIB ок, а в forwarding таблице другое.
Если next-hop не тот, что ожидается — проблема на этапе установки в FIB.
N.A.
Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём.
Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB.
Сначала убеждаемся, что апстрим реально его отдал.
Cisco:
show ip bgp <prefix>
Важно смотреть:
• есть ли несколько путей
• какой помечен как *> (best)
Если маршрута нет, дальше можно не копать.
Маршрут может быть в BGP, но не установлен в основную таблицу.
show ip route <prefix>
Если вместо BGP стоит: static, OSPF или connected, то BGP просто проиграл по административной дистанции.
Смотрим атрибуты best path
Часто маршрут есть, но проигрывает по атрибутам.
show ip bgp <prefix>
Обращаем внимание на:
Даже разница в LocalPref 100 vs 200 полностью меняет путь.
Маршрут может быть принят, но «искажён» политикой.
show run | section route-map
show ip bgp neighbors <IP> received-routes
Иногда route-map не режет маршрут, но меняет LocalPref или MED.
Бывает, BGP и RIB ок, а в forwarding таблице другое.
show ip cef <prefix>
Если next-hop не тот, что ожидается — проблема на этапе установки в FIB.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3
RIB vs FIB divergence в high-end роутерах
В routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится.
Причины чаще всего связаны с ограничениями ASIC, рекурсивным разрешением next-hop или проблемами с adjacency.
Для диагностики сначала проверяем, как маршрут запрограммирован в FIB/CEF:
Если next-hop не разрешается через adjacency, пакеты не будут пересылаться:
На high-end платформах полезно проверить hardware table и возможные дропы:
Решение обычно включает корректировку рекурсивного next-hop, перераспределение нагрузки по ASIC, а иногда - оптимизацию L3 adjacency и проверку максимального количества маршрутов/entry в FIB для high-end маршрутизаторов.
N.A.
В routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится.
Но data-plane не использует этот маршрут - пакеты не уходят, и кажется, что сеть «работает частично».
Причины чаще всего связаны с ограничениями ASIC, рекурсивным разрешением next-hop или проблемами с adjacency.
Для диагностики сначала проверяем, как маршрут запрограммирован в FIB/CEF:
show ip cef <prefix> detail
Если next-hop не разрешается через adjacency, пакеты не будут пересылаться:
show adjacency detail
show ip arp <next-hop>
На high-end платформах полезно проверить hardware table и возможные дропы:
show platform hardware qfp active feature cef drop
Решение обычно включает корректировку рекурсивного next-hop, перераспределение нагрузки по ASIC, а иногда - оптимизацию L3 adjacency и проверку максимального количества маршрутов/entry в FIB для high-end маршрутизаторов.
N.A.
👍5
CoS/DSCP конфликт в мульти-tenant сети
В сети несколько VLAN и overlay, QoS вроде настроен, но голосовой или видео-трафик начинает тормозить.
На L2 пакеты помечены CoS, на L3 - DSCP, и на trunk или VTEP эти метки могут не совпадать. В итоге latency-sensitive трафик попадает в обычный queue, и jitter растёт.
Смотрим, как метки проходят через интерфейсы:
На роутерах проверяем, что DSCP не теряется:
Для overlay VTEP важно, чтобы CoS правильно транслировался в DSCP:
Когда видишь, что голосовой трафик попадает в «обычный» queue, а не в priority, обычно проблема именно в несовпадении CoS ↔ DSCP на пути через trunk и overlay.
N.A.
В сети несколько VLAN и overlay, QoS вроде настроен, но голосовой или видео-трафик начинает тормозить.
На L2 пакеты помечены CoS, на L3 - DSCP, и на trunk или VTEP эти метки могут не совпадать. В итоге latency-sensitive трафик попадает в обычный queue, и jitter растёт.
Смотрим, как метки проходят через интерфейсы:
show mls qos interface <interface> statistics
show policy-map interface <interface>
На роутерах проверяем, что DSCP не теряется:
show class-map
show policy-map
show interface <interface> | include DSCP
Для overlay VTEP важно, чтобы CoS правильно транслировался в DSCP:
show nve vni
show nve peers
Когда видишь, что голосовой трафик попадает в «обычный» queue, а не в priority, обычно проблема именно в несовпадении CoS ↔ DSCP на пути через trunk и overlay.
N.A.
👍5
SNMP polling начинает «тормозить» сеть
Маршрутизатор вроде работает, интерфейсы up, маршруты в таблице, но приложения жалуются на задержки или потерю пакетов.
Часто виноват частый SNMP polling: когда CPU под нагрузкой, device тратит ресурсы на обработку запросов, и forwarding пакетов начинает падать.
Сначала проверяем, сколько SNMP-запросов обрабатывается:
Далее можно увидеть spikes и drops в data-plane:
Если на high-end маршрутизаторах наблюдаются microbursts в CPU, пакеты тихо дропаются, а latency-sensitive трафик (VoIP, video) начинает тормозить.
⏺ Признак проблемы: ping стабильный, но потоковый TCP/UDP трафик теряет пакеты, и это коррелирует с периодом SNMP polling.
N.A.
Маршрутизатор вроде работает, интерфейсы up, маршруты в таблице, но приложения жалуются на задержки или потерю пакетов.
Часто виноват частый SNMP polling: когда CPU под нагрузкой, device тратит ресурсы на обработку запросов, и forwarding пакетов начинает падать.
Сначала проверяем, сколько SNMP-запросов обрабатывается:
show processes cpu sorted
show snmp group
Далее можно увидеть spikes и drops в data-plane:
show interfaces counters errors
show platform hardware qfp active statistics drop
Если на high-end маршрутизаторах наблюдаются microbursts в CPU, пакеты тихо дропаются, а latency-sensitive трафик (VoIP, video) начинает тормозить.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
BFD flaps при высокой jitter
BGP и OSPF соседства держатся, но BFD периодически фиксирует «link down», и маршрутизатор мгновенно перестраивает путь.
Пакеты могут уходить через резервные линии на доли секунд, создавая micro-convergence.
Состояние BFD смотрим так:
Для анализа задержек и потерь:
На высоконагруженных линках короткие spikes создают колебания heartbeat, что проявляется именно как BFD flap, хотя маршруты в control-plane остаются стабильными.
N.A.
BGP и OSPF соседства держатся, но BFD периодически фиксирует «link down», и маршрутизатор мгновенно перестраивает путь.
Пакеты могут уходить через резервные линии на доли секунд, создавая micro-convergence.
Состояние BFD смотрим так:
show bfd neighbors
show bfd sessions
Для анализа задержек и потерь:
ping <neighbor-ip> repeat 100 size 100 df-bit
show interfaces <interface> counters
На высоконагруженных линках короткие spikes создают колебания heartbeat, что проявляется именно как BFD flap, хотя маршруты в control-plane остаются стабильными.
N.A.
👍5
ECMP и hash buckets: почему трафик концентрируется на одном линке
Вроде несколько uplink и ECMP включён, но весь трафик «съезжает» на один порт.
Если потоков мало или они одинаковы по этим полям, почти всё попадает в один bucket.
⏺ На high-end роутерах есть ограничения ASIC - максимальное число hash-bucket’ов, которые реально могут распределять трафик. Даже при большом количестве линков маленькие TCP/UDP потоки часто концентрируются на одном порту.
Проверка распределения трафика:
На некоторых платформах можно посмотреть hash-бакеты напрямую:
⏺ Признак проблемы: линк full-duplex не загружен по среднему, но один порт получает почти весь трафик, а остальные почти пустые.
С небольшой коррекцией hash или увеличением числа параллельных потоков трафик начинает распределяться равномернее.
N.A.
Вроде несколько uplink и ECMP включён, но весь трафик «съезжает» на один порт.
Причина в том, как работает hashing: большинство платформ используют 5-tuple (src/dst IP, src/dst port, protocol) для распределения потоков по линкам.
Если потоков мало или они одинаковы по этим полям, почти всё попадает в один bucket.
Проверка распределения трафика:
show etherchannel load-balance
show interface <port-channel> counters
show interface <member-interface> statistics
На некоторых платформах можно посмотреть hash-бакеты напрямую:
show platform hardware forwarding hash <port-channel>
С небольшой коррекцией hash или увеличением числа параллельных потоков трафик начинает распределяться равномернее.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
🧬 Вебинар: эволюция DDoS-защиты в 2026–2027
Атак стало больше в 2 раза, сценарии усложнились. Всё чаще они маскируются под легитимный трафик, из-за чего классические методы защиты теряют эффективность.
Приглашаем на вебинар, где разберем:
– Трансформацию DDoS и что нас ждет в будущем
– Почему классические методы защиты уже перестают работать
– На какие метрики важно обращать внимание
– Что должна уметь современная система защиты
Актуально для ИТ- и ИБ-руководителей, сетевых инженеров и специалистов по защите IT-инфраструктуры.
Зарегистрироваться бесплатно ✅
Атак стало больше в 2 раза, сценарии усложнились. Всё чаще они маскируются под легитимный трафик, из-за чего классические методы защиты теряют эффективность.
Приглашаем на вебинар, где разберем:
– Трансформацию DDoS и что нас ждет в будущем
– Почему классические методы защиты уже перестают работать
– На какие метрики важно обращать внимание
– Что должна уметь современная система защиты
Актуально для ИТ- и ИБ-руководителей, сетевых инженеров и специалистов по защите IT-инфраструктуры.
Зарегистрироваться бесплатно ✅
👍2👀1
5 команд, которые реально спасают на high-end сетях
Ситуация: маршруты есть, линк up, ping работает, но TCP/UDP падает, jitter/packet loss наблюдается. Эти команды быстро выявляют глубокие проблемы:
1️⃣ RIB vs FIB divergence - маршрут есть в control-plane, но не запрограммирован в forwarding:
2️⃣ ECMP hash distribution - почему traffic концентрируется на одном uplink:
3️⃣ BFD session flaps - link вроде жив, но маршруты конвергируют мгновенно:
4️⃣ Overlay/VTEP sanity check - VXLAN/EVPN мультикаст и BUM-трафик:
5️⃣ CPU spikes под SNMP/NetFlow - microbursts silently дропят пакеты:
N.A.
Ситуация: маршруты есть, линк up, ping работает, но TCP/UDP падает, jitter/packet loss наблюдается. Эти команды быстро выявляют глубокие проблемы:
show ip route <prefix>
show platform hardware forwarding table drop
show platform hardware forwarding hash <port-channel>
show etherchannel load-balance
show bfd neighbors
show bfd sessions
show nve vni
show nve peers
show ip mroute
show processes cpu sorted
show platform hardware qfp active statistics drop
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM