Маршрутизация для групп ЭВМ

Управление рассылкой маршрутов

Каждая таблица переадресации соответствует одному или более атрибутам Target VPN. Когда маршрут VPN-IPv4 сформирован маршрутизатором PE, он ассоциируется с одним или более атрибутами Target VPN. Они рассматриваются протоколом BGP как атрибуты маршрута.

Любой маршрут, ассоциированный с Target VPN T, должен рассылаться каждому маршрутизатору PE, который имеет таблицу переадресации, ассоциированную с Target VPN T. Когда такой маршрут получен PE-маршрутизатором, он пригоден для инсталляции в каждой из таблиц переадресации PE, которая ассоциируется с Target VPN T. (Будет ли этот маршрут инсталлирован, зависит от процесса принятия решений BGP). По существу, атрибут Target VPN идентифицирует набор сайтов. Ассоциация конкретного атрибута Target VPN с маршрутом позволяет поместить маршрут в таблицу переадресации, которая используется для маршрутизации трафика, приходящего от соответствующих сайтов.

Имеется набор Target VPN, которые маршрутизатор PE подключает к маршруту, полученному из сайта S. Имеется набор Target VPN, которые маршрутизатор PE использует для определения, будет ли маршрут, полученный от другого маршрутизатора PE, помещен в таблицу переадресации, ассоциированную с сайтом S. Эти два набора различны.

Функции, выполняемые атрибутом Target VPN, сходны с осуществляемыми атрибутом BGP Communities. Однако формат последнего не является адекватным, так как он допускает только двухбайтовое пространство для нумерации. Самым простым решением является расширение пространства нумерации атрибута BGP Communities.

Когда BGP маршрутизатор получил два маршрута до одного и того же префикса VPN-IPv4, он выбирает один, согласно BGP правилам предпочтения маршрутов.

Заметим, что маршрут может иметь только один RD, но он может иметь несколько Target VPN. В BGP масштабируемость улучшается, если имеется один маршрут с несколькими атрибутами.

Как PE определяет, какой из атрибутов Target VPN, ассоциировать с данным маршрутом?

Существует большое число различных способов. PE может быть сконфигурирован так, чтобы ассоциировать все маршруты, которые ведут к определенному сайту, с некоторым заданным Target VPN. Или PE может быть сконфигурирован так, чтобы определенные маршруты, вели к конкретному сайту с одним Target VPN, а к другому — с другим. Или CE-маршрутизатор, когда он рассылает маршруты, может специфицировать один или более Target VPN для каждого маршрута. Последний метод перемещает управление механизмом, используемым для реализации политики VPN от SP к клиенту. Если применяется этот метод, может быть желательным, чтобы PE удалил любую Target VPN, которая, согласно его собственной конфигурации, не допустима, и/или добавил некоторую Target VPN, которая, согласно его конфигурации, является обязательной. Более точно было бы называть этот атрибут Route Target вместо VPN Target.

Если два сайта VPN, подключенные к PE, размещены в одной автономной системе, PE могут рассылать маршруты VPN-IPv4 друг другу посредством соединения IBGP (смотри RFC-2796).

Если два сайта VPN находятся в разных автономных системах (например, из-за того, что они соединены с разными SP), то PE-маршрутизатор будет вынужден использовать маршрутизатор IBGP для перераспределения VPN-IPv4 маршрутов в маршрутизатор ASBR (Autonomous System Border Router) или в маршрутизатор-рефлектор, клиентом которого является ASBR. ASBR будет вынужден применить EBGP (см. RFC-2858), чтобы перераспределить эти маршруты в ASBR из другой AS. Это позволяет соединить различные сайты VPN различным сервис-провайдерам. Однако маршруты VPN-IPv4 должны восприниматься только соединениями EBGP в точках пирингового обмена. Маршруты VPN-IPv4 не должны никогда рассылаться и восприниматься общедоступным Интернет.

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

Когда маршрутизатор PE рассылает маршрут VPN-IPv4 через BGP, он использует свой собственный адрес в качестве "BGP next hop". Он также определяет и рассылает метки MPLS. (Существенно, что маршрутизаторы PE рассылают не VPN-IPv4 маршруты, а маркированные маршруты VPN-IPv4. [8]) Когда PE обрабатывает пакет, который имеет эту метку на вершине стека, PE очистит стек и пошлет пакет непосредственно сайту, от которого ведет маршрут. Это обычно означает, что он посылает пакет маршрутизатору CE, от которого узнал о маршруте. Метка может также определить инкапсуляцию данных в канале.

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

Заметим, что метка MPLS, которая рассылается таким способом, может использоваться, только если существует маркированный путь между маршрутизатором, его сформировавшим, и BGP-маршрутизатором на следующем шаге. Здесь не делается никакого предположения об используемой процедуре установления маркированного пути (процедура setup). Он может быть сформирован предварительно — или установлен, когда нужный маршрут будет инсталлирован. Это может быть оптимальный маршрут ("best effort") — или это может быть маршрут, созданный в результате процедуры формирования трафика (traffic engineered). Между конкретным маршрутизатором PE и его BGP агентом следующего шага для конкретного маршрута может быть один или несколько LSP, возможно, с разными характеристиками QoS.

Если данный маршрутизатор PE не подключен ни к одной Target VPN данного маршрута, он не должен получать этот маршрут. Другие PE, которые посылают ему маршруты, должны использовать внешние фильтры, чтобы избежать рассылки ненужных маршрутов. Конечно, если маршрутизатор PE получает маршрут через BGP, а данный PE не подключен к какой-либо сети target VPN маршрута, PE должен применить к этому маршруту внутреннюю фильтрацию, не анонсируя и не пересылая его.

Маршрутизатор, который не подключен к какой-либо VPN, т.e. P-маршрутизатор, вообще никогда не анонсирует какие-либо маршруты VPN-IPv4.

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

Маршрут VPN-IPv4 может быть опционно ассоциирован с атрибутом VPN of Origin. Это атрибут уникально идентифицирует набор сайтов и определяет соответствующий маршрут как пришедший из одного из сайтов этого набора. Типичным применением этого атрибута может быть идентификация предприятия, которое владеет сайтом, куда ведет маршрут; он может также идентифицировать интранет сайта. Однако возможны и другие применения. Этот атрибут может быть представлен как расширение атрибута BGP communities.

В ситуации, в которой необходимо идентифицировать источник маршрута, используется именно этот атрибут, а не RD. Этот атрибут может использоваться при формировании VPN, как это описано ниже.

Возможно, более корректно называть этот атрибут "Начало маршрута", а не "VPN of Origin". Он в действительности идентифицирует маршрут, приходящий из определенного набора сайтов, вне зависимости от того, составляет ли этот набор VPN.

Устанавливая соответствующие атрибуты Target VPN и VPN of Origin, можно сконструировать VPN самого разного типа.

Предположим, что нужно создать замкнутую группу пользователей CUG (Closed User Group), которая содержит определенный набор сайтов. Это может быть сделано путем формирования определенного атрибута Target VPN для CUG. Значение этого атрибута затем должно быть ассоциировано с таблицами переадресации сайта для каждого сайта в CUG, оно должно быть связано с каждым маршрутом, полученным от сайта в CUG. Любой маршрут, который имеет этот атрибут Target VPN, должен быть перераспределен так, чтобы достичь каждого маршрутизатора PE, подключенного к одному из сайтов.

В качестве альтернативы, предположим, что желательно по какой-то причине создать VPN типа "hub and spoke" (ось и спица). Это может быть сделано путем использования двух значений атрибута Target, один со значением "Hub" а другой со значением "Spoke". Затем маршруты от spokes могут быть посланы hub, не вызывая посылки маршрутов в обратном направлении.

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

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

Переадресация в опорной сети

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

Маршрутизаторы PE (и ASBR, которые перераспределяют адреса VPNIPv4) должны ввести адресные префиксы /32 для самих себя в таблицы маршрутизации опорной сети. Это позволяет MPLS в каждом узле опорной сети присвоить метку, соответствующую маршруту к каждому маршрутизатору PE. (Определенные процедуры для установления коммутации меток в опорной сети могут не требовать присутствия адресного префикса /32.)

Когда PE получает пакет от CE-устройства, он выбирает определенную таблицу переадресации сайта, в которой отыскивается адрес места назначения пакета. Предположим, что такой адрес найден. Если пакет адресован устройству CE, подключенному к тому же самому PE, пакет посылается непосредственно устройству CE.

Если пакет адресован не устройству CE, подключенному к тому же PE, важен BGP Next Hop пакета, а также метка, которую этот BGP следующего шага присвоил адресу места назначения пакета. Эта метка укладывается в стек меток пакета. Затем PE ищет маршрут IGP до BGP следующего шага и таким образом определяет маршрутизатор следующего шага IGP, а также метку, приписанную адресу маршрутизатора следующего шага BGP. Эта метка заносится на верх стека меток пакета, а пакет затем переадресуется к маршрутизатору следующего шага IGP. (Если BGP следующего шага является тем же, что и для IGP, вторая метка может не извлекаться из стека).

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

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

Заметим, что двухуровневая маркировка делает возможным увод всех маршрутов VPN от маршрутизаторов P, а это, в свою очередь, важно для гарантии масштабируемости модели. Опорная сеть не должна иметь маршрутов к CE (только к PE).