Что такое oam тест сетевого коммутационного оборудования

Ethernet OAM и CFM для коммутаторов

SUMMARY В этом разделе описывается, как интерфейсы Ethernet на Juniper Networks и операционной системе Juniper Networks Junos (Junos OS IEEE) для коммутаторов поддерживают стандарт 802.1ag для эксплуатации, администрирования и управления (OAM).

Понимание управления сбоями подключения Ethernet OAM для коммутаторов

Спецификация IEEE 802.1ag предусматривает управление неисправностями соединений Ethernet (CFM). CFM следит за сетями Ethernet, которые могут включать один или несколько экземпляров обслуживания из-за сбоей ненадежков к сети.

Основные функции CFM:

Наблюдение за ошибками с помощью протокола проверки целостности. Это протокол обнаружения и проверки состояния соседей, который обнаруживает и поддерживает соседства на уровне VLAN.

Обнаружение пути и проверка ошибок с помощью протокола linktrace.

Разлиять ошибки с помощью протокола обратной связи.

CFM разделит сервисную сеть на различные административные домены. Например, операторы, поставщики и клиенты могут явться частью различных административных доменов. Каждый административный домен соедему в один домен обслуживания, который предоставляет достаточно информации для выполнения собственного управления, избегая таким образом нарушений безопасности и делая возможным прямой мониторинг.

В домене технического обслуживания CFM каждый экземпляр службы называется обслуживаемой связью. Ассоциация обслуживания может быть схожа с полной сеткой конечных точек связи обслуживания (MEP), имеющих сходные характеристики. MEP – это активные объекты CFM, генерирующие и реагирующие на сообщения протокола CFM. Кроме того, существует промежуточная точка обслуживания (MIP), которая является объектом CFM, подобным MEP, но более пассивным (MIP отвечают только на сообщения CFM).

Каждый домен обслуживания связан с уровнем технического обслуживания от 0 до 7. Распределение уровня основано на сетевой иерархии, где внешним доменам назначен уровень выше, чем внутренним доменам. Настройте конечные точки клиента на наивысший уровень обслуживания в домене. Уровень домена обслуживания является обязательным параметром, который указывает на отношения вложенных параметров между различными доменами обслуживания. Уровень встроен в каждый кадр CFM. Сообщения CFM на заданном уровне обрабатываются MEP на этом же уровне.

Чтобы включить CFM на интерфейсе Ethernet, необходимо настроить домены обслуживания, связи обслуживания и конечные точки связи обслуживания (MEP). показывает отношения между доменами обслуживания, конечными точками связи обслуживания (MEP) и промежуточными точками обслуживания Рис. 1 (MPS), настроенными на коммутаторе.

Ограничения CFM на EX4600 коммутаторах

Начиная с Junos OS 18.3R1, Junos OS cfM поддерживается только EX4600. Поддержка CFM на EX4600 имеет следующие ограничения:

Поддержка CFM предоставляется программным обеспечением с использованием фильтров. Это может повлиять на масштабирование.

Режим inline модуль передачи пакетов (PFE) не поддерживается. В режиме inline PFE можно делегировать периодическую обработку пакетов (PPM) на модуль передачи пакетов (PFE), что приводит к более быстрой обработке пакетов и поддерживаемой интервалу CCM в 10 миллисекунд.

Мониторинг производительности (ITU-T Y.1731 Ethernet Service OAM) не поддерживается.

Интервал CCM менее 1 секунды не поддерживается.

CFM не поддерживается на маршрутных интерфейсах и агрегированных интерфейсах Ethernet (lag).

Функция половины MIP, поделить функциональность MIP на два однонаправленных сегмента для повышения зоны уверенного обслуживания сети, не поддерживается.

Up MEP не поддерживается.

Общее число поддерживаемых сеансов CFM составляет 20.

Ограничения CFM на коммутаторах серии QFX5120, QFX5200 и QFX5210

Начиная с Junos OS 18.4R1, Junos OS CFM поддерживается на QFX5200 и коммутаторах QFX5210. Начиная с Junos OS 19.4R1, Junos OS CFM поддерживается на коммутаторах QFX5120. Поддержка CFM на коммутаторах серии QFX5120, QFX5200 и QFX5210 имеет следующие ограничения:

Поддержка CFM предоставляется программным обеспечением с использованием фильтров. Это может повлиять на масштабирование.

Режим inline модуль передачи пакетов (PFE) не поддерживается. В режиме inline PFE можно делегировать периодическую обработку пакетов (PPM) на модуль передачи пакетов (PFE), что приводит к более быстрой обработке пакетов и поддерживаемой интервалу CCM в 10 миллисекунд.

Мониторинг производительности (ITU-T Y.1731 Ethernet Service OAM) не поддерживается.

Интервал CCM менее 1 секунды не поддерживается.

CFM не поддерживается на маршрутных интерфейсах и агрегированных интерфейсах Ethernet (lag).

Функция половины MIP, поделить функциональность MIP на два однонаправленных сегмента для повышения зоны уверенного обслуживания сети, не поддерживается.

Up MEP не поддерживается.

Общее число поддерживаемых сеансов CFM составляет 20.

Источник

Лабораторная работа: как мы тестируем российское сетевое оборудование

Привет, меня зовут Кристина, я работаю сетевым инженером в КРОК. Сейчас все чаще мы имеем дело с продукцией российских производителей.

В этом посте я опишу, как обстоят дела с импортозамещением, поделюсь методикой тестирования сетевого оборудования, которую мы разработали за годы работы. В конце расскажу, что нужно делать, чтобы строить надежные сети на базе отечественного железа.

Импортозамещение продолжается уже больше 5 лет, но раньше оно охватывало в основном ПО. А с конца 2020 года мы видим рост спроса и на российское железо, что связано с принятием новых постановлений правительства (ПП) по плану импортозамещения.

Одними из последних вышли постановления № 2013 и 2014. Они устанавливают % квот на закупку российского оборудования для компаний (и их дочек) с 50% участием государства. Сейчас уже идут обсуждения о методах контроля исполнения этих постановлений и мерах наказания в случае их невыполнения.

Мы уже давно готовимся к чему-то подобному и следим за российскими производителями.

Еще пять — шесть лет назад на рынке было полно «российского» железа, но сегодня уже недостаточно просто наклеить на китайский роутер новую этикетку. Российской считается только та продукция, которая прошла отбор и попала в реестр Минпромторга. Для этого нужно доказать, что сетевое оборудование спроектировано и собрано в России, и что его программное обеспечение разработано внутри страны.

Не так уж много компаний сумело это сделать. Самые заметные из них: ELTEX, QTECH, Полигон и Русьтелетех.

В теории, они производят все необходимое, чтобы строить на российском оборудовании корпоративные, промышленные, беспроводные сети и даже целые ЦОДы.

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

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

С тех пор прошло уже больше трех лет. Производственные линии отладили, качество объективно выросло, выбор расширился, но у российского железа по-прежнему есть особенности. Касаются они уже не функциональных возможностей и надежности, а скорее удобства эксплуатации и простоты управления. Что для нас с вами очень важно.

Большинство сетевых инженеров выросло на зарубежном оборудовании. То, к чему мы привыкли у Cisco и Huawei в российской продукции реализовано по-другому. Различаются интерфейсы и сами подходы к настройке, причем это не всегда отражено в документации. Из некоторых железок нельзя вытянуть полные логи, у других нет полноценного режима отладки. Из-за этого иногда непонятно, это баг, или ты просто делаешь что-то не так. Приходится тратить время, чтобы разобраться в чем дело, и все перепроверять.

С самого основания компании в КРОК есть серверная, где под эксперименты выделено несколько стоек. Раньше там изучали возможности Cisco и Huawei, но мы расширили эту зону и организовали лабораторию для испытаний российского сетевого оборудования.

Когда у вендора появляется что-то новенькое, мы заказываем образец для тестирования. Совсем как техноблогеры, разве что ролики для YouTube не снимаем.

В нашу лабораторию приезжают роутеры, маршрутизаторы, коммутаторы, файерволы, точки доступа — весь спектр сетевых решений. Так, мы уже испытали больше полусотни моделей разных российских производителей и выработали собственную методику. Это функциональное тестирование, которое опирается на документацию RFC и опыт наших сетевых инженеров.

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

Например, чтобы протестировать работу функции SSH мы собираем стенд сразу из нескольких коммутаторов и пары роутеров.

При сохранении сетевой топологии, допустимо использовать произвольную нумерацию интерфейсов

После этого мы настраиваем SSH на Router-Top, Router-Bottom, Switch-Top, Switch-Bottom и Switch, вводим команду show ip ssh. на каждом из устройств. Затем выполняем на рабочей станции соединение по SSH с каждым из устройств. Проверка считается пройденной, если сервис SSH запускается на 22 порту, и с каждым устройством устанавливается соединение SSH.

Всего мы проводим больше тридцати тестов, например: проверяем работу протоколов RIP, OSPF, различные атрибуты BGP. Тут нет ничего секретного, так что мы выложили эту методику в открытый доступ.

Помимо проверок маршрутизации, мы прогоняем стандартные тесты каналов по протоколу LACP, смотрим на работу MSTP, DHCP, HTTPS и IP SLA.Когда в лабораторию доставляют новое оборудование, мы настраиваем его через консоль и прогоняем тесты один за другим, вручную. Как правило, на полную проверку нужно 16–20 часов — 2–3 рабочих дня.

Время от времени мы находим мелкие баги. Например, на тестирование попал роутер, на котором мы настроили DHCP-сервер. Во время проверки, мы обнаружили, что в списке выданных клиентам IP-адресов присутствовали задвоенные записи для одного и того же клиента. На работу сети это не влияло, но могло здорово запутать администратора.

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

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

Если оборудование не проходит хотя бы один из тестов, мы штудируем документацию. Может быть, эта функция настраивается как-то иначе. Если не находим решения — обращаемся напрямую к вендору и описываем ситуацию.

На то, чтобы наладить контакт ушло много времени, но сейчас у нас есть прямая связь с российскими производителями. С ними можно оперативно проконсультироваться и, если мы действительно нашли баг, то максимум через неделю получим патч с исправлениями. До зарубежных вендоров гораздо сложнее достучаться.

В лаборатории мы не только проводим комплексные тесты нового оборудования, но и проверяем железо перед каждой инсталляцией — заранее собираем конфигурацию, которая будет у заказчика, и тестируем ее. Так мы можем решить возможные проблемы еще до выезда к клиенту. У инженеров в выездных командах появляется меньше седых волос, и такой подход сокращает время на пусконаладку.

Часто на установку нового оборудования в рабочую инфраструктуру дается всего 2–3 часа. Если не уложиться в это окно, придется возвращать все как было. В таких ситуациях лучше заранее посмотреть и убедиться, что оборудование настраивается и работает так, как ожидаешь.

Кроме того, мы часто перепроверяем уже протестированное железо. Российские производители дорабатывают прошивки, постоянно что-то меняют и часто выпускают крупные обновления. А мы держим руку на пульсе. Пускай, на проверки уходит много сил и времени, наша задача, как интегратора, защитить клиентов от неожиданностей.

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

В тестировании сетевого оборудования нет ничего сверхсложного, можете скачать нашу методику и самостоятельно проверить свое железо. Но, думаю, наша лаборатория еще долго не останется без работы. Чтобы оперативно устранить возможные проблемы с российской продукцией, нужен специфический опыт и связь с производителем. Так что не стесняйтесь обращаться за помощью.

Источник

Методика тестирования неуправляемых коммутаторов, версия 1.4

Тестирование неуправляемых коммуторов включает в себя физическое тестирование в реальной сети, анализ полученных данных и субъективные оценки функциональности и дизайна коммутатора.

Для первой части использовалась утилита IOMeter, разработанная компанией Intel. Больше компания не развивала этот продукт. Но некоторое время назад на сайте SourceForge появилась новая версия программы. К сожалению, она еще достаточно сырая — часто зависала во время тестирования. Поэтому в тестах используется версия программы от Intel.

Для снятия скоростных показателей передачи данных использовалась системная утилита операционной системы «Perfomance Monitor».

В качестве сетевых адаптеров использовались Intel Pro/100+ Management Adapter и 3COM 3c905B-TX с последними драйверами с сайта производителей. Сетевые карты Intel использовались только во множественных тестах (где работают больше двух компьютеров одновременно) и только на скоростях 100Mbit. Тесты с участием только двух компьютеров и где изменяется режимы работы сетевых карт (скорости и дуплекса), прогонялись на сетевых адаптерах от 3COM. Это связано с тем, что в процессе тестирования выяснилось — невозможно однозначно установить режим дуплекса и контроля потока при скорости 10Mbits на Intel адаптерах со стороны драйвера. К примеру, хотя последний и рапортует о выставлении 10Mbits/FDX/Flow=on, вполне вероятно что адаптер, тем не менее работает на 10Mbits/HDX/Flow=off. Но при выставлении нужной скорости со стороны управляемого коммутатора, адаптер правильно на нее переключался. Эта ситуация проверялась на разных компьютерах/драйверах и управляемых коммутаторах (Intel 460T и нескольких моделях от Cisco).

Физическое тестирование

Возможно, более наглядно это будет представить в виде таблицы:

Анализ полученных данных

Очевидно, что теоретически рассчитанный максимум не достижим практически. Хотя бы потому, что часть пропускной способности съедается служебными заголовками протоколов более низких уровней. Поэтому величина порядка 0.9 уже говорит об очень хорошем результате в тесте.

Далее, если в группе присутствует более одного теста, то каждому назначается в соответствие свой весовой коэффициент (безразмерная положительная величина, меньшая единицы; сумма всех весовых коэффициентов для каждой группы тестов равна единице). На этот весовой коэффициент умножается безразмерная величина, полученная в первой стадии. Полученные результаты, принадлежащие одной группе тестов, суммируются. В результате получаем набор безразмерных интегральных показателей по группам тестов. По ним и строим диаграммы.

Теперь рассмотрим деление тестов на группы и их весовые коэффициенты:

Весовые коэффициенты выбирались эмпирическим путем. Статистики по использованию коммутаторов в различных режимах у меня нет.

Функциональность и дизайн

Под функциональностью понимается как наличие дополнительных возможностей (типа QoS), так и «информативность» коммутатора. Так как для неуправляемых коммутаторов единственный способ передачи информации и статистики о своей работе — это светодиодные индикаторы, то оцениваем их количество и способность отразить максимум информации о порте — скорость работы, наличие полного дуплекса, обнаружение коллизии, индикация передачи данных, информацию об аварийном отключении порта. А также индикатор питания. В эту же категорию относим наличие (или соответственно отсутствие) порта «uplink».

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

Естественно, это не окончательный вариант методики, она будет дополняться шлифоваться. Любые Ваши предложения высказывайте в форуме.

Комментарии

Есть мнение, что выбранный размер кадра в 64KB — не оптимальный и на результаты тестирования оказывают сильное влияние конкретная реализация протокола. Вполне возможно. Было проведено небольшое сравнительное тестирование — передача данных со 100Mbits Full Duplex порта в 10Mbits Full Duplex порт с размером пакета в IOMeter от 1KB до 4MB. Результат можно видеть ниже (скорость указана в тысячах байт):

Но на достигнутом останавливаться не будем, дальнейшие тестирования в этом направлении будут продолжены.

Источник

LAG и средства обнаружения проблем

Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку?

Всё здесь прекрасно, LAG обеспечивает резервирование – один линк падает, LACP удаляет его и работаем на оставшихся. Казалось бы. Но известная многим проблема в том, что LACP никак не отследит такую ситуацию:

Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.

То есть между двумя маршрутизаторами ещё сеть SDH. OSN принимает Ethernet-кадры, инкапсулирует их в SDH-фреймы и отправляет их в плавание. С другого конца другой OSN вылавливает их, декапсулирует обратно Ethernet и возвращает их назад в IP-сеть.

Инженер остановил свой выбор на Ethernet OAM для детектирования проблемы и. ошибся. Сам я прежде не сталкивался с данным протоколом, поэтому в лаборатории собрал тестовый стенд без SDH сети – всё работает. SDH не стал настраивать по той простой причине, что это транспорт – какая ему разница, что передавать? Резать и дропать он ничего не должен – что получил, то и отправил. У меня работает, у заказчика нет – начинаем углубляться в детали.

Для начала разберёмся, что такое OAM вообще и как применяется.

OAM – Operation, Administration and Maintenance

Существует их два вида:

EFM OAM – Ethernet in First Mile. Преследует следующие цели: обнаружение партнёра, мониторинг линка, уведомление об авариях, Remote Loopback. EFM OAM соответствует стандарту 802.3ah и ориентирован на отслеживание состояния простого линка.

Ethernet CFM – Connectivity Fault Management – 802.3ag. Это механизм масштаба сети и призван обеспечивать End-to-End связность. Это достаточно мощный протокол и теоретически может использоваться для данных целей, но это всё равно, что поднимать OSPF между своим DLink и компьютером. Можно, но зачем?

Итак, поскольку был выбран EFM OAM, то копнём его поглубже.

EFM определяется на конкретном интерфейсе и может работать в двух режимах – Active и Passive. Только Active инициирует поиск соседа путём отправки OAMPDU в линк. Passive же слушает и отвечает на пришедшие запросы, но не может инициировать поиск соседа. Таким образом, хотя бы один из двух подключенных друг к другу интерфейсов должен иметь EFM в режиме Active. Вот типичная конфигурация:

interface GigabitEthernet1/1/4
eth-trunk 22
efm enable
efm trigger if-down

Последняя команда вынуждает устройство переводить интерфейс в состояние Down при наличии проблем. А вот так выглядит обмен любезностями и успешное установление сессии:

И вот тут, глядя на вид OAMPDU, я начинаю подозревать, что наличие SDH-сети в промежутке может играть фатальную роль. В качестве адреса отправителя стоит MAC-адрес Eth-trunk интерфейса, а вот в качестве получателя, какой-то специальный MAC-адрес, и EtherType – Slow Protocol.

Выдержка из Annex 57A к стандарту 802.3:

This address is within the range reserved by ISO/IEC 15802-3 (MAC Bridges) for link-constrained protocols. As such, frames sent to this address will not be forwarded by conformant MAC Bridges; its use is restricted to a single link

Дело в том, что EFM OAM относится к группе протоколов, скажем так, «одного линка». Их данные не могут покинуть один простой линк. Как только противоположное устройство принимает такой фрейм, оно его обрабатывает нужным образом и уничтожает, не передавая никуда дальше. То есть, когда с обратной стороны у нас стоит маршрутизатор/коммутатор с настроенным EFM на интерфейсе, он, приняв OAMPDU, проверяет его и отправляет ответ на R1, а старый кадр уничтожает. R1 получает OAMPDU от R2 и сессия установлена в лучшем виде.

В нашем же случае OSN, получив такой фрейм, просто отбрасывает его, потому что никакого EFM на нём не запущено.

Для очистки совести я собрал полностью аналогичную схему и увидел, что R1, как активный член партии отсылает данные, но ничего не получает в ответ. А на R2 совсем всё тихо.

debugging efm interface GigabitEthernet 1/1/4 all
Info: Operation succeeded.
May 14 2013 09:18:26.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

May 14 2013 09:18:27.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

May 14 2013 09:18:28.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине.

Спасение

Единственный здесь выход – это использование BFD – Bidirectional Forwarding Detection. В то время, как EFM свои данные инкапсулирует напрямую в Ethernet, BFD использует IP и UDP. То есть для него никакой трудности не представляют промежуточные L2-устройства.

BFD отправляет свои пакеты на мультикастовый адрес 224.0.0.184 и, если противоположное устройство настроено соответствующим образом, оно высылает ответные пакеты – BFD-сессия поднимается. Вот пример конфигурации, которая принуждает устройство погасить интерфейс в случае проблем:

R1
bfd TEST bind peer-ip default-ip interface GigabitEthernet1/1/4
discriminator local 10
discriminator remote 11
process-interface-status
commit

R2
bfd TEST bind peer-ip default-ip interface GigabitEthernet1/1/4
discriminator local 11
discriminator remote 10
process-interface-status
commit

Первой строкой задаём привязку BFD к физическому интерфейсу. Далее определяем дискриминаторы – обязательный параметр BFD, позволяющий различать сессии. И командой process-interface-status указываем, что устройство должно гасить интерфейс, если BFD обнаружил проблему.

В случае проблемы на линке BFD это сразу замечает:

May 14 2013 09:45:45+03:00 R2 %%01BFD/4/STACHG_TODWN(l)[23]:Slot=1;BFD session changed to Down. (SlotNumber=1, Discriminator=20, Diagnostic=DetectDown, Applications=IFNET, ProcessPST=False, BindInterfaceName=GigabitEthernet1/1/6, InterfacePhysicalState=Up, InterfaceProtocolState=Down)

Статус интерфейса принимает вид:

[R2]dis int br
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Aux0/0/1 down down 0% 0% 0 0
Eth-Trunk22 up up 0.05% 0.05% 0 0
GigabitEthernet1/1/4 up up 0.05% 0.05% 0 0
GigabitEthernet1/1/6 up up(b) 0% 0% 0 0

[R2]dis int gig1/1/6
GigabitEthernet1/1/6 current state : UP
Line protocol current state : UP(BFD status down)

Вообще говоря, многие устройства поддерживают команды, которые позволяют «прокидывать» данные Slow Protocls, но это от лукавого.

В общем решение предоставлено, инженер счастлив, а я узнал для себя что-то новое.

Источник