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. Документ не задает каких-либо стандартов. Допускается свободное распространения документа.
Авторские права
Copyright (C) The Internet Society (2006).
Аннотация
Атрибут 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:
Дополнительный непереходный атрибут 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] определяются следующие критерии выбора маршрутов, связанные с MED1:
-
Исключаются из рассмотрения маршруты с менее предпочтительными атрибутами 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 и картошка2
Рассмотрим поток трафика между парой хостов, каждый из которых соединен со своей транзитной сетью, а эти сети соединены между собой в двух или более точках. Каждая из транзитных сетей может выбирать между передачей трафика партнеру, ближайшему ко второй транзитной сети, или партнеру, анонсирующему “более дешевый” путь к адресату.
Первый метод называют hot potato routing (или closest-exit3), поскольку он напоминает быстрое перебрасывание горячей картофелины, удерживаемой голыми руками. Маршрутизация этого типа осуществляется без передачи полученного от EBGP значения MED в IBGP. Это минимизирует транзитный трафик для провайдера, маршрутизирующего трафик. Значительно менее распространенным методом является cold potato routing (или best-exit4), когда транзитный провайдер использует свою транзитную емкость для получения трафика, направляемого смежному транзитному провайдеру, анонсируемому как ближайший к адресату. Этот тип маршрутизации выполняется путем передачи полученного от 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 potato5! Далее в документе приводится дополнительная информация о непредусмотренном поведении систем в результате использования атрибутов 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 (т. е., 232-1).
Кроме того, некоторые реализации показывают использование максимально возможного значения MED (232-1) в качестве «бесконечной» метрики (т. е., значения MED, используемого для недоступных маршрутов). При получении обновления с атрибутом MED = 232-1, такие реализации меняют полученное значение на 232-2. Следовательно, новое значение MED будет распространяться в обновлениях и может приводить к несогласованностям при выборе маршрутов и непредусмотренному выбору пути.
В результате несогласованности реализаций и вариантов спецификации протокола многие сетевые операторы сегодня явно сбрасывают (т. е., устанавливают в 0 или иное “фиксированное” значение) все значения MED на входе в сеть для согласования с внутренней политикой маршрутизации (т. е., для включения правила, по которому значения MED, равные 0 или 232-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. Подавление маршрутных осцилляций6 и MED Churn7
Значения MED часто получаются динамически из метрики IGP или аддитивной стоимости, связанной с метрикой IGP для данного BGP NEXT_HOP. Это обычно обеспечивает эффективную модель, гарантирующую, что атрибуты BGP MED, анонсируемые партнерам, используются для представления лучшего пути к данному адресату в сети, который согласован с IGP внутри данной AS.
Следствием динамического задания атрибутов MED на основе IGP является нестабильность, возникающая в AS или даже на отдельном соединении внутри AS, которая может приводить к широкомасштабной нестабильности BGP или мешанине (churn) маршрутных анонсов BGP, распространяемых через множество доменов. Если ваш атрибут MED “переключается” (flap) всякий раз при смене метрики IGP, ваши маршруты явно будут подавляться в результате использования метода BGP Route Flap Damping8 [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 и 232-1, чтобы избавиться от несогласованности в различных реализациях и вариантах спецификации BGP.
4.1. Сравнение атрибутов MED из разных AS
Хотя атрибут MED был предназначен лишь для сравнения путей, полученных от разных внешних партнеров в одной AS, многие реализации обеспечивают также возможность сравнения атрибутов MED, полученных из разных автономных систем. Операторы AS часто используют атрибут LOCAL_PREF для выбора внешних предпочтений (основное и вторичное восходящее соединение9, партнеры, заказчики и т. п..). Использование 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
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2006).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).
3Ближайший выход
4Лучший выход
5Картофельное пюре.
6Route Flap Damping
7Мешанина атрибутов MED.
8Подавление осцилляций маршрутов BGP.
9Upstream.
