5 команд для анализа L3 ECMP и распределения трафика
Даже когда ECMP настроен, трафик может концентрироваться на одном линке из-за hash-функций.
Эти команды помогут понять, как маршрутизатор реально распределяет потоки и почему часть линков простаивает.
Показывает, какие next-hop задействованы и порядок выбора.
CEF detail: next-hop, adjacency и hash, какие линк-пути используются.
Обзор распределения трафика по интерфейсам и подсетям.
Аппаратные счётчики, показывают, какой линк реально получает пакеты.
Смотрим, не «сбрасывает» ли ASIC пакеты из-за некорректного хеша или hardware limitation.
N.A.
Даже когда ECMP настроен, трафик может концентрироваться на одном линке из-за hash-функций.
Эти команды помогут понять, как маршрутизатор реально распределяет потоки и почему часть линков простаивает.
show ip route <prefix> detail
Показывает, какие next-hop задействованы и порядок выбора.
show ip cef <prefix> detail
CEF detail: next-hop, adjacency и hash, какие линк-пути используются.
show ip cef summary
Обзор распределения трафика по интерфейсам и подсетям.
show controllers ethernet-controller <interface> internal
Аппаратные счётчики, показывают, какой линк реально получает пакеты.
show platform hardware qfp active feature cef drop
Смотрим, не «сбрасывает» ли ASIC пакеты из-за некорректного хеша или hardware limitation.
N.A.
👍7❤1
Почему после включения Port-Security порт уходит в err-disable
Port-Security защищает сеть от нежелательных MAC-адресов, но при строгой настройке порта любое несоответствие правил вызывает блокировку.
⏺ На практике это проявляется так: на порту стоят IP-телефон и ПК, виртуальная машина на сервере, или случайно подключили другой коммутатор без согласования. Порт тут же падает, трафик прекращается, и STP перестраивает дерево.
🔎 Как проверить?
👨🎨 Как исправить
1️⃣ Временно восстановить порт:
2️⃣ Настроить лимит MAC или режим реакции:
3️⃣ Проверить актуальные MAC на порту и при необходимости добавить в allowed list:
N.A.
Port-Security защищает сеть от нежелательных MAC-адресов, но при строгой настройке порта любое несоответствие правил вызывает блокировку.
Порт переходит в err-disable, если на нём появляется больше MAC, чем разрешено, если новый MAC не в списке allowed, или если нарушается режим violation (shutdown).
show port-security interface Gi0/1
show port-security address
show interfaces status err-disabled
show mac address-table interface Gi0/1
interface Gi0/1
shutdown
no shutdown
interface Gi0/1
switchport port-security maximum 3
switchport port-security violation restrict
switchport port-security mac-address sticky
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9👎1
Пинг проходит, а приложение не работает
ICMP отвечает, маршрут есть, latency нормальная - но сайт не открывается, API не отвечает, RDP/SSH зависает на этапе подключения. Это типичный случай, когда L3 жив, а проблема выше.
⏺ Вторая распространённая причина - stateful firewall. Пакеты могут доходить до сервера, но обратный трафик блокируется из-за отсутствия сессии в таблице состояний или из-за asymmetric routing. В логах - тишина, потому что дроп происходит «легально» по логике state engine.
⏺ Третий сценарий - асимметрия маршрутизации. Запрос идёт через один firewall или edge, а ответ возвращается через другой. Для ICMP это не критично, для TCP — критично. В результате handshake не завершается или соединение обрывается.
Также возможны проблемы на уровне L4–L7: неверный listener на сервере, сервис слушает не тот IP, TLS mismatch, истёкший сертификат, DNS возвращает неправильный адрес.
Пинг до IP проходит, но приложение недоступно по FQDN.
N.A.
ICMP отвечает, маршрут есть, latency нормальная - но сайт не открывается, API не отвечает, RDP/SSH зависает на этапе подключения. Это типичный случай, когда L3 жив, а проблема выше.
Чаще всего причина в несоответствии MSS/MTU: small ICMP-пакеты проходят, а крупные TCP-сегменты фрагментируются или silently дропаются. Особенно актуально для VPN, GRE, PPPoE и overlay-сетей.
Также возможны проблемы на уровне L4–L7: неверный listener на сервере, сервис слушает не тот IP, TLS mismatch, истёкший сертификат, DNS возвращает неправильный адрес.
Пинг до IP проходит, но приложение недоступно по FQDN.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
NTP для больших сетей MikroTik: несколько серверов и failover
В корпоративной или разветвленной сети важно не просто синхронизировать время на одном роутере, а обеспечить резервирование и согласованность времени на всех устройствах.
⏺ Несколько NTP-серверов
Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:
Первичные и вторичные серверы внутри сети гарантируют, что локальные устройства будут иметь корректное время даже при обрыве интернета.
⏺ Проверка и диагностика
Состояние клиента можно проверить так:
В выводе видны активные серверы и задержка до них. Высокая задержка или отсутствие ответа сигнализируют о проблемах с сетью или firewall.
⏺ Failover и последовательность
1️⃣ Внутренние серверы берут приоритет, если они доступны.
2️⃣ Внешние NTP сервера — резерв.
3️⃣ Если все недоступны — роутер использует локальные часы, но периодически пробует повторно синхронизироваться.
N.A.
В корпоративной или разветвленной сети важно не просто синхронизировать время на одном роутере, а обеспечить резервирование и согласованность времени на всех устройствах.
Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:
/system ntp client set enabled=yes primary-ntp=192.168.1.10 secondary-ntp=192.168.1.11 server-dns-names=0.pool.ntp.org,1.pool.ntp.org
Первичные и вторичные серверы внутри сети гарантируют, что локальные устройства будут иметь корректное время даже при обрыве интернета.
Состояние клиента можно проверить так:
/system ntp client print
/system ntp servers print
В выводе видны активные серверы и задержка до них. Высокая задержка или отсутствие ответа сигнализируют о проблемах с сетью или firewall.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤3
Почему после добавления второго uplink трафик идёт неравномерно
Добавили второй uplink для увеличения пропускной способности, а трафик почему-то идёт почти только через один линк.
Причина чаще всего не в физике, а в логике маршрутизации: ECMP использует хеширование по 5-tuple (src/dst IP, src/dst port, protocol). Если сессий немного или все они имеют одинаковые адреса/порты, hash «схлопывается» на один путь.
Ещё возможна асимметричная маршрутизация: ответ идёт через другой линк, firewall/stateful inspection блокирует часть трафика, или маршруты не совпадают в разных VRF/таблицах.
Что проверить
⏺ show ip route <prefix> detail - какие next-hop реально используются.
⏺ show ip cef <prefix> detail - hash и adjacency для конкретного префикса.
⏺ show ip cef summary - распределение трафика по интерфейсам.
⏺ show controllers ethernet-controller <interface> internal - реальные счётчики, какой линк принимает пакеты.
⏺ show platform hardware qfp active feature cef drop - проверка, не сбрасывает ли ASIC пакеты из-за некорректного хеша.
N.A.
Добавили второй uplink для увеличения пропускной способности, а трафик почему-то идёт почти только через один линк.
Причина чаще всего не в физике, а в логике маршрутизации: ECMP использует хеширование по 5-tuple (src/dst IP, src/dst port, protocol). Если сессий немного или все они имеют одинаковые адреса/порты, hash «схлопывается» на один путь.
Также влияет L3 load-balancing: маршрутизатор распределяет пакеты по линкам на основе hash, а не равномерно по объёму. Поэтому маленькие потоки будут «привязаны» к одному интерфейсу.
Ещё возможна асимметричная маршрутизация: ответ идёт через другой линк, firewall/stateful inspection блокирует часть трафика, или маршруты не совпадают в разных VRF/таблицах.
Что проверить
show ip route <prefix> detail
show ip cef <prefix> detail
show ip cef summary
show controllers ethernet-controller <interface> internal
show platform hardware qfp active feature cef drop
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤1
Почему NAT-пулы быстро исчерпываются
Серверы вроде имеют доступ в интернет, линк поднят, маршруты есть, а новые подключения внезапно не проходят.
Особенно это заметно при VPN или когда все новые подключения уходят через один NAT IP.
Например, можно сразу посмотреть активные трансляции:
И проверить статистику пула, количество hits и максимум:
Если есть сомнения, что ACL мешает трафику, проверяем:
А для проверки маршрутов, по которым трафик идёт через NAT:
Чтобы временно освободить пул и проверить реакцию сети:
Решение обычно включает расширение NAT-пула, использование overloading через несколько внешних адресов и перераспределение сессий по разным NAT-гейтвеям.
N.A.
Серверы вроде имеют доступ в интернет, линк поднят, маршруты есть, а новые подключения внезапно не проходят.
Обычно проблема не в физике, а в лимите NAT-сессий: каждый исходящий TCP или UDP поток занимает отдельную translation entry, и stateful firewall тоже учитывает каждую сессию.
Особенно это заметно при VPN или когда все новые подключения уходят через один NAT IP.
Например, можно сразу посмотреть активные трансляции:
show ip nat translations
И проверить статистику пула, количество hits и максимум:
show ip nat statistics
Если есть сомнения, что ACL мешает трафику, проверяем:
show access-lists
А для проверки маршрутов, по которым трафик идёт через NAT:
show ip route
Чтобы временно освободить пул и проверить реакцию сети:
clear ip nat translation *
Решение обычно включает расширение NAT-пула, использование overloading через несколько внешних адресов и перераспределение сессий по разным NAT-гейтвеям.
N.A.
👍8❤1👎1
Почему маршруты 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