Прячем трафик: техника сокрытия IP-трафика с помощью секретных пассивных каналов. Информационный портал по безопасности

Всем привет! В сегодняшней статье расскажем о том, как настроить отправку статистики о пакетах, проходящих через наш роутер Mikrotik на коллектор для дальнейшего анализа. Все мы знаем про такой протокол как Netflow, предназначенный для учёта сетевого трафика, разработанный компанией Cisco, так вот у Mikrotik есть своя реализация данного решения, которая полностью совместима со стандартом Cisco Netflow - Mikrotik Traffic Flow .

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

Поскольку Traffic Flow полностью совместим с Cisco Netflow, то он может использоваться различными утилитами, которые разработаны для Netflow.

Traffic Flow поддерживает следующие версии Netflow:

1. version 1 - Самая первая версия формата данных Netflow. Рекомендуется использовать только если нет альтернатив
2. version 5 - Дополнение первой версии, которой появилась возможность добавления номеров автономных систем (AS) и порядковых номеров потоков
3. version 9 - новая версия, позволяющая добавлять новые поля и типы записей благодаря шаблонному исполнению

Настройка

Итак, для того, чтобы начать собирать статистическую информацию о трафике, необходимо сначала включить Traffic Flow и определиться с каких интерфейсов осуществлять сбор. Делается это при помощи комбинации следующих команд:

/ip traffic-flow set enabled=yes interfaces=ether1

В нашем случае, указан лишь один интерфейс ether1, однако, если вы хотите собирать статистику с нескольких интерфейсов, просто укажите их через запятую. Если со всех - интерфейсов введите interfaces=all .

Вы также можете настроить количество потоков, которые могут одновременно находиться в памяти роутера командой cache-entries и указав нужное значение - (128k | 16k | 1k | 256k | 2k / 4k - по умолчанию)

Командой active-flow-timeout - можно настроить максимальное время жизни потока, по умолчанию это 30 минут.

Некоторые потоки, могут стать неактивными через какое-то время, то есть, в них не будет происходить обмен пакетами, этот тайм-аут настраивается командой inactive-flow-timeout . Если пакетов в потоке нет и данное время истекло, то в следующий раз traffic flow создаст новый поток, если обмен возобновится. По умолчанию это 15 секунд, но если сделать данное время слишком коротким, то это может привести к созданию большого количества отдельных поток и переполнению буфера.

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

Ip traffic-flow target

Затем указывается IP адрес и UDP порт хоста назначения - add dst-address=(IP address) port=(UDP port) . Если вы хотите использовать конкретную версию протокола, то укажите ее командой version= (1,5,9)

Пример

Рассмотрим пример конфигурации Traffic Flow на роутере Mikrotik

Допустим мы хотим собирать статическую информацию о трафике, который проходит через интерфейс ether3 нашего роутера и отправлять её на коллектор по адресу 192.168.2.123 используя 5 версию протокола. В этом случае конфигурация может выглядеть следующим образом:

Сначала включаем Traffic Flow и указываем интерфейс

/ip traffic-flow set enabled=yes interfaces=ether3

Затем указываем адрес коллектора, стандартный порт и версию протокола 5:

/ip traffic-flow target add dst-address=192.168.2.123 port=2055 version=5

Если Вы предпочитаете консоли утилиту WinBox , то для настройки Traffic Flow левом меню откройте пункт IP и выберите Traffic Flow , перед Вами откроется следующее окно:

Необходимо включить Traffic Flow, поставив галочку напротив Enabled и выбрать желаемый интерфейс для сбора информации.

После этого переходим на вкладку Targets и добавляем параметры коллектора, достаточно внести IP адрес, порт и версию. После этого нажимаем на кнопку Apply

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

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

... Некоторые компании указывают, с каких IP -адресов может поступать трафик , но это может занять много времени. ... Это значит, что вы можете отслеживать, каким IP используется трафик вашей сети. ... Для того чтобы обеспечить безопасность ваших портов, вы можете навсегда распрощаться с динамичными адресами IP и купить постоянный. ... Порты маршрутизатора – это числовые характеристики сети,...

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

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

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

... Этот адрес называется IP . ... Но что такое IP-адрес? ... IP-адрес - 4-байтовое (32-разрядное) число, задающее уникальный номер компьютеру пользователя в Интернете. ... Если брандмауэр опознаёт пакет данных и его IP-адрес, то он позволяет этим данным «пройти». ... Брандмауэр просматривает весь трафик на наличие вирусов любого вида: - spyware (шпионящее ПО); - вредоносного программного...

... Брандмауэр с поддержкой режима обследования осмотрит каждое состояние соединения, обеспечив более высокую производительность и понизив злоумышленный трафик . ... В основном, беспроводной маршрутизатор используется для распределения сетевого трафика между сетью и Интернетом. ... Проверьте также URL, IP и МАК адреса в опциях фильтра.

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

... Пользователи iPod , чьи музыкальные файлы были потеряны в результате поломки компьютера, смогут восстановить их на компьютере со своего iPod. ... Когда вы разговариваете посредством своего компьютера, то вы общаетесь на IP-сети, которая отправляет и получает весь Интернет-трафик . ... Бизнес: Если вы являетесь менеджером компании-поставщика компьютерных услуг, то в ваши задачи входит...

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

Посмотрело: 3498

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

Это первая теоретическая статья из цикла статей, посвящённого сбору, учёту, управлению и биллингу трафика и IT-ресурсов.

Структура доступа в сеть Интернет

• Внешние ресурсы - сеть Интернет, со всеми сайтами, серверами, адресами и прочим, что не принадлежит сети, которую вы контролируете.


• Устройство доступа - маршрутизатор (аппаратный, или на базе PC), коммутатор, VPN-сервер или концентратор.


• Внутренние ресурсы - набор компьютеров, подсетей, абонентов, работу которых в сети необходимо учитывать или контролировать.


• Сервер управления или учёта - устройство, на котором работает специализированное программное обеспечение. Может быть функционально совмещён с программным маршрутизатором.

Сетевой трафик

Для передачи IP-пакета по проводам (или радио) сетевые устройства вынуждены «оборачивать» (инкапсулировать) его в пакет протокола 2го уровня (L2). Самым распространенным протоколом такого типа является . Фактическая передача «в провод» идет на 1м уровне. Обычно, устройство доступа (маршрутизатор) не занимается анализом заголовков пакетов на уровне, выше 4го (исключение - интеллектуальные межсетевые экраны).
Информация из полей адресов, портов, протоколов и счетчики длин из L3 и L4 заголовков пакетов данных и составляет тот «исходный материал», который используется при учёте и управлении трафиком. Собственно объем передаваемой информации находится в поле Length («Длина пакета») заголовка IP (включая длину самого заголовка). Кстати, из-за фрагментации пакетов вследствие механизма общий объем передаваемых данных всегда больше размера полезной нагрузки.

Суммарная длина интересных нам в данном контексте IP- и TCP/UDP- полей пакета составляет 2...10% общей длины пакета. Если обрабатывать и хранить всю эту информацию попакетно, не хватит никаких ресурсов. К счастью, подавляющий объем трафика структурирован так, что состоит из набора «диалогов» между внешними и внутренними сетевыми устройствами, так называемых «потоков». Например, в рамках одной операции пересылки электронного письма (протокол SMTP) открывается TCP-сессия между клиентом и сервером. Она характеризуется постоянным набором параметров {IP-адрес источника, TCP-порт источника, IP-адрес получателя TCP-порт получателя} . Вместо того, чтобы обрабатывать и хранить информацию попакетно, гораздо удобнее хранить параметры потока (адреса и порты), а также дополнительную информацию - число и сумму длин переданных пакетов в каждую сторону, опционально длительность сессии, индексы интерфейсов маршрутизатора, значение поля ToS и прочее. Такой подход выгоден для ориентированных на соединение протоколов (TCP), где можно явно перехватить момент завершения сессии. Однако и для не ориентированных на сессии протоколов можно проводить агрегацию и логическое завершение записи о потоке по, например, таймауту. Ниже приведена выдержка из SQL-базы , осуществляющей протоколирование информации о потоках трафика:

Необходимо отметить случай, когда устройство доступа осуществляет трансляцию адресов ( , маскарадинг) для организации доступа в Интернет компьютеров локальной сети, используя один, внешний, публичный IP-адрес. В этом случае специальный механизм осуществляет подмену IP-адресов и TCP/UDP портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.

Методы сбора информации о трафике/статистике

ПК-маршрутизатор

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

• перехват (копирование) пакетов, проходящих через сетевую карту сервера, при помощи библиотеки


• перехват пакетов, проходящих через встроенный межсетевой экран


• использование сторонних средств преобразования попакетной статистики (полученной одним из двух предыдущих методов) в поток агрегированной информации netflow

Libpcap

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

• открыть необходимый интерфейс


• указать фильтр, через который пропускать принятые пакеты, размер захватываемой части (snaplen), размер буфера,


• задать параметр promisc, который переводит сетевой интерфейс в режим захвата вообще всех проходящих мимо пакетов, а не только адресованных MAC-адресу этого интерфейса


• установить функцию (callback), вызываемую на каждый принятый пакет.

При передаче пакета через выбранный интерфейс, после прохождения фильтра эта функция получает буфер, содержащий Ethernet, (VLAN), IP и т.д. заголовки, общим размером до snaplen. Поскольку библиотека libcap копирует пакеты, заблокировать их прохождение при ее помощи невозможно. В таком случае программе сбора и обработки трафика придется использовать альтернативные методы, например вызов скрипта для помещения заданного IP-адреса в правило блокировки трафика.

Межсетевой экран

• Пользовательская программа - обработчик трафика регистрирует себя в системе, используя системный вызов, или библиотеку.


• Пользовательская программа или внешний скрипт устанавливает правило в межсетевой экран, в“заворачивающее” выбранный трафик (согласно правилу) вовнутрь обработчика.


• На каждый проходящий пакет обработчик получает его содержимое в виде буфера памяти (с заголовками IP и т.д. После обработки (учёта) программе необходимо также сообщить ядру операционной системы, что делать далее с таким пакетом - отбросить или передать далее. Как вариант, возможно передать ядру видоизмененный пакет.

Поскольку IP-пакет не копируется, а пересылается в программное обеспечение для анализа, становится возможным его «выброс», а следовательно, полное или частичное ограничение трафика определенного типа (например, до выбранного абонента локальной сети). Однако в случае, если прикладная программа перестала отвечать ядру о своем решении (зависла, к примеру), трафик через сервер просто блокируется.
Необходимо отметить, что описанные механизмы при существенных объемах передаваемого трафика создают избыточную нагрузку на сервер, что связано с постоянным копированием данных из ядра в пользовательскую программу. Этого недостатка лишен метод сбора статистики на уровне ядра ОС, с выдачей в прикладную программу агрегированной статистики по протоколу .

Netflow

Объем информации о трафике меньше самого трафика на несколько порядков, что особенно актуально в больших и распределенных сетях. Конечно же, блокировать передачу информации при сборе статистики по netflow невозможно (если не использовать дополнительные механизмы).
В настоящее время становится популярным дальнейшее развитие этого протокола - версия 9, основанная на шаблонной структуре flow record, реализации для устройств других производителей (). Недавно был принят стандарт IPFIX, который позволяет передавать статистику и по протоколам более глубоких уровней (например, по типу приложения).
Реализация netflow-источников (агентов, probe) доступна для ПК-маршрутизаторов, как в виде работающих по описанных выше механизмам утилит (flowprobe, ), так и непосредственно встроенных в ядро ОС (FreeBSD: , Linux: ). Для программных маршрутизаторов поток статистики netflow можно принимать и обрабатывать локально на самом маршрутизаторе, или отправлять по сети (протокол передачи - поверх UDP) на принимающее устройство (коллектор).


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

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

Libpcap в“снаружи”

• Ethernet - хаб (hub): устройство, просто пересылающее пакеты между всеми своими портами без разбора. В современных реалиях его можно найти где-нибудь на пыльном складе, и применять такой метод не рекомендуется: ненадежно, низкая скорость (хабов на скорости 1 Гбит/с не бывает)


• Ethernet - коммутатор с возможностью зеркалирования (мирроринга, . Современные интеллектуальные (и дорогие) коммутаторы позволяют копировать на указанный порт весь трафик (входящий, выходящий, оба) другого физического интерфейса, VLANа, в том числе удаленного (RSPAN)


• Аппаратный , который может потребовать установки для сбора двух сетевых карт вместо одной - и это помимо основной, системной.

Естественно, вы можете настроить SPAN-порт и на самом устройстве доступа (маршрутизаторе), если оно это позволяет - Cisco Catalyst 6500, Cisco ASA. Вот пример такой конфигурации для коммутатора Cisco:
monitor session 1 source vlan 100 ! откуда берем пакеты
monitor session 1 destination interface Gi6/3! куда выдаем пакеты

SNMP

• блокировка трафика может производиться только путем полного отключения интерфейса, при помощи того же SNMP


• счетчики трафика, снимаемые по SNMP, относятся к сумме длин Ethernet-пакетов (причем unicast, broadcast и multicast по-отдельности), в то время как остальные описанные ранее средства дают величины относительно IP-пакетов. Это создает заметное расхождение (особенно на коротких пакетах) из-за оверхеда, вызванного длиной Ethernet-заголовка (впрочем, с этим можно приближенно бороться: L3_байт = L2_байт - L2_пакетов*38).

VPN

Заключение

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

• как и куда попадают собранные данные о трафике


• программное обеспечение для учета трафика


• чем отличается биллинг от простой в“считалки”


• как можно накладывать ограничение на трафик


• учёт и ограничение посещенных веб-сайтов

Передача IP трафика по сетям SDH, или Есть ли у ATM альтернатива?

Немало спорят о том, какие транспортные технологии выйдут на первый план в высокоскоростных мультимедийных сетях, например Internet. И хотя большинство спорящих отдают свои голоса в пользу ATM, с этой точкой зрения согласны далеко не все. Возможен и другой, альтернативный, вариант построения транспортных мультимедийных сетей - использование протокола IP (Internet Protocol) с прямой инкапсуляцией в сети синхронной цифровой иерархии (SDH).

IP используется вот уже более 15 лет, в то время как ATM - относительно новый протокол. За время существования IP Internet из объединенной научной сети разрозненных университетских городков превратилась в огромную компьютерную сеть, покрывшую всю планету. Постоянно увеличивающееся число пользователей Internet (сейчас их счет идет на миллионы) и растущие требования к пропускной способности грозят привести к тому, что Сеть перестанет справляться с нагрузкой. Новые мультимедийные приложения выдвигают гораздо более жесткие требования к предоставляемой полосе пропускания, причем часто в режиме реального времени. Это заставляет пересматривать сложившиеся подходы к построению инфраструктуры Internet.

Для увеличения пропускной способности Internet прежде всего необходим высокоскоростной "транспорт". Один из вариантов - использование популярной технологии ATM. Следует отметить, что в качестве транспортного протокола ATM вызывает все больше нареканий как у производителей оборудования, так и у конечных пользователей. Мы постараемся проанализировать недостатки ATM более подробно и рассмотреть аргументы в пользу другого способа передачи трафика Internet - прямой инкапсуляции протоколов TCP/IP в протоколы SONET/SDH.

Технология ATM

Асинхронный режим передачи, ATM, был представлен на суд производителей и провайдеров сетевых услуг как технология, позволяющая обеспечить необходимую полосу пропускания по требованию и гарантированное качество обслуживания широкому спектру мультимедийных приложений, среди которых на первом месте находился Internet. Таким образом, не самая последняя часть компонентов ATM была ориентирована и разрабатывалась специально для передачи трафика Internet. Предполагалось, что в ближайшем будущем Сеть будет в значительной степени состоять из пользователей ATM и клиентов LANE (LAN Emulation), что обеспечит легкую и естественную миграцию Internet-приложений в новый транспортный протокол, обещающий безграничные возможности.

Однако (возможно, из-за дороговизны новых решений или их неорганичности) этого почему-то не произошло. Более того, все отчетливее стала проявляться тенденция к усилению влияния протоколов TCP/IP именно как транспортных протоколов.

Действительно, стек протоколов TCP/IP давно отработан и испытан, в его создание и отладку вложено немало средств и сил. Если у протокола IPv4 и есть определенные недостатки, то готовящаяся к выходу версия IPv6 позволит устранить большинство из них. Впрочем, существующая версия IPv4 тоже устраивает очень многих и, по мнению экспертов, в состоянии продержаться еще несколько лет. Изрядное число производителей рассматривает именно IP как перспективный транспортный протокол для современной телекоммуникационной инфраструктуры. Так при чем же здесь ATM?

ATM была предложена ITU-T как базовая технология для широкополосного ISDN (или B-ISDN). Поскольку B-ISDN предназначен в основном для передачи мультимедийного трафика, ATM имела все возможности для поддержки такого рода трафика в реальных сетях.

Прошло некоторое время, и производители телекоммуникационного оборудования обратили на ATM свое внимание. Был создан ATM Forum, который занялся воплощением новой технологии в жизнь. При этом задачи, возлагаемые на ATM Forum, состояли в стандартизации и разработке эффективного наращиваемого протокола, поддерживающего трафик с диаметрально противоположными характеристиками (мультимедиа), гарантирующего определенное качество обслуживания (QoS) и поддерживающего многоадресное вещание. Кроме того, данный протокол должен быть совместимым с существующими технологиями LAN и WAN.

Следует понять, что технология ATM приобрела столь широкую популярность именно из-за всеобщей уверенности в том, что существовавшие на тот момент технологии были не в состоянии удовлетворить приведенным выше требованиям.

Технология IP

IP, с другой стороны, совсем не выглядит устаревающим протоколом, о котором следует забыть. По всему миру установлено огромное число решений типа "IP over Ethernet", и совсем непросто уговорить клиентов выбросить дешевые "карточки" Ethernet и установить адаптеры ATM, не обещая при этом принципиально новых возможностей или хотя бы более высоких скоростей (увеличение скорости отнюдь не является очевидным).

Думаю, многие клиенты, имеющие опыт использования адаптеров ATM для персональных компьютеров, согласятся со мной, что сетевая карта Fast Ethernet 100 Мбит/с (не говоря уже про Full Duplex) работает по крайней мере не медленнее, чем адаптер ATM на 155 Мбит/с. Это связано с большей избыточностью протокола ATM и задержками на сборку/разборку ячеек. Что же касается гарантированного качества обслуживания ATM, оно практически не реализовано в LANE, да и для передачи IP-трафика через ATM сейчас используется AAL5 UBR (максимум UBR+ или ABR). Так что говорить о QoS не приходится.

Несомненно, новая технология должна поддерживать широкий диапазон уровней качества обслуживания. Однако IP был выбран в качестве протокола для всеобщего межсетевого взаимодействия и прекрасно работал в Internet, насчитывавшем тогда 20 тыс. компьютеров, уже в середине 1980 г. и продолжает успешно соединять несколько миллионов хостов сегодня. Действительно ли IP изжил себя? Сторонники ATM, вероятно, ответят "да".

Огромные средства были вложены в разработку семейства Internet-протоколов и доведение их до нынешнего состояния. Действует не только ATM Forum, но и IETF (Internet Engineering Task Force) - продолжается поиск путей для применения IP в появляющихся высокоскоростных мультимедийных сетях. Созданы протоколы поддержки многоадресного вещания (IGMP, DVMRP, PIM) и протоколы, обеспечивающие резервирование ресурсов для передачи трафика (RSVP). Имеется возможность осуществлять маршрутизацию (правда, пока еще не так гибко, как при использовании PNNI) на основе требуемого качества обслуживания (Tag Switching), а готовящийся к выходу в IETF стандарт MPLS (Multiprotocol Label Switching) обеспечит интероперабельность всех устройств, поддерживающих коммутацию меток, и, вероятно, ощутимо потеснит позиции MPOA (Multiprotocol Over ATM).

Так имеет ли смысл заменять хорошо проработанную технологию IP на только появляющуюся ATM ?

IP через ATM

Первоначально идея передачи IP через ATM рассматривалась как возможный путь внедрения ATM в существующую архитектуру Internet с последующим полным вытеснением IP. Теперь, понимая, что ATM не в состоянии полностью заменить IP, мы можем задать вопрос: почему же до сих пор не созданы эффективные методы передачи трафика IP через ATM? Видимо, считается, что ATM предлагает уникальную технологию быстрой коммутации, способную решить существующие проблемы нехватки пропускной способности в Internet. Однако на деле здесь проявляются некоторые проблемы.

Прежде всего обратим внимание на то, что практически все (за редким исключением, например ATM25, TAXI и т.п.) физические интерфейсы ATM-коммутаторов работают в формате кадров SDH/SONET/PDH. Это сделано для облегчения интеграции с широко распространенными транспортными сетями SDH. Но даже когда SDH напрочь отсутствует и не предусмотрен проектом, все равно в передачу пользовательского трафика вносится SDH overhead, что, мягко говоря, не увеличивает скорость и производительность сети.

Уместно также будет отметить, что SDH - синхронный метод передачи, а ATM - асинхронный. При передаче ATM-трафика через транспортные сети SDH мы теряем все преимущества асинхронного метода переноса ячеек, не говоря уже о дублировании ряда функций (например, OA&M).

Улучшению ситуации отнюдь не способствует инкапсуляция IP в ATM, в свою очередь работающий через SDH. Протокол ATM является ориентированным на соединение, в то время как IP таковым не является. Это несоответствие также ведет к дополнительному усложнению и дублированию ряда функций.

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

На недостатках методов эмуляции локальных сетей даже нет нужды останавливаться, поскольку любой квалифицированный сетевой специалист согласится, что технологию LANE никак нельзя назвать органичной и перспективной. Со многих точек зрения эта технология - неудачная попытка "притянуть" протоколы, разработанные для сред с широковещательной рассылкой, к работе в среде, где подобный режим передачи данных невозможен (NBMA, Nonbroadcast Multiple Access).

Таким образом, если Internet все-таки остается самим собой и продолжает базироваться на IP, нужна ли дополнительная "прослойка" в виде ATM между IP и действительно эффективным, действительно высокоскоростным транспортным проколом SDH, который одинаково хорошо служит для передачи трафика практически любого вида?

IP через SDH

Технология SDH широко используется для организации надежного транспорта. SDH была разработана для того, чтобы получить стандартный протокол для взаимодействия провайдеров; унифицировать американские, европейские и японские цифровые системы; обеспечить мультиплексирование цифровых сигналов на гигабитных скоростях; обеспечить поддержку функций эксплуатации и технического обслуживания OA&M (operation, administration and maintenance).

Хотя SDH и работает с кадрами и имеет свою канальную структуру, с точки зрения сетевого уровня SDH - всего лишь поток октетов. Для того чтобы корректно вложить пакет IP в SDH-контейнер, необходимо четко определить границы пакета (или группы пакетов) в рамках синхронного транспортного модуля STM (synchronous transport module). Иными словами, между IP и SDH нужна некоторая протокольная "прослойка" для формирования кадров канального уровня.

Поскольку SDH предоставляет соединения типа точка-точка, применение в качестве промежуточного протокола PPP (Point-to-Point Protocol) представляется вполне логичным. PPP широко используется в Internet в качестве протокола канального уровня для организации соединений через глобальные сети. Кроме того, PPP позволяет задействовать дополнительные функции PPP-протокола:

• возможность многопротокольной инкапсуляции;
• защиту от ошибок;
• использование протокола LCP для установления, конфигурирования и тестирования соединений канального уровня;
• возможность применения семейства протоколов NCP для поддержки и конфигурирования различных сетевых протоколов.

Впрочем, надо отметить, что в качестве сетевого протокола для нас сейчас представляет интерес только IP, а кроме того, ряд функций протокола NCP (например, динамическое присвоение IP-адресов) в нашем случае не актуален. Что нас действительно интересует, так это инкапсуляция IP в PPP с последующим размещением PPP-кадров в SDH.

Инкапсуляция IP в PPP не представляет проблемы, поскольку хорошо отработана и повсеместно используется. Процедура инкапсуляции PPP в SDH (определено значение Path Signal Label = 207hex), показанная на рисунке, должна осуществляться специальным сервис-адаптером на уровне тракта SDH. Сервис-адаптер может представлять собой "черный ящик", принимающий поток PPP-кадров и "выдающий" поток транспортных модулей STM. PPP весьма удачно подходит для работы с SDH, так как оба протокола ориентированы на работу в однобайтном режиме.

Таким образом, используя непосредственную инкапсуляцию трафика Internet в существующую транспортную службу SDH, мы существенно упрощаем сложную сетевую инфраструктуру, а тем самым уменьшаем ее стоимость и увеличиваем эффективную пропускную способность. С появлением новых возможностей передачи IP-трафика на гигабитных скоростях (Gigabit Ethernet) и технологий быстрой коммутации IP-пакетов (Multiprotocol Label Switching - MPLS) становится реальным использование именно IP-протокола как основы единой транспортной службы для передачи видео, телефонии и других мультимедийных приложений - благо основная часть работ по внедрению протокола IP во Всемирную сеть уже выполнена. В связи с этим очень своевременным кажется появление стандартов (RFC 1619) и первых практических реализаций интерфейсов типа "PPP over SDH" (или Packets Over Sonet - POS) на предназначенных для Internet современных маршрутизаторах, в частности GSR 12000 от Cisco Systems.

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

ОБ АВТОРЕ

Аннотация: Обсуждается тема, связанная с качеством обслуживания в IP-сетях. Указываются определения, описаны методики определения качества в IP-сетях. Обсуждаются протоколы, с помощью которых реализуется уровень качественного обслуживания. Приведено сравнение различных технологий обеспечения качества IP-услуг. Вводится понятие очередей и "алгоритмов борьбы" с ними

7.1. Понятие QoS

Сети с коммутацией пакетов на основе протокола IP не обеспечивают гарантированной пропускной способности, поскольку не гарантируют доставку.

Для приложений, где не важен порядок и интервал прихода пакетов, время задержек между отдельными пакетами не имеет решающего значения. IP-телефония является одной из областей передачи данных, где важен порядок прихода пакетов и важна динамика передачи сигнала, которая обеспечивается современными методами кодирования и передачи информации. Транспортные протоколы стека TCP / IP , функционирующие поверх протокола IP , не обеспечивают высокого качества обслуживания трафика, чувствительного к задержкам. Протокол TCP , хоть и гарантирует достоверную доставку информации, но переносит ее с непредсказуемыми задержками. Протокол UDP , который, как правило, используется для переноса информации в реальном времени, обеспечивает меньшее, по сравнению с протоколом TCP , время задержки , но, как и протокол IP , не содержит никаких механизмов обеспечения качества обслуживания.

Вместе с тем необходимо обеспечить механизмы , по которым в периоды перегрузки пакеты с информацией, чувствительной к задержкам (например, речь), не будут простаивать в очередях или получат более высокий приоритет, чем пакеты с информацией, не чувствительной к задержкам. Для этой цели в сети должны быть реализованы механизмы , гарантирующие нужное качество обслуживания ( Quality of Service - QoS ).

Объективными, измеряемыми или рассматриваемыми показателями качества являются:

• изменение задержки в сети;
• пропускная способность сети.

Время отклика оценивается по:

• промежутку времени от момента передачи пакета до момента приема подтверждения;
• времени задержки однонаправленного сквозного соединения, также называемой временем запаздывания ( latency );
• пропускной способности.

Готовность и надежность оценивается по:

• возможности получения доступа к ресурсам сети или коэффициенту использования;
• результатам контроля уровня обслуживания 24/7 (при режиме работы 24 часа в сутки, 7 дней в неделю).

Меры обеспечения QoS , применяемые в IP - сетях:

1. Резервирование ресурсов (на время соединения запрашиваются и резервируются необходимые для выполнения приложения ресурсы).
2. Приоритезация трафика (разделение трафика в сети на классы с приоритетным порядком обслуживания некоторых из них).
3. Перемаршрутизация (позволяет при перегрузке в сети перевести трафик на резервный маршрут; именно этим способом обеспечивается QoS в подавляющем большинстве контроллеров SBC ).

В современных IP -сетях перечисленные меры реализуются с помощью технологий IntServ , DiffServ и MPLS с использованием протокола RSVP .

7.2. Трафик реального времени в IP-сетях

Как правило, большую часть VoIP -трафика составляют потоки информации, чувствительной к задержкам. Максимальная задержка не должна превышать 250 мс, причем сюда входит и время обработки информации на конечной станции. Вариацию задержки (джиттер) также необходимо свести к минимуму. Кроме того, необходимо учитывать, что при сжатии информация становится более чувствительной к ошибкам, возникающим при передаче, и их нельзя исправлять путем переспроса именно из-за необходимости передачи в реальном времени.

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

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

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

7.3. Дифференцированное обслуживание разнотипного трафика - Diff-Serv

Опция DiffServ позволяет классифицировать пакеты из трафика, идущего в локальную сеть . Работа DiffServ основывается на идентификаторе DSCP , представляющем собой первые 6 бит поля TOS . DSCP определяет, как будут перенаправляться пакеты в DiffServ -сети (PHB, Per- hop Behavior). Изменяя значение этого идентификатора, различные виды трафика можно распределить по приоритетам в очереди.

Модель Diff-Serv описывает архитектуру сети как совокупность пограничных участков и ядра. Пример сети согласно модели Diff-Serv приведен на рисунке 7.1 .

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

Достоинства модели Diff-Serv:

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

К настоящему времени для Diff-Serv определено два класса трафика:

• класс срочной пересылки пакетов (Expedited Forwarding PHB Group);
• класс гарантированной пересылки пакетов ( Assured Forwarding PHB Group).

Механизм обеспечения QoS на уровне сетевого устройства, применяемый в Diff-Serv, включает в себя следующие операции . Сначала пакеты классифицируются на основании их заголовков. Затем они маркируются в соответствии с произведенной классификацией (в поле приоритета Diff-Serv в зависимости от маркировки выбирается алгоритм передачи, при необходимости - с выборочным удалением пакетов), позволяющий избежать заторов в сети. Заключительная операция чаще всего состоит в организации очередей с учетом приоритетов.

7.4. Интегрированное обслуживание IntServ

IntServ (Integrated Services) больше подходит для концентрации трафика в пограничной сети IP и не рекомендована для применения в транзитных сетях IP (из-за проблем с масштабируемостью).

Модель с интеграцией услуг была предложена в начале 90-х годов и разрабатывалась для обслуживания единичных потоков, которым предоставляется два вида услуг: гарантированные и с управляемой нагрузкой. Гарантированные услуги позволяют обеспечить определенному объему трафика поддающееся количественному вычислению максимальное значение задержки при прохождении пакетов из конца в конец. Услуги с управляемым уровнем нагрузки предоставляют определенному объему трафика обслуживание best- effort при виртуальной низкой сетевой нагрузке без строгих гарантий.

Рассмотрим структурную схему IntServ ( рис. 7.2).

Рис. 7.2.

В каждом узле, поддерживающем IntServ , должно быть несколько обязательных элементов:

• классификатор - направляет поступающий пакет в один из классов обслуживания согласно информации, полученной из заголовков (сетевого и транспортного уровней) пакета. Класс обслуживания реализуется в виде отдельной очереди. Все пакеты в пределах одного класса обслуживания должны получать одинаковый QoS ;
• диспетчер пакетов - извлекает из каждой очереди пакеты и направляет их на канальный уровень . Для IntServ предложен двухступенчатый диспетчер пакетов. Все поступающие пакеты обрабатываются в соответствии с дисциплиной обслуживания WFQ для изоляции потоков, получающих гарантированные услуги, от всех остальных. Потоки с управляемой нагрузкой и потоки best- effort разделяются с помощью приоритетов;
• блок управления доступом ( admission control ) - принимает решения о возможности получения трафиком требуемого количества ресурсов, не влияя при этом на ранее предоставленные гарантии. Управление доступом выполняется на каждом узле для принятия или отклонения запроса на выделение ресурсов по всему пути прохождения потока;
• протокол резервирования ресурсов - информирует участников соединения (отправителя, получателя, промежуточные маршрутизаторы) о требуемых параметрах обслуживания. Для модели IntServ рекомендуется использовать протокол RSVP .

Сервисная модель IntServ в сочетании с RSVP (см. далее) позволяет организовать гибкое обслуживание разнотипного трафика, максимально учитывая потребности каждого приложения, а использование WFQ для обслуживания пакетов гарантирует максимально допустимое значение задержки. Эта особенность делает IntServ идеальной для обслуживания мультимедийного трафика .

Однако высокая гибкость и "желание" удовлетворить потребности единичных потоков являются источником слабых мест IntServ . Основным недостатком модели считается низкая масштабируемость . Производительность IntServ зависит от количества обрабатываемых потоков, следовательно, такую сервисную модель практически невозможно реализовать в сети с миллионами пользователей! Поэтому для больших сетей нужна более простая и масштабируемая технология, а область применения IntServ ограничилась внутренними и оконечными сетями.

Но самый большой недостаток IntServ связан с масштабируемостью RSVP , особенно в высокоскоростных магистральных сетях. Действительно, объем ресурсов, которые необходимы маршрутизатору для обработки и хранения информации RSVP , увеличивается пропорционально количеству потоков QoS . Измерения трафика показывают, что большинство соединений IP "из конца в конец" существует очень недолго, и в каждый момент времени магистральным маршрутизатором поддерживается несколько тысяч активных соединений. Следовательно, многочисленные потоки IntServ в канале с большой пропускной способностью значительно увеличивают нагрузку на маршрутизаторы. Более того, каждый раз при изменении топологии все зарезервированные пути необходимо прокладывать заново.

7.5. Интегро-дифференцированное обслуживание трафика

Опубликованный в 2000 г. стандарт RFC2998 описывает принципы организации взаимодействия IntServ / RSVP и DiffServ для предоставления QoS из конца в конец. Слабые места одной модели компенсируются соответствующими решениями другой. С одной стороны, плохо масштабируемая IntServ на магистральных участках сети может быть заменена на более простую DiffServ , с другой стороны, с помощью RSVP может решаться (если не полностью, то в большей степени) проблема с неопределенностью получаемого сервиса в "чистой" DiffServ -сети.

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

Возможна организация двух вариантов взаимодействия протоколов качества обслуживания:

• DiffServ -регион не поддерживает RSVP -сигнализацию, и ресурсы выделяются на статической основе;
• обработка RSVP -сообщений производится в DiffServ -регионе.

В первом случае совместная работа основана на статическом соглашении клиента с оператором SLS (спецификация уровня сервиса). В простейшей ситуации оно описывает значение пропускной способности, получаемое трафиком пользователя, в DiffServ -сети. В этом случае ( рис. 7.3) Tx (отправитель) генерирует сообщения Path , которые направляются к узлу Rx (получатель) через DiffServ -регион.

При прохождении через DiffServ -регион содержимое RSVP -сообщений игнорируется, и они пересылаются как обычный пакет с данными. При получении узлом Rx сообщения Path генерируется запрос на резервирование RESV , который затем направляется обратно к узлу Tx . В случае успешной обработки запроса каждым RSVP -совместимым маршрутизатором и прохождения через DiffServ -регион сообщение RESV достигает маршрутизатора Er1 . Er1 на основании SLS производит сравнение ресурсов, запрашиваемых в сообщении RESV , и ресурсов, доступных в DiffServ -регионе. Если Er1 подтверждает запрос , сообщение RESV отсылается далее по направлению к узлу Tx . В ином случае сообщение отвергается, и узлу Rx отправляется сообщение об ошибке . В полученном узлом Tx сообщении может содержаться информация о маркировании соответствующим кодом пакетов, адресуемых в узел Rx . Значение кода определяется по умолчанию или из сообщения RESV .

Во втором варианте предполагается, что пограничные маршрутизаторы в DiffServ -регионе (например, маршрутизатор Br1 ) поддерживают протокол RSVP . Отметим, что, несмотря на поддержку RSVP -сигнализации, обрабатываются только агрегированные потоки , а не единичные, как в сети IntServ / RSVP . Порядок обмена RSVP -сообщениями такой же, как и в предыдущем случае. Однако благодаря поддержке