Перевод RFC 4451

На главную

Network Working Group D. McPherson

Request for Comments: 4451 Arbor Networks, Inc.

Category: Informational V. Gill

AOL March 2006

Вопросы использования атрибута BGP MED

BGP MULTI_EXIT_DISC (MED) Considerations

Статус документа

Этот документ содержит информацию

для сообщества Internet. Документ не задает каких-либо стандартов. Допускается

свободное распространения документа.

Авторские права

Тезисы

Атрибут BGP MULTI_EXIT_DISC (MED) обеспечивает для узлов BGP механизм передачи в соседнюю AS информации об оптимальной точке входа в локальную AS. Хотя использование атрибутов BGP MED возможно в различных сценариях работы, может возникать множество проблем в случаях применения MED в динамических и сложных вариантах топологии.

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

Оглавление

1. Введение ................................................................................................................................................................................ ...... .................... 1

2. Уровни требований ................................................................................................................................................................................... ...1...

2.1. Атрибут MULTI_EXIT_DISC (MED) ......................................................................................................................................... ..... .2

2.2. MED и картошка ............................................................................................................................................................................ ....2...

3. Поведение реализаций протокола ....................................................................................................................................................... ........3

3.1. MULTI_EXIT_DISC является дополнительным непереходным атрибутом ................................................................... ............ 3

3.2. Значение MED и предпочтения ..................................................................................................................................... .................... 3

3.3. Сравнение атрибутов MED из разных AS ........................................................................................................................... ..... .. ...... 3

3.4. Атрибуты MED, Route Reflection и AS Confederations для BGP .............................................................................................. ....3

3.5. Подавление маршрутных осцилляций и MED Churn ....................................................................................................... ....... ......... 4

3.6. Влияние атрибутов MED на эффективность упаковки обновлений ............................................................................... ............. 4

3.7. Временная зависимость выбора маршрутов ........................................................................................................................... ........ 4

4. Вопросы развертывания ..................................................................................................................................................................... ........ 4

4.1. Сравнение атрибутов MED из разных AS ............................................................................................................................... .........4

4.2. Эффекты объединения атрибутов MED ................................................................................................................... ........................ 5

5. Вопросы безопасности ....................................................................................................................................................... ..... ...................... 5

6. Благодарности ......................................................................................................................................................................................... ..... 5...

7. Литература .................................................................................................................................................................. ............................ 5

7.1. Нормативные документы .................................................................................................................................................................. 5...

7.2. Дополнительная литература ............................................................................................................................................................. 5...

1. Введение

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

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

rfc.com.ru

Перевод RFC 4451

2.1. Атрибут MULTI_EXIT_DISC (MED)

Атрибут BGP MULTI_EXIT_DISC (MED), ранее известный как INTER_AS_METRIC, определен в параграфе 5.1.4 документа [BGP4] следующим образом¹:

Дополнительный непереходный атрибут MULTI_EXIT_DISC предназначен для использования на внешних (между AS) соединениях для выбора из множества путей в одну смежную AS. Значение атрибута MULTI_EXIT_DISC представляет собой 4-октетное целое число без знака, которое называют метрикой. При прочих равных из нескольких маршрутов следует выбирать тот, у которого меньше значение метрики. При получении через EBGP атрибут MULTI_EXIT_DISC можно распространять черз IBGP другим узлам BGP в данной AS (см. также параграф 9.1.2.2). Атрибут MULTI_EXIT_DISC, полученный из соседней AS, недопустимо распространять в другие соседние AS.

Узел BGP должен обеспечивать механизм (в соответствии с локальной конфигурацией), позволяющий удалять из маршрутов атрибут MULTI_EXIT_DISC. Если узел BGP настроен на удаление атрибута MULTI_EXIT_DISC из маршрутов, такое удаление должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process).

Реализация может также (в соответствии с локальной конфигурацией) изменять значение атрибутов MULTI_EXIT_DISC, полученных через EBGP. Если узел BGP настроен на изменение значений атрибута MULTI_EXIT_DISC, принятых через EBGP, такое изменение должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process). Некоторые ограничения описаны в параграфе 9.1.2.2.

В параграфе 9.1.2.2 (п. c) документа [BGP4] определяются следующие критерии выбора маршрутов, связанные с MED¹:

c) Исключаются из рассмотрения маршруты с менее предпочтительными атрибутами MULTI_EXIT_DISC. Значения MULTI_EXIT_DISC можно сравнивать только для маршрутов, полученных из одной соседней AS (эта AS определяется из атрибута AS_PATH). Маршруты без атрибута MULTI_EXIT_DISC рассматриваются как маршруты с наименьшим возможным значением MULTI_EXIT_DISC.

Описанный выше алгоритм можно представить в виде следующей процедуры:

for m = число остающихся в рассмотрении маршрутов

for n = число остающихся в рассмотрении маршрутов

if (neighborAS(m) == neighborAS(n)) и (MED(n) < MED(m)) исключить маршрут m из рассмотрения

В приведенном выше псевдокоде функция MED(n) возвращает значение атрибута MULTI_EXIT_DISC для маршрута n. Если маршрут n не имеет атрибута MULTI_EXIT_DISC, функция возвращает минимальное из возможных значения MULTI_EXIT_DISC (т. е., 0).

Функция neighborAS(n) возвращает номер соседней AS, из которой был получен маршрут n. Если маршрут получен через IBGP и другой узел IBGP не является исходной точкой этого маршрута, это будет номер соседней AS, из которой другой узел IBGP получил маршрут. Если маршрут получен через IBGP и другой узел IBGP (a) является исходной точкой маршрута или (b) создал маршрут путем агрегирования и атрибут AS_PATH агрегированного маршрута пуст или начинается с AS_SET, это локальная AS.

Если атрибут MULTI_EXIT_DISC удаляется до повторного анонсирования маршрута в IBGP, можно провести сравнение с использованием через EBGP полученного атрибута MULTI_EXIT_DISC. Если реализация решает удалить MULTI_EXIT_DISC, тогда дополнительное сравнение MULTI_EXIT_DISC, если оно выполняется, должно учитывать только маршруты, полученные через EBGP. Наилучший маршрут от EBGP можно тогда сравнивать с маршрутами от IBGP после удаления атрибута MULTI_EXIT_DISC. Если атрибут MULTI_EXIT_DISC удаляется из подмножества маршрутов от EBGP и из выбранного “лучшего” маршрута от EBGP не будет удален атрибут MULTI_EXIT_DISC, тогда этот атрибут должен использоваться для сравнения с маршрутами от IBGP. Для полученных через IBGP маршрутов атрибут MULTI_EXIT_DISC должен использоваться при сранении маршрутов, которые не исключены на предыдущих этапах выбора (Decision Process). Включение атрибута MULTI_EXIT_DISC маршрутов от EBGP в сравнение с маршрутами от IBGP с последующим удалением атрибута MULTI_EXIT_DISC и анонсированием маршрута будет предотвращать возникновение маршрутных петель.

2.2. MED и картошка²

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

Первый метод называют "hot potato routing" (или closest-exit³), поскольку он напоминает быстрое перебрасывание горячей картофелины, удерживаемой голыми руками. Маршрутизация этого типа осуществляется без передачи полученного от EBGP значения MED в IBGP. Это минимизирует транзитный трафик для провайдера, маршрутизирующего трафик. Значительно менее распространенным методом является "cold potato routing" (или best-exit⁴), когда транзитный провайдер использует свою транзитную емкость для получения трафика, направляемого смежному транзитному провайдеру, анонсируемому как ближайший к адресату. Этот тип маршрутизации выполняется путем передачи полученного от EBGP значения MED в IBGP.

Если один из транзитных провайдеров использует метод “hot potato”, а другой - “cold potato”, трафик между адресатами будет более симметричным. Однако если оба провайдера будут использовать метод “cold potato” или “hot potato” между своими сетями, очевидно, что это приведет к возникновению асимметрии.

В зависимости от конкретных отношений между провайдерами, если один из них имеет большую емкость или существенно менее загруженную транзитную сеть, он может использовать метод “cold potato”. Созданная NSF магистральная сеть NSFNET и

¹Приведенный ниже фрагмент спецификации заимствован из перевода документа, доступного на сайте http://rfc.com.ru.

Прим. перев.

²Рекомендуем также прочесть одноименный параграф в RFC 4451, перевод которого имеется на сайте http://rfc.com.ru.

Прим. перев.

³Ближайший выход

⁴Лучший выход

rfc.com.ru 2 rfc.com.ru

Перевод RFC 4451

региональные сети NSF являлись в середине 1990 годов примером повсеместного использования маршрутизации по методу “cold potato”.

В некоторых случаях провайдер может использовать метод “hot potato” для некоторых адресатов в данной партнерской AS и метод “cold potato” - для других. Разное отношение к коммерческому и исследовательскому трафику в сети NSFNET середины 1990 годов является примером такого решения. Сегодня многие коммерческие сети обмениваются атрибутами MED со своими заказчиками, не делают этого для партнеров (bilateral peer). Однако степень коммерческого применение атрибута MED варьируется в широких пределах – от повсеместного использования до полного отказа.

Кроме того, многие развернутые сегодня системы MED сильно отличаются в своем поведении (например, приводят к недостаточно оптимальной маршрутизации) от того, что ждет оператор и в результате получается маршрутизация не по методу “hot potato” или “cold potato”, а нечто среднее, что уместно назвать “mashed potato”⁵! Далее в документе приводится дополнительная информация о непредусмотренном поведении систем в результате использования атрибутов MED.

3. Поведение реализаций протокола

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

3.1. MULTI_EXIT_DISC является дополнительным непереходным атрибутом

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

3.2. Значение MED и предпочтения

Некоторые реализации трактуют нулевое значение атрибута MED, как более предпочтительное по сравнению с отсутствием этого атрибута. Такое поведение приводит к несогласованности выбора маршрутов внутри AS. Текущая версия спецификации BGP [BGP4] устраняет неоднозначности, существовавшие в [RFC1771], указывая, что для маршрутов, не имеющих атрибута MULTI_EXIT_DISC, следует присваивать этому атрибуту минимальное значение MULTI_EXIT_DISC = 0.

Очевидно, что различные реализации и разные версии спецификации BGP через различные варианты интерпретации отсутствия атрибута MED. Например, в ранних версиях спецификации говорилось, что при отсутствии атрибута MED следует присваивать максимально возможное значение MED (т. е., 2^32-1).

Кроме того, некоторые реализации показывают использование максимально возможного значения MED (2^32-1) в качестве “бесконечной” метрики (т. е., значения MED, используемого для недоступных маршрутов). При получении обновления с атрибутом MED = 2^32-1, такие реализации меняют полученное значение на 2^32-2. Следовательно, новое значение MED будет распространяться в обновлениях и может приводить к несогласованностям при выборе маршрутов и непредусмотренному выбору пути.

В результате несогласованности реализаций и вариантов спецификации протокола многие сетевые операторы сегодня явно сбрасывают (т. е., устанавливают в 0 или иное “фиксированное” значение) все значения MED на входе в сеть для согласования с внутренней политикой маршрутизации (т. е., для включения правила, по которому значения MED, равные 0 или 2^32-1, не используются в конфигурациях, где значения MED рассчитываются напрямую или задаются в конфигурации), поскольку не имеют уверенности в том, что все их маршрутизаторы одинаково ведут себя в случаях отсутствия атрибута MED.

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

3.3. Сравнение атрибутов MED из разных AS

Атрибут MED предназначен для использования на внешних (между AS) каналах и позволяет различать разные точки входа или выхода в одной соседней AS. Однако существует множество случаев использования атрибутов MED в целых определения уровня предпочтений для похожих маршрутов, полученных из различных автономных систем.

Большое число реализаций обеспечивает возможность разрешить сравнение атрибутов MED для маршрутов, полученных из разных соседних AS. Хотя такая возможность показала некоторые преимущества (например, описанные в [RFC3345]), операторам следует принимать во внимание побочные эффекты, которые могут возникать в результате такого сравнения. В разделе, посвященном развертыванию, мы приведем некоторые примеры того, как это сравнение может приводить к нежелательному поведению.

3.4. Атрибуты MED, Route Reflection и AS Confederations для BGP

В некоторых вариантах конфигурации механизмы масштабирования BGP, определенные в документах "BGP Route Reflection - An Alternative to Full Mesh IBGP" [RFC2796] и "Autonomous System Confederations for BGP" [RFC3065], будут приводить к постоянным осцилляциям маршрутов BGP [RFC3345]. Эта проблема связана с принципами работы BGP – существует конфликт между сокрытием (иерархией) информации и не использующим иерархии процессом выбора, обусловленный недостатком общего упорядочивания, вызванным правилами MED. С учетом текущей практики можно сказать, что проблема наиболее часто возникает в контексте использования MED совместно с рефлекторами маршрутов или конфедерациями.

Одним из способов предотвращения этой проблемы является задание для метрики inter-Member-AS или inter-cluster IGP более высоких значений, нежели для IGP-метрики intra-Member-AS и/или использование других правил удаления ненужного (tie-breaking), позволяющих избежать выбора маршрута BGP на основе несравнимых значений MED. Естественно, что искусственное снижение метрики IGP может оказаться слишком затруднительным для некоторых приложений.

⁵Картофельное пюре.

rfc.com.ru 3 rfc.com.ru

Перевод RFC 4451

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

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

3.5. Подавление маршрутных осцилляций⁶ и MED Churn⁷

Значения MED часто получаются динамически из метрики IGP или аддитивной стоимости, связанной с метрикой IGP для данного BGP NEXT_HOP. Это обычно обеспечивает эффективную модель, гарантирующую, что атрибуты BGP MED, анонсируемые партнерам, используются для представления лучшего пути к данному адресату в сети, который согласован с IGP внутри данной AS.

Следствием динамического задания атрибутов MED на основе IGP является нестабильность, возникающая в AS или даже на отдельном соединении внутри AS, которая может приводить к широкомасштабной нестабильности BGP или мешанине (churn) маршрутных анонсов BGP, распространяемых через множество доменов. Если ваш атрибут MED “переключается” (flap) всякий раз при смене метрики IGP, ваши маршруты явно будут подавляться в результате использования метода BGP Route Flap Damping⁸[RFC2439].

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

Многие реализации не имеют на практике проблем с переключениями (flapping) IGP; они захватывают свою метрику IGP по первому анонсу или используют некий внутренний механизм подавления. Некоторые реализации считают изменение атрибутов BGP менее значимым, нежели отзыв или анонсирование маршрута в попытке смягчить воздействие этого типа событий.

3.6. Влияние атрибутов MED на эффективность упаковки обновлений

Множество недоступных маршрутов может анонсироваться в одном сообщении BGP Update. Протокол BGP4 также разрешает анонсировать в одном обновлении множество префиксов с общими атрибутами пути. Это обычно назувают упаковкой обновлений (update packing). По возможности рекомендуется использовать упаковку обновлений, так как она обеспечивает механизм более эффективного поведения в целом ряде областей, включая:

♦ снижение нагрузки на систему в результате генерации и приема меньшего числа сообщений Update;

♦ снижение нагрузки на сеть в результате уменьшения числа пакетов и снижения расхода полосы;

♦ менее частая обработка атрибутов пути и поиск соответствий в базе данных AS_PATH (если таковая используется); согласование порядка атрибутов пути позволяет упростить поиск соответствий в базе данных, поскольку не возникает различных вариантов представления одних и тех же данных.

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

3.7. Временная зависимость выбора маршрутов

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

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

4. Вопросы развертывания

Отмечалось, что восприятие атрибутов MED из других автономных систем может вызывать перемешивание (churn) потоков трафика в сети. Некоторые реализации только сбрасывают (ratchet down) MED и никогла не возвращают его для предотвращения чрезмерной мешанины.

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

Как было отмечено выше, многие сетевые операторы сбрасывают значения MED на входе в сеть. В дополнение к этому многие операторы явно не используют для атрибутов MED значений of 0 и 2^32-1, чтобы избавиться от несогласованности в различных реализациях и вариантах спецификации BGP.

4.1. Сравнение атрибутов MED из разных AS

Хотя атрибут MED был предназначен лишь для сравнения путей, полученных от разных внешних партнеров в одной AS, многие реализации обеспечивают также возможность сравнения атрибутов MED, полученных из разных автономных систем. Операторы AS часто используют атрибут LOCAL_PREF для выбора внешних предпочтений (основное и вторичное восходящее соединение⁹,

⁶Route Flap Damping ⁷Мешанина атрибутов MED. ⁸Подавление осцилляций маршрутов BGP. ⁹upstream

rfc.com.ru

Перевод RFC 4451

партнеры, заказчики и т. п..). Использование MED взамен LOCAL_PREF может приводить к несогласованному распространению лучших маршрутов, поскольку сравнение атрибутов MED происходит только после сравнения длины AS_PATH.

Сравнение атрибутов MED из различных AS может быть весьма продуктивным для некоторых конфигураций, однако в общем случае к таким сравнениям нужно подходить весьма осторожно. Узлы BGP часто задают значения MED на основе метрики IGP, связанной с доступом к данному BGP NEXT_HOP внутри локальной AS. Это позволяет в атрибутах MED отражать топологию IGP при анонсировании маршрутов партнерам. Это может хорошо работать при сравнении атрибутов MED для разных путей из одной AS, но потенциально может приводить к принятию “отягощенных” решений при сравнении атрибутов MED из разных автономных систем. Типичным случаем является использование разными автономными системами различных механизмов установки метрики IGP или атрибутов BGP MED, а также использование различных протоколов IGP с существенно различающимися метрическими пространствами (например, OSPF и традиционная метрика IS-IS).

4.2. Эффекты объединения атрибутов MED

Другим вопросом, связанным с использованием атрибутов MED, является влияние, которое на этот атрибут оказывает агрегирование маршрутной информации BGP. Объединенные маршруты (aggregate) часто генерируются из множества мест в AS для того, чтобы учесть стабильность, резервные каналы и устройство сети. Когда атрибуты MED получаются на основе метрики IGP, связанной с упомянутыми объединенными маршрутами, анонсируемое партнерам значение MED может приводить к далекой от оптимальной маршрутизации.

5. Вопросы безопасности

Атрибут MED был предложен как “слабая” метрика, которая будет использоваться лишь в конце процесса выбора лучшего пути. Рабочая группа BGP была заинтересована в том, чтобы любая метрика, указанная удаленным оператором, оказывала влияние на маршрутизацию в локальной AS лишь в тех случаях, когда не указано иных предпочтений. Основной задачей при разработке MED было обеспечение гарантий того, что партнеры не смогут “сливать” или “поглощать” трафик для сетей, которые они анонсируют. Поэтому восприятие атрибутов MED от партнеров может в некотором смысле повышать чувствительность сети к подобным воздействиям со стороны партнеров.

6. Благодарности

Спасибо John Scudder за его зоркий глаз и творческую интуицию. Благодарим также Curtis Villamizar, JR Mitchell и Pekka Savola за их полезные отклики.

7. Литература

7.1. Нормативные документы

[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771¹⁰, March 1995.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119¹⁰, March 1997.

[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796¹⁰, April 2000.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065¹⁰, February 2001.

[BGP4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271¹⁰, January 2006.

7.2. Дополнительная литература

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.

[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.

Адреса авторов Danny McPherson

Arbor Networks EMail: danny@arbor.net

Vijay Gill

AOL

EMail: VijayGill9@aol.com

Перевод на русский язык Николай Малых

nmalykh@bilim.com

¹⁰Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 5 rfc.com.ru



		Перевод RFC 4451
		Перевод RFC 4451
	2.1. Атрибут MULTI_EXIT_DISC (MED) Атрибут BGP MULTI_EXIT_DISC (MED), ранее известный как INTER_AS_METRIC, определен в параграфе 5.1.4 документа [BGP4] следующим образом¹: Дополнительный непереходный атрибут MULTI_EXIT_DISC предназначен для использования на внешних (между AS) соединениях для выбора из множества путей в одну смежную AS. Значение атрибута MULTI_EXIT_DISC представляет собой 4-октетное целое число без знака, которое называют метрикой. При прочих равных из нескольких маршрутов следует выбирать тот, у которого меньше значение метрики. При получении через EBGP атрибут MULTI_EXIT_DISC можно распространять черз IBGP другим узлам BGP в данной AS (см. также параграф 9.1.2.2). Атрибут MULTI_EXIT_DISC, полученный из соседней AS, недопустимо распространять в другие соседние AS. Узел BGP должен обеспечивать механизм (в соответствии с локальной конфигурацией), позволяющий удалять из маршрутов атрибут MULTI_EXIT_DISC. Если узел BGP настроен на удаление атрибута MULTI_EXIT_DISC из маршрутов, такое удаление должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process). Реализация может также (в соответствии с локальной конфигурацией) изменять значение атрибутов MULTI_EXIT_DISC, полученных через EBGP. Если узел BGP настроен на изменение значений атрибута MULTI_EXIT_DISC, принятых через EBGP, такое изменение должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process). Некоторые ограничения описаны в параграфе 9.1.2.2. В параграфе 9.1.2.2 (п. c) документа [BGP4] определяются следующие критерии выбора маршрутов, связанные с MED¹: c) Исключаются из рассмотрения маршруты с менее предпочтительными атрибутами MULTI_EXIT_DISC. Значения MULTI_EXIT_DISC можно сравнивать только для маршрутов, полученных из одной соседней AS (эта AS определяется из атрибута AS_PATH). Маршруты без атрибута MULTI_EXIT_DISC рассматриваются как маршруты с наименьшим возможным значением MULTI_EXIT_DISC. Описанный выше алгоритм можно представить в виде следующей процедуры: for m = число остающихся в рассмотрении маршрутов for n = число остающихся в рассмотрении маршрутов if (neighborAS(m) == neighborAS(n)) и (MED(n) < MED(m)) исключить маршрут m из рассмотрения В приведенном выше псевдокоде функция MED(n) возвращает значение атрибута MULTI_EXIT_DISC для маршрута n. Если маршрут n не имеет атрибута MULTI_EXIT_DISC, функция возвращает минимальное из возможных значения MULTI_EXIT_DISC (т. е., 0). Функция neighborAS(n) возвращает номер соседней AS, из которой был получен маршрут n. Если маршрут получен через IBGP и другой узел IBGP не является исходной точкой этого маршрута, это будет номер соседней AS, из которой другой узел IBGP получил маршрут. Если маршрут получен через IBGP и другой узел IBGP (a) является исходной точкой маршрута или (b) создал маршрут путем агрегирования и атрибут AS_PATH агрегированного маршрута пуст или начинается с AS_SET, это локальная AS. Если атрибут MULTI_EXIT_DISC удаляется до повторного анонсирования маршрута в IBGP, можно провести сравнение с использованием через EBGP полученного атрибута MULTI_EXIT_DISC. Если реализация решает удалить MULTI_EXIT_DISC, тогда дополнительное сравнение MULTI_EXIT_DISC, если оно выполняется, должно учитывать только маршруты, полученные через EBGP. Наилучший маршрут от EBGP можно тогда сравнивать с маршрутами от IBGP после удаления атрибута MULTI_EXIT_DISC. Если атрибут MULTI_EXIT_DISC удаляется из подмножества маршрутов от EBGP и из выбранного “лучшего” маршрута от EBGP не будет удален атрибут MULTI_EXIT_DISC, тогда этот атрибут должен использоваться для сравнения с маршрутами от IBGP. Для полученных через IBGP маршрутов атрибут MULTI_EXIT_DISC должен использоваться при сранении маршрутов, которые не исключены на предыдущих этапах выбора (Decision Process). Включение атрибута MULTI_EXIT_DISC маршрутов от EBGP в сравнение с маршрутами от IBGP с последующим удалением атрибута MULTI_EXIT_DISC и анонсированием маршрута будет предотвращать возникновение маршрутных петель. 2.2. MED и картошка² Рассмотрим поток трафика между парой хостов, каждый из которых соединен со своей транзитной сетью, а эти сети соединены между собой в двух или более точках. Каждая из транзитных сетей может выбирать между передачей трафика партнеру, ближайшему ко второй транзитной сети, или партнеру, анонсирующему “более дешевый” путь к адресату. Первый метод называют "hot potato routing" (или closest-exit³), поскольку он напоминает быстрое перебрасывание горячей картофелины, удерживаемой голыми руками. Маршрутизация этого типа осуществляется без передачи полученного от EBGP значения MED в IBGP. Это минимизирует транзитный трафик для провайдера, маршрутизирующего трафик. Значительно менее распространенным методом является "cold potato routing" (или best-exit⁴), когда транзитный провайдер использует свою транзитную емкость для получения трафика, направляемого смежному транзитному провайдеру, анонсируемому как ближайший к адресату. Этот тип маршрутизации выполняется путем передачи полученного от EBGP значения MED в IBGP. Если один из транзитных провайдеров использует метод “hot potato”, а другой - “cold potato”, трафик между адресатами будет более симметричным. Однако если оба провайдера будут использовать метод “cold potato” или “hot potato” между своими сетями, очевидно, что это приведет к возникновению асимметрии. В зависимости от конкретных отношений между провайдерами, если один из них имеет большую емкость или существенно менее загруженную транзитную сеть, он может использовать метод “cold potato”. Созданная NSF магистральная сеть NSFNET и

	¹Приведенный ниже фрагмент спецификации заимствован из перевода документа, доступного на сайте http://rfc.com.ru. Прим. перев. ²Рекомендуем также прочесть одноименный параграф в RFC 4451, перевод которого имеется на сайте http://rfc.com.ru. Прим. перев. ³Ближайший выход ⁴Лучший выход rfc.com.ru 2 rfc.com.ru



	Перевод RFC 4451

	региональные сети NSF являлись в середине 1990 годов примером повсеместного использования маршрутизации по методу “cold potato”. В некоторых случаях провайдер может использовать метод “hot potato” для некоторых адресатов в данной партнерской AS и метод “cold potato” - для других. Разное отношение к коммерческому и исследовательскому трафику в сети NSFNET середины 1990 годов является примером такого решения. Сегодня многие коммерческие сети обмениваются атрибутами MED со своими заказчиками, не делают этого для партнеров (bilateral peer). Однако степень коммерческого применение атрибута MED варьируется в широких пределах – от повсеместного использования до полного отказа. Кроме того, многие развернутые сегодня системы MED сильно отличаются в своем поведении (например, приводят к недостаточно оптимальной маршрутизации) от того, что ждет оператор и в результате получается маршрутизация не по методу “hot potato” или “cold potato”, а нечто среднее, что уместно назвать “mashed potato”⁵! Далее в документе приводится дополнительная информация о непредусмотренном поведении систем в результате использования атрибутов MED. *3. Поведение реализаций протокола* Имеется множество странностей протокола, связанных с реализаций атрибутов MED, которые могут оказывать влияние на поведение сетей. В следующих параграфах описаны некоторые проблемы этого типа. 3.1. MULTI_EXIT_DISC является дополнительным непереходным атрибутом MULTI_EXIT_DISC представляет собой дополнительный непереходный атрибут, который анонсируется по своему усмотрению как IBGP, так и EBGP-партнерам. В результате некоторые реализации способны передавать атрибуты MED партнерам IBGP по умолчанию, а другие не могут этого. Такое поведение может приводить к выбору неоптимального маршрута внутри AS. Кроме того, некоторые реализации передают атрибуты MED партнерам EBGP по умолчанию, а другие не делают этого. В результате может выбираться неоптимальный путь для междоменной маршрутизации. 3.2. Значение MED и предпочтения Некоторые реализации трактуют нулевое значение атрибута MED, как более предпочтительное по сравнению с отсутствием этого атрибута. Такое поведение приводит к несогласованности выбора маршрутов внутри AS. Текущая версия спецификации BGP [BGP4] устраняет неоднозначности, существовавшие в [RFC1771], указывая, что для маршрутов, не имеющих атрибута MULTI_EXIT_DISC, следует присваивать этому атрибуту минимальное значение MULTI_EXIT_DISC = 0. Очевидно, что различные реализации и разные версии спецификации BGP через различные варианты интерпретации отсутствия атрибута MED. Например, в ранних версиях спецификации говорилось, что при отсутствии атрибута MED следует присваивать максимально возможное значение MED (т. е., 2^32-1). Кроме того, некоторые реализации показывают использование максимально возможного значения MED (2^32-1) в качестве “бесконечной” метрики (т. е., значения MED, используемого для недоступных маршрутов). При получении обновления с атрибутом MED = 2^32-1, такие реализации меняют полученное значение на 2^32-2. Следовательно, новое значение MED будет распространяться в обновлениях и может приводить к несогласованностям при выборе маршрутов и непредусмотренному выбору пути. В результате несогласованности реализаций и вариантов спецификации протокола многие сетевые операторы сегодня явно сбрасывают (т. е., устанавливают в 0 или иное “фиксированное” значение) все значения MED на входе в сеть для согласования с внутренней политикой маршрутизации (т. е., для включения правила, по которому значения MED, равные 0 или 2^32-1, не используются в конфигурациях, где значения MED рассчитываются напрямую или задаются в конфигурации), поскольку не имеют уверенности в том, что все их маршрутизаторы одинаково ведут себя в случаях отсутствия атрибута MED. Поскольку реализации обычно не обеспечивают механизма запрета сравнения MED в алгоритме выбора маршрутов, отказ от использования MED обычно приводит к явной установке для всех атрибутов MED некого фиксированного значения на входе в домен маршрутизации. Если предположить, что фиксированное значение MED согласовано для всех маршрутизаторов сети, атрибуты MED просто не будут использоваться в процессе выбора маршрутов. 3.3. Сравнение атрибутов MED из разных AS Атрибут MED предназначен для использования на внешних (между AS) каналах и позволяет различать разные точки входа или выхода в одной соседней AS. Однако существует множество случаев использования атрибутов MED в целых определения уровня предпочтений для похожих маршрутов, полученных из различных автономных систем. Большое число реализаций обеспечивает возможность разрешить сравнение атрибутов MED для маршрутов, полученных из разных соседних AS. Хотя такая возможность показала некоторые преимущества (например, описанные в [RFC3345]), операторам следует принимать во внимание побочные эффекты, которые могут возникать в результате такого сравнения. В разделе, посвященном развертыванию, мы приведем некоторые примеры того, как это сравнение может приводить к нежелательному поведению. 3.4. Атрибуты MED, Route Reflection и AS Confederations для BGP В некоторых вариантах конфигурации механизмы масштабирования BGP, определенные в документах "BGP Route Reflection - An Alternative to Full Mesh IBGP" [RFC2796] и "Autonomous System Confederations for BGP" [RFC3065], будут приводить к постоянным осцилляциям маршрутов BGP [RFC3345]. Эта проблема связана с принципами работы BGP – существует конфликт между сокрытием (иерархией) информации и не использующим иерархии процессом выбора, обусловленный недостатком общего упорядочивания, вызванным правилами MED. С учетом текущей практики можно сказать, что проблема наиболее часто возникает в контексте использования MED совместно с рефлекторами маршрутов или конфедерациями. Одним из способов предотвращения этой проблемы является задание для метрики inter-Member-AS или inter-cluster IGP более высоких значений, нежели для IGP-метрики intra-Member-AS и/или использование других правил удаления ненужного (tie-breaking), позволяющих избежать выбора маршрута BGP на основе несравнимых значений MED. Естественно, что искусственное снижение метрики IGP может оказаться слишком затруднительным для некоторых приложений.

	⁵Картофельное пюре. rfc.com.ru 3 rfc.com.ru



	Перевод RFC 4451

	партнеры, заказчики и т. п..). Использование MED взамен LOCAL_PREF может приводить к несогласованному распространению лучших маршрутов, поскольку сравнение атрибутов MED происходит только после сравнения длины AS_PATH. Сравнение атрибутов MED из различных AS может быть весьма продуктивным для некоторых конфигураций, однако в общем случае к таким сравнениям нужно подходить весьма осторожно. Узлы BGP часто задают значения MED на основе метрики IGP, связанной с доступом к данному BGP NEXT_HOP внутри локальной AS. Это позволяет в атрибутах MED отражать топологию IGP при анонсировании маршрутов партнерам. Это может хорошо работать при сравнении атрибутов MED для разных путей из одной AS, но потенциально может приводить к принятию “отягощенных” решений при сравнении атрибутов MED из разных автономных систем. Типичным случаем является использование разными автономными системами различных механизмов установки метрики IGP или атрибутов BGP MED, а также использование различных протоколов IGP с существенно различающимися метрическими пространствами (например, OSPF и традиционная метрика IS-IS). 4.2. Эффекты объединения атрибутов MED Другим вопросом, связанным с использованием атрибутов MED, является влияние, которое на этот атрибут оказывает агрегирование маршрутной информации BGP. Объединенные маршруты (aggregate) часто генерируются из множества мест в AS для того, чтобы учесть стабильность, резервные каналы и устройство сети. Когда атрибуты MED получаются на основе метрики IGP, связанной с упомянутыми объединенными маршрутами, анонсируемое партнерам значение MED может приводить к далекой от оптимальной маршрутизации.

	*5. Вопросы безопасности* Атрибут MED был предложен как “слабая” метрика, которая будет использоваться лишь в конце процесса выбора лучшего пути. Рабочая группа BGP была заинтересована в том, чтобы любая метрика, указанная удаленным оператором, оказывала влияние на маршрутизацию в локальной AS лишь в тех случаях, когда не указано иных предпочтений. Основной задачей при разработке MED было обеспечение гарантий того, что партнеры не смогут “сливать” или “поглощать” трафик для сетей, которые они анонсируют. Поэтому восприятие атрибутов MED от партнеров может в некотором смысле повышать чувствительность сети к подобным воздействиям со стороны партнеров. *6. Благодарности* Спасибо John Scudder за его зоркий глаз и творческую интуицию. Благодарим также Curtis Villamizar, JR Mitchell и Pekka Savola за их полезные отклики. 7. Литература 7.1. Нормативные документы [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771¹⁰, March 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119¹⁰, March 1997. [RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796¹⁰, April 2000. [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065¹⁰, February 2001. [BGP4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271¹⁰, January 2006. 7.2. Дополнительная литература [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998. [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.

	Адреса авторов Danny McPherson Arbor Networks EMail: danny@arbor.net

	Vijay Gill AOL EMail: VijayGill9@aol.com

	Перевод на русский язык Николай Малых nmalykh@bilim.com

	Полное заявление авторских прав Copyright (C) The Internet Society (2006).

	¹⁰Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 5 rfc.com.ru



		Перевод RFC 4451
		Перевод RFC 4451
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Интеллектуальная собственность The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Подтверждение Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

rfc.com.ru	6	rfc.com.ru