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

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

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

Изначально медиаконвертер — это конвертер среды передачи, то есть он преобразует электрический сигнал в оптический и наоборот. Разумеется, там не все так просто, но главное, это уровень L1 в модели OSI.

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

Как только вам нужно иметь разные скорости, вам понадобится как минимум буфер.

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

Чем это плохо спросите вы? да в общем для медиаконвертера плохо по целому ряду причин.

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

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

Как на маршрутизаторах с Cisco IOS XE типа ISR4000 C8200, объединить в один L2 сегмент, порт на шасси и на NIM карте. Редкий, но интересный кейс. Описывается настройка Bridge-Domain и некоторые неочевидные вещи.

В этой статье я попробую рассказать о том, в каких случаях для выявления неисправностей в сети может быть полезно, помимо опроса оборудования, принимать сообщения о наступившем событии от устройства. Мы разберём, как работает гарантированная доставка информации о событии, чем Inform лучше чем Trap и в чём сложности его использования. Немного углубимся в детали работы Trap/Inform-сообщений, а закончим простым примером настройки Zabbix. Надеюсь, материал получился интересным и оригинальным.

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

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

Мне был необходим фундамент для создания:

Многоканальных сенсоров для PRTG

Утилит для сбора данных с сетевого оборудования, таких как MAC/ARP таблицы, режим работы портов, их состояние, информация о POE, информация о CDP/LLDP соседях и многое другое.

Приемника SNMP Trap/Inform сообщений версии 3 (с поддержкой смешанных трапов, как версии 2c так и 3 и с различными параметрами шифрования и аутентификации, то есть например часть оборудования шлет Trap и использует пользователя SNMPuser и использует шифрование DES, а часть использует пользователя useram и использует шифрование AES-256).

Утилит управления портами, POE и прочими функциями оборудования

Много внимания было уделено обработке ошибок и производительности.

Были изучены и учтены проблемы SNMP агентов на некотором оборудовании, с которыми мы столкнулись при использовании как gosnmp так и net-snmp и прочих библиотек.

Это вводная статья и надеюсь не последняя.