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

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

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

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

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


Йоб Шнайдерс, IP Development Engineer в NTT Communications, основатель NLNOG RING, вице-президент 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» (термин, объединяющий один язык разных этнических групп) между сетевыми операторами, однако какой-либо международной договорённости не существует. Некоторые сетевые операторы используют приватные 2-байтные ASN в первых двух байтах RFC 1997 communities, а другие операторы используют Extended BGP Communities не по назначению. Итогом являются «не самые лучшие» методы, вредяющие операторскому сообществу.

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

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

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

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

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