Размер имеет значение: пытаемся сократить BGP full-view
Количество глобально анонсируемых сетей в BGP растёт и это ни для кого не секрет. На текущий момент количество префиксов в full-view больше 650000. Является ли это проблемой, может быть и нет для кого-то, но 13 августа 2014 года показало обратное. Популярное решение при стандартных настройках не смогло вместить 512k маршрутов из-за чего случился совсем не локальный апокалипсис и даже то, что об этом предупреждали заранее, никак не спасло ситуацию.
Тривиальный способ не расходовать ресурсы для хранения всех маршрутов в интернет — не хранить все маршруты в интернет. Для интернет-провайдеров за пределами tier’ов это вполне допустимо, наличие 1 аплинка решает проблему в корне. Но что если аплинков 2-3 и хочется всё же иметь актуальную маршрутную информацию, иными словами как сократить распухший full-view и сохранить связность в том виде, в котором она и была. Доступным инструментом для нас являются фильтры, поэтому задача стоит отфильтровать лишнее при полном сохранении актуальности всех направлений, какие были до фильтрации.
Скажу сразу, что при потенциальной возможности сделать это, какого-либо ощутимого результата (я для себя поставил планку минус 100000 префиксов при полном сохранении исходных маршрутов) мне добиться не удалось.
Теория
Начнём издалека. Посмотрим, что же представляет собой BGP full-view на текущий момент, для чего любезно воспользуемся снимком сохраняемом на сайте (я взял данные за 3 июля 18-00).
Больше половины всей таблицы оккупированы сетями по /24. Т.е. наименьшим глобально маршрутизируемым блоком занято больше всего места. Дальше будем обсуждать преимущественно его. Можно предположить, что многие конечные держатели IP сетей имеют в распоряжении только непоследовательные блоки по /24, но при том что различных ASN всего 54615 это не очень вероятный сценарий.
В своей практике мне доставались блоки, которые кроме как разбив на /24 маршрутизировать невозможно. Записи inetnum в RIPEDB задают не сети, а непрерывный список адресов, который не всегда попадает на границы сети. Но чаще /24 это more-specific маршруты, в ситуации, когда остальные механизмы в BGP не работают и один из немногих способов управлять входящим трафиком. Что ж, если это так, тогда они должны легко агрегироваться в свои более полные версии, собственно на этом и основано предположение о возможности сократить full-view без потерь.
Чтобы проверить это предположение надо агрегировать исходную таблицу с учётом наличия более длинных префиксов, которые могут включаться в более короткие. И можно увидеть несколько ситуаций:
- Префиксы всегда анонсируются more-specific, то есть исходная AS для всех своих аплинков предлагает одинаковые объявления маршрутов;
- Префиксы анонсируются more-specific только для какого-то из аплинков, при этом другие аплинки получают полный маршрут;
- Ситуация со стороны не домашней AS, т.е. неважно как префиксы анонсируются, важно как мы их получаем со своих аплинков, то есть можем их агрегировать произвольно;
Что ж, приступим к расчётам. В качестве контрольной идеальной ситуации рассчитаем ещё и вариант, когда мы агрегируем префиксы не только включением в более короткие, но и путём сложения подряд идущих подсетей. В этом случае получаем 106638 префиксов — в 6 раз меньше исходного количества, это теоретический предел при полном контроле за анонсами и суммированием, вариант недостижимый. А вот так как дела обстоят с нашими потенциальными ситуациями.
Ожидаемо, меньше всего агрегировалось префиксов с учётом анонсов аплинков (красный столбец), наше предположение об использовании more-specific подтверждаются, но в тоже время многие AS анонсируют префиксы, которые вообще не агрегируются (синий столбец). В частности, самый большой блок /24 сократился менее чем на 50%, то есть большинство анонсов /24 автономно и никак не покрывается более коротким префиксом от того же провайдера. Эта новость, по сути, похоронила некоторые надежды на позитивный результат. Самый невероятный вариант, что многие сети имеют несмежные блоки по /24 или не предпринимают никакие действия по объединению этих блоков, становится не таким уж и надуманым.
Но ещё хуже дела обстоят, если рассматривать третью нашу ситуацию, по моим ожиданиям объединение должно было достигнуть границы в 70-80%%, так как в этом случае префиксы объединялись, несмотря на различные родительские AS. В итоге, даже в этом случае /24 не агрегируются полностью в более короткие префиксы. В голову приходит только одно разумное объяснение, таблица настолько фрагментирована и адреса выдаются так непоследовательно, что многие участники интернет просто не в состоянии объединить разрозненные сети даже при наличии иерархии, и вынуждены использовать то, что им досталось.
Рассматривая абсолютные значения, мы видим сокращение в лучшем случае с 354146 /24 до 153164, что в 6 раз хуже нашего контрольного варианта. К сожалению, такой исход нам никак не позволяет произвести фильтрацию всех /24 одним правилом. Но пока мы находимся в границах наших условий — сократить на 100000, поэтому двинемся дальше и посмотрим что же внутри /24.
Больше всего раздроблен блок 103.0.0.0/8 — 11708 префиксов с маской /24 и он суммируется лишь на 26%.
Однако в некоторых местах всё же префиксы полностью объединяются.
В абсолютных значениях для лучшего варианта (3-й случай) количество полностью включенных префиксов c более короткими масками равняется 6494, всего. Самые большие агрегированные блоки включаются в 38.0.0.0/8 — 2082 префиксов, 12.0.0.0/8 — 1789 и 8.0.0.0/8 — 1095. Есть места, где агрегация добирается свыше 90%, но и они не приносят дополнительного эффекта. Собственно даже это дробление на поддиапазоны накладно и непрактично, не говоря уже о том, чтобы углубляться дальше.
С другими длинами префиксов не сильно лучше, с учётом, что их количество сильно меньше, для /23 удастся сэкономить 1123 адреса. Общий результат в 10 раз хуже мною ожидаемого.
Практика
Как известно теория сильно отличается от практики, поэтому данные, полученные на боевом маршрутизаторе, могут быть сильно не похожи на то, что было проверено ранее. Итак, в наличии два аплинка с full-view, из которых один из аплинков присутствует на route серверах DATA-IX и MSK-IX. Текущая таблица маршрутизации уже оптимизирована для выбора наиболее устраивающего маршрута, включен режим multipath BGP.
Данная ситуация почти что наиболее благоприятная ситуация для нас, за исключением той особенности, что мы можем фильтровать префиксы только если для обоих аплинков они окажутся агрегированы. В противном случае, если один из аплинков будет зафильтрован, то недостача просочится через второй.
Под такую ситуацию у нас попадает, в моём случае около 8000 префиксов в 12 диапазонах по /8. Фактически это тоже количество что и было посчитано теоретически, но с учётом того, что какой-то из аплинков в некоторые сети имеет приоритетный маршрут. Т.е. общее количество префиксов пригодных для фильтрации сократилось в два раза, но впоследствии удвоилось из-за того, что мы имеем две full-view таблицы. Самый внимательный читатель скажет, что даже так фильтровать некорректно, и агрегирование префиксов может происходить так, что один из апстримов будет иметь всегда приоритетные маршруты с большей маской. Да, это действительно так, но при потенциальной возможности получить значительную экономию. Эту проблему можно было бы начать решать более глубоким анализом, но результат в 10 раз хуже намеченного.
Попробовав отделить IX из общей таблицы и исключить их от фильтрования, ожидая, что на них как раз и приходится большая часть длинных префиксов, получаем результат сравнимый до 100 записей со всеми предыдущими.
Таким образом, попытка обмануть обманщика провалилась, BGP full-view неделима в своей ипостаси. Нельзя что-то отрезать и не потерять при этом в чём-то другом. Результат показывает сильную фрагментацию и невозможность хоть в какой-то ощутимой степени влиять на это, видимо и правда мы доживаем последние дни в IPv4 диапазоне. Предел, в общем, тоже понятен, когда большинство маршрутов будут /24 — что примерно соответствует 14 миллионам записей. При желании что-то фильтровать можно поступиться сохранностью исходной информации и начать фильтровать наиболее агрегированные блоки, но в любом случае это будут уже совсем другие маршруты.
Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы
На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.
И крайне редко обсуждается вопрос о необходимости этого самого фулвью.
Немножко «теории»
Не пугайтесь, я не стану рассказывать все с начала. Уверен, что большинству читателей хорошо известно содержимое моей теоретической вводной. Желающие могут смело ее пропустить. Однако же я регулярно сталкиваюсь с некоторой неуверенностью вполне компетентных в практических вопросах людей, когда речь заходит о нижеизлагаемом. Так что все-таки давайте немножко синхронизируем термины, прежде чем обсуждать матчасть.
Все, что впрямую не касается темы интернетной BGP-таблицы, в частности IGP, MPLS, VRF/VPN и т. п., оставим за скобками.
Роутинг и ричабилити
Фулвью — это практически справочник «Желтые страницы» для всего интернета. Только именно «Желтые страницы», а не ваша личная записная книжка. Принципиальная разница тут в том, что помимо разрешения букв в цифры — для чего в интернете служит не фулвью, а DNS — периодические справочники дают нам возможность знать о появлении и исчезновении объектов. Нужно же нам как-то узнавать, что тот или иной адрес вообще есть в интернете. Мало того, если вдруг он для нас доступен только через линк А, а через Б недоступен — мы ведь тоже хотим об этом знать. Это и есть сигнализация доступности (reachability). Не будем слишком глубоко в вдаваться в абстракции, отметим лишь важность осознавать, что ричабилити и роутинг суть разные вещи.
Роутинг (маршрутизация) — нахождение лучшего пути передачи трафика для заданного направления. Этот процесс мало похож на поиск в телефонном справочнике, а скорее имеет отношение к карте города: если один и тот же адрес x.x.x.x доступен нам и через линк А, и через линк Б, нужно принять решение, куда же посылать пакеты.
Предположим, что читатель знаком с протоколом IP и в курсе, что такое префикс, зачем ему длина, и с чем едят правило лонгест мач.
Итак, как видно из показанного выше знаменитого графика c bgp.potaroo.net, полная таблица интернет-маршрутизации (здесь и далее речь в основном об IPv4, хотя почти все кроме цифр справедливо также и для IPv6) нынче содержит почти 350 тысяч записей. Это число растет экспоненциально и довольно быстро. Каждая из записей представляет собой, собственно, маршрут: IP-префикс назначения (подсеть с маской), некстхоп (следующий узел aka «куда посылать») и разные там другие параметры, определяющие ценность этого маршрута. Когда есть два (полученных от разных маршрутизаторов-соседей) маршрута для одного префикса, в ход идут как раз эти атрибуты. Они определяют, какой некстхоп будет использован для передачи.
rviews@route-server.as8218.eu> show route 8.8.8.8 inet.0: 343453 destinations, 1643368 routes (343453 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /* Активный (т. е. наилучший с точки зрения BGP) маршрут помечен звездочкой, только он используется для передачи трафика */
>8.8.8.0/24 *[BGP/170] 6w2d 06:12:47, MED 200, localpref 3200, from 83.167.56.18
AS path: 15169 I > to 83.167.56.240 via ge-0/0/0.0
[BGP/170] 4w1d 04:00:53, MED 200, localpref 3200, from 83.167.56.6
AS path: 15169 I > to 83.167.56.240 via ge-0/0/0.0
[BGP/170] 4w2d 04:00:03, MED 200, localpref 3200, from 83.167.56.5
AS path: 15169 I > to 83.167.56.240 via ge-0/0/0.0 [. ]
Здесь показаны три маршрута к префиксу 8.8.8.0/24, полученные от трех разных маршрутизаторов-соседей. По некоторой причине — кстати, в данном случае нетривиальной — первый из них был выбран наилучшим (в примере причина не показана). Пусть вас не смущает и то, что у всех трех маршрутов один и тот же некстхоп: данные сняты с весьма специфического маршрутизатора, не передающего транзитный трафик. И да, маршрутизатор-сосед и некстхоп — это не одно и то же.
Анонсируются маршруты между маршрутизаторами при помощи протокола BGP, который собой являет, ну, практически RSS-трансляцию (да простят меня теоретики за кощунственное сравнение). Собственно, термин Full View — популярен в основном у нас, иностранные коллеги чаще говорят Full BGP, Full Table или Full Feed.
То есть сам протокол ничего сложного из себя не представляет — просто способ автоматизированного обмена данными, обернутыми в лучших программистских традициях в нечто вроде контейнеров, которые стандарт протокола позволяет более-менее гибко расширять по мере необходимости. Механизмы поиска наилучшего пути (роутинга) и контроля связности (ричабилити) у него довольно просты, если не сказать примитивны. В частности BGP считает, что трафик передается не между маршрутизаторами, а между укрупненными сущностями: автономными системами (АС, произносится «а-эс») и почти ничего не знает об их внутренней структуре — путь через две транзитных АС, каждая из которых включает, скажем, десять внутренних хопов (маршрутизаторов), BGP сочтет более выгодным, чем путь через пять АС, каждая из которых внутри имеет два хопа. Кроме того, BGP практически ничего не знает о пропускной способности линков; в нашем приближении можно считать, что этот аспект вообще никак не учитывается при выборе маршрута.
По сравнению с другими протоколами он не слишком быстр в обнаружении изменений связности и, как мы только что убедились, далеко не всегда оптимально ищет лучшие пути. Однако это все — не только минус, но и плюс BGP, т. к. именно благодаря своей относительной прямолинейности и «укрупненности мазков» протокол хорошо приспособлен для передачи большого объема маршрутной информации.
Так вот таблица в 340 тысяч записей с кучей атрибутов — это довольно много. А таблиц таких нужно обычно не меньше двух («мэньше нэ былло смы-исла», но об этом потом). Одно лишь хранение всего этого добра требует многих сотен мегабайт памяти, а кроме передачи и держания в памяти, таблицы нужно «обсчитать», в результате чего получить набор наилучших (активных) маршрутов.
Например. Один маршрутизатор-сосед анонсировал нам, что он знает маршрут, скажем, к Гуглу, и другой сосед — тоже анонсировал. Теперь мы знаем, что Гугл доступен нам через каждого из соседей (ричабилити) и хотим принять решение, какой же из двух маршрутов использовать для передачи пакетов (роутинг). Для этого BGP сравнивает показания (разные атрибуты маршрутов: Local Preference, AS-PATH и другие) и принимает решение (по каким-то там, не имеющим сейчас значения критериям), что, допустим, через первого соседа лучше. И так для каждого префикса. Таким образом из нескольких таблиц (каждая из которых состоит из 340 тыс. записей), полученных от разных соседей, «компилируется» одна таблица на 340 тыс. активных маршрутов:
route-server>show ip bgp summary BGP router identifier 12.0.1.28, local AS number 65000 BGP table version is 22316128, main routing table version 22316128
339895 network entries using 41127295 bytes of memory // Активные префиксы: 340 тыс. 6244036 path entries using 324689872 bytes of memory // Всего префиксов: 6,2 млн.
420973/58130 BGP path/bestpath attribute entries using 58936220 bytes of memory 82551 BGP AS-PATH entries using 2164884 bytes of memory 150 BGP community entries using 3600 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 426921871 total bytes of memory Dampening enabled. 1728 history paths, 1519 dampened paths BGP activity 3285644/2945748 prefixes, 85118539/78874498 paths, scan interval 60 secs […]
Или то же самое плюс IPv6 на Juniper:
rviews@route-server.as8218.eu> show route summary Autonomous system number: 8218 Router ID: 83.167.63.120
inet.0: 343437 destinations, 1643129 routes (343437 active, 0 holddown, 0 hidden)
Direct: 3 routes, 3 active Local: 1 routes, 1 active
BGP: 1642930 routes, 343238 active
Static: 2 routes, 2 active IS-IS: 193 routes, 193 active […]
inet6.0: 4796 destinations, 20733 routes (4796 active, 0 holddown, 0 hidden)
Direct: 4 routes, 4 active Local: 2 routes, 2 active
BGP: 20577 routes, 4640 active
Static: 1 routes, 1 active IS-IS: 149 routes, 149 active
Конструкция из нескольких еще необсчитанных BGP-фидов (если быть точнее, то не только их, но и данных других протоколов), называется RIB (routing information base). Хранится она как правило в самой обычной оперативной памяти и обрабатывается самым обычным процессором. Соответственно именно к этим двум элементам и предъявляются требования, когда речь идет о количестве полных BGP-таблиц, которые можно впихнуть в RIB. Общее количество записей тут определяется как сумма всех полученных от соседей маршрутов: две фулвью — почти 700 тыс. префиксов, три — за миллион и т. д.
Вывод первый. Грузить фулвью, если у вас только одна сессия с внешним миром — бессмыслица. Обладание этим массивом информации не даст ничего, кроме нагрузки на оборудование, т. к. трафик можно передать только одним способом: «Адам, это Ева, выбирай себе жену». Представьте, что Адам решил бы прежде проанализировать 340 тысяч параметров Евы — где бы мы теперь были? Из данного правила есть редкие исключения, однако если вы не знаете, какие именно, то они — точно не ваш случай.
Памяти под RIB с несколькими фулвью нужно не то чтобы прям очень много, но сотни мегабайт — единицы гигабайт (в зависимости от количества фулвью, реализации и массы других аспектов). Процессору подчас тоже приходится не очень сладко, особенно в реализациях, имеющих BGP-сканер. Например апдаун сессии, через которую передается полная таблица, на иных платформах может приводить к стопроцентной загрузке процессора где-нибудь на полчасика.
Однако же понятно, что гигабайты памяти и гигагерцы процессорной частоты давно перестали быть чем-то особенным. И даже в контексте сетевого оборудования, производители которого славятся умением продавать обычную, как в компьютере, DRAM по цене космических летательных аппаратов, делая вид, что 2 ГБ — вершина прогресса, приведенные цифры не так уж страшно выглядят. Участники упомянутых в начале топика форумных дискуссий довольно часто приходят именно к такому выводу. Мол, главное памяти побольше. Это утверждение, в общем, верно, но к сожалению на нем дело отнюдь не заканчивается.
Давайте посмотрим, что происходит с фулвью дальше. Но прежде еще одно маленькое, но очень важное замечание.
Маршрутная информация всегда передается навстречу трафику, который коммутируется на ее основе. То есть на базе фулвью передается исходящий из вашей АС трафик. Не смотря на всю очевидность этого тезиса, далеко не всегда практическое его значение осознается в полной мере.
Форвадинг
Дальше эта «скомпилированная» таблица активных маршрутов исп
ользуется для передачи трафика. Называется она FIB (forwarding information base), и количество записей в ней, грубо говоря, равно количеству записей в одной фулвью (340 тыс.). С ней все гораздо интереснее.
Лирическое отступление. Вообще говоря, Full View (в отличии от Full BGP Feed) — это как раз FIB. То есть в большинстве случаев правильнее было бы говорить не «мне нужен маршрутизатор, способный держать три фулвью», а «мне нужен маршрутизатор, способный держать три пира с фулвью».
И, кстати, подпись по оси ординат на великой и ужасной картинке, приведенной в начале поста, неправильная. Это не RIB, а FIB. Заголовок на внутренней странице об этом тоже какбе намекает.
Большинство современных маршрутизаторов, способных передавать трафик на скоростях от пары гигабит в секунду и выше, — «аппаратные». Аппаратность их в том, что FIB и ее атрибуты помещается не в обычную, а в специальную, грубо говоря, «быструю» коммутационную память (SRAM, TCAM, RLDRAM и пр.), к которой обращаются специальные же процессоры обработки пакетов. Эта память — едва ли не самый дорогой ресурс в маршрутизаторе. А возможная изощренность работы с ней — уж точно самый главный из факторов, влияющих на цену железа.
Скажем, коммутатор на 24 гигабитных порта, способный передавать трафик со страшной силой (одновременно на полной скорости всех интерфейсов), нынче стоит каких-нибудь пару тысяч долларов или даже еще дешевле. Он тоже вполне «аппаратный» и скорее всего мощности процессора и объема оперативки в нем достаточно, чтобы без проблем обмолотить штуки четыре фулвью в RIB. Мало того, часто софт в нем поддерживает много разных сложных фич. Однако «полноценный маршрутизатор», способный делать, казалось бы, то же самое, стоит раз в пятнадцать дороже. Все потому что помимо разного рода маркетологических тонкостей у коммутатора в таблицу коммутации можно поместить от силы маршрутов, и набор доступных действий с этой таблицей у него значительно уже. Скажем, если для каждого пакета нужно искать запись в FIB не один раз, а два или три (это нужно чаще, чем вы думаете) — то коммутаторы за 2 тыс. $ такого не умеют.
Есть также программные коробки (производительностью, грубо говоря, до гигабита-двух), у которых, соответственно, FIB, как и RIB, хранится в обычной оперативке. У них, вообще, частенько слишком много всего в ней хранится, но об этом как-нибудь в другой раз — главное, что она (оперативка) не резиновая. Мало того, программный поиск по массиву с нахождением наилучшего соответствия (longest match) — ну очевидно же, что тем медленнее, чем больше в массиве элементов, каким алгоритмом не ищи.
- < 500 тыс. для IPv4 — лучше не стоит такое сегодня брать. Совсем не за горами время, когда этого будет мало. А ведь есть еще и IPv6.
- ~500 тыс. — эта цифра популярна для т. н. больших L3-коммутаторов, тех самых, у которых дури много, а набор коммутационных процедур довольно посредственный. Хотя бывают приятные исключения. «Большие» от «маленьких» коммутаторов здесь отличаются во-первых размером коробки и старшинством модели в линейке, во-вторых и в-главных — объемом коммутационной памяти: редко когда «маленький» коммутатор поддерживает полмиллиона записей в FIB. Так вот, хотя коммутационной памяти у «больших» L3-коммутаторов вроде бы достаточно для сегодняшней фулвью, проделывать с пакетом сложные штуки они почти никогда не умеют (собственно, в этом их главное отличие от маршрутизаторов). Их, с одной стороны, если очень хочется, вроде бы и можно использовать для этой задачи, с другой — лучше бы не надо. Очень уж там много всяких нюансов. Короче, подумайте и помучайте продавца хорошенько, прежде чем покупать L3-коммутатор на BGP-пиринг c фулвью.
- миллион и больше — достойная цифра.
Практические рассуждения
Теперь нам предстоит ответить на обозначенный в заголовке вопрос о пользе и вреде фулвью. Для этого сначала еще чуточку пофилософствуем.
Агрегация vs. детализация
При динамической передаче маршрутов существует два противоположных принципа (слово «принцип» здесь означает не «убеждение» или «склонность», а скорее технический прием, используемый по назначению) работы с маршрутной информацией: детализация и агрегация. То есть либо подробность: много длинных префиксов, либо краткость: представление нескольких длинных префиксов в виде одного покороче.
Агрегация
Вообще говоря, уже ясно, что от детализации много вреда: каждый школьник знает, что чем больше информации, тем сложнее ее хранить и дороже ею оперировать. Во времена программных маршрутизаторов и юности IP тезис о необходимости минимизации количества маршрутов был аксиомой, не подлежащей обсуждению. Ради борьбы со снижением производительности от распухания RIB и FIB было придумано очень много всего интересного. К примеру, бесчисленные и беспощадные типы арий и LSA в OSPF или такая штука как MPLS (да-да, он вовсе не ради VPN или TE был изобретен), Cisco Express Forwarding и другие разной степени полезности вещи, включая, собственно, аппаратный форвадинг.
Агрегация (суммаризация) — целая маленькая наука, связанная с грамотным сегментированием, выбором адресного плана, умением управляться со всякими IGP-ариями, ловкостью рук при написании правил маршрутизации и т. п. Интересующихся отсылаю например к книге «Принципы проектирования корпоративных IP-сетей» А. Ретаны, Д. Слайса и Р. Уайта (Cisco Press).
Экстремальный случай агрегации — маршрут по умолчанию («дефолт»): 0.0.0.0/0, означающий «все, кроме того, к чему есть явные маршруты».
Детализация
К сожалению, интернет — такая штука, к которой слабо применимо все это блестящее искусство агрегации. Принципы независимости от географии, отсутствия централизованного управления, административной изолированности автономных систем, минимизации области повреждений при отказах и т. д. приводят к тому, что соседние префиксы, к примеру 212.90.0.0/19 и 212.90.32.0/19, если только они не принадлежат одной автономной системе (и здесь тоже далеко не всегда это возможно), никак нельзя представить в виде агрегированного префикса 212.90.0.0/18 с общими параметрами. В общем случае такая суммаризация может привести к возникновению закольцовок или «черных дыр».
Однако курсивное выделение «в общем случае» — неспроста. Очевидным исключением является вышеупомянутый маршрут по умолчанию. Собственно именно он используется как маршрут в интернет (и не только) в случаях, когда никакой фулвью у нас нету. То есть это практически единственно возможная альтернатива фулвью: наплевать вообще на всю внутреннюю структуру интернета. Давайте посмотрим, когда это возможно, и в чем разница форвадинга на базе дефолта и полной таблицы.
Кому и зачем же нужна фулвью?
С дефолтом все понятно: все, для чего нет специфических (своих) маршрутов, шлем провайдеру (аплинку) aka в интернет. А что, в сущности, дает нам тут фулвью? Она дает возможность принимать решения о выборе линка для послыки пакета, опираясь на знание не обо всем интернете в целом, а об отдельных его ресурсах. Во-первых пример: маршрут x.x.x.x/x доступен через линки A и Б, а маршрут y.y.y.y/y — только через линк Б. Раз так, то трафик к y.y.y.y/y можно посылать только через Б (ричабилити). Во-вторых — мы сможем оказывать влияние на соответствие между префиксами назначения и соседями, через которых мы будем слать трафик. Гуглу пошлем трафик через провайдера А, а Яндексу — через Б (роутинг).
Зачем это может быть нужно?
Первый, неоспоримый случай — наличие как выше- или равностоящих (uplink, IX), так и нижестоящих (клиенты) АС-соседей. То есть, когда наша автономная система транзитная, и к ней подключены клиенты, которые тоже что-то нам анонсируют. Использовать дефолт здесь нельзя по определению, т. к. мы в таком случае находимся не на окраине, а в «середине» интернета. Наличие агрегации маршрутов здесь может приводить к закольцовкам. Поэтому провайдерам приходится держать полную таблицу на всех маршрутизаторах, которые передают интернет-трафик на основе IP-заголовков. Оговоримся, что варианты «голь на выдумки хитра» тут тоже возможны, но во-первых их обсуждение выходят за рамки топика, во-вторых они довольно сложны в эксплуатации при промышленных мастабах сети. Поэтому, хотя вариации на эту тему не так уж и редко встречаются в жизни, очень часто их использование в провайдерских автономках привносит больше проблем, чем пользы.
Вывод третий. Если ваша АС транзитная, то без фулвью скорее всего не обойтись. Впрочем, вы наверное и сами все это знаете. Про MPLS и BGP-free core, я думаю, тоже что-нибудь да слышали. Если нет, то это вам ключевые слова для дальнейшего размышления.
Следующая, более интересная для нас задача — балансировака нагрузки таким образом, чтобы трафик через интернет шел либо оптимальными с точки зрения BGP (который, как мы выяснили, не всегда точен в выборе) путями, либо теми путями, какими мы хотим (и настроим). Оба желания могут быть вполне законны, если у вас действительно много исходящего (еще раз: исходящего!) из вашей АС трафика (гигабит-другой и больше), и в сложных манипуляциях есть экономическая целесообразность. Как правило такое бывает либо у провайдеров с транзитными автономками, которые все равно попадают под случай, описанный выше, либо у крупных ЦОДов, у которых, кстати, тоже скорее всего есть клиенты со своими АС. А даже если нет, то и тут индивидуальное знание о маршрутах для каждого префикса (которое дает фулвью) не помешает (см. например байку юзера shapa о его «войне» с Голденом).
Если же ваша АС — не транзитная инфраструктура на продажу, а корпоративная сеть, пусть даже со своим небольшим (по мировым меркам) ЦОДом, исходящего трафика у вас скорее всего совсем мало (десятки—сотни мегабит), и задачи типа посылать трафик к Гуглу одним маршрутом, а к Яндексу другим — у вас почти наверняка нету (если только любопытства ради). Максимум что вам тут нужно для исходящего трафика — сбалансировать его либо равномерно, либо в какой-то нужной пропорции между несколькими интернет-линками. Вопреки бытующему мнению фулвью для этого не нужна и даже вредна — об этом ниже.
Третий — чуть более интересный и относительно неочевидный случай — фулвью, как информационное «подспорье». Часто хочется знать, с какими АС у вас идет наиболее интенсивный обмен трафиком. В ряде случаев, в том числе когда для передачи трафика фулвью не нужна, хочется снимать статистику для оценки разного рода тенденций трафика. В этих случаях фулвью используется механизмами типа NetFlow для получения дополнительной информации о трафике (исходящем и входящем). Но надо заметить, что реализация подобного мониторинга требует некоторого опыта и понимания, что должно уметь оборудование, где должна храниться та фулвью, чем это все чревато, и как правильно интерпретировать полученную статистику. Короче говоря, это эдвансная тема, выходящая за рамки топика. Кроме того, если трафика у вас не гигабиты, то скорее всего вам оно и не нужно. Другой вариант на эту тему — продемонстрированный выше консольный вывод, снятый со специальных маршрутизаторов, не передающих транзитный трафик. Они держат фулвью лишь для возможности ее анализа.
Когда можно обойтись без фулвью?
Крайне распространенным заблуждением является мнение, что, если у вас есть своя АС и блок адресов, то вы обязаны принимать полную таблицу. Это именно что заблуждение.
Как было сказано выше, самый сомнительный в отношении нужности фулвью случай (он же самый массовый и самый богатый неблестящими реализациями) — корпоративная сеть, которой АС нужна для обладания своим блоком адресов, чтоб, в свою очередь, не зависеть от провайдеров при резервировании интернет-ресурсов (публичных серверов, VPN-концентраторов и т. п.) Основная задача здесь — сделать возможным получение входящего из интернета трафика при потере одного из внешних подключений. Вспоминаем правило, гласящее, что трафик передается навстречу маршрутной информации. Вопрос: зачем нам нужна фулвью, если речь о входящем трафике? Ответ: да ни зачем не нужна.
Хорошо, но если мы отказываемся от фулвью, то как же мы будем передавать исходящий трафик? Да как обычно! Пишем правило маршрутизации, а еще лучше договариваемся с провайдером (обычно это не проблема), чтоб не насиловать оборудование по пустякам (а в идеальном случае для этого придуман механизм ORF), и принимаем от каждого провайдера только маршрут по умолчанию. Дальше либо используем только один из маршрутов, а второй держим про запас (на случай, если первый отвалится) и пускаем весь исходящий трафик по одному линку, либо настраиваем балансировку нагрузки: равномерную или даже в заданной пропорции при помощи BGP bandwidth community, если ваше оборудование такое умеет (вспоминаем разговор про отличие маршрутизаторов от L3-свичей). Все то же самое, если провайдеров не два, а три, пять, двадцать, сто двадцать.
Некоторый (в общем, единственный) минус такого подхода — это то, что вместе с «гранулярным» роутингом мы отказались и от контроля над ричабилити: у вас не будет сигнализации связности с конкретными ресурсами в интернете. Отдельные префиксы в фулвью — это информация непосредственно от ресурса, которому вам нужно послать трафик. А дефолт чаще всего сгенерирован вашим провайдером (ну, или провайдером вашего провайдера, что лучше), и может так случиться, что дефолт от провайдера вы получаете, а на самом деле никакого интернета у него (провайдера) нету. Вот вам и иллюстрация «черной дыры» как следствия агрегации маршрутов.
Во-первых это все-таки не очень большой риск: степень защищенности инфраструктуры ваших провайдеров в любом случае должна быть на порядок выше, чем у вас. Если же описанная ситуация происходит часто, то это повод задуматься о смене провайдера. Во-вторых, при двух интернет-линках и схеме «основной-резервыный» (напомню, речь только об исходящем трафике), можно дополнительно подстраховаться: ну, например, получите от основного провайдера пару префиксов типа Гугла и Яндекса и напишите правило, создающее агрегированный дефолт только в том случае, если заданные маршруты в норме.
Вы боитесь, что Вконтакте будет доступен только через одного провайдера, а Одноклассники только через другого? Такой челлендж для вас бизнес-критикал? Страшно, и желаете защититься? Хотите поговорить об этом с руководством? Оно тоже так думает и готово потратить деньги? — поздравляю (в первую очередь вашего поставщика оборудования). Нет? — что ж, для вас чуть ниже будет заключительный параграф.
В случаях же, когда вам нужна связность не с абстрактным интернетом, а с конкретными ресурсами, адреса которых (обычно в количестве десятков—сотен) известны, например, когда речь идет о терминировании статических туннелей для VPN с филиалами, можно (и даже нужно) кроме дефолта также принять от провайдеров маршруты к этим ресурсам (удаленным точкам). ORF здесь был бы особенно актуален, но как-то он не слишком в ходу.
Вред от фулвью
А почему, собственно и не фулвью? Чего париться-то всеми этими рассуждениями? Ну примем мы его себе, да и все дела?
Во-первых баласировать исходящий трафик в нужной пропорции, когда у вас на руках фулвью, в разы сложнее и муторнее (совершенно неинтересное занятие). По умолчанию балансировка работает по принципу «как карта ляжет». Допустим, вы арендуете широкий канал у провайдера попроще и подешевле и канал поуже у провайдера покруче и подороже. Так вот, если не принять специальных мер, бо́льшая часть исходящего трафика у вас попрет в узкий канал и (возможно) перегрузит его: связность у «крутого» провайдера лучше, и BGP, который ничегошеньки не знает о пропускной способности ваших линков, будет думать, что бо́льшая часть интернета к вам «ближе» через узкий канал. Хотя с точки зрения юзер-экспириенс скорее всего все равно, каким маршрутом слать трафик, главное, чтобы не было перегрузки. Имея же два дефолта без фулвью и правильный маршрутизатор, можно и вовсе явно указать пропорцию: в канал поуже слать 30%, в канал пошире — 70.
Во-вторых по экономическим причинам: корпоративной сети полноценный большой аппаратный маршрутизатор часто не по карману. Поэтому, если нужна высокая производительность (гигабиты), можно использовать те самые относительно дешевые свичи, способные держать в FIB лишь несколько тысяч префиксов.
Однако часто в корпоративных сетях для BGP-пиринга используется менее производительные, но значительно более многофункциональные программные коробки. И обычно та же коробка является одновременно бордер-маршрутизатором, пограничным стейтфул-файрволом, делает нат, всю внутреннюю маршрутизацию, а иной раз, прости господи, проверяет трафик на вирусы, фильтрует URL, моет посуду, варит кашу, стирает, гладит и нянчит детей. И все это добро хранится у нее в оперативной памяти, которая, как я уже отмечал, все-таки не резиновая, и обрабатывается общим процессором, который тоже не ломовая лошадь. Пихать в такую коробку еще и несколько фидов с фулвью — совсем как-то ни к чему. Да не нужно просто этого делать!
Вывод четвертый. Если автономная система у вас не транзитная (вы не провайдер и у вас нет клиентов со своими АС), и при этом вы сами для себя не можете четко сформулировать, зачем вам фулвью, — фулвью вам не нужна.
Что, если очень хочется?
На самом деле у фулвью есть один важный и часто решающий плюс, о котором я до сих пор стыдливо умалчивал. Многим кажется, что это круто. Одно дело, когда show route summary показывает 7 маршрутов, и совсем другое — когда 700 тысяч. Какая корпоративная сеть не мечтает стать операторской?
Ответы тут такие (выбирайте, какой больше нравится):
- И правильно, не отказывайте себе в удовольствии. Вендоры и продавцы маршрутизаторов будут очень рады этому вашему желанию. Надеюсь, работодатель вас в этом тоже поддержит (материально).
- Внедряя и администрируя публичную АС и BGP-пиринг, вам придется решить более сложную и интересную задачу: балансировка входящего трафика и резервирование линков для него. Вид, в котором ваше адресное пространство видно в интернете (роутинг) и видно ли (ричабилити), как организовать резервирование, что будет при нарушении внутренней связности АС, и еще целая куча сложных вопросов ждет от вас решительных и верных действий. Это вам не фулвью принять.
- Наконец, посмотреть, как выглядит полная таблица, можно и на любом публичном route-сервере (вам, кстати, придется это сделать, отлаживая свои анонсы).
BGP full view
BGP full view — это термин, описывающий полную таблицу маршрутов Интернет.
Синонимы этого термина:
- bgp full table,
- full bgp,
- full BGP table.
[править] Дополнительная информация
- Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы
| BGP — Border Gateway Protocol | |
|---|---|
| Основы | BGP • Типы сообщений BGP • BGP full view • BGP RFC • Bogon • RIPE NCC • RIS |
| Атрибуты BGP | BGP AS path • BGP next-hop • BGP origin • BGP MED • BGP weight • BGP local preference • BGP community |
| IBGP | BGP confederation • BGP route reflector |
| Cisco | Cisco BGP filter order • Cisco distribute-list • Cisco prefix-list • BGP AS path filter • Cisco route-map • Изменение значения AD для BGP в Cisco • Команды отладки BGP • Применение изменений в настройках политик BGP • BGP synchronization • BGP timers • BGP ORF • Процессы BGP в Cisco • Просмотр информации BGP в Cisco |
| Маршрутизация | Выбор лучшего маршрута в BGP • Маршрут по умолчанию в BGP • Перераспределение маршрутов в BGP • Суммирование маршрутов BGP |
| MP-BGP | BGP address-family |
| Безопасность | BGP Security • Аутентификация BGP |
| Управление трафиком | Управление входящим трафиком BGP • Управление исходящим трафиком BGP • Балансировка трафика в BGP • Использование BGP для резервирования Интернет-каналов • BGP AS path prepend • BGP conditional route injection • BGP backdoor |
| Реализации | BGP в Cisco • BGP в Quagga • Zebra BGP |
| Утилиты BGP | BGP tools • BGP Looking Glass • BGPlay |
| Разное | BGP/config |
Просмотры
Личные инструменты
Навигация
- Заглавная страница
- Свежие правки
- Случайная статья
- Справка
Поиск
Инструменты
- Ссылки сюда
- Связанные правки
- Спецстраницы
- Версия для печати
- Постоянная ссылка
- Последнее изменение этой страницы: 06:34, 20 декабря 2013.
- К этой странице обращались 31 742 раза.
- Политика конфиденциальности
- Описание Xgu.ru
- Отказ от ответственности
Ищем свободные IPv4 в BGP full-view
Все мы знаем что IPv4 адреса уже закончились и не один раз. Совсем недавно это была достаточно популярная для обсуждения тема в том числе и на Habrаhabr: строили планы и прогнозы, подсчитывали убытки. На дворе 2016 год, но IPv4 по прежнему в строю.
21 Апреля RIPE NCC опубликовал коротенькую техническую новость про то самое исчерпание IPv4 адресов. Собственно смысл новости — обновился график показывающий текущее положение со свободными адресами у RIPE которых осталось у него в распоряжении почти на полный блок /8. У APNIC только половина /8. Вероятно, жёсткая политика распределения адресов делает своё дело и этот самый последний /8 RIR’ы будут тянуть очень долго.
Но всё это относится к «бумажным» адресам. А сколько реальных адресов доступно для маршрутизации в Интернет? Точнее сколько адресов из возможных для маршрутизации в Интернет не используется. Чтобы это посчитать мы воспользуемся уникальным живым свидетелем — таблицей маршрутизации BGP.
Далее немного технических деталей как посчитать и результаты этого расчёта.
BGP full-view содержит все доступные для маршрутизации адреса, на текущий момент около 600000 префиксов. Таблица с адресами выглядит примерно так:
* 1.1.8.0/24 216.221.157.162 0 0 0 40191 3257 4134 i * 1.1.8.0/24 147.28.7.2 0 0 0 3130 1239 4134 i * 1.1.8.0/24 185.44.116.1 0 0 0 47872 3356 4134 i * 1.1.8.0/24 80.91.255.137 0 0 0 1299 4134 i * 1.1.16.0/20 80.241.176.31 0 0 0 20771 47872 286 49597 i * 1.1.16.0/20 185.44.116.1 0 0 0 47872 286 49597 i * 1.1.16.0/20 134.222.87.1 750 0 0 286 49597 i * 1.1.20.0/24 85.114.0.217 0 0 0 8492 9304 18046 133948 e * 1.1.20.0/24 185.44.116.1 0 0 0 47872 9304 18046 133948 i
нам для расчётов нужны только сами префиксы (первый столбец).
Префиксы отсортированы по возрастанию, причём более короткий префикс той же сети будет всегда впереди длинного. Это нам очень упростит поиск пробелов в таблице, так как возможны только 3 ситуации:
- Один префикс включает другой (первый включает второй, но не наоборот), или они равны;
- Префиксы суммируются в один с более короткой маской;
- Префиксы идут подряд, но не суммируются.
Я не стал искать готовые решения, возможно, то же самое можно было сделать используя ipaddress. В моей реализации применяется стек в качестве основного рабочего инструмента:
for line in fileinput.input(): prefix = ipv4num(line) while len(ipstack): cur_prefix = ipstack.pop() sum_prefix = netsum(cur_prefix, prefix) if sum_prefix[0]: prefix = sum_prefix continue elif issubnet(cur_prefix, prefix): prefix = cur_prefix break elif isseq(cur_prefix, prefix): if prefix[1] /<>".format(numipv4(gapprefix), mask) ipstack[:] = [] break ipstack.append(prefix) Код целиком можно забрать на Github.
Полученный на входе префикс сравнивается с тем что в стеке на предмет выполнения одного из 3-х вышеперечисленных условий:
- Если префиксы суммируются то выполняем суммирование и продолжаем движение ко дну стека, сравнивая уже суммированный префикс с новым взятым с вершины в надежде, что он опять может быть суммируется;
- Если префикс из стека включает в себя префикс на входе, то переходим к следующему префиксу со входа, возвращая проверяемый префикс на вершину стека;
- Если префиксы идут друг за другом и маска префикса со входа длиннее того что взят из стека, то кладём новый префикс на вершину (в дальнейшем он может быть просуммирован с другими префиксами со входа). Если маска короче или равна, то нет смысла держать весь предыдущий стек, так как в любом случае все дальнейшие проверки будут только с новым префиксом. Стек очищаем, поступившее значение кладём на вершину.
Осталось только взять BPG full-view. Можно было бы воспользоваться ближайшим BGP маршрутизатором находящимся под рукой, но такая возможность есть далеко не у всех. Поэтому возьмём данные отсюда www.routeviews.org — хороший исследовательский, академический ресурс. Сам архив с данными в котором собраны таблицы маршрутизации Интернет за солидный промежуток времени находится здесь archive.routeviews.org/oix-route-views. Я выбрал файл за 20 Апреля.
Таблица слегка зашумлёна адресами из частного адресного пространства и адресами /32. Поэтому всё было отфильтровано до префикса /24 (что соответствует практическим реалиям), были убраны повторные префиксы. Ничего специально для этого не придумывалось — использовались инструменты grep и uniq. Это был самый долгий процесс минут на 10.
В результате исходная таблица содержит 628105 префиксов, больше половины из них 344704 приходится на /24. На мой взгляд хороший показатель нехватки адресов, так как вследствие дефицита происходит дробление адресного пространства. 8697 префикса не находятся в управлении RIR и принадлежат организациям получившим их до момента образования RIR. Самый короткий анонсируемый префикс /8 всего их в таблице 16, 13 из которых опять же не находятся в ведении RIR’ов.
LEGACY — адреса не находящиеся в административном управлении RIR’ов.
Исходные данные
| TOTAL | ARIN | RIPE | APNIC | AFRINIC | LACNIC | LEGACY | |
|---|---|---|---|---|---|---|---|
| /24 | 344704 | 120580 | 81055 | 92632 | 8293 | 35894 | 6250 |
| /23 | 61168 | 20135 | 17563 | 13976 | 1373 | 7332 | 789 |
| /22 | 72588 | 24472 | 19366 | 17587 | 1799 | 8803 | 561 |
| /21 | 44409 | 11721 | 13596 | 11143 | 1376 | 6250 | 323 |
| /20 | 40035 | 13363 | 8312 | 12006 | 712 | 5320 | 322 |
| /19 | 27055 | 7140 | 6929 | 7131 | 540 | 5222 | 93 |
| /18 | 13300 | 3868 | 3114 | 4229 | 558 | 1465 | 66 |
| /17 | 7928 | 2431 | 2145 | 2235 | 257 | 810 | 50 |
| /16 | 13212 | 5563 | 2600 | 3894 | 315 | 660 | 180 |
| /15 | 1804 | 502 | 557 | 506 | 56 | 156 | 27 |
| /14 | 1052 | 280 | 276 | 295 | 58 | 135 | 8 |
| /12 | 516 | 123 | 121 | 233 | 31 | 5 | 3 |
| /11 | 269 | 96 | 50 | 101 | 17 | 2 | 3 |
| /10 | 36 | 13 | 9 | 14 | 0 | 0 | 0 |
| /9 | 13 | 4 | 0 | 0 | 0 | 0 | 9 |
| /8 | 16 | 2 | 0 | 1 | 0 | 0 | 13 |
| /7 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Всего: | 628105 | 210293 | 155693 | 165983 | 15385 | 72054 | 8697 |
Таблица маршрутизации содержит пересекающиеся префиксы. Для того чтобы выудить какие-то данные надо углубляться дальше. Делать мы этого не будем, гораздо интереснее посчитать сколько адресов не маршрутизируется.
Выполняем наш скрипт и получаем результат. Так как перед этим из исходной таблицы были вычищены префиксы из частного адресного пространства и некоторые специальные адреса они опять появились, но уже в таблице немаршрутизируемых (что подтверждает правильность работы программы). Вычищаем их ещё раз. Нет смысла их брать во внимание — скорее всего они никогда не будем использоваться для маршрутизации. Мельком обращаем внимание на блок 240.0.0.0/4 где законсервировано 1/16 всех адресов.
Из того адресного пространства что осталось не маршрутизируется в общей сумме 79 блоков по /8. На ARIN приходится 39, на APNIC 12, на RIPE 7. Фактически из этого можно построить второй Интернет. Напомним, что RIPE рапортует всего об одном нераспределённом блоке /8.
Свободные префиксы
| TOTAL | ARIN | RIPE | APNIC | AFRINIC | LACNIC | LEGACY | |
|---|---|---|---|---|---|---|---|
| /24 | 27358 | 14225 | 6213 | 5287 | 401 | 1211 | 21 |
| /23 | 18763 | 10260 | 4159 | 3419 | 257 | 648 | 20 |
| /22 | 15170 | 7469 | 3618 | 3363 | 221 | 479 | 20 |
| /21 | 8366 | 4533 | 1684 | 1650 | 139 | 336 | 24 |
| /20 | 5312 | 3081 | 819 | 1069 | 74 | 236 | 33 |
| /19 | 3355 | 2011 | 426 | 701 | 56 | 136 | 25 |
| /18 | 1959 | 1254 | 181 | 397 | 31 | 76 | 20 |
| /17 | 1194 | 750 | 127 | 241 | 22 | 43 | 11 |
| /16 | 1907 | 1405 | 168 | 251 | 24 | 47 | 12 |
| /15 | 586 | 381 | 69 | 106 | 11 | 7 | 12 |
| /14 | 193 | 114 | 20 | 38 | 8 | 2 | 11 |
| /12 | 70 | 31 | 9 | 17 | 6 | 0 | 7 |
| /11 | 40 | 19 | 1 | 9 | 2 | 0 | 9 |
| /10 | 16 | 4 | 1 | 4 | 1 | 0 | 6 |
| /9 | 8 | 1 | 0 | 0 | 0 | 0 | 7 |
| /8 | 10 | 1 | 0 | 0 | 1 | 0 | 8 |
| /7 | 1 | 0 | 0 | 0 | 0 | 0 | 1 |
Свободные префиксы приведённые к /24
| TOTAL | ARIN | RIPE | APNIC | AFRINIC | LACNIC | LEGACY | ADMINBY | |
|---|---|---|---|---|---|---|---|---|
| /24 | 27358 | 14225 | 6213 | 5287 | 401 | 1211 | 21 | 9439 |
| /23 | 37526 | 20520 | 8318 | 6838 | 514 | 1296 | 40 | 13748 |
| /22 | 60680 | 29876 | 14472 | 13452 | 884 | 1916 | 80 | 21836 |
| /21 | 66928 | 36264 | 13472 | 13200 | 1112 | 2688 | 192 | 27104 |
| /20 | 84992 | 49296 | 13104 | 17104 | 1184 | 3776 | 528 | 37792 |
| /19 | 107360 | 64352 | 13632 | 22432 | 1792 | 4352 | 800 | 53760 |
| /18 | 125376 | 80256 | 11584 | 25408 | 1984 | 4864 | 1280 | 73024 |
| /17 | 152832 | 96000 | 16256 | 30848 | 2816 | 5504 | 1408 | 97664 |
| /16 | 488192 | 359680 | 43008 | 64256 | 6144 | 12032 | 3072 | 396800 |
| /15 | 300032 | 195072 | 35328 | 54272 | 5632 | 3584 | 6144 | 229888 |
| /14 | 197632 | 116736 | 20480 | 38912 | 8192 | 2048 | 11264 | 130048 |
| /12 | 143360 | 63488 | 18432 | 34816 | 12288 | 0 | 14336 | 94208 |
| /11 | 163840 | 77824 | 4096 | 36864 | 8192 | 0 | 36864 | 81920 |
| /10 | 131072 | 32768 | 8192 | 32768 | 8192 | 0 | 49152 | 57344 |
| /9 | 131072 | 16384 | 0 | 0 | 0 | 0 | 114688 | 16384 |
| /8 | 327680 | 32768 | 0 | 0 | 32768 | 0 | 262144 | 32768 |
| /7 | 65536 | 0 | 0 | 0 | 0 | 0 | 65536 | 0 |
| Всего: | 2611468 | 1285509 | 226587 | 396457 | 92095 | 43271 | 567549 | 1373727 |
| Всего блоков по /8 | 79,70 | 39,23 | 6,91 | 12,10 | 2,81 | 1,32 | 17,32 | 41,92 |
ADMINBY — согласно IANA имеют статус LEGACY, но назначены какому либо их RIR (Administered by RIR)
Самый большой немаршрутизируемый блок от 28.0.0.0 до 30.255.255.255. Принадлежит двум организациям судя по этому документу DSI-North и Defense Information Systems Agency.
Стоит отметить что адресные блоки находящиеся в административном управлении RIR могли им достаться уже по факту. Например, блок 7.0.0.0/8 администрируемый ARIN целиком принадлежит DoD Network Information Center если судить по whois ARIN и не маршрутизируется. Всего количество адресов в подобных блоках соответствует, примерно, 42 адресным пространствам с префиксом /8.
Интересно наблюдать, что иногда в сплошном блоке, например, 13.128.0.0/9 или 29.0.0.0/8 присутствуют распределённые inetnum и route объекты, но всё равно глобально не видится ничего.
В некоторых случаях компания обладает большим непрерывным блоком, например, 2.0.0.0/12, но видимо по причине ненадобности анонсирует только часть этого блока. Получаются пробелы в 2.7.0.0/16 и 2.15.0.0/16. Может быть мелочь, но именно /16 является пиковым по свободным адресам.
Если немного посмотреть назад и взять данные за 20 Апреля 2011 года, то получим следующую картину.
Свободные префиксы 2011 год
| TOTAL | ARIN | RIPE | APNIC | AFRINIC | LACNIC | LEGACY | |
|---|---|---|---|---|---|---|---|
| /24 | 19270 | 10418 | 4089 | 3725 | 246 | 789 | 3 |
| /23 | 14019 | 7864 | 2978 | 2435 | 189 | 547 | 6 |
| /22 | 10221 | 5683 | 2251 | 1634 | 183 | 459 | 11 |
| /21 | 6728 | 3637 | 1533 | 1090 | 104 | 356 | 8 |
| /20 | 4899 | 2625 | 903 | 853 | 63 | 430 | 25 |
| /19 | 3068 | 1751 | 485 | 554 | 52 | 210 | 16 |
| /18 | 1876 | 1165 | 221 | 330 | 39 | 106 | 15 |
| /17 | 1186 | 710 | 148 | 224 | 20 | 73 | 11 |
| /16 | 2069 | 1503 | 179 | 309 | 14 | 54 | 10 |
| /15 | 672 | 424 | 65 | 147 | 9 | 18 | 9 |
| /14 | 280 | 147 | 22 | 80 | 8 | 14 | 9 |
| /12 | 129 | 54 | 11 | 41 | 8 | 9 | 6 |
| /11 | 73 | 30 | 7 | 22 | 4 | 3 | 7 |
| /10 | 27 | 9 | 4 | 7 | 1 | 1 | 5 |
| /9 | 17 | 3 | 3 | 3 | 1 | 2 | 5 |
| /8 | 16 | 3 | 2 | 0 | 1 | 2 | 8 |
| /7 | 2 | 1 | 0 | 0 | 0 | 0 | 1 |
Свободные префиксы приведённые к /24 2011 год
| TOTAL | ARIN | RIPE | APNIC | AFRINIC | LACNIC | LEGACY | ADMINBY | |
|---|---|---|---|---|---|---|---|---|
| /24 | 19270 | 10418 | 4089 | 3725 | 246 | 789 | 3 | 6335 |
| /23 | 28038 | 15728 | 5956 | 4870 | 378 | 1094 | 12 | 9642 |
| /22 | 40884 | 22732 | 9004 | 6536 | 732 | 1836 | 44 | 14232 |
| /21 | 53824 | 29096 | 12264 | 8720 | 832 | 2848 | 64 | 19240 |
| /20 | 78384 | 42000 | 14448 | 13648 | 1008 | 6880 | 400 | 29760 |
| /19 | 98176 | 56032 | 15520 | 17728 | 1664 | 6720 | 512 | 43776 |
| /18 | 120064 | 74560 | 14144 | 21120 | 2496 | 6784 | 960 | 64192 |
| /17 | 151808 | 90880 | 18944 | 28672 | 2560 | 9344 | 1408 | 86272 |
| /16 | 529664 | 384768 | 45824 | 79104 | 3584 | 13824 | 2560 | 436480 |
| /15 | 344064 | 217088 | 33280 | 75264 | 4608 | 9216 | 4608 | 250368 |
| /14 | 286720 | 150528 | 22528 | 81920 | 8192 | 14336 | 9216 | 171008 |
| /12 | 264192 | 110592 | 22528 | 83968 | 16384 | 18432 | 12288 | 135168 |
| /11 | 299008 | 122880 | 28672 | 90112 | 16384 | 12288 | 28672 | 135168 |
| /10 | 221184 | 73728 | 32768 | 57344 | 8192 | 8192 | 40960 | 65536 |
| /9 | 278528 | 49152 | 49152 | 49152 | 16384 | 32768 | 81920 | 65536 |
| /8 | 524288 | 98304 | 65536 | 0 | 32768 | 65536 | 262144 | 131072 |
| /7 | 131072 | 65536 | 0 | 0 | 0 | 0 | 65536 | 0 |
| Всего: | 3469168 | 1614022 | 394657 | 621883 | 116412 | 210887 | 511307 | 1663785 |
| Всего блоков по /8 | 105,87 | 49,26 | 12,04 | 18,98 | 3,55 | 6,44 | 15,60 | 50,77 |
Адресов было побольше, почти 1/3 от всех. За это время все RIR’ы потратили адреса кто-то не так много, некоторые очень много, как LACNIC, но в целом от 1/3 до половины. Видно что не администрируемые напрямую RIR адреса как были так и остались практически в полном составе. Наоборот, часть адресов освободилась. Получается, что на заре становления Интернет была распределена пятая часть всех адресов которые до сих пор никак не используются. Точнее они могут могут быть использованы где-то локально, но в нашей действительности BGP Интернет доступа к ним не существует.
Я никак не ожидал что так много адресов не видно в BGP full-view. Кому-то их выделили очень много, но что их вообще не используют. Меня конечно это смутило и я стал искать где ошибся. Ошибся я серьёзно и неоднократно, но после всех исправлений конечный результат не сильно изменился. Может быть я не всё нашёл или неправильно считаю. В конце концов я проверил все блоки соответствующие AFRINIC вручную на предмет наличия в таблице маршрутизации на своих BGP маршрутизаторах и убедился, как минимум, в этом случае считается верно.
От первоначальной задумки сопоставить свободные блоки в таблице маршрутизации с базами RIR пришлось отказаться, слишком много адресов. Все получаемые дампы я положил рядом со скриптом который вычисляет пробелы в списке префиксов, зову всех попробовать повторить мои расчёты. А пока с завистью смотрим на первопроходцев, которым уж точно не грозит нехватка адресов, не в ближайшем будущем. Опрос соответствующий: