Comments 82
Спасибо.
А зачем v4 маршрут и v6 next-hop?
Первая адекватная статья про SDN на хабре! Не забыт даже тот факт, что концепции разделения control plane и data plane сто лет в обед! Все-таки приятно, когда о таких вещах пишет инженер, а не маркетолог.
А про последний пункт можно поподробнее? Я правильно понимаю, что у вас LSP сигнализируются сразу с хоста? И нечто подобное когда-то давно было модно…
А про последний пункт можно поподробнее? Я правильно понимаю, что у вас LSP сигнализируются сразу с хоста? И нечто подобное когда-то давно было модно…
Метки от хоста. При некоторой ухищренности их можно сделать заранее известными, и тем самым избавиться от сигнализации к хосту.
Вот тут лежит наша с Димой Афанасьевым презентация с одной конференции, где про это есть немного:
Но вообще, это отдельная большая тема, где может быть несколько разных подходов со своими достоинствами и недостатками. Может быть, когда-нибудь потом, если мы соберемся, то расскажем отдельно. Наверное.
Вот тут лежит наша с Димой Афанасьевым презентация с одной конференции, где про это есть немного:
Но вообще, это отдельная большая тема, где может быть несколько разных подходов со своими достоинствами и недостатками. Может быть, когда-нибудь потом, если мы соберемся, то расскажем отдельно. Наверное.
Слайды 1-24 читаются так, как будто Яндекс только открыл для себя MPLS VPN и TE, и очень тащится от этого новомодного функционала :)
Слайду 32 аплодирую. Каждому пункту. Это прелесть, когда архитектура приложений такое позволяет.
Только на слайде 34, кажется, понял, зачем вам MPLS до хостов. Это теория, или это у вас реально работает? Насколько быстра и надежна реакция на падение одного из линков от свитча до хоста (когда надо перевести трафик либо на другой линк этого свитча, либо на другой свитч), и как это реализовано в условиях, когда до доставки до других хостов информации о необходимости перемаршрутизации трафика связь с ними будет лишь односторонней? Или вас совсем не волнует смерть хоста, просто выберется другой хост? Каким механизмом хосты обмениваются подобной информацией между собой — перепиленный BGP или нечто свое? Кто пишет control plane софт для LSR'ов, и как они распределяют между собой свои «хостовые» метки? Label swap на каждом хопе производится на почти-рандомную выданную соседом метку (LDP-way), или на ту же самую (segment routing-way)? Path protection внутри площадки используете?
Вообще, мне кажется, при разработке этой архитектуры кто-то вдохновился segment routing'ом. Чертовски похоже. Разве что в нем первые N меток (N>=2) могли бы определять путь до последнего хопа и его порта (а не просто идентифицировать его), а дальше можно засунуть соответствующую виртуалке метку. При остром желании, следующая — интерфейс виртуалки.
Жду статью «кратко об архитектуре сети Яндекса». В принципе, я уже заинтригован этими слайдами. Гугл и Амазон не раскалываются — может, хоть вы что-нибудь расскажете…
Слайду 32 аплодирую. Каждому пункту. Это прелесть, когда архитектура приложений такое позволяет.
Только на слайде 34, кажется, понял, зачем вам MPLS до хостов. Это теория, или это у вас реально работает? Насколько быстра и надежна реакция на падение одного из линков от свитча до хоста (когда надо перевести трафик либо на другой линк этого свитча, либо на другой свитч), и как это реализовано в условиях, когда до доставки до других хостов информации о необходимости перемаршрутизации трафика связь с ними будет лишь односторонней? Или вас совсем не волнует смерть хоста, просто выберется другой хост? Каким механизмом хосты обмениваются подобной информацией между собой — перепиленный BGP или нечто свое? Кто пишет control plane софт для LSR'ов, и как они распределяют между собой свои «хостовые» метки? Label swap на каждом хопе производится на почти-рандомную выданную соседом метку (LDP-way), или на ту же самую (segment routing-way)? Path protection внутри площадки используете?
Вообще, мне кажется, при разработке этой архитектуры кто-то вдохновился segment routing'ом. Чертовски похоже. Разве что в нем первые N меток (N>=2) могли бы определять путь до последнего хопа и его порта (а не просто идентифицировать его), а дальше можно засунуть соответствующую виртуалке метку. При остром желании, следующая — интерфейс виртуалки.
Может быть, когда-нибудь потом, если мы соберемся, то расскажем отдельно.
Жду статью «кратко об архитектуре сети Яндекса». В принципе, я уже заинтригован этими слайдами. Гугл и Амазон не раскалываются — может, хоть вы что-нибудь расскажете…
Вообще, мне кажется, при разработке этой архитектуры кто-то вдохновился segment routing'ом.
Есть немного. :) И есть далеко идущие планы активно скрещивать нашу конструкцию с SR для решения самых разных задач. И мы плотно работаем с Кларенсом Филсфилсом над этим — вот одно из последнего: tools.ietf.org/html/draft-filsfils-spring-segment-routing-central-epe-00. Будет еще. Stay tuned.
Слайды 1-24 читаются так, как будто Яндекс только открыл для себя MPLS VPN и TE, и очень тащится от этого новомодного функционала
Иногда приходится объяснять очевидные вещи, которые почему-то оказываются очевидными далеко не всем.
Так все-таки, сказанное — теория, или практика на вашей боевой сети?
От чтения RFC (особенно — обзорв ных) меня всегда клонит в сон, так что жду статью с человеческим описанием подхода, в том числе при указанных мной выше сценариях :)
От чтения RFC (особенно — обзорв ных) меня всегда клонит в сон, так что жду статью с человеческим описанием подхода, в том числе при указанных мной выше сценариях :)
Нет, это еще не production, сейчас пока стадия отладки в лаборатории.
Ну тогда не интересно… Слайды написаны так, будто описывают нечто уже работающее. Т.е. сейчас у вас нечто «a bit outdated» в продакшне, а также L2 и прочее?
Нельзя просто так взять и заставить вендоров сделать то, что тебе нужно. Особенно, когда вендор думает, что он знает лучше. Это занимает некоторое время. Но в итоге удается, рано или поздно :)
Гугл сам себе вендор. Не подумываете? Вроде мозги имеются.
Опять же про MPLS. А есть какая-то информация, что вендоры развивают это направление в чипах ориентированных на применение в ДЦ?
Тут как раз кстати строчка из вашей презентации, что мы заложники вендоров. Не получится ли так, что все ваши наработки уйдут коту под хвост только из-за того, что вендор не сделает соответствующую поддержку?
Тут как раз кстати строчка из вашей презентации, что мы заложники вендоров. Не получится ли так, что все ваши наработки уйдут коту под хвост только из-за того, что вендор не сделает соответствующую поддержку?
Есть не просто информация. Есть живые чипы, и есть оборудование, построенное на этих чипах. Например, Trident 2 от Broadcom.
Ну а в качестве оборудования можно привести пример Nexus 9500, который на этом чипсете базируется. Коммутатор как раз ориентрован на DC.
Но, помнится, в N9K Trident соседствует с собственными цискиными ASICами, и на трайденте разве что базовый L3, остальным другие чипы занимаются.
А при чем здесь вообще L3? Не уловил. Самое главное в данном контексте это парсинг пакета, дальше L2/L3 lookup, и то и другое делается на trident. Custom ASIC из того что запомнилось занимается VoQ, буферизацией и общением с фабрикой. L3 лишь малая часть забот trident-2.
У меня отложилось в памяти, что там работой с пакетами с метками там занимается custom asic, как и тем самым QoS, наворотами ACI и так далее. Trident — только L3 форвардинг. Ну видимо был не прав. Сейчас найти подтверждение не удалось.
BRKDCT-3640 там на слайдах много чего перечислено было.
Да, есть, но также важно как оно там сделано. Процитирую Ivan Pepelnjak:
Due to lack of customer requests, MPLS is not the primary focus of merchant silicon vendors. Even though FM 6000 supports MPLS, it needs TCAM to match MPLS labels wasting precious hardware resources – the more MPLS labels a switch supports, the fewer ACL or PBR entries it could have.
Due to lack of customer requests, MPLS is not the primary focus of merchant silicon vendors. Even though FM 6000 supports MPLS, it needs TCAM to match MPLS labels wasting precious hardware resources – the more MPLS labels a switch supports, the fewer ACL or PBR entries it could have.
О да, конечно, важно. И таки сделано оно там далеко не идеально (хотя и достаточно, чтобы быть полезным уже сегодня). Там есть некоторые неприятные подробности, которые на сегодня ограничивают масштабирование, впрочем, эти подробности касаются не только и не столько реализации MPLS — эти же ограничения касаются и обычной IP-fabric. В следующих поколениях бродкомовских чипсетов будет лучше.
Статья хорошая, но побольше бы вашего мнения о SDN, а не только по OpenFlow. И про практический опыт было бы здорово узнать, наверняка Яндекс делает эксперименты.
Помнится мне на YACе выступал кто-то из Cumulus Networks. Пробовали ли вы их продукт? Какое мнение относительно концепции Pluribus Networks?
Если я правильно вас понял, то вы за MPLS везде и всюду, в том числе, ДЦ. Тогда ответьте на простой вопрос — почему никто из больших игроков (FB, Google, Amazon) не использует MPLS в своих ДЦ?
Вообще у меня складывается ощущение, что многие вендоры ориентируются все таких на чистый Ethernet/IP. Плюс всякого рода оверлеи. MPLS в западной блогосфере в темах про SDN не упоминается.
Помнится мне на YACе выступал кто-то из Cumulus Networks. Пробовали ли вы их продукт? Какое мнение относительно концепции Pluribus Networks?
Если я правильно вас понял, то вы за MPLS везде и всюду, в том числе, ДЦ. Тогда ответьте на простой вопрос — почему никто из больших игроков (FB, Google, Amazon) не использует MPLS в своих ДЦ?
Вообще у меня складывается ощущение, что многие вендоры ориентируются все таких на чистый Ethernet/IP. Плюс всякого рода оверлеи. MPLS в западной блогосфере в темах про SDN не упоминается.
MPLS в западной блогосфере в темах про SDN не упоминается
Упоминается приблизительно везде, если автор живет в реальном мире, а не в мире фантазий. В мире фантазий как раз можно разместить один контроллер на сеть и обойтись безмозглыми форвардерами. В реальном мире такое по понятным причинам работать не может.
Все смотрят на гибридные подходы, когда у сетевого оборудования все-таки есть мозги, а механизмы SDN используется скорее для внедрения отдельных правил в FIB по мере надобности.
А у Google как минимум до недавнего времени (скорее всего, сейчас тоже) использовалось нечто свое, но очень смахивающее на MPLS.
Не исключаю, что не попадались на глаза толковые статьи про MPLS. Буду благодарен на ссылочки, особенно интересно было бы почитать, что сейчас вендоры делают по MPLS в разрезе железа.
Я про централизацию в один контроллер ничего и не говорил, но вообще поддерживаю гибридные решения. Идея с один (несколькими) контроллерами меня не воодушевляет особо. В связи с этим про Pluribus и заговорил. Очень понравился их подход. Надеюсь Яндекс пригласит их на YaC в следующем году, или какой-ть другое мероприятие по этому вопросу устроит.
Я про централизацию в один контроллер ничего и не говорил, но вообще поддерживаю гибридные решения. Идея с один (несколькими) контроллерами меня не воодушевляет особо. В связи с этим про Pluribus и заговорил. Очень понравился их подход. Надеюсь Яндекс пригласит их на YaC в следующем году, или какой-ть другое мероприятие по этому вопросу устроит.
интересно было бы почитать, что сейчас вендоры делают по MPLS в разрезе железа.
Например. Еще. Еще. Еще. Еще. Еще. Хотя именно в разрезе железа с MPLS не так много чего происходит, все-таки штука очень простая. Из более-менее важного — научить железку заглянуть сквозь 16 меток на IP заголовок для ECMP :) Хотя всякие GMPLS, MPLS-TP…
Про блогосферу я имел в виду, что обычно рядом с «SDN вон что может» упоминают «вообще-то MPLS мог такое издавна» :)
Спасибо, ознакомлюсь.
Однако на циске мир клином не сошелся.
Согласен, что у MPLS большой потенциал, но почему-то его не раскрыли или раскрыли, но не донесли до масс, или еще что-то. Относительно недавно читал информацию о возможных причинах почему MPLS так и не полетел, если правильно помню, то там говорилось про плохое визабилити работы MPLS сети (могу ошибаться). Не могу сейчас вспомнить источник, чуть позже поищу и отпишусь.
Однако на циске мир клином не сошелся.
Согласен, что у MPLS большой потенциал, но почему-то его не раскрыли или раскрыли, но не донесли до масс, или еще что-то. Относительно недавно читал информацию о возможных причинах почему MPLS так и не полетел, если правильно помню, то там говорилось про плохое визабилити работы MPLS сети (могу ошибаться). Не могу сейчас вспомнить источник, чуть позже поищу и отпишусь.
на циске мир клином не сошелся.
А там много многовендорного. По первой ссылке «The session begins with an overview of the activities in the most relevant IETF working groups». Например, как выше выяснилось, циска совместно с яндексом продвигает segment routing… Еще презенташка про то, над чем думает IETF. На примере циски можно много чего рассматривать, потому что это наиболее открытый вендор.
Относительно недавно читал информацию о возможных причинах почему MPLS так и не полетел
Уже на этой фразе можно назвать ту информацию бредом. MPLS взлетел. Еще как взлетел. Он везде — и у операторов (где его изначально и предполагалось использовать), и в ентерпрайзе. Лично я без него жизни не представляю.
Все-таки не переборщите с блогосферой. Блоги разные бывают. Какие-то (вроде etherealmind) могут вести люди, которые вроде грамотные, но могут зациклиться на чем-то одном как это произошло с Greg Ferro и SDN (он уже выздоровел и не считает это панацеей от всех болезней). Раньше перегибал палку.
там говорилось про плохое визабилити работы MPLS сети
Всё дорабатывается. Со всякими OAM он не отстает от любых конкурентов.
Он везде
Тут каждый смотрит со своей колокольни. Я бы так не сказал. Согласен, что для операторов на транспорте это их все.
Но давайте возьмем, например, домовые сети, их огромное множество, почему же там нет MPLS и даже если есть, то как капля в море?
Потому что домовые сети бывают аж в виде единого L2 на целый район. Там правят L2 технологии, QinQ например. Общая цель — как можно сильнее снизить стоимость оборудования, а L2 свитч априори дешевле умеющего MPLS L3 свитча (или openflow форвардера, раз уж мы говорим от SDN). А еще человеку, который хорошо умеет работать с технологиями на базе MPLS, придется платить больше.
Я как-то помогал в изменении дизайна одной городской сети. Там было L2 кольцо по всему городу. С STP. С дефолтными таймерами. И радиорелейками на паре участков. Этот недо-провайдер был безальтернативным ОПМ для одного важного канала, и меня откровенно бесили пропадания связи на 40-50 секунд несколько раз в день, пока STP пересоберется.
Но то, что такая сеть существует в природе, не значит, что она хоть чем-то (кроме стоимости оборудования) хороша.
Я как-то помогал в изменении дизайна одной городской сети. Там было L2 кольцо по всему городу. С STP. С дефолтными таймерами. И радиорелейками на паре участков. Этот недо-провайдер был безальтернативным ОПМ для одного важного канала, и меня откровенно бесили пропадания связи на 40-50 секунд несколько раз в день, пока STP пересоберется.
Но то, что такая сеть существует в природе, не значит, что она хоть чем-то (кроме стоимости оборудования) хороша.
Так а почему цена на MPLS железо высокая — потому, что массовости нет. L2 мыльницы с кучей функционала стоят копейки исключительно из-за массовости.
Мне вот интересно, почему же MPLS не взял верх над всем этим зоопарком L2 фич, которые используются на доступе? Насколько я понимаю, с MPLS все можно было бы сделать очень элегантно. Мне действительно это интересно. Буду очень благодарен за мысли или теории.
Мне вот интересно, почему же MPLS не взял верх над всем этим зоопарком L2 фич, которые используются на доступе? Насколько я понимаю, с MPLS все можно было бы сделать очень элегантно. Мне действительно это интересно. Буду очень благодарен за мысли или теории.
L2 мыльницы с кучей функционала стоят копейки исключительно из-за массовости.
Неверно. Способные лишь на L2 (вариант — с самым базовым L3 функционалом) чипы устроены намного проще своих полноценных L3шных собратьев. Можно обойтись минимумом дорогущей памяти для форвардеров (CAM на десятки тысяч записей и, возможно, ACL TCAM для продвинутых вариантов).
Посмотрите на схему одного из супов моего любимого свитча. В левой части то, что непосредственно передает пакеты (PFC3). Понятно, что выкидыванием L3 engine и всего связанного с ней можно сильно снизить стоимость? Простой коммутируемый в пределах VLANа транзитный пакет туда все равно не попадет.
Далее — софт под них куда проще писать, так как фич почти нет, это тоже означает удешевление.
Когда говорите «MPLS свитч», всегда подразумевайте «это L3 свитч, но не простой L3 свитч, а еще и умеющий передавать трафик с метками»,
Или вот еще, почему в IX не используют MPLS?
Если в MPLS все давно уже, почему просто не дотянут его до конечного пользователя? Почему вендоры не делают на доступ свитчи с MPLS?
P.S. Еще раз замечу, что ничего лично против MPLS не имею, но считаю, что дальше операторов MPLS полноценно так и не распространился.
Если в MPLS все давно уже, почему просто не дотянут его до конечного пользователя? Почему вендоры не делают на доступ свитчи с MPLS?
P.S. Еще раз замечу, что ничего лично против MPLS не имею, но считаю, что дальше операторов MPLS полноценно так и не распространился.
почему в IX не используют MPLS?
Там, где собственно происходит обмен трафиком? Обычно там ставят большие свитчи, к ним подключаются участники пиринга, через RR или напрямую обмениваются маршрутами. А где именно вы хотите воткнуть там MPLS, если простого L2 достаточно?
почему просто не дотянут его до конечного пользователя?
В каком виде? В виде LDP? BGP? RSVP? До сотен тысяч клиентов? А главное — с какой целью? Source routing как предлагает яндекс в случае гипервизорных свитчей? Но это не нужно конечному пользователю, оператору лучше знать, как пустить трафик клиента.
Помните, что любая технология — это способ решения конкретных задач. MPLS VPN — та самая виртуализация сетей. TE — способ гибкого управления трафиком. Не надо пытаться засовывать технологии туда, где и так проблем нет, ради «чтобы было».
дальше операторов MPLS полноценно так и не распространился.
Я не знаю ни одной относительно крупной компании (не оператора), где хоть на каком-то участке не использовался бы MPLS в виде VPN, вариант — VPLS/EoMPLS, где-то даже TE. С другой стороны, известные мне крупные компании обычно небедные, у них есть и мозги, и весьма дорогие железки.
А главное — с какой целью?
Иметь единый контрол-плейн. Не ради ли этого весь SDN затевается? А то получает тут одно, а тут другое. Вот инженеры знают L2, а вот инженеры MPLS. Упрощение и универсальность — разве не к этому все стремятся?
А где именно вы хотите воткнуть там MPLS, если простого L2
достаточно?
Мммм, тут наверно да, перегнул.
хоть на каком-то участке не использовался бы MPLS
Вот тут опять же, почему только местами? Почему не покрывается MPLSсом большая часть сети?
Получается MPLS так всем хорош, но не везде применяется. Странно как-то.
Иметь единый контрол-плейн.
1) Эта идея воистину ужасна. Вы хотите, чтобы вся инфраструктура зависела от здоровья этого единого контрол-плейна? Ну что же, относительно недавно Cisco анонсировали фексы для cat6500 (Instant Access). Это когда есть центральная VSS пара 6500 (см. «стек»), есть множество фексов (выглядят как свитчи, но это только так кажется, на самом деле это совершенно безмозглые линейные карты, подключаемые оптикой к центральным 6500-м свитчам и управляемые оттуда же как родные порты). Итого: если у вас есть кампус на несколько зданий и тысячи портов по десяткам кроссовых, то вы можете обойтись в прямом смысле одним control plane. Зайдете на management адрес центрального свитча и увидите все до единого порты. Весь трафик даже между соседними портами фекса всегда проходит через центральные свитчи. Итак: при наличии бюджета вы бы стали внедрять такую архитектуру? Лично я — нет. Тогда я бы начал бояться даже дышать в сторону этого дела, не то что трогать его. Малейший чих — и ложится ВСЁ. И я даже вживую видел на одной презентации, как ложилось, да так, что консоль не помогала, надо было по питанию центральные свитчи дернуть.
2) MPLS не обязательно подразумевает централизацию :)
3) Те фичи MPLS, которые можно централизовать… Вы всерьез предлагаете оператору связи в режиме реального времени управлять сетевым стеком пользовательского компьютера?
Почему не покрывается MPLSсом большая часть сети?
В моей сети покрывается (кроме кампусной, где он опять же не нужен). Во многих других тоже. А у кого-то (Амазон например) вообще архитектура приложений такова, что ничего кроме простого L3 транспорта не требуется.
Получается MPLS так всем хорош, но не везде применяется. Странно как-то.
Офигенный аргумент.
Есть некоторая технология, которая прекрасно решает определенный список задач. Есть области, где этих задач не возникает, потому технология там просто не нужна, либо. На основании того, что задача не везде возникает, вы начинаете упрекать решение? Мне это даже как-то нечем крыть.
Ну что же, относительно недавно Cisco анонсировали фексы для cat6500 (Instant Access). Это когда есть центральная VSS пара 6500 (см. «стек»), есть множество фексов (выглядят как свитчи, но это только так кажется, на самом деле это совершенно безмозглые линейные карты, подключаемые оптикой к центральным 6500-м свитчам и управляемые оттуда же как родные порты).
Это имеет смысл при экономии денег. Точнее, такая схема используется операторами сотовой связи вместе с asr 9000. В результате за относительно низкую стоимость можно иметь огромное количество L3 портов на одном ASR.
Я бы понял, если бы фекс стоил как 2960, на базе которого он и сделан. Но он стоит примерно как полноценная линейная карта чуть ли не с DFC. Маркетинг…
Операторы связи, кстати, часто не заботятся о резервировании, полагаясь на то, что огромная железка никогда не умрет, линейная карта на ней никогда не отвалится и т.д. Сколько уже было случаев, когда связь с крупным провайдером пропадает на срок от 5 минут до нескольких часов из-за «сбоя маршрутизатора». Что самое огорчающее — разом на нескольких площадках, так как оказывается, что все каналы собраны на одном узле. Но такой подход имеет смысл — обычно клиент не требует компенсации за сбой, а если в договоре она прописана, то она соответствует доле абонентской платы. Итого: подход «сломается — починим» оказывается выгоднее подхода «зарезервируем, чтобы клиент не заметил поломки».
Операторы связи, кстати, часто не заботятся о резервировании, полагаясь на то, что огромная железка никогда не умрет, линейная карта на ней никогда не отвалится и т.д. Сколько уже было случаев, когда связь с крупным провайдером пропадает на срок от 5 минут до нескольких часов из-за «сбоя маршрутизатора». Что самое огорчающее — разом на нескольких площадках, так как оказывается, что все каналы собраны на одном узле. Но такой подход имеет смысл — обычно клиент не требует компенсации за сбой, а если в договоре она прописана, то она соответствует доле абонентской платы. Итого: подход «сломается — починим» оказывается выгоднее подхода «зарезервируем, чтобы клиент не заметил поломки».
Попробуйте уговорить начальство на то, чтобы раздуть бюджет закупки магистрального оборудования потому что «если ляжет магистральное оборудование, у Вас будут недоступен сегмент до суток.» У меня не получилось, максимум что было — резервный маршутизатор на складе и/или смартнет. А так да, надежность низкая. Честно говоря вот для фексов 6500 я не вижу ниши на рынке. Лучше бы Tactical вернули бы.
Честно говоря вот для фексов 6500 я не вижу ниши на рынке.
Не, на слайдах это выглядит красиво, не поспоришь. Единая точка администрирования, плюс весь функционал cat6500 на любом из портов фексов, хоть даже xconnect пробросить прямо от пользовательского порта. Но зная, как работает VSS (и вообще — любая новая технология у циски), становится страшно.
Так-то да, и еще может быть офигенная плотность портов (в обмен на скорость), плюс возможность поместить фексы по всему кампусу ровным слоем. Еще если не подводит память, для феков пара свичей с парой супов в каждом — рекомендуемая конфигурация, заработает и на одном свиче.
Но честно в боевую схему запихнуть их не рискну, нет уверенности в стабильности джиттера а главное — работе при высокой нагрузке (80% нагрузки — и начинают валиться рандомные интерфейсы и то сами фексы — привет длинку!).
Но честно в боевую схему запихнуть их не рискну, нет уверенности в стабильности джиттера а главное — работе при высокой нагрузке (80% нагрузки — и начинают валиться рандомные интерфейсы и то сами фексы — привет длинку!).
для феков пара свичей с парой супов в каждом — рекомендуемая конфигурация,
Режим VSS обязателен.
Наличие двух шасси категорически рекомендовано, но технически не требуется.
Наличие четырех супов, из которых три — hot standby, ни разу не гарантирует, что весь кластер не встанет колом из-за какого-нибудь глюка.
нет уверенности в стабильности джиттера
А вот за это я бы особо не волновался. Фексам валиться от нагрузки нет причин. Аплинки шеститонника могут быть перегружены, но QoS есть с обеих сторон, ничего особо страшного произойти не должно.
Да и видели ли вы когда-нибудь хотя бы 10% утилизацию 10G аплинка в кампусе? Я — нет, даже если это аплинк свитча с сотнями портов, а не то что маленький фекс или стек из фексов.
Те кто задумывается о покупке фексов 10G обычно не используют.
Режим VSS обязателен.
VSS не обязателен! Но сильно желателен.
Из всей документации и из личного общения с Hodgdon'ом я вынес, что режим VSS обязателен, так как задействуется определенная его программная инфраструктура для добавления фексов (т.е. надо сделать switch convert mode virtual, без этого никуда). Вот наличие двух шасси уже не требуется, но желательно.
Ну я не имел в виду, что вернули старый. Сейчас уже доступна новая модель Tactical на основе SX20.
Это строго говоря не tactical. Cisco свернула эту линейку и я не слышал о ее возобновлении. Avizia tactical — это разработка сторонней фирмы. Но вообще можно уточнить у ystas, он точно располагает всей информацией)
Avizia отпочковалась от Циски год-два назад как раз для продолжения разработки линеек tactical/clinical assistant, и сейчас продвигается в сотрудничестве с Циской. Так что не совсем сторонняя фирма все же.
Во, вспомнил.
Electricity over IP.
Шедевр, как раз на тему «почему бы нам не впихнуть MPLS везде где только можно?». Наглядно показывает, что в принципе KISS есть своя прелесть, и не надо усложнять на ровном месте.
Electricity over IP.
This document is motivated by such work as SONET/SDH over IP/MPLS
Шедевр, как раз на тему «почему бы нам не впихнуть MPLS везде где только можно?». Наглядно показывает, что в принципе KISS есть своя прелесть, и не надо усложнять на ровном месте.
Или вот еще, почему в IX не используют MPLS?
Причина та же самая почему Inter-AS VPN крайне редко бывает Option B/C.
Или вот еще, почему в IX не используют MPLS?
Дейтвительно, ну почему же?
Я просто оставлю это здесь:
ams-ix.net/technical/ams-ix-infrastructure/the-ams-ix-mplsvpls-infrastructure
www.linx.net/publicity/2011releases/pr2011-01.html
Эксперименты Яндекс делает, это верно. Возможно, мы что-нибудь расскажем о них в будущем.
Продукты конкретных вендоров я не очень хочу комментировать по понятным причинам. С Cumulus мы дружим не только на YaC, но вне него. В скором времени с кумулюсовскими людьми мы выкатим пару драфтов в ietf.
Внутреннее устройство и планы других игроков я тоже не могу комментировать. Могу только сказать, что мы с ними на этот счет общались, и некоторые из них заинтересованы в таком подходе, а некоторые — нет. И это нормально — у каждого игрока в этой сфере есть свои уникальные потребности.
А что до упоминаний в блогосфере, то это не самый надежный индикатор — в самом деле, блогосфера переполнена опенфлоем и vxlan'ом, и, если смотреть только на блоги, можно подумать, что ничего другого не только нет, но и быть не может.
Продукты конкретных вендоров я не очень хочу комментировать по понятным причинам. С Cumulus мы дружим не только на YaC, но вне него. В скором времени с кумулюсовскими людьми мы выкатим пару драфтов в ietf.
Внутреннее устройство и планы других игроков я тоже не могу комментировать. Могу только сказать, что мы с ними на этот счет общались, и некоторые из них заинтересованы в таком подходе, а некоторые — нет. И это нормально — у каждого игрока в этой сфере есть свои уникальные потребности.
А что до упоминаний в блогосфере, то это не самый надежный индикатор — в самом деле, блогосфера переполнена опенфлоем и vxlan'ом, и, если смотреть только на блоги, можно подумать, что ничего другого не только нет, но и быть не может.
А как можно будет узнать о выпуске драфтов. Интересно почитать.
Блоосфера может быть и не надежный, но все таки, какой-то показатель. С MPLS мне было бы все таки интересно подетальнее узнать реальные внедрения в сетях уровня ДЦ, а таких материалов не встречал. Да и вы говорите, что пока только в лабе.
Блоосфера может быть и не надежный, но все таки, какой-то показатель. С MPLS мне было бы все таки интересно подетальнее узнать реальные внедрения в сетях уровня ДЦ, а таких материалов не встречал. Да и вы говорите, что пока только в лабе.
Спасибо за пост, очень понравилось!
З.Ы. на моменте когда упомянули NP 4 от EZchip и все засмеялись я почувствовал себя дураком ибо первый раз о нем слышу :)
З.Ы. на моменте когда упомянули NP 4 от EZchip и все засмеялись я почувствовал себя дураком ибо первый раз о нем слышу :)
Интереса ради — не планируете скрещивать OF c netchannel (в имплементации Якобсона)?
Очень хорошее меропритие было, правда больше полугода прошло…
1) Дискуссию не добавите? Да, было несколько неконструктивно, но местами забавно.
2) Тема будет еще публично развиваться?
1) Дискуссию не добавите? Да, было несколько неконструктивно, но местами забавно.
2) Тема будет еще публично развиваться?
Я не думаю, что есть смысл пихать в пост, но вот на всякий случай ссылка на видео: tech.yandex.ru/events/science-seminars/SDN-21nov/talks/1428/
Вообще, планируется. Даже как-то раз уже почти собрались сделать еще один семинар. Но тупо времени не хватило — эту фигню надо еще и допиливать, а не только про нее рассказывать. :) Теперь, может в августе уже (или в сентябре даже), после июльского IETF.
Вообще, планируется. Даже как-то раз уже почти собрались сделать еще один семинар. Но тупо времени не хватило — эту фигню надо еще и допиливать, а не только про нее рассказывать. :) Теперь, может в августе уже (или в сентябре даже), после июльского IETF.
У меня вопрос к Даниилу, но возможно другие хабрапользователи тоже смогут ответить.
Насколько я понял из вашего выступления вы знакомы с тем как SDN реализован в google, они на одной из презентаций www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf страница 8-17 показали что SDN/централизованное управление улучшает востановление сети после сбоя, но это как-то не согласовывается с идеей MPLS FRR где возможность принятия решения локально и есть главным приемуществом в плане скорости.
Прокоментируйте пожалуйста, может я что-то не так понял. Спасибо :)
Насколько я понял из вашего выступления вы знакомы с тем как SDN реализован в google, они на одной из презентаций www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf страница 8-17 показали что SDN/централизованное управление улучшает востановление сети после сбоя, но это как-то не согласовывается с идеей MPLS FRR где возможность принятия решения локально и есть главным приемуществом в плане скорости.
Прокоментируйте пожалуйста, может я что-то не так понял. Спасибо :)
Там идет сравнение с чем-то похожим на TE без FRR. Да и есть у FRR одна нерешаемая проблемка: на период, пока новый LSP не был по-человечески просигнализирован, наверняка будет выбран неоптимальный путь. Гугл хвастался, что утилизация линков у них в среднем 90% — соответственно, если упадет один линк, то будет плохой идеей переводить весь трафик с него на один другой линк, в этом случае плохо станет уже двум линкам…
Конечно же ничто не может побить в скорости переключения на резерв схему, когда резервный путь заранее программируется в FIB роутера перед аварийным линком. Другой вопрос, что гуглу может хватить, скажем, 200-300мс времени восстановления (роутер сообщает контроллеру, тот размышляет над резервным путем, шлет информацию отправителям, кому-то перепосылает, те программируют путь себе) вместо 50мс. Я вот никогда не понимал, зачем стремиться к 50мс.
Конечно же ничто не может побить в скорости переключения на резерв схему, когда резервный путь заранее программируется в FIB роутера перед аварийным линком. Другой вопрос, что гуглу может хватить, скажем, 200-300мс времени восстановления (роутер сообщает контроллеру, тот размышляет над резервным путем, шлет информацию отправителям, кому-то перепосылает, те программируют путь себе) вместо 50мс. Я вот никогда не понимал, зачем стремиться к 50мс.
Я вот никогда не понимал, зачем стремиться к 50мс
Для IPTV? Чтобы картинка не разваливалась слишком.
Ну если у вас линк каждую минуту падает… Иначе, если такое происходит раз в неделю/месяц/год, да и пусть эта картинка развалится в течение нескольких кадров, ничего страшного.
Там, где надо, чтобы ни один пакет мультикастового потока не потерялся, делают live-live. Это когда два одинаковых потока идут разными трассами, оба приходят клиенту, и тот отбрасывает дубль. Если потерялся пакет одного потока — ничего страшного, есть другой.
Там, где надо, чтобы ни один пакет мультикастового потока не потерялся, делают live-live. Это когда два одинаковых потока идут разными трассами, оба приходят клиенту, и тот отбрасывает дубль. Если потерялся пакет одного потока — ничего страшного, есть другой.
Видимо 50мс появились из известных технологий резервирования TDM каналов. Просто старались сделать не хуже.
Само собой. Но с решениями, добивающимися тех 50мс, обычно больше геморроя, чем выгоды (есть даже любители делать TE именно ради этого, и я им сочувствую). Хотя не всегда. Допустим, per-prefix LFA приятен — в теории, у него нет недостатков, задействуется он одной командой и работает самостоятельно. Только вот уж больно он чувствителен к топологии, т.е. недостаток все-таки есть — «не всегда применим».
Мне приходилось TE делать на оборудовании, которое не может заглянуть в IP заголовки внутри EoMPLS, чтобы сделать hash на основе src-dst ip и распределить трафик между равнозначными линками. А раз TE появился, несмотря на то, что был ненужен — с ним появились и прочие его прелести, чтобы зря не пропадал.
Ну так основное назначение TE — source routing с относительно человеческим лицом, это было еще как нужно. Есть, условно, X сетевых потоков с ограничением сверху по пропускной способности. Есть Y (Y<X) каналов связи, расположенных совершенно хаотично и потому без возможности сделать ECMP по ним (по-научному — partial mesh), и неплохо бы равномерно загрузить их трафиком, так как канал — дорогостоящий ресурс, и при этом желательно никого не зажать. TE очень даже прилично решает эту задачу — без централизации control plane, с возможностью централизации management plane, ну и да, с колоссальным management overhead, за что его и не любят. А дальше уже накрутили path protection и прочее.
Тема с SDN похоже больше волнует облачных операторов. В традиционных операторах связи мысль о централизации CP на мой взгляд вызывает «тихий ужас». Чем больше оператор связи, тем сильнее в нем идея — «не складывать все яйца в одну корзину». Если централизованный CP в какой то момент поведет себя неправильно — потеряем всю сеть.
Другое дело централизованная конфигурация услуг, с высоким уровнем абстракции. Это действительно привлекательная идея. Есть и соответствующее ПО для этого, например Tail-F NCS.
Другое дело централизованная конфигурация услуг, с высоким уровнем абстракции. Это действительно привлекательная идея. Есть и соответствующее ПО для этого, например Tail-F NCS.
Даня, большое спасибо за статью!
Обязательно пиши еще, иначе все зарастет этим опенгноем.
Обязательно пиши еще, иначе все зарастет этим опенгноем.
opencontrail.org/opencontrail-architecture-documentation/
Пока самое полное и адекватное (продуманное, аргументированное) описане SDN из тех, что я видел. Конечно, там больше упор на управление виртуальными сетями, но концепции вполне зрелые.
Пока самое полное и адекватное (продуманное, аргументированное) описане SDN из тех, что я видел. Конечно, там больше упор на управление виртуальными сетями, но концепции вполне зрелые.
Статья не особо описывает принцип работы SDN и дает понятие о этой технологии в целом. Ну есть один коммутатор в каком-нибудь Ростелекоме и Транстелекоме у которых сеть на столько большая, что можно сутки заходить на все железки без перерыва.Как тогда планируется таким количеством железа управлять с одного устройства? Небольшая тишина.
Хорошо отделение data и форвардинга, схема нарисованная вами напоминает схему устройства джуниперовских роутеров. У них отделен фовардин от дата плейна хотя иногда дата плейн и учавствует в некоторых важных процессах
Идем дальше упростить lookup, чтобы посмотреть метку и дальше пульнуть у нас есть mpls для этого.Как можно это усовершенствовать? Для свичей и в целом для уровня доступа есть технология q-and-q. Ничего нового я снова не вижу в идеи sdn.только красивое слово sdn и openflow.
Что же такое openflow это софт который можно бесплатно ставить на железки он не предназначен для конкретного вендора, он бесплатный и синтаксис на любом оборудовании одинаков и получается из этого польза сетевику который может не заучивать команды разных вендоров? Возможно будут проще некоторые моменты такие как настройка вланов по протоколу vty, только циска поддерживает, а тут бах и такой протокол поддерживают все свичи в сети. Тогда я разом настроил свои 1 тысячу и один свитч и все радость.
В целом складывается такое ощущение эти слова sdn,openflow используются вендорами для того, чтобы все решили пора менять сеть. У меня все не верно и много миллиардные контракты на покупки нового оборудования.
А простыми сетевиками используются SDN и Openflow как некое а страктное которое должно наконец упростить эту сложную работу сетевым специалистом. Главное, чтобы зарплату сетевика не решили упростить с покупкой нового оборудования для построения сети Sdbn, вроде как sdn должно упростить технологии может и бюджет кампании сэкономит?
Так в целом у вас как у архитектора тяжелая работа. Надо смотреть на существующие технологии через призму которая должна помочь увидеть, чего не хватает и что изменить. Всех благ вам. Если не сложно ответь е на вопросы я правда их пронумеровал ну хотя бы на те которые есть ответы.
P S много сетевиков работает в яндексе и какого вендора у вас используется оборудование?
Хорошо отделение data и форвардинга, схема нарисованная вами напоминает схему устройства джуниперовских роутеров. У них отделен фовардин от дата плейна хотя иногда дата плейн и учавствует в некоторых важных процессах
Идем дальше упростить lookup, чтобы посмотреть метку и дальше пульнуть у нас есть mpls для этого.Как можно это усовершенствовать? Для свичей и в целом для уровня доступа есть технология q-and-q. Ничего нового я снова не вижу в идеи sdn.только красивое слово sdn и openflow.
Что же такое openflow это софт который можно бесплатно ставить на железки он не предназначен для конкретного вендора, он бесплатный и синтаксис на любом оборудовании одинаков и получается из этого польза сетевику который может не заучивать команды разных вендоров? Возможно будут проще некоторые моменты такие как настройка вланов по протоколу vty, только циска поддерживает, а тут бах и такой протокол поддерживают все свичи в сети. Тогда я разом настроил свои 1 тысячу и один свитч и все радость.
В целом складывается такое ощущение эти слова sdn,openflow используются вендорами для того, чтобы все решили пора менять сеть. У меня все не верно и много миллиардные контракты на покупки нового оборудования.
А простыми сетевиками используются SDN и Openflow как некое а страктное которое должно наконец упростить эту сложную работу сетевым специалистом. Главное, чтобы зарплату сетевика не решили упростить с покупкой нового оборудования для построения сети Sdbn, вроде как sdn должно упростить технологии может и бюджет кампании сэкономит?
Так в целом у вас как у архитектора тяжелая работа. Надо смотреть на существующие технологии через призму которая должна помочь увидеть, чего не хватает и что изменить. Всех благ вам. Если не сложно ответь е на вопросы я правда их пронумеровал ну хотя бы на те которые есть ответы.
P S много сетевиков работает в яндексе и какого вендора у вас используется оборудование?
Sign up to leave a comment.
SDN: революция или эволюция? Семинар в Яндексе