12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
Зачем на транках отключать DTP, даже если соседи свои
DTP хорош, пока сеть маленькая и все помнят, что где включено.
В реальной жизни это редкость. Достаточно один раз перепутать порт или скопировать конфиг - и access внезапно начинает вести себя как trunk.
interface GigabitEthernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport nonegotiate
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
switchport nonegotiate
show interfaces Gi1/0/24 switchport
Зачем ограничивать MAC-адреса на порту, если есть VLAN
VLAN изолирует трафик, но никак не ограничивает количество устройств за портом.
Для коммутатора access-порт по умолчанию готов принять десятки MAC-адресов, если они в одном VLAN.
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
switchport port-security
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security mac-address sticky
switchport port-security violation shutdown
show port-security interface Gi1/0/10
show mac address-table interface Gi1/0/10
Почему сеть сложнее приложений?
Приложение можно уронить и поднять обратно. В худшем случае - откатить релиз или перезапустить контейнер.
Поэтому сеть не любит эксперименты в продакшене. Здесь нельзя просто «задеплоить и посмотреть».
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
Почему ACL лучше писать длиннее, но понятнее
Короткий ACL выглядит красиво и экономит строки, но на практике это почти всегда ловушка.
! Короткое ACL — вроде работает, но что именно разрешено?
access-list 101 permit tcp any any eq 80
access-list 101 permit tcp any any eq 443
access-list 101 permit udp any any range 5000 6000
! Длинное ACL — сразу понятно, для чего каждая строка
! Веб-трафик
access-list 101 permit tcp any any eq 80 comment Web HTTP
access-list 101 permit tcp any any eq 443 comment Web HTTPS
! UDP для приложений
access-list 101 permit udp any any range 5000 6000 comment App UDP
Когда L2-ошибка страшнее L3
L3 ломается громко и понятно. Нет маршрута - трафик не идёт. traceroute обрывается, логика очевидна: ищем, где потерялся next hop.
L2 ведёт себя иначе. Ошибка может существовать долго и выглядеть как «плавающая» проблема.
Ещё хуже, когда проблема затрагивает control-plane. STP пересчитывается слишком часто, порты то блокируются, то открываются, и сеть сама себя дестабилизирует. Это выглядит как деградация приложений, хотя корень проблемы — обычный L2.
Проблема: при построении высокоскоростных систем при использовании мощного GPU конфигурация часто упирается в скорость передачи данных из хранилища.
Решение: схема GPU-сервер с GDS + Сервер Dell PowerEdge R7725xd
Наглядно показываем, как организовать систему, в которой передача данных из хранилища в GPU происходит напрямую с минимальными задержками. Приятные сюрпризы ожидают специалистов, работающих с 1С и СУБД😉 Краткое пояснение оставили в карточках.
А подробнее о том, как такая архитектура реализована, для кого подходит, каких результатов достигает и что показали тесты — читайте в статье📲
Сервер, сторадж & два свича
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJekSDW
📘 На Stepik вышел курс — «SRE-инженер: От основ до продакшена»
Хотите строить системы, которые не падают, управлять инцидентами без хаоса и внедрять культуру надёжности? Этот курс — полный путь SRE-инженера.
• SRE-фундамент: философия SRE, error budgets, toil reduction, blameless culture
• SLI/SLO/SLA: метрики надёжности, договорённости с бизнесом
• Observability: Prometheus, Grafana, ELK Stack, Jaeger, OpenTelemetry
• Алертинг: эффективные алерты, runbooks, on-call ротации
• Incident Management: классификация, эскалация, координация
• Post-mortem: root cause analysis, предотвращение повторений
• Отказоустойчивость: graceful degradation, circuit breakers, failover
• Chaos Engineering: Chaos Monkey, Litmus, Game Days
• Продакшен: High Availability, Disaster Recovery, RTO/RPO
🎓 Сертификат — добавьте в резюме или LinkedIn
🚀 Скидка 25%, действует 48 часов
👉 Пройти курс на Stepik
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