В данном дипломном проекте требуется разработать "Систему конфигурирования syslog-ng с использованием протокола netconf" для коммутаторов ME5100. Для этого требуется определить модель данных, на основе которых будет строиться конфигурация, утилиты syslog-ng и описать ее на языке YANG, так же необходимо передать модель данных с netconf server на netconf client, так же необходимо разработать библиотеки:

libsyslogapi. so (будет заниматься извлечением конфигурационных данных из дерева данных)

services_syslog. so (будет заниматься генерацией конфигурационного файла для syslog-ng)

Данный механизм разрабатывается для сервисных коммутаторов ELTEX ME5100. Для реализации данной задачи нужно изучить принципы конфигурирования syslog-ng для того что бы можно было сгенерировать конфигурационный файл. Так же был модифицирована утилита syslog-ng для возможности ротации файлов без использования дополнительной утилиты logrotate.

Описание

1.1 Простой протокол сетевого управления (SNMP)

1.1.1 Описание SNMP протокола

SNMP (Simple Network Management Protocol - простой протокол сетевого управления) - протокол для управления сетевыми устройствами в IP-сетях на основе TCP/IP. К устройствам поддерживающим SNMP относятся маршрутизаторы, принтеры, серверы, рабочие станции, коммутаторы, модемные стойки и другие. Обычно протокол применяется в системах сетевого управления устройстваи для контроля и наблюдения подключенных к сети устройств на предмет показателей, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. В него входит набора стандартов для сетевого управления устройстваи

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

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

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

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

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:

Управляемое устройство;

Агент - программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;

Система сетевого управления (Network Management System, NMS) - программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети.

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

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

В структуру применения системы управления сетью (NMS) включен, мониторинг и управление управляемых устройств. NMS обеспечивает основную часть данных, необходимых для управления сетью. В любой управляемой сети может быть один или несколько NMS.

SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели OSI). Агент SNMP получает запросы по UDP-порту 161. Менеджер может посылать запросы с любого доступного порта источника на порт агента. Ответ агента будет отправлен назад на порт источника на менеджере. Менеджер получает уведомления (Traps и InformRequests) по порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании TLS или DTLS запросы получаются по порту 10161, а ловушки отправляются на порт 10162.

В SNMPv1 указано пять основных протокольных единиц обмена (protocol data units - PDU). Еще две PDU, GetBulkRequest и InformRequest, были введены в SNMPv2 и перенесены в SNMPv3.

Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид как показано на рисунке 1

Рисунок 1. Представление SNMP сообщения.

1.1.2 Протокольные единицы обмена SNMP

На рисунке 2 показано схема запросов и откликов SNMP.

Рисунок 2 Схема запросов/откликов SNMP

Ниже перечислены семь протокольных единиц обмена SNMP:

1 GetRequest - Запрос от менеджера к объекту для получения значения переменной или списка переменных. Требуемые переменные указываются в поле variable bindings (раздел поля values при этом не используется). Получение значений указанной переменной должно быть выполнено агентом как Атомарная операция. Менеджеру будет возвращен Response (ответ) с текущими значениями.

2 SetRequest - Запрос от менеджера к объекту для изменения переменной или списка переменных. Связанные переменные указываются в теле запроса. Изменения всех указанных переменных должны быть выполнены агентом как атомарная операция. Менеджеру будет возвращен Response с (текущими) новыми значениями переменных.

3 GetNextRequest - Запрос от менеджера к объекту для обнаружения доступных переменных и их значений. Менеджеру будет возвращен Response со связанными переменными для переменной, которая является следующей в базе MIB в лексиграфическом порядке. Обход всей базы MIB агента может быть произведен итерационным использованием GetNextRequest, начиная с OID 0. Строки таблицы могут быть прочтены, если указать в запросе OID-ы колонок в связанных переменных.

4 GetBulkRequest - Улучшенная версия GetNextRequest. Запрос от менеджера к объекту для многочисленных итераций GetNextRequest. Менеджеру будет возвращен Response с несколькими связанными переменными, обойденными начиная со связанной переменной (переменных) в запросе. Специфичные для PDU поля non-repeaters и max-repetitions используются для контроля за поведением ответа. GetBulkRequest был введен в SNMPv2.

5 Response - Возвращает связанные переменные и значения от агента менеджеру для GetRequest, SetRequest, GetNextRequest, GetBulkRequest и InformRequest. Уведомления об ошибках обеспечиваются полями статуса ошибки и индекса ошибки. Хотя эта единица использовалась как ответ и на get-, и на set-запросы, она была названа GetResponse в SNMPv1.

6 Trap - Асинхронное уведомление от агента - менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменен в SNMPv2 и PDU переименовали в SNMPv2-Trap.

7 InformRequest - Асинхронное уведомление от менеджера - менеджеру или от агента - менеджеру. Уведомления от менеджера - менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована и не сообщается о потерянных пакетах. InformRequest исправляет это отправлением назад подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InformRequest. Этот PDU был введен в SNMPv2.

1.1.3 Безопасность SNMP

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

SNMP версий 1 и 2 подвержены перехвату пакетов со строками сообщений, так как они не используют шифрование.

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

Хотя SNMP работает с TCP и другими протоколами, обычно он используется с UDP, то есть без установки соединения и с уязвимостью к атакам подменой IP. Для ограничения SNMP-доступа могут быть использованы списки доступа к устройству, хотя механизмы защиты SNMPv3 способны помешать успешной атаке.

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

SNMP возглавляет составленный SANS Institute список "Common Default Configuration Issues" с вопросом изначальной установки строк сообщества на значения "public" и "private" и занимал десятую позицию в SANS Top 10 Самых критических угроз Интернет-безопасности за 2000 год.

1.2 Сетевой протокол конфигурирования NETCONF

1.2.1 История NETCONF

В конце 80-х IETF разработал SNMP, который стал очень популярным. Несмотря на то, что SNMP предоставлял возможность конфигурирования устройств, этим протоколом пользовались по большому счету для мониторинга сетей. В 2002 году Совет по архитектуре Интернета и ключевые члены IETF-сообщества объединились с операторами связи, чтобы обсудить эту ситуацию. Результаты обсуждения опубликованы в RFC 3535. На тот момент операторы связи использовали проприетарный командный интерфейс для конфигурирования своих устройств. Интерфейс имел множество удобств, в отличие от SNMP. К тому же, множество производителей не позволяли полностью конфигурировать свои устройства через SNMP. Сетевые инженеры в основном писали скрипты, которые помогали им управлять устройствами, однако, командный интерфейс в этом случае является причиной многих сложностей. Наиболее значимой из которых является непредсказуемось вывода, формируемого сетевым устройством. Содержимое и форматирование вывода имеет склонность к изменениям в не всегда предсказуемую сторону.

В то же время компания Juniper Networks использовала основанную на XML конфигурацию. Это было предложено в IETF и распространено среди сообщества.

Эти два факта послужили причиной создания протокола, который удовлетворял бы требованиям как сетевых операторов так и поставщиков оборудования.

1.2.2 Возможности протокола

Базовая функциональность NETCONF может быть расширена посредством дополнений. При установке сессии клиент и сервер обмениваются друг с другом информацией об установленных расширениях. RFC 4741 определяет дополнительные возможности, в частности: xpath и: validate.

Возможность подписки и получения асинхронных сообщений опубликована в RFC 5277. Она определяет запрос типа <create-subscription>, который включает возможность подписки на сообщения реального времени. В свою очередь сообщения отправляются посредством инструкции <notification>. RFC также определяет возможность: interleave, которая совместно с: notification помогает обрабатывать различные NETCONF запросы во время включенной подписки.

Дополнительные возможности включают блокировку части конфигурации. Это позволяет в рамках нескольких сессий редактировать не перекрывающиеся деревья в исполняемой конфигурации. Без этого дополнения возможна только блокировка всей конфигурации.

В данный момент рабочая группа работает над поддержкой сообщений, позволяющих обмениваться шаблонами (XML Schema, Relax NG, etc.), которые определяют дерево NETCONF.

1.2.3 Описание протокола NETCONF

Сетевой протокол конфигурирования, NETCONF, является IETF протоколом управления сетью и описан в RFC 4741.netCONF в настоящее время используется крупными поставщиками сетей для работы с сетевым оборудованием и получила сильную поддержку в данной отрасли. Производители оборудования начинают поддерживать NETCONF на своих сетевых устройствах.netCONF обеспечивает механизмы для установки, обработки и удаления конфигурации сетевых устройств. Его деятельность осуществляется на верхней части слоя простого удаленного вызова процедур (RPC). Протокол NETCONF использует XML кодирование данных на основе конфигурации данных, а также сообщения протокола.netCONF предназначен для замены программных интерфейсов CLI на основе, такого языка как Perl кроме того, NETCONF часто использует туннелирование TCP соединения с помощью Secure Shell (SSH) [3] с помощью "NETCONF" подсистемы и во многих отношениях он имитирует собственный интерфейс CLI через SSH соединение, доступный в устройстве. Тем не менее, он использует структурированные схемы управлениями данных и предоставляет подробную структурированную информацию об ошибках, возврат которых CLI не может обеспечить.

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

NETCONF может быть схематично разделен на четыре уровня представленных на рисунке 3.

Рисунок 3. Разделение NETCONF на уровни.

NETCONF имеет концепцию логических баз данных, таких как "WRITABLE-RUNNING" или "CANDIDATE" (рисунок 3.3). Операторам нужено выбрать способ распространения изменений в устройствах и проверять их на месте, прежде чем активировать их. Об этом свидетельствуют два нижних вариантов на рисунке 4 где конфигурационные данные могут быть отправлены в базы данных кандидатов в устройствах, прежде чем они намерены работать в производственных приложениях.

Рисунок 4. NETCONF база данных.

Во всех сетевых устройствах использующих для управления конфигурациями NETCONF должна быть возможность блокирования, редактирование, сохранение и разблокировка конфигурационных данных. Кроме того, все изменения в конфигурационных данных должны быть сохранены в энергонезависимой памяти. Пример из RFC 4741, который добавляет интерфейс с именем "Ethernet0/0" в текущей конфигурации, заменяя любой предыдущий интерфейс с этим именем показан на листинге 3.1.

Листинг 1 - Пример из RFC 4741.

<rpc message-id=: ”101”

xmlns=”urn: ietf: params: xml: ns: netconf: base: 1.0”>

<edit-config>

<target>

<running/>

</target>

<config

xmlns: xc=" urn: ietf: params: xml: ns: netconf: base: 1.0”

<top xmlns=http://example.com/schema/1.2config>

<interface xc: operation=”replace”>

<name>Ethernet0/0</name>

<mtu>1500</mtu>

<address>

<name>192.0.2.4</name>

<prefix-length>24</prefix-length>

</address>

</interface>

</top>

</config>

</edit-config>

</rpc>

<rpc-replay message-id=”100”

xmlns=” urn: ietf: params: xml: ns: netconf: base: 1.0”>

</ok>

</rpc-replay>

Базовая реализация протокола включает следующие виды запросов: <get> <get-config> <edit-config> <copy-config> <delete-config> <lock> <unlock> <close-session> <kill-session>.

1.2.4 Содержимое запросов

Содержимое запросов NETCONF представляет собой валидный XML, большая часть которого относится к конфигурации устройства.

Рабочая группа NETMOD закончила работу по созданию человеко-ориентированного языка для представления текущего состояния устройства, конфигурации, оповещений и операций, называемый YANG. YANG определен в RFC 6020 и дополнен RFC 6021, в котором представленные основные типы данных.

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

1.2.5 Транспортный протокол

NETCONF может работать поверх нескольких транспортных протоколов:

SSH (RFC 4742), который является обязательным в реализации NETCONF. SSH (Secure Shell - "безопасная оболочка" ^[1]) - сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). SSH позволяет безопасно передавать в незащищённой среде практически любой другой сетевой протокол.

SOAP (RFC 4743) SOAP (Simple Object Access Protocol - простой протокол доступа к объектам;) - протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур.

BEEP (RFC 4744) BEEP (Blocks Extensible Exchange Protocol - "Расширяемый протокол обмена блоков") - является основой для создания протоколов сетевого приложения. BEEP включает в себя блоки, такие как кадрирование, конвейеризации, мультиплексирование, отчетности и проверки подлинности для подключения и ориентированных на сообщения равный-равному (P2P) протоколов с поддержкой асинхронного полнодуплексном связи.

TLS (RFC 5539) TLS (Transport Layer Security - безопасность транспортного уровня), как и его предшественник SSL криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет. TLS и SSL используют асимметричную криптографию для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.

1.3 Сравнение протоколов NETCONF и SNMP

1.3.1 Введение

В данном сравнение основное внимание уделяется количественному анализу эксплуатационных характеристик двух различных протоколов сетевого управления конфигурациями, простой протокол управления сетью (SNMP) [1] и сетевой протокол управления конфигурациями (NETCONF) [2]. SNMP является устаревшим протоколом, который широко известен и используются в течение нескольких десятилетий и основана на протоколе обмена сообщениями запрос-ответ с использованием протокола пользовательских дейтаграмм (UDP) [3].netCONF является новой технологией.netCONF основан на протоколе XML-обмене сообщениями с использованием, как правило, протокол управления передачей (TCP) [4]. Кроме того, NETCONF часто использует туннелирование TCP соединения с помощью безопасной оболочки (SSH) [5]. Это является первым преимуществом NETCONF над SNMP

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

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

1.3.2 Основные термины используемые в сравнении

Провайдер услуг связи (ПУС) является любой сетевой оператор чья эксплуатации сети, охватывает одну или несколько географических зон и предлагая телефонную связь, видео связь и / или услуги передачи данных в их жилых и / или бизнес-клиентов. Примеры включают Ростелеком, AT&T и т.д.

Управление сетью включает в себя процессы и функции, которые оператор сети выполняет: сохранение, администрирование, контроль и управления их сетью [6].

Управление конфигурацией является функцией инициализации в сети для конкретных компонентов (например, конфигурация одного или более устройств для включения услуг или функций).

Простой протокол управления сетью (SNMP) представляет собой протокол, используемый для выполнения функций управления, включая мониторинг и выделения ресурсов [7]. Протокол основан на модели менеджера-агента, где один или несколько приложения менеджеров находятся в операционном центре ПУС и много агентов развернуты в сети, встроенные в сетевые устройства. Менеджеры выполняют запросы агентов.

Сетевой протокол конфигурации (NETCONF) является другой протокол, используемый для выполнения функций управления, в основном ориентированы на предоставления конфигурации, но может отслеживать определенную конфигурацию и оперативную информацию о состоянии сетевого устройства [3]. Протокол основан на архитектуре клиент-сервер, где один или несколько клиентских приложений находиться в пределах операционного центра ПУС и многие серверы развернуты в сети, встроенные в сетевые устройства подобно тому, как агенты SNMP. Удаленный вызов процедур (например, <rpc>, <rpc-reply>) вызываются для обмена информацией, а также NETCONF < edit-config> операция используется для функций управления конфигурацией.

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

Управляемые объекты являются параметрами внутри сетевого устройства, которые могут быть сконфигурированы с помощью операции SET SNMP [1] или операции<Edit-Config> NETCONF [3].

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

Модель данных описывают конкретный образ управляемых объектов и задаются с помощью специального синтаксиса или определённого языка. В рамках данной работы, модели данных были разработаны с использованием SMIv2 [8] для SNMP и YANG [9] для NETCONF. Модели данных реализованы как на стороне менеджера и так и на стороне агента.

1.3.3 Описание

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

Рисунок 5. Зависимость управляемых объектов от колчиества сетевых элементов.

Услуги, предлагаемые этими сетями становятся все более сложными, с более высокими требованиями клиентов, кредитование к повышению спроса на более богатой мониторинга сети и приложений, выделения ресурсов и протоколов. Tail-f [10] приведен пример платформы системы управления нового поколения, построенной по протоколу NETCONF и YANG языка моделирования данных с этими конкретными целями в виду. Если исследование может показать, что NETCONF значительно более эффективен, чем SNMP, этот факт может быть использован для пропаганды ППО перехода их технологии управления сетью от SNMP в направлении новой, XML на основе технологии. Кроме того, если начать принимать эту новую технологию и связанную с ним язык моделирования данных организации по стандартизации, такие как ITU-T и TeleManagement Forum [9] в рамках спецификации они развивают это изменит индустрию сетевых операций.

Одна группа исследователей [11] исследовали улучшения производительности в рамках протокола NETCONF, но их испытания и характеристики были основаны на ранней IETF версии проекта стандарта NETCONF и реализации прототипа. Сегодня с полки реализации поставщика клиентов NETCONF и серверы доступны. Другая исследовательская группа провела сравнение SNMP для веб-служб [12] для характеристики эффективности управления сетью. Хотя это сравнили производительность SNMP на технологии XML на основе, это не сравнить SNMP на новый протокол NETCONF; эта статья заполняет этот пробел. И, наконец, эмпирическое исследование NETCONF было проведено группой исследователей [13], где SNMP и NETCONF были сравнительно испытаны в лабораторных условиях с использованием открытой реализации сервера Yencap NETCONF. Хотя это исследование провели сравнительный анализ нескольких сотен управляемых запросов объектов с обоими протоколами, он не выполняет никакого сравнения функций управления конфигурацией с использованием этих протоколов.

1.3.4 Анализ

Выполнения количественных измерений на выполнение для двух протоколов были выполнены операции конфигурирования по ряду управляемых объектов М в функции лестничного типа, где М = 1, 10, 100, 1000, 10000 и 100000. Для того, чтобы выполнить измерения для операций конфигурирования, были использованы архитектура клиент-сервер на базе Linux был построены, как показано на рисунке 3.6.

Рисунок 6. Архитектура клиент-сервер для протоколов SNMP и NETCONF на базе LINUX.

Менеджер SNMP и клиентские приложения NETCONF были разработаны как модули Python, которые использовала Net-SNMP [14] и ncclient [15] библиотеки Python с открытым исходным кодом. ConfD NETCONF сервер, который содержит управляемый объект базы данных, является коммерческое приложение доступно от Tail-F систем [16]. ConfD Сервер также включает внедренный агент SNMP [16]. Это моделирует сетевое устройство, которое содержит информацию о конфигурации, которая может быть обновлена обоими протоколами SNMP и NETCONF.

Управляемый объект базы данных в ConfD Сервер был построен путем разработки SNMP MIB и YANG модуля, которые были эквивалентны модели данных. Это создало обстановку, в которой один объект существовал в пределах сервера ConfD и управляемых объектов базы данных, а не определять отдельные объекты базы данных для каждого протокола. Рисунок 7 иллюстрирует определение языка моделирования Unified класса о том, как были разработаны два модуля данных для того, чтобы достичь цели достигая максимума 100000 управляемых объектов. Объект List-N был определен с целочисленным идентификатором, в котором был ключ или индекс. были определены десять атрибутов листьев [1.10], причем каждая из которых является тип String, с максимальной длины строки ограничение 255 символов (SMIv2 вводит это ограничение).

Рисунок 7 Определение языка моделирования класса Unified для протокола SNMP.

Три менеджера на стороне приложения были разработаны с использованием языка программирования Python следующим образом:

NETCONF клиентское приложение для выполнения конфигурации M управляемых объектов и операций записи времени

Приложение диспетчера SNMP для выполнения конфигурации M управляемых объектов и операций записи времени

Анализатор пакетов и приложение для анализа пакетов для выполнения измерений и расчетов приложений протокола

В клиент NETCONF и приложения диспетчера SNMP включены методы для динамического построения конфигураций, которые будут направлены к симулятору сетевому устройству. Например, в клиентском приложении NETCONF, где М = 100000, приложение динамически построенного дерева данных экземпляра YANG добавление значений для всех объектов управления экземплярами. Для поддержания сравнительной тестовой среды, оба приложения сконфигурированы листовые [1.10] атрибуты с одинаковыми значениями; каждый атрибут был настроен с символьной строки в 255 длины, чтобы максимизировать размер полезной нагрузки операций конфигурации.

Приложение SNMP-менеджер, который использовал операцию SET, была оптимизирована для выполнения более одного запроса объекта в сообщении (упоминается как Unit SET Protocol Data). Было определено путем тестирования, что один PDU SET может нести до 36 управляемых запросов конфигурации объекта, наряду с их соответствующими 255 длина строки символов значения. Таким образом, этот оптимизационный подход был использован для всех операций M лестница в стиле для протокола SNMP. Не-оптимизированный подход включал бы только один запрос управляемый объект для каждого SET PDU.

Для выполнения расчетов и анализа измерений для приложений управления конфигурацией, анализатор пакетов и анализа приложение было разработано с использованием PCAP [17] и dpkt [18] модулей библиотеки Python соответственно. Это приложение было работать одновременно с NETCONF и управления SNMP-приложений для сбора, анализа и вычислить статистику эффективности управления трафиком обмена между системой управления и моделируемого сетевого устройства.

1.3.5 Результаты измерений

В этом разделе подробно описываются результаты измерений, полученные для обоих протоколов SNMP и NETCONF. Для расчетов измерений каждый эксперимент был выполнен двадцать раз (количество операций было выполнено пять раз). Средние значения для каждой статистики производительности строится на двойном логарифмическом, наряду с погрешностями по оси ординат, как показано на графиках ниже. Таблица средних значений и стандартных отклонений также предусмотрено. Значения Q1 и Q2, представленные на каждом участке представляет собой процентное соотношение SNMP-к-NETCONF для М = 1 и М = 100000 значений соответственно.

На рисунке 3.8 и в таблице 3.1 представлены результаты измерений для числа пакетов данных. Результаты показывают, что по мере увеличения М, SNMP постоянно использует меньше пакетов данных, чтобы нести полезную нагрузку конфигурации по сравнению с NETCONF. Тем не менее, при меньших значениях М, NETCONF требует большего количества пакетов данных, из-за connection - ориентированный TCP транспорт. Поскольку М приближается к 10000, разрыв между этими двумя протоколами значительно уменьшается. В общем, NETCONF потребует большей обработки накладных расходов в сети, особенно в меньшем количестве управляемых объектов.

Рисунок 8. Диаграма зависимости колечество переданных пакетов данных от колчиества управляемых объектов

Таблица 1 - Количество передаваемых пакетов данных.

На рисунке 3.9 и в таблице 3.2 представлены результаты измерения количества байтов. Результаты показывают, что протокол NETCONF последовательно выполняет большее количество байт в блоке протокола по сравнению с SNMP и, таким образом, имеет более высокие требования использования пропускной способности. Вероятно, это связано с несколькими причинами. Следует отметить, что измерения включали в себя длину заголовка UDP и TCP (UDP, длина заголовка установлен в 8 байт, в то время как минимальная длина заголовка TCP составляет 20 байт, а максимум составляет 60 байт, поэтому накладные расходы заголовок пакета выше для NETCONF).netCONF работает через SSH и, следовательно, имеет встроенную безопасность в транспорте, требующих дальнейшей служебной информации протокола и обмена сообщениями. Для этого эксперимента SNMPv2 был использован, которая не включает в себя механизм безопасности. Кроме того, NETCONF представляет собой протокол на основе сеансов, где-SNMP, как это сеанса меньше протокол работает над UDP. Это добавляет дополнительные накладные расходы для подключения и надежности TCP. И, наконец, протокол NETCONF добавляет уровень рукопожатия, чтобы позволить клиенту и серверу способность обнаруживать возможности в <hello> обмена сообщениями. Все эти дополнительные функции, которые SNMP не имеют включать дополнительные служебные данные обмена сообщениями на уровне протокола.

Таблица 2 - Количество передаваемых байт.

Рисунок 9. Диаграма зависимости колечество переданных байт от колчиества управляемых объектов

На рисунке 10 и в таблице 3 представлены результаты измерения времени работы. Результаты показывают, что даже при всем Служебное сообщение, что NETCONF вводит, время работы протокола быстрее по сравнению с SNMP, как M приблизились 1000 и за его пределами. На рисунке 6 показано, что, когда М имеет малую величину (M <~ 500) SNMP операции работают быстрее однако, как M увеличивается в размерах, становится NETCONF операционно быстрее, чем SNMP.

Рисунок 10 Диаграма зависимости времени выполнения операций от колчиества управляемых объектов

Таблица 3 - Время выполнения операции.

Для атрибута времени исполнения операции, доверительные интервалы 99% были рассчитаны, как показано в таблице 4 ниже. Важно подчеркнуть, что при М = 100000 вычисления в таблице 4 и рисунке 11, показывают, есть значение в данных, который поддерживает, что NETCONF выполняет быстрее, чем SNMP.

Таблица 4 - Количество необходимых транзакций.

Рисунок 11. Диаграма зависимости колечество транзакций от колчиества управляемых объектов

Результаты свидетельствуют что параметр производительности, где NETCONF превосходит SNMP и где SNMP не может конкурировать. Когда M ? 10 оба протокола выполняют одинаково, но за пределами этой точки, производительность SNMP резко уменьшается как количество операций, необходимых увеличивается. В NETCONF можно настроить 100000 управляемых объектов в сетевом устройстве с одной транзакции. В оптимизированном случае SNMP, это занимает 2,779 транзакции. Это почти 3000 сообщений UDP, которые имеют возможность не доходят до места назначения. Это приводит к значительно более высокому количеству сложности развития в разработке инструментов управления и на устройстве программное обеспечение для обработки этих индивидуальных около 3000 операций. Кроме того, это исключает возможность выполнять резервное копирование и восстановление конфигурации устройства с использованием протокола SNMP. С одной транзакции, этот тип операции может быть легко выполнена. Кроме того, SNMP не может выполнить проверку конфигурации, где полная конфигурация проверяется по отношению к конфигурации, хранящейся в системе управления. Только представьте себе, если оператор имел 100000 устройств на их сети, и каждое устройство было 100000 управляемых объектов, и они необходимы для выполнения полной конфигурации всех устройств. Эти результаты показывают значительный недостаток, заключающийся протокола SNMP для функций управления конфигурацией.

1.3.6 Выводы сравнения

NETCONF протокол является более эффективным для выполнения функций управления конфигурации сети, с точки зрения использования пропускной способности протокола, количество пакетов, количество транзакций и времени работы, чем SNMP. Использование количественных результатов измерений и анализа статистических данных, было установлено, что протокол NETCONF имел более эфективное использоования полосы пропускания для количества пакетов данных и байты из-за накладных расходов, необходимых для обеспечения безопасности, ориентированную на соединение (на основе сеансов) и обмена возможностями функции, которые отсутствуют в протоколе SNMP. Тем не менее, это необходимые функции для управления сложными сетями. При меньшем количестве управляемых объектов, SNMP имели более быстрое время работы, но, как управляемые объекты превысили ~ 500, эффективность времени работы NETCONF превзошла SNMP. И наконец, самое главное, NETCONF является самым мощным, когда он складывает против SNMP для ряда операций.netCONF может конфигурировать 100000 управляемых объектов в одной транзакции, используя данные конфигурации XML в качестве полезной нагрузки, в то время как лучший сценарий SNMP является 2779 сделки на такое же количество управляемых объектов. Это преимущество в производительности в одиночку перевешивает более эффективное использование полосы пропускания, что NETCONF несет с протоколом.

Выводы очевидны; NETCONF является жизнеспособной альтернативой SNMP для функций управления конфигурацией для современных сложных сетей. Протокол NETCONF явно обладает способностью вытеснять SNMP в качестве протокола управления конфигурацией и действующий обеспечения связи поставщика услуг с более мощным бэк-офиса инструмент для удовлетворения их более высокие требования к эксплуатации сети.

1.4 Язык YANG

1.4.1 Описание языка yang

YANG является язык моделирования данных, используемый для моделирования данных конфигурации и состояния. Язык моделирования YANG является стандартом, определенным в IETF в рабочей группе NETMOD. YANG можно сказать, что древовидные, а не объектно-ориентированный. Данные конфигурации структурирована в дерево, и данные могут быть сложных типов, таких как списки и объединения. Определения содержатся в модулях и один модуль может увеличить дерево В другом модуле. Сильные правила пересмотра определены для модулей. YANG отображается в представлении NETCONF XML.

YANG также отличается от предыдущих моделей данных языков управления сетью тем что имеет сильную поддержку ограничений и правил проверки данных. В листинге 3.2 показан простой пример YANG.

Листинг 3.2 - Пример описания submodule для dns на языке yang.

submodule execd-dns {

belongs-to execd { prefix execd; }

import inet-types { prefix inet; }

include execd-types;

description

"The 'dns' component provides support for configuring the DNS resolver.

The 'domain' keyword of /etc/resolv. conf is not supported, since

it is equivalent to 'search' with a single domain.I. e. in terms

of the data model, the domains are always configured as 'search'

elements, even if there is only one. The set of available options

has been limited to those that are generally available across

different resolver implementations, and generally useful. ";

revision "2008-11-04" {

description "draft-ietf-netmod-yang-02 compatible. ";

}

revision "2007-08-29" {

description "Syntax fixes after pyang validation. ";

}

revision "2007-06-08" {

description "Initial revision. ";

}

grouping dns {

list search {

key name;

max-elements 3;

leaf name { type int32; }

leaf domain { type inet: host; }

}

list server {

key address;

max-elements 3;

ordered-by user;

leaf address { type inet: ip-address; }

}

container options {

leaf ndots { type uint8; }

leaf timeout { type uint8; }

leaf attempts { type uint8; }

}

}

}

1.4.2 Дерево данных для syslog-ng

На рисунке 3.12, представлено дерево данных которое получим в результате написанного yang файла.

Рисунок 12. Структура модуля syslog-ng для установки конфигурационных значений.

Наш модуль syslog-ng состоит из следующих элементов

Список host (список удалённых хостов куда будут отправляться логи)

Узел host (имя по которому будем получать доступ к настройки удаленного хоста)

Контейнер ipv4_or_ipv6 (Содержит настройки удаленного хоста)

Узел severity (Устанавливается уровень логирования)

Выбор tcp_udp_type (в зависимости от типа установленного порта выбирается тип передачи пакетов)

Узел tcp_type (Узел в котором устанавливается порт для tcp пакетов)

Узел udp_type (Узел в котором устанавливается порт для udp пакетов)

Узел cli-commands (Включает и выключает логирование)

Узел console (Устанавливается уровень логирования выводящийхся логов в консоль)

Узел monitor (Устанавливается уровень логирования выводящийхся логов в ssh/telnet сессии)

Контейнер buffer (Доступ к настройкам buffer файлу)

Узел rotate (Устанавливает количество файлов ротации)

Узел size (Устанавливает размер файла ротации)

Узел severity (Устанавливается уровень логирования выводяшихся сообщений в buffer файл)

1.4.3 Сгенерированные команды из yang файла для настройки syslog-ng

При компиляции утилиты netconf из написанных yang файлов строится не только дерево данных, от куда будут изыматься значения для генерации конфигурационного файла, но и так же генерируется xml файл описывающий команды для настройки syslog-ng в среде cli. На рисунке 3.13 приведен пример вида в команд в оболочке cli.

Рисунок 13 Пример работы с cгенерированными командами в оболочке cli.

После установки значений в дереве и выполнения команды commit в обалочке cli, сформированное дерево данных отправляеться на NETCONF сервер.netCONF сервер определяет модуль у которого были изменения в дереве и запускает для него api библиотеку для извлечения данных в дереве.

1.5 Описание принципов работы библиотеки libsyslogapi. so