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

определенные трудности при движении с грузом в 20 тонн? Правильно подобрать соответствующую мощность процессора очень важно для нормальной маршрутизации в сети.

Недостаточный объем памяти

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

В терминах протокола BGP, запись с информацией о маршруте состоит из записи в таблице пересылки IP-маршрутов и из соответствующей записи в таблице BGP-маршрутов. Сегодня в таблицах маршрутов сети Internet указывается более 75000 маршрутов, и это число ежемесячно увеличивается. Системы, получающие все маршруты из Internet через одного или нескольких провайдеров, едва справляются с таким объемом информации (если вообще справляются) при наличии 32 Мбайт памяти (для хранения BGP-информации и другой маршрутной информации). Большинство провайдеров старается нарастить объем памяти в своих системах до 96, 128 и даже до 256 Мбайт только для обслуживания маршрутных таблиц. Недостаточный объем памяти очень часто может служить причиной нестабильности, так как маршрутизатор, работавший с недостаточным количеством памяти, в дальнейшем может собирать разрозненную информацию из фрагментированной памяти и стать постоянным (до перезагрузки) источником колебаний маршрутов.

Модернизация и техническое обслуживание сетей

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

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

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

Человеческие ошибки

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

Вот лишь один пример ошибки такого рода. Маршрутизатор может посылать своим соседям BGP-маршрут по умолчанию вида 0.0.0.0. Если вы недостаточно осторожны, трафик может пойти по нежелательному маршруту. Точно так же, как в чьи-то обязанности входит рассылка правильных маршрутов по умолчанию, ваша обязанность -обезопасить себя, т.е. убедиться в том, что вы 'фильтруете любые нежелательные маршруты по умолчанию, или в том, что процесс протекает именно так, как вы предполагали. Список возможных человеческих ошибок достаточно длинный: кто-нибудь может непреднамеренно объявлять чужие сети, провайдер может неожиданно прекратить объявление маршрута к вашей сети или кто-то объединить сети, не подлежащие объединению. Основное правило в этом случае

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

Перегруженность соединений

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

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

Функции по обеспечению стабильности в BGP

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

•Управление маршрутами и аннулирование (очистка) содержимого кэша.

•Обновление BGP-маршрутов.

•Разгрузка BGP-маршрутов.

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

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

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

Компания Cisco Systems предлагает механизм, который называется "мягкой перенастройкой" (soft reconfiguration), позволяющий администраторам изменять значения атрибутов "на ходу", без разрыва TCP-сеанса, или вручную имитировать колебания маршрута. В этом случае кэш маршрутов не подвергается очистке, и влияние на всю систему маршрутизации минимально.

См. в главе 12 раздел "Управление маршрутами и аннулирование содержимого

кэша"

Однако этот метод имеет недостаток, который заключается в установлении немодифицированных маршрутов {по отношению к базе Adj-RIB-In, которая должна быть сбалансирована с Adj-RIB-Out) от заданных узлов и хранении их в локальной памяти маршрутизатора. При использовании мягкой перенастройки на крупных узлах может значительно возрастать потребление ресурсов памяти. Согласно выведенному правилу для хранения каждого маршрута, поступающего от взаимодействующего узла, требуется 250 байт памяти.

Обновление маршрутов в BGP

Недавно было найдено еще одно решение, устраняющее недостаток связанный с повышением потребления памяти при мягкой перенастройке. Этот альтернативный метод называется способностью к обновлению маршрута (mute refresh capability) и основан на правилах ведения переговоров в сеансе BGP-4 (эти вопросы освещены в главе 5, "Протокол граничного шлюза Border Gateway Protocol версии 4") с целью облегчения запроса о повторном объяаае-ниц всех префиксов, полученных от взаимодействующего узла (т.е. его

Adj-RIB-Out).

Разгрузка маршрутов

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

При разгрузке маршруты подразделяются на категории и могут быть нормальными (behaved) либо аномальными (ill behaved). Нормальные маршруты ведут себя с высокой степенью стабильности в течение заданного периода времени. Аномальные маршруты крайне нестабильны даже в течение короткого периода времени и на них должны быть наложены "штрафы" пропорционально ожидаемой нестабильности. Нестабильный маршрут должен подавляться (точнее, просто не объявляться) до тех пор, пока он не стабилизируется.

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

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

Штраф (Penalty) - увеличивающееся числовое значение, которое назначается маршруту каждый раз при его колебании.

Половина "штрафного" времени (Half-life) -- настраиваемое числовое значение, определяющее период времени, в течение которого штраф должен уменьшиться наполовину.

Граница подавления (Suppress limit) — числовое значение, которое сравнивается с величиной штрафа. Если штраф больше, чем граница подавления, то маршрут подавляется.

Граница повторного использования (Reuse limit) -- настраиваемое числовое зна чение, которое сравнивается с величиной штрафа. Если штраф меньше, чем граница повторного использования, то подавление маршрут прекращается.

Подавляемый маршрут (Suppressed route) -- маршрут, который не объявляется, даже если он доступен. Маршрут становится подавляемым, если значение штрафа превышает границу подавления.

"Историческая" запись (History entry) — запись, которая используется для

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

Рис. 10.1. Определение размеров штрафа при разгрузке маршрута

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

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

Обеспечение стабильности внутри AS

Преимущества от разгрузки маршрутов заметны как внутри, так и за пределами автономной системы. Когда BGP-маршруты преобразуются в IGP-маршруты, очень важно, чтобы нестабильность отдельных маршрутов не влияла на внутреннюю маршрутизацию и не приводила к "зависанию" внутри AS. Именно здесь приходит на помошь механизм разгрузки маршрутов. Все маршруты, подверженные колебаниям, будут подавлены и не поступят в AS до тех пор, пока не достигнут определенной степени стабильности. На рис. 10.2 сравниваются сети, в которых наблюдается колебание EBGP-маршрутов, с использованием и без использования разгрузки маршрутов.

На рис. 10.2 маршруты Rl, R2 и R3 транслируются из протокола BGP в IGP и поступают в AS. Стрелки возле маршрута R2, указывающие вверх и вниз, обозначают его колебания. Маршруты передаются по IBGP и/или IGP, в зависимости от того, каким образом администратор выполняет преобразование маршрутов в AS. В любом случае мерцание маршрута R2 создает большую нагрузку на граничный маршрутизатор и на внутренние маршрутизаторы. Система, работающая под управлением протокола IGP, будет наводняться сообщениями об удалении и восстановлении нестабильного маршрута. В случае применения разгрузки маршрутов, аномальные маршруты будут подавляться (по достижении границы подавления) и сведения о них не будут поступать в AS.

Рис. 10.2. Влияние колебаний EBGP-маршрутов на IGP-маршруты

Факторы нестабильности за пределами AS

Благодаря разгрузке маршрутов вы можете не допустить передачу нестабильных EBGP-маршрутов на другие узлы. Эти мероприятия позволяют сократить использование полосы пропускания канала и вычислительных мощностей граничных маршрутизаторов. Если вы являетесь провайдером для нескольких клиентов, то очень важно не нагружать собственную сеть (да и другие сети) нестабильными маршрутами, которые затем будут поступать в сети ваших клиентов. Случай, когда провайдер объявляет сети клиента как часть объединенного маршрута, является исключением. Объединенный маршрут всегда будет стабильным, даже если большинство его элементов нестабильны. Тем не менее вызывает тревогу нестабильность клиентских маршрутов внутри AS провайдера. Когда сеть клиента по каким-либо причинам нельзя объединить (вследствие подключения к нескольким провайдерам или использования адресного пространства, которое не входит в диапазон адресов провайдера), то нестабильные маршруты могут попадать за пределы сети.

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

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

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

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

Рис. 10.3. Разгрузка маршрутов на узле провайдера

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

Предположим, что вы получаете полные маршруты из сети Internet (в настоящее время около 75000) от нескольких провайдеров. Теперь представьте, что 5 % этих маршрутов (около 3750) мерцают каждые 2 минуты. Ваш граничный маршрутизатор попросту не справится с такой нагрузкой.

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

Взаключение хотелось бы отметить, что нестабильность маршрутов в Internet будет

втой или иной степени влиять на работу сети. Обязанность каждого администратора минимизировать колебания своих маршрутов. Это достигается четким представлением о том, что они делают и для чего. Провайдеры также становятся более суровыми к источникам колебаний маршрутов. Некоторые провайдеры, например, применяют жесткие штрафы к маршрутам с длинными масками. Это, возможно, выглядит чрезмерным, однако с каждым месяцем все тяжелее контролировать все, что происходит в Internet. Возникает необходимость в создании своего рода "патруля маршрутизации", который бы следил за нарушителями правил маршрутизации и выписывал им штрафы.

Забегая вперед

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

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

Часто задаваемые вопросы

В— Если я указываю максимальное количество принимаемых от взаимодействую щего узла префиксов, например 100, и разрешаю мягкую перенастройку узла, отразится ли этот лимит на количестве маршрутов, которые могут храниться в памяти (т.е. не больше

100)?

О — Нет. Все маршруты, сведения о которых получены от другого узла, (т.е. в базе Adj-RIB-in еще до применения входных правил маршрутизации) могут храниться в памяти.

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

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

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

О — Нет. Если вы настроите разгрузку маршрутов на своем граничном маршрутизаторе, то ваши маршруты вообще не будут объявляться. Вам нужно найти источник нестабильности IGP-маршрутов.

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

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

В— Являясь провайдером, я не хочу "штрафовать" все префиксы одинаково. Существует ли механизм назначения различным префиксам различных параметров разгрузки?

О— Да. Компания Cisco предлагает вам достаточную гибкость при выборе параметров разгрузки по таким критериям, как префикс IP, AS_PATH или сообщество.

Часть IV. Настройка маршрутизаторов для работы в сетях TCP/IP

В этой части...

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

Глава 12. Настройка эффективных правил маршрутизации в сети

Internet

В предыдущих частях мы рассмотрели концепции и схемы маршрутизации, не останавливаясь на настройке оборудования. В главах 11 и 12 вы найдете примеры конфигураций для большинства рассмотренных нами ранее в частях II и III концепций и процедур. В главе 11 основное внимание уделяется настройке BGP-атрибутов. А в главе 12 мы рассмотрим примеры конфигурации для более сложных схем сети, с которыми наиболее часто придется иметь дело администраторам при определении правил маршрутизации. Однако помните, что вы не сможете просто переложить приведенные нами примеры на ваши собственные правила маршрутизации. Они скорее являются моделями определенных решений для различных схем маршрутизации, с которыми вы можете столкнуться на практике при разработке правил маршрутизации по мере расширения сети. Вам необходимо экстраполироваться и привести эти модели в соответствие с вашей ситуацией.

Ключевые темы этой главы:

Сеанс связи между взаимодействующими маршрутизаторами.

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

Фильтрация маршрутов и управление атрибутами. Обсуждается создание карт маршрутов в ВОР, фильтрация на основе NLRI и на основе атрибута AS_PATH.

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

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

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

Атрибуты протокола BGP. Рассматриваются примеры настройки атрибутов NEXT_HOP, AS_PATH, LOCAL PREFERENCE, MED и COMMUNITY.

Агрегация в BGP-4. Приводятся примеры нескольких вариантов агрегации маршрутов.