12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
🧬 Вебинар: эволюция 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 *
NTP для больших сетей MikroTik: несколько серверов и failover
В корпоративной или разветвленной сети важно не просто синхронизировать время на одном роутере, а обеспечить резервирование и согласованность времени на всех устройствах.
⏺Несколько NTP-серверов
Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:
/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
Что будет, если героические способности уместить в компактную оболочку?
❓новый герой Marvel
❓настольный сервер для задач локального ИИ
❓маленькая рабочая станция HP Z2 Mini G1a
Рассуждения в сторону, т.к. это тот самый случай, когда все варианты ответов верны!
А чтобы сомнения в могуществе этой машинки отпали раз и навсегда, подготовили небольшой видеообзор HP Z2 Mini G1a. Подсветили главные достоинства, конфигурации, области применения и даже провели наглядный тест — "как 128 ГБ памяти превращаются в локальный ИИ на 120 млрд параметров"
💬Смотреть в MAX
📺Смотреть на сайте
А совсем скоро ожидаем рабочую станцию Minisforum. Подписывайтесь, чтобы не пропустить обзор!
Сервер, сторадж & два свича
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJmdLdo
Почему после включения Port-Security порт уходит в err-disable
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
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 инженера - что нужно изучить, чтобы не метаться между сотней инструментов.
➡️ Запишись на бесплатные вводные уроки
Чтобы код работал одинаково везде - не только на твоем ноуте, но и на сервере, и в проде.
Почему после добавления второго uplink трафик идёт неравномерно
Добавили второй uplink для увеличения пропускной способности, а трафик почему-то идёт почти только через один линк.
Причина чаще всего не в физике, а в логике маршрутизации: ECMP использует хеширование по 5-tuple (src/dst IP, src/dst port, protocol). Если сессий немного или все они имеют одинаковые адреса/порты, hash «схлопывается» на один путь.
Также влияет L3 load-balancing: маршрутизатор распределяет пакеты по линкам на основе hash, а не равномерно по объёму. Поэтому маленькие потоки будут «привязаны» к одному интерфейсу.
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
Пинг проходит, а приложение не работает
ICMP отвечает, маршрут есть, latency нормальная - но сайт не открывается, API не отвечает, RDP/SSH зависает на этапе подключения. Это типичный случай, когда L3 жив, а проблема выше.
Чаще всего причина в несоответствии MSS/MTU: small ICMP-пакеты проходят, а крупные TCP-сегменты фрагментируются или silently дропаются. Особенно актуально для VPN, GRE, PPPoE и overlay-сетей.
Скотча не было, а вот энтузиазм присутствовал 😎
N.A.
5 команд для анализа L3 ECMP и распределения трафика
Даже когда ECMP настроен, трафик может концентрироваться на одном линке из-за hash-функций.
Эти команды помогут понять, как маршрутизатор реально распределяет потоки и почему часть линков простаивает.
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