Recently in rants Category

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

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

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

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

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

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

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

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

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

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

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

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

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

На слешдоте обсуждали грузинскую цензуру по отношению к российским новостным сайтам. Утверждают, что блокировка - DNS-based. Похоже, что это и в самом деле так, но этим оно не ограничивается.

[13:42] dg@iddater:~$ dig @62.168.168.2 lenta.ru. any

; <<>> DiG 9.3.4 <<>> @62.168.168.2 lenta.ru. any
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49807
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;lenta.ru.                      IN      ANY

;; AUTHORITY SECTION:
ru.                     86400   IN      SOA     ns0.caucasus.net. root.caucasus.net. 2008102903 14400 3600 1209600 172800

;; Query time: 170 msec
;; SERVER: 62.168.168.2#53(62.168.168.2)
;; WHEN: Mon Aug 18 13:43:08 2008
;; MSG SIZE  rcvd: 83

Видно, что люди решили проблему радикально, и в соответствии с принципом “Разве может что-нибудь хорошее прийти из Назарета?”, накрыли медным тазом целый TLD.

Кстати, есть у кого-нибудь предположения, что может означать такой странный serial?

Для особо умных, которые умеют обращаться с собственным рекурсором и не пользуются провайдерским, есть второй слой блокировки - на уровне IP.

Вот пинги lenta.ru:

PING 81.19.69.232 (81.19.69.232) 56(84) bytes of data.
From 80.241.178.70 icmp_seq=3 Packet filtered

--- 81.19.69.232 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2009ms

Как видно, приезжает ICMP 3/13 от 80.241.178.70.

И соседнего адреса:
PING 81.19.69.233 (81.19.69.233) 56(84) bytes of data.
64 bytes from 81.19.69.233: icmp_seq=1 ttl=42 time=132 ms
64 bytes from 81.19.69.233: icmp_seq=2 ttl=42 time=131 ms
64 bytes from 81.19.69.233: icmp_seq=3 ttl=42 time=132 ms

--- 81.19.69.233 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2037ms
rtt min/avg/max/mdev = 131.702/132.192/132.802/0.544 ms

Как видно, тут сделано несколько поизбирательней - блокируется только "вражеская пропаганда".

От оценок я воздержусь, пусть каждый делает выводы сам.

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

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

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

Речь о том, что 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, коллеги.

Что обычно говорят жены своим мужьям, когда уезжают в отпуск, а мужья остаются дома? Ну, например, "много не пей", или там "будешь девок водить - яйца оторву". А вот моя любимая супруга, уезжаючи, сказала: "дорогой, ну ты только по книжным не злоупотребляй, а то я ведь тебя знаю".

Действительно, этому пороку я подвержен. Захожу в книжный магазин - у меня начинается такая легкая лихорадка, немножко кружится голова, и чую подступающее безумия. Выхожу обычно со стопкой в 5-6 книжек - это, считай, легко отделался.

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

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

А вот дядька мой - вот он натуральный маньяк. В нашу квартиру помещалось тысячи три томов и все было как-то цивилизованно, а в дядькину помещалось в два раза больше и там были Книжные Джунгли. Каждый год мы ездили в бабушке в деревню, что на Урале, и проездом гостили в Среднеуральске у тетки и дядьки и моих двоюродных брата и сестры. Это было офигительно, на самом деле. Помимо всего прочего, дядька собирал фантастику. Всю. Все что из фантастики издавалось в стране, у него было. Так вот, у него в квартире книги везде, вообще везде. Из любой точки протянешь руку, а у тебя в руке что-нибудь очень интересное. Дядьке на днях будет 70. С днем рождения, дядя Гера!

Да. Чего-то я заболтался. Я хотел сказать, что в один из последних заходов в книжный (дорогая, всего три раза за этот месяц, не больше, клянусь!), я приобрел пару книжек Лео Каганова. Как я раньше это пропустил, я не знаю. Мне очень понравилось. Много смеялся, немного грустил. В общем, удовольствие получал. Рекомендую.

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

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

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

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

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

Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.

Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.

Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.

До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.

Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.

Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).

Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.

В 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

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

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

Я как-то упоминал про P4P.  Вот замечательная новость трехнедельной давности: Verizon touts smart P2P software.

Using network topology data from Verizon and Telefonica, Yale University tested a software enhancement to the peer-to-peer protocol that it developed with software developer Pando Networks.

What the researchers discovered was that when using the so-called P4P software they were able to reduce the impact of peer-to-peer traffic on Verizon's network by more than 50 percent. This is significant because peer-to-peer traffic makes up roughly half of all traffic traveling over Verizon's network.

....

He said that when the P4P software was used on the Verizon network it found that 58 percent of its peer-to-peer network traffic stayed local. Using regular P2P technology, only 6 percent of the traffic stayed local.

Это очень, очень хороший результат. И шаг в правильном направлении. Аплодисменты Верайзону.
Очень хочется надеяться, что остальные пойдут по тем же стопам.

Устройство эрланговских 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 км отсюда. Не может не радовать.

Первое апреля в этом году наступило неожиданно.

Some document authors want to express requirement levels using the traditional definitions of "MUST" and "SHOULD" from RFC 2119, but also want to express that there is an expectation that later versions of the document may change those requirements. For example, they may want to express "this SHOULD be implemented now, but we expect that this will become a MUST requirement in a future update to this standard". This document defines three new keywords, "MUST-", "SHOULD+", and "SHOULD-" to facilitate such definitions.

http://tools.ietf.org/html/draft-hoffman-additional-key-words-00

Я бы сказал, это doubleplusgoodthink. Огромные просторы открываются.

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

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

Cisco EVC:

interface GigabitEthernet1/0/1
 service instance 1 ethernet
 encapsulation dot1q 1000
 rewrite ingress tag pop 1 symmetric
!
interface GigabitEthernet1/0/2
 service instance 2 ethernet
 encapsulation dot1q 2000
 rewrite ingress tag pop 1 symmetric
!
connect tag-to-tag GigabitEthernet1/0/1 1 TenGigabitEthernet1/0/2 2

Что получается? Правильно, свитчинг по тэгу, безо всякого глупого mac learning'а. Типа как по DLCI в FR. А если два тэга задействовать, то получится VCI/VPI, как в ATM.

Я на самом деле давно хочу мелкую коробочку, которая делала бы именно это - тупо и линейно занималась vlan tag switching'ом. А ежели к этому приделать какую-нибудь сигнализацию, которая могла бы сказать, что "vlan tag vc" умер и можно переключаться на защитный, то было бы совсем хорошо.

This entry was originally posted in my livejournal

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