RFC 4724 Graceful Restart Mechanism for BGP

Network Working Group                                          S. Sangli
Request for Comments: 4724                                       E. Chen
Category: Standards Track                                  Cisco Systems
                                                             R. Fernando
                                                              J. Scudder
                                                              Y. Rekhter
                                                        Juniper Networks
                                                            January 2007

Graceful Restart Mechanism for BGP

Механизм аккуратного перезапуска для BGP

PDF

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

В этом документе приведена спецификация проекта стандартного протокола Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

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

Copyright (C) The IETF Trust (2007).

Аннотация

Этот документ описывает механизм для BGP который поможет минимизировать негативное влияние перезапуска BGP на маршрутизацию. Задан маркер End-of-RIB, который может применяться для передачи информации о схождении маршрутов. Определена новая возможность BGP – Graceful Restart Capability, позволяющая узлу BGP указать свою способность сохранять состояние пересылки при перезапуске BGP. Кроме того, очерчены процедуры для временного сохранения маршрутной информации при разрыве и повторной организации сессии TCP.

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

1. Введение

Обычно при перезапуске маршрутизатора BGP все его партнеры BGP видят разрыв и последующее восстановление сессии. Такой переход «вкл. – выкл.» приводит к перебою маршрутизации (routing flap) и вызывает пересчет маршрутов BGP, генерацию маршрутных обновлений BGP и ненужные сбои в таблицах пересылки, которые могут охватывать множество доменов маршрутизации. Такие перебои в маршрутизации могут создавать временные «черные дыры» и петли в маршрутизации. Кроме того, это ведет к расходу ресурсов на уровне управления затронутых перебоем маршрутизаторов. В результате снижается общая производительность сети.

В этом документе описан механизм для BGP, который поможет минимизировать негативное влияние перезапуска BGP на маршрутизацию. Задан маркер End-of-RIB, который может служить для передачи информации о схождении маршрутов. Определена новая возможность BGP – Graceful Restart Capability, позволяющая узлу BGP указать свою способность сохранять состояние пересылки в процессе перезапуска BGP. Кроме того, очерчены процедуры для временного сохранения маршрутной информации при разрыве и повторной организации сессии TCP.

1.1 Уровни требований

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

2. Маркер для End-of-RIB

Сообщение UPDATE без доступных NLRI¹ и с пустым NLRI отзыва задано в качестве маркера End-of-RIB², который может использоваться узлом BGP для индикации его партнеру завершения начального обновления маршрутов после организации сессии. Для семейства индивидуальных адресов IPv4 маркер End-of-RIB является сообщением UPDATE с минимальным размером [BGP-4]. Для других семейств адресов это будет сообщение UPDATE, содержащее лишь атрибут MP_UNREACH_NLRI [BGP-MP] без отзываемых маршрутов для данной пары <AFI, SAFI>.

Хотя маркер End-of-RIB задан для «аккуратного перезапуска» BGP, отмечено, что генерация такого маркера при завершении начального обновления будет полезна для схождения маршрутов в общем случае, поэтому такая практика рекомендуется.

Кроме того, для схождения маршрутов было бы лучше, если бы узел BGP мог заранее указать своему партнеру, что он будет генерировать маркер End-of-RIB, независимо от способности сохранять свое состояние пересылки при перезапуске BGP. Это может быть достигнуто с помощью возможности Graceful Restart Capability, описанной ниже.

3. Возможность аккуратного перезапуска

Graceful Restart Capability является новой возможностью BGP [BGP-CAP], которая позволяет узлу BGP указать свою способность сохранять состояние пересылки при перезапуске BGP. Она может применяться также для передачи партнеру своего намерения создавать маркер End-of-RIB при завершении начального обновления маршрутов.

Определение возможности приведено ниже.

Capability code

64

Capability length

переменная

Capability value

Поля Restart Flags и Restart Time, а также от 0 до 63 блоков <AFI, SAFI, Flags for address family>, как показано ниже.

+--------------------------------------------------+
| Restart Flags (4 бита)                           |
+--------------------------------------------------+
| Restart Time in seconds (12 битов)               |
+--------------------------------------------------+
| Address Family Identifier (16 битов)             |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 битов)   |
+--------------------------------------------------+
| Flags for Address Family (8 битов)               |
+--------------------------------------------------+
| ...                                              |
+--------------------------------------------------+
| Address Family Identifier (16 битов)             |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 битов)   |
+--------------------------------------------------+
| Flags for Address Family (8 битов)               |
+--------------------------------------------------+

Ниже описаны поля значения Capability.

Restart Flags

Это поле содержит флаги, относящиеся к перезапуску.

 0 1 2 3
+-+-+-+-+
|R|Resv.|
+-+-+-+-+

Старший бит определен как флаг перезапуска (Restart State – R), который может применяться для предотвращения возможного «зависания», вызванного ожиданием маркера End-of-RIB при перезапуске множества связанных между собой узлов BGP. Установленный (1) флаг указывает, что узел BGP был перезапущен и его партнерам недопустимо ждать маркера End-of-RIB перед анонсированием узлу маршрутной информации.

Оставшиеся биты являются резервными и должны сбрасываться (0) при передаче и игнорироваться на приеме.

Restart Time

Оценка времени (в секундах) ожидания восстановления сессии BGP после перезапуска. Это может применяться для ускорения схождения маршрутов у партнера, если узел BGP не возвращается после перезапуска.

Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI)

Комбинация AFI и SAFI указывает, что Graceful Restart поддерживается для маршрутов с данными семействами адресов. Маршруты можно связать с определенными AFI и SAFI явно путем кодирования [BGP-MP] или неявно указать <AFI=IPv4, SAFI=Unicast> путем кодирования [BGP-4].

Flags for Address Family

Это поле содержит флаги, относящиеся к маршрутами, которые будут анонсироваться с данными AFI и SAFI.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|   Reserved  |
+-+-+-+-+-+-+-+-+

Старший бит определен в качестве флага состояния пересылки (Forwarding State – F), который позволяет указать, сохранено ли состояние пересылки для маршрутов, анонсированных с указанными AFI и SAFI, при предшествующем перезапуске BGP. Установленное (1) значение говорит о сохранении состояния пересылки.

Оставшиеся биты являются резервными и должны сбрасываться (0) при передаче и игнорироваться на приеме.

Когда отправитель этой возможности не включает в анонс <AFI, SAFI>, это означает, что он не может сохранить состояние пересылки в при перезапуске BGP, но поддерживает процедуры, определенные в параграфе 4.2. В таких случаях указанное отправителем значение Restart Time не имеет реального смысла.

Узлу BGP недопустимо включать более одного экземпляра Graceful Restart Capability в свой анонс возможностей [BGP-CAP]. При наличии нескольких экземпляров Graceful Restart Capability в анонсе принимающая сторона должна игнорировать все экземпляры Graceful Restart Capability, кроме последнего.

Включение <AFI=IPv4, SAFI=unicast> в Graceful Restart Capability не подразумевает, что маршрутные данные для индивидуальных адресов IPv4 следует передавать с использованием расширений [BGP-MP] – она может передаваться в поле NLRI сообщения BGP UPDATE.

4. Операции

Узел BGP может анонсировать Graceful Restart Capability для семейства адресов своему партнеру, если он может сохранять свое состояние пересылки для этого семейства адресов при перезапуске BGP. Но даже при неспособности узла сохранить состояние пересылки при перезапуске BGP ему рекомендуется анонсировать своему партнеру Graceful Restart Capability без включения в нее <AFI, SAFI>. Для этого имеются две причины. Во-первых, это показывает намерение узла генерировать маркер End-of-RIB при завершении начального обновления маршрутов, что в общем случае полезно для схождения маршрутов. Во-вторых, это указывает поддержку партнеров, которые хотят использовать «аккуратный перезапуск» (graceful restart).

Маркер End-of-RIB должен передаваться узлом BGP его партнеру после завершения начального обновления маршрутов (включая случай отсутствия обновлений) для семейства адресов после организации сессии BGP.

Следует отметить, что при разрыве сессии TCP в результате приема или передачи сообщения BGP NOTIFICATION должны выполняться обычные процедуры BGP.

Предлагается использовать по умолчанию значение Restart Time, не превышающее HOLDTIME из сообщения OPEN.

Далее «перезапускаемым узлом» (Restarting Speaker) называется узел, на котором перезапускается BGP, а «принимающим узлом» (Receiving Speaker) называется партнер перезапускающегося узла.

Следует помнить, что Graceful Restart Capability для семейства адресов анонсируется перезапускаемым узлом и воспринимается принимающим узлом, а между этими узлами имеется сессия BGP. Ниже подробно рассматриваются процедуры, которым должны следовать перезапускаемые и принимающий узел после начала перезапуска.

4.1. Процедуры для перезапускаемого узла

При перезапуске Restarting Speaker должен (по возможности) сохранить состояние пересылки для маршрутов BGP в Loc-RIB и должен отметить его как «замороженное» (stale). Во время пересылки недопустимо отличать «замороженную» информацию от остальной.

Для восстановления сессии с партнером перезапускаемый узел должен установить бит Restart State в Graceful Restart Capability сообщения OPEN. Пока это не разрешено конфигурацией, бит Forwarding State для семейства адресов может устанавливаться лишь в случаях, когда состояние пересылки реально сохранено при перезапуске.

После восстановления сессии Restarting Speaker будет получать и обрабатывать сообщения BGP от своих партнеров. Однако он должен отложить выбор маршрутов для семейства адресов, пока (a) не получит маркеры End-of-RIB от всех партнеров (исключая установивших бит Restart State в переданной возможности и не передавших возможность аккуратного перезапуска) или (b) не завершится отсчет таймера Selection_Deferral_Timer (см. ниже). Следует отметить, что до выбора маршрутов узел не будет иметь маршрутов для анонсирования своим партнерам и обновления состояния пересылки.

При одновременном перезапуске IGP³ и BGP может быть полезно дождаться схождения IGP перед выбором маршрутов BGP.

После выбора маршрутов узлом BGP состояние пересылки узла должно быть обновлено и вся «замороженная» ранее информация должна быть удалена. После этого можно анонсировать партнерам Adj-RIB-Out. По завершении начального обновления для семейства адресов (включая отсутствие обновлений) должен передаваться маркер End-of-RIB.

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

Если хочется применять Graceful Restart только при запланированном перезапуске (а не при каждом), одним из способов является установка бита Forwarding State (1) после запланированного перезапуска и сброс (0) в иных случаях. Другие варианты решения этой задачи выходят за рамки документа.

4.2. Процедуры для принимающего узла

При перезапуске Restarting Speaker принимающий узел не всегда может определить разрыв сессии TCP с перезапускаемым узлом. Это зависит от реализации TCP, использования [BGP-AUTH] и конкретных условий перезапуска. Если разрыв сессии TCP не обнаружен, узел должен считать последующую попытку организации сессии указанием разрыва прежней сессии TCP и действовать подобающим образом (при получении Graceful Restart Capability от партнера). Описание поведения в терминах машины конечных состояний дано в разделе 5⁴.

«Подобающие действия» в этом контексте означают, что узел должен закрыть прежнюю сессию TCP и сохранить новую. Отметим, что это поведение отличается от принятого по умолчанию в параграфе 6.8 [BGP-4]. Поскольку прежнее соединение считается разорванным, передавать сообщение NOTIFICATION не следует – просто закрывается сессия TCP.

Когда Receiving Speaker обнаруживает разрыв соединения TCP для сессии BGP с партнером, анонсировавшим Graceful Restart Capability, он должен сохранить полученные от партнера маршруты для всех семейств адресов, которые были получены в Graceful Restart Capability, и должен пометить их как «замороженные». При обработке последующих перезапусков маршруты (от партнера), помеченные ранее как «замороженные», должны быть удалены. Маршрутизатору недопустимо при пересылке отличать «замороженную» маршрутную информацию от другой.

В восстановленной сессии принимающему узлу недопустимо устанавливать бит Restart State возможности Graceful Restart Capability в сообщении OPEN, если сам этот узел не перезапускался. Наличие и значение бита Forwarding State для семейства адресов зависит от реального состояния пересылки и конфигурации.

Если сессия не была восстановлена с течение интервала Restart Time, ранее анонсированного партнером, принимающий узел должен удалить все «замороженные» маршруты от этого партнера.

Узел BGP может иметь тот или иной способ проверки жизнеспособности состояния пересылки своего партнера, например с помощью [BFD]⁵ или данных мониторинга на канальном уровне. Детали таких механизмов выходят за рамки этого документа. Если нежизнеспособность состояния пересылки партнера будет определена до восстановления сессии, узел может удалить все «замороженные» маршруты от этого партнера.

Если после восстановления сессии бит Forwarding State для конкретного семейства адресов не установлен во вновь полученной возможности Graceful Restart Capability, конкретное семейство адресов не включено в Graceful Restart Capability или сама эта возможность не получена в восстановленной сессии, Receiving Speaker должен незамедлительно удалить все «замороженные» маршруты от партнера для этого семейства адресов.

Принимающий узел должен передать своему партнеру маркер End-of-RIB по завершении начального обновления для семейства адресов (включая отсутствие обновлений).

Принимающий узел должен заменить «замороженные» маршруты полученными от партнера обновлениями. После получения от партнера маркера End-of-RIB для семейства адресов принимающий узел должен незамедлительно удалить все маршруты от партнера, помеченные как «замороженные» для семейства адресов.

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

5. Изменения в конечном автомате  BGP

Как отмечено в параграфе «4.2. Процедуры для принимающего узла», этот документ меняет конечный автомат  BGP.

Конкретные изменения, вносимые в параграф 8.2.2 [BGP-4] приведены ниже.

Состояние Idle

Текст:

• инициализировать все ресурсы BGP для соединения с партнером;

Заменяется текстом:

• инициализировать все ресурсы BGP для соединения с партнером, кроме ресурсов, требуемых для сохранения маршрутов в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

Состояние Established

Текст:

В ответ на индикацию завершения организации соединения TCP (Событие 16 или 17) следует отслеживать второе соединение, пока не будет передано сообщение OPEN.

Заменяется текстом:

Если возможность Graceful Restart Capability с одним или несколькими AFI/SAFI не была получена для этой сессии, в ответ на индикацию завершения организации соединения TCP (Событие 16 или 17) нужно отслеживать второе соединение, пока не будет передано сообщение OPEN.

Однако если в сессии была получена возможность Graceful Restart Capability с одним или несколькими AFI/SAFI, в ответ на событие 16 или 17 локальная система будет:

• сохранять все маршруты, связанные с соединением, в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

• освобождать все остальные ресурсы BGP;

• сбрасывать соединение TCP, связанное с организованной (ESTABLISHED) сессией,

• инициализировать все ресурсы BGP для соединения с партнером, кроме ресурсов, требуемых для сохранения маршрутов в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

• устанавливать ConnectRetryTimer = 0;

• запускать таймер ConnectRetryTimer с начальным значением;

• переходить в состояние Connect.

Текст:

Если локальная система получает сообщение NOTIFICATION (Событие 24 или 25) или сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP, она будет:

• устанавливать ConnectRetryTimer = 0;

• удалять все маршруты, связанные с соединением;

• освобождать все ресурсы BGP;

• сбрасывать соединение TCP;

• увеличивать значение ConnectRetryCounter на 1;

• переходить в состояние Idle.

Заменяется текстом:

Если локальная система получает сообщение NOTIFICATION (Событие 24 или 25) или сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP, а возможность Graceful Restart с одним или множеством AFI/SAFI не была получена в этой сессии, локальная система будет:

• устанавливать ConnectRetryTimer = 0;

• удалять все маршруты, связанные с соединением;

• освобождать все ресурсы BGP;

• сбрасывать соединение TCP;

• увеличивать значение ConnectRetryCounter на 1;

• переходить в состояние Idle.

Однако если локальная система получает TcpConnectionFails (Событие 18) от нижележащего TCP и возможность Graceful Restart Capability с одним или несколькими AFI/SAFI была получена в этой сессии, локальная система будет:

• устанавливать ConnectRetryTimer = 0;

• сохранять все маршруты, связанные с соединением, в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

• освобождать все ресурсы BGP;

• сбрасывать соединение TCP;

• увеличивать значение ConnectRetryCounter на 1;

• переходить в состояние Idle.

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

Хотя описанные здесь процедуры помогают минимизировать влияние маршрутных перебоев, отмечено, что при перезапуске маршрутизатора, поддерживающего BGP Graceful Restart или при перезапуске без сохранения состояния пересылки (например, при сбое питания) возможны временные маршрутные петли или «черные дыры» в сети, если маршрутные данные меняются до того, как вовлеченные маршрутизаторы завершат обновление или схождение маршрутов. Если не все маршрутизаторы IBGP поддерживают Graceful Restart, в зависимости от топологии может увеличиваться вероятность возникновения петель и «черных дыр» при выполнении процедуры Graceful Restart.

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

В заключение следует отметить, что преимущества развертывания BGP Graceful Restart в автономной системе, где протоколы IGP и BGP тесно связаны (т. е. будут перезапускаться совместно), а IGP не имеет возможности, подобной Graceful Restart Capability, снижаются по сравнению с ситуацией, где IGP имеют похожую возможность.

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

Поскольку при использовании этого предложения новое соединение может вызывать разрыв имеющегося, это может «открыть дверь» для атак на отказ служб. Однако уже отмечено, что протокол BGP без проверки подлинности уязвим для атак на службы через атаки на транспорт TCP. Обычно транспорт TCP защищают с помощью [BGP-AUTH]. Такая проверка подлинности будет защищать и от атак на службы путем организации ложных новых соединений.

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

Таким образом, можно считать, что данное предложение не меняет базовую модель (и имеющиеся проблемы) безопасности BGP-4.

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

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

Авторы благодарны Bruce Cole, Lars Eggert, Bill Fenner, Eric Gray, Jeffrey Haas, Sam Hartman, Alvaro Retana, Pekka Savola Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright и Alex Zinin за рецензии и замечания.

9. Взаимодействие с IANA

Этот документ определяет новую возможность BGP – Graceful Restart Capability, для которой выделен код 64.

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

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

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

[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, “Multiprotocol Extensions for BGP-4”, RFC 2858, June 2000.

[BGP-CAP] Chandra, R. and J. Scudder, “Capabilities Advertisement with BGP-4”, RFC 3392, November 2002.

[BGP-AUTH] Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option”, RFC 2385, August 1998.

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

[IANA-AFI] http://www.iana.org/assignments/address-family-numbers

[IANA-SAFI] http://www.iana.org/assignments/safi-namespace

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

[BFD] Katz, D. and D. Ward, “Bidirectional Forwarding Detection”, Work in Progress⁶.

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

Srihari R. Sangli

Cisco Systems, Inc.

EMail: rsrihari@cisco.com

Yakov Rekhter

Juniper Networks, Inc.

EMail: yakov@juniper.net

Rex Fernando

Juniper Networks, Inc.

EMail: rex@juniper.net

John G. Scudder

Juniper Networks, Inc.

EMail: jgs@juniper.net

Enke Chen

Cisco Systems, Inc.

EMail: enkechen@cisco.com

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

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

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, THE IETF TRUST 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 обеспеченоInternet Society.