Network Admin

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{}
    

Сохрани список всех активных VLAN - это твой эталон. 2️⃣Переводи коммутаторы в VTP Transparent по одному, начиная с краёв сети

    
        vtp mode transparent{}
    

Transparent не синхронизирует VLAN с другими, но передаёт VTP-объявления дальше - сеть не ломается сразу. 3️⃣Убеждаешься, что VLAN-база на каждом свиче совпадает с эталоном

    
        show vlan brief{}
    

4️⃣Когда все переведены в Transparent - можно отключить VTP полностью (VTP v3)

    
        vtp mode off{}
    

В v1/v2 режима off нет, Transparent - финальная точка. 5️⃣ Дальше VLAN управляются вручную на каждом свиче или через Ansible/Netmiko. ⚡️ Revision number обнуляется при смене VTP domain или переключении в Transparent. Если срочно нужно обезвредить «опасный» свич перед подключением - меняй domain name на любой другой. N.A.

Traceroute не совпадает с реальным путём Сервис ведёт себя так, будто трафик идёт по одному маршруту, но traceroute показывает совсем другую картину. При этом ping может быть стабильным, а задержки появляться “внезапно” и без логики.

    
        traceroute <ip>{}
    

⏺Дело в том, что traceroute показывает не путь пакета, а поведение промежуточных узлов, которые могут по-разному отвечать на TTL-expired. В реальности трафик часто идёт через ECMP или policy routing, которые в traceroute просто не видны.

    
        ip route get <ip>{}
    

Здесь обычно всплывает реальный next-hop для конкретного пакета — и он может отличаться от того, что ожидается из схемы сети или из traceroute-вывода. Иногда расхождение усиливается из-за балансировки на уровне ядра или оборудования, когда разные потоки уходят по разным линкам, а traceroute показывает только один из возможных путей.

    
        mtr -T <ip>{}
    

TCP-traceroute часто даёт более близкую к реальности картину, потому что имитирует реальный трафик, а не ICMP-ответы.

    
        tracepath <ip>{}
    

N.A.

5 команд, которые реально помогают ловить “невидимые” сетевые проблемы 1️⃣TCP-состояние и скрытые retransmit’ы Когда сервис “живой”, но всё тормозит - обычные проверки ничего не показывают. Тут полезно смотреть, что происходит прямо в TCP-очередях.

    
        ss -ti state all{}
    

Сразу видно RTT, retrans, cwnd - вещи, которые обычно не попадают ни в метрики, ни в логи. 2️⃣Реальное поведение маршрута ядра (а не “как должно быть”) Иногда проблема не в сети, а в том, куда система на самом деле отправляет трафик.

    
        ip route get <ip>{}
    

Показывает конкретный интерфейс, source IP и next-hop для одного пакета - часто всплывает неожиданный путь. 3️⃣Где именно ломается соединение (DNS / connect / TLS / HTTP) Когда всё “медленно”, важно понять, на каком этапе зависает запрос.

    
        curl -w "@-" -o /dev/null -s <url>{}
    

Показывает breakdown по времени: DNS, connect, TLS, first byte. Быстро отделяет сеть от приложения. 4️⃣Потери, которые не видно через ping ICMP может быть чистым, а TCP уже страдает. Нужен более честный взгляд на поток.

    
        mtr -T -P 443 <host>{}
    

TCP-traceroute часто показывает деградацию там, где обычный ICMP ничего не замечает. 5️⃣Реальная картина очередей и backpressure Когда система “не падает, но не отвечает” - это почти всегда очереди.

    
        ss -ltnp{}
    

Смотришь backlog, количество established, и становится видно, где начинается давление — на accept, kernel или приложение. N.A.

Неравномерное распределение трафика LB ⏺Снаружи всё выглядит нормально: LB живой, backend’ы подняты, трафик есть, но один инстанс стабильно перегружен, а остальные почти пустые. Распределение часто ломается не на уровне новых подключений, а на уровне уже установленных сессий и того, как они “прилипают” к backend’ам.

    
        ss -s{}
    

⏺По общей картине видно, что соединения есть, но это ничего не говорит о том, как они распределены между нодами и как долго живут. Если разложить соединения глубже, становится заметно, что часть клиентов держит длинные сессии и фактически закрепляется за конкретным backend’ом.

    
        ss -tn sport = :80{}
    

⏺И именно эти долгоживущие соединения начинают создавать перекос: новые запросы уже не успевают “выровнять” баланс. Иногда эффект усиливается просто из-за того, что клиенты создают разное количество соединений и неравномерно их переиспользуют.

    
        curl -I <url>{}
    

⏺При повторных запросах можно заметить, что ответы стабильно приходят с одних и тех же backend’ов, даже если ожидается равномерное распределение.

    
        ipvsadm -Ln{}
    

На этом уровне уже видно реальную картину: LB не распределяет каждый запрос заново, а работает с уже закреплёнными потоками, из-за чего часть нод оказывается перегруженной просто статистически. N.A.

Service работает через IP, не через DNS Сервис открывается по IP нормально, но по доменному имени начинает вести себя странно: таймауты, разные ответы, иногда вообще “не тот” backend. Часто это, когда клиент и DNS живут разной жизнью: IP уже поменялся, а часть систем продолжает ходить по старым записям.

    
        resolvectl status{}
    

Здесь часто видно, что разные интерфейсы или сети используют разные резолверы, и ответы начинают расходиться по источникам. Дальше полезно посмотреть, что реально возвращается не “в теории”, а в контексте системы.

    
        getent hosts <domain>{}
    

Иногда всплывает, что домен резолвится в несколько IP, и выбор происходит неочевидно - часть клиентов стабильно попадает на один адрес, часть на другой.

    
        ip route get <ip>{}
    

И уже здесь становится заметно, что IP-доступ стабильный, а доменный - нет, потому что DNS фактически раскидывает трафик по разным путям.

    
        curl -v --resolve <domain>:443:<ip> https://<domain>{}
    

Когда вручную фиксируется IP, поведение становится стабильным - и это обычно указывает, что расхождение происходит именно на этапе резолвинга и кеширования, а не в самом сервисе. N.A.

Разное поведение DNS у разных клиентов

    
        Сервис у части пользователей работает нормально, у части периодически “проваливается” или уходит в странные задержки. {}
    

Снаружи всё выглядит одинаково, но поведение разъезжается по группам клиентов. Первое, что обычно всплывает — не сами ответы DNS, а то, как они кешируются и переиспользуются в системе.

    
        resolvectl query <domain>{}
    

Тут уже видно, что один и тот же домен может жить разными TTL-состояниями в зависимости от клиента и момента запроса, и это начинает разносить поведение по времени. Дальше полезно посмотреть не “что резолвится”, а как именно система выбирает адреса и в каком порядке.

    
        getent ahostsv4 <domain>{}
    

Иногда всплывает, что порядок IP разный между клиентами, и это уже влияет на то, какой backend они фактически выбирают, даже если DNS “одинаковый”. Следующий слой - системные кеши и библиотечный резолвинг, который вообще не виден через обычные проверки.

    
        strace -e trace=network -f curl -s <url>{}
    

Здесь часто видно, что разные клиенты делают разное количество попыток резолвинга или уходят в разные источники, хотя запрос формально один и тот же. N.A.

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{}
    

2️⃣Связываем их

    
        vlan 100
 private-vlan association 101{}
    

3️⃣Настраиваем promiscuous порт (uplink)

    
        interface Gi1/0/1
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 100 101{}
    

4️⃣Настраиваем обычные клиентские порты (isolated)

    
        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{}
    

N.A.

Почему “не видно проблему” в сети, пока не посмотришь состояние TCP очередей Иногда сервис не падает, но начинает “вязнуть”: запросы идут, ответы есть, но задержки растут без очевидной причины. В таких случаях полезно смотреть не соединения как факт, а их внутреннее состояние в ядре.

    
        ss -tin state established{}
    

Здесь часто всплывают признаки деградации: растущий rtt, повторные передачи, перегруженные соединения, которые внешне выглядят как обычный HTTP-трафик. Почему “всё открывается”, но часть запросов теряется Бывает ситуация, когда сеть вроде бы живая, но часть пакетов просто не доходит. Это не видно на уровне приложения, пока не посмотреть статистику интерфейса.

    
        ip -s link show <iface>{}
    

Потери, ошибки и dropped packets часто оказываются уже на уровне NIC или драйвера, а не где-то “в сети”. Почему DNS “работает”, но поведение разное у клиентов Иногда проблема вообще не в резолвинге как таковом, а в том, как ядро кеширует и повторно использует результаты.

    
        getent ahosts <domain>{}
    

В отличие от dig, здесь видно реальное поведение резолвинга в контексте системы, а не абстрактного запроса. N.A.

Почему сервис “умирает” после включения retry Retry включили на клиенте или gateway, и вместо стабилизации получили рост нагрузки и ощущение деградации, хотя инфраструктура не менялась.

    
        curl -v <url>{}
    

Сразу видно, что один пользовательский запрос начинает превращаться в несколько попыток. Они накладываются друг на друга и создают лишний трафик там, где его не было. Дальше это проявляется как рост latency и “тяжёлые” ответы, даже если сервис формально не падает.

    
        mtr <ip>{}
    

Иногда кажется, что проблема в сети, но фактически это сам retry разгоняет нагрузку при любых задержках. Если посмотреть на уровень пакетов:

    
        tcpdump -i <iface>{}
    

видно, как одинаковые запросы уходят пачками вместо одного нормального потока. На HTTP уровне это превращается в повторяющиеся обращения к одному endpoint без необходимости.

    
        curl -I <url>{}
    

И в итоге система деградирует не из-за ошибок, а из-за того, что retry усиливает любую задержку в несколько раз. N.A.

Появился удобный AI-инструмент для подготовки к найму и прохождения собеседований - Sobes Copilot. Это ассистент, который помогает прямо во время интервью: слушает диалог, распознаёт речь в реальном времени и подсказывает, как лучше ответить. Работает в Zoom, Google Meet, Teams, VK Calls и других платформах, и не виден при демонстрации экрана. Что есть в Sobes Copilot: • Подсказки в реальном времени во время собеседований • Пост-анализ интервью - сервис разбирает прошедший созвон, выделяет сильные и слабые места, удачные формулировки и зоны роста • Генератор и улучшение резюме - помогает собрать сильное резюме под конкретную вакансию • Мок-собеседования (и System Design) - тренировки с ИИ, приближённые к реальным интервью • Авто-отклики на HH - автоматизируют массовую подачу на вакансии по заданным фильтрам Если хочешь проходить собеседования спокойнее, увереннее и системнее - посмотри, что умеет Sobes Copilot.