Daniel "dbg" Ginsburg

Yota scandal

2009-12-06T23:37:15Z

Сегодня все блоги шумят на предмет того, что Yota заблокировала доступ к целому набору сайтов оппозиции: http://www.kasparov.ru, http://www.nazbol.ru, http://www.rusolidarnost.ru, http://www.rufront.ru, http://www.newtimes.ru, http://www.kavkazcenter.com.

Где-то я это уже слышал :)

Ну естественно, я не мог пройти мимо. Я побежал в ближайшую точку продаж и купил модем. Благо, Yota проводит акцию try and buy. Так что у меня есть целая неделя, чтобы покопаться.

Итак, втыкаем модем, проделываем все положенные прыжки и ужимки на предмет регистрации, и идем на http://www.kasparov.ru и видим: "Firefox не может установить соединение с сервером www.kasparov.ru.".

Круто! Проблема действительно воспроизводится, а значит ее можно исследовать. Проверяем выборочно сайты из списка, и таки да.

Первым делом - проверяем, туда ли мы идем, и не пытаются ли нас обмануть на этапе DNS. Сразу замечаем, что kavkazcenter.com резолвится в 127.0.0.1. С этим сайтом все понятно - он в цензурном списке, и Yota его блокирует без всякого стеснения. Это нормально. "Нормально" не в том, смысле, что я это одобряю - нет, я категорически этого не одобряю и желаю всяческих несчастий всем любителям запретить книжку, газетку или сайтик, какая бы "дрянь" ни была в них написана. Но Йоту можно понять: суд постановил - будь добр выполнять. Увы :(

Остальные же резолвятся совершенно нормально, т.е. в те адреса, в которые должны. В чем же тогда дело?

Берем инструмент и начинаем внимательно разглядывать, что же происходит на самом деле.

03:08:27.979656 IP (tos 0x0, ttl 128, id 42765, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:30.954162 IP (tos 0x0, ttl 128, id 42768, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:33.920210 IP (tos 0x0, ttl 253, id 14323, offset 0, flags [none], proto TCP (6), length 40) 67.218.116.57.80 > 10.128.254.2.3055: R, cksum 0x6117 (correct), 0:0(0) ack 3633491280 win 64512
03:08:34.371135 IP (tos 0x0, ttl 128, id 42769, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:41.140576 IP (tos 0x0, ttl 253, id 13272, offset 0, flags [none], proto TCP (6), length 40) 67.218.116.57.80 > 10.128.254.2.3055: R, cksum 0x9b8c (correct), 2287877420:2287877420(0) ack 1 win 64512

Так. К нам прилетает RST от сайта. Это, в принципе возможно, но поглядим на TTL: он равен 253. Т.е. тот, кто сгенерировал этот пакет, находится от нас не далее, чем в двух хопах - в сети Йоты! Кто-то в промежутке активно вмешивается в нашу TCP-сессию. Пора подозревать неладное.

Когда есть подозрение на странное поведение промежуточного хопа, то лучше всего исследовать такие случаи путем одновременной записи пакетов с обеих сторон. Так и поступим: у меня есть домашняя машинка, подключенная к Акадо.

Со стороны ноутбука на Yota:
03:52:48.544886 IP (tos 0x0, ttl 128, id 45230, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:52:51.555732 IP (tos 0x0, ttl 128, id 45234, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:52:55.595682 IP (tos 0x0, ttl 253, id 24737, offset 0, flags [none], proto TCP (6), length 40) 83.167.114.17.80 > 10.128.254.2.3138: R, cksum 0xcf14 (correct), 0:0(0) ack 2900385037 win 64512
03:52:56.082060 IP (tos 0x0, ttl 128, id 45235, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:53:03.016041 IP (tos 0x0, ttl 253, id 19571, offset 0, flags [none], proto TCP (6), length 40) 83.167.114.17.80 > 10.128.254.2.3138: R, cksum 0x1ede (correct), 509841875:509841875(0) ack 1 win 64512

Со стороны домашнего компа на Акадо:
03:52:49.348749 IP (tos 0x0, ttl 116, id 45230, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe72c (correct), 2068504495:2068504495(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:52:52.323674 IP (tos 0x0, ttl 116, id 45234, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe72c (correct), 2068504495:2068504495(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:52:56.271631 IP (tos 0x0, ttl 245, id 24736, offset 0, flags [none], proto TCP (6), length 40) 109.188.11.104.3138 > 192.168.1.254.80: R, cksum 0x0c89 (correct), 2068504496:2068504496(0) win 0
03:52:57.018421 IP (tos 0x0, ttl 116, id 45235, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe870 (correct), 2390543161:2390543161(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:53:03.689851 IP (tos 0x0, ttl 245, id 19570, offset 0, flags [none], proto TCP (6), length 40) 109.188.11.104.3138 > 192.168.1.254.80: R, cksum 0x0dcd (correct), 2390543162:2390543162(0) win 0

Первое, что бросается в глаза, - мы получили в точности ту же картику, что и с kasparov.ru, если глядеть со стороны Йоты! Т.е. злые цензоры заблокировали и мою домашнюю машину, чтобы она не нарушала гармонию неуместной надписью "It works!" большими черными буквами на белом фоне.

Второе, и на сервер приходят RST якобы от моего ноутбука: SYN, а следом за ним RST от того же хоста, с тех же портов. Хотя со стороны ноутбука видно, что он получает RST, а никак не посылает. Поэтому приходится заключить, что RST возникают в сети Йоты самостоятельно и непрошенно.

Честное слово, оппозиционер из меня хреновый. Ну, разве что кухонный - так, побухтеть. И на машинке той ничего не живет - апач на ней только для всяких экспериментов, которые боязно проводить там, где этот блог находится. Поэтому мысль о том, что Йота каким-то специальным образом меня ненавидит, придется отмести, как неорганизованную :)

В чем же дело? А вот в чем. Мой домашний апач существует, как я уже сказал, только для экспериментов, и отвечает только весьма небольшому количеству внешних хостов. Убираем файрвольное правило, и, вуаля, все работает замечательно - никаких лишних RST. Нормальную сессию я выкладывать не буду - она скучная, поскольку нормальная.

Вот как интересно получается. Если моя машина работает нормально, то Йота в сессию не вмешивается. А ежели сервер на запросы молчит, то через 6-7 секунда Йота сессию обресечивает. Выходит, левые RST возникают, если на дальнем конце что-то не так.

Зачем Йота может это делать? Я подозреваю, что это попытка освобождать память на ихнем NAT'е побыстрее.

Где же тогда проблема? Берем tcptraceroute (вернее, его аналог по винду) и смотрим:
C:\Documents and Settings\dginsburg\My Documents\tmp\tcpt>tracetcp.exe www.kasparov.ru:80 -t 500

Tracing route to 67.218.116.57 on port 80
Over a maximum of 30 hops.
1       *       *       *       Request timed out.
2       *       *       *       Request timed out.
3       *       *       *       Request timed out.
4       *       *       *       Request timed out.
5       *       *       *       Request timed out.
6       199 ms 127 ms 102 ms 213.248.103.177 [mow-m9-i2-link.telia.net]
7       125 ms 125 ms 261 ms 80.91.253.230   [mow-b2-link.telia.net]
8       291 ms 115 ms 113 ms 80.91.249.210   [s-bb1-link.telia.net]
9       268 ms 217 ms 268 ms 213.248.65.25   [kbn-bb1-pos0-0-0.telia.net]
10      289 ms 215 ms 238 ms 80.91.249.21    [nyk-bb1-link.telia.net]
11      338 ms 312 ms 297 ms 80.91.252.153   [sjo-bb1-link.telia.net]
12      350 ms 305 ms 360 ms 80.239.193.126 [layer42-ic-120233-sjo-bb1.c.telia.net]
13      343 ms 476 ms 330 ms 69.36.225.135   [vl2.sw2.scl.layer42.net]
14      307 ms 420 ms 295 ms 67.218.116.57
15      *       *       *       Request timed out.
16      *       *       *       Request timed out.
17      *       *       *       Request timed out.
18      *
Terminate Event Occurred.

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

Подобьем бабки:
1) kavkazcenter.com действительно заблокирован, и заблокирован явно
2) пакеты в сторону kasparov.ru идут и покидают Йоту совершенно успешно
3) очень похоже, что kasparov.ru не отвечает в сторону Йоты.

Если внимательно погуглить, то можно найти, что проблемы возникают только если йотиному юзеру не повезло, и он натится в сеть 109.188.0.0/18. Что может быть причиной?

Мое предположение состоит вот в чем: блок адресов 109/8 был отдан RIPE для раздачи только в начале этого года. До этого он лежал про запас, а следовательно, фигурировал в списках bogons. Некоторые излишне озабоченные безопасностью люди фильтруют маршруты, пакеты или и то, и то, по этим самым bogon lists, но всегда забывают их обновить. Пруфлинк: http://mailman.nanog.org/pipermail/nanog/2009-October/013941.html (обратите внимание на дату).

(Тяжело вздыхая) Что я могу сказать по всему этому поводу? Много чего. Преимущественно нецензурного.

Update: вот, собственно, и yota отписалась - http://community.livejournal.com/yota_ru/660659.html. Я оказался прав.

Про пиво

2009-11-26T21:11:02Z

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

Поэтому, когда года полтора назад я поехал в Дюссельдорф, ничего особенного от тамошнего пива я не ждал. Ну да, наверняка качественное, наверняка свежее, но не более того.

С коллегами мы побродили по историческому центру и остановились у пивоварни, совмещенной с питейным заведением. Народ выпивал в зале, выпивал на улице, несмотря на мелкий дождик, закусывал чем-то непонятным. Мы, естественно, решили попробовать, что же они тут пьют. Оказалось, что там наливают пиво коричневого цвета, с приятным ароматом. Очень приятное и недорогое. Закуской оказались бутерброды с сырым перченым фаршем. Нам очень понравилось, и мы паслись там всю неделю по вечерам.

После этого я изменил мнение о немецких лагерах, и стал считать, что ежели умеючи, то можно и лагер сделать вкусным.

А тут я чего-то начал гуглить и нагуглил это самое пиво. Им оказался Altbier, а заведением - Uerige, одно из четырех мест, где этот Altbier варят на месте. И таки что выяснилось? Alt - один из немногих немецких элей! Он действительно top fermented, но дозревает при низкой температуре, как лагеры. Его начали варить еще до того, как распространилась мода на лагеры, которые, на самом деле, гораздо более позднее изобретение.

Итого, моя едва зародившаяся вера в лагеры опять погибла. Зато убедился, что вкус меня не подвел :)

Ridiculous queueing syndrome

2009-11-14T18:18:44Z

Универсальный эпиграф от arkanoid.

Уважаемые коллеги, предлагаю заценить прекрасную картинку. Кто как, а я просто тащусь:

Вы меня спросите: ты, Даня, спьяну с единицами измерения ничего не напутал? Я вам отвечу: нет, ничего я не напутал, все честно.

Вы меня спросите: а что ж это тогда за инфернальный пиздец? А я вам отвечу: это любимое Акадо какбе хочет показывать нам, как ведет себя TCP в перегруженной DOCSIS-сети.

Картиночка получилась очень просто: заливка файла по scp - один tcp поток, никаких торрентов, никакого шумящего вайфая в середине, ничего подобного. Все, повторяюсь, честно.

По словам Акадовской техподдержки, у них чего-то сломалось на нашем CMTS, и пришел дефицит upstream емкости. А DOCSIS - штука многоподлая в отношении upstream'а. Там, как все мы знаем, система request-and-grant и truncated binary exponential backoff (TBEB) с перепосылом ажно до 16 раз. Поэтому, в перегруженном DOCSIS'е пакетик в кабельном модеме может отлеживаться довольно долго.

Ладно, я не буду плеваться в Акаду по этому поводу. У всех аварии случаются. Хотя, конечно, они могли бы временно удавить скорость в upstream в моем районе. Чесслово, лучше честные 256k, чем вот такое вот.

А сегодняшний приз достается замечательным людям из Scientific Atlanta. За ихнее трепетное отношение к буферизации пакетиков. Эти люди не понимают, что пакет, который провалялся в буфере 28(!) секунд - никому нахуй не нужен. Делать такие глубокие буфера - бессмысленно полностью, т.е. абсолютно.

Что делает TCP в таких условиях? Он льет себе потихонечку в буфер, ack'и приходят рано или поздно, дропов нету, TCP разгоняется, заливает буфер еще сильнее и т.д., пока каналом пользоваться становится совершенно нельзя, ибо все начинает разваливаться: броузить нельзя - соединения просто не устанавливаются при такой задержке, почта не ходит, ибо отваливается по таймаутам, про ssh и говорить нечего. Рано или поздно что-то дропнется, TCP замедлится, но разгонится снова, и так далее по классической пиле. Только у нормальной пилы период в сотни миллисекунд, что работать не мешает, а здесь в десятки секунд.

Чем думали наши дорогие друзья из SA, когда придумали сделать такие очереди без AQM? Наверное, какие-то благие побуждения у них были. Впрочем, кто ж их знает - см. эпиграф.

Интеллигенция

2009-09-25T17:37:08Z

Я многократно говорил, что я не люблю интеллигенцию. К интеллигентам отношусь терпимо, а вот интеллигенцию не люблю, как явление.

Вся эта история с письмом Подрабинека замечательно иллюстрирует почему. Этот господин разразился беспредельно гнусным письмом в сторону ветеранов, за что его начали прессовать Наши. ЖЖшная интеллигентная публика тут же начала причитать о незавидной судьбе г-на Подрабинека.

Что же, собственно, заставляет эту по большей части порядочную публику так переживать за мерзавца? Ну ведь объективно, мерзость этого письма видна невооруженным взглядом. Вот например, avva@lj, в порядочности которого я ничуть не сомневаюсь, вынужден прибегнуть к очень натужному ментальному выкрутасу, чтобы вытеснить письмо из сознания и позволить себе сказать "Подрабинек во всем прав и молодец".

Разгадка этого проста. Подрабинек для интеллигенции свой, а своему простится любая гадость, сделанная в отношении чужих. А когда чужие (те же самые, в отношении которых сделана гадость, или другие - не важно) начинают высказывать недовольство, тогда необходимо дать отпор единым фронтом. Эта так называемая интеллигенция не более чем примитивный кланчик, объединенный взаимной лояльностью.

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

Да, и это объясняет, почему в интеллигентских кругах самым обсуждаемым вопросом является "что же такое интеллигенция, и кто такой интеллигент". Это совершенно естественно. Для примитивного сообщества, задача которого обслуживать интересы своих членов, вопросы принадлежности, вопросы классификации свой/чужой - это самые важные вопросы.

ГЛОНАСС и ГЭС

2009-09-25T16:03:32Z

Ехал сегодня домой и слушал в машине радио. Радио произнесло что-то вроде: "Крупномасштабной аварии на Саяно-Шушенской ГЭС можно было бы избежать при наличии на станции специальных датчиков ГЛОНАСС, которые измеряют вибрацию. Как сообщает ИТАР-ТАСС, такое мнение высказал сегодня в беседе с журналистами вице-премьер РФ Сергей Иванов."

Я от такой заявки мрачно охуел. Ну, какой нафиг ГЛОНАСС для измерения вибрации? Всякие GPS'ы и ГЛОНАССы меряют с метровой погрешностью. Чего им там можно измерить?

Приехал домой, полез гуглить. Да, Иванова все цитируют. Блоггеры злорадствуют.

Я уж было хотел присоединиться к стройному хору обличителей, но задумался. ГЛОНАСС - это не только ценный мех^W^W источник координат, а еще и источник точного времени. А синхронизация времени очень нужна в сетях с распределенными датчиками.

Иногда все-таки полезно придержать себя и не бросаться оплевывать говном высокопоставленного придурка. Погуглишь для начала - узнаешь что-нибудь интересное.

А вот после погугления уже можно отметить, что Иванов - все равно мудак, и заебал уже торговать своим ГЛОНАССом.

Declare victory and go home

2009-09-19T19:39:34Z

Iljitsch van Beijnum in ietf@ietf:
"a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard"

Действительно. Конечно. Безусловно. Статус RFC - это, пожалуй единственное, что мешает повсеместной победе добра над разу^W^W^W IPv6 во всем мире.

Архитектура - это застывшая музыка

2009-06-01T19:39:47Z

Сегодня я увидел кое-что Прекрасное.

Я, когда устаю работать и хочу побездельничать, обычно хожу в гуглоридер почитать всякие новости-сплетни, башорг и прочую расслабляющую дребедень. Вот и сегодня... Но до башорга не дошел. Смотрю, сверху в списке драфтик с интригующим названием. Дай, думаю, гляну. Глянул.

Встречайте, E6 Addressing Scheme and Network Architecture.

Аплодирую автору стоя.

Только настоящему таланту дано написать документ настолько беспощадный в своей бессмысленности и бессмысленный в своей беспощадности. Это даже не летающие свиньи из RFC1925 - там все-таки свиней заставляли летать с какой-то подразумеваемой целью. Здесь - нет! Здесь они полетят только потому, что это отвечает эстетическим запросам автора, который не связан не только мелкими и пошлыми соображениями целесообразности, но и целеполагания как такового. Я считаю, что это архиверный подход, - ибо только так можно сделать что-то действительно возвышенное.

Нужна кристальная ясность мысли, чтобы так полно и точно придерживаться в своей работе принципа "много нового и много правильного". Не беда, что то новое не правильно, а правильное не ново. Пускай. Нет никакой необходимости пачкать одно другим. Пусть они просто будут рядом, не касаясь друг друга.

Заслуживает отдельной похвалы выбранная автором стратегия архитектурного проектирования. Если нечто нельзя за пол-лекции объяснить похмельному студенту, то этому совершенно не место в архитектуре Сетей Будущего. Действительно, ну кому нужен этот дурацкий TCP'шный и не-TCP'шный congestion control вместе со всем TCP? LLC2 прекрасно со всем справится, ведь у него даже предусмотрено скользящее окно! Я, кстати, думаю, что здесь недоработка. Скользящие окна стоило бы тоже запретить - от них оверхед и сплошное расстройство чувств.

Я уверен, что такое замечательное начинание, как E6 Network Architecture, найдет своих горячих поклонников. Я уже в их числе.

Detecting ASN32-capable routers in the Internet (revisited)

2009-05-15T15:40:37Z

Уважаемые, я должен вам признаться, что я лох. Тупой лох.

В прошлом посте я предложил критерий выбора одного из решений системы логических уравнений, возникающей при обнаружении ASN32-capable роутеров по сочетаниями BGP атрибутов.

Мало того, что этот критерий довольно произвольный, так он еще и не приводит к единственному решению. Таких решений на том dataset'е, который у меня есть, - 1728 штук. В общем, файлик с решениями, удовлетворяющими выдвинутому критерию, здесь: allminsol.txt.

В принципе, эти решения имеют много общего, так что "какую-то" картинку на их основе можно сложить.

Где была моя голова, о чем я думал? Почему мне показалось, что такое решение одно? Не понятно.

Мне очень стыдно за свою тупость, простите меня. Пойду заливать стыд пивом в ближайшую пивную.

Надо что-то придумывать. Во-первых, побольше данных. Больше данных - больше ограничений в системе - меньше решений. Во-вторых, мой критерий явно дурацкий, нужен другой.

Detecting ASN32-capable routers in the Internet

2009-05-12T20:12:28Z

Уже некоторое время 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

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

В AS65537 определенно есть новый софт (спасибо, Капитан Очевидность)
В AS10 нового софта не замечено. Если б он там был, то AS4_PATH был бы длиннее.
Про AS40 и AS50 неизвестно ничего. Даже если в них и есть новый софт, то он был "скрыт" новыми роутерами, через которые апдейт прошел потом.
А вот с 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 на этих роутерах получили в довесок и специально выключать ее не стали.

Дальше

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

Blog upgrade

2009-04-26T18:11:38Z

Проапгрейдил MT на 4.25. Новая версия не захотела принимать бэкап старого блога, и пришлось пойти путем экспорта/импорта. Все засосалось, но поменялись идентификаторы постов в фиде, так что ридеры покажут некоторое количество старых записей, как новые. Я дико извиняюсь за это неудобство.

Ежели еще чего поломано, прошу жаловаться. Буду по возможности чинить.

Райффайзен, продолжение

2009-04-03T09:23:09Z

В продолжение к предыдущему.

Райффайзен заявление рассмотрел, расследовал, от претензий отказался, бабло вернул. Причем вернул правильно - по тому курсу, который был на момент возникновения "задолженности".

Ну что ж, молодцы. Уважаю за умение признавать ошибки. Это в наше время среди банков редкость.

Лох - это судьба

2009-03-18T16:07:52Z

Некоторое время назад я матерился в адрес альфабанка (пользуясь случаем в очередной раз желаю им сдохнуть в корчах).

Так вот, видимо, жизнь меня ничему не учит. Нынче на практически такую же фигню я налетел в Райффайзене.

Они умудрились год назад перевыпустить одну из моих карточек, но ничего мне про это не сказать. Взяли комиссию, которая задвинула карточный счет в минус на какую-то незначительную сумму. В connect.raiffeisen.ru об этом, естественно, ни слова - там просто нарисован 0. Потом в июле, когда они от меня приняли завление на закрытие карточки, они опять же не сказали о минусе ни слова и заявление не исполнили, при этом само заявление осталось лежать у них в архиве и они мне его сегодня вытащили. А на минус погнались овердрафтовские проценты.

В общем, пару дней назад они таки проснулись и прислали СМСку. Минус за это время вырос в несколько раз и превратился баксов в пятьдесят. В connect.raiffeisen.ru опять же нарисован нолик.

Сегодня ездил писать заявление, краткое содержание которого сводится к "а вы, часом, не охуели?". Рядом стояла парочка, у которой аналогичный минус вырос за несколько лет до 20000 руб.

Я понимаю, кризис-хуизис, долги взыскивать. Но сначала: починить интернет-банк и научить своих клерков не проебывать заявления.

Тем временем, подыскиваю альтернативный банчок, чтобы послать Райффайзен в жопу. Советы принимаются.

Сам себя не похвалишь ...

2009-02-21T15:45:31Z

Смотрю презентации с MWC2009. Bruce Davie и Yakov Rekhter хором рассказывают про использование BGP+labed unicast для масштабирования MPLS в нескольких IGP area. Я такую конструкцию описывал полтора года назад - http://net-geek.org/dbg/2007/08/interarea-ldp.html. Там конфиги и описание, как это работает.

Сижу и горжусь собой.

Там есть еще много интересного. Как появятся презентации в открытом доступе, обсудим. Stay tuned.

Достижение

2009-02-20T19:24:01Z

Вышел вечером на часик пересечься с коллегой в ближайшем кабаке.

Возвращаюсь домой, жена обнюхивает.

- Дорогая, чего принюхиваешься? Да, выпил.
- Да я пытаюсь определить, чего пил.
- Пиво пил.
- Да нет. Это я понимаю. Какое ...
- Ну, давай, определяй.

Принюхивается внимательно.

- Стаут!
- !!!!

Всегда хотел научить жену разбираться в пивах. Теперь горжусь - воспитал.

Long prepends

2009-02-20T17:10:45Z

Вот оно, оказывается, как: http://www.merit.edu/mail.archives/nanog/msg15730.html
Аплодирую наблюдательности.

Оказывается, так ведет себя Mikrotik в некоторых версиях. Если попытаться задать препенд номером AS, как мы все привыкли, то он интерпретирует это не как ASN, а как число ASN, которыми надо запрепендить AS_PATH, возьмет остаток от деления на 256, и собственно, запрепендит - мало не покажется никому.

Мораль? Молчаливые "нормализации" параметров - зло злодейское. Ну и с интерфейсом выделываться не надо - делай семантику как у всех, а то потом люди будут удивляться.