Network Admin

ECMP: почему трафик «неравномерно» распределяется по линкам Даже когда таблица маршрутизации показывает несколько 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.

🌐 Сети для всех — сообщество для тех, кто хочет разобраться в компьютерных сетях и системном администрировании. 👉 Наш Telegram-канал: https://t.me/Networks_anyone 👉 Наш VK-канал: https://vk.ru/club236314394 Внутри сообщества вас ждет: - практические задания и разборы - понятная теория без воды - видеолекции и примеры конфигураций - обсуждение реальных и нестандартных сетевых задач - помощь и живое общение с единомышленниками 🎓 Курсы команды «Сети для всех»: 1️⃣ Компьютерные сети (Cisco — введение) https://stepik.org/a/227855 2️⃣ Компьютерные сети (Cisco — продвинутый уровень) https://stepik.org/a/230932 3️⃣ Компьютерные сети (MikroTik — практическое администрирование) https://stepik.org/a/260615 👥 Более 500 студентов уже с нами — присоединяйтесь к сообществу и прокачивайте сети вместе с нами. Сети для всех — понятно, практично, по делу. #СетиДляВсех #NetworksForAll

Маршрут есть, но next-hop недостижим В таблице маршрутизации префикс выглядит корректно: выбран 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.

Несогласованность control-plane и data-plane в MPLS В 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.

Маршрут есть в RIB, но не участвует в forwarding В таблице маршрутизации префикс присутствует, 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.

BGP сосед есть, но маршруты не проходят Сессия установлена, состояние Established, keepalive идут, но нужных префиксов в таблице нет. Такое часто происходит, когда маршруты режутся политиками или не могут установиться из-за next-hop. Одна из первых вещей - проверить, приходят ли маршруты от соседа вообще. Это видно через

    
        show ip bgp neighbors <ip> received-routes{}
    

⏺Если маршруты приходят, но не устанавливаются в таблицу, стоит посмотреть общий BGP статус:

    
        show ip bgp{}
    

⏺Частая причина - prefix-list или route-map, которые фильтруют префиксы. Проверяется через

    
        show running-config | section route-map{}
    

⏺Иногда маршрут есть, но next-hop недостижим, поэтому он не попадает в RIB. Проверка обычной таблицы маршрутов помогает быстро это увидеть:

    
        show ip route{}
    

⏺В сетях с route-reflector также бывает, что политика отражения не разрешает распространение маршрута. Тогда полезно посмотреть детали соседа:

    
        show ip bgp neighbors <ip>{}
    

N.A.

Как вычислить сломанный FIB/CEF на магистрали

    
        Сложные сетевые проблемы часто выглядят как «плавающие» потери или нестабильный 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.

SSL/TLS соединения падают при смене времени Когда часы на сервере или клиенте идут неправильно, соединения начинают обрываться. Проблема обычно связана с выключенным или некорректным NTP, истёкшими сертификатами и сбоями handshake. Даже если IP доступен и маршруты корректны, TLS проверяет корректность времени для сертификатов и сессий, поэтому любые расхождения приводят к падению соединения. Проверка и диагностика:

    
        show ntp status
show clock
show crypto pki certificates{}
    

Для исправления нужно синхронизировать время через NTP и убедиться, что сертификаты действительны. Иногда достаточно пересоздать TLS-сессию после корректной синхронизации времени. N.A.

Почему маршруты OSPF есть, но трафик не идёт В 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.

Использование /31 префикса в IP-сетях /31 в IPv4 — это не «странная маска», а рабочий стандарт для линков точка-точка, особенно при подключении к провайдерам. Но если вы не понимаете, почему это вообще стало возможно и как оно устроено, вы либо переплачиваете адресным пространством на /30, либо боитесь внедрять /31 без уверенности. 📅 На открытом уроке 10 марта в 20:00: — Разберём, зачем появился /31, как именно работает линк с такой адресацией и чем подход отличается от классического /30. — После урока вы сможете принимать взвешенное решение, когда /31 уместен, а когда лучше оставить /30. Урок не для тех, кто хочет «просто запомнить настройку» без понимания механики и ограничений, или рассчитывает закрыть тему IPv4 адресации одной шпаргалкой. 👉 Записаться: https://otus.pw/8346/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576