Сервер Информационных Технологий содержит море(!) аналитической информации |
Сервер поддерживается |
---|
В отношении сетевого управления протокол 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, которая определяет, какую информацию о кадрах (называемых в стандарте пакетами) 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.