Skip to content
Все статьи
Маршрутизация и коммутация

Как мы тестируем PoE: бюджет мощности, приоритеты и отказ БП

Alexander Zemskov 4 мин чтения
Как мы тестируем PoE: бюджет мощности, приоритеты и отказ БП

В даташите PoE-коммутатора покупатель читает две строки: «PoE+ на всех 48 портах» и бюджет мощности, например 740 Вт. 48 портов по 30 Вт дают 1440 Вт. Обе строки честные, просто одновременно они не выполняются. Покупатель считает камеры и точки доступа по плану этажа. Коммутатор считает ватты, резервирует их по классам и решает, какой порт погаснет, когда сумма кончится. Мы проверяем эту арифметику с нагрузкой на каждом порту, данными через те же порты и блоком питания, который вынимаем посреди теста.

Стенд

Коммутатор, инжектор или midspan стоит на стенде CloudLAB, его access-порты подключены к эмулированным потребителям (PD). Каждый из них – программируемая нагрузка: отвечает на detection и классификацию как реальное устройство класса от 0 до 8, запрашивает мощность по LLDP и потребляет заданный ток или профиль во времени. Данные проходят через нагрузку на порт генератора, поэтому ватты и кадры считаются на одном порту в одну и ту же секунду. Реальные устройства подключаем там, где результат решает их собственное поведение: точки доступа с Wi-Fi стенда, IP-камера, настольный телефон.

Конфигурация ваша: распределение по классу, по запросу LLDP или по фактическому потреблению, приоритеты портов, набор блоков питания, perpetual и fast PoE, прошивка. Трафик тот, что эти порты понесут на объекте: видео с камер, голос, аплинки точек доступа. Сам форвардинг описан в посте как мы тестируем коммутаторы; здесь коммутатор оценивается как источник питания.

Что проверяем

  • Detection и классификация по портам: классы 802.3af, 802.3at и 802.3bt от 0 до 8, устройства с single и dual signature, неверная сигнатура, на которую питание подаваться не должно
  • Согласование по LLDP: устройство просит больше или меньше своего класса, что выделяет коммутатор и сколько времени занимает выделение
  • Полный бюджет: все порты нагружены до максимума класса, ватты на порту коммутатора и на стороне устройства, сумма против даташита
  • Бюджет исчерпан: подключаем следующее устройство и смотрим, какой порт коммутатор не включит или отключит и решает ли это настроенный приоритет
  • Деградация питания: один блок из 2 вынимаем под полной нагрузкой; новый бюджет, отключенные порты и как быстро, затем блок обратно и время до повторной подачи питания
  • Пусковой ток и перегрузка: inrush по классам, устройство, которое тянет больше класса или закорочено, время отсечки и соседние порты, которые должны остаться под питанием
  • Данные при изменении питания: потери кадров и latency по портам, пока 24 устройства включаются разом, порт отключается по приоритету, нагрузка скачет
  • Перезагрузка с perpetual и fast PoE: питание на каждом порту при теплом рестарте и обновлении прошивки, разрыв в миллисекундах, через сколько холодный коммутатор запитывает порты

Что обычно ломается

Бюджет. В типичном проекте 48-портовый коммутатор с 740 Вт от 2 блоков питания распределяет мощность по классу: каждая AP класса 4 резервирует 30 Вт, а потребляет от 13 до 17 Вт. Порт 25 не получает питания при фактическом потреблении около 400 Вт. Распределение по запросу LLDP (18 Вт на AP) пускает 41 порт. Затем вынимаем один блок: бюджет падает вдвое, коммутатор за 2 секунды отключает 21 порт, на 3 из них камеры с пометкой critical. Приоритет задан на портах, отключение шло по номеру порта.

Точка доступа. AP нужно 30 Вт на стороне устройства для всех радио, а стоит она на порту PoE+. Приходит 25,5 Вт, точка загружается в урезанном режиме и выключает одно радио. В логе коммутатора порт поднят и запитан, хотя план покрытия рассчитан на все радио.

Обновление. Perpetual PoE включен и держит питание при теплом рестарте. Обновление прошивки идет другим путем: порты теряют питание на 3 секунды, все камеры перезагружаются, и каждая около 90 секунд ничего не пишет. Тест с 40 подключенными камерами это показывает, тест на пустом коммутаторе нет.

Что в отчете

Таблицу по портам: определенный класс, мощность, запрошенная по LLDP и выделенная, ватты на коммутаторе и на устройстве, вердикт по каждому пункту. Кривую бюджета по портам с точкой, где коммутатор отказывает, и порядком отключения для каждого состояния блоков питания. Разрывы питания и данных по каждому событию (отказ блока, перегрузка, рестарт, обновление) в миллисекундах, с потерями кадров и latency по портам. Собственные ватты коммутатора на Gbps идут отдельным пунктом, см. энергопотребление под нагрузкой. Для шорт-листа одну таблицу на всех кандидатов: «PoE+ на всех портах» превращается в число устройств, которые каждый коммутатор на деле запитает.

С чего начать

Пришлите нам модели коммутаторов, список устройств на каждый коммутатор с их классами и прошивку, которую планируете запускать. Мы ответим черновиком тест-плана: пункты проверки, схема стенда и сроки. Отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.

Автор

Alexander Zemskov

Эксперт по тестированию сетей и безопасности, продажи (19+ лет) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel и другое

Блог

Читайте также

Стандарты и методика

Как мы автоматизируем регрессию сети: каждая сборка и один diff

В release notes новой прошивки написано «исправления ошибок и улучшения производительности». Вторую половину фразы никто не измеряет. Ручная регрессия занимает у инженера…

Alexander Zemskov 4 мин чтения
Маршрутизация и коммутация

Как мы тестируем пакетные брокеры: дедупликация и slicing

В даташите пакетного брокера перечислены line rate на всех портах, дедупликация, packet slicing, снятие туннельных заголовков и несколько тысяч правил фильтрации. Каждая …

Alexander Zemskov 4 мин чтения