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

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

На маршрутизаторах RTA и RTF поддерживается для внутреннего обмена протокол

IBGP, а для работы с провайдером AS1 — протокол EBGP. Маршрутизатор RTG является внутренним и поддерживает только протокол OSPF. Предположим, что маршрутизаторы RTA и RTF должны в направлении AS1 посылать MED для достижения следующих целей.

Пересылать входящий трафик для сети 172.16.1.0/24 по каналу SF.

Входящий трафик для остальных сетей пересылать с применением граничного маршрутизатора, который обладает информацией о маршрутах в эти сети с меньшими внутренними метриками. Например, входящий трафик в направлении сети 172.16.112.0/24 должен пересылаться по каналу SF, если у RTA есть маршрут с меньшей метрикой к этой сети, чем у RTF.

Рис. 11.8. Установка атрибута MED

В листингах 11.45 и 11.46 показаны конфигурации маршрутизаторов RTA и RTF, удовлетворяющие указанным критериям.

Листинг 11.45. Установка атрибута MED - конфигурация маршрутизатора

RTA

router ospf 10 passive-interface SerialO

network 172.16.0.0 0.0.255.255 area 0

router bgp 3

no synchronization

network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0 network 172.16.112.0 mask 255.255.255.0 neighbor 172.16.1.2 remote-as 3

neighbor 172.16.1.2 update-source LoopbackO neighbor 172.16.20.1 remote-as 1

neighbor 172.16.20.1 filter-list 10 out no auto-summary

ip as-path access-list 10 permit A$

Листинг 11.46. Установка атрибута MED — конфигурация маршрутизатора RTF

router ospf 10

network 172.16.0.0 0.0.255.255 area 0

router bgp 3

no synchronization

network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0 network 172.16.112.0 mask 255.255.255.0 neighbor 172.16.2.254 remote-as 3 neighbor 172.16.2.254 next-hop-self neighbor 192.68.5.2 remote-as 1

neighbor 192.68.5.2 route-map SETMETRIC out neighbor 192.68.5.2 filter-list 10 out

no auto-summary

ip as-path access-list 10 permit A$ access-list 1 permit 172.16.1.0 0.0.0.255

route-map SETMETRIC

permit 10 match ip address 1 set metric 50

route-map SETMETRIC permit 20

Маршрутизатор RTF, сконфигурированный, как показано в листингах 11.45 и 11.46, будет генерировать префикс 172.16.1.0/24 с MED равным 50. Получив сведения об этом префиксе, ASI сравнивает метрику 50 с метрикой 0, поступающей от маршрутизатора RTA, и, естественно, будет задействовать канал SF. Все остальные сети будут объявляться в BGP с внутренними метриками, и AS1 будет выбирать ту точку входа, которая обладает наименьшей метрикой. В листинге 11.47 представлена BGP-таблица на маршрутизаторе RTD после внесения описанных изменений.

Листинг 11.47. BGP-таблица на маршрутизаторе RTD

Посмотрите как в таблице BGP-маршрутов, приведенной в листинге 11.47, выбирается маршрут в сеть 172.16.1.0/24 через узел 192.68.6.2, т.е. через маршрутизатор RTC (он использует самого себя как следующий узел с помощью команды next-hop-self). Этот маршрут выбирается благодаря тому, что имеет меньшую метрику (0 меньше 50). Для всех остальных сетей маршрутизатор RTD также будет использовать маршруты с наименьшими метриками. Обратите внимание, что сведения о сети 172.16.112.0/24 получены от маршрутизатора RTA по маршруту с метрикой 74, а от маршрутизатора RTF — с метрикой 84. Таким образом, чтобы доставить данные в сеть 172.16.112.0/24, маршрутизатор RTD будет передавать их по каналу SF.

Для маршрутов, сведения о которых были получены посредством BGP, имеется возможность пересылки в другую AS с внутренними метриками IGP, перенесенными при преобразовании маршрутов в BGP-маршруты. Это выполняется с помощью команды set metric-type internal, которая описывает часть карты маршрутов в направлении соседнего узла. Таким образом, BGP-маршруты будут переносить в атрибуте MED информацию о внутренних метриках протокола IGP.

Атрибут COMMUNITY

Этот раздел посвящен атрибуту COMMUNITY, с помощью которого можно динамически влиять на процесс принятия решения о выборе маршрута в другой AS. Для обеспечения работы сети, представленной на рис. 11.9, в листинге 11.48 показан пример конфигурации маршрутизатора RTA, в котором AS3 объявляет маршрут в сеть 172.16.65.0/26 автономной системе AS1 и динамически инструктирует ее о запрете на объявление этого маршрута другим AS. Для этого при объявлении маршрута 172.16.65.0/26 в AS1 в системе AS3 ему присваивается атрибут COMMUNITY со значением no-export.

Рис. 11.9. Установка атрибута COMMUNITY

Листинг 11.48. Конфигурация маршрутизатора RTA с использованием атрибута COMMUNITY

router bgp 3

no synchronization

network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0

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

Впримере конфигурации, представленном в листинге 11.48, описана карта маршрутов SETCOMMUNITY в направлении соседнего узла 172.16.20.1 (RTC). Запись в карте маршрутов с номером 10 будет обрабатывать префикс 172.16.65.0/26 и устанавливать атрибут COMMUNITY в no-export. Ключевое слово send-community необходимо задавать при сеансе связи с соседним узлом, что позволяет пересылать указанному узлу атрибут COMMUNITY. В записи карты маршрутов под номером 20 разрешается передавать сведения обо всех остальных сетях без изменений.

Влистинге 11.49 показана BGP-запись на маршрутизаторе RTC для сети

172.16.65.0/26.

Листинг 11.49. Вывод сведений о BGP-маршруте в сеть 172.16.65.0/26

RTC#show ip bgp 172.16.65.0 255.255.255.192

BGP routing table entry for 172.16.65.0/26, version 3 Paths: (1 available, best #1, not advertised to EBGP peer)

3

172.16.20.2 from 172.16.20.2 (172.16.2.254) Origin IGP, metric 20, valid, external, best Community: no-export

Как видите, в атрибуте COMMUNITY было задано значение no-export, что не позволяет передавать данное обновление маршрутов на другие EBGP-узлы. Таким образом, маршрутизатор RTC не будет объявлять этот маршрут своему внешнему соседу —

маршрутизатору RTC. Следует отметить, что в таблице BGP-маршрутов на маршрутизаторе RTD, представленной в листинге 11.50, нет сведений о маршруте в сеть 172.16.65.0/26.

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

Агрегация в BGP-4

В приведенных ниже примерах описываются различные методы агрегации (объединения) маршрутов, которые вы можете встретить в сети Internet. Способ формирования и объявления объединенных маршрутов, а также то, распространяются ли они самостоятельно или совместно с однозначно определенными маршрутами, будет влиять на потоки трафика в сети и на размер маршрутных BGP-таблиц. Помните, что объединяются только те маршруты, сведения о которых есть в маршрутной BGP-таблице. Объединенный маршрут может посылаться другим узлам, если в таблице BGP-маршрутов присутствует по крайней мере один однозначно определенный маршрут.

Только объединенные маршруты, подавление однозначно определенных маршрутов

В этом разделе мы покажем, как сгенерировать объединенный маршрут без распространения однозначно определенных маршрутов, которые входят в его состав. В сети, представленной на рис. 11.10, маршрутизатор RTA посылает информацию о префиксах 172.16.220.0/24, 172.16.1.0/24 и 172.16.65.0/26 на маршрутизатор RTC.

Рис. 11.10. Объединение маршрутов в BGP (с подавлением однозначно определенных маршрутов).

В примере конфигурации, приведенном в листинге 11.51, показано каким образ< на маршрутизаторе RTA проводится объединение всех этих маршрутов в один отде^ ный префикс 172.16.0.0/16, который и посылается на маршрутизатор RTC. Таким с разом, мы полагаем, что AS3 является единоличным владельцем сети класса 172.16.0.0/16. На маршрутизаторе RTF выполняется такое же объединение, и его ко фигурация подобна конфигурации маршрутизатора RTA.

Листинг 11.51. Конфигурация маршрутизатора RTA для объединения маршрутов в оди! .префикс с целью их пересылки на маршрутизатор RTC

router bgp 3

no synchronization

network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0

aggregate-address 172.16.0.0 255.255.0.0 summary-only neighbor 172.16.1.2 remote-as 3

neighbor 172.16.1.2 update-source LoopbackO

При настройке маршрутизатора RTA для объединения однозначно определенных маршрутов в один 172.16.0.0/16 используется команда aggregate-address.

В таблице BGP-маршрутов на маршрутизаторе RTA (листинг 11.52) показано, как генерируется новый объединенный маршрут 172.16.0.0/16. Как видите, этот маршрут сгенерирован на маршрутизаторе RTA (NEXT_HOP 0.0.0.0), а все остальные однозначно

определенные префиксы подавляются (обратите внимание на символ s (т.е. suppressed —

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

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

Из таблицы BGP-маршрутов на маршрутизаторе RTC, представленной в листинге 11.53, видно, что от маршрутизатора RTA получены сведения только о префиксе 172.16.0.0/16. Однако вследствие того, что маршрутизатор RTF выполняет то же объединение маршрутов, RTC получит этот же префикс и от него (через маршрутизатор RTD

в AS2).

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

Рассмотрим более подробно запись об объединенном маршруте 172.16.0.0/16 (листинг 11.54).

Листинг 11.54. Вывод сведений о BGP-маршруте 172.16.0.0 (маршрутизатор

RTC)

RTC#show ip bgp 172.16.0.0

BGP routing table entry for 172.16.0.0/16, version 22 Paths: (2 available, best #1, advertised over EBGP)

3, (aggregated by 3 172.16.2.254)

172.16.20.2from 172.16.20.2 (172.16.2.254)

Обратите внимание на присутствие в записи атрибута ATOMIC_AGGREGATE, который указывает на то, что префикс 172.16.0.0/16 является объединенным. Отметим также выражения aggregated by 172.16.2.254 и aggregated by 192.68.5.1, которые описывают атрибут AGGREGATOR. Атрибут AGGREGATOR (мы его обсуждали в главе 6) несет информацию о номере AS и идентификаторе маршрутизатора ROUTER_ID, который сгенерировал маршрут

— в нашем случае это AS3 и ROUTER_ID — RTA и RTF.

Объединенные маршруты также могут быть сгенерированы статически, как можно видеть по конфигурации маршрутизатора RTA в листинге 11.55 и маршрутизатора RTF в листинге 11.56.

Листинг 11.55. Генерирование объединенных маршрутов с использованием статических маршрутов (конфигурация маршрутизатора RTA)

router bgp 3

no synchronization network 172.16.0.0

neighbor 172.16.1.2 remote-as 3

neighbor 172.15.1.2 update-source LoopbackO neighbor 172.16.20.1 remote-as 1

neighbor 172.16.20.1 filter-list 10 out no auto-summary

ip route 172.16.0.0 255.255.0.0 nullO ip as-path access-list 10 permit A$

Листинг 11.56. Генерирование объединенных маршрутов с использованием

статических маршрутов (конфигурация маршрутизатора RTF)

В листингах 11.55 и 11.56 в таблицу маршрутов вводится статическая запись о статическом маршруте 172.16.0.0/16. Заметьте, что статический маршрут указывает на нулевое устройство null0 (битовую корзину). Если у маршрутизаторов RTA или RTF нет сведений об однозначно определенных маршрутах, которые составляют объединенный маршрут 172.16.0.0, то весь трафик будет игнорироваться. Так предотвращается образование петель маршрутизации, и трафик в RTA и RTF направляется по умолчанию их провайдерам (см. раздел "Бесклассовая междоменная маршрутизация" в главе 3, "IP-адресация и методы распределения адресов").

Объединенные и однозначно определенные маршруты

В некоторых случаях в дополнение к объединенному маршруту желательно передавать в соседние AS однозначно определенные маршруты. Как правило, это делается в AS, подключенных по нескольким каналам к одному провайдеру. Тогда AS провайдера, получая сведения об однозначно определенных маршрутах, сможет принимать более обоснованное решение о выборе маршрута. (Вы уже видели, как AS, принимающая различные метрики маршрутов, может соответствующим образом направлять трафик). На рис. 11.11 представлена топология сети, где реализуется этот вариант объединения маршрутов.

Обратите внимание на команду aggregate-address в конфигурации маршрутизаторов RTA и RTF. Эта команда задается без параметра summary-only, так что и объединенный и однозначно определенные маршруты будут объявляться совместно.

В BGP-таблице на маршрутизаторе RTC (листинг 11.59) видно, что RTC получил сведения не только об объединенном маршруте 172.16.0.0/16, но и однозначно определенные маршруты. Маршрутизатор RTD получает ту же самую информацию.

Листинг 11.59. Подключение к одному провайдеру по нескольким каналам

RTF могут инструктировать RTC и RTD не распространять сведения об однозначно определенных маршрутах и посылать на AS4 только объединенный маршрут 172.16.0.0/16. Эта процедура очень эффективно сдерживает рост таблиц маршрутов, так как AS4 получает только сведения об объединенном маршруте. В листинге 11.60 представлена конфигурация маршрутизатора RTF, где выполняется эта процедура. Маршрутизатор RTA будет сконфигурирован аналогично.

Листинг 11.60. Подавление экспорта однозначно определенных маршрутов

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

Из листинга 11.60 видно, что для настройки маршрутизатора RTF используется несколько записей route-map SETCOMMUNITY, с помощью которых описываются однозначно определенные маршруты 172.16.1.0/24, 172.16.220.0/24, 172.16.10.0/24 и