Вариант 5: подключение клиентов к различным провайдерам с резервным каналом между ними

Иногда возникает необходимость в соединении AS через Internet посредством различных провайдеров. Однако поддержка такой схемы является очень сложной задачей. Мы пойдем даже несколько дальше и рассмотрим, как реализовать эту схему с точки зрения провайдера.

На рис. 7.20 представлены AS1, являющая клиентом ISP1, и AS2, которая является клиентом провайдера ISP2. Согласно двустороннему соглашению, AS1 и AS2 организовали частный канал между своими узлами и решили использовать его в качестве резервного на случай отказа основного канала с Internet.

Рис. 7.20. Подключение клиентов к нескольким провайдерам с использованием резерв ного канала

Как правило, отдельные AS нежелательно использовать в качестве транзитных для других AS. В рассматриваемой ситуации (см. рис. 7.20) в ASI требуется настроить маршрутизацию от провайдера ISP1 таким образом, чтобы он мог попасть в AS2 через ISP2. Точно так же в AS2 следует настроить маршрутизацию от провайдера ISP2 таким образом, чтобы он попадал в AS1 через ISP1. В этом случае для обеспечения работы резервного канала AS1 объявляет маршруты в сети AS2 провайдеру ISP1, a AS2 объявляет маршруты в сети ASI провайдеру ISP2.

собой"

См. в главе 12 раздел "Клиенты различных провайдеров с резервным каналом между

Распределение ролей между каналами проводится здесь так же, как и в предыдущем случае, описанном в разделе "Вариант 4: подключение клиентов к одному провайдеру с резервным каналом между ними". Частный канал может выступать только как резервный либо использоваться для обмена трафиком между двумя клиентскими узлами.

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

установить более высокие локальные предпочтения для маршрутов в AS2, поступающих от провайдера ISP2, чем для маршрутов в AS2, поступающих из AS1. Таким образом, при нормальных условиях провайдер ISP1, чтобы достичь AS2, будет использовать соединение с провайдером ISP2. Те же условия действительны и для ISP2 в отношении AS1.

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

Для внедрения  нужных правил  маршрутизации вы можете использовать  два подхода. Первый — заключается в строгой координации между провайдерами и их клиентами. Он основан на работе с сообществами BGP. Второй подход — управление атрибутом AS_PATH. Его намного легче реализовать, но не все производители оборудования и программного обеспечения поддерживают работу с ним. Управление атрибутом AS_PATH также может потребовать координации между провайдером и клиентами, если на узле провайдера используются фильтры атрибута AS   PATH.

Подход с использованием атрибута COMMUNITY

Подход с использованием атрибута COMMUNITY доказал свою высокую эффективность. Провайдеры требуют преобразования значений атрибута COMMUNITY в соответствующие значения локальных предпочтений (как оговорено в RFC 1998). Провайдер автоматически будет назначать обновлениям маршрутов, поступающим от клиентов, соответствующие значения локальных предпочтений.

Чтобы обеспечить в этой схеме определенный уровень управления, нужно принять

только маршрутизацию и правила от провайдера ISP1. То же самое будет справедливо и в отношении ISP2. Поток трафика в случае, приведенном на рис. 7.21, можно разбить как минимум на три части.

В  зависимости  количества  соединений  между  клиентом  и  провайдером,  можно

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

Образцы потоков, с точки зрения ISP1, выглядят следующим образом.

·              Образец 1 – маршруты, сгенерированные клиентской AS1, или локальные маршруты клиента.

·              Образец 2 – транзитные маршруты через AS1. Эти маршруты поступают от AS2 и включают в себя все остальные маршруты, которые AS2 получает  от 1SP2. Эту информацию использует ISP1 для того, чтобы попасть в AS2 через AS1 в случае отказа канала между провайдеро*Г15Р2 и AS2. Этот образец трафика относится к так называемым транзитным клиентским маршрутам.

·              Образец 3 — все остальные маршруты, поступающие от ISP2, или маршруты 1SP. К ним относятся маршруты, полученные от AS2.

Разделив все маршруты по категориям, провайдер ISP1 будет назначать значения атрибутов COMMUNITY для каждого образца трафика и динамически транслировать их в локальные предпочтения. Подобное преобразование приведено в табл. 7.5.

Рис. 7.21. Использование атрибута COMMUNITY

Таблица 7.5. Динамическое преобразование в локальные предпочтения

Образец                                                    Атрибут COMMUNITY      Локальное предпочтение

Локальные клиентские маршруты Транзитные клиентские маршруты Маршруты ISP

Нет

400:40

400:60

100

40

60

Провайдер ISP1 будет информировать своих клиентов и взаимодействующих с ним провайдеров о том, что его локальные предпочтения динамически устанавливаются согласно табл. 7.5. Клиенты, в свою очередь, могут динамически влиять на принятие решений путем пересылки соответствующих значений атрибута COMMUNITY. Как видно из рис. 7.21, AS1 будет посылать свои локальные маршруты без атрибута COMMUNITY и транзитные маршруты со значением COMMUNITY 400:40. Провайдер ISP2 в этом случае будет свои маршруты посылать со значением COMMUNITY 400:60.

В соответствии с предпочтениями, полученными в табл. 7.5, провайдер ISP1 предпочитает работать с локальными маршрутами ASI через прямой канал (так как он имеет наивысшее значение предпочтения 100). Все остальные маршруты, включая маршруты от AS2, будут обслуживаться через ISP2 (предпочтение 60 больше 40).

См. в главе 12 раздел "Управление маршрутами с помощью атрибута COMMUNITY"

Подход с использованием атрибута AS_PATH

Этот  подход  в  точности  совпадает  с  тем,  который  уже обсуждался  для  случая

подключения к различным провайдерам по нескольким каналам в разделе "Входящий трафик клиента (Управление атрибутом AS_PATH)". Используя этот подход, можно эффективно воздействовать на принятие провайдерами решений об использовании того или иного маршрута. На рис. 7.22 представлен пример сети, в которой при маршрутизации используется управление атрибутом AS_PATH.

Рис. 7.22. Пример управления атрибутом AS_PATH

Предположим, что все атрибуты локальных предпочтений имеют значение по умолчанию, т.е. одинаковы и не "перекрывают" действие атрибута AS_PATH. В этом случае атрибут AS_PATH будет изменяться таким образом, чтобы ISP1 использовал прямое соединение с AS1 для трафика, адресованного  в AS1, и прямое соединение с ISP2 для трафика, адресованного ISP2. Причем эти решения будут приняты на основании кратчайшего маршрута (наименьшего AS_PATH).

Для трафика, предназначенного AS2, у ISP1 есть два равнозначных маршрута: через

ISP2 и AS1. Значение AS_PATH у провайдера JSP1 через AS1 для AS2 равно 1 2, а для маршрута через ISP2 — 500 2, т.е. они имеют одинаковую длину.

Чтобы повлиять на принятие провайдером ISP1 решения, в AS1 необходимо увеличить длину AS_PATH при объявлении маршрутов ISP1 путем добавления дополнительного номера AS в список AS_PATH. Как правило, AS1 просто повторно указывает собственный номер AS. Новый атрибут AS_PATH для провайдера ISP1 от AS2 будет равен 1 1 2, т.е. длиннее маршрута через ISP2 500 2. В результате, чтобы попасть в AS2, провайдер ISP1 будет использовать ISP2.

Источник: Сэм Хелеби, Денни Мак-Ферсон, Принципы маршрутизации в Internet, 2-е  издание.  : Пер. с англ. М. : Издательский дом «Вильямс», 2001. — 448 с. : ил. — Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100