Принципы маршрутизации в Internet. Самое полное описание протокола BGP 4 - Сэм Хелеби

внешняя AS, которая работает через NAP (такая как AS6) и должна передать трафик в сети

AS3.

Листинг 12.29. Таблица BGP-маршрутов на маршрутизаторе RTG

Обратите внимание, что префиксы 172.16.10.0/24 и 172.16.65.0/26 могут быть доступны по каналу NY (маршрут 7 2 3). Префикс 172.16.220.0/24 доступен по каналу SF (маршрут 7 1 3).

Клиенты одного провайдера с резервным каналом между ними

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

В этом примере мы немного изменим роли. На рис. 12.8 показана AS3, которая является провайдером и предоставляет доступ в Internet двум клиентам — AS1 и AS2. Эти клиенты по взаимной договоренности решили использовать каналы друг друга для доступа в сеть Internet в том случае, если один из каналов выходит из строя. В нормальных условиях, когда все каналы исправны, частный канал используется только для обмена трафиком между AS1 и AS2, весь остальной трафик в и из Internet передается по каналам с провайдером AS3.

Предположим также, что и AS1 и AS2 получают полные сведения о маршрутах из сети Internet, т.е. выполняется маршрутизация по полной схеме. Тогда AS1 и AS2 должны объявлять свои маршруты в AS3, так как для обеспечения работы по резервной схеме в AS3 должны быть сведения о том, как попасть в сети AS1 через AS2, и наоборот. Обычно это происходит автоматически, согласно схеме функционирования протокола ВОР. Согласно правилу кратчайшего маршрута, AS1 и AS2 всегда смогут получить доступ к сетям друг друга через частный канал между ними. Чтобы попрактиковаться в установке правил маршрутизации, попытаемся решить эту проблему с использованием атрибута LOCAL_PREF. В листинге 12.30 представлена конфигурация маршрутизатора RTC. Подобным образом следует настроить и маршрутизатор RTD.

Рис. 12.8. Использование частного канала между двумя клиентами в качестве основного

Листинг 12.30. Использование частного канала в качестве основного

(конфигурация маршрутизатора RTC)

router bgp 1

network 192.68.11.0 neighbor 172.16.20.2 remote-as 3 neighbor 172.16.20.2 route-map PREF_FROM_AS3 in neighbor 192.68.6.1 remote-as 2

neighbor 192.68.6.1 route-map PREF_FROM_AS2 in no auto-summary

ip as-path access-list 1 permit _2_

route-map PREF_FROM_AS3 permit 10 match as-path 1

set local-preference 100

route-map PREF__FROM_AS3 permit 20 set local-preference 300

route-map PREF__FROM_AS2 permit 10 set local-preference 200

В примере конфигурации, представленном в листинге 12.30, описывается карта маршрутов PREF_FROM_AS2, с помощью которой все маршрутам, поступающим от AS2 присваивается локальное предпочтение 200. Другая карта маршрутов — PREF_FROM_AS3 присваивает всем маршрутам от AS3 локальное предпочтение 300. Вы уже, вероятно, обратили внимание на нормальное выражение вида _2_, которое указывает на маршруты, прошедшие через AS2. Согласно этой конфигурации, сведения обо всех сетях, поступающие от AS2 или ее клиентов, будут передаваться по частному каналу. Все остальные сведения о маршрутах будут передаваться через провайдера AS3. В листинге 12.31 представлена таблица BGP-маршрутов на маршрутизаторе RTC.

Листинг 12.31. Использование частного канала в качестве основного (таблица

BGP-маршрутов на маршрутизаторе RTC)

Как видите, префиксу 192.68.10.0/24, поступающему от AS3, установлено локальное предпочтение 100, так как его атрибут AS_PATH 3 2 содержит номер автономной системы 2. Всем остальным маршрутам, сведения о которых поступают от AS3, устанавливается локальное предпочтение равное 300.

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

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

Управление маршрутами с помощью атрибута COMMUNITY

На рис. 12.9 клиент AS1 подключается к провайдеру AS4. А клиент AS3 получает доступ в Internet через провайдера AS3. При этом между клиентами AS1 и AS2 имеется частный канал, который используется для обмена трафиком между этими AS. Весь остальной трафик должен передаваться по каналам с соответствующими провайдерами: AS1 -- через AS4, a AS2 — через AS3. В том случае, если частный канал выходит из строя, клиенты должны иметь возможность обмениваться между собой трафиком через сеть Internet. Если у одного из клиентов выходит из строя канал связи с провайдером, то он может через частный канал воспользоваться соединением с Internet другого клиента.

Рис. 12.9. Несколько AS, подключенных к различным провайдерам

В листингах с 12.32 по 12.34 показаны соответствующие конфигурации маршрутизаторов RTA, RTC и RTF. Маршрутизатор RTD должен быть зеркальным отражением RTC.

Листинг 12.32. Использование частного канала между двумя AS, подключенных к различным провайдерам, с применением атрибута COMMUNITY (конфигурация маршрутизатора RTA)

router bgp 4

network 172.16.220.0 mask 255.255.255.0 neighbor 172.16.1.2 remote-as 3

neighbor 172.16.1.2 route-map CHECK_COMMOKITY in neighbor 172.16.20.1 remote-as 1

neighbor 172.16.20.1 route-map CHECK_COMMUNITY in no auto-summary

ip community-list 2 permit 4:40 ip community-list 3 permit 4:60

route-map CHECK_COMMUNITY permit 10 match community 2

set local-preference 40

route-map CKECK__COMMUNITY permit 20 match community 3

set local-preference 60

route-map CHECK__COMMUNITY permit 30 set local-preference 100

Итак, как видите, на маршрутизаторе RTA создана карта маршрутов СНЕСК_ COMMUNITY. Согласно этой карте маршрутов, атрибут COMMINUTY проверяется на соответствие списку (команда match community) значений, представленных с помощью команды ip community-list. В карте маршрутов описывается следующее.

Запись 10 — для всех маршрутов со значением COMMUNITY 4:40 установить локальное предпочтение 40.

Запись 20 — для всех маршрутов со значением COMMUNITY 4:60 установить локальное предпочтение 60.

Запись 30 — для всех остальных маршрутов установить по умолчанию локаль ное предпочтение 100.

Листинг 12.33. Использование частного канала между двумя AS, подключенных

к различным провайдерам, с применением атрибута COMMUNITY (конфигурация маршрутизатора RTC)

Давайте рассмотрим карту маршрутов setcommunity, которая создана для обслуживания маршрутов, поступающих от AS4. В этой карте маршрутов устанавливается следующее.

Запись 10 — для всех маршрутов, прошедших через AS2 (_2_) установить атрибут COMMUNITY 4:40.

Запись 20 — все остальные маршруты должны проходить без изменений и не содержать атрибута COMMUNITY.

На маршрутизаторе RTC используется также список фильтров filter-list out, благодаря которому AS4 не получает сведений об AS3 через AS1. Этот фильтр разрешает только обмен маршрутами между AS1 и AS2. Если же канал между AS4 и AS3 выходит из строя, то AS4 не сможет использовать AS1, чтобы отправить информацию о маршрутах в AS3.

Листинг 12.34. Использование частного канала между двумя AS, подключенных к различным провайдерам, с применением атрибута COMMUNITY (конфигурация маршрутизатора RTF)

no auto-summary

route-map setcommunity permit 10 set community 4:60

На маршрутизаторе RTF карта маршрутов setcommunnity, которая используется совместно с BGP-командой neighbor, устанавливает всем маршрутам в направлении AS4

атрибут COMMUNITY 4:60.

Посмотрим, чего же мы добились. Рассмотрим таблицу BGP-маршрутов на маршрутизаторе RTA, приведенную в листинге 12.35.

Листинг 12.35. Использование частного канала между двумя AS, подключенных

к различным провайдерам, с применением атрибута COMMUNITY (таблица

BGP-маршрутов на маршрутизаторе RTA)

Как видите, маршрутизатор RTA динамически установил локальное предпочтение равное 60 для всех маршрутов провайдера AS3. Все маршруты, поступающие от AS2 через AS1, имеют локальное предпочтение 40, а все локальные маршруты AS1 -- 100.

Все маршруты, сгенерированные AS1 (т.е. локальные маршруты клиента), такие как 192.68.11.0/24, AS4 будет направлять прямо в AS1. Маршруты, принадлежащие AS2 (транзитные клиентские маршруты), такие как 192.68.10.0/24, будут передаваться AS4 другому провайдеру, т.е. на AS3. Все остальные маршруты, объявляемые провайдером (маршруты провайдера) в AS4, также будут направляться провайдеру AS3.

Управление маршрутами с помощью атрибута AS_PATH

Вкачестве альтернативы управлению маршрутами с помощью атрибута COMMUNITY вы можете использовать для этой же цели атрибут AS_PATH (см. рис. 12.9). Поскольку LOCAL_PREF является нетранзитивным атрибутом, управляя маршрутами с помощью AS_PATH, можно повлиять на процесс принятия решений о выборе маршрута не только в двух взаимодействующих AS, но и в других AS.

Влистинге 12.36 показано, как маршрутизатор RTC будет добавлять во все маршруты, полученные от AS2, дополнительную запись об AS в обновления маршрутов, посылаемые на AS4, Система AS4, анализируя атрибут AS_PATH, обнаружит обновления маршрутов с более длинным AS_PATH через AS1 и будет пересылать их далее на AS3.

Листинг 12.36. Управление маршрутами с помощью атрибута AS_PATH

(конфигурация маршрутизатора RTC)

route-map setpath permit 10 match as-path 2

set as-path prepend 1

route-map setpath permit 20

Как видите, маршрутизатор RTC добавил еще один номер AS 1 в обновления маршрутов, посылаемые на RTA. В листинге 12.37 показано, как будет выглядеть после этих манипуляций таблица BGP-маршрутов на маршрутизаторе RTA.

Листинг 12.37. Управление маршрутами с помощью атрибута AS.PATH :

(таблица BGP-маршрутов на маршрутизаторе RTA)

Обратите внимание: теперь, чтобы попасть в сеть 192.68.10.0/24, на маршрутизаторе RTA будет выбираться маршрут через AS3. Вам следует позаботиться о том, чтобы . провайдер в AS1 не использовал списков разрешения доступа на основе анализа атрибута AS_PATH и принимал сведения о маршрутах только от вашей AS в форме Л1$ или Л1 2$. В противном случае добавление номеров AS в AS_PATH может привести к тому, что провайдер отфильтрует ваши маршруты. Еще раз подчеркиваем: всегда согласовывайте подобные действия со своим провайдером.

Установка маршрутов по умолчанию

В последующих примерах мы покажем, как граничные маршрутизаторы преобразуют маршруты по умолчанию внутри вашей AS. Эти маршруты затем используются при организации работы по протоколу IGP. На рис. 12.10 показана следующая схема: AS3 подключена по нескольким каналам к двум провайдерам — AS1 и AS2. Между маршрутизаторами RTA и RTC, а также между RTF и RTD поддерживается протокол EBGP. Внутри AS3 маршрутизаторы RTA и RTF взаимодействуют по протоколу IBGP. Мы рассмотрим два варианта. Первый: RTA и RTF имеют между собой непосредственное физическое соединение. Второй: они работают через посредника. Последний вариант приведен, чтобы показать последствия, к которым может привести неправильная установка маршрута по умолчанию или конфликт маршрута по умолчанию с установленными правилами маршрутизации. И наконец, RTG — внутренний маршрутизатор, который поддерживает только работу по протоколу IGP. Этот маршрутизатор, чтобы получить доступ к сетям вне AS2, должен использовать маршрут по умолчанию 0/0.

Вариант с непосредственным соединением между RTA и RTF довольно прост. Здесь очень сложно сделать что-нибудь неправильно. Пока оба маршрутизатора выдают сведения об IGP-маршрутах по умолчанию, трафик, попавший на любой из этих BGP-узлов, найдет свой маршрут из AS во внешний мир. Важно отметить, что исходящий трафик, поступивший на BGP-маршрутизатор, во избежание образования петли не должен возвращаться на маршрутизаторы, которые не поддерживают BGP.

Рис. 12.10. Установка маршрутов по умолчанию внутри AS (граничные маршрутизаторы имеют непосредственное соединение между собой)

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

— в качестве резервного. Несмотря на используемые правила маршрутизации трафик все равно найдет путь наружу.

В примерах конфигурации, представленных в листингах 12.38 и 12.39, маршрутизаторы RTA и RTF получают полные сведения о маршрутах от своих провайдеров. Затем они посылают в свою AS сведения о маршрутах по умолчанию (сами они не получают маршрутов по умолчанию, так как имеют полные сведения о маршрутах в сети Internet). В качестве протокола IGP здесь используется протокол OSPF (варианты применения других протоколов 1GP мы рассмотрим позднее). Обратите внимание на присутствие в обоих конфигурациях субкоманды OSPF default-information originate.

Листинг 12.38. Установка маршрутов по умолчанию внутри AS с помощью граничных маршрутизаторов, соединенных между собой физически (конфигурация маршрутизатора RTA)

router ospf 10 passive-interface SerialO

network 172.16.8.9 8.0.255.255 area 0 default-information originate always

router bgp 3

no synchronization

network 172.16.1.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 network 172.16.220.0 mask 255.255.255.0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 filter-list 10 out neighbor 172.16.1.2 remote-as 3

no auto-summary

ip as-path access-list 10 permit A$

Листинг 12.39. Установка маршрутов по умолчанию внутри AS с помощью

граничных маршрутизаторов, соединенных между собой физически (конфигурация маршрутизатора RTF)

router ospf 10

network 172.16.0.0 0.0.255.255 area 0 default-information originate always

В листинге 12.40 приведена конфигурация маршрутизатора RTG.

Листинг 12.40. Установка маршрутов по умолчанию внутри AS с помощью

граничных

router ospf 10

network 172.16.0.0 0.0.255.255 area 0

Обратите внимание, что при конфигурации маршрутизаторов RTA и RTF вместе с командой router ospf в субкоманде default-information originate используется ключевое слово always. Так вы принуждаете протокол OSPF в OSPF-домене всегда рассылать маршрут по умолчанию 0/0. При этом внутренний маршрутизатор RTG, который поддерживает только OSPF, получая сведения о маршруте по умолчанию из нескольких источников, будет руководствоваться при выборе маршрута наименьшей метрикой. Маршрутизаторы, которые ближе (согласно метрикам) к RTA будут по умолчанию использовать его в качестве шлюза в Internet, а маршрутизаторы, которые расположены ближе к RTF, будут использовать маршрутизатор RTF.

В таблице IP-маршрутов на маршрутизаторе RTG, представленной в листинге 12.41, показано, как выбирается шлюз по умолчанию. Вы видите, что им оказался маршрутизатор RTA (172.16.70.1), который имеет меньшую метрику, чем RTF.

Листинг 12.41. Установка маршрутов по умолчанию внутри AS с помощью граничных маршрутизаторов, соединенных между собой физически (таблица IPмаршрутов на маршрутизаторе RTG)

RTG#show ip route

Codes: С - connected, S - static, I - IGRP, R - RIP, M - mobile, В - BGP D - EIGRP, EX -• EIGRP external, 0 - OSPF, IA -• OSPF inter area N1 - OSPF NSSA external type 1, N2 •- OSPF NSSA external type 2 El - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i- IS-IS, LI -- IS-IS level-1, L.2 - IS-IS level-2,

*- candidate default U - per-user static route, о - ODR Gateway of last resort is 172.16.70.1 to network 0.0.0.0

172.16.0.0/16 is subnetted, 5 subnets

О172.16.220.0/24 [110/74] via 172.16.70.1, 00:03:27, SerialO С 172.16.50.0/24 is directly connected, Seriall

О172.16.20.0/24 [110/74] via 172.16.70.1, 00:03:27, SerialO

О172.16.1.0/24 [110/74] via 172.16.70.1, 00:03:27, SerialO

С172.16.70.0/24 is directly connected, SerialO

0*E2 0.0.0.0/0 [110/1] via 172.16.70.1, 00:03:27, SerialO

Конфликт между правилами маршрутизации BGP и внутренним маршрутом по умолчанию

Всегда при работе с маршрутами по умолчанию, которые используются для доставки трафика в пункты назначения с неизвестными для данной AS маршрутами, следует соблюдать предельную осторожность, так как имеется потенциальная возможность образования петель маршрутизации. Петля маршрутизации возникает, когда маршругизатор X по умолчанию посылает данные на маршрутизатор Y, который, в свою очередь, использует маршрутизатор X, чтобы доставить их в пункт назначения. Тогда трафик будет передаваться по замкнутому кругу (петле) от X к Y и обратно.

Маршрут по умолчанию 0/0 по-разному преобразуется из BGP в IGP, в зависимости от используемого протокола ЮР. Мы рассмотрим различные варианты такого преобразования для протоколов ЮР — OSPF, RIP, EIRGP, а также IS-IS.

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

Предположим, что в AS3 (рис. 12.11) установлены правила маршрутизации для работы по основному и запасному каналам, где канал NY — основной, a SF — резервный. Тогда маршрутизатор RTA получает сведения о IBGP-маршрутах с более высокими локальными предпочтениями, чем у EBGP-маршрутов, и будет пересыпать трафик взаимодействующему с ним по IBGP узлу RTF. Если же маршрутизатор RTG получает сведения о маршруте по умолчанию 0/0 и от RTA, и от RTF, то он будет выбирать маршрут по умолчанию через маршрутизатор RTF (как основной), в противном случае может возникнуть петля маршрутизации. Приведенная ниже последовательность событий объясняет, почему.

Шаг 1. Маршрутизатор RTG пытается переслать трафик в пункт назначения за пределами AS3.

Шаг 2. Маршрутизатор RTG выбирает маршрут по умолчанию в направлении RTA. Шаг 3. На маршрутизаторе RTA правилами установлено, что в качестве точки выхода из AS нужно использовать маршрутизатор RTF.

Шаг 4. Чтобы переслать трафик на маршрутизатор RTF в качестве следующего промежуточного узла на RTA используется RTG (они ведь не имеют непосредственного соединения).

Шаг 5. Маршрутизатор RTG принимает трафик, адресованный за пределы AS, и посылает его обратно на RTA, т.е. образуется петля.