12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
Как проверить, что 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'"
Протоколы маршрутизации и резервирование: как быстро перестроить сеть без потери трафика
Что происходит в сети при отказе маршрута и как сделать так, чтобы пользователи ничего не заметили? На открытом вебинаре курса OTUS Network Engineer. Professional Николай Колесов разберёт, как работают динамические протоколы маршрутизации и механизмы резервирования, обеспечивающие мгновенное восстановление сети.
→ 26 ноября, 20:00
Протоколы маршрутизации и резервирование — или как быстро перестроить таблицу маршрутизации не привлекая внимание
— как протоколы маршрутизации обеспечивают быструю сходимость сети
— какие механизмы резервирования позволяют избежать простоев
— настройка механизмов повышения скорости перестроения маршрутов
— практические подходы к построению отказоустойчивых сетей
Вебинар будет полезен сетевым инженерам, администраторам и архитекторам, работающим с корпоративными и распределёнными сетями, а также всем, кто хочет глубже разобраться в динамической маршрутизации и резервировании.
→ Зарегистрируйтесь: https://otus.pw/2wip/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Кто идёт на Kuber Conf by AOT 4 декабря?
Устраиваю розыгрыш 2 билетов на Kuber Conf by АОТ — первую коммьюнити конференцию по K8s в России, которая пройдет 4 декабря в Москве.
В программе — только хардкор и реальные кейсы от команд Авито,Т-Банка, Vitastor, Beget, VK Cloud, Yandex Cloud, Selectel и других.
🟣 Изменения в Cluster API без пересоздания машин
🟣 Как строили платформу деплоя в Т-Банке
🟣 Практический deep-dive в CNI chaining
🟣 Безопасный Gatekeeper в архитектуре k8s-in-k8s
🟣 Поддержка Kubernetes в Vitastor
🟣 Karpenter-провайдер своими руками — что внутри
📅 20 ноября в 12:00 выберем 2 счастливчиков.
Чтобы участвовать: подпишитесь на канал, активируйте участие по кнопке снизу и ждите 20.11. В 20:00 с помощью бота-рандомайзера будет выбран победитель.
Kuber Conf by AOT пройдет под эгидой будущей Ассоциации облачно-ориентированных технологий (АОТ), ее создают VK Cloud, Флант и Yandex Cloud.
Присоединяйся!
➡️ Программа и билеты
Реклама Садовская.Е.О
ИНН:9710066394 Erid:2VtzqxfLCoj
Привет. Вот тебе самые топовые каналы по 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>
Как понять, что ACL режет нужный трафик
Когда сервис «периодически падает», VPN не поднимается или API отвечает через раз - один из первых подозреваемых - ACL, который молча дропает пакеты.
Суть в том, чтобы посмотреть, реально ли ACL блокирует нужный поток, и какой именно rule это делает.
🛠 Как смотрим на Cisco
Проверяем hitcount - кто реально срабатывает
Если счётчик растёт → правило принимает или режет трафик прямо сейчас.
show ip access-lists | include hitcnt
show ip access-lists <ACL_NAME>
show run interface <int>
ip access-list extended MY_ACL
deny tcp any any eq 443 log
show logging | include MY_ACL
Cisco: Private VLAN для изоляции устройств
Private VLAN (PVLAN) — это механизм L2-изоляции внутри одного большого VLAN.
Используется там, где клиенты должны видеть интернет, но не видеть друг друга: отели, коворкинги, общественные сети.
Как это работает:
PVLAN делит один VLAN на подтипы:
⏺Primary VLAN — основной VLAN.
⏺Isolated VLAN — хосты не могут общаться между собой, только с promiscuous-портом.
⏺Promiscuous port — обычно uplink к маршрутизатору/фаерволу. Видит всех.
В итоге, 100 клиентов в одном VLAN → каждый полностью изолирован, без создания сотен отдельных VLAN.
⚙️ Конфигурация PVLAN на Cisco
1️⃣Создаём primary и isolated VLAN
vlan 100
private-vlan primary
vlan 101
private-vlan isolated
vlan 100
private-vlan association 101
interface Gi1/0/1
switchport mode private-vlan promiscuous
switchport private-vlan mapping 100 101
interface range Gi1/0/10 - 20
switchport mode private-vlan host
switchport private-vlan host-association 100 101
show vlan private-vlan
show interfaces switchport