Как проверить PoE-потребление без доступа к устройству
Чтобы это проверить, необязательно идти к камере с тестером. Управляемый PoE-коммутатор часто показывает параметры питания прямо через CLI.
⏺ Смотрим общий бюджет PoE
На Cisco Catalyst:
Команда показывает доступную мощность, сколько уже выделено подключённым устройствам и сколько осталось.
Важно не путать allocated power и фактическое потребление. Коммутатор может зарезервировать для камеры 15,4 Вт, хотя сейчас она использует значительно меньше.
⏺ Проверяем конкретный порт
В зависимости от модели и версии ПО можно увидеть класс PoE, выделенную мощность, состояние питания и измеренное потребление.
Например, камера днём потребляет 6 Вт, а ночью включает ИК-подсветку и нагреватель. Потребление растёт, и если мощности недостаточно, устройство может перезагрузиться.
⏺ Ищем события питания
На поддерживаемых Cisco Catalyst так можно найти сообщения об отказе в питании, превышении лимита или отключении PoE на порту.
Если коммутатор не показывает фактические ватты, ориентируемся на выделенную мощность, класс устройства и события контроллера PoE. Не все модели умеют измерять потребление в реальном времени.
N.A.
IP-камера периодически перезагружается, хотя сетевой линк работает нормально. Причина может быть не в сети, а в питании через PoE.
Чтобы это проверить, необязательно идти к камере с тестером. Управляемый PoE-коммутатор часто показывает параметры питания прямо через CLI.
На Cisco Catalyst:
show power inline
Команда показывает доступную мощность, сколько уже выделено подключённым устройствам и сколько осталось.
Важно не путать allocated power и фактическое потребление. Коммутатор может зарезервировать для камеры 15,4 Вт, хотя сейчас она использует значительно меньше.
show power inline Gi1/0/10 detail
В зависимости от модели и версии ПО можно увидеть класс PoE, выделенную мощность, состояние питания и измеренное потребление.
Например, камера днём потребляет 6 Вт, а ночью включает ИК-подсветку и нагреватель. Потребление растёт, и если мощности недостаточно, устройство может перезагрузиться.
show logging | include ILPOWER
На поддерживаемых Cisco Catalyst так можно найти сообщения об отказе в питании, превышении лимита или отключении PoE на порту.
Если коммутатор не показывает фактические ватты, ориентируемся на выделенную мощность, класс устройства и события контроллера PoE. Не все модели умеют измерять потребление в реальном времени.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
4 команды для диагностики оптического линка в Linux
Оптический интерфейс может оставаться UP, даже когда качество сигнала уже ухудшилось. Поэтому при нестабильной связи стоит проверить не только состояние порта, но и сам трансивер.
⏺ Проверить параметры SFP-модуля
Если модуль и драйвер поддерживают диагностику, увидим температуру, напряжение, мощность передатчика (Tx) и принимаемого сигнала (Rx).
Особенно интересен Rx Power. Слишком слабый сигнал может указывать на загрязнённые коннекторы, затухание или проблемы с оптикой. Сравнивать значение нужно с допустимым диапазоном конкретного модуля.
⏺ Посмотреть ошибки интерфейса
Ищем счётчики CRC/FCS, symbol errors и другие ошибки приёма. Названия зависят от драйвера.
Важно смотреть не только абсолютные значения, но и растут ли они со временем.
⏺ Проверить FEC
На поддерживаемых интерфейсах команда покажет настроенный и активный режим Forward Error Correction.
Если доступны счётчики исправленных и неисправимых ошибок FEC, они помогут заметить ухудшение линии ещё до массовых потерь пакетов.
⏺ Проверить согласованную скорость
Смотрим Speed, Duplex и Link detected. Так можно обнаружить, что интерфейс поднялся не в ожидаемом режиме.
N.A.
Оптический интерфейс может оставаться UP, даже когда качество сигнала уже ухудшилось. Поэтому при нестабильной связи стоит проверить не только состояние порта, но и сам трансивер.
ethtool -m eth0
Если модуль и драйвер поддерживают диагностику, увидим температуру, напряжение, мощность передатчика (Tx) и принимаемого сигнала (Rx).
Особенно интересен Rx Power. Слишком слабый сигнал может указывать на загрязнённые коннекторы, затухание или проблемы с оптикой. Сравнивать значение нужно с допустимым диапазоном конкретного модуля.
ethtool -S eth0
Ищем счётчики CRC/FCS, symbol errors и другие ошибки приёма. Названия зависят от драйвера.
Важно смотреть не только абсолютные значения, но и растут ли они со временем.
ethtool —show-fec eth0
На поддерживаемых интерфейсах команда покажет настроенный и активный режим Forward Error Correction.
Если доступны счётчики исправленных и неисправимых ошибок FEC, они помогут заметить ухудшение линии ещё до массовых потерь пакетов.
ethtool eth0
Смотрим Speed, Duplex и Link detected. Так можно обнаружить, что интерфейс поднялся не в ожидаемом режиме.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Как Ethernet временно останавливает передачу
Представим, что сервер принимает трафик быстрее, чем успевает его обрабатывать. Буферы сетевой карты заполняются, и скоро начнутся потери пакетов.
Но Ethernet умеет не только отбрасывать кадры. В некоторых сетях он может попросить соседнее устройство временно прекратить передачу.
⏺ Как это работает?
В стандарте IEEE 802.3x предусмотрены специальные PAUSE-кадры. Если включён Flow Control, перегруженный приёмник может отправить такой кадр соседу.
Получив кадр, сосед временно приостанавливает обычную передачу данных по линку.
При этом PAUSE действует на весь линк, а не на отдельное TCP-соединение.
⏺ Как проверить в Linux?
Посмотрим настройки сетевой карты:
В выводе интересуют
Статистику можно поискать через:
Названия счётчиков и их доступность зависят от драйвера.
⏺ В чём подвох?
PAUSE помогает избежать переполнения буферов, но создаёт другую проблему: один перегруженный получатель способен затормозить весь трафик на физическом соединении.
Из-за этого Flow Control не всегда улучшает производительность. Иногда он просто переносит перегрузку на соседнее устройство.
N.A.
Представим, что сервер принимает трафик быстрее, чем успевает его обрабатывать. Буферы сетевой карты заполняются, и скоро начнутся потери пакетов.
Но Ethernet умеет не только отбрасывать кадры. В некоторых сетях он может попросить соседнее устройство временно прекратить передачу.
В стандарте IEEE 802.3x предусмотрены специальные PAUSE-кадры. Если включён Flow Control, перегруженный приёмник может отправить такой кадр соседу.
Внутри указывается время паузы в единицах по 512 битовых интервалов.
Получив кадр, сосед временно приостанавливает обычную передачу данных по линку.
При этом PAUSE действует на весь линк, а не на отдельное TCP-соединение.
Посмотрим настройки сетевой карты:
ethtool -a eth0
В выводе интересуют
RX и TX: разрешён ли приём PAUSE-кадров и может ли интерфейс отправлять их сам.Статистику можно поискать через:
ethtool -S eth0 | grep -i pause
Названия счётчиков и их доступность зависят от драйвера.
PAUSE помогает избежать переполнения буферов, но создаёт другую проблему: один перегруженный получатель способен затормозить весь трафик на физическом соединении.
Из-за этого Flow Control не всегда улучшает производительность. Иногда он просто переносит перегрузку на соседнее устройство.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Почему два коммутатора могут одновременно считать себя главным шлюзом
В сети используется MLAG: два физических коммутатора объединены в логическую пару, а серверы подключены сразу к обоим через LACP.
Всё работает нормально, пока между коммутаторами не пропадает служебное соединение — peer-link.
⏺ Что происходит при разрыве?
Через peer-link устройства обмениваются служебной информацией и синхронизируют часть состояния.
Если связь между ними потеряна, каждый коммутатор может перестать получать актуальные данные о соседе.
Тогда возникает риск split-brain: оба коммутатора считают, что могут самостоятельно обслуживать общие подключения.
⏺ Чем это грозит?
В зависимости от реализации MLAG возможны дублирование кадров, MAC flapping, нарушения пересылки и потери трафика.
При этом физические интерфейсы могут оставаться UP, поэтому обычная проверка состояния портов не всегда обнаружит проблему.
⏺ Как защищаются от split-brain?
Кроме того, многие реализации MLAG при потере peer-link автоматически отключают определённые порты на вторичном коммутаторе, чтобы не допустить одновременной независимой работы пары.
Конкретное поведение зависит от производителя и настроек.
N.A.
В сети используется MLAG: два физических коммутатора объединены в логическую пару, а серверы подключены сразу к обоим через LACP.
Всё работает нормально, пока между коммутаторами не пропадает служебное соединение — peer-link.
Через peer-link устройства обмениваются служебной информацией и синхронизируют часть состояния.
Если связь между ними потеряна, каждый коммутатор может перестать получать актуальные данные о соседе.
Особенно опасна ситуация, когда одновременно нарушается и дополнительный канал проверки доступности — keepalive.
Тогда возникает риск split-brain: оба коммутатора считают, что могут самостоятельно обслуживать общие подключения.
В зависимости от реализации MLAG возможны дублирование кадров, MAC flapping, нарушения пересылки и потери трафика.
При этом физические интерфейсы могут оставаться UP, поэтому обычная проверка состояния портов не всегда обнаружит проблему.
Обычно используют отдельный peer-keepalive, который проходит независимо от peer-link.
Кроме того, многие реализации MLAG при потере peer-link автоматически отключают определённые порты на вторичном коммутаторе, чтобы не допустить одновременной независимой работы пары.
Конкретное поведение зависит от производителя и настроек.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Проверка DNSSEC валидации через dig +dnssec, а не просто наличия настройки
DNSSEC включён в конфиге резолвера, но это не значит что валидация реально работает.
Резолвер может принимать неподписанные ответы, игнорировать сломанные подписи или вообще не проверять цепочку доверия. Проверяем поведение, а не настройку.
Базовая проверка: резолвер возвращает AD флаг
AD (Authentic Data) в ответе означает что резолвер проверил подписи и доверяет ответу:
Смотрим на флаги в строке flags: qr rd ra ad. Если ad есть, валидация работает для этого домена.
Проверка что резолвер отклоняет сломанные подписи
Существуют специальные тестовые домены с намеренно сломанным DNSSEC:
Если резолвер валидирует правильно, ответ должен быть SERVFAIL а не реальный IP. Если вернулся IP, резолвер принимает сломанные подписи.
Тот же тест, другой домен. SERVFAIL это ожидаемый правильный ответ.
Скрипт массовой проверки нескольких резолверов
В cron раз в час:
N.A.
DNSSEC включён в конфиге резолвера, но это не значит что валидация реально работает.
Резолвер может принимать неподписанные ответы, игнорировать сломанные подписи или вообще не проверять цепочку доверия. Проверяем поведение, а не настройку.
Базовая проверка: резолвер возвращает AD флаг
AD (Authentic Data) в ответе означает что резолвер проверил подписи и доверяет ответу:
dig +dnssec sigok.verteiltesysteme.net @127.0.0.1
Смотрим на флаги в строке flags: qr rd ra ad. Если ad есть, валидация работает для этого домена.
Проверка что резолвер отклоняет сломанные подписи
Существуют специальные тестовые домены с намеренно сломанным DNSSEC:
dig sigfail.verteiltesysteme.net @127.0.0.1
Если резолвер валидирует правильно, ответ должен быть SERVFAIL а не реальный IP. Если вернулся IP, резолвер принимает сломанные подписи.
dig dnssec-failed.org @127.0.0.1
Тот же тест, другой домен. SERVFAIL это ожидаемый правильный ответ.
Скрипт массовой проверки нескольких резолверов
#!/bin/bash
RESOLVERS=(«127.0.0.1» «1.1.1.1» «8.8.8.8» «9.9.9.9»)
VALID_DOMAIN=«sigok.verteiltesysteme.net»
BROKEN_DOMAIN=«sigfail.verteiltesysteme.net»
LOG=«/var/log/dnssec_check.log»
echo «=== DNSSEC check $(date) ===« >> «$LOG»
for resolver in «${RESOLVERS[@]}»; do
valid_ad=$(dig +dnssec +time=3 «$VALID_DOMAIN» @«$resolver» 2>/dev/null \
| grep «flags:» | grep -c « ad «)
broken_status=$(dig +time=3 «$BROKEN_DOMAIN» @«$resolver» 2>/dev/null \
| grep «status:» | awk -F’[,:]’ ‘{print $2}’ | tr -d ‘ ‘)
if [ «$valid_ad» -eq 1 ] && [ «$broken_status» = «SERVFAIL» ]; then
result=«OK»
elif [ «$valid_ad» -eq 0 ]; then
result=«FAIL: не возвращает AD флаг»
else
result=«FAIL: принимает сломанные подписи ($broken_status)»
fi
echo «$resolver: $result» | tee -a «$LOG»
done
В cron раз в час:
0 * * * * /usr/local/bin/check_dnssec.sh
N.A.
👍4
VLAN Translation: когда VLAN 100 превращается в VLAN 200
Представим, что две компании подключаются через сеть оператора. У первой используется VLAN 100, а у второй - VLAN 200.
Нужно объединить их в один L2-сегмент, но менять VLAN на оборудовании клиентов никто не хочет.
Для этого существует VLAN Translation - механизм переписывания VLAN-тегов прямо на коммутаторе.
⏺ Как это работает?
Коммутатор получает Ethernet-кадр с тегом VLAN 100, заменяет VLAN ID на 200 и отправляет дальше.
При этом IP-адреса, MAC-адреса и содержимое полезной нагрузки не меняются. Переписывается именно VLAN ID в заголовке 802.1Q.
⏺ Как это настраивается?
На некоторых платформах Cisco с поддержкой VLAN mapping используется такой синтаксис:
Конкретные команды и ограничения зависят от модели и версии ПО.
Проверить настройки на поддерживаемых платформах можно командой:
⏺ Где применяется?
Чаще всего VLAN Translation встречается в операторских сетях, при объединении инфраструктур и подключении клиентов с пересекающимися VLAN ID.
Но важно учитывать: трансляция не создаёт изоляцию сама по себе. Если несколько клиентских VLAN отображаются в один общий VLAN, их трафик может оказаться в одном широковещательном домене.
⚡️ VLAN Translation позволяет соединять L2-сети с разной нумерацией VLAN без изменения конфигурации конечных устройств. Главное - правильно определить, где именно переписываются теги и какие сегменты после этого объединяются.
N.A.
Представим, что две компании подключаются через сеть оператора. У первой используется VLAN 100, а у второй - VLAN 200.
Нужно объединить их в один L2-сегмент, но менять VLAN на оборудовании клиентов никто не хочет.
Для этого существует VLAN Translation - механизм переписывания VLAN-тегов прямо на коммутаторе.
Коммутатор получает Ethernet-кадр с тегом VLAN 100, заменяет VLAN ID на 200 и отправляет дальше.
При обратной передаче происходит обратная замена: VLAN 200 превращается в VLAN 100.
При этом IP-адреса, MAC-адреса и содержимое полезной нагрузки не меняются. Переписывается именно VLAN ID в заголовке 802.1Q.
На некоторых платформах Cisco с поддержкой VLAN mapping используется такой синтаксис:
interface GigabitEthernet1/0/1
switchport mode trunk
switchport vlan mapping 100 200
switchport vlan mapping enable
Конкретные команды и ограничения зависят от модели и версии ПО.
Проверить настройки на поддерживаемых платформах можно командой:
show interfaces vlan mapping
Чаще всего VLAN Translation встречается в операторских сетях, при объединении инфраструктур и подключении клиентов с пересекающимися VLAN ID.
Но важно учитывать: трансляция не создаёт изоляцию сама по себе. Если несколько клиентских VLAN отображаются в один общий VLAN, их трафик может оказаться в одном широковещательном домене.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
3 команды для диагностики нестабильного OSPF-соседства
OSPF-соседство периодически переходит из Full в Down, а затем восстанавливается. При этом интерфейс остаётся UP, и обычный ping может не показывать проблем.
На Cisco IOS/IOS XE причину можно искать через три команды.
⏺ Проверяем состояние соседей
Смотрим состояние соседства, Dead Timer, количество переходов между состояниями и время последнего изменения.
Если счётчик переходов растёт, соседство действительно нестабильно, даже если сейчас оно снова Full.
⏺ Проверяем параметры интерфейса
Здесь видны Hello и Dead Interval, тип OSPF-сети, приоритет маршрутизатора и другие параметры.
Особенно важно сравнить таймеры на обоих концах соединения. Несовпадение Hello/Dead Interval обычно не позволяет установить соседство.
⏺ Ищем причину последнего сброса
В логах можно найти сообщения об истечении Dead Timer, изменениях состояния соседей и других событиях OSPF.
Если соседство падает по Dead Timer, стоит проверить потери Hello-пакетов, загрузку control plane и фильтрацию IP-протокола 89.
⚡️ Состояние Full показывает только текущую картину. Для диагностики нестабильного OSPF важнее история переходов, параметры интерфейса и причина последнего сброса соседства.
N.A.
OSPF-соседство периодически переходит из Full в Down, а затем восстанавливается. При этом интерфейс остаётся UP, и обычный ping может не показывать проблем.
На Cisco IOS/IOS XE причину можно искать через три команды.
show ip ospf neighbor detail
Смотрим состояние соседства, Dead Timer, количество переходов между состояниями и время последнего изменения.
Если счётчик переходов растёт, соседство действительно нестабильно, даже если сейчас оно снова Full.
show ip ospf interface GigabitEthernet0/0
Здесь видны Hello и Dead Interval, тип OSPF-сети, приоритет маршрутизатора и другие параметры.
Особенно важно сравнить таймеры на обоих концах соединения. Несовпадение Hello/Dead Interval обычно не позволяет установить соседство.
show logging | include OSPF
В логах можно найти сообщения об истечении Dead Timer, изменениях состояния соседей и других событиях OSPF.
Если соседство падает по Dead Timer, стоит проверить потери Hello-пакетов, загрузку control plane и фильтрацию IP-протокола 89.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Маршруты правильные, но трафик идёт по кругу: как найти MPLS-ловушку
В MPLS-сети может возникнуть ситуация, когда IP-маршрутизация выглядит исправной, но пакеты с метками зацикливаются между двумя LSR.
Причина - несогласованность таблиц пересылки меток после изменения топологии.
⏺ Сначала проверяем LFIB
На Cisco IOS/IOS XE:
Здесь видно, какую входящую метку маршрутизатор заменяет на выходную и какому next-hop отправляет пакет.
Если два соседних LSR пересылают трафик для одного FEC обратно друг другу, возможна петля на уровне MPLS.
⏺ Проверяем путь с метками
На платформах с поддержкой MPLS LSP Ping/Traceroute команда помогает исследовать путь конкретного FEC через MPLS-сеть.
Если трассировка показывает повторяющиеся узлы, сравниваем LFIB на каждом из них.
⏺ Ищем источник расхождения
Проверяем, какие метки получены от соседей и соответствуют ли они ожидаемым FEC.
При этом важно отличать ошибку LDP от временной микропетли при сходимости IGP: таблицы могут быть корректными по отдельности, но обновляться на разных маршрутизаторах не одновременно.
⚡️ В MPLS недостаточно проверить
N.A.
В MPLS-сети может возникнуть ситуация, когда IP-маршрутизация выглядит исправной, но пакеты с метками зацикливаются между двумя LSR.
Причина - несогласованность таблиц пересылки меток после изменения топологии.
На Cisco IOS/IOS XE:
show mpls forwarding-table
Здесь видно, какую входящую метку маршрутизатор заменяет на выходную и какому next-hop отправляет пакет.
Если два соседних LSR пересылают трафик для одного FEC обратно друг другу, возможна петля на уровне MPLS.
traceroute mpls ipv4 10.20.30.0/24
На платформах с поддержкой MPLS LSP Ping/Traceroute команда помогает исследовать путь конкретного FEC через MPLS-сеть.
Если трассировка показывает повторяющиеся узлы, сравниваем LFIB на каждом из них.
show mpls ldp bindings
Проверяем, какие метки получены от соседей и соответствуют ли они ожидаемым FEC.
При этом важно отличать ошибку LDP от временной микропетли при сходимости IGP: таблицы могут быть корректными по отдельности, но обновляться на разных маршрутизаторах не одновременно.
show ip route. Пакеты с метками пересылаются по LFIB, поэтому проблема может находиться в label forwarding, даже когда IP-маршрут выглядит совершенно нормальным.N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
TCAM переполнен: почему новая ACL не применяется
Представим, что сетевой инженер добавил несколько правил ACL на коммутатор. Конфигурация сохранилась, ошибок в синтаксисе нет, но часть трафика продолжает проходить так, будто новых правил не существует.
⏺ Что такое TCAM?
Ternary Content Addressable Memory - специальная память, которую коммутаторы используют для быстрого поиска совпадений по правилам.
В отличие от обычной памяти, TCAM умеет сопоставлять биты со значениями 0, 1 и «неважно». Благодаря этому оборудование может проверять ACL на скорости линии, не передавая каждый пакет процессору.
⏺ Почему она заканчивается?
Одно правило ACL не обязательно занимает одну запись TCAM.
Кроме того, TCAM используется не только для ACL. В зависимости от платформы её ресурсы могут распределяться между маршрутизацией, QoS и другими функциями.
⏺ Как проверить?
На поддерживаемых Cisco Catalyst можно посмотреть использование аппаратных ресурсов:
Команда зависит от модели и версии IOS XE. На других платформах используются собственные средства диагностики.
Также стоит проверить системные сообщения об ошибках программирования ACL в аппаратную таблицу.
⚡️ Успешное сохранение ACL в конфигурации ещё не гарантирует, что все правила установлены в forwarding plane. При нехватке TCAM поведение зависит от платформы: она может отклонить изменение, сообщить об ошибке или применить ограничения. Поэтому после изменения крупных ACL важно проверять не только конфигурацию, но и аппаратные ресурсы.
N.A.
Представим, что сетевой инженер добавил несколько правил ACL на коммутатор. Конфигурация сохранилась, ошибок в синтаксисе нет, но часть трафика продолжает проходить так, будто новых правил не существует.
Одна из возможных причин - закончились ресурсы TCAM.
Ternary Content Addressable Memory - специальная память, которую коммутаторы используют для быстрого поиска совпадений по правилам.
В отличие от обычной памяти, TCAM умеет сопоставлять биты со значениями 0, 1 и «неважно». Благодаря этому оборудование может проверять ACL на скорости линии, не передавая каждый пакет процессору.
Одно правило ACL не обязательно занимает одну запись TCAM.
Например, диапазоны портов, сложные маски и особенности аппаратной архитектуры могут потребовать нескольких записей для одного ACE.
Кроме того, TCAM используется не только для ACL. В зависимости от платформы её ресурсы могут распределяться между маршрутизацией, QoS и другими функциями.
На поддерживаемых Cisco Catalyst можно посмотреть использование аппаратных ресурсов:
show platform hardware fed switch active fwd-asic resource tcam utilization
Команда зависит от модели и версии IOS XE. На других платформах используются собственные средства диагностики.
Также стоит проверить системные сообщения об ошибках программирования ACL в аппаратную таблицу.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Как узнать, что изменилось в сети перед аварией
В 14:30 перестал работать один из VLAN. Интерфейсы UP, оборудование доступно, а в логах нет очевидных ошибок.
Чтобы не искать такие изменения вручную, используют Configuration Drift Detection.
⏺ Сохраняем историю конфигураций
Для этого подходит Oxidized - инструмент, который регулярно подключается к сетевому оборудованию, забирает конфигурации и сохраняет их версии, например в Git.
Если на коммутаторе изменили allowed VLAN, в истории появится разница:
Сразу видно, что VLAN 30 исчез из разрешённого списка.
⏺ Проверяем, когда произошло изменение
На Cisco IOS/IOS XE при заранее включённом архивировании конфигураций можно использовать:
Команда помогает увидеть зарегистрированные изменения и, при соответствующей настройке, пользователя, который их выполнил.
⏺ Сопоставляем события
Теперь сравниваем время изменения конфигурации с syslog, SNMP traps и событиями мониторинга.
Например, в 14:27 изменили trunk, а в 14:30 мониторинг зафиксировал недоступность устройств VLAN 30.
Это уже конкретная гипотеза, которую можно проверить, а не случайный поиск неисправности.
⚡️ Configuration drift - это отклонение текущей конфигурации от сохранённой или эталонной. Если хранить историю изменений и сопоставлять её с событиями сети, расследование аварий становится значительно быстрее.
N.A.
В 14:30 перестал работать один из VLAN. Интерфейсы UP, оборудование доступно, а в логах нет очевидных ошибок.
Через полчаса выясняется, что незадолго до сбоя кто-то изменил конфигурацию trunk-порта.
Чтобы не искать такие изменения вручную, используют Configuration Drift Detection.
Для этого подходит Oxidized - инструмент, который регулярно подключается к сетевому оборудованию, забирает конфигурации и сохраняет их версии, например в Git.
Если на коммутаторе изменили allowed VLAN, в истории появится разница:
- switchport trunk allowed vlan 10,20,30
+ switchport trunk allowed vlan 10,20
Сразу видно, что VLAN 30 исчез из разрешённого списка.
На Cisco IOS/IOS XE при заранее включённом архивировании конфигураций можно использовать:
show archive log config all
Команда помогает увидеть зарегистрированные изменения и, при соответствующей настройке, пользователя, который их выполнил.
Теперь сравниваем время изменения конфигурации с syslog, SNMP traps и событиями мониторинга.
Например, в 14:27 изменили trunk, а в 14:30 мониторинг зафиксировал недоступность устройств VLAN 30.
Это уже конкретная гипотеза, которую можно проверить, а не случайный поиск неисправности.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
DNS over HTTPS vs DNS over TLS: что меняется для корпоративной сети
Раньше администратор мог анализировать DNS-запросы сотрудников на UDP/53, блокировать нежелательные домены и выявлять подозрительную активность.
⏺ DNS over TLS (DoT)
DNS-запросы передаются через отдельное TLS-соединение, обычно на TCP-порту 853.
Это удобно для сетевого контроля: администратор может обнаружить или ограничить такой трафик по порту. Но содержимое запросов без расшифровки уже не видно.
⏺ DNS over HTTPS (DoH)
Здесь DNS-запросы передаются внутри HTTPS, обычно через порт 443.
Для сетевого оборудования такой трафик может выглядеть как обычное HTTPS-соединение. Простая блокировка UDP/53 или TCP/853 уже не гарантирует, что устройства используют корпоративный DNS.
Например, браузер может обращаться к внешнему DoH-резолверу, обходя локальную DNS-фильтрацию.
⏺ Как контролировать DNS в корпоративной сети?
Обычно используют несколько подходов:
• Централизованно задают разрешённые DNS-резолверы через политики устройств и браузеров.
• Ограничивают обращения к неразрешённым DNS-сервисам.
• Анализируют DNS-логи корпоративного резолвера и контролируют настройки клиентов.
Проверить доступность конкретного DoH-сервера можно через:
Но такой запрос проверяет HTTPS-доступность endpoint, а не выполнение DNS-запроса через DoH.
⚡️ DoT проще идентифицировать по отдельному порту, а DoH сложнее отличить от обычного HTTPS. Поэтому корпоративная DNS-безопасность всё больше зависит от управления конечными устройствами, а не только от правил на межсетевом экране.
N.A.
Раньше администратор мог анализировать DNS-запросы сотрудников на UDP/53, блокировать нежелательные домены и выявлять подозрительную активность.
Но с появлением шифрованного DNS привычная схема перестала быть такой надёжной.
DNS-запросы передаются через отдельное TLS-соединение, обычно на TCP-порту 853.
Это удобно для сетевого контроля: администратор может обнаружить или ограничить такой трафик по порту. Но содержимое запросов без расшифровки уже не видно.
Здесь DNS-запросы передаются внутри HTTPS, обычно через порт 443.
Для сетевого оборудования такой трафик может выглядеть как обычное HTTPS-соединение. Простая блокировка UDP/53 или TCP/853 уже не гарантирует, что устройства используют корпоративный DNS.
Например, браузер может обращаться к внешнему DoH-резолверу, обходя локальную DNS-фильтрацию.
Обычно используют несколько подходов:
• Централизованно задают разрешённые DNS-резолверы через политики устройств и браузеров.
• Ограничивают обращения к неразрешённым DNS-сервисам.
• Анализируют DNS-логи корпоративного резолвера и контролируют настройки клиентов.
Проверить доступность конкретного DoH-сервера можно через:
curl -I https://dns.google/dns-query
Но такой запрос проверяет HTTPS-доступность endpoint, а не выполнение DNS-запроса через DoH.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Incast: когда сотни серверов перегружают один порт
В датацентре может возникнуть странная ситуация: сеть почти не загружена, но распределённое приложение периодически сталкивается с резкими задержками.
⏺ Как возникает Incast?
Допустим, приложение запрашивает данные сразу у 100 серверов. Каждый отправляет ответ размером 256 КБ.
В сумме это 25 МБ данных, которые почти одновременно направляются к одному получателю.
Даже если каждый сервер подключён через 10 или 25 Гбит/с, выходной порт коммутатора в сторону получателя имеет ограниченную пропускную способность.
Входящий поток на короткое время превышает возможности выходного порта, и очередь начинает быстро заполняться.
⏺ Почему это опасно?
Когда буфер переполняется, коммутатор отбрасывает пакеты. Если потери затрагивают сразу несколько TCP-соединений, часть отправителей вынуждена повторно передавать данные.
Особенно неприятно, когда приложение ждёт ответы от всех серверов: задержка одного соединения тормозит всю операцию.
⏺ Как с этим бороться?
В датацентрах используют ECN, чтобы сигнализировать о перегрузке до переполнения буферов, а также подходящие алгоритмы управления перегрузкой.
На уровне приложения помогает ограничение числа одновременных ответов или распределение их во времени.
N.A.
В датацентре может возникнуть странная ситуация: сеть почти не загружена, но распределённое приложение периодически сталкивается с резкими задержками.
Причина может быть в TCP Incast — эффекте, когда множество серверов одновременно отправляют данные одному получателю.
Допустим, приложение запрашивает данные сразу у 100 серверов. Каждый отправляет ответ размером 256 КБ.
В сумме это 25 МБ данных, которые почти одновременно направляются к одному получателю.
Даже если каждый сервер подключён через 10 или 25 Гбит/с, выходной порт коммутатора в сторону получателя имеет ограниченную пропускную способность.
Входящий поток на короткое время превышает возможности выходного порта, и очередь начинает быстро заполняться.
Когда буфер переполняется, коммутатор отбрасывает пакеты. Если потери затрагивают сразу несколько TCP-соединений, часть отправителей вынуждена повторно передавать данные.
В некоторых случаях восстановление требует ожидания RTO, что резко увеличивает время выполнения всего запроса.
Особенно неприятно, когда приложение ждёт ответы от всех серверов: задержка одного соединения тормозит всю операцию.
В датацентрах используют ECN, чтобы сигнализировать о перегрузке до переполнения буферов, а также подходящие алгоритмы управления перегрузкой.
На уровне приложения помогает ограничение числа одновременных ответов или распределение их во времени.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2