О ненужности Spanning Tree



    Сразу оговоримся, не стоит воспринимать заголовок слишком буквально. Если звезды зажигают… и так далее.

    Тем не менее, семейство протоколов Spannning Tree, если не отживает свой век в качестве основного инструмента резервирования в ethernet-сетях, то как минимум плавно перетекает в узкие и специфические ниши (само собой, их обсуждение выходит за всякие рамки этой статьи, но в приветствуется в комментариях).

    И да, конечно, никто не отменял Spanning Tree как технологию защиты от человеческой ошибки.

    Зачем оно нужно


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

    Поскольку модель ВОС (она же ISO/OSI, если вам так больше нравится) забыла наделить канальный уровень функциями выбора оптимального пути передачи и исключения закольцовок, возложив оные на сетевой уровень, технология Ethernet таковыми функциями и не обладает. Вместо мороки с предварительным вычислением пути к адресу назначения ethernet-коммутатор, если не знает, куда посылать кадр — посылает его во все порты, кроме порта, через который передаваемый кадр был получен. А там, глядишь, найдется адресат, способный по содержимому сообразить, что это кадр для него. (Когда мы говорим о флудинге во все порты, за исключением совсем специальных случаев речь идет только о портах одного VLAN'а.)



    Коммутатор не был бы коммутатором, если б этим и ограничился. Все-таки он не настолько глуп, и чтобы не рассылать всем всё всегда, подглядывает в адреса источников и записывает их себе в табличку: MAC-адрес такой-то находится за таким-то портом. Процесс называется изучением MAC-адресов («мак-лернинг»). Сформировав такую таблицу (таблицу коммутации), коммутатор посылает кадры только в нужные порты.

    Если же поверх Ethernet’а передается IP-трафик, а чаще всего так и есть, то кадров с неизвестными MAC-адресами назначения при хорошем раскладе (и прямых руках) возникать не должно, однако же тут никак нельзя обойтись без специальных кадров c адресом назначения «слать всем», передача которых сводится к тому же самому.

    Итого, в ethernet-сетях флудинг, то есть копирование кадра во все возможные выходные порты является неотъемлемой частью процесса коммутации.

    Теперь представьте, что случится, если в топологии сети обнаружится закольцовка. Одна из копий кадра вернется на расфлудивший его коммутатор, который снова его расфлудит, и так до тех пор, покуда у всех устройств в сети загрузка процессоров не достигнет ста процентов. Описываемая ситуация называется бродкастовым штормом. Кому доводилось наблюдать — не даст соврать, зрелище не для слабонервных.



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

    С одной стороны — чего легче? — не втыкай лишних проводов, да и все. Но не так-то это просто. Ведь хочется, чтоб сеть была отказоустойчивой, с избыточными связями, резервируемыми узлами и автоматическим переключением при отказах. Иными словами, чтоб L2-сеть была как L3. Для достижения желаемого и, вместе с тем, чтоб уберечься от ужаса бродкастовых штормов, люди придумали специальные технологии для поиска циклов в топологии и принудительного их разрыва путем блокирования отдельных линков. Технологии эти и называются словом Spanning Tree.



    Именно технологии, во множественном числе. Ведь мало сказать «блокируют», важно еще понять, какой именно линк блокировать, через какой промежуток времени проверять, не пора ли разблокировать, как именно это делать, какие порты можно не проверять на наличие закольцовки, какие VLAN’ы по каким линкам передавать, как быстро все это происходит и т. д. Разные взгляды на эти и множество других вопросов породили целый ворох протоколов с общим названием Spanning Tree: STP, RSTP, PVST, PVST+, PVRST, MSTP, VSTP, наверняка есть и еще.

    Читатели, всерьез изучавшие что-нибудь из вышеперечисленного, наверняка знакомы с ощущением, схожим на комбинацию сонливости и зубной боли, которое возникает в процессе изучения всех этих бесконечных состояний портов, механизмов формирования весов, алгоритмов выбора корневых коммутаторов, и прочей скукотени, уступающей в занудстве разве что учебнику анатомии. Те же, кто успешно справился с внедрением, эксплуатацией, траблшутингом и развитием сети хотя бы из полутора десятков коммутаторов, построенной на базе spanning tree, смело могут подавать в спортлото IEEE прошение о представлении себе к награде. Им дальше читать не нужно.

    Spanning Tree в переводе с английского означает «ветвящееся дерево». А дерево — это, в свою очередь, «связный ациклический граф», то есть граф без циклов (закольцовок), между двумя вершинами которого существует хотя бы один путь.

    Почему оно не нужно


    Теперь, наконец, о том, почему Spanning Tree стремительно теряет свою актуальность.

    Вы, конечно, уже слышали, что в светлом будущем все будет во-первых общим, во-вторых виртуальным, в-третьих бесплатным. Так вот, в некотором роде, светлое будущее уже наступило.

    Технология объединения линков в агрегированные группы LAG aka EtherChannel появилась не вчера.

    Кстати, не нужно путать само по себе объединение линков в LAG и протокол LACP, который помогает сделать это объединение (полу)автоматически, но из-за неумелого обращения в жизни от него больше проблем, чем пользы.

    Идея проста. Два коммутатора — впрочем, не обязательно коммутатора, любых устройства, работающих на втором и более высоких уровнях — соединяются для надежности двумя проводами, а не одним. При этом коммутаторы настроены (вручную или посредством LACP) таким образом, что для них эти два провода являются одним линком. Слишком углубляться в детали не будем, об этом полно статей на любой вкус, лишь скажем, что агрегация может быть по одной из двух схем: «активный–активный» (наиболее популярная): трафик передается сразу по двум проводам с балансировкой нагрузки; и «активный–пассивный»: пока один линк в «апе», второй в «дауне», при падении основного происходит переключение на резервный.

    В сущности, описанное выше — это простейший способ избавления от Spanning Tree на «одноколенном» уровне. Однако данный способ в общем случае требует, чтобы оба линка с каждой из сторон были подключены к одному коммутатору. Иначе возможны все те же закольцовки или осложнения, связанные с постоянным обновлением таблицы MAC-адресов.

    Но тут на помощь приходит относительно (весьма относительно) современное изобретение — кластеризация коммутаторов. С ее помощью несколько физических устройств могут объединяться в одно логическое. Традиционно данную функцию принято считать «красивостью», призванной в первую очередь упростить управление. Однако же главные плюсы кластеризации коммутаторов совсем в другом. Помимо некоторых технико-коммерческих аспектов, кластеризация — это еще и сокращение количества узлов в топологии при сохранении резервирования физических устройств.



    Сегодня главным драйвером растущей популярности кластеризуемых коммутаторов является именно возможность объединения в LAG портов, находящихся на разных физических устройствах кластера. Таким образом мы получаем возможность подключить один коммутатор доступа (в который воткнуты пользовательские линки) к двум коммутатором агрегации без всякого Spanning Tree. Аналогичным образом, если уровней больше, коммуаторы агрегации можно при помощи LAG-группы подключить к ядру (если оно у вас есть) или магистрали.



    Слово о масштабе


    Изначально кластеризация появилась на коммутаторах формата 24/48×1GE (+ 2×10GE), то есть устройствах относительно небольшого масштаба. В зависимости от производителя и модели объединять такие коммутаторы в кластер можно либо с помощью специальных интерфейсов (PCI Express, InfiniBand и пр.), имеющих ограничение в длине до нескольких метров, либо посредством обычных портов 1 или 10 Gigabit Ethernet, в т. ч. оптических. В последних случаях появляется возможность строить территориально-распределенные коммутаторы и даже небольшие metro-ethernet-сети. В зависимости от конкретной реализации и модели обычно допускается объединение от двух до десяти устройств в один кластер.

    Спустя некоторое время, производители стали внедрять кластеризацию и на больших модульных коммутаторах. В них для внутрикластерых линков как правило используюется несколько интерфейсов 10 Gigabit Ethernet. Максимальное количество таких устройств одного кластера обычно существенно меньше (2–4), впрочем, в этом нет особенного криминала.

    Помимо модульных коммутаторов кластеризация также встречается на полноценных аппаратных маршрутизаторах старших линеек отдельных производителей. С теоретической точки зрения для маршрутизаторов эта функция менее актуальна в силу наличия в сетях IP/MPLS «родных» механизмов маршрутизации, балансиоровки нагрузки и трафик-инженеринга. Но поскольку такие устройства часто применяются и для выполнения L2-функций (PE для услуг L2VPN/VPLS или совмещения L3 и L2 в одной коробке), поддержка кластеризации на них также важна и применяется в первую очередь для того же самого: объединения в LAG интерфейсов разных физических устройств с целью резервирования подключений второго уровня.

    И все-таки бесплатным светлое будущее не будет. В некоторых аспектах кластер коммутаторов таки хуже, чем много отдельных коммутаторов. Например, таблица MAC-адресов на всех устройствах как правило одна. Соответственно, верхняя планка максимального количества записей в ней распространяется на весь кластер. Для сети из 10 устройств масштаба небольшого города лимит в 10–15 тысяч MAC-адресов может оказаться существенным ограничением; некоторые реализации, например, требуют одновременной перезагрузки всех устройств кластера при обновлении софта. Подобного рода нюансов в зависимости от конкретной модели устройств может быть довольно много. Все это делает кластеризацию сомнительным подходом для построения операторских сетей.

    Итого


    Совмещение кластеризации коммутаторов и агрегирования интерфейсов разных устройств в LAG-группы — это наиболее эффективный на сегодня способ строить отказоустойчивые L2-сети предприятий, кампусов (нескольких расположенных рядом зданий единого административного управления), дата-центров и отдельных узлов сетей провайдеров. По большинству параметров: скорость переключения, устойчивость, надежность, простота настройки эксплуатации и траблшутинга, балансировка нагрузки — данный подход существенно превосходит вариации на тему Spanning Tree.

    Однако эта технология — не панацея, не стоит воспринимать ее как механизм построения настоящих L2-сетей операторского масштаба.

    Кроме того, Spanning Tree, хоть и теряет свою актуальность как механизм построения отказоустойчивой топологии и балансировки, но, как уже было сказано, остается актуальным способом защиты от человеческой ошибки. Поэтому, если, например, на коммутаторе включен по умолчанию протокол RSTP или PVST+, не стоит его выключать, если только вы не уверены, что знаете точно, зачем именно. Желательно также, чтоб на всех коммутаторах использовался один протокол, но это уже совсем другая история.
    Поделиться публикацией

    Похожие публикации

    Комментарии 152
      +16
      На самом деле это всё здорово в «сферическом вакууме», а в реальности во многих организациях такой «зоопарк» из устройств, что ни о какой агрегации речи и быть не может. Так что заголовок очень громкий, но с реальностью не сильно связан, потому как STP универсален между железками и свои задачи — «резать петли» и находить кратчайшие пути выполняет очень даже неплохо.
        0
        Хотя… учитывая что речь идёт о гигабитных каналах (да и ценовую категорию железок я по ссылкам посмотрел), там железо думаю более унифицированно.
          0
          Главное предназначение, как я понял это из статьи, крупные сети предприятий. А на многих крупных предприятиях сети проектируются, а не «лепятся и того что было». Таким образом вся L2-среда будет унифицированной. Ведь ни один нормальный босс не согласится тратить кучу денег на умные коммутаторы, которые будут использоваться как тупые. Конечно, все это при условии наличия грамотного админа в штате)
        +4
        LAG — по-моему не очень хорошее название для сетевой технологии. Не хотеть, что у меня что-то ЛАГало.
          +6
          LAG, MIMO… да что мы вообще понимаем в сетевом юморе?!
          +2
          Обычно «кластеризация» коммутаторов довольно расточительное занятие, так как фактически думает за всех мастер (следовательно кластер по всем ТТХ и ограничениям будет равен ТТХ мастера), а все остальные члены кластера всего лишь «удлинители портов». Во вторых при «кластеризации» чаще всего требуются одинаковые модели, ревизии устройств и даже версии FW.
          По поводу STP его реально использовать на уровне агрегации, и абсолютно не рекомендуется на уровне доступа, в противном случае абонент с неисправной (моргающей) сетевой картой устроит вам небольшой армагедонец в рамках STP ветки.
            +1
            Поподробнее о сетевой плате клиента можно?
              0
              при изменении состояния линка SPT «перерисовівает» свое дерево, что является довольно ресурсоемким занятием.
              0
              Не только моргающая сетевая плата, а также закольцованный абонентский свитч к примеру. И тут неплохо, чтобы оборудование уровня доступа имело нормально работающий механизм типа loopdetect, тогда с этим проблем не будет.
                +1
                А никто и не спорит, просто пол статьи, о том что как хорошо STP ловит петли, только вот о том что это как бы побочное (по большому счету) применение STP автор как бы не задумывается.
                  0
                  Разрыв петель — побочное? Какое ж тогда по вашей версии основное?

                  P. S. Ну, про «как хорошо» — это вы уже сами домыслили.
                    0
                    Основное это резервирование, если стоит задача предохраниться от ошибочных петель, то это должно решаться с помощью того же LBD.
                +1
                Блокирование BPDU с портов доступа еще никто не отменял.
                  0
                  Ну только это не про STP, а скорее наоборот — про его отсутствие :)
                    0
                    Как бы и я о том же…
                    0
                    Про «мастер» — вы почти правы. Не совсем — в части «удлинителя портов». Все же не удлинителя — свичи в кластере работают как свичи, то есть коммутируют, принимают решения о передачи кадров дальше. Примерно как карты в больших коммутаторах. Просто таблица коммутации пересчитывается под каждый конкретный свич, с учетом его кластерных портов. Внутри обычно работает нечто вроде протокола маршрутизации. Даже не нечто, а в случае, например Juniper EX, это прям ISIS, к которому дописали нужный TLV. То есть с точки зрения производительности все отнюдь не упирается в производительность одной коробки.

                    С токи зрения масштабирования — как правило да. Хотя есть например исключение в виде Juniper QFabric, но это слишком уж отдельный случай. Из за этого ограничения по масштабированию разного рода таблиц, в первую очередь таблицы MAC-адресов, кластеризация — сомнительный механизм, чтоб строить на ней прям сети. Впрочем об этом в статье сказано. В корпоративных же сетях лимит в 16 тыс. MAC'ов — как правило достаточно высокая планка. Если нет, то скорее всего кольца с STP все равно не спасут.

                    Ну и да. Не всегда нужны одинаковые модели. Juniper EX4200 кластеризуется с EX4500. Причем внутри 4200 модели могут быть какие угодно. 24-портовые, 48, медные оптические, с PoE, без и пр. Brocade FCX — аналогично. За 3750 не помню, но кажись и там можно объединять разные 3750 в стек. Софт, да, везде нужен одинаковый.
                      0
                      Использовать STP на уровне агрегации — безумие. Единственное место где его можно сейчас использовать — уровень доступа. Отключение кольца доступа на 7-10 секунд ещё можно пережить, но вот отключение уровня — агрегации на такое время уже может быть причиной увольнения :).
                      +3
                      Статья хорошая, но заголовок жёлтый.
                        0
                        Пожалуй, да. Хотя позволим себе немножко пооправдываться. Идея статьи родилась от чтения и разговоров на тему STP. Как это круто, да почему без него жить нельзя. Так в мозгу и отложилось, что надо, мол, написать статью о том, почему STP уже не очень-то и надо.
                        0
                        Я как только прочитал заголовок вспомнил как работал в одном здании где сидело 2000 человек. А админы, ради оптимизации отключили Spaning Treee. А какой-то умник в одной из комнат для совещаний, воткнул пачкорд из одной розетки в другую. Было довольно велосело наблюдать, как сеть рухнула, а админи бегали по зданию и бились головой ап стенки пытаясь понять причину ))
                          0
                          Заголовок реально желтый. Также автор забыл упомянуть что с помощью stp можно очень красиво балансировать на l2, в случае если у вас не хилое кольцо из l2 коммутаторов, или просто не используется маршрутизация.
                            –1
                            Да вот не очень-то и красиво. Уж с LAG точно не сравнить. Вообще, пожалуй, про балансировку нужно будет написать отдельно.

                            Что касается «нехилых колец из коммутаторов» с STP, столько популярных в нашей стране, — наш дружный коллектив уверен, что это чистой воды жуть с ружьем. Дешево и сердито, конечно, но как раз вот про тех, кто может писать в спортоло прошение о награде.
                              0
                              Отчего не красиво: есть у нас 10 коммутаторов доступа, которые никогда не слышали о лагах :):):) о LAG конечно же :) Обоими концами соединяем его с агрегацией, которая root и вуаля)
                              Почему так? Ну потому что когда таких коммутаторов тысячи каждая копейка важна, и тут уж не до LAGа, тем более что некрасивость stp больше из пальца высосана. Потеря 1-2 пингов у 50% клиентов этого кольца пока дерево перестроится — это не проблема. ИМХО.
                                0
                                Ну, в общем, да, только… habrahabr.ru/blogs/network_technologies/132312/#comment_4415722
                                  0
                                  В общем у нас разные масштабы :) У вас решения для пары человек, у меня для пары сотен тысяч и т.д. :)
                                    +1
                                    Ну тогда, вам в ООН за наградой :) Хотя plain ethernet для провайдерских сетей — это, к сожалению, наша большая боль. Больше только netflow для биллинга.

                                    Коллеги из какой-нибудь Америки вообще сначала не понимают, о чем речь, когда с ними разговаривают о кольцах с STP. Когда понимают — хватаются за голову, мол, дикая страна.
                                      0
                                      И как же они строят сети?
                                      Н-р сайт cisco.com, включая все их презентации и прочее очень даже знает о stp
                                        +2
                                        Стягивают тот или иной первый уровень (xDSL или xPON, если ШПД для физлиц или прям оптический ethernet, если юрлица) от абонента/клиента в крупные узлы (АТС всю жизнь у нас это называлось), в которых ставят не говнохабы по три копейки, а нечто взрослое. Это взрослое либо (победнее) собирают гирляндой с (раньше с минимумом STP, теперь все больше как описано выше), либо подключают к IP/MPLS сети на базе псевдопроводов или VPLS.

                                        Собственно, это написано в любом учебнике, так всю жизнь делали и у нас (см. классическую телефонию или Стрим). И, конечно, понятно, с чем связаны сложности организации нормальной инфраструктуры сетей доступа у нас. Поэтому, да, весь этот говнометроэзернет с STP лезет из всех щелей. Только из этого не следует, что так надо делать. Это у нас такая болезнь индустрии.

                                        STP, как многократно уже было сказано, никто не отменял. Но только, если тот или иной продукт поддерживает STP, это не значит, что им нужно обставлять полрегиона, соединять абы как (как сможете линии проложить или любымими кольцами), включать STP и ждать счастья. Не случиться, к сожалению.
                                      +1
                                      Вы коллегам из какой-нибудь Америки напомните, что они ещё у себя ATM и FrameRelay изжить не могут, так чта нечего тут хвататься за голову. ;)
                                        0
                                        ATM у нас тоже жив. У Ростелекома какого-нибудь его навалом в регионах. Пока работает, чего его изживать-то.
                                          0
                                          М-м-м, дайте догадаюсь, как он у них появился...«слушайте, у нас тут 72ая циска не может прожевать больше 3 Гбит езернета, может, ещё чо воткнём в неё?» ;)
                                          Не, правда, в чём смысл его существования, особенно сейчас? Он устарел ещё 10 лет назад, в США тянется тяжким наследием горы закупленного оборудования и необходимого ROI, а у нас-то откуда?
                                            0
                                            Да ни в чем, кром етого, что его надо чем-то заменять. Есть присутствие MPLS-магистрали в крупных городах региона. И есть ATM-акцесс, которым они дотягиваются до клиентов в соседних р-нах и т. д. Собственно, чем его заменять? Кольцами скажете с ринг-проекшеном? Сомневаюсь. А MPLS потихоньку дотягивается на районные узлы, становится, извиняюсь за грубое слово, seamless — ATM выкидывают.
                                              0
                                              Так это и называется тяжкое наследство. Если бы строились с нуля, то ой как сомневаюсь в появлении MPLS. Я знаю по Питеру только ситуацию, конечно, так тут проще волокно под 10GbE взять, чем городить MPLS и Ethernet over MPLS схемы при исчерпании пропускной способности. :)
                                                0
                                                Ну, вашу нелюбовь к MPLS мы уже обсуждали :) Правда я не понял про «если б строились с нуля». MPLS у них вроде с нуля, думаю, ATM тоже в свое время был с нуля.

                                                Просто еще города с плотностью населения как в Питере — это одно, а какая-нибудь республика Коми — это трошки совсем другое.
                                                  0
                                                  Да не, MPLS мне нравится… в теории и пока не смотришь на стоимость железяк с его поддержкой. :)
                                                  А у магистралов вообще всё по другому. Ну да «жираф большой, ему видней». ;)
                                                  0
                                                  В Питере, чего не построй, все продать можно, если продавать уметь.
                                                0
                                                MPLS железки класса MX80, которые можно поставить в районный городишко — они ж вот только появились. А на кольца переходить, видно, очень уж не хотелось (что правильно).
                                0
                                Бред. Как без spanning-tree вы сможете подключить свичи несколькими патчами и заставить по одним транкам гонять половину vlan, а половину по другим, при этом если одна половина транков падает, то включается вторая и через оставшуюся половину ходит снова весь трафик.
                                LAG — прекрасное дополнение, но только дополнение. И по большей части прекрасное для избыточности подключения серверов.
                                  0
                                  Ну это и есть та самая балансировка, о которой я выше писал…
                                    0
                                    >как без spanning-tree вы сможете подключить свичи несколькими патчами и заставить по одним транкам гонять половину vlan, а половину по другим,

                                    STP для балансировки нужен только в этих самых наших любимых метро-кольцах, которые сами по себе бред специфическая область, выходящая за рамки статьи. В корпоративных же сетях и прочих классических применениях plain ethernet-форвадинга, LAG для балансировки по любым показателям лучше STP.
                                      0
                                      Пока в сети будет пара портов, на которых не включен STP — такую сеть можно положить. Не важно — корпоративная это сеть или уровня провайдера. Так что говорить о умирании STP можно только на сетях, в которых доступ к каждому порту контролируется физически.
                                        0
                                        «Кроме того, Spanning Tree, хоть и теряет свою актуальность как механизм построения отказоустойчивой топологии и балансировки, но, как уже было сказано, остается актуальным способом защиты от человеческой ошибки. Поэтому, если, например, на коммутаторе включен по умолчанию протокол RSTP или PVST+, не стоит его выключать, если только вы не уверены, что знаете точно, зачем именно. Желательно также, чтоб на всех коммутаторах использовался один протокол, но это уже совсем другая история.»
                                    +3
                                    Мне кажется, уважаемый автор путает мягкое (STP — протокол в основном для L2-резервирования) и тёплое (агрегация линков, EtherChannel — протокол в основном для увеличения пропускной способности). Они друг другу не враги и не конкуренты, а при грамотной настройке — лучшие друзья.
                                    Статья хороша тем, что повествует нам в принципе о таких вещах как агрегация линков и кластеры из коммутаторов. За это плюс. Даже в карму автору.
                                    Статья плоха тем, что сравниваются несравнимые вещи. За это минус статье.
                                      –2
                                      etherchannel как средство увеличения пропускной способности — довольно кривая штука, в случае с ec 1+1!=2, к сожалению. и, к слову, в большинстве курсов cisco, напирмер, ec используется для failover-а.
                                        0
                                        1+1 как раз 2.
                                        другое дело что пропорции меняются когда кол-во физических каналов в езерчанеле иное.
                                          0
                                          похоже, что в матчасти вы не разбираетесь. вот вам простая картинка:
                                          image
                                          2 свитча соединены между собой 2мя линками 100Mbps собранными в EthChan. К каждому свитчу подключено по серверу, через 1Gbps (щас уже 100Mb сервера-та не найдешь уже). Копируем файлик с одного сервера на второй. Внимание, вопрос — до какой скорости разгонится передача файла между серверами?
                                            +4
                                            Хехе. Кто еще не разбирается.
                                            В данном случае, не зависимо даже от того, какая у вас балансировка, будет 100.
                                            Но воткните в каждый свитч по еще оному серверу, и тогда между свитчами у вас будет 200.
                                              0
                                              вы таки понимаете, что я вам дал простой случай и даже тут вам пришлось что-то придумывать, чтоб добиться полной утилизации линка?
                                              попробуйте добиться нормальной утилизации ethChan если у вас ещё есть в середине роутеры и сервера у вас в разных подсетях.
                                                +1
                                                Ответ не верный. Если бы мне надо было соединиться только 2 сервера, как нарисовано у вас, я бы их соединил гигабитом и не придумывал ничего (собственно, а что я придумал? Я ответил что будет 100). Но жизнь она иная, и в одном коммутаторе как правило больше 2 портов занято (включая аплинк), соответственно скорость поднимется выше 100.

                                                Что значит нормальной? 50/50? В реальности — никогда, но лабораторными способами — легко и непринужденно. И кол-во роутеров тут будет не причем.

                                                Т.о. я так и не понял что кривого в ec?
                                                  0
                                                  нет у вас гигабита между двумя зданиями и всё, забудтье. даже в москве оператор связи часто говорит, что — гигабита нету, можем дать 3 по триста, берете?

                                                  вот в том и кривость ес, что в реальных условиях нормальной утилизации всех линков не добиться. и когда покупаются 3x300, то первый линк загружен под 100%, второй на 30-50%, а третий хорошо если на 10. и то, чтоб этого добиться надо танцевать с бубном :) например делать не просто тупой ethChan, а три L3 линка с динамикой, к примеру.
                                                    0
                                                    ну если 2 физ. линка, то пропорции 3:3:2. Другое дело что трафик до того, по какому признаку вы балансируете разный… Тут уж как карта ляжет.
                                                0
                                                вот так:
                                                image
                                                  +1
                                                  Гм. Вы видимо не до конца понимаете как оно работает.
                                                  Во всех ваших примерах у вас что src, что dst mac, ip, port будут в количестве одной штуки. Что здесь можно сбалансировать? Ну не умеет оно per-packet.
                                                    –1
                                                    я-то как раз прекрасно понимаю как оно работает. в том и заключается кривость ethChan, что оно очень ограниченно-применимо.
                                                      0
                                                      Как вы в данной схеме сможете загрузить 2х100?
                                                        –1
                                                        извращенно исключительно.
                                                        сделать оба линка между маршрутизаторами именно L3 и маршрутизируемыми, навесить на оба линка равные веса. это уже будет балансирвока per-flow, что значительно лучше чем то, что есть у ethChan. а можно ещё включить per-packet и тогда совершенно хорошо получится.
                                                        второе — собрать их в бандл ppp-multilink, а он уже сам разберется, у ppp есть свой нормальный механизм packet fragmentation / interleaving.
                                                          +1
                                                          Но свитчи-то де-юро L2 ;)
                                                            +1
                                                            Эээ, нет. Вы неправы. LAG и ECMP на большинстве платформ балансируются одинаково. Либо одинаково хорошо, либо одинаково плохо. Везде сейчас per-flow (кроме MLPPP), вопрос только какие поля включать в хеш, и как приводить хеш к значению линка в LAG или NextHop при ECMP. Чем гибче этот функионал, тем выше цена.

                                                            Просто в сравнении со свичами маршрутизаторы — это обычно либо программная коробка, либо существенно более дорогое железо. В обоих случаях гибкость функионала выше. Поэтому вы фактически сраниваете не LAG vs ECMP, а функционал свичей класса C3750/EX4200 с функционалом тех же Cisco 6500/7600, Juniper MX или программными коробками. Да, C3750/EX4200 при данном сравнении заведо хуже балансируют, что при LAG, что при ECMP. Собственно, это одно из отличий больших L3-свичей от полноценных маршрутизаторов.
                                                              0
                                                              Не подумайте, что я имел в виду, что функционал хеширования у MX и 6500/7600 сколько-нибудь сравним. 7600 в смысле гибкости балансировки ближе к 3750, чем к MX. Просто пример оборудования разных классов.
                                                                0
                                                                я в Juniper-ах к сожалению вообще не разбираюсь :(
                                                                0
                                                                спасибо, я пробовал сделать per-flow в цыскиной реализации LACP/PaGP (пробовал и то и другое). как писал ниже — не взлетело.

                                                                я вобщем-то вообще ничего не сравниваю. я изначально говорю, что не надо так превозносить LAG, а сразу нужно говорить о его ограничениях. а то появляется очень много начнающих одминов которые смотрят на LAG (LACP/PaGP) как не серебрянную пулю, а потом ходят за дополнительным бюджетом либо на линк потолще, либо на железо потяжелее :( мне тут подобную схему с полгода назад пытались предложить коллеги из Англии, блин.
                                                                  0
                                                                  Ну да. Собственно, я когда писал эту статью (в данном случае senetsy=salium), там был подраздел «Слово о балансировке», но много получилось и совсем далеко от темы. Убрал, висит в черновиках как набросок для отдельной статьи.
                                                                    0
                                                                    о, давайте! с удовольствием почитаю.
                                                        0
                                                        А чем эта схема концептуально лучше-то?
                                                          0
                                                          да ничем, это просто более сложный вариант первой, показывающий ещё большие проблемы ethChan.
                                                      0
                                                      Да-да-да. В черновиках давно висит текст про балансировку.

                                                      P. S. Передача файлов может быть и в несколько потоков :)
                                                        0
                                                        Тут написано «файла».
                                                        Если «файлов» и настроена балансировка по L4, то можно и за 100 выпрыгнуть.
                                                          0
                                                          Один файл можно передавать в несколько потоков одновременно :)
                                                            0
                                                            Ну этого не было в условии :)
                                                              0
                                                              ещё в условии не было, что L4-балансинг у цыски нифига не работает. проверено на 3845 и 6509, ios 12.4.24 и 12.2.33SX
                                                                0
                                                                Что значит не фига не работает? Есть две 7609, как раз планирую проверить dst-mixed-ip-port
                                                                  0
                                                                  попробуйте, у меня к сожалению нету 76xx, но на перечисленном железе не взлетело :(
                                                                    0
                                                                    Ваш 6500 мало чем отличается от 7600 :)
                                                                      0
                                                                      ios-ом. 12.4 и 15.0 для шеститонников вроде ещё нету :)
                                                                0
                                                                и ещё бывают не только файлы. попробуйте заставить любую СУДБ, Оракл, мускуль, мсскуль, реплицировать в несколько потоков, пожалуйста?
                                                                  0
                                                                  Понимаете, если что-то очень хочется обосрать, то это не составляет особого труда. Я не силен в СУБД, но догадываюсь что многопоточности там быть не может исходя из соображений целостности.
                                                                    0
                                                                    Собственно, непонятно, о чем дискуссия. Балансировка в LAG — это неидеальный инструмент. Пропорции сильно зависят от типа трафика и оборудования которое его балансирует. Об этом действительно надо отдельно написать. Вот тут была дискуссия, если интересно:

                                                                    www.mail-archive.com/juniper-nsp@puck.nether.net/msg14066.html
                                                                    www.mail-archive.com/juniper-nsp@puck.nether.net/msg14098.html

                                                                    Но, собственно, какие есть варианты. Вы же сами, кажется, где-то написали, что PVST+/MSTP — еще хуже. Вряд ли вы сможете заставить СУБД реплицироваться в несколько VLAN'ов :)
                                                                      0
                                                                      ещё вариант, как я написал уже выше — сделать несколько L3 каналов с равными весами маршрутизации и включить балансировку per-packet. если это не телеметрия от Фобос-Грунта, то нормально будет работать :)
                                                                        0
                                                                        Я там уже ответил :)

                                                                        Сомневаюсь, что это универсально хорошо. Как способ решить конкретную проблему повышения емкости линка для конкретного приложения — может быть. А если для всего трафика пакеты одной TCP-сессии начнут ходить разными путями и потом пересобираться на получателе — сомневаюсь, что это круто. А уж если понадобится поверх этого CoS сделать, то ууу…
                                                                          0
                                                                          да не скажите, нормально там всё будет. если счет идет на сотни мегабит, то tcp вообще ничего не заметит, а джиттер из-за параллельных веток будет не такой страшный, чтоб пакеты умерли в деджиттер буффере телефона :)
                                                                            0
                                                                            да, две ветки дискуссии — у меня уже шизофрения развивается :)
                                                                              0
                                                                              не знаю, как на других железках, но на цисках для per-packet нужно выключить CEF, вот тогда скорость просядет ооооочень сильно.
                                                                                0
                                                                                CEF — это про другое вообще.
                                                                                  0
                                                                                  ну не то, чтобы про другое, выше речь шла о том, что при по-пакетной балансировке работать будет хорошо, так вот чтобы заработала по-пакетная балансировка, нужно выключить CEF, а если его выключить — хорошо работать точно не будет…
                                                                0
                                                                Статьи так и не появилось или я её пропустил?
                                                                0
                                                                В дополнение: цисковские пропорции

                                                                Number of Ports in the EtherChannel Load Balancing

                                                                8 1:1:1:1:1:1:1:1
                                                                7 2:1:1:1:1:1:1
                                                                6 2:2:1:1:1:1
                                                                5 2:2:2:1:1
                                                                4 2:2:2:2
                                                                3 3:3:2
                                                                2 4:4
                                                          0
                                                          На мой взгляд, все-таки LACP не является полноценной заменой STP (или другой технологии резервирования на L2). Подключение коммутатора уровня доступа к двум коммутаторам агрегации (или коммутатора агрегации к двум коммутаторам ядра), расположенным на одной площадке не обеспечивает необходимого уровня резервирования.
                                                          Кроме того, мало что сказано об одном из основных недостатков STP — высоком времени сходимости
                                                            0
                                                            Непонятно, почему на одной площадке. Пожалуйста, на двух, если надо.
                                                              0
                                                              Проглядел в статье упоминание о кластеризации поверх Ethernet. Интересно было бы почитать об этом
                                                                0
                                                                Там (в статье) например даже такая ссылка есть. www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pdf

                                                                Собственно, ничего особенного в кластеризации через ethernet нету. Это не новость совсем. Просто обычный порт указывается в конфиге как внутренний порт кластера и всего делов. Внутренняя логика (в случае Juniper'а, скажем, это протокол ISIS) включает его в топологию с соответствующим весом — и вперед.
                                                                  0
                                                                  Чего-чего у Juniper ISIS?
                                                                    0
                                                                    Под virtual chassis внутри лежит ISIS. Да, да. И не только у Juniper, насколько я понимаю. Именно он строит топологию и считает кратчайшие пути между интерфейсами. В QFabric помимо этого еще и BGP заточили для анонса MAC-адресов (ага-ага, куда катится мир). Хотя у Cisco тоже есть какое-то датацентровое решение, где они биджипней маки анонсируют.
                                                                      0
                                                                      А где почитать можно? Чего-то я не помню, чтобы Juniper о таком писали.
                                                                        0
                                                                        В книжке «JUNOS Enterprise Switching» (в интернетах найти можно при желании). В CLI есть команда show virtual chassis чего-то там isis database и т. д. На каждом заборе, да, не написано, но никакого секрета в этом нет.

                                                                          0
                                                                          Эх, ошибся.

                                                                          user@EX-4200.senetsy.lab> show virtual-chassis protocol ?            
                                                                          Possible completions:
                                                                            adjacency            Show virtual chassis adjacency database
                                                                            database             Show virtual chassis link-state database
                                                                            interface            Show virtual chassis protocol interface information
                                                                            route                Show virtual chassis routing table
                                                                            statistics           Show virtual chassis performance statistics


                                                                          Слова ISIS там в явном виде нету, но по выводу, в общем, все понятно.

                                                                0
                                                                Сколько слышал о высоком времени сходимости — но на практике не сталкивался ни разу. В основном работал с rapid-pvst, при физическом отключении линка ни один пинг не пропадал. Это я к тому, что теория теорией, но на практике вещь хорошая и нужная.
                                                                  0
                                                                  Ну вы все-таки работали с «быстрой» версией протокола? я говорил о классическом STP
                                                                +3
                                                                btw, spanning tree с аглицкого, отнюдь не ветвящееся дерево, а вовсе покрывающее или на крайний случай связующее. Хорош уже на STP обзываться :)
                                                                  +1
                                                                  Пожалуй, вы правы. Недоглядели :)
                                                                    +1
                                                                    Наиболее распространённый русский термин для spanning tree — остовное дерево (хотя его также иногда называют покрывающим деревом, остовом или скелетом графа): ru.wikipedia.org/wiki/Остовное_дерево
                                                                    0
                                                                    Объясните, пожалуйста, как можно говорить, что LAG замена STP и STP морально устаревает, если для реализации LAG необходимо дублировать каждый линк? Возьмем упоминаемый вами в статье MetroEthernet — вы представляете продублировать каждый линк? Да, оптика кладется не одножильная, но себестоимость линка увеличивается в 2 раза, так как надо отдать дополнительные две (или в случае с WDM — одну) жилы. А если коммутаторы не имеют оптических портов (а это далеко не фантастика, мне доводилось работать в телекомах) — дополнительные медиаконвертеры это также дополнительные затраты.

                                                                    Кластеризация это хорошо, за информацию за неё спасибо, однако хотелось бы увидеть отдельную статью, посвященную именно кластеризации. Особенно интересует кластеризация посредством GigabitEthernet, а не PCI.

                                                                    За статью скорее плюс, читать было легко и приятно.
                                                                      0
                                                                      Есть такая штука, как multichassis etherchannel — причем она есть отнюдь не тольо у цыски. автор привел хороший линк на документ от Juniper. Так вот в случае с MC-LAG (multichassis links aggregation) — нет необходимаости дублировать каждый линк. Можно треугольничками, можно колечками.
                                                                        0
                                                                        Я вас правильно понял? Три коммутатора соединяются в треугольник (кольцо), линки не дублируются, при этом для защиты от петель используется не STP, а MC-LAG? Какое преимущество такого способа построения перед STP? Про время сходимости прошу не упоминать, rapid-pvst работает достаточно быстро.
                                                                          0
                                                                          да, вы меня совершенно правильно поняли. преимущество — автоматическая балансировка нагрузке в каналах MC-LAG. Вобщем с STP тоже можно балансировать нагрузку раскидав виланы по разным линкам, но во-первых, нужны виланы, а он может быть и всего один, а во-вторых это руками надо делать. MC-LAG это сделает сам и автоматически. опять же, отлаживать проблемы на ethChan проще, чем с stp.
                                                                          а если используется не просто EthChan, а вендор-специфичная технология — то ещё и виртуализации добиться можно. Всмысле, когда все железки будут выглядеть как будто одна. Цыскин VPS, у Juniper своя технология, не помню названия
                                                                            0
                                                                            Поизучаю на досуге, спасибо.
                                                                              0
                                                                              Посмотрел по интернету… насколько я понял, MC-LAG это удел тяжеловесов? 7600, ASR 9000 и т.д.? Тогда уж извольте, это никак не конкурент. STP работает на, не побоюсь этого сказать, самых популярных 29xx Catalyst, на коммутаторах иных производителей. Так что, закидайте меня камнями, но пока хоронить STP еще рано.
                                                                                0
                                                                                да я вобщем не говорил, что STP надо хоронить :)
                                                                                3750 ещё… только там между разными железками стека
                                                                        +1
                                                                        Простите за оффтоп, но в чём вы такие красивые схемы рисуете?
                                                                          0
                                                                          Любой векторный редактор. В данном случае OpenOffice Draw. Библиотека иконок — в ней весь секрет, ее Juniper дает только тем, кому надо :)
                                                                            +1
                                                                            И ещё один оффтоп — у вас замечательный фак по МХам, только сегодня как раз прочитал.
                                                                              0
                                                                              Пора, кстати, чуточку его проапдейтить в связи с выходом MX5/10/40 и аки объявленной поддержкой IPFIX на Trio.
                                                                                0
                                                                                Будет интересно.
                                                                                У нас, правда, MX240, до MX80 в своё время недотерпели.
                                                                                IPFix хорош, конечно, тем что стандарт… и плох, что хочет Trio и не поддерживается flow-tools (как и Jflow и NetFlow v9, впрочем). Желающие, кстати, приглашаются проголосовать за них у проекта.

                                                                                P.S. После работы с Juniper'ом не понимаешь, как такое УГ как IOS может вообще до сих пор существовать :) Видимо, только за счёт первокласснейшей документации.
                                                                                  0
                                                                                  Это вы, коллега, с EX не долго работали просто =).

                                                                                  (Сейчас кстати вспомнил — годика два назад senetsy нам свитч по ошибке привезла с вашими конфигами :-) )

                                                                                    0
                                                                                    Да ладно, EX4200 стоит и есть не просит :)
                                                                                    Ага, теперь всё ясно.
                                                                            0
                                                                            Поищите на просторах. маленький редактор — Dia называется. С ним в комплекте идёт парочка библиотек, с помощью которых я такие схемы летом рисовал.
                                                                            Вот например
                                                                            0
                                                                            Эх, после такого заголовка надеялся увидеть что-нибудь про TRILL, например. Вот это было бы действительно интересно.
                                                                              0
                                                                              Эмс… Не понятно, а почему кластеризация это отменяет STP? У нас вот стоят на суперкомпьютерах InfiniBand-овские кластерные коммутаторы, и в них специально сделаны кольца (самими производителями), чтобы и надёжнее было и балансировка нагрузки была эффективнее — это слова изофициального объяснения в документации. Ну, и маршруты по этим кольцам строятся при помощи нескольких вариантов STP.

                                                                              Я не специалист по сетям, поэтому интересно было бы понять, кто не прав?
                                                                                0
                                                                                Поскольку модель ВОС (она же ISO/OSI, если вам так больше нравится) забыла наделить канальный уровень

                                                                                Согласно ГОСТ 24402-88, в котором описана ВОС, этот уровень называется Уровень звена данных, а Канальный уровень — недопустимое название.
                                                                                Канальный уровень есть в стеке TCP/IP.
                                                                                  +2
                                                                                  Оч. крутой камент. Буду знать, спасибо )
                                                                                  0
                                                                                  Работаю в крупном забугорном провайдере. Есть привычка разносить ядро по разным ДЦ. Кластеризовать их очень неудобно в этом режиме
                                                                                    0
                                                                                    Ну в ядре-то и без кластеров не должно быть никакого STP.
                                                                                      0
                                                                                      В прицнипе, достаточно кластеризовать устройства ниже по иерархии и соединять их с ядром при помощи RTG. Это как LAG, только всегда active-passive. Тогда в ядре не нужно кластеризации. Собственно, так и делают часто: все-таки большие модульные свичи только-только стали кластеризоваться.
                                                                                        0
                                                                                        так и дистрибушн разнесен по разным ДЦ…
                                                                                      0
                                                                                      Приятель просил задать вопрос.

                                                                                      Не могли бы вы чуть подробнее рассказать о режимах LACP? Давно занимаюсь аггрегацией каналов внутри небольшого провайдера, но нигде ни разу не встречал толкового описания разницы: когда, например, у меня есть два линка между двумя свитчами. В первом случае я на свитче1 настраиваю оба порта «активными» на свитче2 оба порта «пассивными». Во втором на свитче1 и свитче2 все порты «активные».
                                                                                        0
                                                                                        Active — первый инициализирует LACP и шлет negotiation пакеты.
                                                                                        Passive — ожидает установление LACP, и пока не получит negotiation от Active в группу он не войдет и будет работать как обычный порт.
                                                                                        То есть получается ведущий и ведомый.
                                                                                          0
                                                                                          И в связке Active-Active они оба шлют пакеты и оба готовы установить соединение. Но такой вариант, мне кажется, несколько неправильным.
                                                                                          0
                                                                                          Про active и passive теорию я знаю. Интересуют именно различия в работе при разных настройках.

                                                                                          Автор писал, что в режиме "«активный–пассивный»: пока один линк в «апе», второй в «дауне», при падении основного происходит переключение на резервный." То есть, если у меня будет настроено так: свитч1 — LACP-active (два порта по 100мбит), свитч2 — LACP-passive (два порта по 100мбит), то трафик свыше 100мбит не пройдет, т.е. второй канал будет только как резерв включаться?
                                                                                          ­
                                                                                            0
                                                                                            Там автор (то есть я :) еще писал, что не надо путать LAG и LACP. LAG в решиме active/active или active/passive — это то, что вы процитировали. А LACP в режиме active или passive — это то, о чем lumenous (либо устройство слушает и шлет LACP-пакеты, либо только слушает). Совершенно не имеющие отношения друг к другу вещи. Собственно, я бы вам рекомендовал просто разобраться, что такое LACP, зачем он нужен, и вообще нужен ли, тогда и про режимы его работы будет понятно.
                                                                                        0
                                                                                        Насчёт ненужности это сильно сказано в заголовке. Помнится, была у нас одна железяка сборная, в которой как раз пытались сделать кластеризацию, т.е. две карточки — свичи, третья — клиент — соединяется с обоими свичами. Замаялись, в итоге плюнули на всё, сделали RSTP с прицелом на MSTP и все счастливы.
                                                                                          0
                                                                                          Все это красиво и замечательно. Но каменный цветок разрушается как только у Juniper EX отъедут мозги и кольцо развалится, пытался высмотреть в статье методы защиты от split-brain, но не нашел. Это замечание следует считать руководством к действию, коллеги :-).
                                                                                          0
                                                                                          При желании можно избавиться от STP с переходом на Routed Access Layer. Универсальное (вендор-независимое) решение. В большинстве случаев на уровне доступа используются свитчи Cisco Catalyst 2960, 3560, 3750 и реже 45хх — кроме 3750 ни один не поддерживает кластеризацию. Несмотря на уменьшение доли рынка ethernet коммутаторов Cisco, еще в 2010 году они составляли более 73.1%, а следовательно далеко не все могут позволить себе предложенный вами вариант.
                                                                                            0
                                                                                            Да какая разница. То, что у них там в бумажке нарисовано как distribution-block — это и есть моя схема выше. L3 на самых нижних коммутаторах класса c2960/ex2200 — это глупость. А на следующем звене (c3750/ex4200) — самое то. Девяноста пяти процентам компаний больше звеньев и не надо: на двухуровневой гирлянде можно весьма красиво собрать до пары тысяч пользовательских портов, куда больше-то. Ну, если надо больше, то таки да, в зависимости от задачи может быть либо L2 наверх, либо сразу L3.

                                                                                            У провайдеров никакого L3 не может быть (хотя у нас это одна из форм описанной выше болезни индустрии). В корпоративных же сетях L3 обычно плохо, т. к. ACL на свичах поддерживать — гиблое дело. На Juniper можно красивые масштабируемые решения сделать, чтоб и L3, и подсети между собой не ходили (только туда, куда надо), а на Cisco — вроде нет. До недавних пор по крайней мере PBR'ом точно нельзя было пользоваться для этих целей. Плюс, либо надо на L3-свичах BGP (что или дорого, или вообще не бывает), либо пользовательские сети прям OSFP анонсировать, что тоже имеет ряд минусов. В любом случае, все это не вендорно-независимо, не очень гибко и либо довольно сложно в поддержке и траблшутинге, либо немасштабируемо. Короче, no silver bullet.
                                                                                              0
                                                                                              Если мы говорим о трёх уровневой иерархической модели, то это модель для построения кампусных сетей, а не операторских. К тому же операторов тоже надо разделять. И что значит «У провайдеров никакого L3 не может быть»? Еще как может. В данном случае не принциально вырожденная двухуровневая модель с совмещенным уровнем ядра/распределения или трехуровневая модель, Routed Access Layer применим в обоих случаях.

                                                                                              У Cisco есть Catalyst 6500 VSS, который позволяет организовать предложенную вами схему.
                                                                                                0
                                                                                                >Если мы говорим о трёх уровневой иерархической модели, то это модель для построения кампусных сетей, а не операторских.

                                                                                                Ну да. Просто в бумажке, на которую вы дали ссылку, предполагается L3 между вторым и первым (типа, ядром) уровнями гирлянды (routed access layer или как оно там). В жизни (кампусной, ага, сети) это слишком сильное упрощение, так не бывает. Во-первых нужна фильтрация, которую такое решение очень затрудняет, во-вторых — обычно требуется возможность проброса VLAN'ов (тот же голос) по всей сети.

                                                                                                Плюс, я хотел сказать, что три уровня иерархии свичей — это весьма и весьма крупный кампус (не первые тысячи пользовательских портов). В большинстве случаев обычно достаточно двух уровней. Но если нужно три, то механизмов реализации сегодня уже предостаточно, в т. ч. даже допускающих мультивендорность, я с этим и не спорю. И вообще нигде речь не шла, что, скажем, Juniper или какой-то другой вендор в рассматриваемой области предлагает что-то принципиально прям иное (QFabric vs Trill оставим за скобками, это про другое).

                                                                                                Собственно, по-моему у нас с вами спору-то в этой части нету.

                                                                                                >И что значит «У провайдеров никакого L3 не может быть»?

                                                                                                На доступе не может. Особенно, если ШПД для физлиц, впрочем, и юриков тоже так не наагрегируешься. Ну, то есть, в жизни, конечно, еще не то может, особенно в наших краях (весьма популярный способ, да), но это противоречит всему, чему можно противоречить. Несколько тысяч абонентов, и все, привет, дальше не масштабируется. Исключением можно считать, пожалуй, пакетную подсистему сетей мобильных операторов, но там это обстоятельство тянет за собой неслабое количество архитектурных примочек и стоит соответствующих денег.
                                                                                            0
                                                                                            Странно, что никто не вспомнил про такой стремительно набирающий популярность протокол, как Ethernet Automatic Protection Switching. Исключительно хорошая штука, замечательная своей скоростью сходимости.
                                                                                              0
                                                                                              Такая штука есть у многих вендоров, производящих metro-оборудование.
                                                                                                0
                                                                                                О чём и речь :)
                                                                                                0
                                                                                                Я вспомнил, но пока вспоминал название, пока искал линк на описание, пока проверял, что напишу не боян — вы меня опередили. От себя замечу, если в простых конфигурациях что-то и отправит на свалку STP, то ИМХО как раз решения типа EAPS, ибо почти то же самое, в плане стабильности, делают на порядок проще и быстрее.
                                                                                                  0
                                                                                                  А чем это от ethernet ring protection отличается?

                                                                                                  Ну, собственно, да. Но это для небольших провайдеров штука, плюс по-моему там же обязательно должны быть кольца. Или нет? Да и утверждение о том, что оно есть везде, где хошь, по-моему немножко излишне оптимистично. В том-то, блин, и дело, что метро-эзернета толком в америке не бывает. А раз так, то все там на это смотрят сквозь пальцы. На китайцах все надежда, но на них одних, скажем честно, далеко не уедешь.
                                                                                                    0
                                                                                                    А это он и есть :) Просто у разных производителей по разному называется, но в RFC всё же пошёл под этим названием.
                                                                                                    В Америке много чего нет, даже 220 вольт в розетке, и то нет :D А для построения колец, да на десятке (10GbE), в пределах города милое дело (и дешевле, чем MPLS'ое городить).
                                                                                                      0
                                                                                                      Это правда, только
                                                                                                      а) где же такое счастье и почем? :)
                                                                                                      б) к сожалению нишево это очень. Для юрлиц VPN там и т. д. — боюсь, это весьма условно можно назвать провайдерским решением. Ethernet-кольца — удел в первую очередь ШПДшников, там это по понятным причинам оправдано. Но что-то я сильно сомневаюсь, что бывают свичи с ринг-протекшеном, которые не жалко в подъезд поставить.
                                                                                                        0
                                                                                                        Мы взяли Extreme x450 и x480, а так вообще ERPS есть даже в DLink DGS-3627G и DES-3200 — предельно дешёвых (для данного уровня) железяк.
                                                                                                  +1
                                                                                                  STP, не STP, а в логотипе senetsy наблюдается красивое дерево)
                                                                                                    0
                                                                                                    Что вы будете делать без STP если вы оператор и подключаете L2 клиентов (ex: Internet Exchange), которые могут иметь между собой линки (L2)?
                                                                                                      0
                                                                                                      Буду читать второе предложение статьи со слов «то как минимум» :) Еще есть дурацкие способы LDP VPLS-мультихоминга, например.
                                                                                                        –1
                                                                                                        я буду радоваться :) потому как я как провайдер просто отдаю трубу, у этих клиентов случится броадкаст-шторм и в какой-то момент моя труба загрузиться на всё 100% и я как оператор их с удовольствием протарифицирую :)
                                                                                                          0
                                                                                                          На IX вряд ли вам это удастся. Со всех точек зрения. Так что, спорный вопрос, кто кого протарифицирует )
                                                                                                          0
                                                                                                          Кстати, а где такие IX, на которых разрешают больше одного мака на порту?
                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь

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

                                                                                                          Самое читаемое