Почему маршруты OSPF есть, но трафик не идёт
В routing table маршруты видны, интерфейсы up, соседи установлены - а пакеты не проходят.
Чаще всего проблема не в маршрутах, а в деталях OSPF: несоответствие cost, passive interface, ошибка аутентификации, или интерфейс находится в другом VRF, и трафик смотрит в другую таблицу.
Для проверки сначала смотрим соседей и их статус:
Далее проверяем cost и тип интерфейса:
Если используется аутентификация, убедимся, что ключи совпадают:
Для VRF важно проверить, что маршрут существует в нужной таблице:
N.A.
В routing table маршруты видны, интерфейсы up, соседи установлены - а пакеты не проходят.
Чаще всего проблема не в маршрутах, а в деталях OSPF: несоответствие cost, passive interface, ошибка аутентификации, или интерфейс находится в другом VRF, и трафик смотрит в другую таблицу.
Для проверки сначала смотрим соседей и их статус:
show ip ospf neighbor
Далее проверяем cost и тип интерфейса:
show ip ospf interface
show running-config interface Gi0/1
Если используется аутентификация, убедимся, что ключи совпадают:
show ip ospf interface | include Authentication
Для VRF важно проверить, что маршрут существует в нужной таблице:
show ip route vrf <name>
N.A.
🔥6❤2👍2
SSL/TLS соединения падают при смене времени
Когда часы на сервере или клиенте идут неправильно, соединения начинают обрываться. Проблема обычно связана с выключенным или некорректным NTP, истёкшими сертификатами и сбоями handshake.
Даже если IP доступен и маршруты корректны, TLS проверяет корректность времени для сертификатов и сессий, поэтому любые расхождения приводят к падению соединения.
Проверка и диагностика:
Для исправления нужно синхронизировать время через NTP и убедиться, что сертификаты действительны. Иногда достаточно пересоздать TLS-сессию после корректной синхронизации времени.
N.A.
Когда часы на сервере или клиенте идут неправильно, соединения начинают обрываться. Проблема обычно связана с выключенным или некорректным NTP, истёкшими сертификатами и сбоями handshake.
Даже если IP доступен и маршруты корректны, TLS проверяет корректность времени для сертификатов и сессий, поэтому любые расхождения приводят к падению соединения.
Проверка и диагностика:
show ntp status
show clock
show crypto pki certificates
Для исправления нужно синхронизировать время через NTP и убедиться, что сертификаты действительны. Иногда достаточно пересоздать TLS-сессию после корректной синхронизации времени.
N.A.
👍7
Как вычислить сломанный FIB/CEF на магистрали
В реальности сбоит CEF/FIB, когда ASIC-программирование нарушено, есть баг платформы, переполнение adjacency, или MPLS label stack формируется неправильно.
CEF ломается тихо: маршруты в RIB корректны, но forwarding - нет.
На что смотреть: корректность adjacency, наличие glean-энтри, переполнение таблиц, несовпадение RIB/FIB, MPLS labels и программирование hardware-ASIC.
Проверяем конкретный префикс в FIB:
Признаки проблемы: incomplete, glean, unexpected next-hop, adjacency punted в CPU.
Проверяем, как выглядит hardware FIB:
Если entry отсутствует или отличается от CEF - ошибка ASIC программирования.
Проверяем MPLS label stack:
Неверный out-label или отсутствие LFIB записи приводит к silent-drop.
Проверяем consistency между RIB/CEF/FIB:
Если есть mismatch - проблема не в маршрутах, а в forwarding plane.
N.A.
Сложные сетевые проблемы часто выглядят как «плавающие» потери или нестабильный RTT, хотя маршрутизация на уровне RIB выглядит идеально.
В реальности сбоит CEF/FIB, когда ASIC-программирование нарушено, есть баг платформы, переполнение adjacency, или MPLS label stack формируется неправильно.
CEF ломается тихо: маршруты в RIB корректны, но forwarding - нет.
На что смотреть: корректность adjacency, наличие glean-энтри, переполнение таблиц, несовпадение RIB/FIB, MPLS labels и программирование hardware-ASIC.
Проверяем конкретный префикс в FIB:
show ip cef 10.20.50.1 detail
Признаки проблемы: incomplete, glean, unexpected next-hop, adjacency punted в CPU.
Проверяем, как выглядит hardware FIB:
show platform hardware qfp active forwarding ip route
Если entry отсутствует или отличается от CEF - ошибка ASIC программирования.
Проверяем MPLS label stack:
show mpls forwarding-table 10.20.50.1
Неверный out-label или отсутствие LFIB записи приводит к silent-drop.
Проверяем consistency между RIB/CEF/FIB:
show tech cef consistency
Если есть mismatch - проблема не в маршрутах, а в forwarding plane.
N.A.
👍6
BGP сосед есть, но маршруты не проходят
Сессия установлена, состояние Established, keepalive идут, но нужных префиксов в таблице нет. Такое часто происходит, когда маршруты режутся политиками или не могут установиться из-за next-hop.
Одна из первых вещей - проверить, приходят ли маршруты от соседа вообще. Это видно через
⏺ Если маршруты приходят, но не устанавливаются в таблицу, стоит посмотреть общий BGP статус:
⏺ Частая причина - prefix-list или route-map, которые фильтруют префиксы. Проверяется через
⏺ Иногда маршрут есть, но next-hop недостижим, поэтому он не попадает в RIB. Проверка обычной таблицы маршрутов помогает быстро это увидеть:
⏺ В сетях с route-reflector также бывает, что политика отражения не разрешает распространение маршрута. Тогда полезно посмотреть детали соседа:
N.A.
Сессия установлена, состояние Established, keepalive идут, но нужных префиксов в таблице нет. Такое часто происходит, когда маршруты режутся политиками или не могут установиться из-за next-hop.
Одна из первых вещей - проверить, приходят ли маршруты от соседа вообще. Это видно через
show ip bgp neighbors <ip> received-routes
show ip bgp
show running-config | section route-map
show ip route
show ip bgp neighbors <ip>
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2
Маршрут есть в RIB, но не участвует в forwarding
В таблице маршрутизации префикс присутствует, next-hop указан, метрики корректны, однако трафик всё равно не достигает назначения. В таких ситуациях проблема обычно находится между control-plane (RIB) и data-plane (CEF/FIB).
Сначала имеет смысл проверить, установлен ли маршрут в CEF - именно он используется для реальной пересылки пакетов:
Если next-hop не резолвится, CEF создаёт incomplete adjacency, и пакеты фактически не отправляются. Детали резолвинга можно увидеть через:
Часто причина кроется в L2-части — например, next-hop не находится через ARP. Это быстро проверяется:
Если ARP есть, но forwarding всё равно не происходит, стоит проверить, не дропаются ли пакеты аппаратным forwarding-движком:
N.A.
В таблице маршрутизации префикс присутствует, next-hop указан, метрики корректны, однако трафик всё равно не достигает назначения. В таких ситуациях проблема обычно находится между control-plane (RIB) и data-plane (CEF/FIB).
Сначала имеет смысл проверить, установлен ли маршрут в CEF - именно он используется для реальной пересылки пакетов:
show ip cef <prefix> detail
Если next-hop не резолвится, CEF создаёт incomplete adjacency, и пакеты фактически не отправляются. Детали резолвинга можно увидеть через:
show adjacency detail
Часто причина кроется в L2-части — например, next-hop не находится через ARP. Это быстро проверяется:
show ip arp <next-hop>
Если ARP есть, но forwarding всё равно не происходит, стоит проверить, не дропаются ли пакеты аппаратным forwarding-движком:
show platform hardware qfp active feature cef drop
N.A.
👍5
Несогласованность control-plane и data-plane в MPLS
В MPLS-сетях возможно состояние, при котором IGP и BGP полностью сходятся, префиксы присутствуют в таблицах маршрутизации, но трафик не доходит до назначения. На практике это связано с тем, что label forwarding в data-plane не соответствует control-plane информации.
Маршрут может быть установлен в RIB и даже выбран как best-path в BGP, но если LDP или RSVP не запрограммировали соответствующую метку в LFIB, пакет не сможет пройти дальше по LSP.
Проверка MPLS forwarding для конкретного префикса:
Иногда маршрут есть в IGP, но не привязан к label. Это можно увидеть через:
Также важно проверить состояние LDP-соседей:
И соответствие IGP и label distribution:
Если control-plane сошёлся, но forwarding не работает, стоит проверить программирование FIB/label entries:
N.A.
В MPLS-сетях возможно состояние, при котором IGP и BGP полностью сходятся, префиксы присутствуют в таблицах маршрутизации, но трафик не доходит до назначения. На практике это связано с тем, что label forwarding в data-plane не соответствует control-plane информации.
Маршрут может быть установлен в RIB и даже выбран как best-path в BGP, но если LDP или RSVP не запрограммировали соответствующую метку в LFIB, пакет не сможет пройти дальше по LSP.
Проверка MPLS forwarding для конкретного префикса:
show mpls forwarding-table <prefix>
Иногда маршрут есть в IGP, но не привязан к label. Это можно увидеть через:
show mpls ldp bindings
Также важно проверить состояние LDP-соседей:
show mpls ldp neighbor
И соответствие IGP и label distribution:
show mpls ldp igp sync
Если control-plane сошёлся, но forwarding не работает, стоит проверить программирование FIB/label entries:
show platform hardware qfp active feature mpls
N.A.
👍9
Маршрут есть, но 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
👍1