Network Admin

Зачем явно задавать root bridge в STP Если root bridge не назначен вручную, роль root получает коммутатор с наименьшим BID.

    
        После перезагрузки, добавления нового коммутатора или замены железа root может неожиданно переехать, и трафик пойдёт по другим путям. {}
    

В результате появляются неожиданные задержки в L2-сети, flapping портов, частые перестройки STP, а пользователи жалуются на «скачки» сети и потерю соединений. Иногда трафик может попасть в suboptimal path, а диагностировать причину сложнее, чем кажется на первый взгляд. Команды для проверки и диагностики на Cisco:

    
        show spanning-tree
show spanning-tree vlan 1 detail
show spanning-tree vlan 10 detail
show spanning-tree root
show spanning-tree summary
show spanning-tree interface Gi0/1 detail
show log | include STP
debug spanning-tree events{}
    

Настройка явного root bridge:

    
        spanning-tree vlan 1 root primary
spanning-tree vlan 10 root secondary
spanning-tree vlan 1 priority 24576
spanning-tree vlan 10 priority 28672{}
    

N.A.

🎉 Вас приветствует команда "Сети для всех"! 🎉 ✔️Более 300 учащихся на курсах нашей команды ✔️Более 50 выданных сертификатов ✔️Свое сообщество в Телеграмм: https://t.me/Networks_anyone 🎓 Наши курсы помогут вам: Понять основы построения и работы сетей. Научиться применять сетевые технологии на практике (VLAN, DHCP, EtherChannel, Bridge, STP, WIFI, Firewall, NAT и др.). Получить навыки, необходимые для прохождения сертификаций Cisco (CCNA и др.). Сделать первый шаг к карьере сетевого инженера, DevOps или системного администратора. Освоить администрирование таких сетевых устройств как Cisco и Mikrotik. 1️⃣ Компьютерные сети (Введение Cisco - Switching and routing) 👉 https://stepik.org/a/227855 🎯 Курс для тех, кто только хочет познакомиться с миром сетевых технологий. 2️⃣ Компьютерные сети (Продвинутый Cisco - Switching and Routing) 👉 https://stepik.org/a/230932 🎯 Подходит как для начинающих, так и для тех, кто хочет прокачать свои знания до уверенного уровня. 2️⃣Компьютерные сети (MikroTik - практическое администрирование) 👉https://stepik.org/a/260615 🎯 Администрирование всеми известного Mikrotik с видеолекциями и стендом для лабораторных работ. Если есть вопросы — пишите в чат, всегда на связи 🤝 Увидимся на занятиях! 💻🌐 С уважением! Команда "Сети для всех"! #NetworksForAll #СетиДляВсех

ARP / ND cache exhaustion

    
        В больших сетях таблицы ARP (IPv4) и Neighbor Discovery (IPv6) могут переполняться. {}
    

Это создаёт «невидимые» проблемы: линк вроде работает, а трафик теряется или идёт нестабильно, и обычные ping/traceroute иногда ничего не покажут. Симптомы переполнения ARP/ND: ⏺Периодическая недоступность отдельных хостов даже при рабочем линке. ⏺Нестабильная маршрутизация L3: соседние коммутаторы видят один и тот же MAC на разных портах. ⏺Err-disable порты из-за excessive ARP/ND traffic (особенно на access-коммутаторах). ⏺CPU spike на коммутаторе при попытках обработать множество ARP/ND записей. ⏺Flapping sessions на stateful devices (firewall, NAT), когда таблица маршрутов перестаёт корректно обновляться. Продвинутая диагностика:

    
        show arp detail vrf MGMT
show ip arp | include incomplete
show ipv6 neighbors detail
show mac address-table dynamic | include <MAC>
show processes cpu sorted | include ARP
show platform tcam utilization
show logging | include ARP{}
    

Углублённая проверка паттернов:

    
        debug arp
debug ipv6 nd
show interface Gi0/1 counters errors
show ip route vrf MGMT{}
    

И да, важно, что даже если линк физически up, проблемы ARP/ND могут разлагать L3-связь и stateful приложения. Это особенно критично для сегментов с VMs, IoT или high-density access. N.A.

ECMP pitfalls На бумаге ECMP - мечта: несколько равных путей, балансировка, более высокая пропускная способность.

    
        На деле же для stateful трафика это как «разбросанные дорожки»: пакеты одного соединения идут разными путями, и соединение начинает вести себя странно. {}
    

VPN рвётся, firewall теряет сессии, TCP-флоу скачут. 5 типичных проблем с ECMP: 1️⃣Stateful NAT или firewall - сессии рвутся из-за разных путей. 2️⃣Короткие TCP-флоу - хеш распределяет трафик неравномерно, часть линков простаивает. 3️⃣Асимметричный маршрут - входящие и исходящие пакеты идут по разным линкам. 4️⃣Динамическое добавление или удаление линков - внезапное перераспределение трафика вызывает jitter и packet loss. 5️⃣VPN-туннели - пакеты разбросаны, туннель становится нестабильным. Как проверить:

    
        show ip route
show ip cef summary
ping 10.0.0.2 repeat 100
traceroute 10.0.0.2{}
    

N.A.

Jumbo Frames и MTU mismatch Jumbo Frames позволяют передавать большие пакеты (обычно до 9000 байт) и ускоряют трафик для storage, VM migration и high-throughput приложений. Проблема возникает, если на пути хотя бы один интерфейс с меньшим MTU: пакеты падают silently или фрагментируются, что приводит к замедлению и нестабильности приложений. Признаки проблемы: ⏺TCP-сессии медленно открываются или «висят» без packet loss по ping обычного размера ⏺VM migration или storage replication тормозят ⏺traceroute показывает неожиданное поведение или «packet too big» ICMP Примеры команд на Cisco: Настройка MTU на интерфейсе:

    
        interface Gi0/1
 mtu 9216{}
    

Проверка MTU по пути:

    
        ping 10.0.0.2 size 9000 df-bit
show interfaces Gi0/1{}
    

На Linux для проверки MTU и отправки jumbo-пакетов:

    
        ip link set dev eth0 mtu 9000
ping -M do -s 8972 10.0.0.2{}
    

N.A.

UDLD aggressive mode UDLD (Unidirectional Link Detection) помогает обнаруживать односторонние линки, когда физически интерфейс up, но трафик идёт только в одну сторону.

    
        На L2 это особенно опасно: STP видит линк как рабочий, петли не детектятся, трафик теряется или ходит по странным путям.{}
    

Aggressive mode не просто логирует проблему - он переводит интерфейс в err-disable, чтобы остановить распространение проблем по сети до того, как STP или другие протоколы успеют «поймать» ошибку. Включение глобально:

    
        udld enable{}
    

На интерфейсе с агрессивным режимом:

    
        interface Gi0/1
 udld port aggressive{}
    

Для оптики и аплинков:

    
        interface TenGigabitEthernet1/1
 udld port aggressive{}
    

Проверка состояния UDLD:

    
        show udld interface
show udld neighbors{}
    

Если порт ушёл в err-disable:

    
        show errdisable recovery
errdisable recovery cause udld
errdisable recovery interval 300{}
    

N.A.

TTL Security / GTSM для BGP TTL Security (или GTSM - Generalized TTL Security Mechanism) ограничивает BGP-сессии так, чтобы соседний роутер мог «достучаться» только с ожидаемого количества хопов.

    
        Любой пакет с меньшим TTL считается подозрительным и отбрасывается. Это защищает control-plane от spoofed BGP-пакетов и DoS через подмену source IP.{}
    

⏺Часто понять отсутствие GTSM можно так: BGP-сессии рвутся при случайных ICMP или сканировании, или сосед получает пакеты с «чужим TTL», что создаёт flapping. Настройка на Cisco:

    
        router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 ttl-security hops 2{}
    

Проверка состояния BGP-сессии с GTSM:

    
        show bgp neighbors 10.0.0.2
show bgp summary{}
    

N.A.

Route leaking между VRF VRF создают иллюзию жёсткой изоляции: разные таблицы маршрутизации, разные интерфейсы, всё аккуратно разложено.

    
        Проблемы начинаются, когда маршруты из одного VRF внезапно появляются в другом - без явного intent.{}
    

Основная причина - import/export Route Target. RT это просто метка. Если один VRF экспортирует маршрут с RT, а другой его импортирует, маршрут появится, даже если сегменты логически не должны видеть друг друга. Частый сценарий тут: есть VRF PROD и MGMT. Для «временного доступа» или теста добавляют общий RT. Потом про него забывают. В итоге management-сеть внезапно получает маршруты в production или наоборот. Пример некорректной конфигурации. VRF PROD экспортирует маршруты:

    
        vrf definition PROD
 rd 65000:10
 route-target export 65000:10
 route-target export 65000:99{}
    

VRF MGMT импортирует тот же RT:

    
        vrf definition MGMT
 rd 65000:99
 route-target import 65000:99{}
    

Результат: все маршруты из PROD с RT 65000:99 появляются в MGMT. Никаких ACL, никаких предупреждений - маршруты валидны с точки зрения control plane. Снаружи это выглядит странно: пакеты доходят до «чужих» подсетей, traceroute внезапно проходит, firewall «ничего не блокирует», потому что трафик уже оказался не там, где ожидали. ⏺Как это обычно обнаруживается: — неожиданные маршруты в show ip route vrf — асимметричный трафик между VRF — утечки через shared-services VRF — доступ туда, где его быть не должно, без явного L3-соединения Проверка RT:

    
        show vrf detail
show bgp vpnv4 unicast all
show ip route vrf PROD
show ip route vrf MGMT{}
    

Особенно опасны shared RT вроде 65000:100, которые используются «для удобства». Один лишний import — и изоляция превращается в условность. N.A.

Давно планировал выучить Go, но не хотел тонуть в теории? Курс «Golang-разработчик» в Слёрме стартует 30 января. Мы создали его для бэкенд-разработчиков и DevOps-инженеров, которые хотят сменить стек или научиться писать инфраструктурные инструменты на Go. Важно: курс не для новичков. Почему этот курс дает результат: • 80% обучения — это практика. Вместо скучных лекций вы получите 53 часа прикладной работы. • Спикер-практик. Обучение ведет Виталий Лихачев, SRE в Booking.com. • Реальный проект в портфолио. Ты с нуля спроектируешь отказоустойчивый сервис на выбор: онлайн-банк, мессенджер или файловое хранилище. Попробуй продукт бесплатно: мы открываем демо-доступ на 3 дня. Ты сможешь оценить платформу, подачу материала и решить, подходит ли тебе темп обучения, прежде чем платить.

👉 Занять место или получить демо-доступ 👉 Проверь свои знания и получи полезные материалы от экспертов рынка.

DHCP Snooping + IP Source Guard DHCP Snooping позволяет коммутатору понять, какие IP-адреса легитимны, а какие нет. Без этого любой хост может поднять rogue DHCP или подменить IP и начать MITM внутри VLAN. ⏺Типичный симптом: сеть «работает», но клиенты периодически получают странные шлюзы, пропадает доступ или трафик уходит не туда. DHCP Snooping строит binding-таблицу IP–MAC–VLAN–port и делает её источником правды для других механизмов защиты. Включение DHCP Snooping глобально и для VLAN: ip dhcp snooping ip dhcp snooping vlan 10,20 Настройка trusted-портов (uplink к DHCP-серверу или L3): interface Gi0/24 ip dhcp snooping trust Ограничение скорости DHCP-запросов на access-портах: interface Gi0/3 ip dhcp snooping limit rate 15 Проверка binding-таблицы: show ip dhcp snooping binding IP Source Guard использует эту таблицу и блокирует трафик с поддельным IP. Включение на access-порте: interface Gi0/3 ip verify source Проверка статуса: show ip verify source Связка DHCP Snooping + IP Source Guard предотвращает IP spoofing и rogue DHCP на уровне L2, без участия firewall или L3-логики. N.A.