Кратко

  • Route Flap Damping, или RFD, отвечал на реальное ограничение раннего Интернета: повторяющиеся изменения BGP могли исчерпать небольшие вычислительные резервы маршрутизаторов и сами вызвать новую нестабильность.
  • Счётчик штрафа не различал хронически неисправный канал и перебор альтернативных путей, который BGP выполняет после обычного отзыва. Поэтому уже исправный префикс мог оставаться подавленным в сетях, не подконтрольных его держателю.
  • Действенная власть не принадлежала одной организации. Авторы RFC описали механизм, производители превратили параметры в исполняемое поведение, операторы решали, включать ли его.
  • После исследований задержек конвергенции практика прошла путь от согласованных параметров к рекомендации отключить прежний RFD, а затем к осторожным порогам. Предложенный селективный алгоритм не стал обычной заменой, зафиксированной в поздних рекомендациях.

Ремонт, посчитанный как три нарушения

В RIPE-229 описано плановое обновление программного обеспечения. Перезагрузка после обновления стала первым flap. Новая версия аварийно завершилась — вторым. Возврат к старой версии добавил третий. Три изменения за десять минут, но не бесконечная поломка: оператор попробовал обновление, обнаружил сбой и восстановил известное состояние.

Счётчик не мог распознать этот смысл. На некоторых транзитных и пиринговых границах действовали жёсткие параметры, сильнее наказывавшие более длинные префиксы. Документ сообщает, что /24 оператора, включая клиентские маршруты, подавлялись там более трёх часов. Действия по восстановлению создали ровно тот рисунок, который удалённые устройства считали повторным отказом.

Эпизод повлиял на согласованную рекомендацию. Участники RIPE 27 решили не начинать подавление до четвёртого последовательного flap и ограничить максимальный срок одним часом после последнего изменения. Это было мягче наблюдавшегося поведения. Но исправный /24 всё ещё мог исчезнуть на час после пересечения порога.

Почему первоначальный выбор был рационален

В начале 1990-х альтернативой RFD не был современный маршрутизатор с практически неограниченным запасом. Таблицы росли, межоператорские пути становились плотнее, а каждый отзыв обрабатывался устройствами с малой вычислительной мощностью. Волна обновлений могла привести к потере BGP-сессий; падение сессий создавало новые изменения и усиливало волну.

Операционные документы датируют разработку механизма 1993 годом, а реализации в Cisco, ISI/RSd и GateD — 1995-м. К публикации RFC 2439 в ноябре 1998 года техника уже присутствовала в коммерческих продуктах и широко применялась. Цели формулировались точно: снизить нагрузку, прекратить устойчивые колебания и не задерживать маршруты, которые обычно ведут себя нормально.

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

Общие параметры без единого командного центра

После RIPE 26 на RIPE 27 появилась рабочая группа. Параметры Tony Barber из UUNET легли в основу RIPE-178, а RIPE-229 пересмотрел их после случаев длительного подавления. Значит, ни RFC, ни одна встреча не были единственным источником механизма или его практического авторитета.

RFC 2439 описал штраф, его спад со временем, порог подавления и порог повторного использования. Но он не дал IETF или RIPE доступа к каждому маршрутизатору. Производители выбирали доступные настройки и значения по умолчанию. Операторы включали механизм и определяли, какие пути несёт их сеть. Их право управлять собственным маршрутизатором было реально; последствия решения выходили за его границы.

Так расходились формальная норма и практика. Документ описывал возможность. Программа превращала её в счётчик. Локальная конфигурация применяла его к конкретному префиксу. Если всю цепочку назвать «консенсусом», исчезает вопрос об ответственности. Профессиональное согласование помогает координации, но не равно централизованному юридическому мандату и не доказывает справедливого распределения затрат.

Вторичные flaps создавал сам BGP

Сильнейшее возражение основывалось на измерении, а не на догадке о мотивах. Mao и соавторы показали на SIGCOMM 2002, что один отзыв не обязательно проходит через сеть как одно событие. Во время конвергенции BGP перебирает альтернативные пути. Промежуточные изменения пути и атрибутов могут получать новые штрафы, хотя в исходной сети нового отказа не было.

В исследованных топологиях единственного отзыва с последующим объявлением хватало, чтобы префикс оставался подавленным до часа. В одном измеренном случае одно событие породило 41 видимое изменение пути. Получалось, что RFD оценивал не только исправность исходной сети, но также топологию, порядок сообщений и собственный поиск путей в BGP.

Исследователи предложили селективный алгоритм: не считать события, похожие на обычный path exploration, независимыми отказами, но ограничить время ожидания, чтобы настоящий нестабильный источник не получил бесконечной свободы. Это лучше соответствовало причинности. Однако требовало более сложной реализации. Повышение порога или отключение проще внедрить, объяснить и отменить.

Сначала отключение, затем более узкая настройка

В 2006 году RIPE-378 рекомендовал не использовать RFD по действовавшим рекомендациям. Документ указывал, что провайдеры не демонстрировали спроса на селективный алгоритм, производители не вели заметной реализации, а процессоры маршрутизаторов стали мощнее. Он не утверждал, что шум перестал иметь цену. Он фиксировал, что прежний баланс между защитой процессора и задержкой восстановления больше не оправдан.

Проект опроса 2012 года даёт ограниченные, а не всемирные данные. Из 63 самостоятельно откликнувшихся участников 13 применяли RFD, 49 — нет; 15 не применявших сослались на RIPE-378. Такая выборка не репрезентативна. Она всё же показывает, как операционный документ без обязательной силы мог стать точкой координации для решений об отключении.

На этом история не закончилась. RIPE-580 сравнил более осторожные параметры, а RFC 7196 в 2014 году описал, как сделать damping пригодным к применению. За неделю измерений в RIPE-580 порог 6000 сократил поток BGP-обновлений примерно на 19 процентов и затронул подавлением примерно на 90 процентов меньше префиксов, чем порог 2000. При 12000 подавлялись 0,22 процента префиксов, а поток обновлений снижался примерно на 11 процентов. Избирательность достигалась числами, не новой логикой.

RFC 7196 отдельно предостерёг от тихого изменения значений по умолчанию: оператор должен осознанно выбрать поведение. Для одной таблицы опубликовано подтверждённое информационное исправление, не меняющее главного вывода. Оба ограничения существенны. Улучшенный порог не создаёт подотчётности, если нельзя установить, какая версия и настройка реально действуют.

Право управлять было локальным, счёт — внешним

RIR подтверждает выделение номерного ресурса. Исходная сеть управляет объявлением через собственные связи. Но ни реестр, ни источник не имеют общей команды, заставляющей удалённую сеть принять путь. Удалённый оператор контролирует фильтры, выбор маршрутов и RFD. Производитель контролирует архитектуру настроек, значения по умолчанию и наблюдаемость. Органы стандартизации и операционные сообщества могут убеждать и координировать, но не переключают чужой маршрутизатор.

Подавляющая сеть получает прямую выгоду: меньше обновлений и ниже локальная нагрузка. Её соседи тоже могут выиграть, если погашена настоящая волна. Риск ложного подавления несут держатель префикса и его пользователи. Часто они не видят, какая сеть применила штраф, каково его значение и когда маршрут снова станет пригодным.

Политика, зависевшая от длины префикса, связала цель агрегации с более высокой ценой для небольших сетей. Исключения для так называемых «Golden Networks», включая часть инфраструктуры корневых DNS-серверов и TLD, показывали: участники понимали, что последствия ошибки неравны. Но исключение создавало новый вопрос о легитимности — кто получает статус критической инфраструктуры, а кто остаётся под общей формулой?

Источники