Возвращаясь к проблемам удаленного мониторинга - 2
Первая проблема — упрощение идентификации портов и установление их соответствия реальным физическим соединениям. RMON осуществляет это с помощью более старой базы управляющей информации — MIB2 (RFC 1213), разработанной первоначально для маршрутизаторов. Она включает в себя элемент, в котором есть так называемая ifIndex — таблица для каждого интерфейса на устройстве. Их нумерация в таблице производится последовательно, начиная с 1 или 0. Однако эти числа не вполне соответствуют физическим номерам портов на коммутаторе, делая проблематичной интерпретацию данных RMON. Модульный коммутатор еще больше усложняет дело: добавление платы может изменить последовательность номеров. Каждый интерфейс в ifIndex способен включать свое описание, позволяя поставщикам для облегчения проблемы помещать в указанное поле данные — такие, как скорости портов и описания сред передачи.
ПО Nethealth фирмы Concord Communications создает запись в базе данных для каждого порта, из которого собирает данные. А определяемое пользователем поле позволяет дать порту более осмысленное описание, например физический номер порта. Поступление и обновление подобной информации нелегко масштабировать, поэтому стоит ограничиться ключевыми соединениями, подобными тем, что находятся на магистралях.
С коммутаторами связана еще одна проблема. Магистральные соединения обычно работают в режиме дуплекса, обеспечивая два отдельных физических соединения “точка—точка”. RMON был разработан для прослушивания сетей с разделяемой средой передачи, поэтому он не в силах различать оба направления дуплексного соединения. RMON недооценит доступную пропускную способность, по крайней мере наполовину.
Типы компьютерных сетей
