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

Запись (*,G), инициирует формирование маршрутизатором DR сообщения Join/Prune с RP-адресом в его join-списке и установленными битами WC и RPT. Равенство WC =1 говорит о том, что согласно этой записи будут пересылаться пакеты любого отправителя. Список удаления (prune) остается пустым. Когда бит RPT=1, это указывает на то, что подключение осуществлено через общее RP-дерево и, следовательно, сообщение Join/Prune будет идти по этому RP-дереву. Когда бит WC= 1, это означает, что адрес принадлежит RP, а получатели предполагают получать пакеты от всех отправителей (см. http://book.itep.ru/4/44/pim_4495.htm).

Каждый маршрутизатор, расположенный по пути к отправителю, создает и отслеживает изменения маршрутной записи для (*,G), когда он получает сообщения Join/Prune с RPT=WC=1. Интерфейс, через который получено сообщение Join/Prune, добавляется к списку выходных интерфейсов (oif) для (*,G). На основе этой записи каждый маршрутизатор по пути между получателем и RP посылает сообщение Join/Prune, в котором RP включен в список join. Поле данных этого пакета содержит мультикаст-адрес=G, Join=RP, WC-бит, RPT-бит, Prune=NULL.

Когда ЭВМ начинает посылать мультикастинг-пакеты группе, сначала DR должен доставить их в RP для последующей раздачи по дереву. DR отправителя в начале инкапсулирует каждый информационный пакет в сообщение Register и отправляет его по уникастному адресу RP данной группы. RP извлекает каждое сообщение Register и переадресует вложенные информационные пакеты вдоль RP-дерева.

Если поток данных позволяет использовать дерево кратчайшего пути до отправителя (SPT — Shortest Pass Tree), RP может сформировать новую маршрутную запись для дерева мультикаст-маршрута, специфичного для данного отправителя (SP-дерево).

DR отправителя прекратит инкапсуляцию информации в пакеты Register, когда он получит сообщение RegisterStop от RP. RP отправляет сообщения RegisterStop в качестве отклика на сообщение Register, если RP не имеет более активных членов группы.

Новый приемник может подключиться к существующему RP-дереву, для которого установлено состояние обрезания (например, из-за того, что другие получатели переключились на SP-деревья). В этом случае состояние обрезания аннулируется, чтобы обеспечить доставку данных новому получателю.

В стабильном состоянии каждый маршрутизатор периодически посылает сообщения Join/Prune для каждой маршрутной записи PIM. Сообщения Join/Prune посылаются соседу, указанному в соответствующей записи. Такие сообщения позволяют отследить изменения состояния системы и топологию членства в группе.

Чтобы получить информацию о RP, все маршрутизаторы в пределах PIM-домена собирают сообщения Bootstrap. Сообщения Bootstrap пересылаются от узла к узлу в пределах домена. За организацию рассылки этих сообщений несет ответственность специальный маршрутизатор BSR (bootstrap router). Сообщения Bootstrap используются для выполнения динамического выбора BSR, когда это необходимо, а также для получения информации об RP. Домен в этом контексте представляет собой набор смежных маршрутизаторов, поддерживающих PIM, и сконфигурированных для совместной работы в рамках границ, определенных пограничными маршрутизаторами PMBR (PIM Multicast Border Router), которые соединяют PIM-домен с остальным Интернет.

Маршрутизаторы применяют набор доступных RP (называемый {RPSet}), чтобы осуществить связь отдельных групп с RP. Некоторое число маршрутизаторов в домене конфигурируется как кандидаты для выполнения функций BSR. Для назначения BSR в домене существуют простые правила выбора. Часть маршрутизаторов в домене конфигурируются так же, как кандидаты для работы в качестве RP (C-RP); как правило, это те же маршрутизаторы, что и кандидаты в BSR. Кандидат в RP периодически посылает всем BSR домена уникастное сообщение CandidateRPAdvertisement (CRPAdvs). C-RP-Advs включает в себя адрес C-RP, а также опционный групповой адрес и поле длины маски. BSR включает набор этих кандидатов в RP (набор RP), вместе с соответствующим групповым префиксом периодически рассылаемых сообщений.

Маршрутизаторы получают и запоминают содержимое сообщений Bootstrap. Когда DR получает указание о членстве в группе от IGMP, DR использует хэш-функцию для установления соответствия между групповым адресом и одним из C-RP, чей префикс включает в себя данную группу. Для конкретной группы G, хэш-функция задействует только те C-RP, чьи групповые префиксы покрывают G. Когда соответствие установлено, DR посылает сообщение Join/Prune (или уникастный пакет Register) соответствующему RP.

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

Если зона PIM-домена теряет доступ к старому BSR, выбирается новый BSR, — он разошлет RP-набор, который содержит RP, доступные в пределах данной зоны. Любая область в любой заданный момент времени обслуживается только одним BSR, который и осуществляет посылку сообщений Bootstrap.

Чтобы обеспечить совместимость с сетями, работающими в режиме DM, с протоколами типа DVMRP, все пакеты, генерируемые в области PIM-SM, должны быть переправлены мультикастным пограничным маршрутизаторам области PMBR (Multicast Border Router) и переадресованы в сеть DVMRP. Маршрутизатор PMBR размещается на границе домена PIM-SM и взаимодействует с другими типами мультикаст-маршрутизаторов, например, теми, которые поддерживают протокол DVMRP. Таким образом, PMBR должен поддерживать оба протокола. Для совместной работы все маршрутизаторы должны поддерживать специальный тип маршрутных записей, обозначаемых (*,*,RP).

Информационные пакеты соответствуют записи (*,*,RP), если нет никаких других записей, например, (S,G) или (*,G), а групповой адрес места назначения пакета согласуется с RP, указанным в записи (*,*,RP). В этом смысле запись (*,*,RP) представляет собой объединение всех групп, которые работают через данную точку встречи RP. PMBR инициализируют состояние (*,*,RP) для каждой RP в каждом доменном наборе RP. Состояние (*,*,RP) заставляет PMBR посылать сообщения (*,*,RP) Join/Prune каждой активной точке встречи в домене. В результате деревья рассылки строятся так, что передают все пакеты, возникающие в пределах PIM-домена (и ретранслируются в точки встречи) в направлении пограничных маршрутизаторов PMBR.

PMBR осуществляют также доставку внешних пакетов маршрутизаторам в пределах PIM-домена. Для решения этой задачи маршрутизаторы инкапсулируют внешние пакеты, полученные через интерфейсы DVMRP, в сообщения Register, после чего уникастным образом переадресуют их в точку встречи RP PIM-домена. Сообщение Register имеет бит, указывающий на то, что пакет сформирован пограничным маршрутизатором.

Информационные пакеты обрабатываются так же, как и при других мультикаст-схемах. Маршрутизатор сначала проверяет адреса отправителя и группы. Затем определяется адрес RP, если непосредственная передача невозможна. Если пути доставки не существует, пакет выбрасывается. При наличии пути выясняется интерфейс, через который должна производиться передача, и пакет переадресуется.

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

Когда имеется несколько маршрутизаторов, соединенных с сетью, которая имеет много каналов доступа, один из них должен быть выбран в качестве ретранслятора (DR; обычно это маршрутизатор с наибольшим IP-адресом). Это справедливо для любой точки сети в любое время. Процедуре выбора предшествует обмен сообщениями Hello.

При наличии параллельных проходов к источнику или RP для выбора маршрута применяются сообщения Assert. Используя сообщения Assert, адресованные 224.0.0.13 (группа ALL-PIM-ROUTERS) в локальной сети, вышестоящий маршрутизатор может узнать, где осуществляется переадресация сообщений. Нижестоящие маршрутизаторы, получая сообщения Assert, узнают, какой маршрутизатор выбран в качестве ретранслятора и куда следует посылать сообщение Join. Обычно это тот же нижележащий маршрутизатор-сосед (Reverse Path Forwarding — RPF), но иногда это может быть и не так, например, когда в локальной сети используется несколько протоколов маршрутизации. RPF-сосед для конкретного отправителя или RP является следующим маршрутизатором, которому переправляются пакеты по пути к отправителю или RP. По этой причине он может рассматриваться как хорошая промежуточная инстанция для пересылки пакетов отправителем.

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

С понятием метрики связано и значение предпочтения метрики. Оно введено, чтобы решать проблемы в случае, когда вышестоящие маршрутизаторы использует другие уникастные протоколы маршрутизации. Численно меньшее значение предпочтения соответствует более высокому приоритету. Значение предпочтения рассматривается в качестве старшей части метрики при сравнении, которое осуществляется при обработке сообщений Assert. Предпочтение может быть присвоено уникастному протоколу маршрутизации и должно быть взаимосогласованным для всех маршрутизаторов локальной сети с множественным доступом.

Сообщения Assert нужны для маршрутных записей (*,G), так как для деревьев RP и SP некоторых групп в сетях с множественным доступом могут возникать зоны перекрытия. Когда Assert посылается для записи (*,G), RPT-бит устанавливается равным 1. Первый бит поля предпочтения всегда устанавливается равным 1, чтобы отметить, что проход соответствует RP-дереву. RPT-бит всегда обнуляется для предпочтения, которое относится к записям SP-деревьев. Это приводит к тому, что проход через SP-дерево выглядит всегда предпочтительнее, чем проход через RP-дерево. Когда деревья SP и RP перекрываются для какой-то LAN, этот механизм устраняет дублирование для данной сети.

DR может уступить процесс (*,G) Assert другому маршрутизатору LAN, если существует несколько проходов к RP через LAN. В этом случае DR не является более ближайшим маршрутизатором для местных получателей, и он удаляет LAN из своего (*,G)-списка выходных интерфейсов. Маршрутизатор-победитель становится "ближайшим" и ответственным за рассылку сообщений (*,G) Join для RP.

Подавление Join/Prune может использоваться в локальных сетях с множественным доступом, чтобы сократить число дублирующих сообщений управления. Для нормальной работы протокола этого не требуется. Если получено сообщение Join/Prune, которое соответствует существующим маршрутным записям (S,G), (*,G) или (*,*,RP) для данного входного интерфейса, а содержимое поля Holdtime сообщения Join/Prune больше, чем Join/PruneHoldtime получателя, может быть запущен таймер Join/PruneSuppression маршрутной записи получателя, чтобы заблокировать последующие сообщения Join/Prune. После завершения работы таймера получатель отправляет сообщение Join/Prune и возобновляет периодическую посылку Join/Prune для данной записи. Таймер Join/PruneSuppression должен перезапускаться каждый раз, когда приходит сообщение Join/Prune с большим значением Holdtime.

Когда уникастная маршрутизация претерпевает изменения, RPF производит проверку активных маршрутных записей (S,G), (*,G) и (*,*,RP) и вносит необходимые поправки. Входной интерфейс может быть добавлен в список выходных интерфейсов с помощью последующих сообщений Join/Prune, поступающих от нижестоящих узлов. Сообщения Join/Prune, полученные текущим входным интерфейсом, игнорируются, а сообщения, полученные новыми или существующими выходными интерфейсами, обрабатываются. Остальные выходные интерфейсы останутся в прежнем состоянии до тех пор, пока не будут отключены нижележащими маршрутизаторами или по тайм-ауту из-за отсутствия соответствующих сообщений Join/Prune. Если маршрутизатор имеет запись (S,G) с установленным битом SPT, а обновленная запись iif(S,G) не отличается от iif(*,G) или iif(*,*,RP), то маршрутизатор переводит бит SPT в нулевое состояние.

Соседи-маршрутизаторы, поддерживающие протокол PIM, периодически обмениваются сообщениями Hello. Сообщения Hello могут также рассылаться мультикастным образом с использованием адреса 224.0.0.13 (группа ALL-PIM-ROUTERS). Пакет содержит значение Holdtime (время сохранения информации).

Когда маршрутизатор получает сообщение Hello, он запоминает IP-адрес соседа, устанавливает таймер отправки на время, которое соответствует Holdtime, заключенное в Hello, и определяет выделенный маршрутизатор (DR) для данного интерфейса. В качестве DR выбирается объект с наибольшим IP.

Когда маршрутизатор, который является активным DR, получает Hello от нового соседа (например, от IP-адреса, которого нет в таблице DR), DR уникастным образом передает RP-информацию новому соседу.

PIM-соседи, от которых в течение определенного времени не поступало сообщений Hello, считаются отключившимися. Если DR отключился, выбирается новый DR из числа соседей с наибольшим IP-адресом.

Сообщения Join/Prune служат для того, чтобы подключить или удалить ветвь мультикастинг-дерева рассылки. Сообщение содержит как join-, так и prune-списки, любой из них может иметь нулевую длину. Они также содержат все подключенные и отсоединенные источники данных, достижимые через данный узел адресат сообщения. Период отправки сообщений Join/Prune определяется значением [Join/PrunePeriod].

Маршрутизатор периодически посылает сообщения Join/Prune каждому конкретному RPF-соседу, соответствующему каждой маршрутной записи (S,G), (*,G) и (*,*,RP). Сообщения Join/Prune посылаются только тогда, когда RPF-сосед является PIM-соседом.

Кроме периодически рассылаемых сообщений некоторые из Join/Prune пакетов могут генерироваться как следствие следующих событий:

a. создана новая маршрутная запись, или

b. список выходных интерфейсов перешел из нулевого в ненулевое состояние или наоборот.

Может так случиться, что размер сообщения Join/Prune превысит MTU сети. В этом случае сообщение может быть фрагментировано, информация, относящаяся к различным группам, будет послана в разных пакетах. Однако если сообщение Join/Prune должно быть фрагментировано, полный prune-список, соответствующий группе G, должен быть включен в одно сообщение Join/Prune согласно RP-дереву Join для G. Если такая семантическая фрагментация невозможна, при транспортировке пакетов от соседа к соседу должна использоваться IP-фрагментация.

Для любой новой записи (S,G), (*,G) или (*,*,RP), сформированной входящим сообщение Join/Prune, бит SPT сбрасывается.

Если запись имеет таймер Join/PruneSuppression и полученное сообщение Join/Prune не указывает на маршрутизатор в качестве места назначения, тогда принимающий маршрутизатор просматривает join- и prune-списки, чтобы выяснить, нет ли там адресов, полностью соответствующих существующим состояниям (S,G), (*,G) или (*,*,RP), для которых принимающий маршрутизатор осуществляет рассылку сообщений Join/Prune. Элемент join- или prune-списка полностью соответствует маршрутной записи только тогда, когда их IP-адреса и RPT-флаги равны. Если приходящее сообщение Join/Prune полностью соответствует существующим записям (S,G), (*,G) или (*,*,RP), а сообщение Join/Prune приходит на входной интерфейс для данной записи, маршрутизатор сравнивает Holdtime сообщения со своим собственным значением Join/Prune-Holdtime. Если его значение Join/Prune-Holdtime меньше, запускается таймер Join/PruneSuppression. Если Join/PruneHoldtime равно Holdtime сообщения, коллизия разрешается в пользу отправителя сообщения Join/Prune, который имеет больший IP-адрес. Когда время Join/Prune таймера истекает, маршрутизатор отправляет сообщение Join/Prune для соответствующей маршрутной записи.

Когда отправитель начинает отправку данных группе, его пакеты инкапсулируются в сообщения Register и посылаются в RP. Если скорость передачи гарантируется каналом, RP устанавливает соответствующее состояние для отправителя и начинает посылать сообщения (S,G) Join/Prune отправителю с S в join-списке.

Сообщения Assert используются для принятия решения, какой из параллельных маршрутизаторов, подключенных к локальной сети с множественным доступом, должен быть ответственным за ретрансляцию пакетов в LAN.

9.2. Маршрутизация для VPN (Мультипротокольные расширения для BGP-4 – RFC-2858)

Широкое внедрение протокола MPLS (Multiprotocol Label Switching —мультипротокольная коммутация пакетов по меткам) ставит некоторые новые задачи маршрутизации. Специфика коммутации на основе меток, записанных в пакетах, принципиально меняет идеологию маршрутизации. Наиболее часто VPN формируются сервис-провайдерами. Протокол MPLS позволяет достаточно просто решить эту проблему. Маршруты через опорную сеть прокладываются с помощью протокола BGP (Border Gateway Protocol).

Одной из причин широкого внедрения протоколов коммутации пакетов по меткам является непомерный рост объема маршрутных таблиц и, как следствие, увеличение задержек (RTT) из-за необходимости просмотра этих таблиц.

Рассмотрим набор сайтов, которые подсоединены к общей сети, называемой опорной. Определим некоторую политику при создании субнаборов этого набора и введем следующее правило: два сайта могут взаимодействовать друг с другом через опорную сеть, только если, по крайней мере, один из этих субнаборов содержит оба эти сайта.

Субнаборы, которые создаются, являются "Частными виртуальными сетями" (VPN). Два сайта имеют IP-коннективность через опорную сеть, только если существует VPN, которая содержит в себе оба эти сайта. Два сайта, которые не имеют общих VPN, не имеют связи через опорную сеть. (Смотри также RFC-2547.)

Если все сайты в VPN принадлежат одной и той же компании, VPN является корпоративной "интранет". Если разные сайты в VPN принадлежат различным компаниям, VPN считается "экстранетом". Сайт может состоять в более чем одной VPN, например, интранет и несколько экстранетов. Будем рассматривать интранеты и экстранеты как VPN. Вообще, при использовании термина VPN в дальнейшем не будет делаться различия между интранетами и экстранетами.

Будем рассматривать случай, когда опорная сеть принадлежит и обслуживается одним или несколькими сервис-провайдерами (SP). Владельцы сайтов являются клиентами SP. Будет ли конкретный набор сайтов VPN, определяется политикой клиентов. Некоторые клиенты могут пожелать, чтобы реализация политики осуществлялась исключительно SP. Другие клиенты могут осуществлять политику самостоятельно или делить ответственность с SP. Далее обсуждаются механизмы, которые могут быть применены для реализации такой политики. Эти механизмы являются достаточно общими, чтобы реализовать политику либо самим SP, либо клиентом VPN совместно с SP . Большая часть обсуждения, однако, посвящена последнему варианту.

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

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

Предполагается, что на каждом сайте имеется одно или более оконечное устройство клиента CE (Customer Edge), каждое из которых подключено через какой-то канал (например, PPP, ATM, Ethernet, Frame Relay, GRE-туннель, и т.д.) к одному или более оконечному маршрутизатору провайдера PE (Provider Edge).

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

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

Важно сохранять четкие административные границы между SP и их клиентами [4]. Маршрутизаторы PE и P должны администрироваться SP, клиенты SP не должны иметь доступа к их управлению. Устройства CE должны управляться клиентом (если только клиент не заключил соглашение с SP).

VPN с перекрывающимися адресными пространствами

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

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

VPN с разными маршрутами до одной и той же системы

Хотя сайт может находиться в нескольких VPN, не обязательно маршрут к данной системе будет тем же, что для всех прочих VPN. Предположим, например, что имеется интранет, состоящий из сайтов A, B и C, а также экстранет, включающий в себя A, B, C и "чужой" сайт D. Будем считать, что сайт A является сервером и мы хотим предоставить клиентам из B, C или D доступ к этому серверу. Предположим также, что сайт B является файерволом. Мы хотим, чтобы весь трафик из сайта D к серверу проходил через файервол, так, чтобы он мог контролироваться трафик из экстранета. Однако мы не хотим, чтобы трафик от C проходил через firewall на пути к серверу, поскольку это трафик интранет.

Это означает, что нужно конфигурировать два маршрута к серверу. Один маршрут, используемый сайтами B и C, организует трафик к сайту A. Второй маршрут, используемый сайтом D, формирует трафик через firewall сайта B. Если firewall позволяет проходить трафику, этот трафик затем рассматривается как приходящий из сайта B и следующий до узла A.

Таблицы переадресации в PE

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

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

Маршрутизаторы опорной сети SP

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

Если каждый маршрутизатор в опорной сети SP должен поддерживать маршрутную информацию для всех VPN, с которыми работает SP, такая модель будет иметь серьезные проблемы с масштабируемостью. Число поддерживаемых сайтов будет лимитировано объемом маршрутной информации, хранимой одним маршрутизатором. Важно, следовательно, потребовать, чтобы маршрутная информация о конкретном VPN присутствовала только в тех PE-маршрутизаторах, которые соединены с этой VPN. В частности, P-маршрутизаторы не должны иметь какой-либо маршрутной информации о любых VPN.

VPN может пользоваться услугами нескольких сервис-провайдеров. Предполагается, что когда путь между PE-маршрутизаторами пересекает границу между сетями SP, это делается согласно пиринговому соглашению, в рамках которого существует договоренность между двумя провайдерами. В частности, каждый провайдер должен доверять друг другу пересылку только корректной маршрутной информации и передавать ее в помеченных (в значении MPLS [9]) пакетах, только если эти пакеты были помечены отправителями, достойными доверия. Предполагается, что маршрутам, коммутируемым по меткам, разрешается пересекать границы между сервис-провайдерами.

Сайты и CE

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

CE-устройства всегда рассматриваются принадлежащими одному сайту (хотя, как мы это увидим, сайт может состоять из множества "виртуальных сайтов"). Сайт, однако, может принадлежать многим VPN.

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

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

Таблицы переадресации сайта в PE

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

Как заполняются таблицы переадресации сайтов?

В качестве примера, пусть PE1, PE2 и PE3 являются PE-маршрутизаторами и пусть CE1, CE2 и CE3 являются CE-маршрутизаторами. Предположим, что PE1 узнает от CE1 маршруты, которые достижимы в сайте CE1. Если PE2 и PE3 подключены соответственно к CE2 и CE3 и имеется VPN V, содержащая CE1, CE2 и CE3, тогда PE1 использует BGP для посылки маршрутной информации PE2 и PE3, которую он получил от CE1. PE2 и PE3 используют эти маршруты для заполнения таблиц переадресации, которые ассоциируются ими с сайтами CE2 и CE3, соответственно. Маршруты из сайтов, которые находятся вне VPN V, не заносятся в эти таблицы, поэтому пакеты от CE2 или CE3 не могут быть посланы сайтам, которые не принадлежат VPN V.

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

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

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

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

(a) метка в верхней позиции стека действительно прислана маршрутизатором опорной сети в устройство не опорной сети, и

(b) маршрутизатор опорной сети может определить, что использование этой метки вызовет уход пакета из опорной сети, до того как будет рассмотрена какая-либо ниже лежащая в стеке метка и до того как будет проанализирован IP-заголовок. Эти ограничения необходимы, чтобы препятствовать попаданию пакетов в VPN, которой они не принадлежат.

Таблицы переадресации сайта в PE используются только для пакетов, которые приходят от сайта, непосредственно связанного с PE. Они не используются для маршрутизации пакетов, которые присылаются другими маршрутизаторами, принадлежащими опорной сети SP. В результате может существовать несколько разных маршрутов до одной и той же системы, определяемых сайтом, из которого пакет попадает в опорную сеть. Например, может существовать маршрут до данной системы для пакетов из экстранет (где маршрут идет через firewall) и другой маршрут для пакетов из интранет (включая пакеты, которые уже идут через firewall).

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

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

В качестве альтернативы можно разделить интерфейс на несколько субинтерфейсов (в частности, если интерфейс следует стандарту Frame Relay или ATM) и ассоциировать пакет с VPN на основе суб-интерфейса, через который он вошел. Можно также просто использовать отдельный интерфейс для каждого виртуального сайта. Так или иначе, для одного сайта нужен только один CE-маршрутизатор, даже в случае большого числа виртуальных сайтов. Конечно, если хочется, можно использовать разные CE-маршрутизаторы для каждого виртуального сайта.

Заметим, что во всех случаях механизмы и политика управления, какой трафик пропускать и для какого VPN, находится в руках клиента.

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

Эти схемы не требуют от CE поддержки MPLS. Раздел "Если СЕ поддерживает MPLS?" содержит краткое описание того, как CE может поддерживать большое число виртуальных сайтов, если оно не поддерживает MPLS.

Распределение маршрутов VPN посредством BGP

Маршрутизаторы PE применяют BGP для рассылки маршрутов между VPN (точнее, для принуждения VPN обмениваться маршрутами между собой).

Отправитель BGP может анонсировать и разослать маршрут для данного адресного префикса. Каждая VPN может иметь свое адресное пространство; это означает, что некоторые адреса могут использоваться в любом числе VPN, где в каждой VPN адрес соотносится с разными объектами. Отсюда следует, что нужно позволить BGP инсталлировать и рассылать несколько маршрутов для одного IP-адресного префикса. Более того, нужно гарантировать, что для определения, какой маршрут из списка, предоставленного BGP, может использовать сайт и какой из них будет прописан в таблице переадресации, служит политика.

Адресное семейство VPN-IPv4

Мультипротокольное расширение BGP [3] позволяет этому протоколу работать со многими адресными семействами. Введем обозначение VPNIPv4 address family. Адрес VPN-IPv4 имеет 12-байт, начинается с 8 байт идентификатора маршрута RD (Route Distinguisher) и завершается четырьмя байтами адреса IPv4. Если две VPN используют один и тот же адресный префикс IPv4, PE транслирует их в уникальный адресный префикс VPN-IPv4. Это гарантирует, что в случае использования одного и того же адреса в двух разных VPN, будет возможно установить два совершенно разных маршрута до этого адреса — по одному для каждого VPN.

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

RD может также применяться для формирования множественных путей к одной и той же системе. В разделе "Таблицы переадресации сайта в РЕ" (см. выше) приводится пример, где маршрут к определенному серверу должен быть разным для интранет и экстранет. Для этого нужно создать два разных VPN-IPv4 маршрута, которые имеют идентичную IPv4 часть, но разные RD. Это позволяет BGP установить несколько разных путей к одной и той же системе и разрешить использование политики, чтобы решить, какие пакеты будут пользоваться данным маршрутом.

RD структурированы так, что каждый сервис-провайдер может администрировать свою зону нумерации (т.e., может выполнить свои собственные присвоения для RD), не конфликтуя с RD, присвоенными другими сервис-провайдерами. RD состоит из двухбайтного поля типа, поля администратора и поля присвоенного номера. Значение поля типа определяет длины двух других полей, а также семантику поля администратор. Поле администратор идентифицирует систему присвоения номеров (assigned number authority), а поле присвоенного номера несет в себе число, которое служит для идентификации этой системы. Например, может существовать RD, чье поле администратор содержит ASN (Autonomous System number) и поле номера (4-байта) содержит число, присвоенное SP, которому этот код ASN присвоен IANA. Для RD выбрана такая структура, чтобы гарантировать, что SP, который предоставляет услуги опорной сети, может всегда сформировать уникальный RD, когда это потребуется. Однако данная структура не предоставляет никакой семантики. Когда BGP сравнивает два таких адресных префикса, он полностью игнорирует структуру. Если субполя администратор и присвоенный номер адреса VPN-IPv4 установлены равными нулю, считается, что адрес VPN-IPv4 имеет то же значение, что и глобально уникальный адрес IPv4. В частности, этот VPN-IPv4 адрес и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как совместимые. Во всех других случаях, адрес VPN-IPv4 и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как несовместимые.

Данная таблица переадресации сайта будет иметь только один маршрут VPN-IPv4 для любого заданного адресного префикса IPv4. Когда место назначения пакета соответствует маршруту VPN-IPv4, это соответствие касается только IPv4-части.

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

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

Каждая таблица переадресации соответствует одному или более атрибутам 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).

Как 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:

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

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 однозначно идентифицирует сайт, от которого маршрутизатор 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, будет идентифицировать только виртуальный сайт, от которого пакет пришел.

Представление ISP VPN в качестве части VPN

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

Безопасность

a) Помеченные пакеты не воспринимаются маршрутизаторами опорной сети, если они пришли из источников, не внушающих доверия, за исключением случаев, когда известно, что такие пакеты покинут опорную сеть до того, как будут проанализированы IP-заголовки или какие-либо метки в стеке; и

b) помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия; безопасность, предоставляемая этой архитектурой, виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM.

Не имеет никакого значения тот факт, что использование MPLS упрощает достижение уровня безопасности, который возможен при создании туннеля IP-поверх-IP вместо MPLS. Довольно просто отказать в допуске помеченных пакетов, если только не реализуется первое из указанных выше условий. Много труднее сконфигурировать маршрутизатор так, чтобы заблокировать прием IP-пакетов, если эти пакеты представляют собой IP-поверх-IP, идущие в "неправильное" место.

Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации.

Для пользователя VPN возможно также обеспечить себе повышенную безопасность, применяя туннельный режим IPSEC [5].

Пользователи VPN, чувствительные к проблемам безопасности, могут требовать гарантии того, что некоторые или все пакеты, которые проходят через опорную сеть, были аутентифицированы и/или зашифрованы. Стандартный путь получения такого режима заключается в создании "безопасного туннеля" для каждой пары маршрутизаторов CE в VPN, используя туннельный режим IPSEC.

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

Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, идентифицирующий следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, тогда может использоваться стандартный туннельный режим IPSEC.

Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP.

Каждый CE, который должен использовать IPSEC, должен быть так сконфигурирован, чтобы запретить посылку небезопасного трафика по любому из оговоренных адресов. Это блокирует посылку небезопасного трафика CE, если по какой-то причине ему не удалось получить необходимую информацию.

Когда MPLS применяется для переноса пакетов между двумя конечными точками туннеля IPSEC, внешний заголовок IPSEC не выполняет в действительности никакой функции. Может быть желательно разработать форму туннеля IPSEC, которая позволяет отбрасывать внешний заголовок, в тех случаях, когда используется MPLS.

Многокомпонентные безопасные ассоциации

Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, — оно должно знать какой сети VPN предназначена эта информация. Оконечное устройство клиента CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом, защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка.

Существенным преимуществом схемы, подобной этой, является то, что изменение в маршрутизации (в частности, изменение выхода CE для конкретного адресного префикса) прозрачны для механизма безопасности. Это может быть важным, в частности, в случае мультипровайдерских VPN, где нужно пересылать информацию об изменении маршрутов с целью поддержания механизмов безопасности. BGP-4 транспортирует три типа данных, которые ориентированы на IPv4:

a. атрибут NEXT_HOP (представляет собой адрес IPv4);

b. AGGREGATOR (содержит адрес IPv4), и

c. NLRI (Network Layer Reachability Information — представляет собой префикс IPv4).

В данном документе предполагается, что любой BGP-партнер (включая тот, который поддерживает мультипротокольные возможности, рассмотренные ниже) должен иметь IPv4 адрес (который будет использоваться в атрибуте AGGREGATOR). Следовательно, чтобы BGP-4 мог поддерживать несколько протоколов сетевого уровня, необходимо добавить две вещи:

a. возможность ассоциирования конкретного протокола сетевого уровня с данными о следующем шаге, и

b. возможность для заданного протокола сетевого уровня работать с NLRI.

Чтобы идентифицировать протокол сетевого уровня, здесь применяется понятие семьи адресов (Address Family), как это определено в [RFC-1700].

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

Чтобы обеспечить обратную совместимость, а также упростить введение мультипротокольных возможностей в BGP-4, здесь используются новые атрибуты: многопротокольная NLRI достижимости ( MP_REACH_NLRI ), и многопротокольная NLRI недостижимости ( MP_UNREACH_NLRI ). Первый из них ( MP_REACH_NLRI ) нужен для хранения набора достижимых адресатов и данных о следующем шаге, который следует использовать для достижения этих мест назначения. Второй атрибут ( MP_UNREACH_NLRI ) применяется для хранения набора недостижимых адресатов. Таким способом партнер BGP, который не поддерживает мультипротокольные возможности, будет просто игнорировать информацию, содержащуюся в этих атрибутах, и не передаст эти данные другим BGP партнерам.

Многопротокольная NLRI достижимости — MP_REACH_NLRI (код типа 14)

Это опционный не транзитивный атрибут, который может использоваться для следующих целей:

(a) чтобы оповестить о возможном пути до партнера

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

(c) чтобы позволить данному маршрутизатору уведомить некоторую или все точки подключения к субсети SNPA (Subnetwork Points of Attachment), которые имеются в локальной системе

Атрибут закодирован следующим образом.

Использование и значения этих полей описаны ниже.

Идентификатор семейства адресов

Это поле содержит код протокола сетевого уровня, соответствующего последующему сетевому адресу. Определенные на данный момент значения этого поля специфицированы в RFC-1700 (смотри раздел кодов семейств адресов).

Идентификатор семейства последующих адресов

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

Длина сетевого адреса следующего шага

1-октетное поле, значение которого определяет длину поля Сетевой адрес следующего шага, измеренную в октетах.

Сетевой адрес следующего шага

Поле переменной длины, которое содержит сетевой адрес следующего маршрутизатора на пути к системе назначения.

Число SNPA

1-октетное поле, содержащее число SNPA, которые перечислены в последующих полях. Значение 0 может использоваться для индикации отсутствия SNPA в данном атрибуте.

Длина N-го SNPA

1-октетное поле, чье значение определяет длину поля "N-ый SNPA следующего шага", выраженную в полуоктетах.

N-ый SNPA следующего шага

Поле переменной длины, которое содержит SNPA маршрутизатора, чей сетевой адрес размещен в поле "Сетевой адрес следующего шага". Поле длины определяет целое число октетов в длине, точнее, округленное до целого значение половины длины SNPA, выраженное в полуоктетах; если SNPA содержит нечетное число полуоктетов, значение этого поля дополняется полуоктетом, заполненным нулями.

Информация о достижимости сетевого уровня

Поле переменной длины, где перечислены NLRI для доступных маршрутов, которые объявляются этим атрибутом. Когда поле идентификатора семейства последующих адресов имеет значение из набора, описанного в данном документе, каждое NLRI кодируется согласно описанию из раздела "Кодирование NLRI".

Информация о следующем шаге, записанная в атрибуте пути MP_REACH_NLRI, определяет адрес сетевого уровня пограничного маршрутизатора, который следует использовать в качестве следующего шага, из перечня MP_NLRI в сообщении UPDATE. В случае применения атрибута MP_REACH_NLRI для оповещения внешнего партнера, в компоненте следующего шага атрибута маршрутизатор может использовать один из адресов собственных интерфейсов. BGP-отправитель может анонсировать внешнему партнеру интерфейс любого внутреннего маршрутизатора.

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

BGP-партнер не должен никогда устанавливать маршрут, где он сам является следующим шагом.

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

Сообщение UPDATE, которое содержит MP_REACH_NLRI, должно также содержать атрибуты ORIGIN и AS_PATH (как в EBGP-, так и в IBGP-обменах). Более того, в IBGP-обменах такое сообщение должно также содержать атрибут LOCAL_PREF. Если такое сообщение получено от внешнего партнера, локальная система проверит, является ли самая левая AS в атрибуте AS_PATH автономной системой партнера, пославшего это сообщение. Если это не так, локальная система пошлет сообщение предупреждения (NOTIFICATION) с кодом ошибки UPDATE Message Error и субкодом ошибки Malformed AS_PATH.

Сообщение UPDATE, которое не содержит NLRI, отличных от записанных в атрибуте MP_REACH_NLRI, не должно нести в себе атрибута NEXT_HOP. Если такое сообщение содержит атрибут NEXT_HOP, BGP-партнер, который получает это сообщение, должен игнорировать этот атрибут.

Мультипротокольное NLRI недостижимости — MP_UNREACH_NLRI (Код типа 15)

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

Идентификатор семейства адресов

Это поле содержит идентификатор протокола сетевого уровня, ассоциированного с последующим NLRI. В настоящее время, значения, определенные для этого поля, специфицированы в RFC-1700 (смотри раздел коды адресных семейств).

Идентификатор семейства последующих адресов

Это поле предоставляет дополнительную информацию о типе данных доступности, содержащихся в атрибуте.

Ликвидируемые маршруты

Поле переменной длины, где перечисляются NLRI для маршрутов, которые отзываются. Когда поле идентификатора семейства последующих адресов соответствует коду, определенному в данном документе, каждое из NLRI кодируется согласно разделу "Кодирование NLRI".

Сообщение UPDATE, которое содержит MP_UNREACH_NLRI, не обязано нести какие-либо другие атрибуты пути.

Кодирование NLRI

Информация достижимости сетевого уровня кодируется в виде одного или более 2-полуоктетов в форме <длина, префикс>, представленной ниже:

Длина

Поле длина указывает длину адресного префикса в битах. Длина, равная нулю, означает, что префикс соответствует всем адресам (как это специфицировано семейством адресов).

Префикс

Поле префикс содержит адресный префикс, за которым следует число бит, достаточное, чтобы сделать длину поля кратной октету. Заметим, что значение этих бит не играет роли.

Идентификатор семейства последующих адресов

Этот документ определяет следующие значения для поля идентификатора семейства последующих адресов, содержащегося в атрибутах MP_REACH_NLRI и MP_UNREACH_NLRI.

Обработка ошибок

Если BGP-партнер получает от соседа сообщение Update, которое содержит атрибут MP_REACH_NLRI или MP_UNREACH_NLRI, и партнер определяет, что атрибут некорректен, он должен аннулировать BGP-маршруты, полученные от соседа, чье AFI/SAFI совпадает со значением в некорректном атрибуте MP_REACH_NLRI или MP_UNREACH_NLRI. На время BGP сессии, когда получено сообщение Update, отправитель должен игнорировать все маршруты с AFI/SAFI, полученными в ходе сессии.

Кроме того, партнер может завершить BGP сессию, во время которой получено сообщение Update. Сессия должна быть завершена посылкой сообщения-предупреждения с кодом/субкодом "Update Message Error/Optional Attribute Error" (ошибка сообщения обновления/ошибка опционного атрибута).

Использование возможности оповещения в BGP

BGP-партнер, который использует мультипротокольные расширения, должен использовать процедуры оповещения о возможностях [BGP-CAP], чтобы определить, может ли он применять мультипротокольные расширения с конкретным партнером.

В параметре Опционные возможности содержатся следующие поля. Поле кода возможности устанавливается равным 1 (что указывает на возможность многопротокольных расширений). Поле длины возможностей устанавливается равным 4. Формат поля возможностей представлен на рис. 9.3:

Использование и значение полей:

Партнер, который поддерживает множественные комбинации полубайтов <AFI, SAFI>, включает их как множественные возможности в параметр опционных возможностей.

Чтобы иметь двунаправленный обмен маршрутной информацией для конкретного <AFI, SAFI> между партнерами BGP, каждый из них должен уведомлять другого (через механизм анонсирования возможностей) о поддержке этих конкретных <AFI, SAFI> маршрутов.

Другие возможности маршрутизации с использованием коммутации по меткам рассмотрены в разделе, где описан протокол MPLS.