12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
Parallelism в сети: почему несколько потоков - это норма
Один TCP-поток почти никогда не использует весь канал между узлами с высокой пропускной способностью или большим RTT.
Даже гигабитный линк может быть недогружен, если работает только одно соединение.
iperf3 -c <server-ip> -P 1 # один поток, упираемся в single-flow limit
iperf3 -c <server-ip> -P 8 # 8 потоков, канал почти полностью загружен
Как понять, что упираешься в single-flow limit
Канал вроде быстрый, интерфейс не забит, CPU в порядке - но скорость упирается в 200–300 Мбит/с и выше не растёт. При этом параллельные загрузки «вдруг» дают почти весь канал.
iperf3 -c <server-ip> -P 1
iperf3 -c <server-ip> -P 10
ss -ti
BFD flaps на стабильных линках
Линк выглядит стабильным: OSPF и BGP держат соседство, ping проходит, маршруты есть, но BFD внезапно сигнализирует «link down».
В результате мгновенно конвергируют маршруты, появляются кратковременные packet drops, а логи показывают тревожные сообщения, хотя физический линк не упал.
show bfd neighbors
show bfd sessions
ping <neighbor-ip> repeat 100
VRF для полной изоляции management-трафика
На первый взгляд кажется, что смешивание management и user traffic - нормальное решение.
vrf definition MGMT
rd 65000:99
interface Vlan99
vrf forwarding MGMT
ip address 10.99.0.10 255.255.255.0
no shutdown
🧬 Вебинар: эволюция DDoS-защиты в 2026–2027
Атак стало больше в 2 раза, сценарии усложнились. Всё чаще они маскируются под легитимный трафик, из-за чего классические методы защиты теряют эффективность.
Приглашаем на вебинар, где разберем:
– Трансформацию DDoS и что нас ждет в будущем
– Почему классические методы защиты уже перестают работать
– На какие метрики важно обращать внимание
– Что должна уметь современная система защиты
Актуально для ИТ- и ИБ-руководителей, сетевых инженеров и специалистов по защите IT-инфраструктуры.
Зарегистрироваться бесплатно ✅
BFD flaps при высокой jitter
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
📘 На Stepik вышел курс — «DevOps-инженер: От основ до продакшена»
Хотите автоматизировать деплой и выстраивать надёжные CI/CD процессы? Этот курс — полный путь DevOps-инженера: от первого сервера до продакшена.
• CI/CD: Jenkins, GitLab CI/CD, GitHub Actions, Blue-Green, Canary, rollback
• Контейнеризация: Docker (образы, Compose, networking), безопасность контейнеров
• Kubernetes: Pods, Services, Deployments, Helm
• Infrastructure as Code: Terraform, Ansible, ArgoCD и Flux для GitOps
• Мониторинг: Prometheus, Grafana, ELK Stack, OpenTelemetry, SLI/SLO/SLA
• Продакшен практики: High Availability, Disaster Recovery, Chaos Engineering
• В стоимость включено: поддержка на протяжении курса, разбор задач и вопросов, рецензирование итогового проекта и помощь в составлении резюме
🎓 Сертификат — добавьте в резюме или LinkedIn
🔥 Цена со скидкой: 9 990 ₽ → 5 990 ₽, действует ограниченное время
👉 Пройти курс на Stepik
RIB vs FIB divergence в high-end роутерах
В routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится.
Но data-plane не использует этот маршрут - пакеты не уходят, и кажется, что сеть «работает частично».
show ip cef <prefix> detail
show adjacency detail
show ip arp <next-hop>
show platform hardware qfp active feature cef drop
LACP bundle под нагрузкой ведёт себя криво
Несмотря на то что LACP показывает все линки поднятыми, часть трафика может «схлопываться» на один или два интерфейса, особенно под высокой нагрузкой.
Причины в том, как работает hashing по 5-tuple (src/dst IP, src/dst port, protocol): если потоков мало, почти все попадают в один bucket.
show etherchannel summary
show lacp neighbor
show interface <port-channel> counters
show interface <member-interface> statistics
show platform hardware forwarding hash <port-channel>
Silent packet drops на L3
В routing table маршрут есть, интерфейсы подняты, ping проходит, но часть трафика теряется или «тает» в пути.
Проблема кроется не в маршрутах, а в data-plane: ACL, CEF adjacency, рекурсивное разрешение next-hop или MTU mismatch. Даже когда control-plane полностью сходится, пакеты могут тихо дропаться на уровне forwarding.
Для диагностики сначала проверяем, как маршрут запрограммирован в CEF:
show ip cef <prefix> detail
show adjacency detail
show ip arp <next-hop>
show access-lists
ping <destination> size 1500 df-bit
Маршрут есть, но next-hop недостижим
В таблице маршрутизации префикс выглядит корректно: выбран best-path, указан next-hop, метрики нормальные.
Но трафик не проходит, потому что маршрут до самого next-hop не резолвится. Такое часто происходит в сетях с BGP и IGP, где next-hop объявляется через один протокол, а достижимость обеспечивается другим.
Сначала смотрят, какой next-hop используется для префикса:
show ip bgp <prefix>
show ip route <next-hop>
show ip cef <prefix> detail
show adjacency detail
Маршрут есть в RIB, но не участвует в forwarding
В таблице маршрутизации префикс присутствует, next-hop указан, метрики корректны, однако трафик всё равно не достигает назначения. В таких ситуациях проблема обычно находится между control-plane (RIB) и data-plane (CEF/FIB).
Сначала имеет смысл проверить, установлен ли маршрут в CEF - именно он используется для реальной пересылки пакетов:
show ip cef <prefix> detail
show adjacency detail
show ip arp <next-hop>
show platform hardware qfp active feature cef drop
Как вычислить сломанный FIB/CEF на магистрали
Сложные сетевые проблемы часто выглядят как «плавающие» потери или нестабильный RTT, хотя маршрутизация на уровне RIB выглядит идеально.
show ip cef 10.20.50.1 detail
show platform hardware qfp active forwarding ip route
show mpls forwarding-table 10.20.50.1
show tech cef consistency
Почему маршруты OSPF есть, но трафик не идёт
В routing table маршруты видны, интерфейсы up, соседи установлены - а пакеты не проходят.
Чаще всего проблема не в маршрутах, а в деталях OSPF: несоответствие cost, passive interface, ошибка аутентификации, или интерфейс находится в другом VRF, и трафик смотрит в другую таблицу.
Для проверки сначала смотрим соседей и их статус:
show ip ospf neighbor
show ip ospf interface
show running-config interface Gi0/1
show ip ospf interface | include Authentication
show ip route vrf <name>
Почему NAT-пулы быстро исчерпываются
Серверы вроде имеют доступ в интернет, линк поднят, маршруты есть, а новые подключения внезапно не проходят.
Обычно проблема не в физике, а в лимите NAT-сессий: каждый исходящий TCP или UDP поток занимает отдельную translation entry, и stateful firewall тоже учитывает каждую сессию.
show ip nat translations
show ip nat statistics
show access-lists
show ip route
clear ip nat translation *
Инженеры перебрали... Linux-кейсов 🤩
23 апреля K2 Cloud и K2Тех проведут онлайн - митап — pебята будут разбирать реальные инженерные кейсы из практики про поломанный SSH, обновление ядер, поломку сети в ВМ и балансировщики с одинаковыми конфигами, но разными результатами.
А ещё можно принести свой кейс на разбор и получить приз.
Подробности и регистрация по ссылке.
Корпоративные сети 2026 – конференция по сетевым технологиям. Никакой рекламы. Только обмен опытом.
🔗 Регистрация
Участие бесплатное, но регистрация обязательна
📅 8 апреля 2026 в 11:30
📍 Москва, ВК «Тимирязев Центр» (Верхняя аллея, 6, стр. 1)
Ⓜ️ Станция метро «Петровско-Разумовская»
Сетевые инженеры и ИТ-руководители поделятся реальными кейсами эксплуатации, настройки и защиты сетей. Честно обсуждаем цены и особенности железа разных производителей.
🧩 Полная программа конференции тут
Лично пообщаться с экспертами и коллегами можно будет во время кофе-брейков и в зоне экспозиции оборудования.
Конференция пройдет в рамках выставки «Связь-2026», так что вы сможете совместить посещение крупнейшего отраслевого события и нашей профильной площадки.
Организатор мероприятия:
ООО «Элтекс Коммуникации» — официальный дилер завода Eltex.
Ждем Вас на КС-2026!
#eltex #eltexcm #cnets #cnets2026 #связь2026 #кс2026
@eltexcm
#реклама
О рекламодателе
SNMP и NetFlow могут тайно ломать сеть
На первый взгляд кажется, что мониторинг - безопасное занятие. Но на high-end маршрутизаторах частый SNMP или NetFlow polling может создавать настоящие microbursts для CPU. В результате:
⏺Ping остаётся стабильным, но TCP/UDP падает.
⏺Пакеты silently drop, jitter растёт.
⏺Даже high-speed uplinks начинают вести себя странно.
Симптомы, которые сразу бросаются в глаза:
show processes cpu sorted
show platform hardware qfp active statistics drop
show interface <int> counters errors
5 команд, которые реально спасают на high-end сетях
Ситуация: маршруты есть, линк up, ping работает, но TCP/UDP падает, jitter/packet loss наблюдается. Эти команды быстро выявляют глубокие проблемы:
1️⃣RIB vs FIB divergence - маршрут есть в control-plane, но не запрограммирован в forwarding:
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
ECMP и hash buckets: почему трафик концентрируется на одном линке
Вроде несколько uplink и ECMP включён, но весь трафик «съезжает» на один порт.
Причина в том, как работает hashing: большинство платформ используют 5-tuple (src/dst IP, src/dst port, protocol) для распределения потоков по линкам.
show etherchannel load-balance
show interface <port-channel> counters
show interface <member-interface> statistics
show platform hardware forwarding hash <port-channel>
SNMP polling начинает «тормозить» сеть
Маршрутизатор вроде работает, интерфейсы up, маршруты в таблице, но приложения жалуются на задержки или потерю пакетов.
Часто виноват частый SNMP polling: когда CPU под нагрузкой, device тратит ресурсы на обработку запросов, и forwarding пакетов начинает падать.
Сначала проверяем, сколько SNMP-запросов обрабатывается:
show processes cpu sorted
show snmp group
show interfaces counters errors
show platform hardware qfp active statistics drop
CoS/DSCP конфликт в мульти-tenant сети
В сети несколько VLAN и overlay, QoS вроде настроен, но голосовой или видео-трафик начинает тормозить.
На L2 пакеты помечены CoS, на L3 - DSCP, и на trunk или VTEP эти метки могут не совпадать. В итоге latency-sensitive трафик попадает в обычный queue, и jitter растёт.
Смотрим, как метки проходят через интерфейсы:
show mls qos interface <interface> statistics
show policy-map interface <interface>
show class-map
show policy-map
show interface <interface> | include DSCP
show nve vni
show nve peers
Как проверить, что BGP-маршрут анонсируется, но не используется
Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём.
Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB.
1️⃣Проверяем, что маршрут вообще пришёл по BGP
Сначала убеждаемся, что апстрим реально его отдал.
Cisco:
show ip bgp <prefix>
show ip route <prefix>
show ip bgp <prefix>
show run | section route-map
show ip bgp neighbors <IP> received-routes
show ip cef <prefix>
DNS работает, но приложения не резолвят хосты
Ping до IP проходит, DNS-сервер отвечает на запросы, но приложения (HTTP, LDAP, почта) не могут резолвить имена.
nslookup example.com <dns-server>
dig example.com @<dns-server>
show access-lists
show ip nat translations
show ip route <client-ip>
show ip helper-address
traceroute <dns-server>
traceroute <client-ip> <router>
ECMP: почему трафик «неравномерно» распределяется по линкам
Даже когда таблица маршрутизации показывает несколько next-hop для префикса, data-plane может отдавать большинство потоков через один линк.
Причина не в маршрутах, а в том, как работает hashing для ECMP: большинство платформ используют 5-tuple hash (src/dst IP, src/dst port, protocol).
show ip route <prefix> detail
show ip cef <prefix> detail
show interface <interface> counters
show interface <interface> statistics
show platform hardware forwarding ecmp table
Несогласованность 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>
show mpls ldp bindings
show mpls ldp neighbor
show mpls ldp igp sync
show platform hardware qfp active feature mpls
BGP сосед есть, но маршруты не проходят
Сессия установлена, состояние 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>
SSL/TLS соединения падают при смене времени
Когда часы на сервере или клиенте идут неправильно, соединения начинают обрываться. Проблема обычно связана с выключенным или некорректным NTP, истёкшими сертификатами и сбоями handshake.
Даже если IP доступен и маршруты корректны, TLS проверяет корректность времени для сертификатов и сессий, поэтому любые расхождения приводят к падению соединения.
Проверка и диагностика:
show ntp status
show clock
show crypto pki certificates
Использование /31 префикса в IP-сетях
/31 в IPv4 — это не «странная маска», а рабочий стандарт для линков точка-точка, особенно при подключении к провайдерам. Но если вы не понимаете, почему это вообще стало возможно и как оно устроено, вы либо переплачиваете адресным пространством на /30, либо боитесь внедрять /31 без уверенности.
📅 На открытом уроке 10 марта в 20:00:
— Разберём, зачем появился /31, как именно работает линк с такой адресацией и чем подход отличается от классического /30.
— После урока вы сможете принимать взвешенное решение, когда /31 уместен, а когда лучше оставить /30.
Урок не для тех, кто хочет «просто запомнить настройку» без понимания механики и ограничений, или рассчитывает закрыть тему IPv4 адресации одной шпаргалкой.
👉 Записаться: https://otus.pw/8346/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Запустил Docker на локалке - все летает. Залил на сервер - посыпались ошибки.
Знакомая картина: у тебя на ноуте контейнер стартует, приложение работает, порты открываются.
⁉️А на сервере:
— контейнер падает с непонятной ошибкой
— файлы не подмонтировались
— права доступа вылезают там, где их не ждали
И ты сидишь, гуглишь и не понимаешь, что пошло не так.
Спойлер: дело не в Docker, а в окружении. Разные версии, переменные, пути. Docker просто честно показывает, что они отличаются.
❇️ Ребята из Merion Academy (того самого YouTube-канала про IT) на бесплатных вводных уроках разбирают Docker с нуля и дают пошаговый роадмап по профессии DevOps инженера - что нужно изучить, чтобы не метаться между сотней инструментов.
➡️ Запишись на бесплатные вводные уроки
Чтобы код работал одинаково везде - не только на твоем ноуте, но и на сервере, и в проде.