Йоб Шнайдерс, NTT: «Large BGP Communities — решение проблемы роутинга между операторами AS»

В августе текущего года в архивах IETF ^[1] появилось обсуждение ^[2] способов решения проблемы обмена мета-информацией между автономными системами (AS) по методу RFC1997 BGP communities.

Дело в том, что интернет опять угрожает «кончиться», причём самым неожиданным образом — из-за «скелета в шкафу» или частного, но широкого, случая иллюстрирующего, насколько серьёзной может быть проблема технического долга, известная любому разработчику. Сначала мы наблюдали проблему исчерпания пула IPv4 адресов, в качестве решения которой был введён в эксплуатацию не на 100% функционирующий стандарт IPv6. Теперь на наших глазах назревает другая опухоль, связанная, однако, всё с той же сетевой маршрутизацией.

Написанное Йобом Шнайдерсом из компании NTT ^[3] открытое письмо к IETF служит стартом общественного обсуждения проблемы, угрожающей вскоре стать критической. Дело в том, что основное удобство RFC1997 — 32-битность записи. Первые 16 бит принадлежат ASN, последние 16 несут в себе какое-то значение. Однако уже сейчас один из пяти операторов автономных систем в сети имеет 4-байтный ASN (RFC4893) (4 байта = 32 бита), что делает невозможным использование 16-битной записи (32-битное значение просто не влазит).

Примером Large BGP Community является: 2914:1299:40.

Мы обратились напрямую к Йобу Шнайдерсу за комментарием по данной проблеме.

Йоб Шнайдерс ^[4], IP Development Engineer в NTT Communications, основатель NLNOG RING ^[5], вице-президент PeeringDB.

— Йоб, в двух словах, вы можете объяснить почему larger BGP community является решением данной проблемы?

Всё просто: RFC 1997 BGP Communities это то что используют все ISP (интернет-провайдеры) для обмена мета-информации между автономными системами. Стиль RFC 1997 предлагает вам 2 байта, новые Large Communities — 8 байтов, что отвечает требованиям многих операторов.

— Почему проблема усугубляется с каждым новым размещённым ASN?

IANA исчерпала 2-байтные ASN, поэтому по-умолчанию вам присвоит 4-байтный ASN, только если вы не попросите иначе. Это значит, что использование лучших практик, таких как communities, для внутренней разметки и роутинга будет вам недоступно. По-крайней мере стандартными способами, как это делают другие операторы и сети. Нельзя просто увеличивать сложность сетевых политик используя существующие документы — это повышает вероятность ошибок.

— Как эта проблема влияет на интернет-провайдеров и обычных пользователей?

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

— Как можно понять или протестировать наличие проблемы?

Если у вас есть BGP-сессия с 4-байтным ASN или вам был присвоен 4-байтный ASN организацией RIPE NCC, то вас это касается. Это лимитирует варианты, которые вы можете предоставить потребителям, так как необходимо использовать либо частный номер, либо захватывать чужой

— Существует ли какой-то способ избежания или решения проблемы?

На сегодняшний день не существует хорошего способа избежания проблемы. RFC 1997 BGP communities это некоторая «Lingua Franca» ^[6] (термин объединяющий один язык разных этнических групп) между сетевыми операторами, однако какой-либо международной договорённости не существует. Некоторые сетевые операторы используют приватные 2-байтные ASN в первых двух байтах RFC 1997 communities, а другие операторы используют Extended BGP Communities не по назначению. Итогом являются «не самые лучшие» методы, вредяющие операторскому сообществу.

— Наконец, почему это срочно?

Именно из-за исчерпания IANA номеров для AS. Ваш локальный RIR, ARIN, APNIC, Afrinic, LACNIC и RIPE больше не будут иметь ресурсов для обмена. Раньше они разрешали сетям с проблемами возвращать 32-битный ASN взамен 16-битных, но и эта опция для них скоро закроется.

Любой желающий стать частью процесса должен присоединиться к рассылочному листу IDR ^[2] и прочитать архив. IETF будет голосовать по данной проблеме вплоть до 20 сентября.

» Спецификация ^[7] Large BGP Communities на IETF.
» Веб-страница Large BGP Communities ^[8].

За поддержкой Large BGP communities обращайтесь к своему вендору.

Автор: Shapelez

Источник ^[9]