Описание протокола SNMP. Автоматическая пинговалка.

Новости.

После долгого перерыва на сайте вновь заработал поиск. Попытки заменить чем-то капризный поисковый механизм dig привели к неутешительному выводу - приличных систем с русской морфологией в свободном доступе не наблюдается. А в бесплатном модуле Yandex'а установлено ограничение в 5 Мб текста, далее ценовая линейка начинается с $500 и заканчивается $15 000. Совсем даже не даром, что тут еще сказать...

Не удержусь, проанонсирую бомбу следующего выпуска. К выкладыванию в сеть подготавливаются шаблоны (реальные документы) для получения лицензий на телематику, СПД, строймонтаж, проектирование и генподряд. Надеюсь, ссылочка получится весьма и весьма популярной среди Ethernet-провайдеров. :-)

Перед излишне серьезным материалом о SNMP приведу интересную картинку:

Такой вот оптоволоконный трансивер из оптики в AUI. Солидное устройство, напоминающее размерами старый катушечный магнитофон... Но ведь работает, сколько лет прошло - а все в строю.

Управляемые коммутаторы (окончание).

Сотрудничество с Михаилом Кузьминым (aka ArchNet) оказалось очень плодотворным. Ниже представлена очередная "порция" информации, почерпнутой из его писем.

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

Перед классификацией коммутаторов (#76) обязательно нужно сказать несколько слов об архитектуре свитча. Он содержит:
1. Высокоинтегрированный чип (контроллер), в котором есть процессор, спецпрограмма, интерфейсы с портами, EEPROM, (а современные модели - еще и все буфера).
2. Внешний процессор (с соответствующим программным обеспечением), который может присутствовать в реальном свитче, а может - и нет.

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

Далее, надо сказать еще несколько слов про коммутатор CeLAN EtherSW 1201Gi, с которого, собственно, и началось это повествование (#75). Дальнейшие исследования его параметров выявили следующее:

Маршрутизирует он все-таки медленно: достигнутая ранее скорость оказалась для него предельной, более точно, на ftp-сессиях наблюдалось 0.65-0.7MByte/s.

Ограничение скорости не связано с глючностью данного экземпляра, что подтверждено контрольным экспериментом. Тот же файл качался через коммутатор, но оба линка подключались одному и тому же VLAN'у (при этом не требуется работа по маршрутизации) - в этом случае наблюдались нормальные 10.5MByte/s.

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

Так что все противоречия разъясняются: это - не L3-свитч, а обычный (L2) свитч + обычный (не-аппаратный) маршрутизатор. Скорость маршрутизации при этом далека от wire-speed скорости свитча. Таким образом, становится понятно, почему производитель эту опцию даже не упоминает в спецификации (небольшой отрывок из которой был выложен на сайте в позапрошлом обзоре)...

Ну и как окончание материала о коммутаторах нужно сказать несколько слов о протоколе SNMP (Simple Network Management Protocol), который назвали "Simple" словно в издевательство над сетевыми администраторами.

SNMP - самый общий стандарт представления базы Административной Информации (Management Information Base, MIB), и протокола обмена информацией статистического характера о трафике и внутреннем состоянии устройств. Вопрос описания SNMP в общем виде обширен, и в отечественной практике (за отсутствием действительно больших сетей) слабоизучен.

Для Etherenet и свитчей интересны только его расширения - RMON и SMON, которые описаны ниже (только RMON-I, а еще есть RMON-II - по более высоким уровням OSI, и SMON специально по свитчевым наворотам - VLAN, QoS и т.п.)

В свитчах "среднего уровня" обычно реализовано не очень много - группы RMON 1-4 и 9, на этом все и заканчивается.

RMON используется для мониторинга достаточно больших сетей: RMON-агенты на свитчах шлют информацию на центральный компьютер админа, где стоит, скажем, HP OpenView. И админ не только видит красочную картинку всей своей сети с текущими трафиками по портам/устройствам, а получает удобный инструмент.

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

Можно, в принципе, на этом даже биллинг строить. Почти наверняка в будущем так и будет, а пока использование коммутаторов в качестве поставщика биллинговой информации по меньшей мере экзотично (но реально используется в одной из Питерских сетей, о чем есть упоминание в #70).

Стандарт RMON-I MIB описывает 9 групп объектов:

1. Statistics - текущие накопленные статистические данные о характеристиках кадров, количестве коллизий, ошибочных кадров (с детализацией по типам ошибок) и т.п.
2. History - статистические данные, сохраненные через определенные промежутки времени для последующего анализа тенденций их изменений.
3. Alarms - пороговые значения статистических показателей, при превышении которых агент RMON генерирует определенное событие. Реализация этой группы требует реализации группы Events - события.
4. Host - данные о хостах сети, обнаруженных в результате анализа MAC-адресов кадров, циркулирующих в сети.
5. Host TopN - таблица N хостов сети, имеющих наивысшие значения заданных статистических параметров.
6. Traffic Matrix - статистика о интенсивности трафика между каждой парой хостов сети, упорядоченная в виде матрицы.
7. Filter - условия фильтрации пакетов; пакеты, удовлетворяющие заданному условию, могут быть либо захвачены, либо могут генерировать события.
8. Packet Capture - группа пакетов, захваченных по заданным условиям фильтрации.
9. Event - условия регистрации событий и оповещения о событиях.

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

Поэтому, не лишне иметь об этом хотя бы самое общее представление. Может оказаться, что какая-то опция (ранее казавшаяся недостижимой мечтой) давно реализована в устройстве, стоящем в ваше сети.

Разное

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

Линукс, тонкий и склизкий,
Глянцевит, страшен, бел,
Гложет слоты и диски,
Лижет кулер, пробел.

Вспыхнет красным и черным,
И потянется вдаль
Жалом красным, проворным,
Бычья туша - нетварь.

А за лесом синеет,
Сладко манит вдали,
Страшной сказкой взлелеет
Твою душу - NT.

Stealth Bug

Забавно развивается ситуация с сетевым спамом. Аудитория Рунета в своей массе еще не имеет должной подготовки к его правильному восприятию (инстинктивному нажатии кнопочки Del). Поэтому спам эффективен (мне известны вполне солидные офф-лайновые коммерсанты, которые внимательно читают рекламные письма, и даже пытаются на них отвечать).

Но когда получаешь наимахровейший спам (переслал Матроскин) от бренда российского масштаба, начинаешь задумываться, все ли в порядке с понятиями сетевой этики.
Вот он:
Тема: ИД "Коммерсантъ" спец. предложение.
Уважаемые господа!
Издательский Дом "Коммерсантъ" представляет ежемесячное приложение ...

Какой прогресс, однако. Год назад подобные письма рассылали только юные любители халявы. И вот, докатились. Даже слово придумали "директ-мейл". Директ - на деревню, дедушке. Тьфу!

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

Система управления домашней сетью

Продолжение (и очень надеюсь, что не окончание) переработанного рассказа Александра Горбатенко, начало см. #73.

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

Представляет оно из себя совершенно автономное устройство, не содержащее никакой процессорной части. Вся схема состоит из простой логики. В ПЗУ записан Ethernet-кадр, который в заголовке содержит адрес сервера, МАС адрес карточки и свой адрес.

Такой подход имеет некоторые недостатки.
Во-первых, появляются сложности при замене сетевой карты и IP адреса на сервере, т.к. в этом случае придется менять все ПЗУ на "пинговалках". Хотя MAC-адрес всегда можно поменять, а в качестве IP использовать фиктивную сеть.
Во-вторых, нет контроля коллизий, поэтому "пинговалки" можно подключать только к свитчам.

При всей внешней неуклюжести, подобная схема достаточно универсальна. ПЗУ достаточно большое, в нем записаны несколько вариантов пакетов, которые меняются перебором старших адресов. Т.е. вариантом ответа можно управлять. У автора разработки этим занимается... Источник питания, который формирует сигналы "пропадание 220В", "зарядка аккумулятора", "выход из строя аккумулятора", а так же от состояние наружных датчиков.

В общем, возможно до 8 отдельных сигналов на два состояния ("1" или "0"). Пакеты идут с паузой 4-6 секунд, поэтому даже 20-30 секундные перерывы вполне можно отслеживать.

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

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

При наличии "Пинговалки" специальная программа контролирует периодичность и наличие пакетов. Для удобства администратора может формироваться HTML страничка типа www.topol.dp.ua/ping.html, а при возникновении нештатной ситуации отсылается SMS сообщение на мобильные телефоны, и E-mail.

Таким образом, про нарушение связи становится известно через несколько секунд (время, пока идет SMS сообщение). А это означает принципиально иной уровень сервиса.

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

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

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

Но у них тоже есть недостатки. Время между перезагрузками выставляется от 30 минут до 2 часов. Таким образом, если в цепочке от сервера до потребителя стоит 20 свитчей со "сбрасыванием" каждые 2 часа, пропадание связи на две секунды происходит примерно каждые 120/20=6 минут.

При серфинге это не чувствуется, но при игре на игровом сервере заметны подтормаживания (не говоря уже от IP телефонии и т.п.). И самое обидное, что 99% сбрасываний происходит в пустую.

Поэтому следующим этапом стала разработка интеллектуального сброса. Если мы постоянно контролируем связь при помощи "пинговалок", мы владеем мгновенной информацией о зависании свитча. Значит, надо только заставить все свитчи сбросится по цепочке от сервера до самой "пинговалки".

Получится так называемая волна сбрасывания. Для этого был разработали "магистральный блок питания версия 2". Он содержит PIC контроллер, которому проще контролировать заряд и работоспособность аккумулятора. Но самое главное, он контролирует (при помощи высокоомного входа) наличие "линка" с предыдущего ящика.

Когда "линк" пропадает на доли секунды, он не реагирует, а когда пауза увеличивается до 2 секунд, он сбрасывает свой свитч (или хаб) на 2 секунды, тем самым подавая сигнал на следующий ящик по магистрали. Получается что-то похожее на цепную реакцию или принцип домино ;-)

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

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

Обсудить в форуме

Анонс

Постараюсь поднять вопрос, который всегда вызывает жаркие споры - 10 или 100 мегабит использовать? Фоном для этой сверхтемы будут служить разъемы от Phoenix и текущие новости, а в практической части планируется программная часть сети в Днепропетровске.