Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы управления техническим состоянием цифровых систем коммутации для повышения надежности их работы
.pdf
Северо-западный офис.
Великий Новгород.
Западный офис.
Смоленск
Восточный офис.
Владимир.
Северный офис.
Санкт-
Петербург.
Потоки НУ
ГТС
Городская
телефонная станция,
находящаяся на
территории города.
Центральный
офис.
Москва.
Потоки ВУ
УАТС
ГТС
УАТС
ГТС
УАТС
ГТС
УАТС
ГТС
УАТС
ГТС
Обозначения:
13. Использование информационных технологий для построения сетей
Если выполняется проект для крупной корпорации, в которой наиболее
актуальным является требование защищенности передаваемой информации и
высокой надежности, должны использоваться специальные решения по
организации связи между филиалами (например, необходимо использование
виртуальных частных сетей VPN).
Общая схема проектируемой сети связи представлена на рисунке 13.1.
Удаленный офис может иметь смешанную структуру, где присутствуют как
аналоговые, так и IP-телефоны, а интеграция серверов беспроводного DECT
Рисунок 12.4 - Структурная схема корпоративной сети связи
Компании N
связи крупных корпораций
доступа возможна в любом из удаленных офисов.
45
VOICE GW 1
VOICE GW 2
KIRK Wireless Server CUCM Subscriber
CCX IVR
Базовые станции KIRK
IP Телефоны
DECT Телефоны
Voice VLAN
ЛВС
MGCP
MGCP
SIP
SCCP
Аналоговые шлюзы
Аналоговые телефоны
MGCP
ТфОП
E1
E1
WAN
DMVPN
CUCM Publisher
Центральный офис
VOICE GW
SRST
ЛВС
VOICE GW
SRST
ЛВС
E1
E1
IP Телефоны
Voice VLAN
PBX
E1
Voice VLAN
Аналоговые телефоны
АЛ
Удаленный офис с
IP телефонами
Удаленный офис с
аналоговыми телефонами
Рисунок 13.1 - Схема проектируемой корпоративной сети
46
Основой для предоставления инфокоммуникационных услуг является
технология построения динамической многоточечной виртуальной частной
сети (Dynamic Multipoint Virtual Private Network, DMVPN). Эта технология
разработана компанией Cisco для построения масштабируемых защищенных
VPN сетей. Cisco DMVPN имеет централизованную архитектуру, однако
позволяет филиалам напрямую обмениваться друг с другом данными,
например при использовании VoIP соединений между площадками, но не
требует организации постоянного туннеля между ними. Таким образом,
архитектура решения на рис.13.2 подразумевает создание топологии типа
«звезда» (hub and spoke) c возможностью организации прямых соединений
между удаленными офисами при необходимости (spoke to spoke).
Рисунок 13.2 - Архитектура модели DMVPN
47
Основными элементами модели 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).
48
Рисунок 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 облаками, что необходимо
49
для построения отказоустойчивых сетевых структур. Структура
расширенного заголовка протокола 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 заголовка
Структура, которую образует DMVPN с возможностью организации
spoke-to-spoke туннелей, является сетью с множественным доступом, не
поддерживающей множественную рассылку (NBMA – Non-Broadcast Multiple
50
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.
51
Рисунок 13.5 - Процесс построения spoke-to-spoke туннеля
52
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-hubspoke, а после – напрямую. При этом если туннель был создан до начала RTP
сессии – такая проблема не возникает. Процесс создание туннеля занимает
менее 1 секунды, а вызванная данным процессом вариация задержки может
быть компенсирована анти-джитерным буфером, если разница в задержке не
53
превышаем 50-100 мс. В случае, если на сети имеет место сценарий, когда
разница в задержке слишком велика (например, если два участвующих spoke
расположены географически близко друг к другу и при этом далеко от
центрального маршрутизатора), то необходимо принимать меры для того,
чтобы организованный spoke-to-spoke туннель не удалялся, например, с
помощью механизмов IP SLA.
Отдельно стоит отметить особенности работы QOS в архитектуре
DMVPN. Поскольку spoke-to-spoke являются динамическими, то никакие
политики QOS для них не применимы. Такие политики должны применяться
непосредственно на физическом интерфейсе. При этом, полоса пропускания
каналов должна быть выделена на основе требований конкретных
приложений и ограничена соответствующими значения в политике QOS. Так
же должна быть рассчитано количество голосовых соединений между всеми
элементами системы, а данное количество должно быть ограничено
механизмом Location-based Call Admission Control (CAC). Механизм CAC
может запретить или направить по другому маршруту инициированный
вызов через WAN если, если вся полоса пропускания на источнике или
получателе уже была выделена другим вызовам, при этом существующие
вызовы будут обслуживаться без ухудшения качества связи. В случае, если
данный механизм использоваться не будет, то, при поступлении вызова,
полоса пропускания которого превысит выделенную, произойдет перегрузка
и, что приведет к потерям и, как следствие, к ухудшению качества связи на
всех, уже инициированных вызовах.
54
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]