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

Рис. 9.4. Сравнительная характеристика обеспечения логической и физической избыточности

Нельзя преувеличивать важность дополнения логической избыточности по сравнению с физической избыточностью. Нет смысла обеспечивать избыточность отражателей маршрутов, если отсутствует физическая избыточность, В левой части рис. 9.4 показана схема реализации логической избыточности, где маршрутизатор RTA является клиентом отражателей маршрутов RR1 и RR2, (Здесь и далее отражатели маршрутов будут обозначаться как RR от англ, — route reflector). Маршрутизатор RTA взаимодействует с обоими отражателями маршрутов для создания избыточного соединения. К сожалению, если соединение с отражателем маршрутов RR1 по каким-либо причинам будет разорвано или выйдет из строя отражатель RR1, то маршрутизатор RTA окажется изолированным. Таким образом, в данной схеме логическое соединение RTA и отражателя маршрутов RR2 не имеет практической пользы, оно лишь потребляет больше памяти и создает дополнительную нагрузку на процессор.

В правой части рис, 9.4 представлена схема реализации физической избыточности, в которой можно обеспечить также и физическую избыточность. В случае выхода из строя соединения с отражателем маршрутов RR1 маршрутизатор RTA может работать с RR2.

Модели топологии с элементами отражения маршрутов

Национальные телекоммуникационные сети, как правило, планируются в соответствии с географическими регионами и имеют точки сосредоточения в городах. Провайдеры имеют собственные точки присутствия (Points of Presence — POP), которые также иногда называют хабами (hubs), в различных регионах США с высокоскоростными каналами, соединяющими различные узлы смешанной топологии. Концепция отражателя маршрутов может использоваться, чтобы логически объединять маршрутизаторы под управлением протокола BGP в структуры, соответствующие физической топологии сети. На рис. 9.5 показана комплексная инфраструктура с использованием отражателей маршрутов.

Исключая тот факт, что отражатель маршрутов должен обрабатывать больше IBGPсеансов, чем маршрутизаторы-клиенты, любой маршрутизатор может быть сконфигурирован как отражатель маршрутов. Физическая топология вашей сети определяет, какой маршрутизатор будет наилучшим отражателем маршрутов. Поскольку клиентам не требуется взаимодействовать с большим количеством других IBGP-маршрутизаторов, для обработки соединений по EBGP у него имеется больше свободных ресурсов.

Рис. 9.5. Инфраструктура сети с несколькими отражателями маршрутов

На рис. 9.5 AS100 разделена на три кластера: Сан-Франциско, Даллас и Нью-Йорк. Кластер Далласа в целях обеспечения избыточности имеет несколько отражателей маршрутов. Маршрутизаторы RTA и RTD физически соединяют Сан-Франциско и НьюЙорк. При выборе отражателей маршрутов имеет смысл просто следовать физическому потоку трафика, так что маршрутизаторы RTA и RTD являются наилучшими кандидатами на эту роль в кластере Далласа.

В Сан-Франциско маршрутизатор RTC обеспечивает физическое соединение с Далласом, так что именно он и будет наилучшим кандидатом для отражателя маршрутов. То же самое справедливо и для кластера Нью-Йорка: маршрутизатор RTE физически соединяет Нью-Йорк с Далласом и, следовательно, является наилучшим кандидатом для работы в качестве отражателя маршрутов.

Отражатель маршрутов и IBGP-атрибуты

Концепция использования отражателя маршрутов не влияет на работу по протоколу IBGP, т.е. отражатель маршрутов не может изменять атрибуты отражаемых IBGPмаршрутов. Например, атрибут NEXT_HOP остается неизменным, когда два отражателя маршрутов обмениваются IBGP-маршрутом. Это необходимо, чтобы избежать образования петель внутри AS.

На рис. 9.6 показано, почему отражатель маршрутов не должен модифицировать атрибуты. В качестве примера приводится атрибут NEXT_HOP. Здесь представлен элемент сети, объединяющий Даллас и Сан-Франциско.

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

Рис. 9.6. Отражатель маршрутов сохраняет информацию об IBGP-атрибутах

Предположим, что маршрутизатор RTB указан в качестве отражателя маршрутов раньше, чем маршрутизатор RTA, и между маршрутизаторами RTB (2.2.2.2) и RTC (1.1.1.1) установлен lBGP-сеанс. Это выглядит не совсем правильно, так как трафик физически проходит через маршрутизатор RTA, в то время как RTB лишь отражает BGP-маршруты между RTA и RTC. Маршрутизатор RTB будет получать префикс 192.213.11.0/24 от своего соседа по IBGP-маршрутизатора RTC с адресом RTB следующего узда (1.1.1.1). Маршрутизатор RTB будет отражать маршрут своему клиенту-маршрутмзатору RTA также с адресом следующего узла (1.1.1.1). Это стандартное и наиболее желательное отражение маршрутов.

С другой стороны, если маршрутизатор RTB изменит IP-адрес следующего узла на свой IP-адрес (2.2.2.2), то RTA попытается использовать RTB, чтобы попасть в сеть 192.213.11.0/24. В результате между маршрутизаторами RTA и RTB возникнет петля, так как RTA будет использовать в качестве следующего узла RTB. Вследствие этого маршрутизатор будет пересылать трафик обратно RTA, чтобы доставить его в конечный пункт назначения. Эта гипотетическая ситуация служит примером того, почему отражателю маршрутов нельзя изменять IBGP-атрибуты.

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

Как избежать образования петель маршрутизации

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

С введением в вашу сеть отражателей маршрутов опасность образования петель маршрутизации внутри AS возрастает. Сообщение об обноааении маршрутов, которое покинуло кластер, может повторно в него поступить. Петли внутри AS не могут быть обнаружены традиционным методом с использованием AS_PATH, так как обновления

маршрутов не имеют подписи AS, сгенерировавшей атрибут. Таким образом, при использовании отражателей маршрутов в BGP можно использовать два дополнительных атрибута, с помощью которых можно избежать образования петель внутри AS, —

ORIGINATOR_ID и CLUSTER_LIST.

Применение атрибута ORIGINATORJD

Атрибут ORIGINATOR_ID представляет собой четырехбайтовый необязательный нетранзитивный атрибут BGP (код типа 9). В этом атрибуте переносится информация об идентификаторе маршрутизатора ROUTER_ID, который сгенерировал маршрут в локальной AS, и добавляется в сообщение UPDATE отражателем маршрутов. Если в результате неправильной конфигурации обновление поступает обратно на сгенерировавший его узел, то оно должно быть отвергнуто эти узлом.

Атрибут CLUSTER_LIST

Атрибут CLUSTER_LIST является необязательным нетранзитивным атрибутом BGP (код типа 10). Каждому кластеру назначается идентификатор CLUSTER_ID.

Атрибут CLUSTER LIST представляет собой последовательность идентификаторов CLUSTER_ID, в которых содержится маршрутная информация о списке кластеров, через которые прошло сообщение UPDATE. Когда отражатель маршрутов посылает маршрут от своих клиентов неклиентам вне кластера, он добавляет свой локальный CLUSTER_ID в CLUSTER_LIST или создает новый список CLUSTER_LIST, если таковой отсутствует. Если отражатель маршрутов принимает сообщение UPDATE, в CLUSTER_LIST которого уже имеется CLUSTER_ID, то он игнорирует это сообщение. Таким образом, в CLUSTER_LIST реализован механизм предотвращения образования петель маршрутизации внутри AS, в то время как список AS_PATH, который мы обсуждали ранее, предотвращает образование петель для сообщений UPDATE, прошедших через несколько внешних AS.

Более подробно об этом читайте в разделе "Отражатели маршрутов" в главе 12.

Отражатели маршрутов и группы взаимодействующих узлов

Вернемся к главе 6, "Настройка параметров BGP", где в качестве группы взаимодействующих узлов выступает группа соседних BGP-маршрутизаторов, которым заданы одни и те же правила маршрутизации. Ранее отражатели маршрутов могли использоваться только в группах взаимодействия, когда все клиенты внутри кластера соединены по полносвязной схеме. Причины этого лучше всего объяснить на примере. В обычной ситуации с использованием отражателя маршрутов маршрутизатор А получает префикс от маршрутизатора В. Затем маршрутизатор А посылает сообщение UPDATE, содержащее удаленные маршруты (в поле WITHDRAWN ROUTES), обратно на маршрутизатор В для того, чтобы нейтрализовать этот маршрут. Другими словами, маршрутизатор А информирует маршрутизатор В о том, что заданный префикс недоступен через маршрутизатор А. Это предотвращает образование петли маршрутизации, когда маршрутизатор А требует, чтобы префикс был доступен через маршрутизатор В, а В указывает, что префикс доступен через А.

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

Они лишь выполняют соединения по полносвязной схеме между отражателями маршрутов и клиентами (в отличие от организации соединений между клиентами в кластере).

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

Рис. 9.7. Типовая топология сети с применением отражения BGP-маршрутов

С использованием групп взаимодействующих узлов структура AS будет представлять собой систему колец, объединенных по полносвязной схеме. Отражатели маршрутов при этом соединены каждый с каждым, а клиенты должны лишь подключаться к отражателям маршрутов. На рис. 9.7 представлена структура такой сети: каждая выделенная группа узлов представляет собой определенную группу взаимодействующих узлов и кластер отражателя маршрутов. В отличие от этой схемы, на рис. 9.8 представлена структура, которую необходимо реализовать, если отражатели маршрутов не используются.

Рис. 9.8. Полносвязная топология сети

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

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

Конфедерация (confederation)2 -- еще один метод борьбы с полносвязностью IBGP внутри AS. Организовывать конфедерации рекомендуется только в тех случаях, когда в работу по протоколу IBGP вовлечено большое количество узлов, что вызывает лавинообразное нарастание числа JBGP-сеансов на отдельном маршрутизаторе.

См. в главе 12 раздел "Конфедерации"

BGP-конфедерации основаны на концепции, согласно которой AS может разбиваться на несколько более мелких AS. Внутри каждой такой подсистемы AS действительны все правила маршрутизации по IBGP. Например, все BGP-маршрутизаторы внутри подсистемы AS должны быть соединены друг с другом по полносвязной схеме. Так как каждая подсистема AS имеет собственный номер, то они будут взаимодействовать по внешнему протоколу BGP. Однако несмотря на то, что между подсистемами AS используется протокол EBGP, маршрутизация внутри конфедерации напоминает маршрутизацию по IBGP внутри отдельной AS. Другими словами, при пересечении подсистемы AS информация о следующем ближайшем узле, локальные предпочтения и MED сохраняются. Для внешней глобальной сети конфедерация выглядит, как одна отдельная AS.

На рис. 9.9 приведен пример конфедерации.

Рис. 9.9. Пример структуры конфедерации

Здесь AS 100 разделена на две подсистемы AS — AS65050 и AS65060. Теперь вся AS тредставляет собой одну большую конфедерацию, которая идентифицируется номе-эом 100. Все подсистемы AS "невидимы" для внешней сети, и им в принципе можно задавать любые номера. Эти номера вы можете назначать из диапазона частных номе-юв AS (от 64512 до 65534, как это оговорено в RFC I9303) для того, чтобы не использовать уникальные номера AS.

Как уже отмечалось, внутри подсистем AS используется полносвязная схема соединений для работы по IBGP. Протокол EBGP используется для организации работы чежду несколькими подсистемами AS, а также между самой конфедерацией и внешними AS. В конфедерациях относительно легко выявить петли маршрутизации внутри \S, благодаря протоколу EBGP, который поддерживается для обеспечения взаимодей-:твия между подсистемами AS. Механизм применения списка AS в AS_PATH, пре-ютвращаюший образование петель маршрутизации, используется для обнаружения обновлений маршрутов, покидающих одну подсистему AS и пытающихся повторно топасть в эту же подсистему AS. Сообщение об обновлении маршрута, которое по-jTopHO пытается попасть в подсистему AS, где оно сгенерировано, немедленно обна-зуживается, так как подсистема AS "увидит" в AS_PATH собственный номер AS.

Недостатки конфедераций

Основной недостаток при работе с конфедерациями заключается в том, что миграция к ггруктуре конфедерации требует существенной перенастройки маршрутизаторов и внесе-

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

Итак, конфедерация 100 состоит из трех подсистем AS: 65010, 65020 и 65030. Маршрут AS_PATH внутри конфедерации 100 представляет собой последовательность юмеров AS и подсистем AS, через которые пролегает маршрут. В стандартном BGP кратчайший маршрут через AS определяет наилучший путь для передачи трафика. Однако в конфедерации подсистема AS «e влияет на общую длину маршрута через VS. Например, одному префиксу соответствуют два равных по длине маршрута VS__PATH, в каждом из которых, в свою очередь, имеются AS_PATH различной дли-ш от разных подсистем AS, что в результате может привести к неоптимальной мар-ирутизации внутри AS, так как неясно, какой из маршрутов наилучший. Со стороны подсистемы AS 65030 маршрут с AS_PATH

(65010) имеет ту же длину, что и AS_PATH (65020 65010). При этом трафик внутри конфедерации может передаваться по любому из этих маршрутов. Чтобы повлиять на работу системы маршрутизации, можно дополнительно установить соответствующие правила маршрутизации. Например, для того, чтобы маршруту с AS_PATH (65020 65010) предпочесть маршрут с AS_PATH (65010), можно сконфигурировать для них локальные предпочтения.

Рис. 9.10. Внутренняя и внешняя маршрутизация в конфедерации

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

заблуждение те AS, в которых правила маршрутизации основаны на длине атрибута AS_PATH. Чтобы попасть в AS200, AS300, скорее всего, выберет маршрут через конфедерацию 100, так как этот маршрут выглядит короче, чем маршрут через AS400 и AS500. В действительности, конечно же, маршрут через конфедерацию 100 не самый короткий, так как на самом деле придется пересечь три подсистемы AS (65030 65020 65010), в то время как альтернативный маршрут предлагает пересечь только две (AS400 AS500). Однако AS300 никогда не узнает об этом "подвохе", если не будет раскрыта структура конфедерации AS 100.

Обмен маршрутами и принятие решений BGP в конфедерациях

Хотя между подсистемами AS обмен маршрутами проводится посредством протокола EBGP, к ним применимы все правила работы по IBGP в порядке обеспечения действия всей AS как единого домена маршрутизации. При этом внутри AS, наряду со значениями атрибутов MED и LOCAL_PREF, по EBGP передается и атрибут NEXT_HOP.

Согласно алгоритму принятия решения в протоколе BGP, только изменения BGPмаршрутов к внешним конфедерациям можно сравнивать с маршрутами внутри самой конфедерации. Если нет конфедераций, то EBGP-маршруты перекрывают IBGP-маршруты. При использовании конфедераций появляется новая разновидность EBGP-маршрутов -- маршруты между подсистемами AS, которые называют внешними маршрутами конфедерации. В протоколе BGP предпочтение тем или иным маршрутам отдается в следующем порядке:

EBGP-маршруты от конфедерации к другим AS > внешние маршруты конфедерации > IBGP-маршруты.

Следовательно, если имеется два маршрута к одному и тому же пункту назначения:

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

Рекомендуемая структура конфедерации

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

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

На рис. 9.11 показано, что каждая подсистема AS взаимодействует только с одной подсистемой AS. Результат может быть более унифицированным с учетом длины атрибута AS_PATH и схемы обмена маршрутами внутри конфедерации.

Рис. 9.11. Централизация в конфедерации

Конфедерации против отражателей маршрутов

Выбор между использованием конфедераций или отражателей маршрутов —

нелегкая задача. Хотя различные организации эмпирическим путем получили определенные результаты от использования этих схем, компания Cisco рекомендует использовать отражатели маршрутов для обеспечения полносвязности по IBGP в крупных сетях. Реальные схемы доказали, что отражатели маршрутов более гибкие в настройке и обслуживании. С другой стороны, конфедерации могут применяться для обеспечения работы протоколов IGP в отдельно взятой подсистеме AS, независимо от IGP в других подсистемах AS, что помогает избежать нестабильности в крупных AS.

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

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

Ограничение роста IGPинфраструктуры

Необходимость ограничения роста сетей объясняется тем, что в результате бесконтрольного разрастания сети стало трудно управлять протоколами IGP. Причем не имеет значения, имеете ли вы дело с устаревшим RIP версии I или с новейшими протоколами кратчайшего открытого маршрута Open Shortest Path First (OSPF) и взаимодействия промежуточных систем Intermediate System-to-Intermediate System (IS-IS), но рано или поздно вы столкнетесь с проблемой масштабируемости вашей сети. До сих пор в этой главе мы обсуждали отражатели маршрутов и конфедерации с точки зрения решения проблемы управления ростом IBGP. Один из способов управления ростом IGP-инфраструктуры заключается в сегментировании AS между несколькими регионами, в каждом из которых поддерживается работа по определенному протоколу IGP. В свою очередь, отдельные регионы должны объединяться по BGP. При такой схеме построения сети стабильность работы сети в одном регионе не будет влиять на стабильность работы другого.

Какими же критериями при выборе точек сегментирования должны руководствоваться разработчики сетей? Очевидно одно: Internet представляет собой одну огромную сеть, которая не может обслуживаться ни одним из протоколов IGP, поэтому она сегментируется с помощью протокола BGP.

Итак, чем же определяется размер сети? Количеством маршрутизаторов или маршрутов? И какое это количество должно быть? На эти вопросы вы услышите различные ответы, которые в основном зависят от устойчивости к ошибкам протокола IGP, средств, используемых для управления ростом инфраструктуры сети и контроля стабильности, а также того, предоставляет ли BGP-сегментирование больше преимуществ при меньших затратах (в долларах и усилиях), чем средства IGP.

Такие протоколы, как OSPF и IS-IS, предоставляют определенные методы контроля стабильности маршрутов и средства для суммирования маршрутов. Но даже несмотря на все эти возможности, lGP-инфраструктура имеет тенденцию к разрастанию. На сегодняшний день можно ориентироваться на предельный объем таблиц IP-маршрутов порядка 2000-3000 внутренних IGP-маршрутов. При достижении этой границы нужно внимательно проанализировать, не продолжает ли их количество расти. Приведенное нами количество маршрутов не может создавать серьезные проблемы, так как на сегодняшний день транзитные BGP-маршрутизаторы в сети Internet практически без проблем обрабатывают до 75000 маршрутов. Проблемные ситуации возникают вследствие отказов оборудования или нестабильности линий доступа, когда информация о маршрутах не достигает пунктов назначения и они периодически стремятся сойтись в одну точку, что вызывает так называемое "зависание" сети.

Означает ли это, что сети с 3000 IGP-маршрутов нуждаются в сегментировании с помощью BGP? Необязательно. В большинстве случаев реструктуризация самого IGP с использованием технологий сегментирования и суммирования маршрутов может способствовать повышению степени управляемости сети.

Чтобы понять, почему необходима такая осторожность при сегментировании с помощью BGP, следует представлять, какому риску подвергается AS при сегментировании. Основная мощь протоколов IGP, особенно тех, что основаны на анализе состояния канала, заключалась в конвергенции — их способности быстро адаптироваться к изменениям сети. Еще одна сильная сторона IGP заключается в их способности поддерживать определенный уровень избыточности и распределять нагрузку в сети.

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