Способ маршрутизации IP-пакетов при использовании VPLS совместно с DHCP в сети с коммутацией пакетов
METHOD OF ROUTING IP-PACKETS WHEN USING VPLS IN CONJUNCTION WITH DHCP IN PACKET-SWITCHED NETWORK

Область техники, к которой относится изобретение
Предлагаемое изобретение относится к цифровым сетям передачи данных с коммутацией пакетов (IP) и, в частности, к способам маршрутизации IP-пакетов при использовании VPLS (Virtual Private LAN Service) совместно с DHCP (Dynamic Host Configuration Protocol).
Уровень техники
В современных цифровых сетях передачи данных, имеющих множество узлов, сложную распределенную топологию и отдельные участки (подсети или сегменты), которые содержат компьютеры конечных пользователей (клиентов) и которые могут быть территориально расположенными в разных географических регионах, большое значение имеет возможность использовать преимущества объединения в сеть с коммутацией пакетов на канальном уровне (с одним сегментом broadcast). В такой сети можно использовать простейшие сетевые устройства, работающие по протоколу BootP (принтеры, сканеры, IP-телефоны), устройства для конференцсвязи, использующие мультикаст-сообщения, и другие клиентские устройства с упрощенной настройкой (например, с получением адреса по протоколу DHCP и т.д.). Это позволяет облегчить настройку и в дальнейшем снизить затраты на обслуживание сети в целом.
Для такого объединения удаленных сегментов сети часто используется технология VPLS [1, 2].
Введем следующие термины:
клиентская сеть (КС, в английской терминологии Client Equipment (CE)) - это сегмент сети, содержащий клиентские компьютеры (КК) и другое клиентское оборудование, объединенный с другими КС по технологии VPLS;
пограничный маршрутизатор (ПМ, в английской терминологии Provider Edge (PE)) - это маршрутизатор, который служит для подключения КС к другим сегментам сети по технологии VPLS;
внешняя сеть - это участок сети, объединяющий ПМ.
Технология VPLS позволяет объединять несколько удаленных КС в одну локальную сеть с коммутацией пакетов на канальном уровне. Сетевые узлы в каждой КС при этом взаимодействуют с узлами в других КС, обмениваясь с ними кадрами канального уровня таким же образом, как если бы оба узла находились в одной и той же КС.
Для построения единой сети канального уровня на базе VPLS каждая КС подключается к своему ПМ. Несколько ПМ, каждый из которых подключен к одной из КС, соединяются между собой с помощью построения туннельных соединений между ними. Каждый ПМ должен быть связан туннелем с каждым из остальных ПМ, образующих данный сервис VPLS, для этого может использоваться один из известных туннельных протоколов канального или сетевого уровня (MPLS, GRE, EtherIP и др. [1, 2]).
При поступлении кадров из КС и от других ПМ данный ПМ производит их коммутацию, для чего ведет таблицу адресов канального уровня, связывая каждый адрес с логическим портом (в качестве порта может выступать один из сетевых интерфейсов ПМ, подключенный к одной из КС, либо один из удаленных ПМ). При получении кадра из какого-либо логического порта производится поиск адреса получателя кадра, и кадр пересылается в логический порт, связанный с данным адресом. Если адрес получателя отсутствует в таблице, либо кадр широковещательный, то создается несколько копий кадра, которые рассылаются следующим образом: если исходный кадр поступил из своей КС, копии рассылаются во все остальные КС, а также на все удаленные ПМ; если же исходный кадр поступил от удаленного ПМ, копии рассылаются только в своей КС.
Каждый ПМ может, помимо функций VPLS, выполнять и другие функции: на нем может происходить маршрутизация пакетов из своей КС во внешнюю сеть и обратно, а также могут работать сетевые сервисы, доступные для своей КС. Для этого ПМ имеет отдельный логический порт, соответствующий его собственной сетевой подсистеме, и в такой логический порт коммутируются кадры из своей КС, адресованные самому ПМ на канальном уровне.
В настоящее время большинство IP-сетей используют динамическую конфигурацию клиентских устройств с помощью протокола DHCP, что позволяет упростить администрирование сети и исключить конфликты IP-адресов за счет того, что адреса устройств назначаются автоматически из единой точки - DHCP сервера, который следит за их уникальностью. Кроме IP-адреса, на устройства передаются через DHCP также и другие настройки, в том числе шлюз по умолчанию, а также, при необходимости, сетевые маршруты.
При этом, поскольку DHCP сервер по умолчанию не имеет информации о работе VPLS и не может узнать, к какой именно КС принадлежит узел, запрашивающий настройки по DHCP, он будет назначать всем узлам-клиентам одинаковые сетевые настройки (кроме IP-адреса), в том числе всем клиентам будет назначен одинаковый шлюз по умолчанию.
Такая ситуация приводит к неэффективной маршрутизации трафика из КС во внешнюю сеть. Поскольку шлюз по умолчанию должен быть в той же подсети, что и все клиентские узлы объединенных КС, он должен располагаться в одной из КС. Тогда сетевые узлы из удаленных КС, обращаясь к внешней сети, должны будут сначала передать пакет в ту КС, где находится шлюз (посредством механизмов VPLS), а затем уже от этого шлюза пакет будет передан во внешнюю сеть. Это будет создавать задержки в передаче пакетов, а также повысит нагрузку на КС, где находится шлюз, и на связанный с нею ПМ. Очевидно, что более эффективной была бы маршрутизация пакетов из каждой КС во внешнюю сеть через ближайший ПМ, без предварительной передачи таких пакетов в другую КС посредством VPLS.
Если при настройке сети не пытаться учесть наличие VPLS и не интегрировать работу VPLS и DHCP между собой, то достичь такого эффекта можно путем настройки DHCP сервера таким образом, чтобы DHCP сервер выдавал каждому КК отдельный набор настроек, при этом в наборе настроек для каждого КК администратором указывается шлюз по умолчанию в зависимости от того, в какой КС находится КК. Указание настроек при этом должно осуществляться отдельно для каждого КК, и заниматься этим может только администратор сети вручную. При этом КК могут идентифицироваться только своими адресами канального уровня, то есть адреса канального уровня всех КК должны быть заданы на DHCP сервере. Если КК значительное количество, и их набор постоянно меняется, то такой способ приводит к дополнительной нагрузке на DHCP сервер и увеличивает трудозатраты администратора на управление настройками.
Известен способ интеграции VPLS и DHCP, который характерен тем, что каждый ПМ выступает как DHCP ретранслятор (relay agent), модифицируя DHCP запросы от КК к DHCP серверу, проходящие через него [3].
В известном способе используются следующие шаги:
на каждом ПМ задают IP-адрес DHCP сервера, на который нужно перенаправлять запросы от КК, а также идентификатор DHCP ретранслятора, уникальный для каждого ПМ;
на DHCP сервере задают различные наборы настроек для КК в зависимости от идентификатора DHCP ретранслятора, через который был получен запрос КК, а шлюз по умолчанию в этих наборах настраивают так, чтобы шлюз по умолчанию соответствовал адресу ПМ, который имеет соответствующий идентификатор DHCP ретранслятора;
при поступлении на ПМ из своей КС DHCP запроса от КК к DHCP серверу производят с запросом следующие действия:
добавляют в сообщение DHCP идентификатор DHCP ретранслятора, соответствующий данному ПМ (с помощью опции 82);
пересылают запрос DHCP серверу, адрес которого был ранее задан;
на DHCP сервере при получении запроса анализируют идентификатор DHCP ретранслятора, и, в зависимости от него, отправляют КК настройки из соответствующего набора;
таким образом, DHCP сервер при получении запроса от КК уже будет иметь информацию о том, в какой КС находится КК (из идентификатора DHCP ретранслятора), и сможет назначить КК в качестве шлюза по умолчанию адрес ПМ, ближайший к данной КС.
Известный способ принят за прототип.
К сожалению, известный способ имеет ряд недостатков.
Способ требует, чтобы для каждой КС (характеризующейся идентификатором ретранслятора ближайшего к ней ПМ) на DHCP сервере был вручную определен набор клиентских настроек, в том числе шлюз по умолчанию. Между тем, в настоящее время решения VPLS нередко используются для объединения большого количества мелких сетей (до 100 и более), каждая из которых содержит 2-3 клиентских устройства (например, компьютер и IP-телефон), и в этих условиях ручная настройка параметров для каждой КС существенно усложняется.
Способ описан только для случая, когда DHCP сервер находится в сети провайдера VPLS, а не в одной из КС, в последнем случае работоспособность данного способа неясна и, в общем случае, не обеспечивается. Между тем, в ряде случаев назначение IP-адресов DHCP сервером провайдера нежелательно или вовсе невозможно, так, администраторы КС могут желать, чтобы DHCP сервер управлялся ими, или же сеть VPLS может быть построена усилиями администраторов самих КС поверх внешней сети с использованием разных провайдеров и туннельных протоколов, работающих через внешнюю сеть (таких, как GRE, EtherIP и т.д.).
В ряде случаев запрос DHCP может прийти из КС, уже пройдя через внутренний ретранслятор, используемый внутри КС. В этом случае способ не будет работать, поскольку протокол DHCP не предусматривает использование каскада ретрансляторов (более одного для каждого запроса).
Способ требует, чтобы DHCP сервер мог назначать клиентам разные настройки в зависимости от идентификатора ретранслятора. Идентификатор ретранслятора изначально использовался в целях безопасности, чтобы DHCP сервер мог принимать запросы только от доверенных ретрансляторов, а не для создания различных наборов клиентских настроек в зависимости от него, поэтому последняя возможность поддерживается не всеми DHCP серверами. Это накладывает ограничения на использование конкретных реализаций DHCP серверов.
Раскрытие сущности изобретения
Техническим результатом является
1) упрощение настройки маршрутизации,
2) снижение нагрузки на сервис VPLS и в целом на сеть,
3) устранение ограничений на расположение и реализацию DHCP сервера.
Указанный результат достигается за счет применения следующего способа маршрутизации в сети с коммутацией пакетов, причем в состав сети входят
клиентские компьютеры, расположенные в КС;
пограничные маршрутизаторы, причем каждая КС подключена к своему ПМ через заданный интерфейс, образующий шлюз по умолчанию;
DHCP сервер, находящийся в одной из КС;
при этом каждый ПМ содержит средство обработки, выполненное с возможностью:
сравнения IP-адресов, содержащихся в кадрах запроса;
модификации кадра запроса путем добавления или удаления данных;
замены IP-адресов, содержащихся в кадрах запроса; способ заключается в том, что
передают запрос из КК на получение IP-адреса интерфейса и IP-адреса шлюза по умолчанию в ПМ своей КС, причем запрос содержит
набор кадров;
опции протокола DHCP;
передают запрос из пограничного маршрутизатора КС, содержащей КК, в ПМ, находящийся в КС DHCP сервера;
передают запрос из ПМ, находящегося в КС DHCP сервера, в DHCP сервер;
формируют ответ в DHCP сервере в виде совокупности кадров;
передают ответ DHCP сервера в ПМ, находящийся в КС DHCP сервера;
обрабатывают полученный ответ DHCP сервера в средстве обработки ПМ, выполняя следующие действия:
проверяют, содержат ли сведения, имеющиеся в кадрах, какой-либо маршрут, имеющий в качестве IP-адреса шлюза по умолчанию IP-адрес шлюза по умолчанию данного ПМ;
если был обнаружен факт совпадения, то модифицируют ответ путем добавления отметки в кадр;
передают ответ DHCP сервера из ПМ, находящегося в КС DHCP сервера, в ПМ клиентской сети, в которой находится КК, пославший запрос;
обрабатывают ответ DHCP сервера в средстве обработки ПМ клиентской сети, из которой поступил запрос, выполняя следующие действия:
проверяют, содержат ли сведения, имеющиеся в кадрах, отметку;
если отметка присутствует, то выполняют следующие действия:
в каждом случае, когда в сведениях, имеющихся в кадрах, указан маршрут, заменяют IP-адрес шлюза по умолчанию ПМ клиентской сети, в которой находится DHCP сервер, на IP-адрес шлюза по умолчанию ПМ клиентской сети, из которой поступил запрос;
удаляют из ответа DHCP сервера отметку;
передают ответ DHCP сервера из ПМ клиентской сети, из которой поступил запрос, в КК, пославший запрос;
принимают ответ DHCP сервера в КК, пославшем запрос.
В реальной сети, например корпоративной, компьютеры отдельных пользователей (клиентов) или КК, расположены в территориально удаленных сегментах сети (КС), имеют выход во внешнюю сеть, например, Интернет, через отдельный маршрутизатор (названный выше ПМ). Данные ПМ организуют сеть VPLS, а каждая КС подключается к своему ПМ. Несколько ПМ, каждый из которых подключен к одной из КС, соединяются между собой с помощью построения туннельных соединений между ними. Каждый ПМ должен быть связан туннелем с каждым из остальных ПМ, образующих данный сервис VPLS, для этого может использоваться один из известных туннельных протоколов канального или сетевого уровня (MPLS, GRE, EtherIP и др.)
Каждый ПМ, например, может представлять собой программно-аппаратный комплекс (ПАК) на базе какой-либо ОС (Linux).
Для реализации предложенного способа в состав комплекса включают средство обработки, реализованное в виде программного модуля.
В данном модуле обрабатываются все кадры (на втором уровне модели OSI), проходящие через ПМ. Для кадров, коммутируемых между локальной КС и удаленными ПМ (в любом направлении), проверяется, что в кадре содержится пакет UDP с сообщением протокола DHCP, направленным от сервера к клиенту, и это сообщение содержит хотя бы одну из опций, имеющих в себе информацию о маршрутах. Эти опции имеют номера 3, 33, 121, 249 [4, 5]. Кадры, содержащие такие опции, подвергаются дальнейшей обработке.
Если кадр получен из локальной КС и коммутируется на удаленный ПМ, то анализируют все имеющиеся в сообщении опции DHCP с номерами 3, 33, 121, 249 и проверяют, указан ли в какой-либо опции маршрут по умолчанию, такой, что IP-адрес шлюза этого маршрута совпадает с локальным IP-адресом ПМ на интерфейсе, подключенном к КС, из которой был принят кадр. Если была обнаружена хотя бы одна опция, удовлетворяющая этому условию, то в сообщение DHCP добавляют отметку в виде опции 43 (опция производителя оборудования) [4, 5] с заранее определенным значением, например, в виде сочетания символов "VPLS-DHCP".
Если кадр получен от удаленного ПМ и коммутируется в локальную КС, то анализируют, присутствует ли в сообщении DHCP опция 43 с заранее определенным нами значением, например, "VPLS-DHCP". Если присутствует, то анализируют все имеющиеся в сообщении опции DHCP с номерами 3, 33, 121, 249 и для каждой опции, в которой указан маршрут по умолчанию, заменяют адрес шлюза на локальный IP-адрес ПМ на интерфейсе, подключенном к КС, в которую коммутируется кадр. После этого удаляют из сообщения DHCP отметку из опции 43 (только ту, значение которой соответствует заранее определенной, в рассматриваемом случае - "VPLS-DHCP"), другие имеющиеся опции 43 не удаляют.
В итоге, если DHCP сервер находится в одной из КС, то DHCP клиенты из других КС могут получать IP-адреса и другие настройки от этого DHCP сервера. Это упрощает настройку маршрутизации и исключает возникновение конфликтов. Все КК в каждой КС маршрутизируют пакеты во внешнюю сеть через ПМ, ближайший к данной КС, за счет чего минимизируются задержки при обработке пакетов, и уменьшается нагрузка сервис VPLS и в целом на сеть. Замена шлюза по умолчанию происходит автоматически и не требует настроек ни на DHCP сервере, ни на DHCP клиенте, ни на промежуточных ПМ.
Таким образом, преимуществом предложенного способа, по сравнению с известным способом, состоит в том, что запрос DHCP клиента не модифицируется, дополнительные идентификаторы в него не добавляются, а модифицируется только ответ DHCP сервера и только на участке передачи его между двумя ПМ.
За счет этого:
отсутствует необходимость для DHCP сервера поддерживать передачу клиенту разных наборов настроек, т.е. отсутствует необходимость для администратора сети задавать разные наборы настроек для разных КС, если различие состоит только в адресе шлюза по умолчанию, так как замена адреса шлюза происходит автоматически;
DHCP сервер может находиться в одной из КС, т.е. поддерживается конфигурация, в которой сеть VPLS построена с использованием туннелирования через внешнюю сеть с подключением разных ПМ к разным провайдерам, также поддерживается конфигурация, в которой запрос DHCP из КС поступает на ПМ, как без использования DHCP ретранслятора, так и с использованием каскада DHCP ретрансляторов.
Осуществление изобретения
Рассмотрим осуществление предложенного способа в сети с коммутацией IP-пакетов. Это может быть корпоративная сеть, имеющая один основной сегмент - КС с установленным DHCP сервером и множеством сегментов сетей удаленных офисов - КС, подключенных через различных провайдеров сети Интернет по технологии VPLS, для создания сети с коммутацией пакетов на канальном уровне (с одним сегментом broadcast). В такой сети можно использовать простейшие сетевые устройства, работающие по протоколу BootP (принтеры, сканеры, IP-телефоны), устройства для конференцсвязи, использующие мультикаст-сообщения, и другие клиентские устройства с возможностью получение адреса по протоколу DHCP.
В рассматриваемую сетевую конфигурацию входят:
КК, расположенные в КС,
ПМ, к которым подключается КС,
DHCP сервер в одной из КС.
Количество КК и КС может быть значительным, например несколько сотен КС, в каждой из которых несколько десятков КК.
При этом DHCP сервер может быть размещен в любой КС.
В качестве ПМ используется высокопроизводительный ПАК HW1000Q6 на базе Intel Core i3-4360 с тактовой частотой 3,7 ГГЦ, объемом оперативной памяти 2 ГБ, объемом жесткого диска 500 Мб, с установленной ОС Linux Debian 7 (ядро 3.10.92). ПАК HW1000Q6 содержит несколько сетевых интерфейсов (4 проводных Ethernet и 2 оптических SFP+) [6].
В состав каждого ПАК входит специализированное ПО - программный модуль средства обработки.
Для реализации способа программный модуль необходимо сформировать и установить в ПАК. Разработку модуля может выполнить специалист по программированию (программист), например на языке программирования С, зная выполняемые ПО функции:
сравнение IP-адресов, содержащихся в кадрах запроса,
модификация кадра запроса путем добавления или удаления данных,
замена IP-адресов, содержащихся в кадрах запроса.
После установки программного модуля средства обработки во все ПМ можно непосредственно реализовать предложенный способ.
Для этого ПМ, к которым подключаются КС, запускаются в рабочем режиме. В одной из КС запускается DHCP сервер, а также включают КК.
Изначально КК не имеет сведений о назначенном IP-адресе интерфейса и IP-адреса шлюза по умолчанию, поэтому из КК передается запрос на получение IP-адреса интерфейса и IP-адреса шлюза по умолчанию в ПМ своей КС, причем запрос содержит
набор кадров,
опции протокола DHCP.
Полученный запрос передается из ПМ в ПМ, находящийся в КС DHCP сервера, а затем в DHCP сервер.
При получении запроса в DHCP сервере формируется ответ в виде совокупности кадров, который передается в ПМ, находящийся в КС DHCP сервера.
Полученный ответ DHCP сервера обрабатывается в средстве обработки ПМ с выполнением следующих действий:
проверяется, содержат ли сведения, имеющиеся в кадрах, какой-либо маршрут, имеющий в качестве IP-адреса шлюза по умолчанию IP-адрес шлюза по умолчанию данного ПМ;
если был обнаружен факт совпадения, то модифицируют ответ путем добавления отметки в кадр.
После обработки передают ответ DHCP сервера из ПМ, находящегося в КС DHCP сервера, в ПМ КС, в которой находится КК, пославший запрос.
Затем обрабатывают ответ DHCP сервера в средстве обработки ПМ КС, из которой поступил запрос, выполняя следующие действия:
проверяют, содержат ли сведения, имеющиеся в кадрах, отметку;
если отметка присутствует, то выполняют следующие действия:
в каждом случае, когда в сведениях, имеющихся в кадрах, указан маршрут, заменяют IP-адрес шлюза по умолчанию, в которой
находится DHCP сервер, на IP-адрес шлюза по умолчанию ПМ КС, из которой поступил запрос;
удаляют из ответа DHCP сервера отметку.
После этого передают ответ DHCP сервера из ПМ КС, из которой поступил запрос, в КК, пославший запрос.
Ответ DHCP принимается в КК, пославший запрос, и, таким образом, обеспечивается дальнейшая работа КК в сети.
В результате, вся объединенная сеть, состоящая из нескольких КС, получает IP-адреса и другие настройки от одного DHCP сервера, что упрощает настройку маршрутизации и администрирование сети и исключает возникновение конфликтов. Все КК в каждой КС, благодаря описанному способу, получают каждый свое значение шлюза по умолчанию, за счет чего маршрутизируют пакеты во внешнюю сеть через ПМ, ближайший к данной КС. При этом минимизируются задержки при обработке пакетов, и уменьшается нагрузка на сервис VPLS и в целом на сеть. Замена шлюза по умолчанию происходит автоматически и не требует дополнительных настроек на DHCP сервере или DHCP клиенте.
Необходимо отметить, что возможны и другие варианты реализации предложенного способа, отличающиеся от описанного выше и зависящие от личных предпочтений при программировании отдельных действий и функций.
Источники информации, принятые во внимание при составлении заявки
1. М. Lasserre, V. Kompella, Alcatel-Lucent, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, 2007 (RFC 4761) - статья по адресу:
https://tools.ietf.org/html/rfc4762
2. К. Kompella, Y. Rekhter, Juniper Networks, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, 2007 (RFC 4762) - статья по адресу:
https://tools.ietf.org/html/rfc4761
3. DHCP Relay Support for MPLS VPN Suboptions - инструкция компании Cisco no настройке DHCP совместно с VPLS, статья по адресу:
http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2b/12_2b4/feature/guide/12b_dhc.html
4. S. Alexander, Silicon Graphics, Inc, R. Droms, Bucknell University, DHCP Options and BOOTP Vendor Extensions, 1997 (RFC 2132) - статья по адресу:
https://www.ietf.org/rfc/rfc2132.txt
5. Т. Lemon, Nominum, Inc., S. Cheshire, Apple Computer, Inc., B. Volz, Ericsson, The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4, 2002 (RFC 3442) - статья по адресу:
https://tools.ietf.org/html/rfc3442
6. ViPNet Coordinator HW1000 v2 - статья по адресу:
http://www.infotecs.ru/products/catalog.php?SECTION_ID=«&ELEMENT_ID=190