AAA

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

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

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

Тезисы

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

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

Оглавление

1. Введение

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

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

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

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

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

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

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

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 и региональные сети 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 может оказаться слишком затруднительным для некоторых приложений.

Отказ от сравнения атрибутов 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). По возможности рекомендуется использовать упаковку обновлений, так как она обеспечивает механизм более эффективного поведения в целом ряде областей, включая:

Упаковка обновлений требует, чтобы все доступные маршруты в одном обновлении имели общий набор атрибутов пути, чтобы включить общее значение 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 для выбора внешних предпочтений (основное и вторичное восходящее соединение, партнеры, заказчики и т. п..). Использование 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. Нормативные документы

  1. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
  2. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  3. [RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection — An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
  4. [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
  5. [BGP4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006

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

  1. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
  2. [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: ten.robra@ynnad

Vijay Gill
AOL
EMail: moc.loa@9lligyajiv

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

Николай Малых, ur.slocotorp@hkylamn