Category: общество

Category was added automatically. Read all entries about "общество".

Фрики

Моя драгоценная супруга водит дочку гулять на ближайшую площадку. Ну и, естественно, общается там с родителями других детишек. Как-то приходит домой и рассказывает, что какой-то деятель ее там грузил антипрививочной пропагандой Continue Reading »
May I politely interject here?

(no subject)

Как некоторые знают, у меня в квартире ремонт. Пошел я сегодя пересунуть шкаф с места на место, чтобы рабочие могли обои наклеить. Чтобы не сильно соскучиться, решил включить радио. Бизнес-ФМ успело мне надоесть за сегодня в машине. Это очень неплохое радио, кстати. По-крайней мере я слушаю его без сильного отвращения, если неподолгу и нечасто - новостей и тем на весь эфир у них не хватает, поэтому они повторяются с периодом часа в два. Так вот, включил я Йеху. И попались мне там Бунтман с Гусманом в программе "Кейс". Сначала они обсудили какой-то малоинтересный казус с суррогатным материнством, а потом переключились на кое-что более интересное.

Бунтман представил это дело так. Мол, есть в Америке человек, которого тамошние полицаи посадили на 9 лет за невинную шалость, - он рассылал спам, но спам совершенно некоммерческий, а ему за это "этап на север - срока огромные". И аппеляционный суд приговор подвердил, послав этого невинного человека нахер с его закидонами про свободу слова и неконституционность приговора. "Справедливо ли это, дорогие радиослушатели?" - восклицал Бунтман, - "Ведь свобода слова - величайшая ценность, и превыше всего".

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

Звонили в передачу люди, объясняли, что спаммерство к свободе слова никакого отношения не имеет, что свобода одного кончается там, где начинается свобода другого, что право говорить, не обозначает обязанности других слушать и т.д. Звонили и спаммеры, но чего они там говорили, я не расслышал - шкаф двигал. Ну и время подходит к голосованию слушателей, Бунтман формулирует вопрос. Нет, он не спросил, много 9 лет за рассылку (по его легенде некоммерческую). Нет, он не спросил, нарушили ли конституционные права этого Джейнса. Нет, он спросил: "Что выше: свобода слова или право собственности?"! Вот прямо вот так, вопрос ребром. Дескать, не дали высказаться бедненькому, пожидились на копеечный ресурс, нарушили священное право срать на голову миллионам людей. И все у них на этом эхе так. Каждый раз как пытаюсь слушать, так каждый раз одно расстройство.

Upd: Оказывается, это был Ганапольский, а не Бунтман. В принципе, разницы никакой, я их не сортирую. Но тов. Бунтману приношу свои извинения, если чо.

(no subject)

Иногда я захожу почитать rsdn.ru. Из чистого любопытства. Иногда там кроме "жабобыдлокодерства" обсуждается что-нибудь интересное. Сегодня я натолкнулся на тред про TCP.

Вопрос формулируется так: Программы обмениваются сообщениями через TCP. Сообщения короткие, с десяток байт. Возможно ли такое что на принимающей стороне recv вернёт меньшее количество байт чем размер сообщения?

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

Ничего нового я не расскажу, все это многократно описано.

Казалось бы, все давно усвоили, что TCP - byte stream протокол и полагаться на сохранение границы сообщения нельзя, однако все равно у людей возникает соблазн думать: "ну, мы будем посылать маленькие сообщения, nagle отключим, тогда сообщения будут приходить по одному на TCP сегмент и все будет круто". Так вот - круто не будет.

Во-первых, как обычно, в том треде первым делом перепутали гарантированный IP reassembly buffer размером 576 октетов и minimum IP MTU, который на самом деле составляет 68 октетов (RFC 791). Впрочем, это уже хорошая традиция, путать эти вещи. Соответственно, при использовании PMTUD те самые "маленькие сообщения" могут стать недостаточно маленькими и начать сегментироваться. Но это теоретическая опасность - я не могу припомнить ни одной ситуации, где бы я видел такой MTU вне лаборатории.

Во-вторых, всегда есть возможность, что в сети появится какой-нибудь application level proxy, какой-нибудь socks или что-нибудь из этой оперы, который TCP поток примет, пересоберет как ему понравилось и отправит дальше. Опасность вполне реальная, но оптимистами от сетевого программирования часто игнорируется.

А могут ли возникнуть неприятности в "нормальных условиях"? Т.е. в ситуации с реалистичным MTU, без каких-либо хитрых прокси и т.д. Да, могут. И воспроизвести такую ситуацию достаточно несложно.

Collapse )

Итого, ответ на вопрос Возможно ли такое что на принимающей стороне recv вернёт меньшее количество байт чем размер сообщения? будет "Да, конечно, безусловно, непременно. А кто этого не понимает, будет бит по голове утяжеленным томом Стивенса."

Закон парных случаев

Миф о Всесильном Тоталитарном Режиме, стремящимся удушить все Силы Добра, никак не дает покоя представителям этих самых сил. Не успела отгреметь истерика по поводу "цензуры" в ЖЖ, как тут же выпрыгнули очередные умучанные от гэбни.

Collapse )
networking

Так!

Коллега подогнал драфтик. Не знаю, как я его прощелкал - седьмая версия драфтика все-таки, к тому же выходит в WG, список рассылки я, хоть и по остаточному принципу, но читаю. Оказывается, оно уже выдвигалось на proposed standard в 6-й версии, но решили немного доточить и на днях вышла новая, 7-я версия.

Это очень, очень хороший драфтик. Не то, что мне на самом деле нравится решение, но это шаг в очень правильном направлении. Я давно ждал чего-то на эту тему.

Дело вот в чем. Есть один очень противный сценарий отказа. Редкий, но очень плохой. Бывает так, что роутер попадает в такую позу, что пакетики к нему самому, т.е. к егойному control plane'у, идут, а вот насквозь - фигушки. И лежит такой роутер, как живой, будто и не помирал вовсе, и даже не пахнет от него - все adjacencies на месте, bgp-сессии стоят как почетный караул, но в баскетбол играть пакетики через него не пролезают. Трижды за свою жизнь такое видел и самолично траблшутил. Понятно, что всякими обычными стандартными средствами этот отказ не обнаруживается, а раз не обнаруживается, то и сеть от такого отказа не восстанавливается, пока бедную железяку из этой позы руками насильственно не выведут.

В принципе, есть решение прямое и дубовое - end-to-end monitoring, благо, LSP ping изобрели уже давно. Знай себе фигачь из конца в конец, а ежели фигачить перестало, кричи громким голосом и переходи на запасной путь, например, врубай path protection. Надо побыстрее и с меньшим оверхедом? BFD multihop в помощь. Одна беда - это не масштабируется: N^2 мониторинговых сессий - это очень тяжело, а в большой сети практически невозможно.

Так вот, драфтик, про который я начал рассказывать, обещает нам неземное счастье прямо сейчас. Он вводит довольно остроумную схему самотестирования forwarding plane. Я прямо картику из драфта передеру:
                 +-------+       +-------+       +-------+
                 |     ,-|-------|<DPVRq |       |       |
                 |     `-|-------|-------|-------|->     |
                 |       |       |       |       |       |
                 |       |       |     <-|-------|<DPVRp |
                 +-------+       +-------+       +-------+
                   LSR-U           LSR-T           LSR-D

               DPVRq: MPLS Data Plane Verification Request
               DPVRp: MPLS Data Plane Verification Reply

                    Figure 1: Self Test Message Flow


Сначала роутер посылает request, предназначенный для downstream'ного роутера, но посылает он его вверх, upsteam'ному роутеру. Тот этот request заворачивает, request пролетает через forwarding plane самотестирующегося роутера, долетает до downstream'а, а тот отвечает "так точно, все хорошо". Здорово, правда? Для организации этого фокуса употребляется довольно нехитрая механика, про которую желающие могут прочитать в драфте. Масштабируется это вполне разумно - количество тестов зависит от числа непосредственных соседей, а не от общего числа роутеров в сети.

Если такое самотестирование обламывается несколько раз, роутер может сказать "всем привет" и положить свои adjacencies, чтобы соседи трафик через него не слали. Очень часто тестировать такое не обязательно - отказ действительно редкий. Главное, чтобы сеть могла от такого отказа самостоятельно восстановиться и сделать это за какое-то детерминированное время.

Проблема решена? Нет, к сожалению. Кроме пути mpls2mpls, есть еще ip2mpls и mpls2ip. И их тоже по уму надо бы тестировать, но нынешнее решение этого не позволяет. Но все равно, от того, что этой проблемой, наконец, занялись, мне очень радостно.
networking

Бесчеловечные эксперименты в области стоматологии

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

Итак. Некоторое время назад, я написал сумбурный и путанный пост про защиту мультикаста с помощью MPLS FRR. Это, конечно же, было полное гонево. Там требовалось модифицировать протоколы, изменять алгоритм проверки RPF и т.д. На самом деле, все составные части для того, чтобы сделать защиту мультикаста FRR'ом, уже есть. Во-первых, мультикаст в VPLS, который пропагандирует Алкатель, а во-вторых, routed pseudowires, на которые мое внимание обратил один хороший человек в приватной беседе.

В чем, собственно, идея? Идея очень простая - создать поверх MPLS-сети наложенную топологию из pseudowires, по которой и гонять мультикаст. А эти PW уже можно положить в MPLS TE туннели, которые защитить fast-reroute'ом с соответствующим временем восстановления. FRR будет либо link protection, если PW в точности повторяют физическую топологию, либо node и link protection, если PW лежат не между соседними узлами.

Возникает вопрос, что делать с этими PW дальше, и где будет репликация, и какая. С PW можно делать две вещи. А именно, бриджить между ними и роутить. Соответственно, в первом случае получается VPLS, возможно daisy-chained, во втором - те самые routed pseudowires. А репликация мультикаста, очевидно, будет на стыкующих узлах. В первом случае - L2 репликация со всеми ее приколами: snooping'ом, MVR'ом и прочими прелестями жизни, во-втором случае - L3 multicast routing с PIM'ом.

Чем же я занимался сегодня в лабе. Этим вот и занимался. Наконец, решил попробовать собрать на циске и посмотреть на все это живьем. Одна беда. Для VPLS'а и для routed PW нужны умные карточки в 7600: либо SIP'ы, либо новенькие ES20, а у меня только 6704 и 6748. 6704 - штука, конечно, хорошая, она даже умеет loss of signal миллисекунд за 30 обнаруживать, но для VPLS'а и прочих нужных штук довольно бесполезная. Ну, где наша не пропадала. Как обычно, на помощь пришло оружие пролетариата - hairpin, т.е. проводок, соединяющий два порта одной и той же железки. Берем один порт, вешаем на него xconnect куда надо, а второй, с ним соединенный, либо делаем свитчпортом в каком-то нужном VLAN'е, либо оставляем обычным routed портом и вешаем на него адрес. В первом случае получается бриджинг между PW, если их засунуть в один VLAN, во втором, очевидно роутинг. Благо мультикаста у меня заметно меньше гигабита, то порты на 6748 вполне годятся.

Сыграл я в оба варианта. Оба работают. Рвешь десятигиговый линк - картинка либо вообще не дергается, либо появляется маленький-маленький артефактик, который, если его специально не ждать, то и не заметишь. Еще бы, fast route все-таки.

Какой из вариантов лучше? Оба, на самом деле, плохие. Во-первых, наложенные топологии строить ужасно геморно, просто геморно. Во-вторых, в случае с бриджингом PW надо внимательно следить, чтобы не наделать лупов. Плюс, L2, как обычно, отлаживать тяжело - диагностических средств минимум. В случае с роутингом между PW все тоже весело: надо запускать второй протокол маршрутизации (первый нужен для самого MPLS'а) на наложенной сети, чтобы PIM работал нормально, что тоже не сахар, но зато можно строить произвольную топологию из PW.

У всей этой идеи в обоих ее вариантах есть слабое место - восстановление при гибели узла, который стыкует PW либо с помощью бриджига, либо с помощью роутинга. Что делать?

В случае с бриджингом восстановление от потери узла будет происходить с помощью выбора PIM designated router. Этот процесс можно сделать достаточно быстрым путем выкручивания pim query-interval. Но надо осторожно, слишком сильно выкручивать нельзя. При обрыве линка, когда срабатывает FRR, и трафик идет сильно окольным путем, сообщения PIM'а могут и опоздать. Тогда будет плохо.

В случае с роутингом между PW сходимость будет опираться на сходимость второго IGP. Поскольку второй IGP живет в наложенной сети, то непосредственно увидеть погасшие линки к упавшему узлу он не сможет. Поэтому обнаружение аварии во втором IGP опирается на hello-сообщения. Что не быстро, совсем не быстро. Можно сделать BFD, но опять же надо без фанатизма. Думается, что добиться субсекундной сходимости для гибели узла вполне реально.

Буду ли я делать подобные конструкции в живых сетях? Не знаю. Надо их изучить гораздо внимательней, чем я смог за три часа сегодняшних упражнений. Там есть куча подробностей, которые я даже не упомянул в этом посте. Точно не буду делать с hairpin'ами: криво, ненадежно, непроизводительно - трафик проходит через роутер трижды. С SIP'ами или ES'ками, может быть, но надо много экспериментировать, прежде чем внедрять.
networking

(no subject)

netch показал небезынтересный тред в f.r.u.b. Собственно, обсуждение от конкретной ситуации там быстро перешло к фрагментации и PMTUD вообще. Это далеко не единственное обсуждение PMTUD, благо проблема реальная, вредная и до сих пор без удовлетворительного решения. Пожалуй, попробую изложить, что я по этому поводу думаю.

Итак, у нас есть пакетная сеть, как обычно, состоящая из узлов и линков между ними. Разные линки могут поддерживать разный максимальный размер пакета, который можно по этому линку передать. Это называется Hop MTU, или просто MTU. Часто MTU имеет некоторый гарантированное минимальное значение, например для IPv4 сетей - это 68 байт (распространенное заблуждение: 576 байт, но это неправильно. 576 байт - это минимальный reassembly buffer, т.е. это гарантии для end host'а, а не для сети), для IPv6 - 1280 байт. Минимальное значение Hop MTU на пути от узла A к узлу B называется Path MTU.

Если мы хотим, чтобы узлы A и B могли говорить друг с другом у нас есть следующие варианты:
1) посылать только пакеты не более чем минимального гарантированного размера
2) посылать пакеты побольше и позволить сети их фрагментировать, если потребуется
3) каким-то образом понять, каков Path MTU между общающимися узлами и использовать пакеты не более такого размера

Понятно, что вариант 1 - это ну очень неэффективно. В IPv6 с этим чуть полегче, но все равно недостаточно хорошо.

Вариант 2 тоже не очень хорош по нескольким причинам.

Во-первых, фрагментация в IPv4 сломана. По этому поводу есть "IPv4 Reassembly Errors at High Data Rates" (в предыдущих редакциях этот драфт назывался "Fragmentation Considered Very Harmful"). Очень советую прочитать.

Во-вторых, фрагментация неэффективна. Неэффективное использование полосы и увеличение packet rate, проблемы при потере фрагмента, трудности обратной сборки - это все описано в классической статье Kent & Mogul.

В упомянутой дискусси netch заметил: На самом деле здесь самая тяжёлая диверсия - то, что needfrag является ICMP.:(( Даже если ICMP не режется, часто ставится предельная субполоса на него (например до 5% канала). Если кто-то один вдруг начинает гнать мусор типа ping flood, страдают все.

Это верно, но не до конца. Проблема не столько в том, что это ICMP, а сколько в том, что обработка пакетов, непролезающих в следующий линк - дорогое удовольстивие, что с фрагментацией, что с генерацией "fragmentation needed and DF set", и эта операция реализуется в slow path. Поэтому, нередко ставятся rate limits на эту операцию. Соотвественно, можно как самому налететь на такой rate limit и получить существенную потерю пакетов, так и нарваться на намеренное и злоумышленное исчерпание этого лимита.

И, наконец, вариант 3. Всем бы он был хорош, если б работал. Проблемы классического PMTUD многократно перетерты и подробно расписывать их я не стану: обезьяна с гранатойМСЭ, сбрасывающие все ICMP без разбору, упомянутые выше rate limits на генерацию ICMP, органичения по полосе на ICMP - это все широко известно.

Попробуем порассуждать, как вообще можно было бы подойти к проблеме фрагментации и Path MTU.

Можно было бы заставить протокол маршрутизации распространять информацию о Path MTU к разным сетям. Такое уже делалось. Например IGRP и EIGRP в составе метрики приносят значение Path MTU к той или иной сети (правда, это никогда и никак не использовалось, насколько я помню). В принципе, ничто не мешало сделать такое и в BGP, и других IGP (одним только BGP обойтись нельзя из-за того, что iBGP соседи могут не быть соединены напрямую). Никакой особой хитрости тут нету. Добавляем атрибут MTU, при первичной генерации BGP-маршрута берем либо статически сконфигурированное значение, либо, если у нас редистрибуция, то берем значение оттуда, откуда редистрибутим. При дальнейшем анонсировании выбираем min(route MTU, MTU to next-hop). У агрегированного маршрута - min(MTU всех агрегируемых маршрутов).

Как это можно было бы использовать? Можно было бы заставить first hop router либо фрагментировать пакеты, либо отбиваться needfrag'ом. Как было б хорошо: first hop router разобрался с фрагментацией и понеслись пакеты по привольному интернету быстренько и гладенько. И ничего страшного, если FHR напряжется - это все-таки network edge, там положено напрягаться.

Сработало бы такое? Нет.

First hop router в подавляющем большинстве случаев сидит с одним единственным маршрутом, касающимся интернета, - с default route. А это значит, что с этим default route ассоциирован либо минимальный из всех MTU во всем интернете, если этот default - BGP-derived (поскольку порождение дефолта - это по сути дела экстремальная агрегация), либо MTU, взятый с потолка, если маршрут сконфигурен статически. Соответственно, либо совершенно ненужное понижение MTU для для всех пакетов, идущих через этот FHR, либо разборки с фрагментацией сдвинуты на первый в пути роутер с полной таблицей. Первое плохо - это не только неэффективно, но и просто опасно: кто-нибудь очень умный санонсировал маршрут с атрибутом MTU=100 и привет, 90% пакетов в интернете стали не длиннее сотни байт и интернет кончился. Второе тоже плохо: DFZ-роутеров не так уж много, получают они высокоскоростной агрегированный трафик, поэтому концентрировать еа них нагрузку по разборкам с фрагментацией - совершенно неправильно.

Т.е. идея это гиблая.

Значит, нам ничего не остается, кроме как заставить хосты заниматься "разведкой" Path MTU. Как это можно организовать?

Во-первых, классический PMTUD, основанный на ICMP needfrag. Во-вторых, PMTUD, основанный на потерях больших пакетов.

С первым мы уже разобрались, почему он работает через раз.

Второй действует довольно просто, я процитирую: "The proposed new method does not rely on ICMP or other messages from the network. It finds the proper MTU by starting a connection using relatively small packets (e.g. TCP segments) and searching upwards by probing with progressively larger test packets (containing application data). If a probe packet is successfully delivered, then the path MTU is raised. The isolated loss of a probe packet (with or without an ICMP can't fragment message) is treated as an indication of a MTU limit, and not a сongestion indicator."

Что можно сказать про второй метод, чем он хорош, и чем он нехорош? Хорош он, очевидно, тем, что от сети не надо никакого интеллекта, кроме умения сбрасывать пакеты, которые не лезут в следующий линк. Чем нехорош? Специфицирован он только для TCP и SCTP, но ничто не мешает поступить похожим образом для любого протокола с двунаправленным потоком между общающимися хостами. Однако, если поток однонаправленный, т.е. никаких подтверждений с той стороны не предусмотренно, то такой метод работать не будет. А вот классический PMTUD мог бы с такой ситуацией справиться.

Можно нафантазировать еще один метод. Метод Кровавого Обрезания. Пусть есть пакет, который не лезет в следующий линк. Вместо того чтобы его фрагментировать, берем и отрезаем ему половину жопы передаем от этого пакета сколько пролезает и устанавливаем ему в заголовке соотвественный битик. Получатель видит обрезанный пакет и сигнализирует передатчику "давай-ка помельче пакетики". Как сигнализирует? Лучше всего piggyback на протоколе повыше уровнем в рамках того же соединения - заведомо не дропнут файрволом, не зажмут полосу и т.п. Недостаток у этого метода тот же - работает только для двунаправленных протоколов. Достоинства: 1) Кровавое Обрезание легко реализуется в ASIC'е 2) нет нужды строить предположения из-за чего потерялся пакет: из-за MTU, из-за congestion, или из-за банальной битовой ошибки в канале. Но такой метод требует поддержки на всех хостах, так что вряд ли мы увидим его в реальной жизни.

Итого. Все плохо. По крайней мере сейчас. Завтра появятся реализации draft-ietf-pmtud-method и какую-то часть проблем это решит. Что же делать сегодня? Неформально стандартизоваться на гарантированном MTU 1500. В принципе, оно так и есть сейчас. А тех операторов сетей, которые не понимают, что это established industry practice и умудряются поломать MTU на транзите, надо расстреливатьучить.
networking

Китайская грамота

Утомил, небось, прогонами-то?

Несколько дней назад в cisco-nsp проскочило письмо на тему [c-nsp] Backup methods in MPLS networks.

В этом письме автор спрашивал: "How about LDP FRR, IP FRR, VPN FRR?". Многие удивились: "Какие, нафиг, LDP FRR и VPN FRR? MPLS TE FRR знаем и умеем. IP FRR знаем, но пока не умеем. А эти два кто такие?". На это автор оригинального вопроса сказал, что есть замечательный вендор Хуавей, и у него есть то, чего нет ни у кого, и дал ссылок на хуавейные white papers.

Я заинтересовался и пошел читать. Пока я прочитал и успел обдумать только LDP FRR. Про него и напишу. Про VPN FRR я пока не прочел. Когда прочитаю и если найду, что это интересная тема для обсуждения, то напишу и про него тоже. Но потом.

Collapse )