Network Admin

Почему после замены коммутатора половина сети перестала работать Заменили коммутатор, всё подключили, часть хостов работает, часть нет. Физически всё поднято, линки горят. Начинается час диагностики. Обычно проблема в одном из трёх Новый коммутатор пришёл с дефолтной конфигурацией. Все порты в VLAN 1, транки не настроены. Хосты которые работают находятся в VLAN 1 и просто повезло. Остальные VLANы не существуют на новом железе.

show vlan brief
show interfaces trunk

Если VLANы не созданы или транк не поднят, вот оно. STP выбрал новый коммутатор Root Bridge потому что у него меньший MAC или приоритет не был выставлен. Топология пересчиталась, часть портов ушла в blocking. Хосты за этими портами недоступны.

show spanning-tree
show spanning-tree detail | include root

Смотрим кто стал Root и почему. Если новый коммутатор, выставляем приоритет обратно на нужное железо:

spanning-tree vlan 1 priority 4096

Старый коммутатор работал с negotiated duplex или speed, новый договорился иначе. Часть портов поднялась в half-duplex, отсюда коллизии и потери.

show interfaces Gi0/1 | include duplex

Если видим half-duplex там где не должно быть, фиксим явно:

interface Gi0/1
 duplex full
 speed 1000

N.A.

У FirstVDS проходит акция «Битва Гиков» Прямо сейчас можно заказать новый VDS со скидкой до 30%, подключить спецтариф с фиксированной ценой на всё время использования сервера, а заодно поучаствовать в онлайн‑игре и розыгрыше призов. Среди призов — PS5 Pro 2 ТБ, Steam Deck OLED 512 ГБ, и сертификаты на баланс. За призами! 🎮 #реклама О рекламодателе

Как ведёт себя сеть при split-brain в HSRP Два роутера в HSRP обмениваются hello-пакетами каждые 3 секунды. Если связь между ними пропадает, каждый решает что сосед умер и становится Active.

Оба держат один виртуальный IP, оба отвечают на ARP-запросы своим MAC.

Клиенты в этот момент делятся на два лагеря в зависимости от того чей ARP-ответ пришёл последним. Половина трафика идёт через один роутер, половина через другой. Если маршруты на них разные, часть сессий рвётся, часть работает. Отлаживать это неприятно потому что проблема плавающая и воспроизводится через раз. Смотрим состояние HSRP и кто сейчас Active:

show standby brief
show standby

Если оба показывают Active, split-brain в действии. Проверяем доступность между роутерами:

ping <IP соседнего роутера> source <интерфейс HSRP>

Чаще всего причина не в роутерах а в коммутаторе между ними: упал транк, слетел VLAN, сработал STP. Hello-пакеты не проходят, оба уходят в Active.

show interfaces trunk
show spanning-tree vlan <ID>

N.A.

Что происходит когда два DHCP-сервера отвечают на один запрос

Подключил кто-то в офисе домашний роутер к корпоративной сети, или подняли новый DHCP и старый не выключили. Оба слышат broadcast, оба отвечают.

Клиент берёт первый пришедший offer. Не правильный, а именно первый. Если левый сервер ответил быстрее, клиент получает адрес из чужого пула, чужой шлюз, чужой DNS. Настроен, но в сеть не ходит или ходит куда не надо. Хуже когда пулы пересекаются: два клиента получают одинаковый IP и оба теряют связь. Без каких-либо ошибок на их стороне. Смотрим кто вообще отвечает на DHCP в сегменте:

sudo tcpdump -i eth0 port 67 or port 68 -n
nmap --script broadcast-dhcp-discover

Если в выводе несколько Server Identifier, проблема подтверждена. Лечится DHCP Snooping на коммутаторе: офферы разрешены только с доверенных портов, со всех остальных дропаются:

ip dhcp snooping
ip dhcp snooping vlan 10

interface Gi0/1
 ip dhcp snooping trust

interface range Gi0/2 - 24
 no ip dhcp snooping trust

N.A.

Ethernet OAM (802.1ag) с Linux и FRRouting Ethernet OAM (Operations, Administration and Maintenance) по стандарту 802.1ag позволяет контролировать доступность и состояние линков на уровне L2. На Linux можно использовать утилиты eth-oam для генерации OAM-сообщений (Continuity Check Messages, Loopback, Link Trace). Пример проверки линка:

# Проверка доступности линка между хостами через CFM Continuity Check
eth-oam-ccm -i eth0 -m 1 -t 10

Где -i — интерфейс, -m — Maintenance Association ID, -t — интервал в секундах. Для интеграции с FRRouting можно настроить уведомления о недоступности линка и динамически изменять маршруты. Например, при падении линка BGP-сессия будет разорвана и маршруты уйдут на резервный путь. Дополнительно можно использовать Loopback и Link Trace для диагностики проблем:

# Loopback запрос к соседнему устройству
eth-oam-lb -i eth0 -m 1

# Trace путь до узла через L2
eth-oam-lt -i eth0 -m 1 -d <MAC-адрес-соседа>

N.A.

Что такое IX и как трафик идёт внутри него IX (Internet Exchange) это физическая точка где провайдеры, CDN и крупные сети подключаются друг к другу напрямую. Вместо того чтобы гонять трафик через транзитного провайдера и платить за каждый гигабит, участники обмениваются трафиком напрямую и бесплатно между собой.

Крупнейшие точки обмена: DE-CIX во Франкфурте, AMS-IX в Амстердаме, MSK-IX в Москве. Через DE-CIX проходит больше 10 Тбит/с в пике.

Как устроено внутри Физически IX это один большой коммутатор (или несколько связанных), к которому все участники подключают свои роутеры. Эта общая среда называется IXP fabric. Каждый участник получает порт и IP-адрес в общей подсети IX. Дальше всё через BGP. Каждый участник поднимает BGP-сессии с теми с кем хочет обмениваться трафиком, анонсирует свои префиксы и получает чужие. Никакой автоматики, только явные пиринговые договорённости. Route Server Чтобы не поднимать сотни BGP-сессий с каждым участником отдельно, большинство IX предоставляют Route Server. Подключаешься к одному RS, получаешь маршруты от всех участников кто тоже подключён к RS. Можно фильтровать что принимать и что анонсировать.

router bgp 65001
 neighbor 193.178.185.1 remote-as 65000
 neighbor 193.178.185.1 description MSK-IX Route Server

Как трафик идёт внутри Пакет от пользователя провайдера А до сервера в сети провайдера Б: роутер А смотрит BGP-таблицу, видит что префикс Б получен через IX, отправляет пакет напрямую на роутер Б через IXP fabric. Транзитный провайдер не участвует, задержка меньше, стоимость ниже. N.A.

Почему MTU 1500 в реальности никогда не 1500. Часть 2 Почему фрагментация не всегда спасает: Когда пакет не влезает в MTU промежуточного узла, тот должен отправить отправителю ICMP Fragmentation Needed.

Отправитель получает сообщение, уменьшает размер сегмента и пробует снова. Это называется Path MTU Discovery и работает хорошо в теории.

На практике многие сети и файерволы блокируют ICMP полностью. Сообщение Fragmentation Needed не доходит, отправитель продолжает слать большие пакеты, они дропаются без каких-либо уведомлений. Симптом характерный: мелкие запросы проходят нормально, крупные зависают или обрываются. Проверяем реальный Path MTU до хоста и тестируем конкретный размер пакета:

tracepath 8.8.8.8
ping -M do -s 1400 8.8.8.8

Если ping с -M do (don’t fragment) падает на определённом размере, MTU на пути именно там. Как фиксить Выставляем MTU вручную на туннельном интерфейсе:

ip link set dev tun0 mtu 1420

Для PPPoE на Cisco MSS clamp ограничивает размер TCP-сегментов на уровне роутера, не давая клиентам использовать значения выше допустимого:

interface Dialer0
 ip tcp adjust-mss 1452

N.A.

Как работает TCAM и почему правила ACL влияют на производительность железа Обычная RAM ищет данные по адресу: дай адрес, получи значение. TCAM работает наоборот: дай значение, получи результат за один такт. Content Addressable Memory, и T означает Ternary: каждый бит может быть 0, 1 или X (don’t care). Именно X позволяет матчить префиксы и маски.

Благодаря этому коммутатор находит совпадение для любого пакета за одну операцию, независимо от размера таблицы. Именно поэтому железо форвардит трафик на линейной скорости.

Почему TCAM дорогой и ограниченный TCAM потребляет в 5-10 раз больше энергии и площади чристалла чем обычная SRAM. Поэтому его мало: на типичном enterprise-коммутаторе несколько десятков тысяч записей, и они делятся между маршрутами, ACL, QoS и MAC-таблицей. Посмотреть сколько TCAM осталось на Cisco:

show platform tcam utilization
show sdm prefer

Как ACL влияют на TCAM Каждая строка ACL это одна или несколько записей в TCAM. Правило с диапазоном портов разбивается на несколько записей потому что TCAM не умеет в диапазоны нативно. Правило permit tcp any any gt 1024 может развернуться в десятки записей. На больших ACL это незаметно, но на коммутаторах с маленьким TCAM таблица заканчивается и новые правила просто не применяются.

show ip access-lists
show platform hardware capacity

Что делать при нехватке Меняем SDM profile чтобы перераспределить TCAM между функциями. Например отдать больше под ACL за счёт MAC-таблицы:

sdm prefer acl
reload

N.A.

Почему MTU 1500 в реальности никогда не 1500? MTU 1500 это максимальный размер payload в Ethernet-фрейме. Цифра знакомая, но в реальной сети между твоим приложением и получателем почти всегда есть что-то, что откусывает от этого значения.

Иногда немного, иногда достаточно чтобы сломать крупные передачи.

Туннели Любой туннель оборачивает оригинальный пакет в новый и добавляет свои заголовки. GRE забирает 24 байта, IPsec в tunnel mode от 50 до 70 байт в зависимости от алгоритмов шифрования, WireGuard 60 байт, VXLAN 50 байт. Если на пути несколько туннелей, байты суммируются. Итоговый MTU внутри может оказаться 1400 и ниже, при этом интерфейс снаружи честно показывает 1500. PPPoE

PPPoE используют большинство провайдеров на последней миле. Протокол добавляет 8 байт заголовка к каждому фрейму, реальный MTU на интерфейсе становится 1492. 

Если роутер не учитывает это и анонсирует клиентам MSS под 1500, крупные TCP-сегменты начинают фрагментироваться или молча дропаться на пути. Делаем вторую часть с более подробным разбором на практике? N.A.

Как коммутатор строит CAM-таблицу и что происходит при переполнении CAM-таблица это то, за счёт чего коммутатор работает как коммутатор, а не как хаб. Без неё каждый фрейм уходил бы на все порты. Как строится таблица Коммутатор учится пассивно: когда фрейм приходит на порт, смотрит на source MAC и записывает на каком порту он находится. Когда нужно отправить фрейм, ищет destination MAC. Нашёл, отправил на конкретный порт. Не нашёл, flooding на все порты кроме входящего. Записи живут 300 секунд по умолчанию, потом удаляются.

show mac address-table
show mac address-table aging-time

Что происходит при переполнении CAM хранится в аппаратной памяти фиксированного размера. Когда таблица полна, новые записи не добавляются и любой фрейм с неизвестным MAC уходит флудом. Коммутатор деградирует до хаба. На этом построена атака MAC flooding: генерируются фреймы с тысячами случайных source MAC, таблица забивается, и весь трафик начинает идти на порт атакующего тоже. Защита Port Security ограничивает количество MAC на порту:

interface Gi0/1
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict

show port-security interface Gi0/1

N.A.

Proxy ARP: когда роутер отвечает на чужие ARP-запросы Обычно на ARP-запрос “кто такой 192.168.1.50?” отвечает сам хост с этим IP. Proxy ARP меняет это поведение: роутер перехватывает запрос и отвечает своим MAC-адресом, как будто этот IP находится на нём. Хост отправляет трафик на роутер, роутер форвардит дальше.

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

Где это реально используется сейчас В облаках и гипервизорах Proxy ARP используется постоянно. Когда виртуальная машина получает IP из одной подсети, а физически находится на хосте в другой, гипервизор отвечает на ARP-запросы за неё. VMware, KVM с определёнными сетевыми конфигурациями, AWS при определённых настройках VPC, всё это Proxy ARP под капотом. Когда это ломает сеть Если Proxy ARP включён на роутере по умолчанию (на Cisco он включён), а в сети несколько роутеров, начинается хаос. Несколько устройств отвечают на один ARP-запрос разными MAC-адресами, трафик уходит не туда, сессии рвутся. Вторая проблема: хосты кешируют ARP-ответы. Если роутер ответил за чужой IP, хост будет слать трафик через него даже когда прямой маршрут появился. Проверяем на Cisco:

show ip interface Gi0/0 | include proxy

Отключаем если не нужен:

interface Gi0/0
 no ip proxy-arp

На Linux:

cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
echo 0 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

N.A.

Anycast: как это работает за пределами DNS Anycast это когда один и тот же IP-адрес анонсируется из нескольких точек одновременно. Клиент отправляет пакет, сеть сама выбирает ближайший узел по метрикам BGP.

Никакого DNS, никакого балансировщика между клиентом и сервером.

Большинство знает anycast по DNS: 8.8.8.8 это не один сервер, а сотни точек по всему миру. Но этим применение не ограничивается. CDN используют anycast чтобы отдавать статику с ближайшего к пользователю POP-а. Cloudflare, Fastly, Akamai, все работают так. Пользователь в Берлине получает контент из Франкфурта, а не из Нью-Йорка, хотя обращается к одному IP.

DDoS-mitigation строится на том же принципе. Атака распределяется между всеми точками присутствия, ни одна не получает весь объём трафика.

NTP-серверы пула pool.ntp.org тоже anycast, клиент всегда попадает на географически близкий узел без какой-либо логики на своей стороне. Как анонсируется anycast-префикс Каждая точка присутствия поднимает BGP-сессию с апстримом и анонсирует один и тот же префикс:

router bgp 65001
 network 192.0.2.0 mask 255.255.255.0

ip route 192.0.2.0 255.255.255.0 Null0

Маршрут в Null0 нужен чтобы BGP принял префикс для анонса, реальный трафик обрабатывается локально. N.A.

DevSecMLOps: как безопасно внедрять ИИ в процессы разработки и эксплуатации. Открытый урок курса «Внедрение и работа в DevSecOps» ИИ уже вошёл в рабочие процессы команд разработки, эксплуатации и информационной безопасности. Но вместе с ускорением работы он приносит и новые риски: утечки данных, небезопасное обращение с моделями и зависимостями, ошибки при встраивании инструментов ИИ в конвейеры и внутренние сервисы. Поэтому вопрос уже не в том, использовать ИИ или нет, а в том, как делать это управляемо и безопасно. 📅 На открытом уроке 18.05.2026 в 20:00 разберём, как смотреть на ИИ не только как на полезный инструмент, но и как на новый элемент ландшафта угроз. Поговорим о том, какие риски возникают при встраивании ИИ в продукты, внутренние сервисы и процессы разработки, как принципы DevSecOps применяются к таким сценариям и какие меры стоит предусмотреть ещё до внедрения. Обсудим моделирование угроз, контроль доступа, работу с данными, безопасные проверки в процессе разработки и подходы, которые помогают использовать ИИ без роста уязвимости системы.

Урок не для тех, кто считает ИИ «просто ещё одной утилитой», не думает о рисках данных и зависимостей или хочет встроить ИИ в процессы без пересмотра модели угроз и защитных мер.

👉 Записаться: https://otus.pw/ISqY/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576 (

BGP Blackholing: как быстро дропать DDoS-трафик на уровне сети Когда на сервер идёт DDoS, стандартный ответ: заблокировать на фаерволе. Сложность в том, что трафик всё равно доходит до твоего канала и забивает его. Blackholing решает это на уровень выше, трафик дропается ещё у провайдера или на границе сети. Идея простая: анонсируешь BGP-соседу маршрут до атакуемого IP с community-тегом, который говорит “дропай этот трафик”. Провайдер получает анонс и перенаправляет трафик в null на своей стороне до того как он дошёл до тебя. Как это выглядит на практике Создаём статический маршрут в null и анонсируем его через BGP с нужным community (значение уточняется у провайдера, обычно это RTBH community):

ip route 203.0.113.5 255.255.255.255 Null0

route-map BLACKHOLE permit 10
 set community 65535:666 additive
 set local-preference 200

router bgp 65001
 neighbor 198.51.100.1 route-map BLACKHOLE out
 network 203.0.113.5 mask 255.255.255.255

Проверяем что маршрут анонсируется соседу:

show bgp ipv4 unicast 203.0.113.5
show bgp neighbors 198.51.100.1 advertised-routes

Убираем blackhole когда атака закончилась

no ip route 203.0.113.5 255.255.255.255 Null0
clear ip bgp 198.51.100.1 soft out

N.A.

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

Проверяем TCN, частые topology change говорят о нестабильном линке или петле:

show spanning-tree detail | include topology change

⏺Что делать? Если порт ведёт к конечному устройству (PC, сервер, принтер), включаем PortFast. Порт сразу переходит в Forwarding, минуя Listening/Learning:

interface Gi0/1
 spanning-tree portfast

Если TCN генерирует конкретный порт, включаем BPDU Guard. При получении BPDU порт уходит в err-disabled вместо того чтобы ломать топологию:

interface Gi0/1
 spanning-tree bpduguard enable

Глобально для всех PortFast-портов:

spanning-tree portfast default
spanning-tree portfast bpduguard default

N.A.

📂Как правильно документировать сеть, чтобы не потерять конфиги Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам. 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   | веб-сервер

3️⃣Version control: Сохраняем конфиги в Git. Каждый коммит с комментарием: что и зачем изменилось.

git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"

4️⃣Визуализация топологии: Diagram-as-code (Mermaid/Graphviz) или инструменты типа NetBox/Draw.io. Пример Mermaid:

graph TD
    R1 --> SW1
    SW1 --> Server1
    SW1 --> Server2

5️⃣Автоматизация и backup: Скрипты для снятия конфигов и их сохранения в репозиторий или на NAS. Проверка актуальности backup. ✅ Полезные команды для контроля

git log --oneline --graph   # история изменений
diff old_config new_config  # что изменилось
ping 10.0.1.2              # проверить доступность после изменений

N.A.

Bonding на Linux: mode 802.3ad и проверка активных линков Bonding в Linux это аналог LAG на уровне ОС. Mode 802.3ad (LACP) объединяет интерфейсы в агрегат с динамическим согласованием, как на Cisco mode active. Для работы нужен пакет ifenslave и загруженный модуль bonding:

modprobe bonding
apt install ifenslave

Настройка через systemd-networkd Создаём bond-интерфейс:

# /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

Назначаем IP на 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

Покажет режим, активные интерфейсы, состояние LACP и MII каждого слейва. Если слейв показывает MII Status: down, физический линк не поднят или коммутатор не согласовал LACP. Быстрая проверка через ip:

ip link show bond0
ip -d link show bond0

N.A.

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

LACP (active инициирует согласование, passive ждёт):

interface range Gi0/1 - 2
 channel-group 1 mode active

Проверка агрегата Смотрим статус Port-Channel и какие порты в него входят:

show etherchannel summary
show lacp neighbor

В выводе show etherchannel summary флаги говорят всё: P - порт в бандле, D - порт упал, S - suspended. Если видишь I (individual) вместо P, порт не попал в агрегат, скорее всего несовпадение настроек speed/duplex или native VLAN. N.A.

КАК ПИРАТОВ С МИЛЛИОНАМИ ВЗЯЛИ ЧЕРЕЗ… ТЕРМОМЕТР👻 👀 В Испании накрыли одну из крупнейших пиратских платформ с мангой. Ребята годами крутили трафик на аниме, собирали сотни миллионов просмотров и зарабатывали на 18+ рекламных баннерах миллионы. Никаких подписок и донатов они не просили, просто с*кс реклама. И деньги шли стабильно, всё выглядело как идеально выстроенная схема. Но проблемы начались не в интернете. Правообладатели наняли специалистов, те аккуратно собрали информацию: где хостятся сайты, кто за ними стоит, где живут админы. Передали всё полиции и дальше уже дело техники. Они пришли к ним домой и обнаружили там простой термометр. А из него достали флешки с холодными криптокошельками почти на полмиллиона долларов! ⚠️ То есть люди, которые умели зарабатывать миллионы в интернете, слились на базовой вещи — физической безопасности и хранении активов. И это не единичный случай. Сейчас всё чаще работают не через взлом, а через деанон. Тебя находят → приходят → забирают всё. И если ты думаешь, что «ну я же просто храню крипту», то это ровно до первого интереса к тебе. Хорошая новость — от этого можно защищаться. Потому что есть конкретные инструменты: 🟢 двойное дно 🟢 duress-пароль 🟢 криптоконтейнеры 🟢 убедительная легенда (правдоподобное отрицание) 🟢 Panic Button - уничтожит все при верном сигнале и многие другие Почитать про эти инструменты можно по ссылке: 🦔 CyberYozh

Wireshark фильтры для диагностики VLAN-трафика Быстрая шпаргалка для тех, кто разбирает проблемы на trunk-портах или отлавливает трафик конкретного VLAN. Базовые фильтры Показать все 802.1Q фреймы, сузить до конкретного VLAN ID или до трафика одного хоста внутри него. Отправная точка для любой диагностики:

vlan
vlan.id == 10
vlan.id == 10 && ip.addr == 192.168.10.5

ARP, DHCP, STP ARP помогает отловить конфликты IP и посмотреть кто отвечает на запросы. DHCP покажет, доходят ли Discover-пакеты до сервера. STP нужен когда подозреваешь петлю или нестабильную топологию:

vlan.id == 10 && arp
vlan.id == 10 && bootp
vlan.id == 10 && stp

Трафик между двумя хостами и очистка от служебного Первый фильтр изолирует сессию между конкретными хостами. Второй убирает CDP, LLDP и STP, когда нужно смотреть только на пользовательский трафик без шума:

vlan.id == 20 && ip.addr == 192.168.20.1 && ip.addr == 192.168.20.2
vlan.id == 10 && !stp && !cdp && !lldp

Double-tag и QoS Первый фильтр ловит QinQ-фреймы или признаки VLAN hopping, когда внутри тегированного фрейма есть ещё один тег. Второй фильтрует по значению CoS, полезно при диагностике приоритизации трафика:

vlan.id == 100 && vlan
vlan.priority == 5

N.A.