Network Working Group J. Hawkinson
Request for Comments: 1930 BBN Planet
BCP: 6 T. Bates
Category: Best Current Practice MCI
March 1996
Руководство по созданию, выбору и регистрации автономных систем
Guidelines for creation, selection, and registration of an Autonomous System (AS)
Статус документа
Этот документ является обобщением опыта (Internet Best Current Practices) для сообщества Internet и служит запросом к обсуждению темы в целях дальнейшего развития. Документ может распространяться свободно.
Аннотация
В этом документе рассматриваются вопросы регистрации и использования автономных систем (AS), а так же описаны предъявляемые к AS требования. Автономная система представляет собой элемент политики маршрутизации в современной среде внешней маршрутизации и, в частности, понятие AS применяется к протоколам типа EGP (Exterior Gateway Protocol – устаревший протокол, см. [EGP]), BGP (Border Gateway Protocol – современный стандарт de facto для маршрутизации между AS, см. [BGP-4]) и IDRP (OSI Inter-Domain Routing Protocol – предполагается, что этот протокол будет использоваться в Internet взамен BGP, см. [IDRP]). Следует отметить, что в протоколе IDRP эквивалентом автономной системы (AS) является идентификатор RDI (Routing Domain Identifier).
1. Введение
В этом документе обсуждаются вопросы регистрации и использования автономных систем, а также приводится список требований к AS. Автономная система представляет собой элемент политики маршрутизации в современной среде внешней маршрутизации и, в частности, понятие AS применяется к протоколам типа EGP (Exterior Gateway Protocol – устаревший протокол, см. [EGP]), BGP (Border Gateway Protocol – современный стандарт de facto для маршрутизации между AS, см. [BGP-4]) и IDRP (OSI Inter-Domain Routing Protocol – предполагается, что этот протокол будет использоваться в Internet взамен BGP, см. [IDRP]). Следует отметить, что в протоколе IDRP эквивалентом автономной системы (AS) является идентификатор RDI (Routing Domain Identifier).
2. Мотивация
Этот документ адресован сетевым операторам и поставщикам услуг, которые хотят понять, в каких случаях следует использовать AS. Предполагается, что читатель знаком с протоколами маршрутизации и имеет опыт настройки и использования сетей, связанных с Internet. К сожалению, существует много неясностей по вопросу использования AS в современных сетях – в этом документе делается попытка разъяснения этих вопросов и даны рекомендации по организации современной системы маршрутизации.
3. Определения
В документе постоянно будет использоваться термин «префикс» (prefix). В бесклассовой среде Internet (см. [CIDR]), сети классов A, B или C могут указываться префиксом и маской, пока такие сети начинаются и заканчиваются на границах, кратных степени 2. Например, сети:
192.168.0.0/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
можно указать как:
192.168.0.0/22
Термин «префикс» в контексте этого документа служит эквивалентом термина “CIDR block” и, говоря проще, может обозначать группу из одной или нескольких сетей. Термин «сеть» (network) в данном документе используется применительно к сетям класса A, B и C.
Определение AS, к сожалению, является весьма нечетким.
[BGP-4] содержит определение:
По классическому определению автономная система представляет собой множество маршрутизаторов с единым техническим администрированием, использующих один протокол внутренней маршрутизации (IGP) и единую метрику для маршрутизации пакетов внутри AS, а для передачи пакетов в другие автономные системы применяющих протокол внешней маршрутизации (exterior gateway protocol или EGP). Со временем классическое определение было расширено и в современном понимании AS может использовать несколько протоколов внутренней маршрутизации, а в некоторых случаях даже несколько наборов метрик в рамках одной AS. Использование термина AS в таких случаях обусловлено тем, что даже при использовании множества метрик и протоколов IGP администрирование такой AS с точки зрения других автономных систем выглядит как единый план внутренней маршрутизации и показывает согласованную картину доступности адресатов с использованием данной AS.
В более краткой форме это можно выразить следующими словами:
AS представляет собой группу из одного или нескольких префиксов IP, работающих у одного или нескольких сетевых операторов, которые имеют единую (SINGLE) и четко определенную (CLEARLY DEFINED) политику маршрутизации.
Политика маршрутизации (routing policy) в данном случае понимается как набор решений о пересылке (routing decisions), принимаемых в современной сети Internet. Эта политика представляет собой обмен маршрутной информацией, которая является субъектом политики маршрутизации, между AS. Рассмотрим случай обмена информацией двух AS – X и Y:
NET1 ...... ASX <---> ASY ....... NET2
ASX знает, как достигнуть префикс NET1. Не имеет значения, принадлежит NET1 автономной системе ASX или относится к другой AS, которая обменивается информацией с ASX (напрямую или косвенно) – мы просто предполагаем, что ASX знает, как пересылать пакеты в направлении NET1. Подобно этому ASY знает путь к NET2.
Для того чтобы трафик из NET2 в NET1 проходил между автономными системами ASX и ASY, система ASX анонсирует префикс NET1 в систему ASY, используя протокол внешней маршрутизации; это означает, что ASX будет принимать трафик, направленный в NET1, от автономной системы ASY. Политика начинает работать, когда ASX решает анонсировать NET1 в автономную систему ASY.
Для тог, чтобы передача трафика стала возможной, ASY следует воспринять полученную информацию и использовать ее. Система ASY сама решает, как ей поступать с полученной от ASX информации о доступности NET1 – использовать эти сведения или отбросить их. ASY может отказаться от использования полученных сведений, если из этой автономной системы не нужно передавать трафик в NET1 или имеется другой маршрут к NET1.
Для того чтобы трафик в направлении NET1 передавался между ASX и ASY, автономная система ASX должна анонсировать маршрут в ASY, а автономная система ASY должна принять анонс от ASX:
Поток трафика в направлении NET1 <<=================================== | | анонс NET1 | восприятие NET1 --------------> + -------------> | AS X | AS Y | <------------- + <-------------- восприятие NET2 | анонс NET2 | | Поток трафика в направлении NET2 ===================================>>
Идеальным, но не всегда практичным, решением является симметричные правила анонсирования и восприятия маршрутов для автономных систем ASX ASY.
Для того чтобы сделать возможной передачу трафика в направлении NET2, должно произойти анонсирование и восприятие NET2 (зеркальное отображение NET1). Для большинства приложений передача трафика лишь в одном направлении не имеет практической пользы.
Следует отметить, что при более сложной топологии трафик из NET1 в NET2 может идти по пути, отличному от маршрута из NET2 в NET1 (это называется асимметричной маршрутизацией). Асимметричная маршрутизация не должна рассматриваться как негативное явление, но она может вызывать проблемы в работе протоколов верхних уровней (например, TCP) и должна использоваться только при необходимости. Однако асимметричная маршрутизация может оказаться неизбежной для мобильных хостов (например, при использовании спутникового канала в одном направлении и модемной линии – в другом).
Политика не задается отдельно для каждого префикса, это можно делать для целых групп (такие группы префиксов являются автономными системами).
Автономная система AS имеет уникальный (в глобальном масштабе) идентификатор, который иногда называют ASN (Autonomous System Number – номер автономной системы); этот идентификатор используется как при обмене маршрутными данными между соседними AS, так и в качестве обозначения самой AS.
Автономная система обычно использует один или несколько протоколов внутренней маршрутизации (IGP) для передачи сведений о маршрутизации в пределах данной AS (см. главу 8. Вопросы внутренней маршрутизации (IGP).
4. Распространенные ошибки, связанные с AS
Термин AS зачастую ошибочно используют для обозначения групп префиксов, находящихся под единым администрированием, даже при использовании для этих префиксов различной политики маршрутизации. Подчеркнем, что термин AS должен использоваться только применительно к системе с единой политикой маршрутизации.
Очень важен осторожный и взвешенный подход к вопросу создания AS. Следует избегать неоправданного применения AS – примером неудачного использования является создание AS для отдельной сети того или иного класса (идеальной ситуацией является наличие одного префикса на AS, содержащего набор более длинных префиксов). Это может означать, что потребуется некоторая реорганизация для того, чтобы применить критерии и рекомендации по созданию и выделению AS, приведенные ниже. Эта реорганизация необходима, поскольку обеспечивает единственный способ реализации желаемой политики маршрутизации.
Если вы занимаетесь созданием AS, зарегистрируйте блоки адресов CIDR требуемого размера у вашего местного регистратора1 для минимизации числа префиксов, анонсируемых из вашей AS. Лучше всего, если анонсироваться будет единственный префикс.
Некоторые маршрутизаторы используют номер AS как форму меток для идентификации как внутренних, так и внешних маршрутов. Такие метки не обязаны быть уникальными, если нет обмена маршрутной информацией с другими AS (см. главу 8. Вопросы внутренней маршрутизации (IGP).
5. Когда нужна AS – критерии
Обмен внешней маршрутной информацией
AS должна использоваться для обмена внешней маршрутной информацией с другими AS на основе протокола внешней маршрутизации. Рекомендуемым протоколом внешней маршрутизации сегодня является протокол BGP (Border Gateway Protocol). Однако необходимость обмена внешней маршрутной информацией не является достаточным основанием необходимости AS (см. параграф 5.1 Примеры).
Множество префиксов в одной AS
Как общее правило рекомендуется помещать множество префиксов в одну AS, используя в ней единую политику маршрутизации.
Уникальная политика маршрутизации
AS является необходимой только в тех случаях, когда вы используете политику маршрутизации, отличающуюся от политики граничного маршрутизатора в соседней системе того же уровня (peer). В данном случае политика маршрутизации определяет, как остальная часть Internet будет принимать решение о маршрутизации на основе сведений из вашей AS. В параграфе 5.1 Примеры применение этого критерия рассматривается более детально.
5.1 Примеры
Однодомный сайт, один префикс
Отдельная AS не требуется, префикс должен быть размещен в AS провайдера. Префикс сайта использует такую же политику маршрутизации, как и сайты других заказчиков провайдера и, следовательно, нет необходимости в использовании каких-либо отличий в маршрутной информации.
Эта идея может многим не понравиться с первого взгляда, но она четко показывает использование номера AS в качестве представления политики маршрутизации, а не просто области единого администрирования.
В некоторых ситуациях отдельный сайт или часть сайта может счесть необходимым использование политики маршрутизации, отличающейся от политики провайдера или политики, применяющейся для остальной части сайта. В таких случаях для связанных с этой частью сайта префиксов должна создаваться отдельная AS. Такие ситуации достаточно редки и являются скорее исключением, нежели правилом. Поскольку AS является единицей политики маршрутизации, в некоторых случаях такой вариант все же может использоваться на практике.
Однодомный сайт, множество префиксов
Отдельная AS не требуется, префиксы должны быть размещены в AS провайдера.
Многодомный сайт
Многодомным в настоящем документе считается префикс или группа префиксов, соединенных с несколькими провайдерами (т. е., имеется более одной AS со своей политикой маршрутизации). Это не означает, что многодомным является сайт, использующий IGP в целях повышения уровня гибкости.
Для многодомных сайтов требуется организация AS и префиксы сайта должны быть частью единой AS, отличающейся от автономных систем провайдеров. Это дает возможность использовать представление политики маршрутизации, отличающееся от политики маршрутизации провайдеров.
Этот случай является почти единственным критерием необходимости создания AS. В этом случае сайт должен обеспечивать все необходимые атрибуты автономной системы и поддерживать подходящий протокол маршрутизации (например, BGP4).
5.2 Прочие факторы
Топология
На принятие решения о необходимости создания AS могут оказывать влияние и другие факторы – географическое расположение, соответствие правилам AUP (Acceptable Use Policy – правила допустимого использования), топология сети. Однако зачастую решение на основе этих критериев принимается без учета необходимости создания AS с точки зрения добавления информации в политику маршрутизации остальной части Internet. При использовании перечисленных здесь критериев следует принимать во внимание и остальные факторы, перечисленные в этой главе.
Создание AS «впрок»
Часто сайт подключается к одному провайдеру, но планирует в будущем использовать дополнительные каналы подключения. Такая перспектива не является достаточным основанием для создания AS. Пространство номеров AS ограничено и реорганизация сети, связанная с созданием AS должна рассматриваться как необходимый элемент при подключении к дополнительному провайдеру.
Исторические причины
Форма для получения номера AS исторически не связана с политикой маршрутизации. Однако достаточно часто AS создавались просто как «часть процесса» подключения к Internet. Этот документ явно показывает, что AS следует создавать только в случаях реальной необходимости.
6. Предложения
-
Если провайдер A и провайдер B широко представлены в географической области (или иной области маршрутизации) и множество заказчиков подключены к обоим провайдерам, имеет смысл включить всех таких заказчиков в одну AS. Однако на практике такое решение возможно только при достаточном уровне координации между заказчиками и провайдерами.
-
Сайты не должны представлять себя как AS просто потому, что они могут принимать решения о политике маршрутизации на базе AS. Несмотря на это, в некоторых случаях может потребоваться разделение одного префикса или AS на две автономные системы из соображений политики маршрутизации. Однако в таких случаях окончательное решение остается за сетевым оператором, который управляет префиксами и AS, содержащими эти префиксы. Т. е., реализация желаемой политики маршрутизации возможна не во всех случаях.
7. Один префикс, одна исходная AS
В общем случае префикс должен относиться только к одной AS. Это является прямым следствием того факта, что каждая точка в сети Internet может иметь ровно одну политику маршрутизации для трафика, адресованного каждому префиксу. В тех случаях, когда один префикс используется в двух соседних AS одного ранга, возникает неоднозначность при решении вопроса о том, к какой AS реально относится префикс.
С учетом возможности агрегирования следует принимать во внимание, что префикс может относиться к нескольким AS, однако это является скорей исключением, чем правилом. Такие ситуации встречаются, когда при агрегировании используется атрибут AS_SET протокола BGP там, где его смысл теряется. В некоторых случаях значение исходной AS теряется при наличии менее специфичного атрибута агрегирования ATOMIC_AGGREGATE.
8. Вопросы внутренней маршрутизации (IGP)
Как было сказано выше, маршрутизаторы многих фирм требуют использования идентификатора в качестве метки для своих процессов IGP. Однако такая метка не обязана быть уникальной в глобальном масштабе. На практике эту информацию протоколы внешней маршрутизации никогда не видят. Если вы уже используете протокол внешней маршрутизации, разумно применять номер вашей AS в качестве метки IGP, если же протокол внешней маршрутизации не применяется, можно использовать значения идентификаторов из специально выделенного диапазона (см. параграф 10. Зарезервированные номера AS). Факт использования IGP не является достаточным основанием для регистрации номера AS.
При использовании BGP4 протокол IGP становится необходимым для передачи информации о бесклассовых маршрутах. Примеры этого включают OSPF [OSPF] и ISIS [ISIS].
9. Нехватка номеров AS
Пространство номеров AS весьма ограничено. В настоящее время номера автономных систем определены как 16-битовые целые числа, следовательно, число номеров AS не может превысить 65535 уникальных значений. Сейчас распределены около 5100 AS, но реально для активной маршрутизации в глобальных масштабах Internet используется чуть меньше 600 номеров2. Очевидно, что расширение числа автономных систем должно контролироваться. Однако если следовать рассмотренным выше критериям, не возникает опасений нехватки пространства номеров AS. Предполагается, что протокол IDRP будет реализован до того, как все номера будут исчерпаны. Протокол IDRP не задает фиксированного размера RDI3.
10. Зарезервированные номера AS
Агентство IANA зарезервировало блок номеров AS для использования в частных сетях (эти номера не анонсируются в глобальной сети Internet). Зарезервированный блок включает номера с 64512 по 65535.
11. Вопросы безопасности
Выбор AS слабо связан с обеспечением безопасности.
Информация о выделенных номерах AS является общедоступной (ее можно получить с помощью WHOIS) и попытки подмены номеров автономных систем могут приводить лишь к путанице при маршрутизации трафика IP в сеть Internet у тех, кто пытается использовать подменные номера AS.
12. Благодарности
Этот документ основан на работе [RIPE-109] и предназначен для более широкого распространения опыта сообщества RIPE. Без [RIPE-109] данного документа просто бы не было.
13. Литература
[RIPE-109] Bates, T., Lord, A., “Autonomous System Number Application Form & Supporting Notes”, RIPE 109, RIPE NCC, 1 March 1994. URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt.
[BGP-4] Rekhter, Y. and T. Li, “A Border Gateway Protocol 4 (BGP-4)”, RFC 16544, T.J. Watson Research Center, cisco Systems, July 1994.
[EGP] Mills, D., “Exterior Gateway Protocol Formal Specifications”, STD 18, RFC 904, International Telegraph and Telephone Co., April 1984.
[IDRP] Kunzinger, C., Editor, “OSI Inter-Domain Routing Protocol (IDRP)”, ISO/IEC 10747, Work In Progress, October 1993.
[CIDR] Fuller, V., T. Li, J. Yu, and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy”, RFC 1519, BARRnet, cisco, MERIT, OARnet, September 1993.
[OSPF] Moy, J., “OSPF Version 2”, RFC 15836, March 1994.
[ISIS] Callon, R., “Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments”, RFC 1195, Digital Equipment Corporation, December 1990.
14. Адреса авторов
John Hawkinson
BBN Planet Corporation
150 CambridgePark Drive
Cambridge, MA 02139
Phone: +1 617 873 3180
EMail: jhawk@bbnplanet.com
Tony Bates
MCI
2100 Reston Parkway
Reston, VA 22094
Phone: +1 703 715 7521
EMail: Tony.Bates@mci.net
Перевод на русский язык
Николай Малых
2 Данные относятся к 1996 году, когда был создан документ. Прим. перев.
3 Эквивалент номера AS. Прим. перев.
4Этот документ устарел и признан утратившим силу. Действующая спецификация протокола опубликована в RFC 4271 (на сайте www.protokols.ru имеется перевод этого документа на русский язык). Прим. перев.
5Перевод этого документа имеется на сайте www.protokols.ru. Прим. перев.
6Этот документ устарел и признан утратившим силу. Действующая спецификация протокола опубликована в RFC 2328 (на сайте www.protokols.ru имеется перевод этого документа на русский язык). Прим. перев.