Кратко

  • Спокойная глобальная таблица маршрутов в схеме RFC 2260 означает лишь то, что часть стоимости отказоустойчивости не вынесена в бездефолтную зону. Она может находиться в адресации, внутренних проверках, межпровайдерской координации, туннелях или выборе более длинного пути.
  • Базовая схема сохраняет провайдерскую агрегацию в штатном режиме. При отказе предприятие либо временно объявляет более специфичный префикс через другой канал, либо использует недиректный EBGP и инкапсуляцию, либо сочетает эти способы с ограниченным распространением дополнительных маршрутов.
  • Сообщение BGP подтверждает только действие плоскости управления. Само по себе оно не доказывает принятие маршрута оператором, его глобальное распространение, корректную пересылку пакетов, сохранение транспортной сессии или доставку приложения.

Резервирование без бесплатного обеда

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

В январе 1998 года Tony Bates и Yakov Rekhter опубликовали Informational RFC 2260 — описание стратегий адресации и маршрутизации для предприятий, подключённых к нескольким интернет-провайдерам. Документ исходил из проблемы масштаба: если каждому такому предприятию понадобится отдельный маршрут в каждом бездефолтном маршрутизаторе, рост глобального состояния окажется неудовлетворительным. Поэтому проектный вопрос формулировался не как «можно ли убрать стоимость многопровайдерского подключения», а как «где она должна находиться и кто будет ею управлять».

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

Штатный режим: агрегация покупается адресной зависимостью

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

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

Первый счёт — зависимость от выделившего адреса провайдера. При смене провайдера ту часть сети, которая использовала его блок, требуется перенумеровать. RFC 2260 трактовал это как следствие модели заимствования адресов, описанной в RFC 2008, а не как особое исключение для multihoming. NAT был упомянут как возможный ответ на некоторые вопросы назначения адресов и перенумерации, но многопровайдерский NAT прямо оставался за пределами документа. Следовательно, его нельзя незаметно превратить в недостающий механизм этой конструкции.

Документ утверждал, что стратегии применимы и к IPv4, и к IPv6. Это архитектурное утверждение, а не доказательство одинакового внедрения, эксплуатационной зрелости или результатов в обоих протоколах.

Отказ: дополнительный маршрут как временный счёт

В варианте автоматического добавления маршрута пограничный маршрутизатор наблюдает состояние другого провайдерского пути. Пока тот считается доступным, он объявляет своему непосредственно подключённому провайдеру только «родной» префикс. Когда удалённая связность исчезает, тот же маршрутизатор начинает объявлять через уцелевшего провайдера префикс, выданный отказавшей стороной. В бездефолтную зону на время отказа попадает дополнительная информация.

В примере с двумя провайдерами маршрутизатор со стороны ISP-A объявляет только Pref-A, пока множества маршрутов, наблюдаемые через ISP-A и ISP-B, имеют непустое пересечение. Если пересечение становится пустым, он также объявляет Pref-B через ISP-A. После восстановления пересечения дополнительное объявление отзывается.

Эта логика превращает отказоустойчивость в конечный автомат: наблюдать, обнаружить изменение, добавить маршрут, дождаться восстановления, удалить маршрут. Каждый переход требует корректного сигнала. RFC предлагал IBGP и сравнение достижимых маршрутов как один из способов определить состояние. Поскольку вычисление пересечения больших множеств может быть дорогим, документ допускал наблюдение за одним или несколькими выбранными префиксами магистрали провайдера. Исчезновение такого контрольного префикса через IBGP становилось триггером для добавления удалённого префикса предприятия.

Упрощение проверки создаёт собственную неопределённость. Наблюдаемый префикс — индикатор, а не сама доступность всех назначений. Его присутствие или отсутствие может не совпасть с состоянием пути, который важен конкретному приложению. Более того, фильтры по длине префикса способны отсечь временное более специфичное объявление. RFC прямо предупреждал, что из-за этого нельзя считать полную интернет-достижимость гарантированной.

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

Недиректный EBGP: тихая таблица, активная локальная машина

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

Когда прямой канал между ISP-B и предприятием отказывает, трафик к Pref-B всё ещё приходит в ISP-B. Затем его инкапсулируют и направляют через уцелевшую сторону, где пакет декапсулируется и передаётся внутрь сети предприятия. Для GRE документ ссылался на RFC 1773.

При такой организации отказ предприятия не обязан создавать новый специфичный маршрут в бездефолтной зоне и не сталкивается с фильтрацией длины временно добавленного префикса. Однако исчезновение глобального маршрута из счёта оплачивается недиректной BGP-сессией, правилами предпочтения, туннельным состоянием, внутренней доставкой и согласованными действиями разных операторов. Раздел безопасности требует подходящей аутентификации для многошаговых EBGP-сессий. Вопросы защиты IBGP и одношагового EBGP документ не рассматривал.

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

Оптимальность пути — отдельная покупка

Недиректный EBGP уменьшает дополнительное глобальное состояние, но после отказа может привести к неоптимальному пути. Даже в штатном режиме объявление только непосредственно выделенного префикса способно удлинить маршрут: клиент одного провайдера идёт к узлу предприятия, адресованному из блока другого провайдера, через топологически не лучший вход.

Предприятие может объявлять дополнительные провайдерские префиксы, чтобы улучшить входной путь. Но более широкая видимость маршрутов снова увеличивает состояние, а плохо ограниченное распространение способно создать значительную нагрузку в бездефолтной части Интернета. RFC 2260 поэтому предлагал сочетать недиректный EBGP с изменённым автоматическим добавлением, при котором дополнительные объявления распространяются лишь в заданных пределах. Одним из средств ограничения служит BGP Community, определённая RFC 1997.

Получается не одна шкала «есть резервирование — нет резервирования», а как минимум четыре независимых счёта:

  1. Адресный счёт. Провайдерские префиксы сохраняют агрегацию, но связывают часть нумерации с поставщиком и делают смену подключения задачей перенумерации.
  2. Счёт состояния маршрутов. Более специфичное объявление может дать обход отказа или улучшить выбор входа, но расширяет область, где маршрутизаторы должны хранить и обрабатывать изменение.
  3. Счёт координации и туннелей. Недиректный EBGP удерживает специфичное состояние вне глобальной таблицы, но требует сессий, аутентификации, инкапсуляции, политики предпочтения и согласованной эксплуатации.
  4. Счёт длины пути. Строгая агрегация и локализация состояния могут оставить трафику более длинный маршрут. Попытка купить лучшую траекторию дополнительной видимостью возвращает часть стоимости глобальной системе.

Ни один из вариантов не аннулирует остальные ограничения. Он только выбирает, какой системе и в какой момент предъявить платёж.

Сравнения, которые очерчивают границу

Провайдер-независимое пространство даёт предприятию один префикс, не зависящий от конкретного оператора, но его маршрут нельзя агрегировать в провайдерский блок. RFC 2260 характеризовал нагрузку в бездефолтной зоне как O(N) по числу многопровайдерских предприятий. Это сравнение не делает провайдерские адреса переносимыми: именно отказ от такой независимости позволяет базовой схеме удерживать префиксы внутри агрегатов.

Схема с одним префиксом одного провайдера, выборочно переносимым другими провайдерами, требует proxy aggregation, дополнительной межоператорской координации и более сложной конфигурации маршрутизаторов. Автоматическое добавление, напротив, делает изменение видимым каждому бездефолтному маршрутизатору, который получил более специфичный маршрут, и нуждается в мерах устойчивости при flapping. Недиректный EBGP локализует колебание, но вводит другой набор механизмов.

Позднейшие документы уточняют фон, не превращаясь в доказательство внедрения RFC 2260. RFC 2519 объясняет, что агрегация сокращает таблицы, обработку и область распространения колебаний, тогда как более специфичную информацию можно оставить локальной или пометить no-export. RFC 4116 относит подход RFC 2260 к multihoming с провайдер-агрегируемыми адресами: в базовой форме он не добавляет нагрузку в глобальную таблицу, но не удовлетворяет всем распространённым целям, особенно сохранению транспортных сессий. RFC 8678 уже в контексте IPv6 отмечает, что провайдерские адреса не добавляют PI-маршруты в глобальную таблицу, однако хостам и маршрутизаторам всё равно приходится согласовывать исходный адрес и выход. Его более поздние механизмы нельзя задним числом приписывать RFC 2260.

Что именно известно — и чего маршрут не доказывает

Источники подтверждают статус и содержание RFC 2260: предпосылку адресного заимствования, правило штатного объявления, триггер временного маршрута, возможную проверку состояния, конструкцию недиректного EBGP с инкапсуляцией, ограниченное распространение оптимизирующих маршрутов, последствия перенумерации и требование аутентификации многошаговой сессии.

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

Тихая глобальная таблица — важное инженерное свойство. Но в RFC 2260 она была следствием дисциплины размещения состояния, а не отсутствия стоимости. Чем меньше видимого глобального шума, тем внимательнее нужно искать локальную машину, которая его поглощает.