В отношении сетевого управления протокол 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.
Когда тот или иной физик использует понятие "физический вакуум", он либо не понимает абсурдности этого термина, либо лукавит, являясь скрытым или явным приверженцем релятивистской идеологии.
Понять абсурдность этого понятия легче всего обратившись к истокам его возникновения. Рождено оно было Полем Дираком в 1930-х, когда стало ясно, что отрицание эфира в чистом виде, как это делал великий математик, но посредственный физик Анри Пуанкаре, уже нельзя. Слишком много фактов противоречит этому.
Для защиты релятивизма Поль Дирак ввел афизическое и алогичное понятие отрицательной энергии, а затем и существование "моря" двух компенсирующих друг друга энергий в вакууме - положительной и отрицательной, а также "моря" компенсирующих друг друга частиц - виртуальных (то есть кажущихся) электронов и позитронов в вакууме.
Однако такая постановка является внутренне противоречивой (виртуальные частицы ненаблюдаемы и их по произволу можно считать в одном случае отсутствующими, а в другом - присутствующими) и противоречащей релятивизму (то есть отрицанию эфира, так как при наличии таких частиц в вакууме релятивизм уже просто невозможен). Подробнее читайте в FAQ по эфирной физике.