kantrium.com | E-Norway.ru | HELFI.ru | MySuomi.com

Прозрачное объединение сетей с помощью мостов

Прозрачные мосты (ТВ) были впервые разработаны Digital Equipment Corporation в начале 1980 гг. Digital представила свою работу в IEEE, который включил ее в стандарт IEEE 802.1. ТВ очень популярны в сетях Ethernet/IEEE 802.3.

 

Основы технологии

ТВ названы так потому, что их присутствие и работа являются прозрачными для хостов сети. После подачи питания на ТВ, они узнают о топологии сети путем анализа адреса источника блоков данных, прихо­дящих из всех других подключенных сетей. Например, если мост видит, что какой-нибудь блокданных поступил налинию 1 из ХостаА, он дела­ет вывод, что до Хоста А можно добраться через сеть, подключенную к линии 1. С помощью этого процесса ТВ строят таблицу.

Host address

Network number

15

1

17

1

12

2

13

2

12

1

9

1

14

3

   

Мост использует свою таблицу в качестве базиса для продвижения трафика. Когда на один из интерфейсов моста принят блок данных, мост ищет адрес пункта назначения этого блока данных в своей внутренней таблице. Если таблица содержит взаимосвязь между адресом пункта на­значения и любым из портов этого моста, за исключением того, в кото­рой был принят этот блок данных, то блок данных продвигается из ука­занного порта. Если не найдено никакой взаимосвязи, то блок данных отправляется лавинной адресацией во все порты, кроме порта вхождения блока данных. Широковещательные сообщения и сообщения много­пунктовой адресации также отправляются лавинной адресацией таким же образом.

ТВ успешно изолирует внутрисегментный трафик, тем самым со­кращая трафик, видимый в каждом отдельном сегменте. Это обычно улучшает время реакции сети, видимое пользователю. Степень сокраще­ния трафика и улучшения времени реакции зависят от объема межсег­ментного трафика относительно общего трафика, а также от объема ши­роковещательного и многопунктового трафика.

Петли в сетях, объединенных с помощью мостов

Без протокола взаимодействия между мостами алгоритм ТВ отка­зывает, когда между двумя любыми LAN объединенной сети имеется не­сколько трактов, включающих в себя мосты и локальные сети.

Помимо основных проблем связности, потенциально серьезной проблемой является размножение широковещательных сообщений в се­тях с петлями.

Топология с петлями может быть полезной, но также и потенци­ально вредной. Петля подразумевает существование нескольких трактов через объединенную сеть. В сети с несколькими трактами от источника до пункта назначения общая помехоустойчивость может увеличиться благодаря улучшенной топологической гибкости.

Алгоритм связующего дерева (Spanning-Tree Algoritm) (STA)

Алгоритм был разработан для того, чтобы сохранить преимущест­ва петель, устранив их проблемы. Первоначально алгоритм был доку­ментирован корпорацией Digital — основным поставщиком Ethernet. Новый алгоритм, разработанный Digital, был впоследствии пересмотрен комитетом IEEE 802 и опубликован в спецификации IEE 802. Id в каче­стве алгоритма STA.

STA предусматривает свободное от петель подмножество тополо­гии сети путем размещения таких мостов, которые, если они включены, то образуют петли в резервном (блокирующем) состоянии. Порты бло­кирующего моста могут быть активированы в случае отказа основного канала, обеспечивая новый тракт через объединенную сеть.

STA пользуются выводом из теории графов в качестве базиса для построения свободного от петель подмножества топологии сети. Теория графов утверждает следующее: Для любого подсоединенного графа, состоя­щего из узлов и ребер, соединяющих пары узлов, существует связующее дере­во из ребер, которое поддерживает связность данного графа, но не содер­жит петель.

Каким образом STA устраняет петли? STA требует, чтобы каждо­му мосту был назначен уникальный идентификатор. Обычно этот иден­тификатор является одним из адресов MAC данного моста, который до­полнен приоритетом. Каждому порту во всех мостах также назначается уникальный (в пределах этого моста) идентификатор (как правило, его собственный адрес MAC). И наконец, каждый порт моста взаимосвязан с затратами какого-нибудь тракта. Затраты тракта представляют собой затраты на передачу какого-нибудь блока данных в одну из локальных сетей через этот порт.

Первым шагом при вычислении связующего дерева является вы­бор корневого моста (root bridge), который представляет собой мост с на­именьшим значением идентификатора моста. Допустим, корневым мос­том является Мост 1. Далее определяется корневой порт (root port) во всех остальных мостах. Корневой порт моста — это порт, через который можно попасть в корневой мост с наименьшими комбинированными за­тратами тракта. Эта величина (т.е. наименьшие комбинированные затра­ты тракта до корневого моста) называется затратами корневого тракта (root path cost).

И наконец, определяются назначенные мосты (designated bridges) и их назначенные порты (designated ports). Назначенный мост — это тот мост каждой локальной сети, который обеспечивает минимальные за­траты корневого тракта. Назначенный мост локальной сети является единственным мостом, который позволяет продвигать блоки данных в ту локальную сеть (и из нее), для которой этот мост является назначенным. Назначенный порт локальной сети — это тот порт, который соединяет ее с назначенным мостом.

В некоторых случаях два или более мостов могут иметь одинако­вые затраты корневого тракта.

Расчет связующего дерева имеет место при подаче питания на мост и во всех случаях обнаружения изменения топологии. Для расчета необходима связь между мостами связующего дерева, которая осуществ­ляется через сообщения конфигурации (иногда называемые протоколь­ными информационными единицами моста — bridge protocol data units, или BPDU). Сообщения конфигурации содержат информацию, иденти­фицирующую тот мост, который считается корневым (т.е. идентифика­тор корневого моста), и расстояние от моста-отправителя до корневого моста (затраты корневого тракта). Сообщения конфигурации также со­держат идентификаторы моста и порта моста-отправителя, а также воз­раст информации, содержащейся в сообщении конфигурации.

Мосты обмениваются сообщениями конфигурации через регуляр­ные интервалы времени (обычно 1-4 сек.). Если какой-нибудь мост отка­зывает (вызывая изменение в топологии), то соседние мосты вскоре об­наруживают отсутствие сообщений конфигурации и инициируют пересчет связующего дерева.

Все решения, связанные с топологией ТВ, принимаются логичес­ки. Обмен сообщениями конфигурации производится между соседними мостами. Центральные полномочия или администрация управления се­тевой топологией отсутствуют.

 

Формат блока данных (фрейма)

Мосты ТВ обмениваются сообщениями конфигурации (configura­tion messages) и сообщениями об изменении в топологии (topology change). Мосты обмениваются сообщениями конфигурации для установ­ления топологии сети. Сообщения об изменении топологии отправляют­ся после обнаружения какого-нибудь изменения в топологии для указа­ния того, что должен быть произведен повторный прогон STA.

Первым полем сообщения конфигурации ТВ является поле иден­тификатора протокола (protocol identifier), которое содержит нулевое значение.

Вторым полем в сообщении конфигурации ТВ является поле вер­сии (version), которое содержит нулевое значение.

Третьим полем в сообщении ТВ является поле типа сообщения (message type), которое содержит нулевое значение.

Четвертым полем в сообщении конфигурации ТВ является одно­байтовое поле флагов (flags). Бит ТС сигнализирует об изменении в топо­логии. Бит ТСА устанавливается для подтверждения приема сообщения конфигурации с установленным битом ТС. Другие шесть битов этого байта не используются.

Следующим полем в сообщении конфигурации ТВ является поле идентификатора корневого моста (root ID). Это 8-байтовое поле иденти­фицирует корневой мост путем перечисления его 2-байтового приорите­та, за которым следует его 6-байтовый ID.

За полем ID корневого моста идет поле затрат корневого тракта (root path cost), которое содержит затраты тракта от моста, который от­правляет конфигурационное сообщение, до корневого моста.

Далее идет поле идентификатора моста (bridge ID), которое иден­тифицирует приоритет и ID моста, отправляющего сообщение.

Поле идентификатора порта (port ID) идентифицирует порт, из которого отправлено конфигурационное сообщение. Это поле позволяет обнаруживать и устранять петли, образованные несколькими подклю­ченными мостами.

Поле возраста сообщения (message age) определяет промежуток времени, прошедшего с момента отправки корневым мостом конфигура­ционного сообщения, на котором базируется текущее конфигурацион­ное сообщение.

Поле максимального возраста (maximum age) указывает, когда те­кущее конфигурационное сообщение должно быть стерто.

Поле времени приветствия (hello time) обеспечивает период вре­мени между конфигурационными сообщениями корневого моста.

И наконец, поле задержки продвижения (forward delay) обеспечи­вает промежуток времени, в течение которого мосты должны выжидать, прежде чем перейти в новое состояние после изменения в топологии. Ес­ли переходы какого-нибудь моста происходят слишком быстро, то не все каналы сети могут оказаться готовыми для изменения их состояний, в результате чего могут появиться петли.

Сообщения о топологических изменениях состоят всего из 4 бай­тов. Они включают в себя поле идентификатора протокола (protocol iden­tifier), которое содержит нулевое значение, поле версии (version), кото­рое содержит нулевое значение и поле типа сообщения (message type), которое содержит значение 128.

 

Объединение сетей с помощью мостов «Источник-Маршрут»

Алгоритм Source-Route Bridging (SRB) (объединение с помощью мостов «источник-маршрут») был разработан IBM и предложен комите

ту ШЕЕ 802.1 в качестве средства объединения локальных сетей с помо­щью мостов. После того, как комитет предпочел другой конкурирующий стандарт, сторонники SRB предложили его комитету IEEE 802.5, кото­рый впоследствии включил его в спецификацию локальной сети IEEE 802.5/Token Ring.

За первым предложением IBM последовало предложение нового стандарта объединения с помощью мостов в комитет IEEE 802: Source-Route Transparent (SRT) (Прозрачное объединение «источник-марш­рут»). SRT полностью устраняет мосты «источник-маршрут» (SRB), предлагая взамен два типа мостов LAN-ТВ и SRT. Несмотря на то, что SRT получил одобрение, мосты SRB по-прежнему широко применяются в сетях.

Алгоритм SRB

Свое название мосты SRB получили потому, что они предполага­ют размещение полного маршрута от источника до пункта назначения во всех межсетевых (LAN) блоках данных, отправляемых источником. SRB хранят и продвигают эти блоки данных в соответствии с указаниями о маршруте, содержащимися в соответствующем поле блока данных.

Формат блока данных (фрейма)

Подполе типа (type) в RIF указывает на количество узлов, в кото­рые должен быть отправлен данный блок данных: в один узел, в группу узлов, включающих в себя связующее дерево данной объединенной сети, или во все узлы. Первый тип называется «специально направленным» (specifically routed) блоком данных, второй тип — «разведчиком связую­щего дерева» (spanning-tree explorer), а третий тип — «разведчиком всех трактов» (all-paths explorer). Разведчик связующего дерева может быть использован в качестве транзитного механизма для блоков данных с многопунктовой адресацией. Он может быть также использован в каче­стве замены разведчика всех трактов в запросах об исходящих маршру­тах. В этом случае пункт назначения в ответ присылает разведчика всех трактов.

Подполе длины (length) обозначает общую длину RIF в байтах.

Бит D указывает направление движения блока данных (прямое или обратное).

Поле «самый большой» (largest) обозначает самый большой блок данных, который может быть обработан вдоль всего этого маршрута.

Полей описателя маршрута (route descriptor) может быть несколь­ко. Каждое из них содержит пару «номер кольца/номер моста», которая определяет какую-нибудь часть маршрута. Таким образом, маршруты представляют собой просто чередующиеся последовательности номеров LAN и мостов, которые начинаются и заканчиваются номерами LAN.

Объединение смешанных носителей с помощью мостов

Прозрачные мосты (transparent bridges — ТВ) в основном встреча­ются в сетях Ethernet, в то время как мосты SRB встречаются почти ис­ключительно в сетях Token Ring. Оба метода объединения сетей с помо­щью мостов (ТВ и SRB) популярны, поэтому естественно возникает вопрос о существовании какого-нибудь метода, который позволил бы объединить их.

Основы технологии

Трансляционное объединение с помощью мостов (Translational bridging — TLB) обеспечивает относительно недорогое решение некото­рых из многочисленных проблем, связанных с объединением с помощью моста доменов ТВ и SRB. TLB впервые появился в середине-конце 1980 гг., но ни одна из организаций по стандартам не стала заниматься им. В результате многие аспекты TLB предоставлены для решения тому, кто реализует его.

В 1990 г. IBM устранила некоторые из недостатков TLB путем вве­дения «Прозрачного объединения с помощью моста «источник-марш­рут» (Source-Route Transparent-SRT). SRT может продвигать трафик из конечных узлов сети как с прозрачным объединением, так и с объедине­нием «источник-маршрут», и образовывать общее связующее дерево с мостами ТВ, позволяя тем самым конечным станциям каждого типа со­общаться с конечными станциями такого же типа в сети с произвольной топологией.

В конечном итоге, целью объединения доменов ТВ и SRB являет­ся возможность сообщения между конечными станциями ТВ и SRB.

Трудности трансляции

Существует ряд трудностей, связанных с обеспечением связи между конечными станциями домена Ethernet/ТВ и конечными станци­ями домена SRB/Token Ring, которые перечислены ниже:

♦     Несовместимый порядок организации битов. Хотя и Ethernet, и Token Ring поддерживают 48-битовые адреса MAC, внутреннее аппаратное представление этих адресов 

различно. Token Ring считает битом высшего порядка какого-нибудь байта первый бит, встречаемый в последовательном потоке битов, представляющим адрес. В Ethernet же, напротив, первый встреченный бит считается битом низшего порядка.

♦                Адреса встроенного управления доступом к носителю (MAC). В некоторых случаях адреса MAC фактически содержатся в информационной части блока данных. Например, Протокол разрешения адреса (ARP), который является популярным протоколом в сетях TCP/IP, размещает аппаратные адреса в информационной части блока данных канального уровня. Преобразование адресов, которые могут находиться в информационной части блока данных или их может не быть там, является нелегкой задачей, так как они должны обрабатываться индивидуально в каждом отдельном случае.

♦                Несовместимые максимальные размеры единиц передачи (MTU). Token Ring и Ethernet обеспечивают разные максимальные размеры блоков данных. MTU Ethernet равен примерно 1500 байтам, в то время как блоки данных Token Ring могут быть значительно больше. Так как мосты не могут выполнять фрагментацию и повторную сборку пакетов, то пакеты, превышающие MTU сети, должны быть отброшены.

♦                Обработка операций бита состояния блока данных. Блоки данных Token Ring содержат три бита состояния блока данных: А, С и Е. Назначение этих битов — сообщить источнику блока данных, видел ли пункт назначения этот блок данных (задан бит А), скопировал ли его (задан бит С) и (или) обнаружил ли ошибки в этом блоке данных (задан бит Е). Так как Ethernet не обеспечивает этих битов, то изготовителям моста Ethernet/Token Ring предоставлено самим решать проблему этих битов.

♦                Обработка эксклюзивных функций Token Ring. Некоторые биты Token Ring не имеют следствия в Ethernet. Например, Ethernet не имеет механизма приоритетов, в то время как Token Ring имеет его. В числе других битов Token Ring, которые должны быть отброшены при преобразовании блока данных Token Ring в блок данных Ethernet, бит маркера, бит монитора и бит резервирования.

 

♦                Обработка ТВ блоков данных разведчика. В мостах ТВ не предусмотрен механизм обработки блоков данных разведчика маршрута SRB. ТВ узнают о топологии сети путем анализа адреса источника входящих блоков данных. Они не имеют понятия о процессе поиска маршрутов SRB.

♦                Обработка ТВ информации поля маршрутной информации (RIF), содержащейся в блоках данных Token Ring. Алгоритм SRB размещает маршрутную информацию в поле RIF. Алгоритм ТВ не имеет эквивалента RIF, и для ТВ чуждо понятие о размещении маршрутной информации в блоке данных.

♦                Несовместимость алгоритмов связующего дерева. Как ТВ, так и SRB используют алгоритм связующего дерева для предотвращения петель, однако конкретные алгоритмы, используемые этими двумя способами объединения сетей с помощью мостов, несовместимы.

♦                Обработка SRB блоков данных без маршрутной информации. Мосты SRB предполагают наличие маршрутной информации во всех блоках данных обмена между LAN. Если в мост SRB поступают блоки данных без поля RIF (в их числе конфигурационные сообщения и сообщения о топологических изменениях, а также блоки данных MAC, отправляемые из домена ТВ), они просто игнорируются.

Трансляционное объединение с помощью мостов (TLB)

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

При трансляции между Ethernet и Token Ring протокол TLB пере­упорядочивает биты адреса источника и пункта назначения. Проблема встроенных адресов MAC может быть решена путем программирования моста таким образом, чтобы он проверял адреса MAC разных типов; од­нако это техническое решение должно адаптироваться к каждому ново­му типу встроенных адресов MAC.

В некоторых решениях TLB просто проверяются наиболее попу­лярные встроенные адреса MAC. Если программное обеспечение TLB работает в роутере с несколькими протоколами, то этот роутер может уc

пешно назначать тракты для этих протоколов и полностью решить эту проблему.

Поле RIF имеет подполе, которое указывает размер самого боль­шого блока данных, который может быть принят конкретной реализаци­ей SRB. TLB, отправляющие блоки данных из домена ТВ в домен SRB, обычно устанавливают значение поля размера MTU равным 1500 для то­го, чтобы ограничить размер блоков данных Token Ring, входящих в до­мен ТВ. Некоторые хосты не могут точно обрабатывать это поле; в этом случае TLB вынуждены просто игнорировать те блоки данных, которые превышают размер MTU Ethernet.

Биты, представляющие функции Token Ring, не имеющие следст­вия в Ethernet, обычно отбрасываются протоколами TLB. Например, от­брасываются биты приоритета, резервирования и монитора Token Ring. Что касается битов состояния блоков данных Token Ring, то они обраба­тываются по-разному в зависимости от изготовителя TLB. Некоторые изготовители TLB просто игнорируют эти биты. Другие обеспечивают установку в мостах бита С, но не обеспечивают бит А. В первом случае узел источника Token Ring не имеет возможности установить, потерян или нет отправленный им блок данных.

Сторонники этого метода считают, что механизмы надежности, такие, как отслеживание потерянных блоков данных, лучше реализовать в уровне 4 модели OSI. Защитники «метода установки бита С» утвержда­ют, что этот бит должен быть задан для отслеживания потерянных бло­ков данных, но бит А не может быть установлен, так как мост не являет­ся конечным пунктом назначения.

TLB могут образовывать программный мост между двумя домена­ми. Для конечных станций SRB мост TLB выглядит как стандартный SRB, так как он имеет номер кольца и номер моста, связанного с ним. В этом случае номер кольца фактически отражает весь домен ТВ. Для до­мена ТВ, TLB является просто еще одним ТВ.

При объединении с помощью моста доменов SRB и ТВ информа­ция SRB удаляется. RIF обычно сохраняются в кэш для использования последующим возвратным трафиком. При объединении с помощью мос­та доменов ТВ и SRB, TLB может проверить блок данных, чтобы узнать, имеет ли он назначение многопунктовой адресации. Если блок данных имеет многопунктовое или широковещательное назначение, он отправ­ляется в домен SRB в качестве разведчика связующего дерева. Если блок данных имеет однопунктовый адрес, то TLB ищет пункт назначения в кэш RIF. Если тракт найден, то он будет использован, а информация RIF включается в блок данных; в противном случае этот блок данных отправ­ляется в качестве разведчика связующего дерева. Так как две этих реали­зации связующего дерева несовместимы, то, как правило, не разрешают­ся несколько трактов между доменами SRB и ТВ.

Прозрачное объединение с помощью мостов «Источник-Маршрут» (SRT)

SRT комбинируют реализации алгоритмов ТВ и SRB. SRT исполь­зуют бит индикатора маршрутной информации (routing information indi­cator — RII), чтобы отличать блоки данных, использующих SRB, от блоков данных, использующих ТВ. Если бит RII равен 1, то RIF присут­ствует в блоке данных, и данный мост использует алгоритм SRB. Если RII равен 0, то RIF отсутствует, и данный мост использует ТВ.

Как и мосты TLB, мосты SRT не являются техническим решени­ем, совершенным с точки зрения решения проблем объединения с помо­щью мостов смешанных носителей. SRT также должны иметь дело с опи­санными выше несовместимостями Ethernet/Token Ring. Скорее всего, SRT потребует расширения аппаратных возможностей SRB, чтобы они могли справляться с дополнительной нагрузкой, связанной с анализом каждого пакета. Может потребоваться также программное наращивание SRB. Кроме того, в окружениях смешанных SRT, ТВ и SRB, выбранные маршруты источника должны пересекать любые доступные SRT и SRB. Результирующие тракты могут быть потенциально значительно хуже маршрутов связующего дерева, образованных мостами ТВ. И наконец, смешанные сети SRB/SRT теряют преимущества SRT, поэтому пользо­ватели поймут, что они вынуждены осуществить полный переход к SRT, требующий значительных расходов. Однако SRT позволяет сосущество­вание двух несовместимых сред и обеспечивает связь между конечными узлами SRB и ТВ.

SNMP

В создание протокола SNMP внесли свой вклад разработки по трем направлениям:

High-level Entity Management System (HEMS)

Система управления объектами высшего уровня. Определяет сис­тему управления с рядом интересных технических характеристик. К со­жалению, HEMS использовалась только в местах ее разработки, что в ко­нечном итоге привело к прекращению ее действия.

Simple Gateway Monitoring Protocol (SGMP)

Протокол управления простым роутером. Разработка была начата группой сетевых инженеров для решения проблем, связанных с управле­нием быстрорастущей Internet; результатом их усилий стал протокол, предназначенный для управления роутерами Internet. SGMP был реали­зован во многих региональных ветвях Internet.

CMIP over TCP (CMOT)

CMIP над TCP. Пропагандирует сетевое управление, базирующе­еся на OSI, в частности, применение Common Management Information Protocol (CMIP) (Протокол информации общего управления) для облег­чения управления объединенных сетей, базирующихся на TCP.

Достоинства и недостатки этих трех методов (HEMS, SGMP и CMOT) часто и горячо обсуждались в течение второй половины 1987 г. В начале 1988 г. был образован комитет Internet Activities Board — IAB (IAB — это группа, ответственная за техническую разработку протоколов Internet) для разрешения дебатов по поводу протокола сетевого управле­ния. В конечном итоге комитет IAB пришел к соглашению, что улучшен­ная версия SGMP, которая должна была называться SNMP, должна стать временным решением; для долгосрочного применения должна быть про­анализирована одна из технологий, базирующихся на OSI (либо СМОТ, либо сам CMIP). Для обеспечения легкого пути наращивания была раз­работана общая структура сетевого управления (которая теперь называ­ется стандартной Структурой Управления Сети — Network Management Framework).

Сегодня SNMP является самым популярным протоколом управ­ления различными коммерческими, университетскими и исследователь­скими объединенными сетями. Деятельность по стандартизации, связанная с SNMP, продолжается по мере того, как поставщики разраба­тывают и выпускают современные прикладные программы управления, базирующиеся на SNMP. SNMP относительно простой протокол, одна­ко набор его характеристик является достаточно мощным для решения трудных проблем, возникающих при управлении гетерогенных сетей.

 

Основы технологии

SNMP является протоколом прикладного уровня, предназначен­ным для облегчения обмена информацией управления между сетевыми устройствами. Пользуясь информацией SNMP (такой, как показатель числа пакетов в секунду и коэффициент сетевых ошибок), сетевые адми­нистраторы могут более просто управлять производительностью сети и обнаруживать и решать сетевые проблемы.

Модель управления

Агентами в SNMP являются программные модули, которые рабо­тают в управляемых устройствах. Агенты собирают информацию об уп­равляемых устройствах, в которых они работают, и делают эту информа­цию доступной для систем управления сетями (network management systems — NMS) с помощью протокола SNMP.

Управляемое устройство может быть узлом любого типа, находя­щимся в какой-нибудь сети: это хосты, служебные устройства связи, принтеры, роутеры, мосты и концентраторы. Так как некоторые из этих систем могут иметь ограниченные способности управления программ­ным обеспечением (например, они могут иметь центральные процессо­ры с относительно малым быстродействием или ограниченный объем памяти), программное обеспечение управления должно сделать допуще­ние о наименьшем общем знаменателе. Другими словами, программы управления должны быть построены таким образом, чтобы минимизи­ровать воздействие своей производительности на управляемое устройст­во.

Так как управляемые устройства содержат наименьший общий знаменатель программного обеспечения управления, тяжесть управле­ния ложится на NMS. Поэтому NMS обычно являются компьютерами калибра АРМ проектировщика, которые имеют быстродействующие центральные процессоры, мегапиксельные цветные устройства отобра­жения, значительный объем памяти и достаточный объем диска. В любой управляемой сети может иметься одна или более NMS. NMS про­гоняют прикладные программы сетевого управления, которые представ­ляют информацию управления пользователям. Интерфейс пользователя обычно базируется на стандартизированном графическом интерфейсе пользователя (graphical user interface — GUI).

Сообщение между управляемыми устройствами и NMS регулиру­ется протоколом сетевого управления. Стандартный протокол сети Internet, Network Management Framework, предполагает парадигму дис­танционной отладки, когда управляемые устройства поддерживают зна­чения ряда переменных и сообщают их по требованию в NMS. Напри­мер, управляемое устройство может отслеживать следующие параметры:

♦                Число и состояние своих виртуальных цепей

♦                Число определенных видов полученных сообщений о неисправности

♦                Число байтов и пакетов, входящих и исходящих из данного устройства

♦                Максимальная длина очереди на выходе (для роутеров и других устройств объединения сетей)

♦                Отправленные и принятые широковещательные сообщения

♦                Отказавшие и вновь появившиеся сетевые интерфейсы

 

Типы команд

Если NMS хочет проконтролировать какое-либо из управляемых устройств, она делает это путем отправки ему сообщения с указанием об изменении значения одной из его переменных. В целом управляемые ус­тройства отвечают на четыре типа команд (или инициируют их):

Reads

Для контролирования управляемых устройств NMS считывают переменные, поддерживаемые этими устройствами.

Writes

Для контролирования управляемых устройств NMS записывают переменные, накопленные в управляемых устройствах

Traversal operations

NMS используют операции прослеживания, чтобы определить, какие переменные поддерживает управляемое устройство, а затем со­брать информацию в таблицы переменных (такие, как таблица маршру­тизации IP)

Traps

Управляемые устройства используют ловушки для асинхронных сообщений в NMS о некоторых событиях.

 

Различия в представлении информации

Обмен информацией в управляемой сети находится потенциально под угрозой срыва из-за различий в технике представления данных, ис­пользуемой управляемыми устройствами. Другими словами, компьюте­ры представляют информацию по-разному; эту несовместимость необ­ходимо рационализировать, чтобы обеспечить сообщение между различными системами. Эту функцию выполняет абстрактный синтак­сис. SNMP использует для этой цели подмножество абстрактного син­таксиса, созданного для OSI — Abstract Syntax Notation One (ASN. 1) (Си­стема обозначений для описания абстрактного синтаксиса). ASN.1 определяет как форматы пакетов, так и управляемые объекты. Управля­емый объект — это просто характеристика чего-либо, которой можно уп­равлять. Управляемый объект отличается от переменной, которая явля­ется конкретной реализацией объекта. Управляемые объекты могут быть скалярными (определяя отдельную реализацию) или табулярными вели­чинами (определяя несколько связанных друг с другом реализаций).

Базы данных управления

Все управляемые объекты содержатся в Информационной базе управления (Management Information Base — MIB), которая фактически является базой данных объектов. Логически MIB можно изобразить в ви­де абстрактного дерева, листьями которого являются отдельные инфор­мационные элементы. Идентификаторы объектов уникальным образом идентифицируют объекты MIB этого дерева. Идентификаторы объектов похожи на телефонные номера тем, что они организованы иерархически и их отдельные части назначаются различными организациями. Напри­мер, международные телефонные номера состоят из кода страны (назна­чаемого международной организацией) и телефонного номера в том ви­де, в каком он определен в данной стране. Телефонные номера в США далее делятся на код области, номер центральной телефонной станции (СО) и номер станции, связанной с этой СО. Аналогично, идентифика­торы объектов высшего уровня MIB назначаются Международной Элек­тротехнической Комиссией ISO (ISO IEC). ID объектов низшего уровня назначаются относящимися к ним организациями.

Дерево MIB расширяемо благодаря экспериментальным и част­ным ветвям. Например, поставщики могут определять свои собственные ветви для включения реализаций своих изделий. В настоящее время вся работа по стандартизации ведется на экспериментальной ветви.

Структуру MIB определяет документ, называемый Структура Ин­формации Управления (Structure of Management Information — SMI). SMI определяет следующие типы информации:

Network addresses (Сетевые адреса)

Представляют какой-нибудь адрес из конкретного семейства про­токолов. В настоящее время единственным примером сетевых адресов являются 32-битовые адреса IP.

Counters (Счетчики)

Неотрицательные целые числа, которые монотонно увеличивают­ся до тех пор, пока не достигнут максимального значения, после чего они сбрасываются до нуля. Примером счетчика является общее число бай­тов, принятых интерфейсом.

Gauges (Измерительный прибор, мера, размер)

Неотрицательные целые числа, которые могут увеличиваться или уменьшаться, но запираются при максимальном значении. Примером измерительного прибора является длина очереди, состоящей из выход­ных пакетов (в пакетах).

Ticks (Тики)

Сотые доли секунды, прошедшие после какого-нибудь события. Примером tick является время, прошедшее после вхождения интерфейса в свое текущее состояние.

Opaque (Мутный)

Произвольное кодирование. Используется для передачи произ­вольных информационных последовательностей, находящихся вне пре­делов точного печатания данных, которое использует SMI.

Операции

SNMP является простым протоколом запроса/ответа. Узлы могут отправлять множество запросов, не получая ответа. Определены следую­щие 4 операции SNMP:

Get (достань)

Извлекает какую-нибудь реализацию объекта из агента.

Get-next (достань следующий)

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

Set (установи)

Устанавливает реализации объекта в пределах какого-нибудь агента.

Trap (ловушка)

Используется агентом для асинхронного информирования NMS о каком-нибудь событии.

Формат сообщений

Сообщения SNMP состоят из 2 частей: имени сообщества (com­munity пате) и данных (data). Имя сообщества назначает среду доступа для набора NMS, которые используют это имя. Можно сказать, что NMS, принадлежащие одному сообществу, находятся под одним и тем же административным началом. Так как устройства, которые не знают правильного имени сообщества, исключаются из операций SNMP, уп­равляющие сетей также используют имя сообщества в качестве слабой формы опознавания.

Информационная часть сообщения содержит специфичную опе­рацию SNMP (get, set, и т.д.) и связанные с ней операнды. Операнды обо­значают реализации объекта, которые включены в данную транзакцию SNMP.

Сообщения SNMP официально называются протокольными еди­ницами данных (protocol data units — PDU).

PDU операций get и set SNMP состоят из следующих частей:

Request-ID (идентификатор запроса)

Устанавливает связь между командами и ответами.

Error-status (состояние сбоя)

Указывает ошибку и ее тип.

Error-index (индекс ошибки)

Устанавливает связь между ошибкой и конкретной реализацией объекта.

variable bindings (переменные привязки)

Состоят из данных SNMP PDU. Переменные привязки устанав­ливают связь между конкретными переменными и их текущими значе­ниями.

PDU ловушки несколько отличаются от PDU других операций. Они состоят из следующих частей:

Enterprise (предметная область)

Идентифицирует тип объекта, генерирующего данную ловушку.

Agent address (адрес агента)

Обеспечивает адрес объекта, генерирующего данную ловушку.

Generic trap type (групповой тип ловушки)

Обеспечивает групповой тип ловушки.

Specific trap code (специфичный код ловушки)

Обеспечивает специфичный код ловушки.

Time stamp (временной ярлык)

Обеспечивает величину времени, прошедшего между последней повторной инициализацией сети и генерацией данной ловушки.

Variable bindings (переменные привязки)

Обеспечивает перечень переменных, содержащих интересную ин­формацию о ловушке.

 

ПечатьE-mail

Яндекс.Метрика