Recently in rants Category

Уважаемые, а давайте пофлеймим? Я кое-что скажу, а вы мне в ответ скажете, что я дурак и нихрена не понимаю.

А скажу я вот что: цископикс (ну и его производные) - говно.

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

Речь о том, что PIX - говно по построению. Сам принцип, по которому действует PIX, не позволяет построить что-либо, кроме говна.

А именно, попытка анализировать и модифицировать пакеты в некотором контексте, выведенном из пролетающего мимо трафика, - идея заведомо ущербная. Вот возьмем TCP, к примеру. TCP по своему дизайну - end-to-end протокол. Функции согласования параметров, сборки потока, ретрансмиссии, контроля скорости и все остальные выполняются на оконечном устройстве. Попытка вмешаться в пролетающие пакеты без взятия на себя всех функций неминуемо ведет к неисчислимым бедствиям.

Перейдем к примерам.

Я тут повспоминал, и понял, что PIX последовательно и неуклонно просрал все полимеры по очереди.

ECN просрал? Тупо и линейно. PIX присылал RST на SYN с установленными ECN-флагами (CSCds23698).

SACK просрал? Еще как! С фейрверком. PIX и ASA рандомизируют TCP sequence numbers, а тот sequence number, который внутри SACK option - забыли (CSCse14419). Oops.

Window scaling просрал? Просрал самым классическим образом. До некоторой версии window scaling не поддерживался. Попытка контролировать window overshooting в сочетании с непониманием window scaling приводил понятно к чему: пикс думал, что окошко маааленькое, и дропал совершенно нормальные пакеты. Починили это несчастье только в 2006 году, если мне не изменяет склероз. Т.е. через 14 (!) лет после выхода RFC 1323. Аплодисменты.

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

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

Вы мне скажете: Даня, ты дурачок, это же security, security is supposed to break things.
Так я вам отвечу: Ежели так, то глобальная ядреная война - это the ultimate security solution. Вот взять, долбануть всех Бомбой и чтобы никто и никуда, и чтобы ша, и чтобы тихо и ничего не шевелилось.

/me облачился в asbestos suit. Расчехляйте flamethrower, коллеги.

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

Что я имею по этому поводу сказать.

Социальная рознь у меня со всей этой сволотой существует объективно. Эту рознь не надо разжигать. Они сами замечательно c этим справляются. В том числе и такими вот приговорами.

А что касается методов наведения порядка среди прокуроров, ментов, журналистов и депутатов, то децимации должны помочь.

В ru_telecom@lj сегодня часа в 2 ночи какое-то существо запостило следующий текст (пост удален, но яндекс все помнит):

17 мая 2008 года около 11:30 рейдерами был захвачен домен, с 1997 года принадлежащий ОАО "Вашъ Финансовый Попечитель" - VFP.RU. Подложный сайт компании разместился в хостинговом центре ХЦ РБК. 20 мая контроль над доменом был восстановлен. В базе данных компании-регистратора RU-CENTER появились новые, легитимные данные об адресе настоящего сайта ОАО "ВФП" - 195.68.187.163. Но не все серверы доменных имен обновили информацию о вэб-сайте. Например, серверы компании Голден Телеком (194.85.128.10 и 194.85.129.80) указывают на заведомо ложный адрес нашего сайта. Получается, что Рунет (по крайней мере его часть) не является свободной средой распространения информации, а используется некоторыми нечистоплотными операторами для выполнения рейдерских заказов.

Ахринеть. Круто. Смотрим.

$ whois vfp.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:     VFP.RU
type:       CORPORATE
nserver:    ns.vfp.ru. 195.68.187.163
nserver:    ns.rusmedia.net.
state:      REGISTERED, DELEGATED
org:        Vash Finansovy Popechitel Ltd.
phone:      +7 495 2536984
fax-no:     +7 495 9564386
e-mail:     boris@vfp.ru
registrar:  RUCENTER-REG-RIPN
created:    1997.09.24
paid-till:  2008.10.01
source:     TC-RIPN


Last updated on 2008.05.23 10:41:53 MSK/MSD

На TLD-серверах все зашибись:

$ dig +nostats +nocomments vfp.ru @NS.RIPN.NET

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @NS.RIPN.NET
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      A
vfp.ru.                 345600  IN      NS      ns.rusmedia.net.
vfp.ru.                 345600  IN      NS      ns.vfp.ru.
ns.vfp.ru.              345600  IN      A       195.68.187.163

Смотрим на авторитетные сервера для зоны:

$ dig +nostats +nocomments vfp.ru @195.68.187.163

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      A
vfp.ru.                 7200    IN      A       195.68.187.163
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       195.68.187.163
$ dig +nostats +nocomments vfp.ru @195.68.187.163 soa

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163 soa
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      SOA
vfp.ru.                 7200    IN      SOA     ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       195.68.187.163
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      A
vfp.ru.                 7200    IN      A       213.243.107.145
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       213.243.107.145
ns.rusmedia.net.        43200   IN      A       195.230.64.13
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net soa

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net soa
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      SOA
vfp.ru.                 7200    IN      SOA     ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       213.243.107.145
ns.rusmedia.net.        43200   IN      A       195.230.64.13

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

Устройство эрланговских port drivers - пожалуй, самое странное из всех FFI, с которыми я когда-либо сталкивался. Попытки как-то облегчить ситуацию только ее ухудшают и приводят к перверсиям типа Dryverl: это ж можно мозгом ебануться, писать драйвер на XML, вписывая в этот развесистый пиздец кусочки C и Erlang кода.

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

Какая, казалось бы, хорошая идея, сделать так, чтобы крэш роутера не прерывал трафик, идущий через него. Достоинств куча: упрощается сеть - не надо ставить вторую коробку; можно обойтись одним только link protection и забить на node protecion, если с питанием все хорошо; можно сэкономить немножко денег - опять же за счет дублирующей коробки, за счет rack space, за счет операционных расходов на конфигурацию и мониторинг второй коробки; можно улучшить доступность для single-homed подключений. В общем, это должно быть круто.

Собственно, этому ничего не мешает - у современного роутера control plane и forwarding plane раздельны. Поэтому, если control plane упал по софтверной ошибке или по отказу процессорного модуля, forwarding plane вполне может продолжать бег, как та курица с отрубленной головой. А тем временем запасной процессорный модуль, обнаружив такое безобразие, переговорит с соседними роутерами, восстановит состояние протоколов, возьмет контроль над безголовым forwarding plane и все продолжится в нормальном режиме. Такая конструкция называется NSF/SSO (Non-Stop Forwarding/Stateful Switchover) и graceful restart.

Все ли хорошо в этой схеме? Нет.

Весь этот NSF/SSO основан на трех предположениях:

1. При падении процессорного модуля forwarding plane остался в целости и сохранности.
2. Соседи падающего роутера могут достоверно понять, что с ним случилось: отказал control plane, forwarding plane или весь ящик целиком?
3. В процессе восстановления состояния протоколов по информации от соседей не произойдет временного разрушения forwarding.

Все три предположения в общем случае неверны.

1. Целостность FIB. Если был железный отказ RP, кто сказал, что этот отказ произошел не во время FIB update? Если нам не повезло, и отказ случился именно в такой неудобный момент, то FIB может оказаться в неконсистентном состоянии. Масштаб этой неконсистентности зависит от организации FIB. Может быть, кривым останется один маршрут - это более вероятно при табличной организации FIB на основе TCAM, а может, от всего FIB'а остались одни ошметки - такое совсем не исключено, если для FIB используется какая-нибудь сложная структура данных.
   
   Т.е. для надежной работы NSF необходимы транзакционные FIB updates. В принципе, это сделать можно, но довольно сложно. FIB оптимизируется в первую очередь под задачу быстрого lookup - это самое главное, во-вторых под компактность в случае non-TCAM-based FIB - быстрая память, в которой приходится держать FIB, дорога, в-третьих под быстрые updates - это тоже немаловажно. Требование транзакционности неизбежно вступит в противоречие с этими тремя целями.
   
   Можно обеспечить более слабую версию транзакционности FIB update. Если на линейной карте есть свой управляющий процессор (а он таки есть), то можно проводить транзакцию FIB update с ним, а не непосредственно с FIB, а тот уже сам разберется. Т.е. получится гарантия целостности FIB относительно отказа RP, но не относительно отказа CPU линейной карты. Этого, в принципе, достаточно.
   
   Если же это падение по софтверной ошибке, то тут all bets are off. Если дело дошло до какого-нибудь SIGSEGV в монолитном IOS'е, то кто в здравом рассудке поручится, что перед этим падающий RP не превратил FIB в кровавое месиво? Тут надо падать с грохотом, с погашением лазеров и загружаться из cold state. Да, перерыв будет долгим, но зато конечным. Товарищи вендоры, не допускайте падения своих продуктов по такой симптоматике! А ежели такое, недайбоже, случилось, плюйте на всякий NSF и уходите на жесткий ребут всей коробки целиком.


2. Отличение соседями сбоев forwarding plane от сбоев control plane. Вся логика работы NSF основана на том, что соседи падающего роутера знают заранее: не надо пугаться, если с соседом что случилось, он еще может воспрянуть к жизни, а пока можно слать ему трафик. Однако оптимальная реакция соседа на отказ роутера, конечно же, зависит от вида отказа. Например, если с той стороны в линк не светят, то нет никакого смысла слать туда пакеты, надо быстренько перекинуть трафик в другом направлении.
   
   В общем случае логика должны быть такова: если у соседа отказал control plane, то ничего не предпринимаем, а когда тот начнет восстанавливать состояние, поможем, а если оказал forwarding plane, то разворачиваем трафик в другую сторону как можно быстрее. Другой способ действий чреват очень медленным восстановлением от сбоя. Проблема в том, что отличить отказ control plane от отказа forwarding plane бывает трудно.
   
   Для детектирования отказа control plane существуют протокольные hello/keepalives. Они должны быть достаточно медленными в случае NSF - надо, чтобы восстанавливающийся роутер успел начать восстановление до развала adjacencies. Масштаб - секунды, десятки секунд. Это, очевидно, неприемлемо для случаев отказа forwarding элементов, ибо в этом случае надо действовать быстро.
   
   Есть замечательное изобретение - протокол BFD, которое по идее должно обеспечить нам именно обнаружение сбоев в forwarding plane, причем обнаружение достаточно быстрое. Спасает ли наc BFD?
   
   Для того, чтобы BFD мог детектировать сбои forwarding plane, он должен работать исключительно на этом самом forwarding plane независимо от control plane. Ок, я не буду произносить все те слова, которые у меня накопились в адрес бывшего энтерпрайзного свитча, которые злые и циничные люди попытались превратить в сервис-провайдеский роутер. Все и так всё знают и понимают. Настоящие же роутеры могут исполнить BFD прямо с линейной карты. Это хорошо, но не покрывает все нужные случаи. Речь о наложенных топологиях, которые не совпадают с физическими. Пусть у нас есть протокольное соседство по pseudowire. Этот PW может выходить из нашей коробки сейчас через интерфейс на одном модуле, а через секунду через интерфейс на другом. Или, что еще хуже, входить через один, в выходить через другой. Где именно должен исполняться BFD, контролирующий adjacency через этот PW? Или вот взять multihop BFD для контроля далекого iBGP'шного next-hop - та же самая ситуация.
   
   Таким образом, общего решения задачи отличения сбоев forwarding plane от сбоев control plane не существует.


3. Непрекращение forwarding'а в процессе самого восстановления. Нас ведь интересует не просто восстановление чего-то там в сети. Нас интересует восстановление сервиса, за который клиент платит деньги. Возьмем, к примеру, какой-нибудь простецкий VPLS с autodiscovery. Что должно восстановиться, чтобы он продолжил функционировать? IS-IS (ну или OSPF), как IGP, раз. RSVP, как протокол сигнализации TE-туннелей, два. BGP, как средство autodiscovery, три. Targeted LDP, как средство сигнализации наших псевдопроводов, четыре. Совсем не мало.
   
   Вся эта банда протоколов рестартует [почти] независимо, сходится в произвольном порядке, апдейтит forwarding'овые таблицы кто во что горазд, взаимодействует друг с другом - например малейшая неаккуратность в восстановлении BGP'шных VPLS autodiscovery префиксов совершенно очевидным образом разрушит LDP-сигнализацию pseudowires, которым повезло выжить при отказе активного RP. Вся эта конструкция процессе сходимости может находиться в самых интересных промежуточных состояниях и целостность forwarding'а в этих промежуточных состояниях ой как не гарантируется. Известно лишь одно: рано или поздно оно сойдется и все станет хорошо, но, для того, чтобы NSF был действительно Non-Stop, этой гарантии "рано или поздно" мало.
   
   Роутер, стартующий из холодного состояния, тоже подвержен подобным проблемам, но для более или менее удовлетворительного решения этих проблем есть всякие механизмы типа LDP-IGP synch, overload bit при старте и т.д., суть которых сводится к заявлению "я еще не готов к работе, не надо слать через меня трафик". Очевидно, что это не годится для случая NSF.
   
   Изменение такого положения вещей потребует, пожалуй, полной переработки механики работы протоколов с тем, чтобы они больше знали о внутреннем состоянии друг-друга и избегали странных промежуточных поз. Очень большая работа. И я совсем не уверен в том, что это вообще возможно.

Каков итог? Итог прост: NSF/SSO вряд ли когда-нибудь будет работать нормально, пусть даже вендоры вылижут реализацию до блеска. Это - гиблая затея. И если оно иногда срабатывает гладко, то это происходит по чистому везению. Строить на этом сервис с гарантиями нельзя.

Неужто нам никогда не будет счастья? Может быть и будет. Следующий кандидат - NSR, Non-Stop Routing. Идея в том, что оба RP, и активный, и запасной, всегда несут полное состояние. И при отказе одного, второй тут же подхватывает управление. Т.е. ситуации "курица, бегущая без головы" не возникает. Не рвутся и не восстанавливаются протокольные adjacency; запасной RP, став активным, может сразу проверить целостность FIB, а то и тупо-линейно сформировать его заново; не надо детектировать раздельные отказы - ящик либо сдох, либо жив во всех своих частях (наверное жив, тут тоже могут быть нюансы), не надо надеяться на безглючность реализации graceful restart соседом. Реализации NSR в природе существуют. Я, правда, еще их подробно не испытывал. Наверное, испытав, опять буду ругаться. Но есть хотя бы надежда.

А что делать сегодня? Ставить две коробки. Да, деньги. Да, rack space. Да, сложность сети. Но если действительно нужна отказоустойчивость, то другого выхода нет. Ну а можно сыграть в оптимиста и забить на недостатки NSF, только надо четко понимать, где здесь выигрыш, а где проигрыш.

Несколько дней назад, когда мы с уважаемым reedcat@lj собрались за стаканчиком, он рассказал мне хороший анекдот про Носика и оказался прав. Я понимаю, что Носик - занятой человек, и читать то, на что он ссылается, ему некогда. Вот он и занес меня в расстрельные списки Вербицкого. Что я могу сказать? dolboeb.

Впрочем, я не сильно бы переживал, если б я действительно был в том расстрельном списке. Я только отказываюсь быть в нем на одной строчке с Мариной Литвинович. Миша, может быть ты перепишешь меня на отдельную страничку? :)

А в Йоханнесбурге лето. Cолнце, зелень, небо южнополушарное. После Москвы контраст потрясающий. И dolboeb'ы в 10000 км отсюда. Не может не радовать.

Я всегда знал, что это враги. Но это уже вообще за рамками.

Network Solutions is under fire this week for domain "front running," or for purchasing and holding certain domains after they're searched for at the company's website, thereby not letting anyone buy the domain at other registrars. For example, should you be in the business of eating aardvarks and try to search for the availability of the domain eataardvark.com at Network Solutions, the website will show you that it's available.

Within seconds, Network Solutions subsequently registers the domain for five days, preventing users from buying it anywhere other than Network Solutions. Places where, in many instances, you might be able to get a better deal should you want to shop around.

http://www.dslreports.com/shownews/Network-Solutions-Holding-Domain-Names-Ransom-90862

Мало того, что это злодейство, это еще глупое злодейство. Ибо не достигает декларируемой цели защиты от сквоттеров и фронраннеров.

Не могу удержаться, чтобы не поделиться ссылкой: http://blog.lexa.ru/2007/12/25/sberbank_sdelal_moj_den.html
Аплодирую сбербанку стоя. Твердое второе место на известно каком конкурсе.

Update в целях яндексотопопиара: http://alextutubalin.livejournal.com/57351.html

Three engineers were in the bathroom standing at the urinals. The first engineer finished and walked over to the sink to wash his hands. He then proceeded to dry his hands very carefully. He used paper towel after paper towel and ensured that every single spot of water on his hands was dried. Turning to the other two engineers, he said, "At Cisco, we are trained to be extremely thorough."

The second engineer finished his task at the urinal and he proceeded to wash his hands. He used a single paper towel and made sure that he dried his hands using every available portion of the paper towel. He turned and said, "At Juniper, not only are we trained to be extremely thorough, but we are also trained to be extremely efficient."

The third engineer finished and walked straight for the door, shouting over his shoulder, "At D-Link. we don't pee on our hands."

Хехе. В cisco_ru замечательный тред. Участники "освоили" модель OSI и предлагают пытать ей на собеседованиях кандидатов в начинающие цисководы. Я всегда говорил, и повторю еще раз: OSI reference model - на 90% глупая схоластика, типа подсчета числа чертей на кончике иглы. Все, что про нее надо знать это то, что уровней там семь, чем отличаются первые четыре друг от друга, и что ортодоксальность в ее применении свидетельствует об ущербном кругозоре ортодокса.

Но самое главное, почему я считаю вопросы про OSI вредными - это то, что они очень легко приводят к совершенно контрпродуктивным дискуссиям по совершенно неинтересным вопросам. Один из таких глупых вопросов - это "какого уровня MPLS". Классический, можно сказать. Когда я увидел первый комент в том треде про OSI, я подумал, что дискуссия быстро докатится до чего-нибудь подобного. И я не ошибся. Джигиты посрались именно об этом ключевом вопросе современности.

Для интересующихся вопросом процитирую Якова Рехтера:
Just to help more, here are few points from one of my presentations
on (G)MPLS:

(G)MPLS is not a Network Layer on its own, as it does not have routing
and addressing on its own - it uses IP addressing + IP routing (with
extensions)

(G)MPLS is not a Link Layer because MPLS works over various Link Layer
technologies (e.g., SONET, Ethernet, ATM, etc.)

(G)MPLS is not a Layer in the OSIRM (OSI Reference Model) sense as it
does not have a single format for transport of the data from the
layer above (e.g., (G)MPLS uses "shim" on SONET, VCI/VPI on ATM, time
slot on TDM, lambda on OXC, etc...).
http://cell.onecall.net/mhonarc/mpls/2004-Nov/msg00031.html

Схоластам привет!

This entry was originally posted in my livejournal