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

отправляемым взаимодействующему узлу. На рис. 11.2, маршрутизатор RTD в AS2 объявляет маршрут в сеть 192.68.10.0/24 и посылает его маршрутизатору RTF. Затем маршрутизатор RTF передает сведения о маршруте маршрутизатору RTA по IBGP, который, в свою очередь, будет распространять сведения о нем в AS1. Таким образом, объявляя сеть 192.68.10.0/24, AS3 может стать транзитной.

Рис. 11.2. Идентифицирование и фильтрация префиксов

Чтобы избежать подобной ситуации, на маршрутизаторе RTA можно настроить фильтр, который бы не допускал распространения префикса 192.68.10.0/24 в AS1. В листинге 11.13 показан пример организации такого фильтра на маршрутизаторе RTA.

Листинг 11.13. Фильтр префикса на маршрутизаторе RTA

router bgp 3

no synchronization

neighbor 172.16.1.2 remote-as 3 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 prefix-list 1 out no auto-summary

!

ip prefix-list 1 seq 5 deny 192.68.10.0/24

ip prefix-list 1 seq 10 permit 0.0.0.0/0 le 32

Влистинге 11.13 комбинация команд настройки маршрутизатора neighbor prefix-list

исписка префиксов 1 не дает возможности маршрутизатору RTA распространять сведения о префиксе 192.68.10.0/24 в AS1. В части настроек маршрутизатора, где описывается список префиксов, когда последний используется совместно с BGP-командой neighbor, задается фильтрация исходящих обновлений маршрутов в направлении указанного соседнего узла (обратите внимание на ключевое слово out). Заметьте, что список префиксов 1 заканчивается логическим выражением, которое разрешает распространение всех обновлений маршрутов (permit 0.0.0.0/0 1е 32). Когда с целью фильтрации используются списки префиксов или списки разрешения доступа, если в конце не определено какое-либо действие, то по умолчанию будет применяться логическое выражение "запретить все остальное". Это означает, что маршруты, не соответствующие ранее заданным условиям, будут отвергаться. Вот почему очень важно определить действия по умолчанию. В нашем примере маршрут 192.68.10.0/24 будет запрещен, а все остальные маршруты разрешены к распространению. Для этой цели задание в явном виде выражения "запретить все остальное" (если вам действительно это необходимо) поможет избавиться от головной боли.

Хотя из примера этого и не видно, наиболее распространенная на сегодня практика заключается в подготовке списка маршрутов, которые будут разрешены к распространению,

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

Карты маршрутов (которые ссылаются на списки разрешения доступа, списки

Глава 11. Настройка основных функций и атрибутов BGP

271

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

Применение списков разрешения доступа для фильтрации маршрутов к суперсетям или диапазонов маршрутов — довольно сложное дело, поэтому обычно прибегают к различным хитростям. Предположим, что, например, к марш руги затору RTF на рис. 11.2 подключены различные подсети из диапазона 172.16.Х.Х, а вам необходимо объявить объединенный маршрут только в форме 172.16.0.0/16. Тогда стандартный список разрешения доступа вида: access-list I permit 172.16.0.0 0.0.255.255

работать не будет, так как он разрешает больше, чем вам необходимо. В стандартном списке разрешения доступа анализируется только IP-адрес источника и не проверяется длина сетевой маски. Таким образом, приведенный список разрешения доступа допускает объявление маршрутов 172.16.0.0/16, 172.16.0.0/17, 172.16.0.0/18, 172.16.0.0/24 и т.д.

Чтобы ограничить распространение маршрутов только одним 172.16.0.0/16, необходимо воспользоваться расширенным списком разрешения доступа: access-list access-

list-number	{deny | permit} protocol source source-wildcard destination destination-
wildcard I	mask mas.fc-ivild.card

Этим выражением вы определяете расширенный список разрешения доступа, в котором сопоставление проводится по паре адресов источника и пункта назначения или по адресу источника и маске. На основе этих данных принимается решение о разрешении или запрещении распространения определенного обновления маршрутов. Номер списка разрешения доступа назначается из диапазона между 100 и 199. Если проверка осуществляется по протоколу IP и сопоставление проводится по паре адрес источника —

маска, то строка конфигурации может быть задана в виде:

access-list access-list-number permit ip network-number network- do-not-care-bits mask mask-do-not-care-bits

Например:

access-list 101 permit ip 172.16.0.0 0.0.255.255 255.255.0.0

0.0.0.0

Здесь 0 — это точно совпавший бит, а 1 — незначащий бит.

В приведенном выше расширенном списке разрешения доступа показано, что объединенный маршрут 172.16.0.0/16 будет распространяться лишь потому, что его маска в точности совпадает с 255.255.0.0. А обновление маршрутов, содержащее 172.16.0.0/17. фильтр уже не пропустит.

Вы можете достичь этого и другими путями. Например:

access-list 101 permit ip host 172.16.0.0 host 255.255.0.0

Или использовать список префиксов в качестве фильтра:

ip prefix-list 1 seq 5 permit 172.16.0.0/16

Помните: по умолчанию предполагается, что все, не описанное в правилах, запрещено, если вы не задали обратное.

Идентифицирование и фильтрация маршрутов на основе атрибута AS_PATH

Фильтрация маршрутов на основе информации, которая содержится в атрибуте AS_PATH, довольно удобна, когда требуется фильтровать все маршруты в одной или между

Глава 11. Настройка основных функций и атрибутов BGP

272

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

Давайте снова вернемся к рис. 11.2. Если требуется не допустить чтобы AS3 стала транзитной, то нужно сконфигурировать ее граничные маршрут заторы RTA и RTF так, чтобы они объявляли только локальные сети. Имеются в виду локальные сети, сгенерированные в самой AS. В листинге 11.14 приведена конфигурация маршрутизатора RTA, где выполняются эти действия (подобным образом нужно будет настроить и маршрутизатор RTF).

Листинг 11.14. Как не допустить, чтобы AS3 стала транзитной

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

router bgp 3

no synchronization neighbor 172.16.1.2 remote-as 3 neighbor 172.16.20.1 remote-as 1

neighbor 172.16.20.1 filter-list 1 out no auto-summary

ip as-path access-list 1 permit A$

В листинге 11.14 список разрешения доступа 1, работающий на основе анализа AS_PATH, идентифицирует только те обновления, которые были сгенерированы в AS3. Субкоманда filter-list при фильтрации обновлений маршрутов работает совместно со списком разрешения доступа на основе анализа AS_PATH. В данном примере эта субкоманда применяется к исходящим обновлениям маршрутов (обратите внимание на ключевое слово out). Нормальное выражение вида А$ говорит о том, что атрибут AS_PATH пустой, т.е. не содержит каких-либо данных. Знак вставки (А) указывает на начало атрибута AS_PATH, а символ $ обозначает конец атрибута AS_PATH. Так как все сети, сгенерированные в AS3, будут иметь пустые атрибуты AS_PATH (вспомните, что локальный номер AS не включается в атрибут, пока маршрут не передан другому EBGP-узлу), то они будут объявляться дальше. Все остальные префиксы будут отвергаться.

Если вы хотите убедиться в корректной работе вашего нормального выражения, воспользуйтесь для этого командой EXEC:

show ip bgp regexp regular-expression

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

Примечание

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

Группы взаимодействующих узлов

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

Глава 11. Настройка основных функций и атрибутов BGP

273

Применение групп взаимодействующих узлов показано на рис. 11.3.

Рис. 11.3. Группы взаимодействующих узлов в BGP

Здесь маршрутизатор RTC формирует одинаковые сеансы с маршрутизаторами RTD, RTE и RTH. Вместо того чтобы формулировать и задавать подобные правила отдельно каждому узлу, на маршрутизаторе RTC создается группа взаимодействующих узлов, в которой действуют единые правила маршрутизации для всех узлов, являющихся членами этой группы. В листинге 11.15 приведена конфигурация маршрутизатора для работы в группе.

Листинг 11.15. Настройка группы взаимодействующих BGP-узлов

router bgp 1

neighbor INTERNALMAP peer-group neighbor INTERNALMAP remote-as 1

neighbor INTERNALMAP route-map INTERNAL out

neighbor INTERNALMAP filter-list		1	out
neighbor INTERNALMAP filter-list		2	in
neighbor	172.16.11.1 peer-group	INTERNALMAP
neighbor	172.16.13.1 peer-group	INTERNALMAP
neighbor	172.16.12.1 peer-group	INTERNALMAP
neighbor	172.16.12.1 filter-list		3 in

Конфигурация, приведенная в листинге 11,15, описывает группу узлов с именем INTERNALMAP, в которой содержатся следующие правила маршрутизации. (Отметим, что имя INTERNALMAP мы выбрали произвольно, так что здесь вы совершенно вольны в выборе. Как правило, более практично давать группам имена описательного характера.)

•Используется карта маршрутов с именем INTERNALMAP.

•Задан список фильтров для исходящих обновлений маршрутов (filter list 1).

•Задан список фильтров для входящих обновлений маршрутов (filter list 2).

Эта конфигурация объединяет в группу все соседние узлы внутри AS — маршрутизаторы RTD, RTE и RTH.

Члены группы наследуют все параметры, заданные группе узлов. Члены группы могут быть сконфигурированы таким образом, что правила группы будут "перекрываться", если вносимые изменения не повлияют на исходящие обновления маршрутов. Другими словами, члены группы взаимодействующих узлов могут быть сконфигурированы так, что они будут действовать вопреки заданным в группе правилам, а это может повлиять на входные правила маршрутизации. Так, например, при настройке маршрутизатора RTC задается также список фильтров с номером 3 для обновлений, поступающих от соседнего узла с IP-адресом 172.16.12.1 (RTH). Список фильтров 3 будет "перекрывать" действие входных правил маршрутизации, которые установлены для группы INTERNALMAP в

Глава 11. Настройка основных функций и атрибутов BGP

274

отношении маршрутизатора RTH.

В листинге 11.16 показано, как настроить группу взаимодействующих BGP-узлов с именем EXTERNALMAP на маршрутизаторе RTC с участием внешних взаимодействующих узлов из AS3 и AS2.

Листинг 11.16. Группа взаимодействующих BGP-узлов

router bgp 1
neighbor EXTERNALMAP peer-group
neighbor EXTERNALMAP route-map	SETMED out
neighbor EXTERNALMAP filter-list	1	out
neighbor EXTERNALMAP filter-list 2		in
neighbor 172.16.20.2 remote-as	3
neighbor 172.16.20.2 peer-group	EXTERNALMAP
neighbor 172.16.20.3 remote-as	2
neighbor 172.16.20.3 peer-group	EXTERNALMAP
neighbor 172.16.20.3 filter-list	3	in
ip as-path access-list 1 permit	A$3

В конфигурации, представленной в листинге 11.16, команды neighbor remote-as задаются после команд конфигурации маршрутизатора neighbor peer-group, так как требуется описать несколько различных внешних AS. Обратите внимание, что в этой конфигурации настраивается список фильтров 3, который можно использовать для подавления на узле с IP-адресом 172.16.20.3 (RTF) параметров конфигурации, заданных для входящих обновлений маршрутов.

Два последующих абзаца относятся только к старым версиям IOS. В новых версиях эти ограничения отсутствуют.

Обратите внимание, что внешние BGP-узлы — маршрутизаторы RTA и RTF, которые также входят в группу узлов EXTERNALMAP, принадлежат к одной подсети 172.16.20.0. Это ограничение вводится, чтобы не допустить потерь информации. Поместив внешние взаимодействующие узлы в различные подсети, вы можете спровоцировать маршрутизатор RTC посылать обновления маршрутов на взаимодействующие узлы (RTA и RTF) по неопределенному IP-адресу. При нормальном функционировании EBGP, маршруты при отсутствии непосредственного соединения со следующим ближайшим узлом будут игнорироваться (вспомните, чтобы не допустить этого мы использовали команду ebgpmultihop). Таким образом, будут потеряны и обновления маршрутов.

Еще одно ограничение заключается в том, что группы взаимодействующих узлов не следует составлять из EBGP-узлов, если маршрутизатор между этими узлами действует как транзитный. Если маршрутизатор (RTC) пересылает обновления маршрутов с одного внешнего узла на другой, то помещение внешних узлов в группу может привести к тому, что маршруты будут ошибочно удаляться. Отметим, что список фильтров 1 был задан для того, чтобы разрешить распространение локальных маршрутов AS1 только в направлении соседних узлов RTA и RTF. Таким образом, маршрутизатор RTC не сможет работать как чисто транзитный между RTA и RTF.

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

Источники обновления маршрутов

Как вы уже знаете, маршруты в протокол BGP могут поступать динамически или

Глава 11. Настройка основных функций и атрибутов BGP

275

статически. Выбор способа поступления маршрутов в BGP зависит от количества и стабильности маршрутов.

Динамическое вложение информации в BGP

Рис. 11.4. Вложение маршрутов в протокол BGP

В приведенном ниже примере демонстрируется динамическое вложение маршрутной информации в протокол BGP. Рассмотрим рис. 11.4

Предположим, что AS3 подключена к сети Internet через AS1. Внутри AS3 в качестве протокола IGP используется OSPF, а с ASI она взаимодействует по EBGP. С другой стороны,

уAS3 есть клиент К1, со следующими характеристиками:

•К1 указывает маршрут по умолчанию в направлении AS3;

•К1 объявляет все свои маршруты в AS3 с использованием протокола RIP.

На маршрутизаторе RTF организовано два процесса маршрутизации —OSPF и RIP. Кроме того, маршрутизатор RTF будет только ожидать появления RIP-маршрутов через соединение с К1 и преобразовывать полученные маршруты в OSPF-маршруты. С другой стороны, на маршрутизаторе RTA также запущено два процесса — OSPF и ВОР. Маршрутизатор RTA будет динамически преобразовывать все свои локальные маршруты и маршруты, полученные от своего клиента К1, в BGP-маршруты. Все это видно из листинга 11.17.

Листинг 11.17. Преобразование маршрутов в маршрутизаторе RTF

interface Ethernetl/0

ip address 172.16.65.1 255.255.255.192

interface Etnernetl/1

ip address 172.16.1.2 255.255.255.0

interface Serial2/l

ip address 192.68.5.1 255.255.255.0

router ospf 10 redistribute rip subnets

network 172.16.0.0 0.0.255.255 area 0

router rip

passive-interface Serial2/l network 192.68.5.0

Вконфигурации маршрутизатора RTF вы встретите две новых команды.

passive-interface type number — запрещает пересылку обновлений маршрутов на указанный интерфейс. В приведенном примере при использовании совместно с RIP эта команда не допускает пересылку обновлений RIP-маршрутов на

Глава 11. Настройка основных функций и атрибутов BGP

276

интерфейс S2/1. Это необходимо в том случае, когда несколько клиентов, подключенных к маршрутизатору RTF, не должны "видеть" сети друг друга.

При работе по протоколу OSPF эта команда запрещает передачу пакетов hello на определенный интерфейс, что, в свою очередь, не допускает обмена информацией

о состоянии соединения через этот интерфейс.

redistribute protocol [process-id] осуществляет преобразование (подстановку) маршрутов из одного процесса маршрутизации в другой. В рассматриваемом случае в маршрутизаторе RTF RIP-маршруты преобразуются в OSPF-маршруты (процесс 10). Для команды redistribute существует огромное количество различных расширений (например, subnets). Все эти расширения будут рассмотрены позднее.

Спомощью ключевого слова subnets можно удостовериться, вся ли информация о подсетях была в точности передана процессу OSPF. Это требуется только при вложении маршрутов в протокол OSPF. Подобный случай приведен в листинге 11.18.

Листинг 11.18. Статическое преобразование маршрутов в RIP на маршрутизаторе RTD

interface Ethernetl/1

ip address 192.68.10.1 255.255.255.0

interface SerialO/0

ip address 192.68.5.2 255.255.255.0

router rip redistribute static network 192.68.5.0 network 192.68.10.0 default-metric 1

ip route 0.0.0.0 0.0.0.0 192.68.5.1

Обратите внимание, что маршрутизатор RTD сконфигурирован со статическим маршрутом по умолчанию в направлении маршрутизатора RTF. Для всех пунктов назначения вне сети клиента К1 маршрутизатор RTD будет направлять трафик на RTF. Кроме того, RTD будет также ретранслировать информацию о статическом маршруте по умолчанию во внутренний домен RIP, так что все остальные маршруты могут по умолчанию указывать на AS3. Команда маршрутизатора default-metric задает метрику преобразуемых маршрутов. В этом случае метрика по умолчанию устанавливается равной ], так как имеется всего один промежуточный узел для Маршрута 0/0 и этот маршрут преобразуется в RIPмаршрут. Этот случай описан в листинге 11.19.

Листинг 11.19. Преобразование OSPF-маршрутов на маршрутизаторе RTA

interface EthernetO

ip address 172.16.220.1 255.255.255.0

interface Ethernetl

ip address 172.16.1.1 255.255.255.0

interface SerialO

ip address 172.16.20.2 255.255.255.0

router ospf 10 passive-interface Serial 0

network 172.16.0.0 0.0.255.255 area 0

router bgp 3

redistribute ospf 10 match external 1 external 2 neighbor 172.16.20.1 remote-as 1

no auto-summary

На маршрутизаторе RTA имеется комбинация OSPF-маршрутов, которые

Глава 11. Настройка основных функций и атрибутов BGP

277

принадлежат к AS3 и к другим внешним маршрутам, поступающим из RIP-домена К1. При применении команды маршрутизатора redistribute маршрутизатор RTA будет динамически подставлять все эти маршруты в свой процесс BGP. Отметим, что в маршрутизаторе RTA с этой командой используются также ключевые слова match external I external 2, поскольку протоколом OSPF не предусмотрено вложение внешних маршрутов в BGP, если явно не указано, что он должен это делать. Это было сделано, чтобы избежать образования петель маршрутизации в тех случаях, когда информация о внешних OSPF-маршрутах может быть получена из BGP-маршрутов.

В листинге 11,20 показан фрагмент таблицы IP-маршрутов на маршрутизаторе RTA после выполнения вышеуказанных действий.

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

RTA#show ip route

Codes:С -- connected, S -- static, I - IGRP, R - RIP M -- mobile, В - BGP, D - EIGRP, EX - EIGRP external, О -- 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, L2 - IS-IS level-2,

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

Gateway of last resort is not set

ОЕ2 192.68.5.0/24 [110/20] via 172.16.1.2, 2dl3h, Ethernetl

ОЕ2 192.68.10.0/24 [110/20] via 172.16.1.2, 2dl3h, Ethernetl

В192.68.11,0/24 [20/0] via 172.16.20.1, 2dl3h

172.16.0.0/16 is variably subnetted, 5 subnets, 3 masks

С172.16.2.254/32 is directly connected, LoopbackO

С172.16.220.0/24 is directly connected, EthernetO

С172.16.20.0/24 is directly connected, SerialO

С172.16.1.0/24 is directly connected, Ethernetl

0 172.16.65.0/26 [110/20] via 172.16.1.2, 2dl3h, Ethernetl

Обратите внимание, что в таблице IP-маршрутов маршруты в сети 192.68.10.0/24 и 192.68.5.0/24 описаны как внешние OSPF-маршруты (О Е2). Динамическое преобразование приведет к тому, что маршруты в эти сети будут вложены в BGP. В листинге 11.21 представлен внешний вид таблицы BGP-маршрутов на маршрутизаторе RTC после преобразования.

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

RTCttshow ip bgp
BGP table version is 20, local router ID is 192.68.11.1
Status codes: s suppressed, d damped, h history, * valid, > best,
1 - internal Origin codes: i - IGP, e - EGP, ? – incomplete
Network		Next Hop	Metric	LocPrf	Weight	Path
*>	172.16.1.0/24	172.16.20.2	0	0	3	?
*>	172.16.2.254/32	172.16.20.2	0	0	3	?
*>	172.16.20.0/24	172.16.20.2	0	0	3	?
*>	172.16.65.0/26	172.16.20.2	20	0	3	?
*>	172.16.220.0/24	172.16.20.2	0	0	3	?
*>	192.68.5.0	172.16.20.2	20	0	3	?
*>	192.68.10.0	172.16.20.2	20	0	3	?
*>	192.68.11.0	0.0.0.0	0		32768	i

Обратите внимание, что все маршруты к сетям в AS3, где поддерживается OSPF, становятся BGP-маршругами в AS1. В BGP нужно передавать сведения не обо всех сетях, принадлежащих к вашей AS. Дело в том, что довольно часто внутри AS имеются сети с общедоступными IP-адресами или используются IP-адреса, незарегистрированные официально. Нельзя допустить, чтобы эти данные попадали во внешние сети. Посмотрите, каким образом проводится преобразование в BGP адреса петли 172.16.2,254/32. Провайдеры

Глава 11. Настройка основных функций и атрибутов BGP

278

обычно не разрешают объявление столь длинных префиксов (например, /32) и настаивают, чтобы вы их фильтровали или сами фильтруют их на своих узлах. Это ограничение вводится с целью сдерживания роста глобальных таблиц IP-маршрутов. Нет необходимости и в преобразовании в ВОР сведений о сети 172.16.20.0/24, которая является зоной демилитаризации (demilitarized zone — DMZ). Вот почему совместно с преобразованием маршрутов следует использовать фильтрацию. Благодаря этому вы сможете точно определить маршруты, которые следует объявлять.

Маршрутизатор RTA, сконфигурированный, как показано в листинге 11.22, позволяет выполнить такую фильтрацию.

Примечание

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

Листинг 11.22. Фильтрация преобразуемых маршрутов

router ospf 10 passive-interface SerialO

network 172.16.0.0 0.0.255.255 area 0

router bgp	3
redistribute		ospf	10	match external		1 external 2
neighbor	172.16.20.1			remote-as	1
neighbor	172.16.20.1			route-map BLOCKROUTES out
no auto-summary
access-list	1	permit		172.16.2.254		0.0.0.0
access-list	1	permit		172.16.20.0		0.0.0.255
route-map BLOCKROUTES				deny 10
match ip address			1

route-map BLOCKROUTES permit 20

Фильтрация в листинге 11.22 выполняется с помощью карты маршрутов, которая определяет набор действий, предпринимаемых в случае необходимости анализа ситуации на основе определенного критерия. Критериями в нашем случае является выявление соответствия маршрута на хост 172.16.2.254/32 и к сети 172.16.20.0/24, чтобы не допустить их вложения в BGP. В списке разрешения доступа access-list 1 вы можете найти соответствия этим маршрутам, а команда route-map BLOCKROUTES определяет дальнейшие действия (в нашем случае маршруты должны быть отвергнуты). Вторая запись в карте (20) разрешает преобразование всех остальных маршрутов в BGP. (Если нужно более детальное описание этого процесса, обратитесь к главе 6, где обсуждалась фильтрация).

В листинге 11.23 представлено, как будет выглядеть таблица BGP-маршрутов на маршрутизаторе RTC после фильтрации. Как видите, маршруты на хост 172.16.2.254/32 и в сеть 172.16.20.0/24 отсутствуют.

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

RTC#show ip bgp
BGP table version is 34, local router ID is 192.68.11.1
Status codes: s suppressed, d damped, h history, * valid, > best,
	i -• internal Origin codes: i - IGP, e - EGP, ? – incomplete
Network		Next Hop	Metric	LocPrf	Weight	Path
*>	172.16.1.0/24	172.16.20.2	0	0	3	?
*>	172.16.65.0/26	172.16.20.2	20	0	3	?
*>	172.16.220.0/24	172.16.20.2	0	0	3	?
*>	192.68.5.0	172.16.20.2	20	0	3	?
*>	192.68.10.0	172.16.20.2	20	0	3	?
*>	192.68.11.0	0.0.0.0	0		32768	i

Чтобы лучше контролировать, что преобразуется из ЮР в ВОР вы можете

Глава 11. Настройка основных функций и атрибутов BGP

279

использовать команду network. Команда network — еще один способ отдельно задавать префиксы, которые нужно пересылать по ВОР. С помощью этой команды указывается префикс, который будет пересылаться дальше (адрес сети и ее маска). Например, выражение network 172.16.1.0 mask 255.255.255.0 говорит о том, что должен пересылаться префикс 172.16.1.0/24. С сетями, которые приходятся на опорные связки (типа 255.0.0.0, 255.255.0.0 или 255.255.255.0), указывать маску не обязательно. Так, например, чтобы послать сведения о префиксе 172.16.0.0/16 достаточно выражения network 172.16.0.0. Такого рода сети выводятся в таблице BGP-маршрутов без префикса /х. Например, сеть класса С с адресом 192.68.11.0 может быть записана как 192.68.11.0/24.

Согласно схеме, представленной на рис. 11.4, в конфигурации маршрутизатора RTA будут указаны адреса сетей, преобразуемые в ВОР (листинг 11.24).

Листинг 11.24. Конфигурация маршрутизатора RTA, где задаются адреса сети, требующие преобразования в BGP

router ospf 10 passive-interface SerialO

network 172.16.0.0 0.0.255.255 area 0

router bgp	3
network	172.16.1.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	192.68.5.0
network	192.68.10.0
neighbor	172.16.20.1	reniote-as 1

no auto-summary

В листинге 11.25 показан внешний вид таблицы BGP-маршрутов на маршрутизаторе RTC после выполнения описанных действий.

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

RTC#show		ip bgp	34, local	routerID	is 192.68.11.1
BGP	table	version is
Status codes: s suppressed, d damped, h history, * valid, > best,
	i - internal Origin codes: i - IGP, e - EGP, i - incomplete
Network			Next Hop	Metric	LocPrf	Weight	Path
*>	172.16.1.0/24		172.16.20.2	0	0	3	i
*>	172.16.65.0/26		172.16.20.2	20	0	3	i
*>	172.16.220.0/24		172.16.20.2	0	0	3	i
*>	192.68.5.0		172.16.20.2	20	0	3	i
*>	192.68.10.0		172.16.20.2	20	0	3	i
*>	192.68.11.0		0.0.0.0	0		32768	i

Итак, в BGP преобразуются все маршруты, кроме 172.16.2.254/32 и 172.16.20.0/24. Обратите внимание, что таблица BGP-маршрутов очень похожа на ту, которая была сформирована после преобразования OSPF-маршрутов в BGP-маршруты и применения к ним фильтров. Единственная заметная разница заключается в коде источника i, который ставится в конце записи с информацией о маршруте. Код источника i означает, что источник сведений об этих сетях — внутренний по отношению к AS (в данном случае это протокол IGP). Если вы просмотрите еще раз предыдущий снимок таблицы BGP-маршрутов, сделанный с BGPмаршрутизатора (листинг 11.23), то увидите, что в нем указывается код источника ?, т.е. незавершенный. Это говорит о том, что сведения об этих сетях были получены какими-то другими средствами. Маршруты, поступающие в BGP после преобразования, будут иметь незавершенный код источника, если явно не указано другое.

Команда network действует только в том случае, если заданные в ней префиксы известны маршрутизатору. Другими словами, в BGP невозможно объявлять префиксы вслепую, только на основании того, что они указаны в команде. Прежде чем объявить тот или иной префикс, маршрутизатор сопоставит его с содержимым таблицы IP-маршрутов. Так, в листинге 11.25, если вы задаете команду network 172.16.192.0 mask 255.255.255.0,

Глава 11. Настройка основных функций и атрибутов BGP

280