vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Размер имеет значение: пытаемся сократить BGP full-view 8

Дата публикации: 14.07.2016
Количество просмотров: 5312

Количество глобально анонсируемых сетей в 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 миллионам записей. При желании что-то фильтровать можно поступиться сохранностью исходной информации и начать фильтровать наиболее агрегированные блоки, но в любом случае это будут уже совсем другие маршруты.

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/29630/razmer-imeet-znachenie-pyitaemsya-sokratit-bgp-full-view.html

Комментарии:(8) комментировать

20 июля 2016 - 17:22
Robot_NagNews:
#1

Материал:
Количество глобально анонсируемых сетей в BGP растёт и это ни для кого не секрет. На текущий момент количество префиксов в full-view больше 650000. Является ли это проблемой, может быть и нет для кого-то, но 13 августа 2014 года показало обратное. Популярное решение при стандартных настройках не смогло вместить 512k маршрутов из-за чего случился совсем не локальный апокалипсис и даже то что об этом предупреждали заранее никак не спасло ситуацию.

Полный текст


20 июля 2016 - 17:22
Дима Григорьев:
#2

Если вопрос с IPv4 стоит все острее и острее с каждым годом, то почему никто не шевелится с переходом на IPv6. Или на небольшой августовский коллапс 2014 никто не обратил внимания?


20 июля 2016 - 17:29
snvoronkov:
#3

http://www.cidr-report.org/as2.0/

Автор материала сей сайт видел?


21 июля 2016 - 16:54
mixae1:
#4

Просмотр сообщенияsnvoronkov (20 июля 2016 - 16:29) писал:

http://www.cidr-report.org/as2.0/

Автор материала сей сайт видел?


Да. В статье как раз интегральная оценка сего внутри одной области /24. Там ссылка есть на http://www.routeviews.org/ с совсем сырыми данными, на котором перечислены ещё несколько сайтов, включая этот, где эти данные анализируются.

Просмотр сообщенияДима Григорьев (20 июля 2016 - 16:22) писал:

Если вопрос с IPv4 стоит все острее и острее с каждым годом, то почему никто не шевелится с переходом на IPv6. Или на небольшой августовский коллапс 2014 никто не обратил внимания?


Пока всё работает и так, даже для коллапса нашёлся обходной путь и найдётся ещё не раз.


21 июля 2016 - 23:49
Дима Григорьев:
#5

Просмотр сообщенияmixae1 (21 июля 2016 - 15:54) писал:

Пока всё работает и так, даже для коллапса нашёлся обходной путь и найдётся ещё не раз.


а зачем искать обходные пути, если решение проблемы на поверхности? так дешевле и проще? или я чего-то просто не понимаю в силу малой осведомленности)


22 июля 2016 - 1:55
Saab95:
#6

Это что у какой-то древней циски ограничение на 512к маршрутов? Другие же решения, особенно не такие аппаратные, подобных ограничений не имеют и никак не замечают увеличения количества маршрутов, поэтому проблема надумана.


22 июля 2016 - 21:48
orlik:
#7

Просмотр сообщенияSaab95 (22 июля 2016 - 00:55) писал:

Это что у какой-то древней циски ограничение на 512к маршрутов? Другие же решения, особенно не такие аппаратные, подобных ограничений не имеют и никак не замечают увеличения количества маршрутов, поэтому проблема надумана.


Опять в лужу пёрнул и доволен


24 июля 2016 - 12:54
RialCom.ru:
#8

сами же анонсы до /24 сначала отдаете, а потом возмущаетесь ;)


27 июля 2016 - 19:17
Дегтярев Илья:
#9

Самый правильный ответ как обрезать размер таблицы, если нет прямых стыков с операторами Tier1 - обрезать все маршруты в пути которых есть АСки Tier1, оставив только дефолт в сторону оператора, имеющего в аплинках Tier1вых. Ничего не потеряете. Это половина таблицы и всего несколько % исходящего трафика.


Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться