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

Как PE узнают о маршрутах от CE

Маршрутизаторы PE, которые подключены к какой-то VPN, должны знать адреса для каждого сайта из данного VPN.

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

PE транслирует эти адреса в адреса VPNIPv4, используя сконфигурированный RD. PE далее рассматривает эти маршруты в качестве входной информации протокола BGP. Ни при каких обстоятельствах маршруты из сайта не должны уходить в IGP опорной сети.

Какой из методов рассылки маршрутов PE/CE возможен, зависит оттого, является ли конкретное устройство CE транзитным VPN или нет. Транзитная VPN – это сеть, которая содержит маршрутизатор, получающий маршруты от третей стороны (т.e., от маршрутизатора, который находится вне VPN, но не является PE-маршрутизатором) и перераспределяющий эти маршруты в маршрутизатор PE. Сеть VPN, которая не является транзитной, представляет собой частичную VPN. Такими сетями следует считать подавляющее большинство VPN, включая практически все корпоративные сети.

Возможные механизмы рассылки PE/CE:

1. Может использоваться статическая маршрутизация (т.e., конфигурация).
2. PE и CE-маршрутизаторы могут быть RIP-партнерами, а CE может использовать RIP, чтобы сообщить маршрутизатору PE набор адресных префиксов, которые достижимы для сайта CE. Когда RIP сконфигурирован в CE, следует позаботиться о том, чтобы адресные префиксы от других сайтов (т. e., адресные префиксы, полученные маршрутизатором CE от маршрутизатора PE) никогда не анонсировались PE. Точнее, если маршрутизатор PE (скажем, PE1) получает VPNIPv4 маршрут R1 и в результате посылает маршрут IPv4 R2 в CE, R2 не должен быть послан назад из сайта CE в маршрутизатор PE (скажем, PE2), где PE1 и PE2 могут быть тем же маршрутизатором или разными маршрутизаторами, если только PE2 не ставит в соответствие R2 и маршрут VPNIPv4, который отличается от R1 (т.e., содержит другой RD).
3. Маршрутизаторы PE и CE могут быть партнерами OSPF. В этом случае сайт должен быть единой областью OSPF, CE должно быть ABR для этой области, а PE должно быть ABR, который находится вне области. Кроме того, PE не должен анонсировать никакие связи маршрутизатора, кроме тех, что существуют до CE, размещенном в том же сайте. Этот метод должен использоваться только в частичных VPN.
4. Маршрутизаторы PE и CE могут быть партнерами BGP, а маршрутизатор CE может использовать BGP. В частности, он может быть EBGP, чтобы уведомить маршрутизатор PE о наборе адресных префиксов, которые находятся в сайте маршрутизатора CE. Эта технология может использоваться в частичных или транзитных VPN.

С чисто технической точки зрения это далеко не совершенная методика.

a) В отличие от альтернатив IGP, она не требует от PE направлять несколько запросов алгоритму маршрутизации, чтобы взаимодействовать с несколькими CE.

b) BGP сконструирован как раз для решения таких задач: пересылки маршрутной информации между системами, управляемыми разными администраторами.

c) Если сайт содержит "BGP backdoors", т.e., маршрутизаторы с BGP-соединениями с маршрутизаторами, отличными от PE-маршрутизаторов, эта процедура будет работать корректно при любых обстоятельствах. Другие процедуры могут работать или нет, в зависимости от конкретных обстоятельств.

d) Использование BGP упрощает для CE передачу атрибутов маршрутов PE. Например, CE может предложить определенное значение Target для каждого маршрута, из числа атрибутов Target, которые авторизованы PE для присвоения маршруту.

С другой стороны, использование BGP, вероятно, является чем-то новым для CE администраторов, за исключением случая, когда клиент сам представляет из себя Интернет сервис-провайдера. Если сайт не является транзитной VPN, он не должен иметь уникальный ASN (Autonomous System Number). Каждый CE, чей сайт не является транзитной VPN, может использовать один и тот же ASN. Значение может быть взято из частного ASN-пространства, оно будет ликвидировано PE. Маршрутные петли предотвращаются путем использования атрибута Site of Origin (см. ниже).

Если набор сайтов представляет собой транзитную VPN, удобно представить их как BGP конфедерацию, так что внутренняя структура VPN окажется спрятанной от любого маршрутизатора, который находится вне VPN. В этом случае каждый сайт в VPN потребует двух BGP-соединений с опорной сетью: одно будет внутренним по отношению к конфедерации, а другое — внешним. Обычные интра-конфедерационные процедуры должны быть слегка модифицированы, чтобы учесть возможность того, что опорная сеть и сайты могут иметь разную политику. Опорная сеть является членом конфедерации для одного из соединений, но не будет членом конфедерации для другого. Такие методики полезны, если клиентом услуг VPN является ISP. Эта методика позволяет клиенту, который является ISP, получить услуги опорной сети VPN от одного из партнеров ISP.

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

Прежде чем PE сможет передать VPNIPv4 маршрут, узнанный от сайта, он должен присвоить ему определенный атрибут. Существует три таких атрибута.

• Исходный сайт (Site of Origin)
• Исходная VPN (VPN of Origin)
• Оконечная VPN (Target VPN)

Атрибут Site of Origin однозначно идентифицирует сайт, от которого маршрутизатор PE узнал о маршруте. Всем маршрутам, полученным от определенного сайта, должен быть присвоен один и тот же атрибут Site of Origin, даже если сайт имеет несколько соединений с одним PE или соединен с несколькими PE. Определенные атрибуты Site of Origin должны использоваться с определенными сайтами. Этот атрибут может быть представлен как атрибут extended BGP communities.

Как CE узнает маршруты от PE

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

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

Какая бы из процедур ни использовалась для рассылки маршрутов от CE к PE, она же может служить для передачи маршрутов от PE к CE.

Если CE поддерживает MPLS?

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

Вариант с виртуальными сайтами

Если рассылка маршрутов CE/PE выполнена через BGP, CE может использовать MPLS, чтобы осуществить поддержку большого числа сайтов. CE может сам содержать отдельную таблицу переадресации для каждого виртуального сайта, которую он заполняет, как это указано атрибутами Origin и Target VPN маршрутов, получаемых им от PE. Если CE получает от PE полный набор маршрутов, PE не будет просматривать адреса пакетов, полученных от CE. В качестве альтернативы PE может в некоторых случаях посылать CE отдельный (помеченный) маршрут по умолчанию для каждого VPN. Затем, когда PE получает помеченный пакет от CE, он узнает, какую таблицу переадресации следует просматривать. Метка, помещенная в пакет CE, будет идентифицировать только виртуальный сайт, от которого пакет пришел.