Поле monitor содержит информацию о уровни логирования в ssh/telnet сессии

Поле buffer содержит информацию о настройках buffer файла.

После того как все узлы дерева просмотрены и данные записаны в структуру syslog_t, вызывается функция int generate_config_syslog (syslog_t * syslog, service_data_t * service_data, const char * config_path) которая принадлежит библиотеки libservices_syslog. so и занимается генерацией конфигурационного файла. Параметры функции следующие:

syslog_t * syslog - структура которая была заполнена в библиотеки libsyslogapi. so

service_data_t * service_data - структура которая заполняется и необходима для дальнейшего перезапуска утилиты syslog-ng

const char * config_path - путь до места генерации конфигурационного файла.

После выполнения этой функции будет сгенерирован конфигурационный фал syslog. conf для syslog-ng. Что бы утилита начала работать по новой конфигурации необходимо отправить команду которая хронится в service_data в service-manager с помощью функции send_command (ipc_hub_conn,svc_mgr_local_addr, SRV_MGR_API_TO, &rpl_data, &srv, service_data->cmd), где service-manager определит PID syslog-ng и выполниг команду kill - hup SYSLOG_PID, в результате которой будет перечитан конфигурационный файл утилитой libsyslog. После выполнения функции send_command она вернет код возврата который может быть в следующих состояниях:

SVCAPI_RC_OK - означает что сообщение доставлено до service-manager

SVCAPI_RC_FAIL - означает что сообщение не дошло до service-manager

Если получили SVCAPI_RC_FAIL тогда возвращается код ошибки этой функцией и NETCONF server отправляет NETCONF client-у что применение конфигурации не удалось и выводит сообщение на экран уведомляя пользователя.

Если получили SVCAPI_RC_OK тогда необходимо проверить значение переменной rpl_data. reply_msg->data_buf на соответствие со строкой "ОК!". Если это так то конфигурация была применена и логирование с помощью syslog-ng ведётся по только что сгенерированной конфигурации. Иначе это может означить следующие:

Утилита syslog-ng не может работать с новой конфигурацией из за ошибок парсинга.

Утилита syslog-ng не существует.

У пользователя cli не хватает прав на применение конфигурации.

После чего в окно пользователя выводиться сообщение что commit применен и выводиться время потраченное на передачу сообщения к NETCONF client, генерацию конфигурационного файла, применение конфигурации с помощью server-manager.

1.6 Описание принципов настройки syslog-ng

1.6.1 Базовая настройка

Настройка для простой одиночной машины, с чего начать? По умолчанию syslog-ng в идёт с конфигом как на листинге 3.6.

Листинг 6 - Пример конфигурационного файла для syslog-ng.

options {

chain_hostnames (off);

sync (0);

};

source src {

unix-stream ("/dev/log" max-connections (256));

internal ();

file ("/proc/kmsg");

};

destination messages { file ("/var/log/messages"); };

destination console_all { file ("/dev/tty12"); };

log { source (src); destination (messages); };

log { source (src); destination (console_all); };

source src {

unix-stream ("/dev/log" max-connections (256));

internal ();

file ("/proc/kmsg");

};

destination messages { file ("/var/log/messages"); };

destination console_all { file ("/dev/tty12"); };

log { source (src); destination (messages); };

log { source (src); destination (console_all); };

Попытаемся более ли менее разобраться в данных строках: options указывает глобальные опции, к ним вернёмся позже. А для начала рассмотрим правила

1.6.2 Правила syslog-ng

В syslog-ng используется всего четыре правила:

Source

Filter

Destination

Log

Далее рассмотрим их подробнее по порядку.

Правило source

Данное правило описывает источник. Синтаксис этого правила показан на листинге 7.

Листинг 7 - Описание правила source.

source <identifier> { source-driver (params); source-driver (params);. };

identifier - это то как вы назавете это правило (часто называют src)

source-driver (источником) - может быть: internal, unix-stream, unix-dgram, file, pipe, fifo, tcp, udp, tcp6, udp6, sun-stream, sun-streams

internal - это логи самого syslog-ng

unix-stream/unix-dgram - для AF_UNIX socket'ов (сокеты в файловом пространстве имён) различие между ними в том, что dgram применяется в BSD и использует семантику SOCK_DGRAM

tcp/tcp6 и udp/udp6 - логично догадаться, для пересылки логов по сети

file - это специальный файл (устройство, спецфайлы), примеры: /proc/kmsg, /dev/kmsg. обычный файл вроде my. log использовать нельзя, для этого лучше использовать, что нибудь вроде tail - f my. log | logger - p local4. info

pipe - похож на file, но не рекомендуется к использованию потому, как специфика pipe открывает именованный канал для чтения записи, что не рекомендуется, например для /proc/kmsg.

sun-stream (s) - это какое-то новое IPC от sun'a для Solaris'ов с версии 2.5 (что-то вроде doors)

params - их довольно много, причем для каждого типа соединения свои параметры, для детального изучения рекомендуется обратиться к документации syslog-ng

Пример стандартного источника логов показан на листинге 9.

Листинг 9 - Пример правила source.

source src {

unix-stream ("/dev/log" max-connections (256));

internal ();

file ("/proc/kmsg");

};

Если мы хотим, чтобы syslog-ng слушал так же UDP сокет (к примеру haproxy пишет в syslog-ng через udp socket), то в источник (source src) надо добавить строку, для поддержки udp как показано в листинге 3.10.

Листинг 10 - Пример правила source для удаленого server syslog-ng.

source src {

.

udp (ip ("127.0.0.1") port (514));

}

Правило filter

Фильтры описываются как показано на листинге 11.

Листинг 11 - Описание правила filter.

filter <identifier> { expression; };

expression в фильтре может принимать следующие значения:

facility (текст) - такой вариант grep, если встречается строка, она выбирается фильтром, допускается вложенность

level (приоритет) - выборка по приоритетам (emerg/warning/debug и т.д.)

program (имя) - grep по имени программы, которая шлёт логи (пример: sshd)

host (имя_хоста) - grep по имени хоста:)

match (regexp) - регулярное выражение

filter - т.е. вложенность фильтров в фильтры

netmask (ip/mask) - grep по ip или маске

Пример, фильтр выбирающий только сообщения программы foo показаны на листинге 12.

Листинг 12 - Пример использования правила filter.

filter f_foo { program ("foo"); };

Правило destination

Пункт назначения. Описывается как и прочие правила и показаны на листинге 13.

Листинг 13 - Описание правила destionation.

destination <identifier> { destination-driver (params); destination-driver (params);. };

Драйвера назначения повторяют драйвера source, за исключением некоторых новых:

usertty (имя_пользователя) - пугать пользователя логами:)

program (программа_с_всякими_параметрами) - пускает логи на stdin программы

Вот и все отличия.

Пример, логов в файл показано на листинге 14.

Листинг 14 - Пример использования правила destionation.

destination messages { file ("/var/log/foo. log"); };

Правило log

Самое главное правило. Его синтексис показан на листинге 15:

Листинг 15 - Простой пример правила использования log.

log { source (s1); source (s2);.

filter (f1); filter (f2);.

destination (d1); destination (d2);.

flags (flag1 [, flag2.]);

};

понятно, что является набором комбинаций источников, фильтров и назначения + флаги.

Пример, все что идет из src направить в messages показано на листинге 16.

Листинг 16 - Стандартное правило log.

log { source (src); destination (messages); };

Или, все что попало под фильтр foo пустить на консоль, пример с фильтром показан на листинге 17.

Листинг 17 - Пример использования правила log с фильтром внутри.

log { source (src); filter (f_foo); destination (console); };

1.6.3 Организация сервера логов

Для того что бы настроить "сток" логов в одно место - сервер (ip-192.168.200.10). На клиентах в syslog-ng. conf необходимо написать destination и log как показано на листинге 19.

Листинг 19 - Пример конфигурации на отправку у client syslog-ng.

destination remote {udp ("192.168.200.10" port (514)); };

log { source (src); destination (remote); };

На сервере 192.168.200.10 в syslog-ng. conf необходимо написать как на листинге 20.

Листинг 20 - Пример конфигурирования на прием у server syslog-ng.

source from_all { udp (ip ("192.168.200.10") port (514)); };

destination to_all { file ("/var/log/HOSTS/$HOST/log" perm (0640) dir_perm (0755) create_dirs (yes)); };

log { source (from_all); destination (to_all); };

После чего необходимо перезапустить syslog-ng на клиентах и сервере и можно будет увидеть что логирование видеться.

1.6.4 Шаблоны syslog-ng

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

SODATE\FULLDATE - варианты описание даты

FACILITY - каким уровнем сгенерированно сообщение (auth/mail/cron и т.д.)

PRIORITY - приоритет (info/err и т.д.)

HOST\FULLHOST - откуда

HOST_FROM - последний хост в цепочке

PROGRAM - какая программа

PID - pid процесса

MSG - само сообщение

Хороший пример шаблона показан на листинге 21.

Листинг 21 - Пример простого шаблона для вывода сообщений.

template ("$ISODATE - $HOST_FROM <$FACILITY. $PRIORITY> $MSG\n")

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

Библиотека libservices_syslog. so была написана для генерации конфигурационного файла для утилиты syslog-ng. Она содержит одну функцию которая доступна для вызова в библиотеке libsyslogapi. so. Первое что делает функция generate_config_syslog () это создает файл syslog. conf в директории /tmp, и только после окончания генерации конфигурации уже копирует в заданную директорию конфигурационный файл. Это делается для того что бы в случае падения syslog-ng мог перезапуститься и работать с самой с актуальным конфигурационным файлом, и избежать случая когда конфигурационный файл генерируется и падает syslog-ng, что бы при перезапуске небыло проблем с парсингом.

После того как был создан файл syslog. conf начинается генерация и запись данных в него. Сперва генерируется часть как показано на листинге 22.

Листинг 22 - Описание версии syslog-ng и переменных.

@version: 3.7

@include "/usr/etc/modules. conf"

@define log_path "/var/log/syslog"

@define log_path_eltex "/var/log/syslog/eltex"

@version: 3.7 - Указывается версия используемой утилиты syslog-ng

@include "/usr/etc/modules. conf" - Включает файл "/usr/etc/modules. conf в котором описаны модули используемые syslog-ng, например для парсинга конфигурационного файла

@define log_path "/var/log/syslog" - Обявляет переменную log_path которая содержит путь до дириктории в которой будут хранится лог файл.

@define log_path_eltex "/var/log/syslog/eltex" - Обявляет переменную log_path_eltex в которой будет храниться путь до директории содержащей подробные логи.

Затем генерируются опции которые показаны на листинге 23.

Листинг 23 - Описание опции для syslog-ng.

options {

perm (0644);

keep_hostname (yes);

use_dns (no);

stats_freq (0);

mark_freq (0);

time_reopen (60);

rotate_if_larger (10000000);

rotate_program ("/bin/rotate 1");

};

perm (0644) - Устанавливает права доступа к лог файлам.

keep_hostname (yes) - Указывает доверять имени узла, которое включено в журнальное сообщение. Если keep_hostname - yes и в сообщении имеется имя узла, то оно остаётся неизменным, в другом случае оно всегда перезаписывается основываясь на информации о том, откуда было принято сообщение.

use_dns (no) - Включить или выключить использование DNS. syslog-ng блокиреут DNS-запросы, поскольку включение DNS может привести к атаке с отказом в обслуживании (DoS). Для предотвращения DoS, защитите ваш целевой syslog-ng правилами пакетного фильтра, и удостоверьтесь, что все узлы, которые может запросить syslog-ng решаемы.

stats_freq (0) - отключает опцию stats.

mark_freq (0) - отключает опцию mark.

time_reopen (60) - Время ожидания перед повторной установкой разорвавшихся подключений.

rotate_if_larger (10000000) - Размер файла по достижению которого будет выполнена ротация файла, размер указывается в битах. Значение получаем из полученной структуры syslog_t, которую получили в результате работы библиотеки libsyslogapi. so.

rotate_programm (“/bin/rotate 1“) - Устанавливает путь до скрипта выполняющего ротацию, и количество файлов ротации. Значение получаем из полученной структуры syslog_t, которую получили в результате работы библиотеки libsyslogapi. so.

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

Листинг 24 - Описание основных source, filter и destination.

source s_local {

unix-dgram ("/dev/log");

file ("/proc/kmsg");

internal ();

};

destination d_console {

file ("/dev/console" template ("$ISODATE $MSG\n") template_escape (no));

destination d_monitor {

usertty (*);

};

destination d_local_to_file_excluded_procs {

file ("`log_path_eltex`/excluded_procs" template ("$ISODATE $PROGRAM $MSG\n") template_escape (no) flags (syslog-

};

destination d_debug_memory {

file ("`log_path_eltex`/memory_diff" template ("$ISODATE $PROGRAM $MSG\n") template_escape (no) flags (syslog-pro

};

filter f_not_procs {

not program ("cron") and not program ("pdns_recursor") and not program ("useradd") and not program ("adduser") an

};

filter f_procs {

program ("cron") or program ("pdns_recursor") or program ("useradd") or program ("adduser") or program ("gpasswd")

};

filter f_debug_memory {

program ("ESRconfig_byte_output");

};

filter f_kernel_messages {

not (facility (kern) and level (debug. notice));

};

log {

source ("s_local");

filter ("f_procs");

destination (d_local_to_file_excluded_procs);

};

log {

source ("s_local");

filter ("f_debug_memory");

destination (d_debug_memory);

};

После того как были сгенерированы основные правила для работы syslog-ng библиотека начинает генерировать часть отвечающую за вывод сообщений на консоль устройства, показано на листинге 25.

Листинг 25 - Описание правил filter и log для вывода на /dev/console.

filter f_console {

not level (debug. emerg)

};

log {

source (s_local);

filter (f_console);

filter (f_not_procs);

filter (f_kernel_messages);

destination (d_console);

};

Где фильтр f_console устанавливает уровень логов выводящихся на консоль. По умолчанию логирование на консоль не ведётся. Если мы установили значение severity в info для консоли с помощью команды syslog console info, то филтир будет выглядить слейдующим образом, как показано на листинге 26.

Листинг 26 - Пример правила filter для console при измененом параметре.

filter f_console {

level (info. emerg)

};

Поле log для вывода в консоль всегда выглядит одинаково где:

source (s_local) - Указывает что источником сообщения является /dev/log.

filter (f_console) - Устанавливает фильтр f_console который ограничивает вывод сообщений по уровню.

filter (f_not_procs) - Устанавливает фильтр f_not_procs который ограничивает сообщения от утилит cron, pdns_recursor, useradd, adduser, так как они могут засорят лог файл излишками сообщений, и их логирование ведется в отдельный файл находящийся в директории /var/log/syslog/eltex

filter (f_kernel_messages) - Устанавливает фильтр f_kernel_messages который органичивает сообщения ядра уровнем notice.

destination (d_console) - Устанавливает вывод сообщений в dev/console по заданому шаблону.

Затем генерирует часть отвечающую за вывод логов в telnet/ssh сессии, она показана на листинге 27.

Листинг 27 - Описание правил filter и log для вывода на ssh/telnet сессии.

filter f_monitor {

not level (debug. emerg)

};

log {

source (s_local);

filter (f_kernel_messages);

filter (f_monitor);

filter (f_not_procs);

destination (d_monitor);

};

Где фильтр f_monitor устанавливает уровень логов выводящихся в telnet/ssh cессии. По умолчанию логирование в telnet/ssh сессии не ведётся. Если мы установили значение severity в warning для telnet/ssh сессий с помощью команды syslog monitor info, то филтир будет выглядить слейдующим образом, как показано на листинге 28.

Листинг 28 - Пример правила filter при измененом параметре severity.

filter f_monitor {

level (warning. emerg)

};

Поле log для вывода в telnet/ssh сессии всегда выглядит одинаково где:

1 source (s_local) - Указывает что источником сообщения является /dev/log.

2 filter (f_monitor) - Устанавливает фильтр f_monitor который ограничивает вывод сообщений по уровню.

3 filter (f_not_procs) - Устанавливает фильтр f_not_procs который ограничивает сообщения от утилит cron, pdns_recursor, useradd, adduser, так как они могут засорят лог файл излишками сообщений, и их логирование ведется в отдельный файл находящийся в директории /var/log/syslog/eltex

4 filter (f_kernel_messages) - Устанавливает фильтр f_kernel_messages который органичивает сообщения ядра уровнем notice.

5 destination (d_monitor) - Устанавливает вывод сообщений во все telnet/ssh сесии по заданому шаблону.

Затем генерирует часть отвечающую за вывод логов в buffer файл, как показано на листинге 29.

Листинг 29 - Описание правил destination, filter и log для вывода в buffer.

destination d_buffer {

file ("`log_path`/buffer" template ("$ISODATE $PROGRAM $MSG\n") template_escape (no));

};

filter f_buffer {

level (debug. emerg)

};

log {

source ("s_local");

filter (f_buffer);

destination (d_buffer);

};

Поле destination d_buffer описывает вывод сообщений в файл находящийся по пути var/log/syslog/buffer, по шаблону где:

ISODATE - Время поступления сообщения в dev/log

PROGRAM - Имя программы или утилиты от которой поступило это сообщение

MSG - Само сообщение которое поступило на dev/log.

Фильтр f_buffer устанавливает уровень логов выводящихся в лог файл buffer. По умолчанию логирование в лог файл buffer ведется всех уровней. Также можно ограничить по уровням или отключить полностью.

Поле log для вывода сообщений в buffer файл всегда выглядит одинаково где:

source (s_local) - Указывает что источником сообщения является /dev/log.

filter (f_buffer) - Устанавливает фильтр f_buffer который ограничивает вывод сообщений по уровню.

destination (d_buffer) - Устанавливает вывод сообщений в лог файл buffer по заданому шаблону

Далее генерируется часть отвечающая за отправку логов на уделенные сервера syslog-ng. Для каждого удаленного хоста генерируется свои поля destination, filter и log, на листинге 30 приведен пример для одного удаленного сервера:

Листинг 30 - Пример генерации правил для 1 удаленного сервера syslog.

destination d_host_0.

udp ("192.168.16.43" port (514) localport (514) template ("$ISODATE $MSG\n"));

};

filter f_host_0 {

level (crit. emerg)

};

log {

source ("s_local");

filter (f_host_0);

destination (d_host_0);

};

Поле destination d_host_0 описывает вывод отправку сообщению с помощьюudp пакетов на syslog-ng сервер имеющий адресс 192.168.16.43 и порт 514, по шаблону где:

ISODATE - Время поступления сообщения в dev/log.

MSG - Само сообщение которое поступило на dev/log.

Фильтр f_host_0 устанавливает уровень логов отправляемых на удаленный сервер syslog-ng. По умолчанию логирование уровень логирования на удаленный сервер syslog-ng не задан, по этому необходимо его задать в настройках удаленного сервера в командной оболочке cli. Также можно ограничить по уровням или отключить полностью.

Поле log для вывода сообщений в buffer файл всегда выглядит одинаково где:

source (s_local) - Указывает что источником сообщения является /dev/log.

filter (f_host_0) - Устанавливает фильтр f_host_0 который ограничивает отправку сообщений на удаленный сервер по уровню.

destination (d_ host_0) - Устанавливает отправку сообщений на удаленный сервер по заданному ip адресу на заданный порт.

Пример работы

Тестирование производилось на сетевых коммутаторах ME5100. После написания библиотек и внедрения их в проект конфигурирования производится следующим образом: После входа пользователя в командную оболочку cli мы увидим приветствие как на рисунке 14

Рисунок 14 Приветствие ME5100.

Далее необходимо ввести команду, если не известно какие команды доступны в даном view необходимо ввести? и мы увидим список доступных команд как на рисунке 3.15, после чего необходимо выбрать одну из команд и ввести ее. Так как нам необходимо изменить конфигурацию syslog необходимо перейти во view configure. Далее необходимо выбрать одну из доступных командконфигурирования как показано на рисунке 16.

После ввода конфигурации как показано на рисунке 17 будет построенно дерево данных на устройстве которое содержит клиент NETCONF и это дерево данных будет отправлено на сетевое устройство которое содержит сервер NETCONF, где произойдет считывания данных, генерация конфигурационного файла, отправка сигнала SUGHUP утилите syslog-ng и возвращен ответ на клиент NETCONF ответ об успешном окончании приминения конфигурации и выведит время которое потребовалось на применение конфигурации.

Рисунок 15 Просмотор списка доступных команд.

17 Доступные команды конфигурирования syslog-ng

Из конфигурации которая показана на рисунке 3.17 будет построенно дерево где будет иметься:

Включим утилиту логирования syslog-ng.

Логирование будет вестись на удаленных сервер с ip адресом 192.168.16.43 по udp порту 514 с уровнем логирования notice и ниже.

Вывод логов на консоль будет вестись сообщений уровнем alert и ниже.

buffer файл который будет хранить 1 файл ротации и ротация будет совершаться при достижении размера файла 500 Kb.

Логирование в telnet/ssh сессии не будет.

Рисунок 17 Пример конфигурирования утилиты syslog-ng.

Заключение

В ходе выпускной квалификационной работы были изученны теоретические основы протокола NETCONF и языка YANG, так же было проведенно сравнение протоколов SNMP и NETCONF и доказано, для предприятия ELTEX оптимальнее использовать протокол NETCONF. Был описан модуль syslog-ng на языке моделирования данных YANG. Были разработаны две библиотеки, одня для работы с деревом данных модуля syslog-ng и заполнения структуры на основе которой будет генерироваться конфигурационный файл, вторая библиотека занимается на основе полученных данных генерированием конфигурационного файла. Все работоспособность была проверена на комутатарх ELTEX ME5100 и ME5000. После система конфигурирования с помощью протокола NETCONF была внедрена на предприятии ELTEX, также было реализовано конфигурирование для сервисов и утилит ssh, telnet, aaa, ntp, dhcp и другие.

Библиография

1. William Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Addison-Wesley, Third Edition, 1999. ?

2. R. Enns, “NETCONF Configuration Protocol”, IETF RFC 4741, December 2006

3. J. Postel, “User Datagram Protocol”, IETF RFC 768, August 1980. ?

4. J. Postel, “Transmission Control Protocol”, IETF RFC 793, September 1981.

5. M. Wasserman, T. Goddard, “Using the NETCONF Configuration Protocol over Secure SHell (SSH)", IETF RFC 4742, December 2006. ?

6. ITU-T, “Series M: TMN and Network Maintenance: International Transmission Systems, Telephone Circuits, Telegraphy, Facsimile and Leased Circuits; Telecommunications management network; TMN management functions”, ITU-T Recommendation M.3400, February 2000. ?

7. J. Case, M. Fedor, M. Schoffstall, and J. Davin, “A Simple Network Management Protocol (SNMP)", IETF RFC 1157, May 1990. ?

8. Таненбаум Э. Современные операционные системы. - 2-е изд. - СПб.: ПИТЕР, 2002. - 1037с. ?

9. M. Bjцrklund, “YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) ”, IETF RFC 6020, October 2010. ?

10. Лав Р. Linux. Системное программирование - 2-е изд. - Санкт-Петербург: Питер, 2014. - 448. с.

11. S. M. Yoo, H.T. Ju, and J.W. Hong, “Performance Improvement Methods for NETCONF-Based Configuration Management”, Proceedings from 9th Asia-Pacific Network Operations and Management Symposium, APNOMS 2006, Busan, Korea, September 27-29, 2006, pp.242-252. ?

12. A. Pras, T. Drevers, R. v. d. Meent and D. Quartel, “Comparing the Performance of SNMP and Web Services - Based Management”, IEEE eTNSM, Vol.1, No.2, Dec. 2004, pp.1-11. ?

13. J.Yu, I. Ajarmeh, “An Empirical Study of the NETCONF Protocol”, Sixth International Conference on Networking and Services, ICNS 2010, Cancun, Mexico, March 7-13, 2010, pp.253-258. ?

14. G.S. Marzot, The Python 'netsnmp' Extension Module for the Net-SNMP Library, v5.4.3, Project Documentation Page, viewed March 26, 2011, https: // net-snmp. svn. sourceforge.net/svnroot/net - snmp/trunk/net-snmp/python/README. ?

Приложение

Наиболее употребляемые текстовые сокращения

SNMP (Simple Network Management Protocol) - простой протокол сетевого управления SSH (Secure Shell) - безопасная оболочка IP (Internet Protocol) - интернет протокол CLI (Command Line Interface) - интерфейс командной строки IETF (Internet Engineering Task Force) - Инженерный совет интернета.	NETCONF (Network Configuration) - протокол сетевого конфигурирования TCP (Transmission Control Protoco) - протокол управления передачей UDP (User Datagram Protocol) - протокол пользовательских датаграмм

Размещено на Allbest.ru