Современные локальные вычислительные сети
Управление сетью в объединенных сетях TCP/IP. Архитектуры и структуры распределенных систем управления локальными сетями. Иерархические связи между менеджерами. Создание протокола SNMP. Стандарты управления OSI. Сравнение протоколов SNMP и CMIP.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 21.11.2013 |
| Размер файла | 224,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Введение
Локальные сети в последнее время из модного дополнения к компьютерам все более превращаются в обязательную принадлежность любой компании, имеющей больше одного компьютера. Однако с развитием современных локальных вычислительных сетей (ЛВС) всё более насущной становится проблема управления и мониторинга сетей. Всё больше денег приходится тратить организациям на поддержание нормального функционирования своих локальных сетей. Всё больше людей могут сказать, что их профессией является профессия системного администратора. В наши дни сложно представить современную организацию или компанию, в которой бы не было компьютеров, а компьютерная сеть является наиболее естественным продолжением персонального компьютера. Уже перестали быть редкостью и домашние сети, объединяющие жильцов одного подъезда или дома. Конечно, для управления миниатюрной домашней "сеткой" на 5-10 компьютеров не требуется специальных средств, однако, уже само появление такой "сетки" говорит о большом распространения компьютерных сетей и их росте.
Так вот, сети растут, а, следовательно, вместе с массой преимуществ несут с собой и массу проблем, которые связанны с управлением. Основной проблемой, несомненно, является обеспечение работоспособности сети. Ведь рядовому пользователю не так важна скорость, как постоянство и надёжность работы сети, именно за возможность в любой момент получить сводку новостей или отправить свою почту, пользователь и платит деньги.
Залогом устойчивой работы сети является правильное планирование и установка оборудования, прокладка кабелей, настройка серверов и т.д. На все виды монтажных работ существует масса стандартов, как отечественных, так и международных. Но всё спланировать невозможно, ведь сеть является динамической структурой, и строгое соблюдение стандартов залог устойчивой работы не всей сети, а только кабельной инфраструктуры. При планировании сети следует учитывать всевозможные перестановки и изменения в оборудовании. Нельзя же, без особых на то причин, запретить пользователю подключить ещё один компьютер или принтер, также невозможно предвидеть запросы пользователей на долгое время вперёд. Потребность в информации у человека или у группы людей может расти по мере её получения, так сказать, аппетит приходит во время еды. Конечно, этот аппетит может быть и не оправдан, однако если он оплачивается, то святая обязанность сисадмина его удовлетворить. В конце концов, даже игры в рабочее время, так сильно занимающие ресурсы сети, ведут к освоению компьютера всё большим числом людей, а это всё же плюс.
Таким образом, мы и пришли к пониманию главных врагов системного администратора (ну, кроме кракеров и прочих хулиганов). Это оказались такие вещи как перегрузка, нехватка мощностей, проблемы административного управления и пр. Конечно, существуют также и различные трудности при настройке оборудования, конфигурации серверов и брандмауэров и т.д., но эти проблемы относятся к сетевому уровню, а данная работа направлена на профилактику физического и канального уровней.
Именно профилактика призвана решить основную часть проблем. Постоянное наблюдение за сетевыми устройствами, приём тревожных сообщений и реакция на них, удобная возможность быстрой настройки - вот те вещи, которые позволят сисадмину спокойно спать и не подскакивать при каждом телефонном звонке. Может быть, кому-то устранять проблему проще когда таковая уже произошла и телефон раскаляется от звонков, однако, это означает потери рабочего времени пользователей и денег организации. А потерь никто не любит, и потому нужно не допустить краха системы. Разумеется, остановки абсолютно недопустимы в жизненно важных системах крупных организаций.
1. Архитектуры систем управления сетями
сеть локальный протокол
Схема менеджер--агент
Управление сетью в объединенных сетях TCP/IP строится на взаимодействии между станцией управления сетью (менеджер) и элементами сети. Элементами сети могут быть любые объекты, которые используют семейство протоколов TCP/IP: хосты, маршрутизаторы, X терминалы, терминальные сервера, принтеры и так далее. На элементах сети должно быть запущено программное обеспечение, которое называется агентом. Станции управления это обычно рабочие станции с цветным монитором и графическим дисплеем, которые отображают то, что происходит с элементами (которые из них работают, а которые нет, объем трафика по различным каналам за единицу времени и так далее). Схема «менеджер - агент» представлена на рис. 1. Агент является посредником между управляемым ресурсом и основной управляющей программой-менеджером. Чтобы один и тот же менеджер мог управлять различными реальными ресурсами, создается некоторая модель управляемого ресурса, которая отражает только те характеристики ресурса, которые нужны для его контроля и управления. Например, модель маршрутизатора обычно включает такие характеристики, как количество портов, их тип, таблицу маршрутизации, количество кадров и пакетов протоколов канального, сетевого и транспортного уровней, прошедших через эти порты.
Рис. 1. Взаимодействие агента, менеджера и управляемого ресурса
Менеджер получает от агента только те данные, которые описываются моделью ресурса. Агент же является некоторым экраном, освобождающим менеджера от ненужной информации о деталях реализации ресурса. Агент поставляет менеджеру обработанную и представленную в нормализованном виде информацию. На основе этой информации менеджер принимает решения по управлению, а также выполняет дальнейшее обобщение данных о состоянии управляемого ресурса, например, строит зависимость загрузки порта от времени. Для получения требуемых данных от объекта, а также для выдачи на него управляющих воздействий агент взаимодействует с реальным ресурсом некоторым нестандартным способом. Когда агенты встраиваются в коммуникационное оборудование, то разработчик оборудования предусматривает точки и способы взаимодействия внутренних узлов устройства с агентом. При разработке агента для операционной системы разработчик агента пользуется теми интерфейсами, которые существуют в этой ОС, например интерфейсами ядра, драйверов и приложений. Агент может снабжаться специальными датчиками для получения информации, например датчиками релейных контактов или датчиками температуры.
Менеджер и агент должны располагать одной и той же моделью управляемого ресурса, иначе они не смогут понять друг друга. Однако в использовании этой модели агентом и менеджером имеется существенное различие. Агент наполняет модель управляемого ресурса текущими значениями характеристик данного ресурса, и в связи с этим модель агента называют базой данных управляющей информации -- Management Information Base, MIB. Менеджер использует модель, чтобы знать о том, чем характеризуется ресурс, какие характеристики он может запросить у агента и какими параметрами можно управлять. Менеджер взаимодействует с агентами по стандартному протоколу. Этот протокол должен позволять менеджеру запрашивать значения параметров, хранящихся в базе MIB, а также передавать агенту управляющую информацию, на основе которой тот должен управлять устройством.
Различают управление in-band, то есть по тому же каналу, по которому передаются пользовательские данные, и управление out-of-band, то есть вне канала, по которому передаются пользовательские данные. Например, если менеджер взаимодействует с агентом, встроенным в маршрутизатор, по протоколу SNMP, передаваемому по той же локальной сети, что и пользовательские данные, то это будет управление in-band. Если же менеджер контролирует коммутатор первичной сети, работающий по технологии частотного уплотнения FDM, с помощью отдельной сети Х.25, к которой подключен агент, то это будет управление out-of-band. Управление по тому же каналу, по которому работает сеть, более экономично, так как не требует создания отдельной инфраструктуры передачи управляющих данных. Однако способ out-of-band более надежен, так как он предоставляет возможность управлять оборудованием сети и тогда, когда какие-то элементы сети вышли из строя и по основным каналам оборудование недоступно. Стандарт многоуровневой системы управления TMN имеет в своем названии слово Network, подчеркивающее, что в общем случае для управления телекоммуникационной сетью создается отдельная управляющая сеть, которая обеспечивает режим out-of-band.
Обычно менеджер работает с несколькими агентами, обрабатывая получаемые от них данные и выдавая на них управляющие воздействия. Агенты могут встраиваться в управляемое оборудование, а могут и работать на отдельном компьютере, связанном с управляемым оборудованием по какому-либо интерфейсу. Менеджер обычно работает на отдельном компьютере, который выполняет также роль консоли управления для оператора или администратора системы.
Модель менеджер - агент лежит в основе таких популярных стандартов управления, как стандарты Internet на основе протокола SNMP и стандарты управления ISO/OSI на основе протокола CMIP. Агенты могут отличаться различным уровнем интеллекта -- они могут обладать как самым минимальным интеллектом, необходимым для подсчета проходящих через оборудование кадров и пакетов, так и весьма высоким, достаточным для выполнения самостоятельных действий по выполнению последовательности управляющих действий в аварийных ситуациях, построению временных зависимостей, фильтрации аварийных сообщений и т.п.
Структуры распределенных систем управления
В крупной корпоративной сети полностью централизованная система управления, построенная на базе единственного менеджера, вряд ли будет работать хорошо по нескольким причинам. Во-первых, такой вариант не обеспечивает необходимой масштабируемости по производительности, так как единственный менеджер вынужден будет обрабатывать весь поток сообщений от всех агентов, что при нескольких тысячах управляемых объектов потребует очень высокопроизводительной платформы для работы менеджера и перегрузит служебной управляющей информацией каналы передачи данных в той сети, где будет расположен менеджер. Во-вторых, такое решение не обеспечит необходимого уровня надежности, так как при отказе единственного менеджера будет потеряно управление сетью. В-третьих, в большой распределенной сети целесообразно располагать в каждом географическом пункте отдельным оператором или администратором, управляющим своей частью сети, а это удобнее реализовать с помощью отдельных менеджеров для каждого оператора.
Схема менеджер - агент позволяет строить достаточно сложные в структурном отношении распределенные системы управления. Обычно распределенная система управления включает большое количество связок менеджер - агент, которые дополняются рабочими станциями операторов сети, с помощью которых они получают доступ к менеджерам (рис. 2.). Каждый агент собирает данные и управляет определенным элементом сети. Менеджеры, иногда также называемые серверами системы управления, собирают данные от своих агентов, обобщают их и хранят в базе данных. Операторы, работающие за рабочими станциями, могут соединиться с любым из менеджеров и с помощью графического интерфейса просмотреть данные об управляемой сети, а также выдать менеджеру некоторые директивы по управлению сетью или ее элементами.
Рис. 2. Распределенноя система управления на основе нескольких менеджеров и рабочих станций
Наличие нескольких менеджеров позволяет распределить между ними нагрузку по обработке данных управления, обеспечивая масштабируемость системы. Как правило, связи между агентами и менеджерами носят более упорядоченный характер, чем тот, который показан на рис. 2. Чаще всего используются два подхода к их соединению -- одноранговый (рис. 3) и иерархический (рис. 4).
Рис. 3. Одноранговые связи между менеджерами
В случае одноранговых связей каждый менеджер управляет своей частью сети на основе информации, получаемой от нижележащих агентов. Центральный менеджер отсутствует. Координация работы менеджеров достигается за счет обмена информацией между базами данных каждого менеджера. Одноранговое построение системы управления сегодня считается неэффективным и устаревшим. Обычно оно вызвано тем обстоятельством, что элементарные системы управления построены как монолитные системы, которые первоначально не были ориентированы на модульность системы (например, многие системы управления, разработанные производителями оборудования, не поддерживают стандартные интерфейсы для взаимодействия с другими системами управления). Затем эти менеджеры нижнего уровня стали объединяться для создания интегрированной системы управления сетью, но связи между ними оказалось возможным создавать только на уровне обмена между базами данных, что достаточно медленно. Кроме того, в базах данных таких менеджеров накапливается слишком детальная информация об управляемых элементах сети (так как первоначально эти менеджеры разрабатывались как менеджеры нижнего уровня), вследствие чего такая информация малопригодна для координации работы всей сети в целом. Такой подход к построению системы управления называется подходом «снизу вверх».
Рис. 4. Иерархические связи между менеджерами
Гораздо более гибким является иерархическое построение связей между менеджерами. Каждый менеджер нижнего уровня выполняет также функции агента для менеджера верхнего уровня. Такой агент работает уже с гораздо более укрупненной моделью (MIB) своей части сети, в которой собирается именно та информация, которая нужна менеджеру верхнего уровня для управления сетью в целом. Обычно для разработки моделей сети на разных уровнях проектирование начинают с верхнего уровня, на котором определяется состав информации, требуемой от менеджеров-агентов более низкого уровня, поэтому такой подход назван подходом «сверху вниз». Он сокращает объемы информации, циркулирующей между уровнями системы управления, и приводит к гораздо более эффективной системе управления. Модель TMN в наибольшей степени соответствует иерархической архитектуре связей между менеджерами, хотя известны реализации принципов TMN и в одноуровневых архитектурах.
Платформенный подход
При построении систем управления крупными локальными и корпоративными сетями обычно используется платформенный подход, когда индивидуальные программы управления разрабатываются не «с нуля», а используют службы и примитивы, предоставляемые специально разработанным для этих целей программным продуктом -- платформой. Примерами платформ для систем управления являются такие известные продукты, как HP Open View, SunNet Manager и Sun Soltice, Cabletron Spectrum, IMB/Tivoli TMN10.Эти платформы создают общую операционную среду для приложений системы управления точно так же, как универсальные операционные системы, такие как Unix или Windows NT, создают операционную среду для приложений любого типа, таких как MS Word, Oracle и т. п. Платформа обычно включает поддержку протоколов взаимодействия менеджера с агентами -- SNMP и реже CMIP, набор базовых средств для построения менеджеров и агентов, а также средства графического интерфейса для создания консоли управления. В набор базовых средств обычно входят функции, необходимые для построения карты сети, средства фильтрации сообщений от агентов, средства ведения базы данных. Набор интерфейсных функций платформы образует интерфейс прикладного программирования (API) системы управления. Пользуясь этим API, разработчики из третьих фирм создают законченные системы управления, которые могут управлять специфическим оборудованием в соответствии с пятью основными группами функций.
Обычно платформа управления поставляется с каким-либо универсальным менеджером, который может выполнять некоторые базовые функции управления без программирования. Чаще всего к этим функциям относятся функции построения карты сети (группа Configuration Management), а также функции отображения состояния управляемых устройств и функции фильтрации сообщений об ошибках (группа Fault Management). Например, одна из наиболее популярных платформ HP Open View поставляется с менеджером Network Node Manager, который выполняет перечисленные функции.
Чем больше функций выполняет платформа, тем лучше. В том числе и таких, которые нужны для разработки любых аспектов работы приложений, прямо не связанных со спецификой управления. В конце концов, приложения системы управления -- это прежде всего приложения, а потом уже приложения системы управления. Поэтому полезны любые средства, предоставляемые платформой, которые ускоряют разработку приложений вообще и распределенных приложений в частности. Компании, которые производят коммуникационное оборудование, разрабатывают дополнительные менеджеры для популярных платформ, которые выполняют функции управления оборудованием данного производителя более полно. Примерами таких менеджеров могут служить менеджеры системы Optivity компании Bay Networks и менеджеры системы Trancsend компании 3Com, которые могут работать в среде платформ HP Open View и SunNet Manager.
Выводы
Желательно, чтобы системы управления сетями выполняли все пять групп функций, определенных стандартами ISO/ITU-T для систем управления объектами любого типа.
Система управления большой сетью должна иметь многоуровневую иерархическую структуру в соответствии со стандартами Telecommunication Management Network (TMN), позволяющую объединить разрозненные системы управления элементами сети в единую интегрированную систему.
В основе всех систем управления сетями лежит схема агент - менеджер. Эта схема использует абстрактную модель управляемого ресурса, называемую базой управляющей информации -- Management Information Base, MIB.
Агент взаимодействует с управляемым ресурсом по нестандартному интерфейсу, а с менеджером -- по стандартному протоколу через сеть.
В больших системах управления используется несколько менеджеров, которые взаимодействуют друг с другом по одной из двух схем : одноранговой и иерархической.
Иерархическая схема взаимодействия менеджеров соответствтвует стандартам TMN и является более перспективной.
При построении систем управления активно используется платформенный подход. Платформа системы управления выполняет для менеджеров роль операционной системы для обычных приложений, так как обеспечивает разработчика менеджеров набором полезных системных вызовов общего для любой системы управления назначения.
2. Создание протокола SNMP
В создание протокола SNMP внесли свой вклад разработки по трем направлениям:
High-level Entity Management System (HEMS)
Система управления объектами высшего уровня. Определяет систему управления с рядом интересных технических характеристик. К сожалению, HEMS использовалась только в местах ее разработки, что в конечном итоге привело к прекращению ее действия.
Simple Gateway Monitoring Protocol (SGMP)
Протокол управления простым роутером. Разработка была начата группой сетевых инженеров для решения проблем, связанных с управлением быстрорастущей Internet; результатом их усилий стал протокол, предназначенный для управления роутерами Internet. SGMP был реализован во многих региональных ветвях Internet.
CMIP over TCP (CMOT)
CMIP над ТСР. Пропагандирует сетевое управление, базирующееся на OSI, в частности, применение Common Management Information Protocol (CMIP) (Протокол информации общего управления) для облегчения управления об'единенных сетей, базирующихся на ТСР.
Достоинства и недостатки этих трех методов (HEMS, SGMP и CMOT) часто и горячо обсуждались в течение второй половины 1987 г. К началу 1988 года стало ясно, что необходим некоторый общий набор средств управления сетевыми устройствами различных производителей, которые до сих пор создавали собственные продукты мониторинга и конфигурирования для своих же сетевых устройств, поддерживающие уникальные механизмы взаимодействия с ними.
После многих заседаний IAB (Internet Architecture Board) опубликовал в апреле 1988 года эпохальный RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в котором призвал к скорейшему созданию элементов Простого Сетевого Управления (Simple Network Management). Работа по созданию SNMP закипела. Многие идеи, лежащие сегодня в основе SNMP были заимствованы из предыдущих исследований по мониторингу Internet- маршрутизаторов (исторически называемых шлюзами - gateways), явивших на свет Simple Gateway Monitoring Protocol (SMGP). И уже в августе 1988 появились три основополагающих документа:
· RFC 1065: Structure and Identification of Management Information for TCP/IP-based internets.
· RFC 1066: Management Information Base for Network Management of TCP/IP-based internets.
· RFC 1067: A Simple Network Management Protocol.
Впоследствии эти документы были переизданы и дополнены до определения следующего поколения SNMP: RFC 1155, 1156 и 1157, которые в свою очередь, также подверглись переработкам.
В конце концов, в мае 1991 года была закончена работа по созданию первой версии протокола SNMP, которая нашла свое отражение в своде следующих документов:
· RFC 1155: Structure and Identification of Management Information for TCP/IP-based internets (Май, 1990)
· - Определяет структуру управляющей информации в виде глобального дерева.
· - Представляет синтаксис определения имен переменных управления.
· RFC 1212: Concise MIB Definitions (Март, 1991)
· - Дополняет RFC 1155 в части синтаксиса определения имен переменных.
· RFC 1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II (Март, 1991)
· - Содержит список более ста наиболее необходимых переменных, отвечающих за конфигурацию, статус и статистику систем, входящих в TCP/IP сеть.
· RFC 1157: A Simple Network Management Protocol (SNMP) (Май, 1990)
· - Определяет сообщения, которыми обмениваются управляющая станция и об'ект управления для получения и обновления значения переменных.
· - Определяет trap(alarm)-сообщения, посылаемые системой при значительных изменениях в ее конфигурации.
Сегодня SNMP является самым популярным протоколом управления различными коммерческими, университетскими и исследовательскими об'единенными сетями. Деятельность по стандартизации, связанная с SNMP, продолжается по мере того, как поставщики разрабатывают и выпускают современные прикладные программы управления, базирующиеся на SNMP. SNMP относительно простой протокол, однако набор его характеристик является достаточно мощным для решения трудных проблем, возникающих при управлении гетерогенных сетей.
Концепции SNMP-управления
В системах управления, построенных на основе протокола SNMP, стандартизуются следующие элементы:
· Протокол взаимодействия агента и менеджера;
· Язык описания моделей MIB и сообщений SNMP -- язык абстрактной синтаксической нотации ASN.1 (стандарт ISO 8824:1987, рекомендации ITU-T X.208);
· Несколько конкретных моделей MIB (MIB-I, MIB-II, RMON, RMON 2), имена объектов которых регистрируются в дереве стандартов ISO.
Все остальное отдается на откуп разработчику системы управления.
SNMP -- это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB П. Кроме того, сам протокол SNMP также весьма несложен. Древовидная структура MIB содержит обязательные (стандартные) поддеревья, а также в ней могут находиться частные (private) поддеревья, позволяющие изготовителю интеллектуальных устройств управлять какими-либо специфическими функциями устройства на основе специфических объектов MIB. Агент в протоколе SNMP -- это обрабатывающий элемент, который обеспечивает менеджерам, размещенным на управляющих станциях сети, доступ к значениям переменных MIB и тем самым дает им возможность реализовывать функции по управлению и наблюдению за устройством.Основные операции по управлению вынесены в менеджер, а агент SNMP выполняет чаще всего пассивную роль, передавая в менеджер по его запросу значения накопленных статистических переменных. При этом устройство работает с минимальными издержками на поддержание управляющего протокола. Оно использует почти всю свою вычислительную мощность для выполнения своих основных функций маршрутизатора, моста или концентратора, а агент занимается сбором статистики и значений переменных состояния устройства и передачей их менеджеру системы управления.
Примитивы протокола SNMP
SNMP -- это протокол типа «запрос-ответ», то есть на каждый запрос, поступивший от менеджера, агент должен передать ответ. Особенностью протокола является его чрезвычайная простота -- он включает в себя всего несколько команд.
Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.
Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.
С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.
Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие -- отключить порт, приписать порт определенной VLAN и т. п. Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.
Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.
Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.
Структура SNMP MIВ
На сегодня существует несколько стандартов на базы данных управляющей информации для протокола SNMP. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого существуют стандарты для специальных устройств MIB конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.
Версия MIB-I (RFC 1156) определяет 114 объектов, которые подразделяются на 8 групп.
System -- общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).
Interfaces -- параметры сетевых интерфейсов устройства (например, их количество, типы, скорости обмена, максимальный размер пакета).
Address Translation Table -- описание соответствия между сетевыми и физическими адресами (например, по протоколу ARP).
Internet Protocol -- данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика о IP-пакетах).
ICMP -- данные, относящиеся к протоколу обмена управляющими сообщениями ICMP.
TCP -- данные, относящиеся к протоколу TCP.
UDP -- данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).
EGP -- данные, относящиеся к протоколу обмена маршрутной информацией Exterior Gateway Protocol, используемому в Internet (число принятых с ошибками и без ошибок сообщений).
Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP. В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10. На рис. 5 приведен пример древовидной структуры базы объектов MIB-II. На нем показаны две из 10 возможных групп объектов -- System (имена объектов начинаются с префикса Sys) иInterfaces (префикс if). Объект SysUpTime содержит значение продолжительности времени работы системы с момента последней перезагрузки, объект SysObjectID -- идентификатор устройства (например, маршрутизатора).
Рис. 5. Стандартное дерево MIB-II (фрагмент)
Объект ifNumber определяет количество сетевых интерфейсов устройства, а объект ifEntry является вершиной поддерева, описывающего один из конкретных интерфейсов устройства. Входящие в это поддерево объекты ifType и ifAdminStatus определяют соответственно тип и состояние одного из интерфейсов, в данном случае интерфейса Ethernet.
В число объектов, описывающих каждый конкретный интерфейс устройства, включены следующие.
ifType
Тип протокола, который поддерживает интерфейс. Этот объект принимает значения всех стандартных протоколов канального уровня, например rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing и т. д.
ifMtu
Максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс.
ifSpeed
Пропускная способность интерфейса в битах в секунду (100 для Fast Ethernet).
ifPhysAddress
Физический адрес порта, для Fast Ethernet им будет МАС-адрес.
ifAdminStatus
Желаемый статус порта:
· up -- готов передавать пакеты;
· down -- не готов передавать пакеты;
· testing -- находится в тестовом режиме.
ifOperStatus
Фактический текущий статус порта, имеет те же значения, что и ifAdminStatus.
ifInOctets
Общее количество байт, принятое данным портом, включая служебные, с момента последней инициализации SNMP-агента.
ifInUcastPkts
Количество пакетов с индивидуальным адресом интерфейса, доставленных протоколу верхнего уровня.
ifInNUcastPkts
Количество пакетов с широковещательным или мультивещательным адресом интерфейса, доставленных протоколу верхнего уровня.
ifInDiscards
Количество пакетов, которые были приняты интерфейсом, оказались корректными, но не были доставлены протоколу верхнего уровня, скорее всего из-за переполнения буфера пакетов или же по иной причине.
ifInErrors
Количество пришедших пакетов, которые не были переданы протоколу верхнего уровня из-за обнаружения в них ошибок.
Кроме объектов, описывающих статистику по входным пакетам, имеются аналогичные объекты, но относящиеся к выходным пакетам. Как видно из описания объектов MIB-II, эта база данных не дает детальной статистики по характерным ошибкам кадров Ethernet, кроме этого, она не отражает изменение характеристик во времени, что часто интересует сетевого администратора. Эти ограничения были впоследствии сняты новым стандартом на MIB -- RMON MIB, который специально ориентирован на сбор детальной статистики по протоколу Ethernet, к тому же с поддержкой такой важной функции, как построение агентом зависимостей статистических характеристик от времени.
3. Стандарты управления OSI
Модель сетевого управления OSI -- OSI Management Framework -- определена в документе ISO/IEC 7498-4: Basic Reference Model, Part 4, Management Framework. Она является развитием общей семиуровневой модели взаимодействия открытых систем для случая, когда одна система управляет другой.
Документ ISO/IEC 7498-4 состоит из следующих основных разделов.
Термины и общие концепции.
Модель управления системами.
Информационная модель.
Функциональные области управления системами.
Структура стандартов управления системами.
Стандарты ISO в области управления использует терминологию, которая частично совпадает с терминологией систем управления SNMP, а частично от нее отличается.
Как показано на рис. 8, обмен управляющей информацией с использованием протокола управления (Management Protocol) происходит между субъектами приложений управления системами (Systems Management Application Entities, SMAE). Субъекты SMAE расположены на прикладном уровне семиуровневой модели OSI и являются элементами службы управления. Под субъектом в модели OSI понимается активный в данный момент элемент протокола какого-либо уровня, участвующий во взаимодействии. Примерами SMAE являются агенты и менеджеры систем управления.
Рис. 8. Концепция SMAE
Агенты и менеджеры
Определения функций агентов и менеджеров в стандартах OSI достаточно хорошо согласуются с определениями систем SNMP, за некоторыми исключениями в терминологии. Сообщения, которые агент посылает менеджеру по своей инициативе, называются уведомлениями -- notifications. Например, если некоторый элемент сети Х отказал, то менеджеру необходимо обновить свою базу данных конфигурации сети. Элемент X, который является для системы управления управляемым объектом (managed object), может послать уведомление агенту. Элемент Х может находиться в той же управляемой системе, что и агент, или может находиться в другой системе. В свою очередь агент посылает уведомление менеджеру о том, что элемент Х отказал. В соответствии с этим уведомлением менеджер обновляет базу данных конфигурации.
Менеджер не только собирает и сопоставляет данные, получаемые от агентов, на основе этих данных он может также выполнять административные функции, управляя операциями удаленных агентов.В стандартах OSI границы между менеджерами и агентами не очень четкие. Субъект SMAE, выполняющий в одном взаимодействии роль менеджера, может в другом взаимодействии выполнять роль агента, и наоборот. Стандарты OSI не определяют способов взаимодействия агента с управляемыми объектами. Стандарты OSI также не говорят о том, как агент взаимодействует с управляемыми объектами, которые находятся за пределами управляемой системы, то есть объектами, с которыми нужно взаимодействовать через сеть. В таких случаях может потребоваться, например, чтобы один агент запросил данные о некотором объекте от другого агента. Порядок такого рода взаимодействия также не определяется стандартами OSI.
Чтобы менеджер и агент смогли взаимодействовать, каждый должен иметь определенные знания о другом. Эти знания модель OSI называет контекстом приложения (Application Context, AC). AC описывает элементы прикладного уровня стека OSI, которые используются агентами и менеджерами.
Прикладной уровень стека OSI включает несколько вспомогательных служб общего назначения, которые используются прикладными протоколами и пользовательскими приложениями (в том числе и приложениями управления) для автоматизации наиболее часто выполняемых действий. Это не законченные протоколы прикладного уровня, подобные протоколам ftp, telnet или NCP, с помощью которых пользователь сети может выполнить какое-то полезное действие, а вспомогательные системные функции, которые помогают разработчику прикладного протокола или приложения написать его программу компактно и эффективно. На прикладном уровне стека OSI существуют следующие вспомогательных службы.
ACSE (Association Control Service Element)
Отвечает за установление соединений между приложениями различных систем. Соединение (сессия, сеанс) на прикладном уровне OSI носит название ассоциации. Ассоциации бывают индивидуальными и групповыми (shared).
RTSE (Reliable Transfer Service Element)
Занимается поддержкой восстановления диалога, вызванного разрывом нижележащих коммуникационных служб, в рамках ассоциации.
ROSE (Remote Operations Service Element)
Организует выполнение программных функций на удаленных машинах (аналог службы вызова удаленных процедур RPC).
Протокол СМ1Р, используемый в стандартах OSI для взаимодействия между менеджерами и агентами, а также программные реализации менеджеров и агентов широко пользуются услугами данных вспомогательных служб, в особенности службы ROSE для вызова удаленных процедур.
Управление системами, управление уровнем и операции уровня
Основная модель управления OSI включает:
· управление системами
· управление N-уровнем
· операции N-уровня
Это разбиение на три области сделано для того, чтобы учесть все возможные ситуации, возникающие при управлении.
Управление системами имеет дело с управляемыми объектами на всех семи уровнях OSI, включая прикладной уровень. Оно основано на надежной передаче с установлением соединения управляющей информации между конечными системами. Необходимо подчеркнуть, что модель управления OSI не разрешает использования служб без установления соединения.
Управление N-уровнем ограничено управляемыми объектами какого-то определенного уровня семиуровневой модели. Протокол управления использует при этом коммуникационные протоколы нижележащих уровней. Управление N-уровнем полезно, когда нет возможности использовать все семь уровней OSI. В этом случае допускается пользоваться протоколом управления N-уровня, который строго предназначен для данного уровня.
Наконец, операции N-уровня сводятся к мониторингу и управлению на основе управляющей информации, содержащейся в коммуникационных протоколах только данного уровня. Например, данные мониторинга сети, содержащиеся в кадрах STM-n технологии SDH, относятся к операциям N-уровня, а именно физического уровня.
Стандарты на управление N-уровнем и операции N-уровня не входят в набор стандартов управления OSI. Стандарты OSI рассматривают только управление системами с помощью полного семиуровневого стека. Основная модель управления системами подразумевает выполнение управляющих операций и передачу уведомлений между одноранговыми системами, что означает необязательность жесткого распределения ролей на управляющие и управляемые системы. Эта модель облегчает реализацию распределенных аспектов управления. С другой стороны, допускается реализация одноранговых систем как управляющих и управляемых.
Информационная модель управления
Управляемый объект -- это представление OSI о ресурсе в целях управления. Ресурс может быть описан как управляемый объект. Конкретный управляемый объект -- это экземпляр (instance) некоторого класса управляемых объектов. Модель управления OSI широко использует объектно-ориентированный подход. Класс управляемых объектов -- это набор свойств, которые могут быть обязательными или условными. С помощью описания одного класса управляемых объектов, например коммутаторов, можно создать другой класс управляемых объектов, например коммутаторов, поддерживающих технику VLAN, унаследовав все свойства класса коммутаторов, но добавив новые атрибуты.
Для управления ресурсами менеджер и агент должны быть осведомлены о деталях этих ресурсов. Детализация представления управляемых объектов, которые требуются для выполнения функций управления, хранится в репозитории, известном как Management Information Base (MIB). Базы MIB OSI хранят не только описания классов управляемых объектов, но и характеристики сети и ее элементов. Базы MIB содержат характеристики каждой части управляемого оборудования и ресурсов. MIB также включает описание действий, которые могут выполняться на основе собранных данных или же вызываемые внешними командами. Базы MIB позволяют внешним системам опрашивать, изменять, создавать и удалять управляемые объекты (реальные ресурсы сети при этом, естественно, продолжают работать). Протокол CMIP и локальные интерфейсы управления обеспечивают доступ к этим возможностям.
MIB -- это концептуальная модель, и она не имеет никакой связи со способом физического или логического хранения данных в ресурсе. Стандарты не определяют аспекты собственно хранения данных. Протоколы OSI определяют синтаксис информации, хранящейся в MIB, и семантику обмена данными.
Управляющие знания и деревья знаний
Крупная система управления обычно состоит из большого количества агентов и менеджеров. Для организации автоматического взаимодействия между менеджерами и агентами необходимо каким-то образом задать данные, содержащие характеристики агентов и менеджеров. Менеджеру необходимо знать о том, какие агенты работают в системе управления, их имена и сетевые адреса, поддерживаемые ими классы управляемых объектов и т. п. Агенту также необходима аналогичная информация о менеджерах, так как ему нужно отправлять по своей инициативе уведомления и отвечать на запросы менеджеров.
Такие данные называются в модели OSI разделяемыми управляющими знаниями (shared management knowledge) между менеджером и агентом. (В системах SNMP организация этих данных не стандартизована, и в каждой конкретной системе управления эти данные хранятся в индивидуальной форме). Разделяемые управляющие знания должны быть известны до установления ассоциации между агентом и менеджером. Обычно они хранятся в каком-либо файле или распределенной базе данных и запрашиваются каждый раз, когда устанавливается ассоциация. Во время установления ассоциации происходит обмен разделяемыми управляющими знаниями.
В OSI стандартизуются различные аспекты организации управляющих знаний и доступа к ним. Следование объектно-ориентированному подходу обусловило использование для хранения этих знаний специальных системных объектов. Стандарт ISO 10164-16.2 определяет модель объектов управляющих знаний и классы таких объектов. Кроме того, определены функции работы с управляющими знаниями.
Имеются три типа управляющих знаний и, соответственно, три типа объектов, которые описывают эти знания.
Знания репертуара (Repertoire Knowledge)
Описывают возможности управляемой системы, включающие перечень поддерживаемых классов управляемых объектов, поддерживаемые функции управления и именования. Знания репертуара помогают менеджеру идентифицировать возможности управляемых систем без доступа к ним.
Знания определений (Definition Knowledge)
Включают формальные описания классов управляемых объектов, категории тестов, классов взаимосвязей и определения управляющей информации, понимаемой управляемой системой.
Знания об экземплярах (Instance Knowledge)
Обеспечивают информацию о конкретных экземплярах управляемых объектов, имеющихся в управляемой системе.
Использование древовидных баз данных для хранения управляющих знаний
В системе управления знания о поддерживаемых классах объектов и о порожденных экземплярах объектов должны храниться в какой-либо форме, удобной для предоставления модулям системы управления доступа к этой информации. Архитектура управления OSI предусматривает несколько схем базы данных об управляемых объектах и их классах. Эти схемы обычно называют деревьями из-за иерархической организации информации. Существуют следующие деревья.
Дерево наследования (Inheritance Tree)
Называется также деревом регистрации. Описывает отношения между базовыми и производными классами. Подчиненный класс наследует все характеристики суперкласса и дополняет их специфическими расширениями (дополнительными атрибутами, поведениями и действиями). Классы объектов OSI регистрируются в том же дереве, что и объекты MIB Internet. Дерево наследования может быть глобальным, то есть начинаться с корня, представляющего весь мир, или локальным, имеющим корень, соответствующий верхнему уровню объектов данной организации или сети. Все управляемые объекты OSI должны быть зарегистрированы в глобальном дереве ISO (в котором зарегистрированы объекты MIB-I, MIB-II, RMON MIB стандарта SNMP). Объекты, представляющие международные стандарты, регистрируются в международной ветви дерева, а частные модели, разработанные производителями систем управления, регистрируются в ветвях дерева, начинающихся с ветви private.
Дерево включений (Containment Tree)
Описывает отношения включения управляемых объектов реальной системы.
Дерево имен (naming tree)
Определяет способ именования объектов в системе управления. Объекты OSI могут иметь имена нескольких типов: относительное отличительное имя (Relative Distinguished Name, RDN), отличительное имя (Distinguished Name, DN), иногда называемое полным отличительным именем (Full Distinguished Name, FDN), и локальное отличительное имя (Local Distinguished Name, LDN). Эти имена связаны с деревом включений, так как определяют имена объектов относительно включающих их объектов. Относительное имя, RDN, соответствует короткому имени, которое однозначно определяет объект среди множества других объектов, подчиненных тому же родительскому объекту. Например, имя interface_a является RDN-именем, уникально характеризующим объект среди объектов, подчиненных объекту node_a. Полное отличительное имя FDN представляет собой последовательность RDN-имен, начинающуюся в вершине глобального дерева имен, то есть дерева, описывающего некоторую глобальную сеть. Наконец, локальное отличительное имя -- это последовательность RDN-имен, но начинающаяся не в глобальном корне, а в корне дерева имен локальной системы управления, отвечающей за часть глобального дерева имен данной сети.
Дерево имен обычно совмещается с деревом включений. Пример дерева включений показан на рис. 9. Экземпляр управляемого объекта класса согр-conс (корпоративный концентратор) имеет имя В1, а также атрибут max-slotes, описывающий максимальное количество слотов данного класса концентраторов, равный в данном случае 14. В этот объект включено ряд других объектов: объекты класса repeator, switch и RAS, которые в свою очередь включают объекты типа interface, описывающие порты модулей концентратора.
Имя класса объекта позволяет обратиться к описанию класса и узнать полный список атрибутов этого класса или ссылку на родительский класс, у которого наследуются все или некоторые атрибуты. Имя экземпляра объекта дает информацию о принадлежности конкретного модуля или интерфейса определенному коммуникационному устройству, например имя В1.Е1.Р2 определяет второй порт модуля повторителя Е1, входящего в состав корпоративного концентратора В1.
Рис. 9. Пример дерева включений
Правила определения управляемых объектов
Классы управляемых объектов OSI должны определяться в соответствии со стандартом GDMO (Guidelines for the Definition of Managed Objects )-- Правила определения управляемых объектов), являющимся стандартом ISO 10165-4.В GDMO определяется несколько шаблонов (templates) -- пустых форм, которые заполняются для описания определенного класса управляемых объектов. В шаблоне класса перечисляются комплекты свойств (PACKAGES), которые составляют класс. Шаблон комплекта свойств PACKAGE перечисляет Атрибуты, Группы атрибутов, Действия, Поведение и Уведомления, то есть свойства, сгруппированные для удобства описания класса объектов. Отношения наследования между классами описываются с помощью шаблона Связывание имен.
Атрибуты и Группы атрибутов определяют параметры объекта, которые можно читать и узнавать из них о состоянии объекта. Свойства Действия описывают возможные управляющие воздействия, которые допускается применять к данному объекту -- например, мультиплексировать несколько входных потоков в один выходной. Свойство Поведение описывает реакцию объекта на примененное к нему действие. Уведомления составляют набор сообщений, которые генерирует объект по своей инициативе.
Заполненные шаблоны GDMO определяют представление класса и его свойств. Заполнение шаблонов выполняется в соответствии с нотацией ASN.1. В отличие от стандартов SNMP, использующих только подмножество типов данных ASN.1, в GDMO и CMIP применяется полная версия ASN.1.
На основании правил GDMO определено несколько международных стандартов на классы управляемых объектов. Документы Definition of Management Information (DMI, ISO/IEC 10165-2:1991) иGeneric Management Information (GMI, ISO/IEC CD 10165-5:1992) являются первыми определениями MIB на основе окончательной версии GDMO. Эти MIB могут рассматриваться как ISO-эквивалент для Internet MIB II, так как они создают основу для построения более специфических MIB. Например, DMI определяет класс объектов, называемый Тор, который является верхним суперклассом, -- он содержит атрибуты, которые наследуются всеми другими классами управляемых объектов. Определены также классы объектов System и Network, занимающие верхние позиции в дереве наследования, так что любой агент должен понимать их атрибуты. В 1992 году была завершена работа и над более специфическими классами объектов -- объектами сетевого и транспортного уровней (ISO/IEC 10737-1 и ISO/ IEC 10733).
Сегодня многие организации работают над созданием классов объектов на основе GDMO. Это и международные организации по стандартизации -- ISO, ITU-T, ANSI, ETSI, X/Open, и организации, разрабатывающие платформы и инструментальные средства для систем управления, такие как SunSoft, Hewlett-Packard, Vertel, ISR Global. Для телекоммуникационных сетей в рамках архитектуры TMN разработан стандарт М.3100, который описывает ряд специфических для телекоммуникационных сетей классов объектов.
Описания классов управляемых объектов OSI регистрируются как в частных ветвях дерева ISO -- ветвях компаний Sun, Hewlett-Packard, IBM и т. п., так и в публичных ветвях, контролируемых ISO или другими международными органами стандартизации. В отсутствие одной регистрирующей организации, такой как IETF Internet, использование классов объектов OSI представляет собой непростую задачу.
Протокол CMIP и услуги CMIS
Доступ к управляющей информации, хранящейся в управляемых объектах, обеспечивается с помощью элемента системы управления, называемого службой CMSIE (Common Management Information Service Element). Служба CMSIE построена в архитектуре распределенного приложения, где часть функций выполняет менеджер, а часть -- агент. Взаимодействие между менеджером и агентом осуществляется по протоколу CMIP. Услуги, предоставляемые службой CMSIE, называются услугами CMIS (Common Management Information Services).
Протокол CMIP и услуги CMIS определены в стандартах Х.710 и Х.711 ITU-T. Услуги CMIS разделяются на две группы -- услуги, инициируемые менеджером (запросы), и услуги, инициируемые агентом (уведомления).
Услуги, инициируемые менеджером, включают следующие операции:
M-CREATE
Инструктирует агента о необходимости создать новый экземпляр объекта определенного класса или новый атрибут внутри экземпляра объекта;
M-DELETE
Инструктирует агента о необходимости удаления некоторого экземпляра объекта определенного класса или атрибута внутри экземпляра объекта;
M-GET
Инструктирует агента о возвращении значения некоторого атрибута определенного экземпляра объекта;
M-SET
Инструктирует агента об изменении значения некоторого атрибута определенного экземпляра объекта;
M-ACTION
Инструктирует агента о необходимости выполнения определенного действия над одним или несколькими экземплярами объектов.
...Подобные документы
Общие понятия, задачи и характеристика компьютерной сети TMN: технология управления, состав и назначение основных элементов, функциональные возможности, архитектура. Реализация управления в модели ВОС. Сравнительная характеристика протоколов SNMP и CMIP.
курсовая работа [1,1 M], добавлен 18.03.2011История развития протокола SNMP. Структура и база управляющей информации. Форматы и имена объектов SNMP MIB. Протокол управления простым роутером и система управления объектами высшего уровня. Отсутствие средств взаимной аутентификации агентов.
курсовая работа [238,9 K], добавлен 29.05.2014Описания сетевых протоколов прикладного уровня, позволяющих производить удалённое управление операционной системой. Основные характеристики протокола CMIP. Изучение особенностей Telnet, сетевого протокола для реализации текстового интерфейса по сети.
реферат [47,0 K], добавлен 24.01.2014Определение, свойства и характеристики распределенных систем баз данных. Основная задача систем управления ими. Архитектура распределения СУБД. Сравнение технологий файлового сервера и "клиент-сервера". Стратегия распределения данных по узлам сети ЭВМ.
курсовая работа [601,3 K], добавлен 24.05.2015Организация и функции административного управления сетью. Использование протокола TCP/IP. Формат и классы IP-адресов. Программное обеспечение компьютерных сетей. Системы управления сетью (HP OpenView NetworkNodeManager (NNM)). Состав регламентных работ.
курсовая работа [1,2 M], добавлен 19.05.2011Общие сведения о вычислительных сетях, история их появления. Локальные и глобальные сети. Пакет как основная единица информации вычислительной сети. Главные способы переключения соединений. Методы организации передачи данных между компьютерами.
презентация [611,9 K], добавлен 25.11.2012Локальная вычислительная сеть управления систем связи и телекоммуникаций автомастерской. Пропускная способность каналов между клиентами сети и серверами. Отличия стека протоколов 100Base-T от стека протоколов 10Base-T. Расчет работоспособности сети.
курсовая работа [572,5 K], добавлен 18.01.2016Глобальная компьютерная сеть. Стандарт протоколов TCP/IP. Основные типы подключения к Интернет. Подключение через локальные сети. Выделенная линия или канал. Направления развития Internet. Локальные вычислительные сети. Адресация в сети Интернет.
презентация [1,4 M], добавлен 28.10.2011Применение сетевых технологий в управленческой деятельности. Понятие компьютерной сети. Концепция открытых информационных систем. Преимущества объединения компьютерных сетей. Локальные вычислительные сети. Глобальные сети. Международная сеть INTERNET.
курсовая работа [38,1 K], добавлен 16.04.2012Методы защиты автоматизированных систем. Анализ сетевых уровней на предмет организации виртуальных частных сетей. Варианты построения виртуальных защищенных каналов. Безопасность периметра сети и обнаружение вторжений. Управление безопасностью сети.
курсовая работа [817,8 K], добавлен 22.06.2011Принцип построения компьютерных сетей: локальные вычислительные сети и глобальные компьютерные сети Internet, FidoNet, FREEnet и другие в деле ускорения передачи информационных сообщений. LAN и WAN сети, права доступа к данным и коммутация компьютеров.
курсовая работа [316,0 K], добавлен 18.12.2009Компьютерные сети и протоколы передачи данных. Устройства, взаимодействующие с компьютерными сетями при помощи протоколов передачи данных. Мобильные вычислительные устройства и операционные системы. Клиент-серверное приложение для управления расписанием.
дипломная работа [1,8 M], добавлен 11.12.2015Стандартные сети коммуникационных протоколов. Стек OSI. Стек TCP/IP. Принципы объединения сетей на основе протоколов сетевого уровня. Ограничения мостов и коммутаторов. Модем как средство связи между компьютерами. Международные стандарты модемов.
курсовая работа [29,3 K], добавлен 06.07.2008Теоретические основы организации локальных сетей. Общие сведения о сетях. Топология сетей. Основные протоколы обмена в компьютерных сетях. Обзор программных средств. Аутентификация и авторизация. Система Kerberos. Установка и настройка протоколов сети.
курсовая работа [46,3 K], добавлен 15.05.2007Общие принципы построения цифровых систем передачи, их иерархия и достоинства. Организация управления сетью оборудования связи с помощью персонального компьютера по интерфейсу серии F. Оборудование гибкого мультиплексирования ОГМ-30Е, принцип его работы.
дипломная работа [1,1 M], добавлен 28.10.2013Характеристика протоколов и методов реализации частных виртуальных сетей. Организация защищенного канала между несколькими локальными сетями через Интернет и мобильными пользователями. Туннель на однокарточных координаторах. Классификация VPN сетей.
курсовая работа [199,6 K], добавлен 01.07.2011Анализ структуры незащищенной сети и выявление потенциальных угроз информационной безопасности. Исследование функции туннелирования открытого трафика локальной сети. Характеристика защиты Cisco IP-телефонии между двумя офисами и мобильными компьютерами.
курсовая работа [851,1 K], добавлен 22.06.2011Классификация компьютерных сетей (КС) по различным признакам. Исследование современных протоколов управления КС. Анализ архитектур управления КС. Разработка требований, предъявляемых к системам управления КС. Выбор способа организации системы мониторинга.
дипломная работа [3,3 M], добавлен 13.10.2016Создание автоматизированной системы мониторинга состояния аппаратных средств компьютерных сетей на основе протокола SNMP в среде программирования С++Builder. Описание реляционной базы данных и ее визуальное представление. Разработка диаграммы классов.
отчет по практике [2,2 M], добавлен 05.01.2016Создание автоматизированных систем управления для предприятий нефтяной и газовой промышленности. Система управления базами данных (СУБД), ее функциональные возможности, уровневая архитектура. Характеристика реляционных, объектных и распределенных СУБД.
курсовая работа [434,7 K], добавлен 20.07.2012
