Detecting ASN32-capable routers in the Internet

Уже некоторое время RIR'ы выдают 32-битные номера автономных систем. В Интернете появились префиксы, анонсируемые 32-битными AS. Очевидно, для того, чтобы такие префиксы появились, нужна поддержка в софте роутеров. Основные вендоры, конечно же, уже выпустили софт с такой поддержкой. Однако, одно дело - выпущенный софт, другое - софт, задеплоенный в работающих сетях.

RFC4893 (BGP Support for Four-octet AS Number Space) позволяет переходить к повсеместной поддержке ASN32 постепенно и не требует, чтобы весь Интернет взял и одномоментно проапгрейдил софт на всех роутерах. Для того, чтобы сохранить совместимость новых номеров автономных систем со старым софтом, RFC4893 предусматривает довольно интересный механизм совместимости.

Вкратце, RFC определяет optional transitive атрибут AS4_PATH. Роутеры, которые поддерживают ASN32, при передаче апдейта роутеру без такой поддержки, сохраняют AS_PATH с 32-битными ASN в этом атрибуте, а в AS_PATH 32-битные номера заменяет на специальное значение 23456. Роутеры без поддержки ASN32 прозрачно передают этот атрибут дальше, а когда роутер с поддержкой ASN32 видит в апдейте атрибут AS4_PATH, он восстанавливает AS_PATH, основываясь на текущем значении AS_PATH и AS4_PATH.

Там немножко больше процедур, чем я описал одним абзацем, но пересказывать весь RFC я здесь не буду. Поэтому, интересующихся отошлю к тексту документа. Разобраться довольно не сложно.

Задача

Новый софт необходим только для тех автономных систем, которым присвоен 32-битный номер. Для 16-битных AS апгрейд, в принципе, необязателен - почти все будет работать как надо. С другой стороны, апгрейд имеет некоторые бенефиты: можно использовать в as-path regexp настоящие номера AS, а не 23456, MED будет работать правильно и т.п. Кому-то мелочи, кому-то нет.

Вопрос: а насколько распространен софт с поддержкой ASN32 в настоящий момент?

Метод

Можно попытаться ответить на этот вопрос, наблюдая за BGP-апдейтами, в которых есть атрибут AS4_PATH.

Рассмотрим апдейт вот с такими атрибутами (пример 1):
AS_PATH: 10 20 30 40 23456 50
AS4_PATH: 30 40 65537 50

Что можно сказать, глядя на такой апдейт?

1. В AS65537 определенно есть новый софт (спасибо, Капитан Очевидность)
2. В AS10 нового софта не замечено. Если б он там был, то AS4_PATH был бы длиннее.
3. Про AS40 и AS50 неизвестно ничего. Даже если в них и есть новый софт, то он был "скрыт" новыми роутерами, через которые апдейт прошел потом.
4. А вот с AS20 и AS30 все несколько интересней. AS_PATH со значением 30 40 65537 50 был сохранен в AS4_PATH в одной из этих двух автономных систем.
• Если в AS20 новый софт стоит вперемешку со старым, то могло получиться так, что сначала апдейт попал на роутер с новым софтом, а потом по iBGP ушел на старый - в этом случае получится именно такой AS4_PATH.
  При этом в AS20 обязательно должны быть и роутеры со старым софтом. Например, роутер на стыке с AS10. Если б этот роутер имел новый софт, то AS4_PATH выглядел бы как 20 30 40 65537 50.
• Если в AS20 нового софта нет, то такой AS4_PATH мог получиться только, если в AS30 роутер на стыке с AS20 - новый.

Видно, что рассматривая апдейты по одиночке, сказать что-то определенное о поддержке ASN32 в каждой из замеченных AS сложно. Кое-что можно, а кое-что нет. Но можно рассмотреть апдейты в совокупности.

Пусть в дополнению к предыдущему апдейту мы увидели еще и такой апдейт (пример 2):
AS_PATH: 30 80 65538
AS4_PATH: 65538

Становится понятно, что апдейт прошел через AS30 только по роутерам без поддержки ASN32. В принципе, могло получиться и так, что в AS30 есть новый софт, но апдейт прошел через другие роутеры. Т.е. либо AS30 не поддерживает ASN32 полностью, либо поддерживает частично. Если AS30 не поддерживает ASN32, то получается, что AS4_PATH в примере 1 был сформирован в AS20, и тогда в AS20 есть частичная поддержка ASN32.

Если мы посмотрим на апдейты за какой-то промежуток времени, то получится система логических ограничений, которая решается классическими методами для таких систем. Такая система имеет решение - в конце концов мы наблюдаем реальный интернет, который существует объективно (предполагаем, что сеть функционирует так, как описано в RFC4893 без ошибок). Такая система имеет много решений - например, есть тривиальное и неинтересное: говорим, что все наблюдаемые AS имеют частичную поддержку ASN32 и тогда все сойдется.

Поскольку решений может быть много, нам надо как-то выбрать одно. В связи с этим, я выдвину предложение: наиболее близким к реальности будем считать то решение, которое содержит наименьшее число утверждений "в автономной системе X мешанина из старого и нового софта", ибо это разврат, а разврата не может быть много. Называйте это presumption of sane operational practices :)

Эксперимент

Я собрал апдейты, содержащие атрибут AS4_PATH за трое суток c 7 мая 17:00 по 10 мая 17:00 (время московское) с http://bgpmon.netsec.colostate.edu/. Этот сервис отдает BGP-апдейты в реальном времени, которые получает от нескольких автономных систем. Файл с данными: as4upd.log. Формат, я думаю, очевиден.

За это время было зарегистрировано 869 апдейтов, несущих AS4_PATH, из них 294 с уникальными AS_PATH и AS4_PATH. 33 различных префикса. 30 автономных систем с номером более 65556. 119 автономных систем (считая 32-битные), про которые зарегистрированные апдейты дают какую-то информацию.

Решая получившуюся систему уравнений, получаем следующие результаты.
Внимание: т.к. для выбора одного из решений я сделал довольно произвольное предположение о минимизации мешанины, не стоит рассматривать эти результаты, как твердо установленный факт.

Update: Это не просто не "установленный факт". Эти результаты - говно чуть менее, чем полностью. См. следующий пост.

Результаты

Результаты приводятся только ASN16, ибо для ASN32 все очевидно.

Обнаружен новый софт, старого не обнаружено:

• AS702
• AS1103
• AS1213
• AS2828
• AS3255
• AS8758
• AS8928
• AS9035
• AS9070
• AS13249
• AS20960
• AS20965
• AS22773
• AS23352
• AS24863
• AS35320
• AS42184
• AS43561
• AS48100
• AS48850

Обнаружен старый софт, нового не обнаружено:

• AS701
• AS715
• AS1267
• AS1273
• AS2516
• AS2907
• AS2914
• AS3043
• AS3216
• AS3327
• AS3491
• AS3701
• AS3741
• AS4436
• AS4600
• AS4648
• AS4697
• AS5539
• AS5784
• AS6298
• AS6453
• AS6461
• AS6762
• AS6789
• AS6854
• AS7018
• AS7091
• AS7660
• AS7911
• AS8207
• AS8400
• AS8452
• AS8495
• AS8601
• AS8866
• AS9050
• AS10764
• AS10876
• AS11537
• AS12389
• AS12552
• AS12956
• AS12989
• AS13030
• AS15412
• AS15589
• AS15703
• AS15742
• AS15772
• AS20485
• AS21011
• AS21219
• AS26769
• AS34224
• AS42396

Обнаружена мешанина из старого и нового софта:

• AS174
• AS286
• AS812
• AS1239
• AS1299
• AS3257
• AS3303
• AS3356
• AS3549
• AS6939
• AS8342
• AS9002
• AS16150
• AS22388

Обсуждение

Из 89 16-битных автономных систем (119 всего минус 30 32-битных)

• в 55 обнаружен только старый софт (а нового не найдено)
• в 20 обнаружен только новый софт (а старого не найдено)
• в 14 обнаружено и то, и другое.

В принципе, результаты совпадают с моим представлением о положении дел. Большинство (62%) - разумные консерваторы, которые не стремятся к апгрейду на новый софт, пока их не вынуждают обстоятельства. Некоторые (22%) апгрейдятся, либо из-за относительно небольших преимуществ, которые дает поддержка ASN32, либо из-за каких-то других фич и фиксов.

Интересно довольно большое количество сетей, в которых есть и старый, и новый софт. Моя гипотеза состоит в том, что это сети с консервативной политикой по отношению к апгрейдам, но которые недавно ставили на сеть новое железо, поддерживаемое только новым софтом, а поддержку ASN32 на этих роутерах получили в довесок и специально выключать ее не стали.

Дальше

Я собираюсь повторить эксперимент через несколько месяцев, чтобы посмотреть что изменится за это время. Очень хотелось бы расширить источники данных, чтобы увидеть больше разных путей. Советы, где бы взять побольше пригодных данных, и помощь в этом приветствуются.