Диагностика VLAN leakage

VLAN leakage - ситуация, когда трафик из одного VLAN неожиданно появляется в другом. Обычно это не «баг», а следствие ошибок в trunk-настройках, native VLAN или некорректного tagging’а.

⏺Основные источники VLAN leakage

Чаще всего проблема возникает из-за несовпадения native VLAN на транке, когда untagged трафик интерпретируется по-разному на соседних устройствах.

Второй частый сценарий - trunk mismatch: VLAN разрешён с одной стороны, но не с другой. Третья причина - устройства или гипервизоры, которые отправляют трафик без тегов там, где ожидается tagged frame.

⏺Проверка trunk-интерфейсов

show interfaces trunk

Можно увидеть:
• какие интерфейсы реально работают в trunk
• native VLAN
• список allowed VLAN

show running-config interface Gi0/24

Проверка, явно ли задан switchport trunk native vlan и allowed vlan.

⏺Проверка native VLAN consistency

show interfaces Gi0/24 switchport

Отображает operational native VLAN. Именно она важна, а не только конфигурация.

show spanning-tree vlan <VLAN_ID>

Иногда leakage проявляется через неожиданные STP-события в «чужом» VLAN.

⏺Поиск VLAN mismatch и неожиданных MAC

show mac address-table vlan <VLAN_ID>

Если в VLAN появляются MAC-адреса, которые физически должны быть в другом сегменте — это прямой индикатор leakage.

show mac address-table interface Gi0/24

Помогает понять, какие VLAN реально приходят по конкретному транку.

⏺Проверка tagging ошибок и untagged трафика

show interfaces Gi0/24 counters errors

Ошибки encapsulation и drops иногда указывают на некорректный tagging.

show vlan brief

Позволяет проверить, не используется ли native VLAN как рабочий пользовательский VLAN, что сильно повышает риск leakage.

N.A.

Что происходит при конфликте IP-адресов

IP-конфликт - это ситуация, когда два устройства в одной подсети считают один и тот же адрес «своим».

На бумаге всё выглядит корректно: маска правильная, gateway задан, линк зелёный. Но на уровне ARP начинается борьба за право отвечать на запросы.

Когда кто-то в сети спрашивает: «Кто владелец IP 192.168.1.10?», отвечают оба устройства. В ARP-кэше сохраняется MAC того, кто ответил последним. Через некоторое время ответит второй, и запись перепишется. Трафик начнёт уходить уже к нему.

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

Что в этот момент происходит в сети

ARP-таблицы на разных устройствах начинают «мигать»: один и тот же IP связан с разными MAC-адресами.

На коммутаторе можно увидеть, что трафик для этого IP приходит то с одного порта, то с другого.

Если конфликт затрагивает gateway или сервер - последствия становятся заметными сразу: сессии рвутся, NAT ломается, сервисы становятся непредсказуемыми.

Почему это выглядит случайно

Потому что всё зависит от того, чья ARP-ответная гонка победила в конкретный момент. Пока в кэше «правильный» MAC - всё работает. Как только запись обновилась, трафик уходит к другому устройству.

N.A.

Почему трафик концентрируется на одном линке в агрегированных каналах

Даже когда в сети настроено несколько линков через LACP / Port-Channel или ECMP, трафик иногда упорно идёт по одному физическому каналу. Интерфейсы подняты, агрегирование активно, но один линк перегружен, а остальные почти пустые.

Такое поведение часто вводит в заблуждение - кажется, что резервные линки «не работают», хотя на самом деле алгоритм распределения трафика делает именно так.

↗️Как работает распределение трафика

Балансировка в LACP и ECMP обычно основана на hash-функции, которая использует параметры пакета для выбора линка:
• Source / Destination MAC
• Source / Destination IP
• Source / Destination TCP/UDP порты

Коммутатор или маршрутизатор вычисляет «хэш» и назначает конкретный линк для этой сессии.

Если большинство сессий используют одинаковые параметры (например, много трафика к одному серверу или одному сервису), хэш-функция распределяет их на один линк. 

Остальные остаются почти пустыми - это и называется hash polarization.

На практике это проявляется так:
⏺Один линк работает на 90–100% пропускной способности, другие - почти пустые.
⏺Сессии к одному серверу всегда идут через один и тот же линк.
⏺Мониторинг агрегированного канала показывает нормальную пропускную способность, но дисбаланс по отдельным линкам очевиден.

Как проверить на Cisco

show etherchannel summary

Статус всех Port-Channel, активные интерфейсы и режим LACP.

show interfaces port-channel 1

Ошибки, drops, скорость и загрузка агрегированного интерфейса.

show interfaces Gi0/1 etherchannel

Как конкретный физический интерфейс участвует в Port-Channel.

show etherchannel load-balance

Схема распределения трафика: по MAC, IP или портам.

show platform hardware port-channel statistics

Аппаратные счётчики по линкам, чтобы увидеть дисбаланс на уровне ASIC.

N.A.

Почему серверы теряют доступ к gateway

Даже когда линк активен, а сервер «пингуется» в своей подсети, иногда невозможно выйти за пределы VLAN.

Основные причины кроются в логике L2/L3: ARP, маршруты, конфликты IP и асимметричные пути.

Основные причины 👇

1️⃣ARP-проблемы
Если на сервере или коммутаторе устарели ARP-записи, gateway может «исчезнуть» из таблицы. Сервер отправляет пакеты, а коммутатор не знает, куда их направить.

2️⃣Default route отсутствует или неверная
Без корректного default route сервер не знает, куда уходить за пределы своей подсети. Иногда статическая маршрутизация задаётся неправильно или конфликтует с динамическими маршрутами.

3️⃣Duplicate IP
Если кто-то в сети использует тот же IP, ARP-кэш может переписываться, и трафик на gateway идёт на чужое устройство. Сессии становятся нестабильными: часть пакетов проходит, часть теряется.

4️⃣Asymmetric routing
Когда трафик «туда» идёт по одному пути, а «обратно» - по другому, stateful firewall или NAT могут рвать соединения. Сервер вроде отправляет пакеты, а ответы не доходят.

Как проверить

show ip arp

Смотрим MAC-адрес gateway и его актуальность.

ping <gateway>

Проверяем, доступен ли gateway в реальном времени.

show ip route

Проверяем наличие default route и маршрутов к другим подсетям.

show ip interface brief

Статус интерфейсов сервера и коммутатора.

show logging | include ARP

Логи могут показать конфликты и дублирование IP.

N.A.

Почему SSL/TLS соединения падают при смене времени

Даже когда сертификаты вроде валидны и сервер доступен, HTTPS-сессии могут обрываться или выдавать ошибки handshake.

Основная причина в том, что TLS строго проверяет время: если системные часы сервера или клиента сильно отстают или опережают реальное время, сертификаты могут считаться просроченными или ещё не действительными.

⏺Ещё одна частая причина - неправильно настроенный NTP. Без синхронизации часы расходятся, и handshake с клиентом завершается с ошибкой.

Иногда сбои связаны с expired сертификатами, которые дополнительно усугубляют проблему, особенно на новых соединениях.

Как проверить

show ntp status

Проверка синхронизации времени на сетевых устройствах.

date

Смотрим системное время на сервере.

openssl s_client -connect <host>:443

Анализ TLS handshake и проверки сертификатов.

timedatectl

Проверка часового пояса и синхронизации на Linux.

show logging | include NTP

N.A.

Как понять, что firewall блокирует трафик «мимо правил»

Иногда кажется, что все правила настроены правильно, но трафик не проходит. Проблема часто кроется в особенностях stateful firewall. 

Он отслеживает сессии, и если обратный путь идёт другим маршрутом (asymmetric routing) или таблица состояний переполнена, новые пакеты могут просто сбрасываться, даже если правила разрешают соединение.

⏺Симптомы: соединение устанавливается частично, ping проходит, а приложения не работают; одни сессии живут, другие рвутся без видимых причин.

Как проверить

show conn

Просмотр активных сессий на firewall.

show session all

Полная таблица сессий с их состояниями.

show logging | include DROP

Логи о сброшенных пакетах.

traceroute <destination>

Проверка маршрута в обход firewall и выявление асимметрии.

show ip route

Смотрим маршруты, чтобы убедиться, что обратный путь совпадает.

N.A.

Почему OSPF соседство не поднимается

Интерфейсы в состоянии up/up, IP-адреса корректные, но соседи в OSPF не переходят в Full.

Чаще всего причина в несовпадении параметров: area ID, network type, hello/dead timers, MTU или authentication. 

Иногда интерфейс попадает под passive-interface, либо multicast 224.0.0.5 блокируется ACL’ом.

Также соседство не установится, если Router ID дублируется в домене или если одна сторона работает в stub/NSSA, а другая - нет.

🤖Что проверить на Cisco

show ip ospf neighbor
show ip ospf interface Gi0/1
show ip ospf interface Gi0/1 | include MTU
show ip protocols
show running-config | section router ospf
show ip ospf database
show access-lists

N.A.

Как сделать резервный интернет-канал с автоматическим переключением

Чтобы при падении основного провайдера трафик автоматически уходил на backup, используется IP SLA + track + floating static route.

1️⃣Настроить IP SLA для проверки доступности внешнего узла:

ip sla 1
 icmp-echo 8.8.8.8 source-interface Gi0/0
 frequency 5
ip sla schedule 1 life forever start-time now

2️⃣Создать track-объект:

track 1 ip sla 1 reachability

3️⃣Основной маршрут через primary ISP:

ip route 0.0.0.0 0.0.0.0 1.1.1.1 track 1

4️⃣Backup-маршрут с большей administrative distance:

ip route 0.0.0.0 0.0.0.0 2.2.2.2 200

5️⃣Проверка работы переключения:

show track 1
show ip sla statistics
show ip route 0.0.0.0

При падении primary SLA перестаёт получать ответы, track переходит в down, основной маршрут удаляется из RIB и трафик автоматически идёт через backup.

N.A.

Почему после включения Port-Security порт уходит в err-disable

Port-Security защищает сеть от нежелательных MAC-адресов, но при строгой настройке порта любое несоответствие правил вызывает блокировку.

Порт переходит в err-disable, если на нём появляется больше MAC, чем разрешено, если новый MAC не в списке allowed, или если нарушается режим violation (shutdown).

⏺На практике это проявляется так: на порту стоят IP-телефон и ПК, виртуальная машина на сервере, или случайно подключили другой коммутатор без согласования. Порт тут же падает, трафик прекращается, и STP перестраивает дерево.

🔎Как проверить?

show port-security interface Gi0/1
show port-security address
show interfaces status err-disabled
show mac address-table interface Gi0/1

👨‍🎨Как исправить
1️⃣Временно восстановить порт:

interface Gi0/1
 shutdown
 no shutdown

2️⃣Настроить лимит MAC или режим реакции:

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

3️⃣Проверить актуальные MAC на порту и при необходимости добавить в allowed list:

switchport port-security mac-address sticky

N.A.

Скотча не было, а вот энтузиазм присутствовал 😎

N.A.

Что будет, если героические способности уместить в компактную оболочку?

❓новый герой Marvel
❓настольный сервер для задач локального ИИ
❓маленькая рабочая станция HP Z2 Mini G1a

Рассуждения в сторону, т.к. это тот самый случай, когда все варианты ответов верны!

А чтобы сомнения в могуществе этой машинки отпали раз и навсегда, подготовили небольшой видеообзор HP Z2 Mini G1a. Подсветили главные достоинства, конфигурации, области применения и даже провели наглядный тест — "как 128 ГБ памяти превращаются в локальный ИИ на 120 млрд параметров"

💬Смотреть в MAX
📺Смотреть на сайте

А совсем скоро ожидаем рабочую станцию Minisforum. Подписывайтесь, чтобы не пропустить обзор!

Сервер, сторадж & два свича

Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJmdLdo

Пинг проходит, а приложение не работает

ICMP отвечает, маршрут есть, latency нормальная - но сайт не открывается, API не отвечает, RDP/SSH зависает на этапе подключения. Это типичный случай, когда L3 жив, а проблема выше.

Чаще всего причина в несоответствии MSS/MTU: small ICMP-пакеты проходят, а крупные TCP-сегменты фрагментируются или silently дропаются. Особенно актуально для VPN, GRE, PPPoE и overlay-сетей.

⏺Вторая распространённая причина - stateful firewall. Пакеты могут доходить до сервера, но обратный трафик блокируется из-за отсутствия сессии в таблице состояний или из-за asymmetric routing. В логах - тишина, потому что дроп происходит «легально» по логике state engine.

⏺Третий сценарий - асимметрия маршрутизации. Запрос идёт через один firewall или edge, а ответ возвращается через другой. Для ICMP это не критично, для TCP — критично. В результате handshake не завершается или соединение обрывается.

Также возможны проблемы на уровне L4–L7: неверный listener на сервере, сервис слушает не тот IP, TLS mismatch, истёкший сертификат, DNS возвращает неправильный адрес.

Пинг до IP проходит, но приложение недоступно по FQDN.

N.A.

NTP для больших сетей MikroTik: несколько серверов и failover

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

⏺Несколько NTP-серверов

Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:

/system ntp client set enabled=yes primary-ntp=192.168.1.10 secondary-ntp=192.168.1.11 server-dns-names=0.pool.ntp.org,1.pool.ntp.org

Первичные и вторичные серверы внутри сети гарантируют, что локальные устройства будут иметь корректное время даже при обрыве интернета.

⏺Проверка и диагностика

Состояние клиента можно проверить так:

/system ntp client print
/system ntp servers print

В выводе видны активные серверы и задержка до них. Высокая задержка или отсутствие ответа сигнализируют о проблемах с сетью или firewall.

⏺Failover и последовательность
1️⃣Внутренние серверы берут приоритет, если они доступны.
2️⃣ Внешние NTP сервера — резерв.
3️⃣ Если все недоступны — роутер использует локальные часы, но периодически пробует повторно синхронизироваться.

N.A.