Использование информационных технологий для построения сетей связи крупных корпораций

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

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

Рисунок 13.1 - Схема проектируемой корпоративной сети
Основой для предоставления инфокоммуникационных услуг является технология построения динамической многоточечной виртуальной частной сети (Dynamic Multipoint Virtual Private Network, DMVPN). Эта технология разработана компанией Cisco для построения масштабируемых защищенных VPN сетей. Cisco DMVPN имеет централизованную архитектуру, однако позволяет филиалам напрямую обмениваться друг с другом данными, например при использовании VoIP соединений между площадками, но не требует организации постоянного туннеля между ними. Таким образом, архитектура решения на рис.13.2 подразумевает создание топологии типа «звезда» (hub and spoke) c возможностью организации прямых соединений между удаленными офисами при необходимости (spoke to spoke).

Рисунок 13.2 - Архитектура модели DMVPN

Основными элементами модели DMVPN являются следующие технологии:Multipoint Generic Routing Encapsulation (mGRE) с протоколом NHRP (Next Hop Resolution Protocol); Psec; протокол динамической маршрутизации.

Общий алгоритм работы DMVPN облака имеет следующий вид.

1. Каждый spoke строит постоянный GRE/IPsec туннель до hub-маршрутизатора, но не до других spoke-маршрутизаторов. Они регистрируются как клиенты на NHRP сервере (который является Hub-ом).

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

3. После этого spoke-маршрутизатор может установить динамический GRE/IPsec туннель с маршрутизатором назначения, поскольку знает его адрес.

4. Динамический spoke-to-spoke туннель строится на основе mGRE интерфейса.

5. Когда передача трафика между этими сетями прекращается, туннель удаляется.

Рассмотрим основные элементы данной технологии.

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

Протокол общей инкапсуляции маршрутов (Generic Routing Encapsulation – GRE) – это протокол, который может быть использован для передачи других протоколов-пассажиров, в том числе широковещательных и многоадресных сообщений (см. рис. 13.3).

Рисунок 13.3. – Использование GRE в качестве протокола инкапсуляции

Использование GRE туннелей в сочетании с IPSec обеспечивает возможность использовать динамические протоколы маршрутизации и многоадресную рассылку между центральным и удаленными офисами. При использовании GRE туннелей типа «точка-точка» (p2p) весь трафик между площадками инкапсулируется в стандартный GRE пакет и затем подвергается шифрованию с помощью IPsec. При таком построении сети на центральном маршрутизаторе необходимо описывать уникальные туннельные интерфейсы для каждого удаленного офиса, что ведет к большой трудоемкости внедрения и эксплуатации.

В архитектуре DMVPN используется mGRE интерфейс, который представляет собой интерфейс типа «один ко многим» (one to many) для создания множества «hub and spoke» туннелей. При этом IP адрес назначения туннеля не описывается, а определяется динамически с использованием протокола NHRP. Таким образом, на центральном маршрутизаторе требуется описание одного туннельного интерфейса в рамках DMVPN облака для всех удаленных маршрутизаторов.

Заголовок протокола mGRE на 4 байта длиннее, чем обычный GRE заголовок. Дополнительные 4 байта представляют собой значение туннельного ключа, который используется для того, чтобы отличать различные mGRE интерфейсы в пределах одного маршрутизатора. Туннельные ключи позволяют маршрутизаторам иметь несколько mGRE интерфейсов для связи с несколькими DMVPN облаками, что необходимо для построения отказоустойчивых сетевых структур. Структура расширенного заголовка протокола GRE (RFC 2890) представлена на рисунке 13.4 и имеет следующие поля:

- флаг С (Cheksum Present) равен 1, если в заголовке присутствует поле контрольной суммы;

- флаг K (Key Present) равен 1, если в заголовке присутствует поле туннельного ключа;

- флаг S (Sequence Number Present) равен 1, если в заголовке присутствует поле порядкового номера;

- поле Ver (Номер версии) всегда равно 0;

- поле Protocol Type (Тип протокола) содержит описание протокола-пассажира, для IPv4 значение поля равно 47;

- поле Cheksum (Контрольная сумма) содержит контрольную сумму всех элементов GRE заголовка вместе с полезной информацией пакета;

- поле Key (Ключ) содержит туннельный ключ, описанный выше;

- поле Sequence Number (Порядковый номер) используется получателем для определения порядка, в котором пакеты передавались от отправителя.

Рисунок 13.4 - Формат расширенного GRE заголовка

1.

2.

3.

3.1.

Структура, которую образует DMVPN с возможностью организации spoke-to-spoke туннелей, является сетью с множественным доступом, не поддерживающей множественную рассылку (NBMA – Non-Broadcast Multiple Access Network). Множественный доступ определяется использование mGRE туннелей, когда в рамках одного DMVPN облака все маршрутизаторы находятся в пределах одной IP сети. Но в силу того, что объединение данного сегмента происходит через виртуальный туннельный интерфейса, а инкапсулированный трафик проходит через публичную WAN сеть, прохождение широковещательных пакетов обеспечить не возможно. При этом внутри GRE пакета многоадресные сообщения успешно передаются между сегментами сети. Примером NBMA сетей являются сети Frame-Relay.

В NBMA сетях не работает протокол ARP (Address Resolution Protocol), так как его работа основана на широковещательных пакетах. Его функцию, связанную с преобразованием адресов сетевого уровня в адреса канального уровня выполняет протокол NHRP. С помощью NHRP система, подсоединенная к NBMA сети, динамически получает NBMA-адрес другой системы, которая является частью этой сети, позволяя этим системам взаимодействовать друг с другом напрямую, минуя промежуточные узлы. В случае работы NHRP в сетях DMVPN происходит преобразованием внутреннего адреса туннельного интерфейса (VPN адрес) в публичный IP адрес (NBMA адрес).

В протоколе предусмотрены три основные функции: регистрация, разрешение и перенаправление. Функция регистрации позволяет NHRP-клиентам (удаленные маршрутизаторы) регистрироваться на NHRP-сервере (центральный маршрутизатор) для построения таблицы соответствия VPN и NBMA адресов. Функция разрешения (resolution) позволяет двум NHRP-клиентам в NBMA сети динамически получать NBMA-адрес друг друга. Функция перенаправления позволяет центральному маршрутизатору перенаправлять пакеты, предназначенные другому spoke-маршрутизатору, тем самым инициируя процесс создания прямого spoke-to-spoke туннеля. Процесс передачи трафика по DMVPN сети между spoke маршрутизаторами представлен на рисунке 13.5.

Рисунок 13.5 - Процесс построения spoke-to-spoke туннеля

Spoke-источник, получив IP пакет, направляет его маршрутизатору-получателю через Hub. Hub-маршрутизатор, получив данный пакет, направляет его через туннельный интерфейс получателю, а в сторону маршрутизатора-источника отправляет сообщение NHRP Redirect (1). Spoke-источник, получив это сообщение, формирует ответное сообщение NHRP Resolution Request в сторону маршрутизатора-получателя (2). Получив данное сообщением, маршрутизатор-получатель строит spoke-to-spoke туннель и отправляет по нему сообщение NHRP Resolution Reply (3). На рисунке так же показано формирования трех таблица, используемых для пересылки пакетов. Таблица NHRP mapping содержит записи NHRP кэша. Таблица CEF Adjacency строится на основе NHRP кэша и содержит информацию о NBMA адресе соседних маршрутизаторов. Таблица CEF Forwarding Information Base (FIB) использует для быстрой пересылки пакетов и строится на основе таблицы маршрутизации и таблицы CEF Adjacency.

Динамические NHRP записи имеют конечное время жизни, определяемое специальным таймером. После истечения этого таймера данные должны быть запрошены заново с помощью сообщений NHRP Resolution Request/Reply, в противном случае данная запись удаляется.

Описанный принцип пересылки пакетов в DMVPN может влиять на качество передаваемого VoIP трафика. При анализе задержек, присутствующих между офисами компании, необходимо учитывать время, вносимое процессом шифрования. Согласно [8] это время составляет в среднем 2 мс для однократного процесса шифрование/дешифровки. Другой фактор, влияющий на вариацию задержки – это различные маршруты прохождения пакетов при инициализации spole-to-spoke туннеля. Так, до момента создания данного туннеля трафик проходит маршрут spoke-hub-spoke, а после – напрямую. При этом если туннель был создан до начала RTP сессии – такая проблема не возникает. Процесс создание туннеля занимает менее 1 секунды, а вызванная данным процессом вариация задержки может быть компенсирована анти-джитерным буфером, если разница в задержке не превышаем 50-100 мс. В случае, если на сети имеет место сценарий, когда разница в задержке слишком велика (например, если два участвующих spoke расположены географически близко друг к другу и при этом далеко от центрального маршрутизатора), то необходимо принимать меры для того, чтобы организованный spoke-to-spoke туннель не удалялся, например, с помощью механизмов IP SLA.

Отдельно стоит отметить особенности работы QOS в архитектуре DMVPN. Поскольку spoke-to-spoke являются динамическими, то никакие политики QOS для них не применимы. Такие политики должны применяться непосредственно на физическом интерфейсе. При этом, полоса пропускания каналов должна быть выделена на основе требований конкретных приложений и ограничена соответствующими значения в политике QOS. Так же должна быть рассчитано количество голосовых соединений между всеми элементами системы, а данное количество должно быть ограничено механизмом Location-based Call Admission Control (CAC). Механизм CAC может запретить или направить по другому маршруту инициированный вызов через WAN если, если вся полоса пропускания на источнике или получателе уже была выделена другим вызовам, при этом существующие вызовы будут обслуживаться без ухудшения качества связи. В случае, если данный механизм использоваться не будет, то, при поступлении вызова полоса пропускания которого превысит выделенную, произойдет перегрузка и, что приведет к потерям и, как следствие, к ухудшению качества связи на всех, уже инициированных вызовах.