12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
BFD vs OAM: мониторинг линка
✅ BFD (Bidirectional Forwarding Detection) и OAM (Operations, Administration, Maintenance) выглядят похоже, оба следят за состоянием канала, но работают по разному и для разных целей.
BFD мгновенно реагирует на падение соседнего узла.
bfd
peer 10.0.0.2
minimum-interval 300
detection-multiplier 3
ethtool -S eth0
📂Как правильно документировать сеть, чтобы не потерять конфиги
Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.
1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:
ip addr show # список интерфейсов
ip route show # таблица маршрутов
vtysh -c "show running-config" # конфиги роутеров
show vlan brief # VLAN на коммутаторах
Устройство | Интерфейс | IP | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1 | eth0 | 10.0.1.1/24 | 10 | WAN
sw1 | vlan10 | 10.0.1.2/24 | 10 | серверная зона
sw2 | vlan20 | 10.0.2.1/24 | 20 | офисная зона
server1 | eth1 | 10.0.1.10/24 | 10 | база данных
server2 | eth1 | 10.0.1.11/24 | 10 | веб-сервер
git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"
graph TD
R1 --> SW1
SW1 --> Server1
SW1 --> Server2
git log --oneline --graph # история изменений
diff old_config new_config # что изменилось
ping 10.0.1.2 # проверить доступность после изменений
Как проверить, что 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>
Ping внешнего IP: что происходит с ICMP-пакетом
На первый взгляд ping 8.8.8.8 прост, но под капотом - целый путь через стек и сеть.
Шаги прохождения пакета:
1️⃣Формирование пакета
Ping создаёт ICMP Echo Request через RAW-сокет. Источник - твой IP, цель - 8.8.8.8.
2️⃣Локальный стек
Пакет проходит через iptables/netfilter. Если политика DROP - даже локально он не уйдёт.
3️⃣Маршрутизация
Ядро выбирает интерфейс и next-hop для внешнего IP. NAT может поменять исходный адрес.
4️⃣Физический путь
Пакет выходит на интерфейс, проходит коммутаторы и маршрутизаторы. TTL уменьшается на каждом hop.
5️⃣Удалённый узел
Echo Reply создаётся на хосте и идёт обратно по пути, определённому его routing table.
6️⃣Возврат и RTT
Пакет возвращается, ping фиксирует RTT и выводит результат.
Что может сломать ping:
Пинг может не работать, если на локальной машине или по пути к цели блокируют ICMP пакеты (firewall/ACL), отсутствует маршрут к внешнему IP, некорректно настроен NAT, или TTL пакета слишком мал, чтобы достичь удалённого узла.
Полезные команды:
traceroute 8.8.8.8
tcpdump -i eth0 icmp
iptables -L -v -n
ip route get 8.8.8.8
Что происходит при ping 127.0.0.1: путь ICMP-пакета в loopback
ping 127.0.0.1 кажется банальной вещью, но под капотом — полноценный сетевой стек. Вот что происходит по шагам:
Сначала утилита ping создает RAW-сокет и формирует ICMP Echo Request. Пакет получает IP-адрес источника 127.0.0.1 и тот же адрес в качестве получателя.
Утилита ping ловит Echo Reply и выводит строку с временем RTT, даже если интерфейс lo отключен — это чисто внутренняя маршрутизация.
Сломана маршрутизация: удалена запись 127.0.0.0/8 dev lo — пакеты просто не найдут путь.
ip route get 127.0.0.1 — какая таблица маршрутов применяетсяiptables -L -v -n — проверка, не режется ли ICMPtcpdump -i lo icmp — убедиться, что пакеты доходятss -npi — посмотреть, что происходит с сокетом
Как найти «утекающий» DHCP‑трафик
Когда клиенты жалуются, что «IP не выдаётся», причина часто не в сервере, а в том, что DHCP broadcast где‑то теряется по пути. Это трудно заметить, потому что обычный трафик при этом работает.
Вот короткая схема проверки:
1️⃣Проверяем Snooping
Если включён DHCP Snooping, он может блокировать сервер или relay на недоверенном порту.
show ip dhcp snooping
show ip dhcp snooping binding
show storm-control
show vlan brief
show access-lists
show running-config interface <uplink>
show interface Gi1/0/15 counters
tcpdump -ni eth0 port 67 or port 68
Наконец-то ребята из контейнерной платформы “Штурвал” прислушались к сообществу и сделали альтернативу бесячей форме на сайте для получения community-лицензии. Теперь ее можно получить через бота в телеге: @l4_helper_bot.
Может ещё и Open-Source-версию сделают?
Как вычислить сломанный 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
🧭 Как вычислить некорректную обработку ECN
Разберём типовую ситуацию: приложение «плавает» по скорости, задержки нормальные, потерь нет, а throughput падает.
Часто причина, что ECN по пути работает неправильно: биты стираются, игнорируются или не ставится CE при перегрузке.
show policy-map interface Gi1/0/1
show policy-map interface Gi1/0/1 | i ECN|marked
monitor capture ...
tcpdump ip[1] & 0x03 != 0
show platform hardware qfp active statistics drop | i ECN
Проверяем, что firewall не режет return-трафик
Надо убедиться, что пакеты ответа проходят через firewall, а не блокируются из-за ассиметрии или политики stateful/NAT.
1️⃣На Linux (iptables/nftables): Смотрим состояние соединений через conntrack:
# Состояние соединений
conntrack -L | grep ESTABLISHED
# Количество непринятых ответов
conntrack -S | grep UNREPLIED
show conn detail | include ESTABLISHED
show conn detail | include half-open
/ip firewall connection print where state=established
/ip firewall connection print where state=unreplied
Как быстро проверить, что OSPF не анонсирует лишние маршруты
Надо убедиться, что соседние маршрутизаторы не получают маршруты, которые им не нужны, и сеть остаётся чистой.
OSPF умеет анонсировать маршруты через все интерфейсы по умолчанию. Чтобы ограничить это:
⏺Используем passive-interface - OSPF не будет посылать Hello и LSAs на этом интерфейсе.
⏺Используем фильтры (distribute-list или prefix-list) - чтобы пропускать только нужные сети.
Примеры на Cisco:
Сделать интерфейс пассивным:
router ospf 1
passive-interface GigabitEthernet0/1
show ip ospf neighbor
ip prefix-list ONLY_MY_NET seq 5 permit 192.168.10.0/24
router ospf 1
distribute-list ONLY_MY_NET out
show ip ospf database
🔎Как выявить дубликаты IP в сети
Дубли IP создают хаос в L2/L3: ARP-флуд, потерю пакетов и непредсказуемое поведение сервисов.
Особенно критично в VLAN с большим количеством хостов.
Простая диагностика на Linux:
Смотрим ARP-таблицу и ищем одинаковые IP с разными MAC:
ip neigh
arping -c 5 -I eth0 192.168.1.100
for ip in $(seq 1 254); do arping -c 1 -I eth0 192.168.1.$ip; done
show ip arp
show mac address-table
SPRINT OFFER в YADRO: Network Engineer in Test!
3 дня — и вы среди инженеров, которые обеспечивают надёжность сетевых систем YADRO 🚀
Мы расширяем команду KORNFELD, которая отвечает за качество и стабильность сетевого оборудования YADRO. Именно здесь инженеры анализируют архитектуру, пишут тестовые сценарии, моделируют сбои и доводят продукт до идеала.
Специалисты работают с самыми глубокими слоями сетевой инфраструктуры — от L2/L3 до сложных связок протоколов и сценариев отказоустойчивости.
⚙️ Как проходит SPRINT OFFER:
1️⃣ Подайте заявку до 30 ноября, пройдите HR-скрининг и технический скрининг.
2️⃣ Пройдите техническое и менеджерское интервью.
3️⃣ Получите оффер в течение 3 дней.
📍 Чем предстоит заниматься:
• Анализировать продуктовые требования и составлять use cases.
• Проводить функциональные, E2E- и failover-тесты.
• Разрабатывать тест-кейсы и тест-планы для нового и уже существующего функционала.
• Участвовать в интеграционных испытаниях, взаимодействовать с разработкой и L3-командами.
📀 У нас:
• Удалённая работа (РФ/РБ) или офис в городах присутствия — Москве, Санкт-Петербурге, Нижнем Новгороде, Екатеринбурге, Минске.
• Амбициозные проекты в уникальной команде инженеров.
• Вертикальный и горизонтальный карьерный рост.
• ДМС с первого дня, поддержка спортивных инициатив сотрудников и другие бенефиты.
💙 YADRO — место, где ценят инженерную экспертизу и предоставляют возможности для эксперимента и инициативы. Оставляйте заявку до 30 ноября и присоединяйтесь к команде KORNFELD!
Ветер перемен: представляем новую систему выпуска релизов UserGate NGFW
В основе — лучшие практики международных вендоров, принятые в мировой ИТ/ИБ-индустрии.
Все подробности расскажем на вебинаре. В программе:
— Что побудило нас к изменениям
— Новая система релизов: FR, LTS, LTS (GD)
— Что ещё мы делаем для повышения стабильности
— Первый кандидат на LTS и что в нём нового
В завершении ответим на ваши вопросы.
Вебинар будет интересен как техническим специалистам, так и руководителям ИТ- и ИБ-департаментов.
Спикеры:
— Кирилл Прямов, менеджер по развитию NGFW
— Михаил Кадер, архитектор ИБ, R&D
Когда: 27 ноября, четверг, 10:00 (МСК).
Увидимся в эфире!
Зарегистрироваться
Как выявить microbursts на интерфейсе
Microbursts — это короткие всплески трафика, которые длятся доли секунды.
show interface gi0/1 | include drops
watch -n 0.2 "ethtool -S eth0 | grep -E 'drop|overflow|miss'"
ICMP: тестируем не только ping
На первый взгляд ping кажется простой командой, но ICMP - полноценный инструмент для диагностики сети и анализа маршрутов.
# Traceroute через ICMP
traceroute -I 8.8.8.8
# Ping с разным TTL
ping -t 10 -c 5 8.8.8.8
# Проверка Path MTU
ping -M do -s 1472 8.8.8.8
Эмуляция RPL-сети на Linux через Docker Compose
Цель — поднять небольшую IoT-сеть с 5 узлами, построить DAG и проверить маршрутизацию.
Docker Compose конфигурация
Создаём файл docker-compose.yml:
version: '3.9'
services:
rpl-node1:
image: ubuntu:22.04
container_name: rpl-node1
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node2:
image: ubuntu:22.04
container_name: rpl-node2
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node3:
image: ubuntu:22.04
container_name: rpl-node3
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node4:
image: ubuntu:22.04
container_name: rpl-node4
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node5:
image: ubuntu:22.04
container_name: rpl-node5
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
ip link add veth1 type veth peer name veth1-peer
ip addr add 2001:db8:1::1/64 dev veth1
ip link set veth1 up
ip link set veth1-peer netns <container> # подключаем к соседнему контейнеру
rpld -i veth1 -r
rpld -i veth2
rpld -i veth3
rpld -i veth4
rpld -i veth1
rpld -i veth2
rplctl -i veth1 show
ping6 2001:db8:1::2 -I veth1
Привет. Вот тебе самые топовые каналы по IT!
⚙️ Free Znanija (IT) — Самая огромная коллекция платных курсов, которые можно скачать бесплатно;
👩💻 IT Books — Самая огромная библиотека книг;
💻 Hacking & InfoSec Base — Крутой блог белого хакера;
🛡 CyberGuard — Всё про ИБ;
🤔 ИБ Вакансии — Всё, чтобы найти работу в ИБ;
👩💻 linux administration — Всё про Линукс;
👩💻 Программистика — Python, python и ещё раз python;
👩💻 GameDev Base — Всё про GameDev;
😆 //code — Самые топовые мемы по IT:
Подпишись, чтобы не потерять!
🤩 Admin Books —электронные книги о компьютерных технологиях.
Используй предстоящие новогодние выходные наилучшим образом! Изучай новые технологии или закрой пробелы в знаниях по своему стеку.
Стань экспертом в следующих направлениях:
• Системное администрирование
• Информационная безопасность
• Сетевое администрирование
• Этичный хакинг
Ссылка для своих: /channel/admbooks
Как вычислить «молчаливый» ARP-флуд в сети
Даже если обычный трафик нормальный, сеть может испытывать проблемы из-за частого повторного ARP-запроса, который почти не виден в интерфейсных counters, но забивает CPU коммутатора или broadcast-домен.
Особенно важно для IoT, камер и массовых DHCP-сетей.
Проверим 👇
1️⃣Счётчики ARP на коммутаторе
show ip arp summary
show interfaces Gi1/0/10 counters
show logging | include ARP
tcpdump -nn -i eth0 arp
show ip arp inspection
🧭 Как вычислить сломанную политику QoS с Shaping и Token-Bucket
Иногда трафик вроде классифицирован правильно, но на пиках появляются задержки или пакеты «теряются» без видимых drop’ов.
Причина часто в неправильно настроенном shaping или drift token-bucket - hardware ограничивает throughput неравномерно, либо буфер переполняется.
Важно понимать, что QoS работает только если shaping и token-bucket настроены согласованно по всей цепочке.
1️⃣Проверяем статистику очередей:
show policy-map interface Gi1/0/1
show queueing interface Gi1/0/1
show platform hardware qfp active statistics drop
monitor capture ...
Как найти порты с неправильными Storm Control-лимитами
Иногда Storm Control включён, но лимиты выставлены слишком жёстко - и коммутатор начинает резать обычный трафик как «шторм».
Типичный признак - порты рандомно падают в suppression, появляются жалобы на «плавающий» доступ, особенно в сетях с VoIP, камерой или IoT.
Важно понять две вещи:
⏺где включён Storm Control,
⏺и не слишком ли низкий порог стоит для конкретного трафика.
1️⃣Проверяем текущее состояние лимитов:
show storm-control
show running-config interface Gi1/0/10 | include storm
show storm-control interface Gi1/0/10snmpwalk -v3 -u user -l authPriv -a SHA -A authpass -x AES -X privpass <switch> .1.3.6.1.4.1.9.9.187
Ловим «ломаный» QoS по DSCP
Бывает так: сеть чистая, задержки нормальные, потерь нет - а приложения вдруг притормаживают.
Часто проблема не в каналах, а в том, что DSCP меняется там, где никто не планировал.
В итоге QoS работает “криво”, а трафик оказывается в неверном классе.
QoS по DSCP держится на трёх вещах:
⏺Правильный trust на портах (где мы доверяем меткам)
⏺Классификация, соответствующая реальному трафику
⏺Политики, которые не перетирают DSCP по пути
Если одно звено даёт сбой - весь QoS превращается в best-effort.
Проверяем trust на интерфейсе:
show mls qos interface Gi1/0/1
show policy-map interface Gi1/0/1
show policy-map interface Gi1/0/1 | i match|packets
monitor capture ...
🔥 БЕСПЛАТНЫЙ КУРС ПО СОЗДАНИЮ НЕЙРО-СОТРУДНИКОВ НА GPT И ДРУГИХ LLM 🔥
Ищете практический и углубленный курс, чтобы освоить создание нейро-сотрудников? Мы создали курс из 5 объемных занятий. Это именно то, что нужно, чтобы прокачать свои навыки абсолютно бесплатно!
📌 Темы занятий:
1. Введение в мир нейро-сотрудников
2. Как работают LLM и их аналоги
3. Создание базы знаний для нейро-сотрудника (RAG)
4. Тестирование и отладка нейро-сотрудников
5. Интеграция нейро-сотрудников в Production
Вот 5 тем курса - он максимально простой и доступный, общеобразовательный, без какого-либо сложного программирования 📚Прохождение этого курса, скорее всего, займет у вас от 1 до 3 часов
🤖 Присоединяйтесь к нашему бесплатному курсу и разберитесь в этой увлекательной теме с нами!
Как найти порты с включённым Storm Control
Storm Control защищает коммутаторы от флудов широковещательного, мультикаст и уникаст трафика.
show storm-control
show running-config interface Gi1/0/10 | include storm
snmpwalk -v3 -u user -l authPriv -a SHA -A authpass -x AES -X privpass <switch> .1.3.6.1.4.1.9.9.187
🧭 Как вычислить неправильную политику VRF
Попробуем понять, почему трафик «исчезает» между VRF и не достигает нужного сегмента.
Часто бывает, что маршруты присутствуют, но CEF или next-hop указывают на другой VRF, либо политики import/export настроены неправильно.
VRF (Virtual Routing and Forwarding) создаёт отдельные таблицы маршрутизации на одном устройстве.
Для того чтобы трафик мог идти между VRF или к внешним интерфейсам, нужно правильно настроить:
⏺Route-target import/export (для MPLS VPN)
⏺CEF/forwarding для нужных IP
⏺Interface VRF assignment
Если хоть один элемент настроен неверно, пакеты не будут маршрутизироваться.
Практика на Cisco:
1️⃣Проверяем маршруты в конкретной VRF:
show ip route vrf CUSTOMER_A
show ip cef vrf CUSTOMER_A 10.10.1.5
show ip bgp vpnv4 all
show run | section interface
interface Gi1/0/1
vrf forwarding CUSTOMER_A
ip address 10.10.1.1 255.255.255.0
Проверка асимметричного VLAN на trunk
Проблема в том, что на стыке двух коммутаторов trunk порт настроен, но трафик некоторых VLAN не проходит.
Часто это из-за того, что на одной стороне не разрешены все нужные VLAN, или VLAN ID не совпадает.
Как быстро проверить:
1️⃣На Cisco:
show interfaces trunk
show vlan brief
ip -d link show eth0
ping -I eth0.10 <IP в этой VLAN>
Осторожно, пакеты отправляются. Следующая станция 192.168. …
N.A.
🎉 Результаты розыгрыша:
🏆 Победители:
1. Руслан (@pandikkd)
2. . (@pythonschik)
✔️Проверить результаты
Как поймать внезапный ARP-resolve timeout
Когда «всё работает… но периодически что-то замирает», очень часто виноват ARP.
Хост просто не может быстро получить MAC адрес - и весь трафик встаёт на паузу. Особенно больно это бьёт по VoIP, SSH и интерактивным сервисам.
tcpdump -ni eth0 arp
debug arp
show arp
tcpdump -ni eth0 "arp or icmp"
ip -s neigh
show mac address-table dynamic | include <MAC>