Recently in networking Category

На слешдоте обсуждали грузинскую цензуру по отношению к российским новостным сайтам. Утверждают, что блокировка - 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

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

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

Сейчас в end2end-interest идет интересная дискуссия: Why do we need TCP flow control (rwnd). Там выступают очень правильные люди и говорят очень интересные вещи. David P. Reed (тот самый) поделился очень правильной мыслью: So the rwnd parameter is NOT actually measuring buffer pool size. It is actually a control loop that measures the endpoint application's ability to do work.

У меня есть предположение, что мы наблюдаем это прямо сейчас в некоторых реализациях TCP.

Часто на форумах встречаются вопросы про сообщение "TCP: Treason Uncloaked!". Некоторые предполагают, что это атака, некоторые - что это ошибка в реализации TCP.

Код ядра, где возникает это сообщение, вполне прозрачен: если получатель закрыл окно, а у нас есть сегменты "в полете", то что-то здесь не так. В принципе RFC1122 (пункт 4.2.2.16) настоятельно не рекомендует получателю так поступать:

A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left.  However, a sending TCP MUST be robust against window shrinking

Воспроизвести такое сообщение очень просто. Вот скрипт для hping3, который делает именно это. Если будете экспериментировать, не забудьте зафильтровать исходящие RST.

Я предполагаю, что такое поведение получателя - это не ошибка, а намеренное следование принципу, который высказал David Reed. И в самом деле, у нас теперь много мобильных устройств. Чем они характерны? У них мало памяти и они часто выходят в интернет через соединения с огромным RTT.

В этих условиях будет разумным анонсировать относительно большое окно, но буфер подо все окно не резервировать, а надеяться на то, что приложение будет выгребать данные достаточно быстро, и буфер не успеет заполниться. Конечно, помимо всего прочего, у этих устройств относительно слабый CPU, и приложение иногда не успевает потреблять данные из сокета. Тогда стеку не остается ничего другого, кроме как окошко прикрыть, несмотря на то, что раньше окно было анонсированно довольно большое.

Хорошо такое поведение или плохо? С одной стороны у мобильного стека большого выбора нет: линк с большим RTT хочется держать заполненным, но памяти под соотвествующий буфер нет. С другой, стек сервера в случае tcp treason продолжает режим retransmit'ов, а не входит в tcp persist, как было бы, если окошко закрылось нормально, т.е. генерирует пакетов больше, чем нужно.

Есть у кого-нибудь машина, куда приходит много мобильных клиентов? С благодарностью приму запись трафика TCP-сессий, в которых возникал tcp treason. Хочется навести кое-какую статистику.

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

Некоторые авторы связывают сообщение "TCP: Treason Uncloaked" с DoS-атаками и странным поведением apache. Но все что удается найти по этому поводу - не более чем circumstatial evidence. Мне не ясен механизм, как таким образом можно заDoSить машину. Исчерпать память ядра буферами? Есть у кого-нибудь из уважаемых читателей более внятные свидетельства о связи tcp treason с DoS-атаками? 

P.S.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)

Очередной интересный Google Tech Talk:

http://www.youtube.com/watch?v=IBPg9Lyta3A&feature=user

Докладчик Nick Feamster. Он, помимо всего прочего, автор нескольких очень интересных статей про interdomain routing: http://www.cc.gatech.edu/~feamster/publications/. Очень рекомендую к прочтению.

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

Вот какая есть штука: между работой 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, то получится похоже на то, что я хочу.

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

Я как-то упоминал про 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.

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

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

Давным-давно в беседе на IRC с одним коллегой из циски я сказал, что BGP - давно уже не только и не столько routing protocol, собеседник помялся-помялся, но согласился. Сейчас вот мне эта беседа чего-то вспомнилась и я решил написать немного подробней.

Почему же BGP не только routing protocol. Дело в том, что этот замечательный протокол давно уже приспособили для переноса очень разной информации (я как-то упоминал отличный Google Tech Talk с Яковом Рехтером - он там про это немного говорит). Действительно: QoS Policy Propagation, BGP-based VPLS, autodiscovery всех типов, you name it. То, что нынче ездит по BGP, с трудом можно назвать "маршрутом". Т.е. в современной сети BGP (iBGP, если быть точным, с eBGP есть ) - это не просто способ донести какие-то маршруты отсюда досюда, а универсальная инфраструктура для распространения практически произвольной информации в сети.

Рехтер утверждает, что BGP делает это эффективно. Я почти согласен. BGP, как инфраструктура распространения произвольной информации, очень хорош: можно переносить практически все что угодно, ограничений на количество переносимой информации практически не существует (важна частота изменений, но не само количество), можно всячески фильтровать, кто хочет, тот эту информацию слушает и хранит, а кому какая-то не информация не нужна - так не слушает и не хранит. Все здорово. Почти.

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

Дело вот в чем. Когда появляется очередное приложение BGP, разработчики протокола берут AFI/SAFI, изобретают NLRI с какой-то структурой, возможно придумывают еще один-два extended community со специальной семантикой - и вперед.

Естественно, для того, чтобы новый address family заработал, надо, чтобы его понимали оба BGP пира - ведь если один не понимает этот AF, то эта информация ему и не нужна. Казалось бы, логично. Но нет. Есть исключение - route reflectors. Им на самом деле пофигу на address family, их роль проста - принять анонсы, прогнать BGP decision process и раздать анонс, а что внутри, им по барабану. В нынешней схеме для поддержки новой address family приходится апгрейдить и конфигурить route reflector'ы  - во-первых лишняя, а во-вторых рискованная работа: баги, недосып, похмелье, кривые руки.

Что бы спасло положение? Wildcard address family capability. Все просто: отдельный AFI/SAFI для использования в capability advertisement и небольшое дополнение к decision process, типа просто пояснение о том, как его делать на неизвестном типе NLRI.

Написать драфт, что ли?

В прошлом посте я кратко упомянул вопрос flow fairness в разрезе P2P, а сегодня вот накопалась интересная статья на предмет flow fairness вообще: Flow Rate Fairness: Dismantling a Religion. Статья написана несколько необычно для такого рода публикаций, вот что пишет сам автор:

It is a classic case of a hegemony where those living within the box don’t recognise the existence of the box, let alone the world outside the box. This paper was written from frustration that no-one inside the box believes that voices outside the box should be listened to. We expect complaints about the blunt style of this paper, but it seemed the only way forward was to force the issue, by making the box look ridiculous in its own terms.

И идеи, которые высказываются в статье, на первый взгляд выглядят неоднозначно. По крайней мере, непривычно. Некоторые из них звучат вполне логично, а некоторые мой разум/опыт сходу не принимает. Но прочитать стоит, и стоит обдумать.

Мне тут на днях хороший человек lesham подогнал свежачок (за что ему отдельное спасибо) - материалы с конференции MPLS 2007: http://www.isocore.com/mpls2007/cd/MPLS2007Program.htm.

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

http://news.clnz.net/2007/10/19

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

This entry was originally posted in my livejournal