12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
STP Port States: почему порт долго висит в Listening/Learning
STP переводит порт через несколько состояний перед тем как начать передавать трафик. Blocking, Listening, Learning, Forwarding. В норме переход занимает 30 секунд (15 сек Listening + 15 сек Learning). Если порт завис и не переходит в Forwarding, сеть на этом сегменте не работает.
⏺Чаще всего дело в одном из трёх: некорректно выбран Root Bridge и порт пересчитывает топологию, на порту включён TCN (Topology Change Notification) и STP постоянно переинициализируется, или PortFast не включён там где должен быть.
⏺Диагностика
Смотрим состояние портов и кто Root Bridge:
show spanning-tree
show spanning-tree detail
show spanning-tree detail | include topology change
interface Gi0/1
spanning-tree portfast
interface Gi0/1
spanning-tree bpduguard enable
spanning-tree portfast default
spanning-tree portfast bpduguard default
Bonding на Linux: mode 802.3ad и проверка активных линков
Bonding в Linux это аналог LAG на уровне ОС. Mode 802.3ad (LACP) объединяет интерфейсы в агрегат с динамическим согласованием, как на Cisco mode active.
Для работы нужен пакет ifenslave и загруженный модуль bonding:
modprobe bonding
apt install ifenslave
# /etc/systemd/network/bond0.netdev
[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=802.3ad
LACPTransmitRate=fast
MIIMonitorSec=100ms
# /etc/systemd/network/bond-slave.network
[Match]
Name=eth0 eth1
[Network]
Bond=bond0
# /etc/systemd/network/bond0.network
[Match]
Name=bond0
[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
cat /proc/net/bonding/bond0
ip link show bond0
ip -d link show bond0
КАК ПИРАТОВ С МИЛЛИОНАМИ ВЗЯЛИ ЧЕРЕЗ… ТЕРМОМЕТР👻
👀 В Испании накрыли одну из крупнейших пиратских платформ с мангой. Ребята годами крутили трафик на аниме, собирали сотни миллионов просмотров и зарабатывали на 18+ рекламных баннерах миллионы.
Никаких подписок и донатов они не просили, просто с*кс реклама. И деньги шли стабильно, всё выглядело как идеально выстроенная схема.
Но проблемы начались не в интернете. Правообладатели наняли специалистов, те аккуратно собрали информацию: где хостятся сайты, кто за ними стоит, где живут админы. Передали всё полиции и дальше уже дело техники. Они пришли к ним домой и обнаружили там простой термометр. А из него достали флешки с холодными криптокошельками почти на полмиллиона долларов!
⚠️ То есть люди, которые умели зарабатывать миллионы в интернете, слились на базовой вещи — физической безопасности и хранении активов. И это не единичный случай. Сейчас всё чаще работают не через взлом, а через деанон. Тебя находят → приходят → забирают всё. И если ты думаешь, что «ну я же просто храню крипту», то это ровно до первого интереса к тебе.
Хорошая новость — от этого можно защищаться. Потому что есть конкретные инструменты:
🟢 двойное дно
🟢 duress-пароль
🟢 криптоконтейнеры
🟢 убедительная легенда (правдоподобное отрицание)
🟢 Panic Button - уничтожит все при верном сигнале
и многие другие
Почитать про эти инструменты можно по ссылке:
🦔 CyberYozh
OSPF: сосед завис в EXSTART/EXCHANGE
EXSTART/EXCHANGE - это этап, где два OSPF-соседа договариваются об обмене LSA. Если сосед завис здесь, база топологии не синхронизируется и маршруты не появятся.
⏺Три главные причины: MTU mismatch (самая частая, DD-пакеты не проходят если MTU разный), дублирующийся Router ID (два роутера с одинаковым RID не могут завершить negotiation), проблемы аутентификации (пакеты уходят, но отклоняются на другой стороне).
Диагностика
Смотрим состояние соседа:
show ip ospf neighbor
show interfaces Gi0/0 | include MTU
interface Gi0/0
ip ospf mtu-ignore
show ip ospf | include Router ID
router ospf 1
router-id 1.1.1.1
clear ip ospf process
show ip ospf interface Gi0/0
interface Gi0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 <key>
Traceroute не совпадает с реальным путём
Сервис ведёт себя так, будто трафик идёт по одному маршруту, но traceroute показывает совсем другую картину.
При этом ping может быть стабильным, а задержки появляться “внезапно” и без логики.
traceroute <ip>
ip route get <ip>
mtr -T <ip>
tracepath <ip>
Неравномерное распределение трафика LB
⏺Снаружи всё выглядит нормально: LB живой, backend’ы подняты, трафик есть, но один инстанс стабильно перегружен, а остальные почти пустые.
Распределение часто ломается не на уровне новых подключений, а на уровне уже установленных сессий и того, как они “прилипают” к backend’ам.
ss -s
ss -tn sport = :80
curl -I <url>
ipvsadm -Ln
Разное поведение DNS у разных клиентов
Сервис у части пользователей работает нормально, у части периодически “проваливается” или уходит в странные задержки.
resolvectl query <domain>
getent ahostsv4 <domain>
strace -e trace=network -f curl -s <url>
Почему “не видно проблему” в сети, пока не посмотришь состояние TCP очередей
Иногда сервис не падает, но начинает “вязнуть”: запросы идут, ответы есть, но задержки растут без очевидной причины.
В таких случаях полезно смотреть не соединения как факт, а их внутреннее состояние в ядре.
ss -tin state established
ip -s link show <iface>
getent ahosts <domain>
Появился удобный AI-инструмент для подготовки к найму и прохождения собеседований - Sobes Copilot.
Это ассистент, который помогает прямо во время интервью: слушает диалог, распознаёт речь в реальном времени и подсказывает, как лучше ответить. Работает в Zoom, Google Meet, Teams, VK Calls и других платформах, и не виден при демонстрации экрана.
Что есть в Sobes Copilot:
• Подсказки в реальном времени во время собеседований
• Пост-анализ интервью - сервис разбирает прошедший созвон, выделяет сильные и слабые места, удачные формулировки и зоны роста
• Генератор и улучшение резюме - помогает собрать сильное резюме под конкретную вакансию
• Мок-собеседования (и System Design) - тренировки с ИИ, приближённые к реальным интервью
• Авто-отклики на HH - автоматизируют массовую подачу на вакансии по заданным фильтрам
Если хочешь проходить собеседования спокойнее, увереннее и системнее - посмотри, что умеет Sobes Copilot.
Почему после изменения ACL пропадает доступ к части сети
Настроили новый ACL на интерфейсе или между сегментами, но часть сервисов перестала отвечать: одни IP доступны, другие нет, часть приложений зависает на таймаутах.
Чаще всего проблема не в самом ACL, а в порядке правил и скрытых “deny any” в конце. Также часто забывают про обратный трафик, из-за чего запрос проходит, а ответ блокируется.
Типовые причины: ⏺правило блокирует обратный трафик (return traffic) ⏺ACL применён не в том направлении (in/out) ⏺отсутствуют разрешения для established/related соединений ⏺правило выше по списку перекрывает нужный allow ⏺забытый implicit deny в конце списка ⏺ACL применён только на одном интерфейсе в цепочке
Команды для проверки:
show access-lists
show ip interface
show run interface Gi0/0
debug ip packet
(аккуратно в проде)
traceroute <ip>
ping <ip>
show access-lists <name>
interface Gi0/0
ip access-group <name> in
ip access-group <name> out
⚡️ Анонсирована еще более бюджетная версия MacBook Pro
N.A.
FastPath vs FastTrack и разрыв модели обработки трафика
FastPath и FastTrack оба ускоряют обработку, но работают на разных уровнях и ломают привычную линейную модель прохождения пакета через RouterOS.
/ip firewall filter print
/ip firewall mangle print
/ip firewall connection print
/ip settings print
Link aggregation hashing algorithms и почему нагрузка распределяется неравномерно
Port-channel или bond выглядит как один быстрый интерфейс, но внутри трафик всегда режется по алгоритму хеширования. И от того, какие поля участвуют в hash, зависит реальная загрузка линков.
Если hash основан на L2 (например src-mac или dst-mac), распределение зависит от количества MAC-адресов. В сети с few talkers это быстро приводит к перекосу, когда один линк загружен, а остальные почти пустые.
⏺Если используется L3/L4 (src-ip, dst-ip, 5-tuple), балансировка становится ближе к реальной нагрузке приложений, но все равно упирается в количество потоков. Один большой поток всегда останется на одном физическом линке.
Cisco:
show etherchannel load-balance
show etherchannel summary
show interfaces port-channel 1
/interface bonding print
/interface bonding monitor bond1
Почему «низкая загрузка» не означает, что сеть здорова
На графиках всё спокойно. 10–20% загрузки, никаких красных зон, интерфейсы не перегружены. С точки зрения мониторинга - сеть «дышит».
show interfaces counters
show interface <int> | include rate
show queueing interface <int>
TCP retransmits в реальных сетях
Даже на пустом канале приложения могут тормозить. Packet loss или jitter заставляют TCP пересылать пакеты снова и снова, а один поток не успевает «накачать» канал.
⏺Признаки - медленный throughput, высокий RTT, заметные retransmits.
На Linux проверить легко
ss -ti | grep retrans
tcpdump -i eth0 tcp and host <peer-ip> -vv
📂Как правильно документировать сеть, чтобы не потерять конфиги
Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.
1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:
ip addr show # список интерфейсов
ip route show # таблица маршрутов
vtysh -c "show running-config" # конфиги роутеров
show vlan brief # VLAN на коммутаторах
2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:
Устройство | Интерфейс | 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 # проверить доступность после изменений
LACP vs Static LAG: когда что использовать
LAG (Link Aggregation Group) объединяет несколько физических линков в один логический. Два способа это сделать: статически или через LACP. Разница принципиальная.
⏺Static LAG просто объединяет порты без какого-либо согласования. Коммутатор не знает, что происходит на другой стороне, линк считается активным даже если там ничего нет. Быстро настраивается, но слепо.
⏺LACP (802.3ad) согласовывает агрегат через обмен LACPDU-пакетами. Оба конца знают о состоянии линков, при падении одного порта трафик перераспределяется автоматически. Чуть сложнее в настройке, но надёжнее.
Статику используют когда другая сторона не поддерживает LACP, например старое оборудование или некоторые гипервизоры. В остальных случаях лучше LACP.
Настройка на Cisco
Static LAG:
interface range Gi0/1 - 2
channel-group 1 mode on
interface range Gi0/1 - 2
channel-group 1 mode active
show etherchannel summary
show lacp neighbor
Wireshark фильтры для диагностики VLAN-трафика
Быстрая шпаргалка для тех, кто разбирает проблемы на trunk-портах или отлавливает трафик конкретного VLAN.
Базовые фильтры
Показать все 802.1Q фреймы, сузить до конкретного VLAN ID или до трафика одного хоста внутри него. Отправная точка для любой диагностики:
vlan
vlan.id == 10
vlan.id == 10 && ip.addr == 192.168.10.5
vlan.id == 10 && arp
vlan.id == 10 && bootp
vlan.id == 10 && stp
vlan.id == 20 && ip.addr == 192.168.20.1 && ip.addr == 192.168.20.2
vlan.id == 10 && !stp && !cdp && !lldp
vlan.id == 100 && vlan
vlan.priority == 5
VTP - почему его лучше отключить и как безопасно мигрировать без него
VTP (VLAN Trunking Protocol) автоматически синхронизирует VLAN-базу между коммутаторами. Звучит удобно, но по факту это бомба замедленного действия.
Главная проблема, что любой коммутатор с более высоким revision number перезапишет VLAN-базу на всех остальных. Подключил старый свич из кладовки, и все VLAN на продакшене слетели.
Почему отключают:
⏺Один неверный свич уничтожает всю VLAN-конфигурацию сети
⏺Сложно контролировать изменения - нет нормального аудита
⏺VTP v1/v2 не поддерживает extended VLAN (1006–4094)
⏺В современных сетях проще и безопаснее управлять VLAN вручную или через автоматизацию
Как безопасно мигрировать
1️⃣Сначала зафиксируй текущую VLAN-базу на VTP Server
show vlan brief
show vtp status
vtp mode transparent
show vlan brief
vtp mode off
5 команд, которые реально помогают ловить “невидимые” сетевые проблемы
1️⃣TCP-состояние и скрытые retransmit’ы
Когда сервис “живой”, но всё тормозит - обычные проверки ничего не показывают. Тут полезно смотреть, что происходит прямо в TCP-очередях.
ss -ti state all
ip route get <ip>
curl -w "@-" -o /dev/null -s <url>
mtr -T -P 443 <host>
ss -ltnp
Service работает через IP, не через DNS
Сервис открывается по IP нормально, но по доменному имени начинает вести себя странно: таймауты, разные ответы, иногда вообще “не тот” backend.
Часто это, когда клиент и DNS живут разной жизнью: IP уже поменялся, а часть систем продолжает ходить по старым записям.
resolvectl status
getent hosts <domain>
ip route get <ip>
curl -v --resolve <domain>:443:<ip> https://<domain>
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
Почему сервис “умирает” после включения retry
Retry включили на клиенте или gateway, и вместо стабилизации получили рост нагрузки и ощущение деградации, хотя инфраструктура не менялась.
curl -v <url>
mtr <ip>
tcpdump -i <iface>
curl -I <url>
Почему после добавления VLAN пропадает связь
Добавили VLAN, всё выглядит корректно, но хосты внезапно перестают видеть шлюз или друг друга. При этом линк “зелёный”, порты up, явных ошибок нет.
Проверка обычно начинается с того, что VLAN вообще существует и не потерялся на уровне коммутатора.
show vlan brief
show interfaces trunk
show running-config interface Gi0/1
show ip interface brief | include Vlan
show ip route connected
В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн
Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда?
Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России
📆 в канале размещаются как онлайн, так и оффлайн мероприятия;
👩💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие;
🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое
А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах:
🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!
Правильное Питание (ПП) коммутационного оборудования
Система резервного электроснабжения должна обеспечивать не просто бесперебойное, но правильное питание. ПП — как у зожников, только для электроприборов. Много есть неочевидных нюансов — и первые в мире ПП-ИБП, решающие все проблемы с плохим качеством электричества, делает Systeme Electric.
Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа. ПП-ИБП Systeme Electric с онлайн-топологией двойного преобразования обеспечат чистый синус, защитят от помех и скачков напряжения.
Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной. Система не рухнет в момент включения мощных потребителей (именно в это время возникают краткосрочные, но сильные перегрузки).
Настоящий суперфуд для оборудования — высочайший КПД 95%. Из-за этого ПП-ИБП Systeme Electric не перегреваются.
Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS). Не будет сложностей с подключением нового бесперебойника к существующему оборудованию.
Гарантия рекордная — 3 года — такую больше никто не дает.
Техподдержка 24/7 (в мессенджерах, днем и по телефону): после 6 — можно!
ПП-ИБП Systeme Electric — это не какой-то китайский электро-фастфуд. Это бывшее российское подразделение Schneider Electric, производителя легендарных APC. Технологии и лучшая команда инженеров те же самые — только вывеска новая (из-за евросанкций). Эти люди точно знают: на здоровье оборудования не экономят!
Первые в мире ПП-ИБП тут.
VXLAN vs MPLS vs VLAN design в датацентре
Три разных подхода к сегментации и масштабированию сети. Отличаются не только технологией, но и моделью построения всей инфраструктуры.
1️⃣VLAN design
VLAN - это классическая L2 сегментация через broadcast domain. Всё просто: разделили сеть на VLAN и связали их через trunk или L3 устройство.
Подходит для небольших и средних сетей, где важна простота и быстрый запуск.
Проблемы начинаются при масштабировании: рост количества VLAN, зависимость от STP и сложность расширения между сегментами и стойками.
show vlan brief
show interfaces trunk
show spanning-tree
show mpls forwarding-table
show mpls ldp neighbor
show ip route
show nve peers
show nve vni
show bgp l2vpn evpn summary
DNS кеш на уровне системы и «устаревшие» ответы
Сервис уже переехал, DNS запись обновлена, инфраструктура выглядит корректно. Но часть клиентов продолжает ходить на старый IP и поведение выглядит нестабильно.
resolvectl status
resolvectl statistics
dig <domain>
nslookup <domain>
getent hosts <domain>
QoS surprises в multi-tenant сетях
Даже когда вроде всё настроено, трафик может терять приоритет. CoS на L2 и DSCP на L3 не совпадают, и на trunk или overlay это особенно заметно: пакеты проходят, но VoIP, видео и контрольные протоколы начинают тормозить.
Чтобы понять, где «теряется приоритет», полезно смотреть, как устройство обрабатывает QoS. Например на Cisco:
# Как классифицируются пакеты на интерфейсе
show mls qos interface Gi1/0/1
show policy-map interface Gi1/0/1
# Какие очереди и сколько пакетов дропается
show queueing interface Gi1/0/1
# Какие class-map и DSCP сопоставления настроены
show class-map
show policy-map
# Проверка QoS на VLAN
show vlan brief
show mls qos vlan 10
Апгрейд канала не всегда ускоряет приложение
Увеличили линк с 1 Гбит/с до 10 Гбит/с, а скорость приложения почти не изменилась. Такое часто встречается, когда речь про один TCP-поток.
Дело не в канале, а в том, сколько данных поток успевает держать «в полёте».
iperf3 -c <server-ip> -P 1 # один поток — потолок не выше старого
iperf3 -c <server-ip> -P 8 # несколько потоков — канал полностью загружен