Новые книги

Эта книга исключительна полезна. С одной стороны она про такой хорошо (если не излишне) раскрученный термин как Scrum, на который ведутся большинство (если не все) начальников. С другой стороны, она упирает на то, что Scrum без инженерных практик не живёт. Не знаю сознательно ли Хенрик заложил этот месадж в книгу или так получилось случайно, но получилось именно то, что доктор прописал :-)
Эта книга помогает не просто определить факторы популярности, но и предлагает набор конкретных прикладных методик для создания сообщений или рекламы, которыми люди охотно будут делиться друг с другом.

Чем бы вы ни занимались, эта книга поможет вам сделать так, чтобы о вашем продукте или идее заговорили.

На русском языке публикуется впервые.

Управление в сетях Fast Ethernet. Параметры протокола Ethernet, отслеживаемые агентами SNMP и RMON

 

Управление в сетях Fast Ethernet. Параметры протокола Ethernet, отслеживаемые агентами SNMP и RMON

В отношении сетевого управления протокол Fast Ethernet ничем не отличается от классического 10-Мегабитного Ethernet'a. Для сбора информации о состоянии коммуникационных устройств, поддерживающих Fast Ethernet, и управления этими устройствами по сети используется протокол SNMP и агенты, встроенные в устройства, либо выполненные в виде автономных зондов.

Агенты большинства производителей поддерживают в настоящее время как классическую для сетей TCP/IP базу управляющей информации MIB II (RFC-1213), так и базу RMON MIB, специально ориентированную на протоколы нижнего уровня Ethernet и Token Ring.

База MIB II ориентирована в основном на сбор статистики о протоколах сетевого и транспортного уровней стека TCP/IP, а протоколам физического и канального уровней, таким как Ethernet (и, соответственно Fast Ethernet) в ней уделяется не так много внимания.

Из многочисленных объектов, определенных в MIB II, работу коммуникационного устройства (повторителя, моста, коммутатора, маршрутизатора, сетевого адаптера) по протоколу Ethernet отражают в основном объекты группы Interfaces. Эти объекты описывают каждый порт устройства в параметрах протокола канального уровня, то есть уровня Ethernet.

В число объектов, описывающих каждый конкретный интерфейс устройства, включены следующие:

ifType - тип протокола, который поддерживает интерфейс.

Этот объект принимает значения всех стандартных протоколов канального уровня, например, rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing, и т.д.

ifMtu - максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс.

ifSpeed - пропускная способность интерфейса в битах в секунду (100 для Fast Ethernet).

ifPhysAddress - физический адрес порта, для Fast Ethernet им будет MAC-адрес.

ifAdminStatus - желаемый статус порта:

up - готов передавать пакеты ready to pass packets;

down - не готов передавать пакеты;

testing - находится в некотором тестовом режиме.

ifOperStatus - фактический текущий статус порта, имеет те же значения, что и ifAdminStatus.

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

ifInUcastPkts - количество пакетов с индивидуальным адресом интерфейса, доставленных протоколу верхнего уровня.

ifInNUcastPkts - количество пакетов с широковещательным или мультивещательным адресом интерфейса, доставленных протоколу верхнего уровня.

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

ifInErrors - количество пришедших пакетов, которые не были переданы протоколу верхнего уровня из-за обнаружения в них ошибок.

Кроме объектов, описывающих статистику по входным пакетам, имеются аналогичные объекты, но относящиеся к выходным пакетам.

Как видно из описания объектов MIB-II, эта база данных не дает детальной статистики по характерным ошибкам кадров Ethernet, кроме этого она не отражает изменение характеристик во времени.

Все эти возможности и многие другие полезные свойства реализованы в стандарте RMON MIB, описанном в RFC-1757.

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

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

Рассмотрим более подробно группу Statistics, которая определяет, какую информацию о кадрах (называемых в стандарте пакетами) Ethernet может предоставить агент RMON. Группа History основана на объектах группы Statistics, так как ее объекты просто позволяют строить временные ряды для объектов группы Statistics.

В группу Statistics входят наряду с некоторыми другими следующие объекты:

etherStatsDropEvents - общее число событий, при которых пакеты были проигнорированы агентом из-за недостатка его ресурсов. Сами пакеты при этом не обязательно были потеряны интерфейсом.

etherStatsOctets - общее число байт (включая ошибочные пакеты), принятые из сети (исключая преамбулу, н включая байты контрольной суммы).

etherStatsPkts - общее число полученных пакетов (включая ошибочные).

etherStatsBroadcastPkts - общее число хороших пакетов, которые были посланы по широковещательному адресу.

etherStatsMulticastPkts - общее число хороших пакетов, полученных по мультивещательному адресу.

etherStatsCRCAlignErrors - общее число полученных пакетов, которые имели длину (исключая преамбулу) между 64 и 1518 байтами, не содержали целое число байт (alignment error) или имели неверную контрольную сумму (FCS error).

etherStatsUndersizePkts - общее число пакетов, которые имели длину, меньше, чем 64 байта, но были правильно сформированы.

etherStatsOversizePkts - общее число полученных пакетов, которые имели длину больше, чем 1518 байт, но были тем не менее правильно сформированы.

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

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

etherStatsCollisions - наилучшая оценка числа коллизий на данном сегменте Ethernet.

etherStatsPkts64Octets - общее количество полученных пакетов (включая и плохие), размером в 64 байта.

etherStatsPkts65to127Octets - общее количество полученных пакетов (включая и плохие), размером от 65 до 127 байт.

etherStatsPkts128to255Octets - общее количество полученных пакетов (включая и плохие), размером от 128 до 255 байт.

etherStatsPkts256to511Octets - общее количество полученных пакетов (включая и плохие), размером от 256 до 511 байт.

etherStatsPkts512to1023Octets - общее количество полученных пакетов (включая и плохие), размером от 512 до 1023 байт.

etherStatsPkts1024to1518Octets - общее количество полученных пакетов (включая и плохие), размером от 1024 до 1518 байт.

Как видно из описания объектов, с помощью агента RMON, встроенного в повторитель или другое коммуникационное устройство, можно провести очень детальный анализ работы сегмента Ethernet или Fast Ethernet. Сначала можно получить данные о встречающихся в сегменте типах ошибок в кадрах, а затем целесообразно собрать с помощью группы History зависимости интенсивности этих ошибок от времени (в том числе и привязав их ко времени). После анализа временных зависимостей часто уже можно сделать некоторые предварительные выводы об источнике ошибочных кадров, и на этом основании сформулировать более тонкие условия захвата кадров со специфическими признаками (задав условия в группе Filter), соответствующими выдвинутой версии. После этого можно провести еще более детальный анализ за счет изучения захваченных кадров, извлекая их из объектов группы Packet Capture.

Предыдущая глава | Оглавление | Следующая глава