Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

VPS в России, Европе и США

Бесплатная поддержка и администрирование

Оплата российскими и международными картами

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Управление в сетях 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.

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

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...