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

В листинге 12.62 представлена таблица IP-маршрутов на маршрутизаторе RTG. Как видите, на RTG установлен маршрут по умолчанию в направлении к RTF.

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

RTA#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 - OSPP external type 1, E2 -- OSPF external type 2, E - EGP

i- IS-IS, LI - IS-IS level-1, L2 - IS-IS level-2,

*- candidate default U - per-user static route, о - ODR

Gateway of last resort is 172.16.50.1 to network 0.0.0.0

С172.16.50.0/24 is directly connected, Seriall

С172.16.70.8/24 is directly connected, SerialO i*L2 0.0.0.0/0 [115/10] via 172.16.50.1, Seriall

Маршрутизация по правилам

В этом разделе показано, как использовать маршрутизацию по правилам для пересылки трафика на основе IP-адреса источника, а не IP-адреса пункта назначения. На рис. 12.12 показан маршрутизатор RTA, который поддерживает работу по протоколу ВОР с провайдерами AS1 и AS2. На внутренних маршрутизаторах, таких как RTG и RTF, поддерживается только протокол IGP (в данном случае OSPF) и установлены маршруты по умолчанию в направлении RTA.

Рис. 12.12. Вариант организации маршрутизации по правилам

Итак, на маршрутизаторе RTA нужно установить такие правила маршрутизации, чтобы трафик, поступающий через интерфейс S1 от RTG направляйся бы в AS2, если он поступил из сети 172.16.10.0/24. Трафик, поступающий от RTG из сети 172.16.112.0/24, следует направлять в AS1, а в случае выхода из строя канала с провайдером — в AS2. Все остальные IP-адреса источников обрабатывать без изменений. В листинге 12.63 представлена

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

Листинг 12.63. Маршрутизация по правилам (конфигурация маршрутизатора

RTA)

interface EthernetO

ip address 172.16.80.1 255.255.255.0

interface Seriall

ip address 172.16.70.1 255.255.255.0 ip policy route-map CHECK_SOURCE

router ospf 10 passive-interface SerialO passive-interface EthernetO

network 172.16.0.0 0.0.255.255 area 0 default-information originate always

router bgp 3

network 172.16.50.0 mask 255.255.255.0 network 172.16,70.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.112.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.80.2 remote-as 2 neighbor 172.16.80.2 filter-list 10 out no auto-summary

ip as-path access-list 10 permit A$

access-list 1 permit 172.16.10.0 0.0.0.255 access-list 2 permit 172.16.112.0 0.0.0.255

route-map CHECK__SOURCE permit 10 match ip address 1

set ip next-hop 172.16.80.2

route-map CHECK__SOURCE permit 20 match ip address 2

set ip next-hop 172.16.20.1 172.16.80.2

Маршрутизация по правилам используется всегда в отношении входящего интерфейса. Как видите, интерфейс Serial 1 настраивается с помощью команды ip policy route-map map-name. В нашем случае ко всему входящему на интерфейс Serial 1 трафику применяется карта маршрутов CHECK^SOURCE. Эта карта работает следующим образом.

Запись 10 - для всех IP-адресов источника, которые принадлежат сети 172.16.10.0/24, назначить следующим узлом 172.16.80.2. Если узел 172.16.80.2 недоступен, пакет отвергается.

Запись 20 - для всех IP-адресов источника, принадлежащих сети 172.16.112.0/24, установить в качестве следующего узла 172.16.20.1. Если узел 172.16.20.1 недоступен, то попытаться направить трафик на узел 172.16.80.2.

Все остальные IP-адреса обрабатываются как обычно.

Вданном случае маршрутизация по правилам с помощью карт маршрутов позволяет выбирать следующий узел, на который будет пересылаться трафик. Необходимо всегда иметь резервный маршрут. Весь трафик, на который не распространяется действие карт маршрутов, должен обрабатываться без изменений согласно протоколу маршрутизации. Чтобы проиллюстрировать, что мы получили в результате последних манипуляций, на маршрутизаторе RTG мы задали команду traceroute 192.68.10.1 с IP-адресом источника 172.16.112.1. В листинге 12.64 представлена таблица IP-маршрутов на маршрутизаторе RTA.

Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort.

Tracing the route to gateway.aeg-aas.de (192.68.10.1} 172.16.70.1 0 msec 4 msec 4 msec

172.16.80.2 8 msec 4 msec 4 msec

Как видите, вывод результатов выполнения traceroute, представленный в листинге 12.66, демонстрирует, что маршрутизатор RTA выбирает альтернативный следующий узел

172.16.80.2.

Прежде чем приступить к реализации решений на основе маршрутизации по правилам, ознакомьтесь с документацией на вашу версию IOS и уточните, поддерживаются ли те процедуры, которые вы собираетесь использовать, и если — да, то на каком оборудовании. Кроме того, вы можете получить дополнительную информацию по этим вопросам в справочнике по командам Cisco (Cisco Guide Reference), руководстве по конфигурированию (Configuration Guidelines) и в информационных бюллетенях для вашего оборудования и версий программного обеспечения (Release Notes).

Отражатели маршрутов

В этом разделе мы рассмотрим варианты практического применения отражателей мари ipyroB (route reflectors) и групп взаимодействующих узлов (peer groups). На рис. 12.13 представлены маршрутизаторы RTA и RTG, которые формируют кластер отражателя маршрутов, где RTG является отражателем маршрутов. Маршрутизаторы RTF, RTE и RTD формируют еще один кластер, где в качестве отражателя маршрутов используется маршрутизатор RTF. Кроме того, маршрутизаторы RTG и RTF являются частью группы взаимодействующих узлов с названием REFLECTORS. Если существуют другие отражатели маршрутов, то все они должны соединяться по полносвязной схеме с использованием протокола 1BGP. Маршрутизатор RTF помещает всех своих клиентов в группу с именем CLIENTS, где используются общие правила маршрутизации.

Клиенты идентифицируются серверами отражателей маршрутов путем задания !"imic-reflector-client с соответствующим параметром neighbor x.x.x.x. Традиционно ложилось определенное ограничение в IOS, согласно которому необходимо, чтобы .ражение маршрутов между клиентами было запрещено, если они являются членами . ;п ппы взаимодействующих узлов. Однако теперь это ограничение снято. Внутри кла-repa RTF- RTD-RTE поддерживается полносвязная работа по протоколу IBGP, и ".•тенты взаимодействуют только с соответствующим отражателем маршрутов. В листинге 12.67 приведена конфигурация маршрутизатора RTF.

Рис. 12.13. Отражатели маршрутов

Листинг 12.67. Отражатели маршрутов (конфигурация маршрутизатора RTF)

Так как на RTF имеется единственный возможный маршрут за пределы кластера, маршрутизаторы RTE и RTD сконфигурированы как клиенты отражателя маршрутов. Вместе маршрутизаторы составляют так называемый кластер (cluster). Маршрутизаторы RTE и RTD ведут с RTF обычный IBGP-сеанс. Другими словами, клиент может и не знать, что он является клиентом. (Заметим, что это было одно из требований при организации отражения маршрутов -- клиенты не должны знать, что они клиенты). В листингах 12.68—12.70 представлены конфигурации маршрутизаторов RTD, RTG и RTA.

Листинг 12.68. Отражатели маршрутов (конфигурацияi маршрутизатора

RTD)

router bgp 3

no synchronization

network 172.16.90.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor 172.16.30.1 remote-as 3 neighbor 172.16.30.1 next-hop-self neighbor 192.68.20.2 remote-as 2 neighbor 192.68.20.2 filter-list 10 out no auto-summary

ip as-path access-list 10 permit A$

neighbor CLIENTS route-reflector-client neighbor 172.16.25.2 peer-group CLIENTS neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS bgp cluster-id 1000

no auto-summary

Параметр CLUSTER_ID — это специальный номер, идентифицирующий кластер. Каждому кластеру нужно назначить уникальный номер. Это также необходимо, чтобы предотвратить образование петель маршрутизации в том случае, если и RTF, и RTE настроены как отражатели маршрутов в одном кластере. Отметим, что "хорошим тоном" считается назначение CLUSTERED, даже если в кластере используется только один отражатель маршрутов. После задания CLUSTER_ID на маршрутизаторе нельзя добавлять новых клиентов. Следовательно, если вы упустили при конфигурировании одного из клиентов, вам придется удалить всех клиентов из списков, а затем снова создать их и повторно установить CLUSTER_ID. Так что определение CLUSTER_1D во время начальной загрузки маршрутизатора — очень хорошая идея.

Конфедерации

На схеме, представленной на рис. 12.14, показано, как разделить AS3 на две меньших подсистемы — AS65050 и AS65060. Номера подсистем AS выбраны из диапазона частных номеров (64512—65535). В каждой из подсистем AS в качестве протокола IGP используется протокол OSPF. Причем OSPF внутри AS65050 не зависит от OSPF в AS65060, т.е. номера областей, используемые в AS65050, можно повторно использовать в AS65060. Таким образом, вы получаете определенное преимущество по сравнению даже с BGP, если IGP в одной подсистеме AS не зависит от 1GP в другой подсистеме AS.

Рис. 12.14. Конфедерации

Из конфигурации маршрутизатора RTA, приведенной в листинге 12.73, видно, что все его интерфейсы находятся в области OSPF с номером 5. На маршрутизаторе RTA для взаимодействия с RTC в AS1 поддерживается протокол EBGP, а для работы с RTG в AS65050 - протокол IBGP.

Обратите внимание, что на маршрутизаторе RTA субкоманда bgp configuration identifier 3 помогает представить его маршрутизатору RTC как члена конфедерации 3.

Листинг 12.73. Конфедерации (конфигурация маршрутизатора RTA)

router ospf 10 passive-interface SerialО

network 172.16.0.0 0.0.255.255 area 5

router bgp 65050

no synchronization

bgp confederation identifier 3

network 172.16.220.0 mask 255.255.255.0 network 172.16.70.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.70.2 remote-as 65050 no auto-summary

ip as-path access-list 10 permit A$

Как видно из листинга 12.74, на маршрутизаторе RTC при взаимодействии с RTA используется обычный протокол EBGP. С точки зрения RTC, маршрутизатор RTA принадлежит AS3. Он также не имеет сведений о подсистемах AS внутри конфедерации 3. И с маршрутизатором RTH в AS2 RTC также взаимодействует по EBGP.

Листинг 12.74. Конфедерации (конфигурация маршрутизатора RTC)

no auto-summary

Маршрутизатор RTG является граничным для подсистемы AS65050 и взаимодействует с RTF в подсистеме AS65060 по EBGP для конфедераций (confederation EBGP). Кроме того, с маршрутизатором RTA он взаимодействует с помощью протокола IBGP. К тому же RTG является граничным маршрутизатором, который имеет общую с RTA область OSPF 5, а остальные его интерфейсы лежат в области 0. Обратите внимание, что в RTG запрещена обработка данных, поступающих по протоколу OSPF через интерфейс Serial I (passive-interface Serial 1), который к тому же является общим с маршрутизатором RTF. В этом соединении поддерживается только протокол EBGP. В листинге 12.75 приведена конфигурация маршрутизатора RTG.

Листинг 12.75. Конфедерации (конфигурация маршрутизатора RTG)

confederation identifier 3). Чтобы сохранить все атрибуты, такие как LOCAL_PREF и NEXT_HOP, при проведении EBGP-сеанса с AS65060 на RTG используется команда bgp confederation peers 65060. С помощью этой команды EBGP-сеанс для конфедерации с подсистемой AS65060 будет выглядеть как сеанс по протоколу IBGP. С помощью команды

neighbor 172.16.50.1 next-hop-self для маршрутов, поступающих от RTG на RTF, в качестве адреса следующего ближайшего узла будет устанавливаться IP-адрес марш руги затора RTG. Без этой команды адрес следующего ближайшего узла для всех EBGP-маршрутов от AS1 будет посылаться на RTF равным 172.16.20.1, что действительно только при наличии к нему доступа из конфедерации маршрутизаторов в подсистеме AS65060.

Как видно из листинга 12.76, та же конфигурация применяется и на маршрутизаторе RTF, который также является граничным для подсистемы AS65060. Кроме того, RTF является граничным маршрутизатором для областей 0 и 5. Области 0 и 5 в AS65060 абсолютно не зависят от таких же областей в AS65050. Таким образом, оба протокола IGP "защищены" друг от друга посредством BGP. При этом между маршрутизаторами RTE, RTD и RTF поддерживается полносвязная схема взаимодействия с использованием протокола IBGP и группы узлов с именем SUB_AS_65060.

Листинг 12.76. Конфедерации (конфигурация маршрутизатора RTF)

neighbor 172.16.25.2 peer-group SUB_AS_65060 neighbor 172.16.30.2 peer-group SUB_AS_65060 neighbor 172.16.50.2 remote-as 65050 neighbor 172.16.50.2 next-hop-self

Маршрутизатор RTD является граничным для конфедерации 3. Как видно из листинга 12.77, RTD взаимодействует с RTH в AS2 по протоколу EBGP и по полносвязной схеме — с RTE и RTF в подсистеме AS65060. Все интерфейсы маршрутизатора RTD находятся в области 0. На RTD не поддерживается OSPF во внешнем канале с AS2. Вот почему для внешних обновлений, поступающих на RTD, в качестве следующего ближайшего узла следует задать его же, прежде чем распространять эти сведения в направлении RTF и RTE.

Листинг 12.77. Конфедерации (конфигурация маршрутизатора RTD)

Как видно из листинга 12.78, все интерфейсы маршрутизатора RTE лежат в области 5 протокола OSPF, и он поддерживает полносвязную схему IBGP с RTF и RTD.

Листинг 12.78. Конфедерации (конфигурация маршрутизатора RTE)

Как показано в листинге 12.79, маршрутизатор RTH является граничным для AS2 и на нем поддерживается протокол EBGP для обеспечения взаимодействия между AS1 и AS3. При этом RTH не имеет сведений о подсистемах AS в конфедерации 3.

Листинг 12.79. Конфедерации (конфигурация маршрутизатора RTH)

no auto-summary

Теперь давайте рассмотрим несколько фрагментов таблиц BGP-маршрутов. Посмотрите, как на маршрутизаторе RTH отображаются маршруты (листинг 12.80). Это делается через AS1 и через AS3. Как видите, все подсистемы AS "невидимы" для RTH.

Листинг 12.80. Конфедерации (таблица BGP-маршрутов на маршрутизаторе

RTH)

Рассмотрим теперь таблицу BGP-маршрутов на маршрутизаторе RTA, которая представлена в листинге 12.81. Из нее видно, что все подсистемы AS заключены в скобки.