Кратко

  • AMS-IX эксплуатирует в Амстердаме два маршрутных сервера под AS6777 — rs1.ams-ix.net и rs2.ams-ix.net; участие означает сессию с обоими.
  • Норма делает обязательным ровно одно поведение — передачу NEXT_HOP без изменений — и оставляет сохранность AS_PATH и MED на уровне рекомендаций с прямо названной причиной.
  • Единственное явное распределение ответственности в опубликованных материалах возлагает согласованность списка префиксов и соответствие конфигурации на участника.

Сеть, подключающаяся к маршрутному серверу амстердамской площадки, перестаёт строить по сессии на каждого пира и строит одну — к машине, которая переобъявляет то, что объявляют остальные. AMS-IX публикует две: rs1.ams-ix.net на 80.249.208.255 и 2001:7f8:1::a500:6777:1, rs2.ams-ix.net на 80.249.209.0 и 2001:7f8:1::a500:6777:2, обе под AS6777. Условия конкретны: подключиться к обеим, объявлять одинаковое число и длину префиксов в каждой сессии, открыть TCP-порт 179. Документация AMS-IX по маршрутному серверу перечисляет это без обиняков.

Чего эта документация не делает — она не обязывает оператора симметричным набором гарантий. Она описывает поведение. Обязанности, которые она перечисляет, принадлежат участнику.

Единственное, о чём норма не торгуется

RFC 7947 определяет маршрутный сервер точки обмена, и его самое жёсткое требование касается адреса: «the NEXT_HOP attribute MUST be passed unmodified» (раздел 2.2.1, сентябрь 2016 года). Эта фраза объясняет, почему маршрутный сервер не является маршрутизатором ни в каком смысле, существенном для пакета. Следующий узел, который видит клиент, — адрес объявившего пира на коммутационной фабрике, поэтому трафик идёт по фабрике от пира к пиру и никогда не проходит через машину, говорившую BGP от его имени. RFC 7948, эксплуатационный документ того же месяца, проводит ту же границу: распространение информации о достижимости — не пересылка трафика.

Всё остальное в разделе об атрибутах мягче, и намеренно. Маршрутный сервер «SHOULD NOT prepend its own AS number» — не должен добавлять собственный номер AS к тому, что он передаёт (раздел 2.2.2.1). Он распространяет MULTI_EXIT_DISC и «SHOULD NOT modify its value» (раздел 2.2.3). Раздел 2.2 задаёт прозрачность атрибутов по умолчанию и прямо допускает исключения там, где этого требует локальная конфигурация; раздел 2.1 попросту разрешает фильтрацию по политике.

Сам RFC называет причину, по которой по AS_PATH он останавливается на SHOULD, а не на MUST: существует реальный парк старых клиентов, отвергающих сессию с неожиданным первым AS, и обязательное правило оставило бы их за бортом. Поэтому норма требует от реализаций дать возможность отключить проверку первого AS, желательно для каждого пира отдельно, вместо того чтобы брать на себя более тяжёлую гарантию. Это инженерный компромисс в одежде уровня требований, и он важен каждому, кто полагал, что площадка приняла абсолютную обязанность не касаться атрибутов его пути.

Что оператор действительно фиксирует

AMS-IX публикует свою половину договорённости. Сервер не вставляет AS6777 в AS_PATH передаваемых маршрутов, а проверки первого AS должны быть отключены там, где это применимо. Пиры для экспорта выбираются через записи RPSL и сообщества: сообщество 0:6777 блокирует весь экспорт, 6777: включает выбранного пира, а новые сессии по умолчанию проходят совместную фильтрацию IRRDB и RPKI. Полученные маршруты могут обслуживать участника и его нижестоящих клиентов, но перераспространение их вышестоящим провайдерам, внешним пирам или маршрутному серверу другой точки обмена запрещено.

В этом тексте два предложения заслуживают второго прочтения. Первое предупреждает, что данные IRRDB и RPKI не дают гарантии достоверности и на них не следует полагаться в одиночку, — это собственное описание оператором той фильтрации, которую он применяет по умолчанию. Второе — пункт об ответственности: «Participants are responsible for ensuring that their routing configuration complies with this policy.»

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

Что я искала и что говорит текст

Я искала документированную сделку: одна сессия до каждого члена в обмен на опубликованный перечень того, что площадка тебе за это должна. Документы подтверждают только первую половину. Сделка реальна — число сессий действительно обваливается, — но платят за неё раскрытием, а не уровнями обслуживания. Категорическое MUST удерживает пакеты вне общего говорящего. Два SHOULD, аргумент о совместимости и открытая дверь для локальной конфигурации оставляют оператору свободные руки в выборе пути и в MED.

Поэтому полезное чтение не в том, что маршрутный сервер AMS-IX небрежен. Оно в том, что вещь спроектирована как администратор с ограниченным мандатом: ему позволено принимать решения на уровне управления, ему запрещено переслать хотя бы один пакет, и отвечает он в основном опубликованным текстом. Эта рамка моя, не IETF и не площадки, и никакая официальная позиция её не формулирует.

Что участник действительно может проверить

Запись справочника об этом маршрутном сервере собирает те же опубликованные факты в одном месте, и проблема проверки кроется именно в том, что они оставляют открытым. Участник не может проверить внутреннее соответствие общего говорящего, прочитав страницу политики. Что он может — читать маршруты, которые получает, и убеждаться, что видимый следующий узел принадлежит пиру, а не маршрутному серверу. Может наблюдать, дают ли 0:6777 и 6777: описанное поведение экспорта. Может держать обе сессии и сравнивать, что присылает каждый сервер, чтобы расхождение выглядело как расхождение, а не как загадка.

Документация не имеет даты в опубликованной версии, получена 12 ноября 2026 года, и её актуальность на момент публикации не подтверждена. Реальное поведение здесь не проверялось, и по просмотренной странице нельзя установить, одинаково ли работают умолчания фильтрации и управление экспортом через сообщества на rs1 и rs2. Найден ровно один явный пункт об ответственности, касающийся согласованности списка префиксов; отсутствие более широкой гарантии оператора на этой странице — наблюдение об этой странице, а не доказательство, что такого текста нет где-то ещё.

Честная сводка сделки

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