Category: it

Category was added automatically. Read all entries about "it".

(no subject)

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

Оставляйте, пожалуйста, телефоны в комментах (скринятся). Очень прошу. Мне ваши контакты были очень ценны. Спасибо и извините за предоставленные неудобства.

Erlang shell

Меня чертовки раздражает CLI, в котором не работают ^U и ^W. Просто выводит из себя. Я долго мирился с этим безобразием в erlang shell, но наконец не вытерел. Continue Reading »
networking

(no subject)

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

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

Некоторое время назад я писал про draft-ietf-mpls-ldp-interarea. С тех пор в этой области был некоторый прогресс. Циска выступила с контр-драфтом. Идея там очень простая: агрегирующий ABR посылает только одну метку на агрегированный префикс, но при этом не использует PHP, а деагрегирующие метки, необходимые для построения непрерывных LSP, вычисляются некоторым общим для ABR и ingress PE алгоритмом, при этом метка агрегированного префикса и деагрегирующая метка стекируются на пути от ingress PE до агрегирующего ABR и, соотвественно, никому по пути от ingress PE до агрегирующего ABR деагрегирующая метка неизвестна. Симпатично. Проблема решена?

Презентация George Swallow (автора draft-swallow-mpls-aggregated-fec) как раз посвящена проблемам, возникающим при таком подходе, и развитию его идеи с тем чтобы избежать этих проблем.

В чем засада при чистом draft-swallow-mpls-aggregated-fec? В BGP next hop tracking. Если мы все сагрегируем: и next-hop адреса, и метки, соотвествующие этим адресам, то единственным способом определить падение дальнего PE будет BGP hold timer - а это очень и очень небыстро.

Как объехать? Swallow предлагает подход "Summarized route, detailed reachability" (SRDR). Т.е. IGP у нас будет агрегировать маршрут, но при этом сообщать достижимость отдельных адресов внутри агрегированного префикса, анонсируя битовый вектор размером 2^(32 - длина агрегированного префикса). Поскольку драфта по SRDR еще нет (по крайней мере я не нашел), можно только предполагать, как именно это будет реализованно. Логично предположить, что для OSPF это будет LSA type 11 (inter-area opaque), а для IS-IS - просто отдельный TLV.

Джунипер тоже не стоял на месте, и Kireeti Kompella в своей презентации рассказал про развитие draft-ietf-mpls-ldp-interarea. У draft-ietf-mpls-ldp-interarea нет проблемы с NHT, как у draft-swallow-mpls-aggregated-fec - в случае draft-ietf-mpls-ldp-interarea падение egress PE можно определить по пропаданию его LDP метки, но есть другая проблема - там уменьшается объем IGP, но объем LDP-сигнализации и объем LIB/LFIB остается тем же.

Что предлагается? Hierarchical LDP. В Label Mapping Message добавить TLV того же самого формата, что и сам Label Mapping Message. Внешний label mapping соотвествует агрегированному префиксу, а метки во вложенных деагрегированным. Метки во внешнем Label Mapping Message и внутреннем стекируются. Соотвественно, этот внутренний label mapping нужен только ingress PE и, естественно, самому ABR. Тоже красиво. На это опять таки нет драфта, поэтому о некоторых деталях нужно догадываться.

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

Не претендуя на полноту, попробую сравнить.

1) Interop с существующим положением вещей.
Цискина схема:
Потребуется включение opaque LSA в сетях с OSPF. Поскольку речь о LDP сетях, то это новая фича - такие сети раньше не зависили от opaque LSA. А поскольку речь идет об inter-area opaque, то обязательно найдется какой-нибудь говновендор, у которого это сломано - в нынешних сетях inter-area opaque нет, соотвественно, кое-кто мог и забить. В случае IS-IS надо организовывать leaking SRDR TLVs в level-1 области. Тут больших засад не предвидится, L1/L2 роутеры все равно будут обязаны поддерживать SRDR, а остальные уже давно научились правильно обходиться с unknown TLV в IS-IS'ных LSP.
Джуниперская схема:
LDP предусматривает расширяемость и транспорт ранее неизвестных TLV с помощью механизма U- и F-битов. Конечно, всегда может найтись дятел, который сломает и это, но вероятность мала, ибо это U- и F-биты - интегральная часть спецификации LDP.

2) Потенциальные проблемы с размерами протокольных сообщений.
Цискина схема:
Максимальный размер OSPF LSA - 64K. Для достаточно длинных агрегированных префиксов SRDR бит-вектора будут не очень длинными, все может и поместиться. А если мы таки доживем до IPv6? Бит-вектор длиной 2^64 бит, например, - это слишком. Можно избежать этих проблем аккуратным назначением адресов лупбекам роутеров и выключением SRDR для агрегированных префиксов, соотвествующим адресам линков. Для IS-IS почти все то же самое, но там есть механизмы борьбы с очень длинными LSP.
Джуниперская схема:
Максимальная длина LDP Label Mapping Message - тоже 64K, но здесь не надо перечислять все адреса в агрегируемом диапазоне даже в виде битового вектора. Пусть средняя длина обычного Label Mapping Message - байтов 40. Это с запасом: 8 байт на заголовок, 16 (или 12? не помню) - на FEC, 8 на метку. Ну, с IPv6 длина FEC TLV будет побольше. Т.е. даже если в области 1000 роутеров, все поместится.

3) Общая "правильность".
Цискина схема:
Мысль о том, что routing и reachability - разные вещи, очень правильная. И, в принципе, SRDR механизм может найти и другие применения. Самое простое - обычный IP-роутинг без какого-либо MPLS с агрегацией на границах областей и BGP next-hop tracking. Если подумать, можно придумать еще. Т.е. полезность этой схемы не исчерпывается решением проблемы масштабирования LDP.
Джуниперская схема:
Здесь хорошо то, что вся информация в одном месте - в LDP. Нет сценариев, когда LDP говорит одно, а SRDR механизм говорит другое. Плюс LSA/LSP фладятся периодически, а LDP сообщения ходят по TCP и при liberal retention живут, пока живет adjacency. Цискина схема выглядит несколько более хрупкой.

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

Немного в сторону. Несколько слов в презентации Luca Martini пересекаются с этой темой, хотя презентация совсем о другом. "Keep the MPLS implementation simple, PW is the access, L3VPN in the edge/core for services." В этом есть резон не только с точки зрения сложности сети, о чем сама презентация, но и с точки зрения масштабируемости IGP и LDP. Если выделить домены, из которых выносить трафик псевдопроводами до узлов, на которых живут реальные сервисы, но эти домены вполне могут иметь совершенно отдельные IGP и LDP.

А сама по себе презентация Martini тоже интересная. Имеет прямое отношение к хайпу о PBT. Советую прочитать.

Все на сегодня. Выговорился. Пойду пивка приму.
networking

(no subject)

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" умер и можно переключаться на защитный, то было бы совсем хорошо.
networking

(no subject)

Что-то давненько я не блогал длинной и скучной нудятины про сети. Видимо, работа удовлетворяет потребности в писательстве ;)

Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался draft-decraene-mpls-ldp-interarea, а теперь его приняли как workgroup документ в MPLS WG и теперь он называется draft-ietf-mpls-ldp-interarea.

Collapse )
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 )
networking

Мутант-переросток, часть V

Начало здесь, здесь, здесь и здесь.

Кратенько про сервисы.

1) L2 VPN точка-точка

Тут все понятно.

2) L2 VPN многоточка, он же VPLS

Тут в принципе тоже все ясно. Те же туннели между PE свитчами, что в обычном VPLS, тот же лернинг на границе, тот же split horizon forwarding. Все то же самое. То же самое и в части мультикаста. А именно чудовищно неэффективная репликация на ingress node. Когда бродкастного/мультикастного трафика мало, то и фиг с ним. А от видео эта конструкция двинет кони.

Есть, конечно, выход. PBT может жить бок о бок с обычным *STP - некоторые VID используются для установки PBT-путей, а некоторые живут, как жили раньше, т.е. с STP. Можно взять один vlan, запустить в нем мультикаст, который будет фладиться человеческим образом, а на PE-свитче MVR'ом реплицировать его клиентам. Можно. Но это шаг назад. У нас опять возникает ненавистное дерево. Ясно, что это решение никак не тянет на Provider Backbone Transport.

Другого способа побороть проблему мультикаста в этой среде я не вижу. Фокус а-ля аткателевкий daisy chained VPLS здесь не пройдет. Никакого multipoint LSP, как в MPLS мире, здесь не предвидится. В общем, грустно.

3) L3 VPN

Вендоры, которые не умеют ничего умнее ethernet'а очень любят глубокомысленно говорить: "Over 95 percent of all data traffic originates and terminates on Ethernet ports." Они скромно молчат о том, что 99.99% of all data traffic travels the networks in IP packets. ;)

L3 VPN масштабируются существенно лучше, чем всяческий VPLS. Причем масштабируются лучше не только со стороны оператора, а, что более важно, со стороны клиента. Подход, основанный на сборе всех подряд в один широковещательный домен имеет очевидные ограничения. Поэтому, как ни крути, а продавать L3 VPN надо.

Что здесь предлагает PBT? А ничего.

Хочешь, бери обставляй свой PBT'шный "backbone" роутерами по кругу и запускай на них MPLS/BGP VPN. Хорошо? Абсолютно ничего хорошего.

Хочешь, стягивай клиентов L2 point-to-point туннелями к паре роутеров, которые и исполняют L3 VPN. Хорошо? Да тоже ничего приятного.

Хочешь, выстраивай полноценный MPLS домен, а PBT используй для агрегации. Уже теплее. Только это уже не backbone transport, а совсем даже aggregation. Если б оно еще управлялось по человечески - сигнализацией. ;)

4) Трипельплей и прочий новомодный IPTV

См. пункт 2 про мультикаст.

Все. Хватит. Надо закруглять.

Итак. Что такое этот PBT? По своей сути, это такой недо-MPLS. С неясным позиционированием, с недостатками в области масштабирования, в области восстановления, в области сервисов.

Единственный плюс этого PBT - это более низкая стоимость компонентов forwarding plane. Однако, если довести функциональность PBT'шного forwarding plane до той степени, что он сможет избавиться от своих недостатков, этот forwarding plane станет стоить ничуть не дешевле MPLS'ного, а думается, что и дороже.

Может быть, PBT найдет свое место в сети агрегации, подтягивая клиентов к сети. Однако, непонятно, что делать с мультикастом - уж больно не хочется назад к *STP. Однако IEEE с некоторых пор разрабатывает 802.1aq - shortest path bridging как замену *STP в ethernet сетях. Это, на мой взгляд, выглядит привлекательней для сети агрегации, чем PBT.

(no subject)

Маски шоу в Ланите и в IBM:
http://lenta.ru/news/2006/12/06/lanit/
http://abbra.livejournal.com/65328.html

Совершенно очевидно, что это связано со вчерашним постом _adept_: http://users.livejournal.com/_adept_/48362.html. Никаких других объяснений быть не может - таких совпадений просто не бывает. Ищут якобы утерянную документацию на описанный бэкдор.
networking

mcast

"When you see a bunch of engineers standing around congratulating themselves for solving some particularly ugly problem in networking, go up to them, whisper "multicast", jump back, and watch the fun begin..."
-- draft-irtf-routing-reqs-groupa

В принципе, мультикаст у нас как бы есть. Но предела совершенству не существует, и попытки улучшить жизнь не прекращаются, благо есть куда. В частности, многие хотят скрестить мультикаст с MPLS. Собственно, от такого сожительства хочется получить три вещи:

1) Изоляция. L3 VPN, но с мультикастом.
2) Защита. Не в смысле security, а в смысле protection. Т.е. чтобы, ежели что поломается в сети, у нас все быстренько восстановилось.
3) Масштабируемость. Нынешний подход к мультикасту (с PIM в разных вариантах и позах), он создает в ядре сети состояния, которые в принципе могут довольно часто меняться. А у core router'ов control plane не резиновый: они умеют кидать трафик быстро и далеко, а вот задрачивать их всякой сигнализацией - этого надо избегать, ну, или хотя бы стараться.

Подходов тут масса, драфтов понаписана туева хуча. Я, признаться, прочел далеко не все - уж слишком их много. Есть draft-rosen-vpn-mcast, который решает только проблему 1. Есть набор драфтов про multipoint LSP, которые должны вылечить все и всех (судя по всему, это и есть наше светлое, но отдаленное будущее). Есть попытки мультикастить через VPLS, для чего этот бедный VPLS обставляется неприличным количеством костылей и подпорок, с драфтом на каждую из них, разумеется. Ну и куча гибридных вариантов, которые я не могу даже перечислить, не говоря уж о том, чтобы изложить идеи.

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

Сейчас сходимость мультикаста напрямую зависит от сходимости IGP. Собственно, для того, чтобы приблизить сходимость мультикаста к сходимости IGP сделаны две вещи: 1) пересчитывать RPF [почти] сразу, как сойдется IGP; 2) дать рукоятку для выкручивания query interval, чтоб designated router переизбрался побыстрее. "Почти" - это потому что по есть такой таймерок (по крайней мере есть у циски), называется rpf backoff, нужен он "чтобы два раза не бегать", действует он так: произошли изменения в IGP, запускаем таймер, и если все тихо, пересчитываем RPF, если опять какая-то фигня, то запускаем удвоенный и так до некоторого верхнего предела. Равен этот таймер 500мсек по умолчанию, рукоятка для его выкручивания есть. Если учесть, что на сегодняшний день OSPF или IS-IS реально затюнить до сходимости в ~300мсек, то получить сходимость мультикаста в пределах секунды тоже можно. В принципе, это уже неплохо, но хочется лучше. Скажем, в IPTV картинка от этого сильно портится.

Что можно было бы сделать?

Есть такой подход к развертыванию MPLS TE FRR. Называется он one-hop. Применяют его в тех случаях, когда нужен только link protection, а node protection - нет. Между соседними роутерами строится TE тоннель по unconstrained path, который, естественно, лежит через линк их соединяющий. Также строятся nhop bypass'ы, которые защищают эти линки. При этом, благодаря penultimate hop popping, пакеты в штатной ситуации идут без лишних меток. Деплоится это легко, число тоннелей не велико - по два на каждый линк. А выгода получается довольно существенная.

Примерно то же самое можно было бы вытворить и с мультикастом. Оставляем всякую PIM-сигнализацию как есть: все эти RP, все эти (*, G) и (S, G), и всю прочую ботву. В штатной ситуации, когда защита не активна, форвардинг тоже остается без изменений. А когда произошло страшное, берем пакет, вешаем на него юникастную метку нашего bypass'а и отправляем по запасному пути. Вот тут возникает засада. Поскольку пакет приехал по обходному пути, у нас обломается RPF check. Что делать? Надо как-то понимать, что пакет свалился по обходному пути не просто так, а посредством bypass'а. Для этого достаточно, чтобы он приходил с меткой, т.е. надо 1) чтобы в нашем bypass'е не работал PHP; 2) чтобы по этой метке можно было понять, с какого интерфейса пакет должен был бы придти при неактивной защите, для этого надо эту метку аллоцировать не из platform label space, а из interface label space. После того, как пакет с меткой пришел к на nhop router и прошел RPF check, меточку снимаем и делаем L3 forwarding как обычно. В принципе, на платформах типа 7600 это означает рециркуляцию, ну да и фиг с ней. Думается, что добавить в RSVP опцию, которая попросила бы у tail end'а описанное назначение меток, не сложно, благо RSVP протокол хорошо расширяемый.

Разумеется, это все касается только link protection. При падении узлов сходимость будет IGP'шная.

Есть вариант как сделать похожую вещь прямо сейчас без изменений софта и протоколов, но он мне не нравится. Можно сделать one hop GRE тоннели и запустить PIM в них, а сами эти GRE тоннели защитить обычным FRR. Не нравится мне тут много чего: оверхед, необходимость бороться с RPF в этих тоннелях (если мы хотим, чтобы юникаст у нас шел как обычно, а мультикаст через GRE, то тут будут проблемы). В общем, это будет жуткий гемор как в развертывании, так и в эксплуатации. Зато защита. Пожалуй, на неделе я это отыграю в лабе, но думаю, что после отыгрывания вариант с GRE мне понравится еще меньше, чем сейчас.