Кратко

  • RFC 1863 ранжировал серверы по числу информируемых клиентов: меньшая нагрузка давала меньший DelayTimer и вероятную, а не гарантированную победу.
  • Запись в списке informed clients выражала обязанность сервера отправлять маршруты, но не подтверждала получение, выбор, установку или полезную связность у клиента.
  • Клиент поглощал одинаковые дубликаты, а смена сервера должна была завершиться в пределах Hold Time. Позднее RFC 4223 зафиксировал отсутствие реализаций именно этой схемы.

После ожидания требовалось спросить ещё раз

RFC 1863 предложил в 1995 году BGP/IDRP route server как способ уменьшить число сессий полного mesh. Для резервирования клиент соединялся со всеми серверами кластера, хотя обычно обновления ему должен был посылать один.

Каждый сервер хранил собственный список информируемых клиентов и копии списков соседей. Их сортировали по числу клиентов, затем по адресу сервера. Если нового клиента нигде не было, сервер с позицией N ждал (N-1) × DelayGranularity. У менее загруженного ожидание было короче.

По истечении срока списки просматривались заново. Если свежая LIST показывала другого ответственного, сервер молчал. Иначе добавлял клиента к себе, планировал новую LIST и начинал рассылку. Повторная проверка уменьшала окно устаревшего состояния, но не делала распределённые копии атомарным реестром. Документ прямо признавал, что согласование не устраняет все гонки.

Сокращались соединения, не объём знания

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

Получение сервером, пересылка, получение клиентом, выбор, установка и фактическая доставка пакета поэтому остаются разными квитанциями. Центральный relay не наследует итог всей цепочки.

ADVERTISER переносил адрес пограничного маршрутизатора, первоначально представившего маршрут. Это сохраняло контекст политики, но не аутентифицировало источник. Раздел безопасности говорил, что документ не рассматривает такие вопросы. RCID_PATH между кластерами обнаруживал петли и удалялся перед обычными клиентами; это была внутренняя память пути, не универсальное доказательство происхождения.

Информируемый — заявление отправителя

LIST создавал сервер, считавший себя ответственным. Клиент не подтверждал ею конкретный UPDATE, хранение или выбор.

В состоянии Initiation сервер мог принимать сессии и обрабатывать входящие маршруты, но не рассылал их. Он ждал рекомендованные пять минут либо все настроенные внутрикластерные соединения и списки. Живая сессия ещё не означала согласованного права начать отправку.

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

Отказ запускал новую заявку на ответственность

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

Готовый титул владения от отказавшего узла не передавался. Ответственность восстанавливалась по оставшимся наблюдениям, а старый список удалялся лишь после согласования.

Максимальный DelayTimer вместе с межсерверным Hold Time рекомендовалось держать ниже двух третей минимального клиентского Hold Time. Пример для трёх серверов использовал 90 секунд у клиента, 30 между серверами и гранулярность 15. Неравенство сохраняло время для работы, но не доказывало актуальность таблицы или непрерывность трафика.

Исторический статус закрыл вопрос реализации

Запись RFC Editor теперь помечает RFC 1863 как Historic. RFC 4223 в 2005 году сообщил, что реализаций определённого RFC 1863 route server не существует и как альтернатива full mesh он не используется.

Другие значения термина route server были явно вне этого вывода. RFC 4223 назвал route reflection, BGP confederations и частные AS среди действующих альтернатив. RFC 2796 и RFC 4456 описывают reflectors, выбирающие лучший путь и использующие другие атрибуты против петель; RFC 3065 — confederations. Это не скрытые реализации RFC 1863.

Отсутствие реализации не опровергает каждую идею. Оно доказывает более узкое: таймеры, разделения и восстановление этой схемы не получили операционной проверки. Спецификация описала желаемый переход, но running code не подтвердил его при потерях, разделениях и разных часах.

Где заканчивалось доказательство

Сессия подтверждала управляющее соединение. LIST — текущую претензию сервера на обязанность. Короткий таймер повышал шанс первого действия. Повторная проверка сокращала устаревшие решения. Идентичная замена сдерживала дубль. Hold Time оставлял окно восстановления.

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

Источники