Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 152
На самом деле это всё здорово в «сферическом вакууме», а в реальности во многих организациях такой «зоопарк» из устройств, что ни о какой агрегации речи и быть не может. Так что заголовок очень громкий, но с реальностью не сильно связан, потому как STP универсален между железками и свои задачи — «резать петли» и находить кратчайшие пути выполняет очень даже неплохо.
Хотя… учитывая что речь идёт о гигабитных каналах (да и ценовую категорию железок я по ссылкам посмотрел), там железо думаю более унифицированно.
Главное предназначение, как я понял это из статьи, крупные сети предприятий. А на многих крупных предприятиях сети проектируются, а не «лепятся и того что было». Таким образом вся L2-среда будет унифицированной. Ведь ни один нормальный босс не согласится тратить кучу денег на умные коммутаторы, которые будут использоваться как тупые. Конечно, все это при условии наличия грамотного админа в штате)
LAG — по-моему не очень хорошее название для сетевой технологии. Не хотеть, что у меня что-то ЛАГало.
Обычно «кластеризация» коммутаторов довольно расточительное занятие, так как фактически думает за всех мастер (следовательно кластер по всем ТТХ и ограничениям будет равен ТТХ мастера), а все остальные члены кластера всего лишь «удлинители портов». Во вторых при «кластеризации» чаще всего требуются одинаковые модели, ревизии устройств и даже версии FW.
По поводу STP его реально использовать на уровне агрегации, и абсолютно не рекомендуется на уровне доступа, в противном случае абонент с неисправной (моргающей) сетевой картой устроит вам небольшой армагедонец в рамках STP ветки.
По поводу STP его реально использовать на уровне агрегации, и абсолютно не рекомендуется на уровне доступа, в противном случае абонент с неисправной (моргающей) сетевой картой устроит вам небольшой армагедонец в рамках STP ветки.
Поподробнее о сетевой плате клиента можно?
Не только моргающая сетевая плата, а также закольцованный абонентский свитч к примеру. И тут неплохо, чтобы оборудование уровня доступа имело нормально работающий механизм типа loopdetect, тогда с этим проблем не будет.
Блокирование BPDU с портов доступа еще никто не отменял.
Про «мастер» — вы почти правы. Не совсем — в части «удлинителя портов». Все же не удлинителя — свичи в кластере работают как свичи, то есть коммутируют, принимают решения о передачи кадров дальше. Примерно как карты в больших коммутаторах. Просто таблица коммутации пересчитывается под каждый конкретный свич, с учетом его кластерных портов. Внутри обычно работает нечто вроде протокола маршрутизации. Даже не нечто, а в случае, например Juniper EX, это прям ISIS, к которому дописали нужный TLV. То есть с точки зрения производительности все отнюдь не упирается в производительность одной коробки.
С токи зрения масштабирования — как правило да. Хотя есть например исключение в виде Juniper QFabric, но это слишком уж отдельный случай. Из за этого ограничения по масштабированию разного рода таблиц, в первую очередь таблицы MAC-адресов, кластеризация — сомнительный механизм, чтоб строить на ней прям сети. Впрочем об этом в статье сказано. В корпоративных же сетях лимит в 16 тыс. MAC'ов — как правило достаточно высокая планка. Если нет, то скорее всего кольца с STP все равно не спасут.
Ну и да. Не всегда нужны одинаковые модели. Juniper EX4200 кластеризуется с EX4500. Причем внутри 4200 модели могут быть какие угодно. 24-портовые, 48, медные оптические, с PoE, без и пр. Brocade FCX — аналогично. За 3750 не помню, но кажись и там можно объединять разные 3750 в стек. Софт, да, везде нужен одинаковый.
С токи зрения масштабирования — как правило да. Хотя есть например исключение в виде Juniper QFabric, но это слишком уж отдельный случай. Из за этого ограничения по масштабированию разного рода таблиц, в первую очередь таблицы MAC-адресов, кластеризация — сомнительный механизм, чтоб строить на ней прям сети. Впрочем об этом в статье сказано. В корпоративных же сетях лимит в 16 тыс. MAC'ов — как правило достаточно высокая планка. Если нет, то скорее всего кольца с STP все равно не спасут.
Ну и да. Не всегда нужны одинаковые модели. Juniper EX4200 кластеризуется с EX4500. Причем внутри 4200 модели могут быть какие угодно. 24-портовые, 48, медные оптические, с PoE, без и пр. Brocade FCX — аналогично. За 3750 не помню, но кажись и там можно объединять разные 3750 в стек. Софт, да, везде нужен одинаковый.
Использовать STP на уровне агрегации — безумие. Единственное место где его можно сейчас использовать — уровень доступа. Отключение кольца доступа на 7-10 секунд ещё можно пережить, но вот отключение уровня — агрегации на такое время уже может быть причиной увольнения :).
Статья хорошая, но заголовок жёлтый.
Я как только прочитал заголовок вспомнил как работал в одном здании где сидело 2000 человек. А админы, ради оптимизации отключили Spaning Treee. А какой-то умник в одной из комнат для совещаний, воткнул пачкорд из одной розетки в другую. Было довольно велосело наблюдать, как сеть рухнула, а админи бегали по зданию и бились головой ап стенки пытаясь понять причину ))
Заголовок реально желтый. Также автор забыл упомянуть что с помощью stp можно очень красиво балансировать на l2, в случае если у вас не хилое кольцо из l2 коммутаторов, или просто не используется маршрутизация.
Да вот не очень-то и красиво. Уж с LAG точно не сравнить. Вообще, пожалуй, про балансировку нужно будет написать отдельно.
Что касается «нехилых колец из коммутаторов» с STP, столько популярных в нашей стране, — наш дружный коллектив уверен, что это чистой воды жуть с ружьем. Дешево и сердито, конечно, но как раз вот про тех, кто может писать в спортоло прошение о награде.
Что касается «нехилых колец из коммутаторов» с STP, столько популярных в нашей стране, — наш дружный коллектив уверен, что это чистой воды жуть с ружьем. Дешево и сердито, конечно, но как раз вот про тех, кто может писать в спортоло прошение о награде.
Отчего не красиво: есть у нас 10 коммутаторов доступа, которые никогда не слышали о лагах :):):) о LAG конечно же :) Обоими концами соединяем его с агрегацией, которая root и вуаля)
Почему так? Ну потому что когда таких коммутаторов тысячи каждая копейка важна, и тут уж не до LAGа, тем более что некрасивость stp больше из пальца высосана. Потеря 1-2 пингов у 50% клиентов этого кольца пока дерево перестроится — это не проблема. ИМХО.
Почему так? Ну потому что когда таких коммутаторов тысячи каждая копейка важна, и тут уж не до LAGа, тем более что некрасивость stp больше из пальца высосана. Потеря 1-2 пингов у 50% клиентов этого кольца пока дерево перестроится — это не проблема. ИМХО.
Ну, в общем, да, только… habrahabr.ru/blogs/network_technologies/132312/#comment_4415722
В общем у нас разные масштабы :) У вас решения для пары человек, у меня для пары сотен тысяч и т.д. :)
Ну тогда, вам в ООН за наградой :) Хотя plain ethernet для провайдерских сетей — это, к сожалению, наша большая боль. Больше только netflow для биллинга.
Коллеги из какой-нибудь Америки вообще сначала не понимают, о чем речь, когда с ними разговаривают о кольцах с STP. Когда понимают — хватаются за голову, мол, дикая страна.
Коллеги из какой-нибудь Америки вообще сначала не понимают, о чем речь, когда с ними разговаривают о кольцах с STP. Когда понимают — хватаются за голову, мол, дикая страна.
И как же они строят сети?
Н-р сайт cisco.com, включая все их презентации и прочее очень даже знает о stp
Н-р сайт cisco.com, включая все их презентации и прочее очень даже знает о stp
Стягивают тот или иной первый уровень (xDSL или xPON, если ШПД для физлиц или прям оптический ethernet, если юрлица) от абонента/клиента в крупные узлы (АТС всю жизнь у нас это называлось), в которых ставят не говнохабы по три копейки, а нечто взрослое. Это взрослое либо (победнее) собирают гирляндой с (раньше с минимумом STP, теперь все больше как описано выше), либо подключают к IP/MPLS сети на базе псевдопроводов или VPLS.
Собственно, это написано в любом учебнике, так всю жизнь делали и у нас (см. классическую телефонию или Стрим). И, конечно, понятно, с чем связаны сложности организации нормальной инфраструктуры сетей доступа у нас. Поэтому, да, весь этот говнометроэзернет с STP лезет из всех щелей. Только из этого не следует, что так надо делать. Это у нас такая болезнь индустрии.
STP, как многократно уже было сказано, никто не отменял. Но только, если тот или иной продукт поддерживает STP, это не значит, что им нужно обставлять полрегиона, соединять абы как (как сможете линии проложить или любымими кольцами), включать STP и ждать счастья. Не случиться, к сожалению.
Собственно, это написано в любом учебнике, так всю жизнь делали и у нас (см. классическую телефонию или Стрим). И, конечно, понятно, с чем связаны сложности организации нормальной инфраструктуры сетей доступа у нас. Поэтому, да, весь этот говнометроэзернет с STP лезет из всех щелей. Только из этого не следует, что так надо делать. Это у нас такая болезнь индустрии.
STP, как многократно уже было сказано, никто не отменял. Но только, если тот или иной продукт поддерживает STP, это не значит, что им нужно обставлять полрегиона, соединять абы как (как сможете линии проложить или любымими кольцами), включать STP и ждать счастья. Не случиться, к сожалению.
Вы коллегам из какой-нибудь Америки напомните, что они ещё у себя ATM и FrameRelay изжить не могут, так чта нечего тут хвататься за голову. ;)
ATM у нас тоже жив. У Ростелекома какого-нибудь его навалом в регионах. Пока работает, чего его изживать-то.
М-м-м, дайте догадаюсь, как он у них появился...«слушайте, у нас тут 72ая циска не может прожевать больше 3 Гбит езернета, может, ещё чо воткнём в неё?» ;)
Не, правда, в чём смысл его существования, особенно сейчас? Он устарел ещё 10 лет назад, в США тянется тяжким наследием горы закупленного оборудования и необходимого ROI, а у нас-то откуда?
Не, правда, в чём смысл его существования, особенно сейчас? Он устарел ещё 10 лет назад, в США тянется тяжким наследием горы закупленного оборудования и необходимого ROI, а у нас-то откуда?
Да ни в чем, кром етого, что его надо чем-то заменять. Есть присутствие MPLS-магистрали в крупных городах региона. И есть ATM-акцесс, которым они дотягиваются до клиентов в соседних р-нах и т. д. Собственно, чем его заменять? Кольцами скажете с ринг-проекшеном? Сомневаюсь. А MPLS потихоньку дотягивается на районные узлы, становится, извиняюсь за грубое слово, seamless — ATM выкидывают.
Так это и называется тяжкое наследство. Если бы строились с нуля, то ой как сомневаюсь в появлении MPLS. Я знаю по Питеру только ситуацию, конечно, так тут проще волокно под 10GbE взять, чем городить MPLS и Ethernet over MPLS схемы при исчерпании пропускной способности. :)
Ну, вашу нелюбовь к MPLS мы уже обсуждали :) Правда я не понял про «если б строились с нуля». MPLS у них вроде с нуля, думаю, ATM тоже в свое время был с нуля.
Просто еще города с плотностью населения как в Питере — это одно, а какая-нибудь республика Коми — это трошки совсем другое.
Просто еще города с плотностью населения как в Питере — это одно, а какая-нибудь республика Коми — это трошки совсем другое.
В Питере, чего не построй, все продать можно, если продавать уметь.
MPLS железки класса MX80, которые можно поставить в районный городишко — они ж вот только появились. А на кольца переходить, видно, очень уж не хотелось (что правильно).
Бред. Как без spanning-tree вы сможете подключить свичи несколькими патчами и заставить по одним транкам гонять половину vlan, а половину по другим, при этом если одна половина транков падает, то включается вторая и через оставшуюся половину ходит снова весь трафик.
LAG — прекрасное дополнение, но только дополнение. И по большей части прекрасное для избыточности подключения серверов.
LAG — прекрасное дополнение, но только дополнение. И по большей части прекрасное для избыточности подключения серверов.
Ну это и есть та самая балансировка, о которой я выше писал…
>как без spanning-tree вы сможете подключить свичи несколькими патчами и заставить по одним транкам гонять половину vlan, а половину по другим,
STP для балансировки нужен только в этих самых наших любимых метро-кольцах, которые сами по себебред специфическая область, выходящая за рамки статьи. В корпоративных же сетях и прочих классических применениях plain ethernet-форвадинга, LAG для балансировки по любым показателям лучше STP.
STP для балансировки нужен только в этих самых наших любимых метро-кольцах, которые сами по себе
Пока в сети будет пара портов, на которых не включен STP — такую сеть можно положить. Не важно — корпоративная это сеть или уровня провайдера. Так что говорить о умирании STP можно только на сетях, в которых доступ к каждому порту контролируется физически.
«Кроме того, Spanning Tree, хоть и теряет свою актуальность как механизм построения отказоустойчивой топологии и балансировки, но, как уже было сказано, остается актуальным способом защиты от человеческой ошибки. Поэтому, если, например, на коммутаторе включен по умолчанию протокол RSTP или PVST+, не стоит его выключать, если только вы не уверены, что знаете точно, зачем именно. Желательно также, чтоб на всех коммутаторах использовался один протокол, но это уже совсем другая история.»
Мне кажется, уважаемый автор путает мягкое (STP — протокол в основном для L2-резервирования) и тёплое (агрегация линков, EtherChannel — протокол в основном для увеличения пропускной способности). Они друг другу не враги и не конкуренты, а при грамотной настройке — лучшие друзья.
Статья хороша тем, что повествует нам в принципе о таких вещах как агрегация линков и кластеры из коммутаторов. За это плюс. Даже в карму автору.
Статья плоха тем, что сравниваются несравнимые вещи. За это минус статье.
Статья хороша тем, что повествует нам в принципе о таких вещах как агрегация линков и кластеры из коммутаторов. За это плюс. Даже в карму автору.
Статья плоха тем, что сравниваются несравнимые вещи. За это минус статье.
etherchannel как средство увеличения пропускной способности — довольно кривая штука, в случае с ec 1+1!=2, к сожалению. и, к слову, в большинстве курсов cisco, напирмер, ec используется для failover-а.
1+1 как раз 2.
другое дело что пропорции меняются когда кол-во физических каналов в езерчанеле иное.
другое дело что пропорции меняются когда кол-во физических каналов в езерчанеле иное.
похоже, что в матчасти вы не разбираетесь. вот вам простая картинка:
2 свитча соединены между собой 2мя линками 100Mbps собранными в EthChan. К каждому свитчу подключено по серверу, через 1Gbps (щас уже 100Mb сервера-та не найдешь уже). Копируем файлик с одного сервера на второй. Внимание, вопрос — до какой скорости разгонится передача файла между серверами?
2 свитча соединены между собой 2мя линками 100Mbps собранными в EthChan. К каждому свитчу подключено по серверу, через 1Gbps (щас уже 100Mb сервера-та не найдешь уже). Копируем файлик с одного сервера на второй. Внимание, вопрос — до какой скорости разгонится передача файла между серверами?
Хехе. Кто еще не разбирается.
В данном случае, не зависимо даже от того, какая у вас балансировка, будет 100.
Но воткните в каждый свитч по еще оному серверу, и тогда между свитчами у вас будет 200.
В данном случае, не зависимо даже от того, какая у вас балансировка, будет 100.
Но воткните в каждый свитч по еще оному серверу, и тогда между свитчами у вас будет 200.
вы таки понимаете, что я вам дал простой случай и даже тут вам пришлось что-то придумывать, чтоб добиться полной утилизации линка?
попробуйте добиться нормальной утилизации ethChan если у вас ещё есть в середине роутеры и сервера у вас в разных подсетях.
попробуйте добиться нормальной утилизации ethChan если у вас ещё есть в середине роутеры и сервера у вас в разных подсетях.
Ответ не верный. Если бы мне надо было соединиться только 2 сервера, как нарисовано у вас, я бы их соединил гигабитом и не придумывал ничего (собственно, а что я придумал? Я ответил что будет 100). Но жизнь она иная, и в одном коммутаторе как правило больше 2 портов занято (включая аплинк), соответственно скорость поднимется выше 100.
Что значит нормальной? 50/50? В реальности — никогда, но лабораторными способами — легко и непринужденно. И кол-во роутеров тут будет не причем.
Т.о. я так и не понял что кривого в ec?
Что значит нормальной? 50/50? В реальности — никогда, но лабораторными способами — легко и непринужденно. И кол-во роутеров тут будет не причем.
Т.о. я так и не понял что кривого в ec?
нет у вас гигабита между двумя зданиями и всё, забудтье. даже в москве оператор связи часто говорит, что — гигабита нету, можем дать 3 по триста, берете?
вот в том и кривость ес, что в реальных условиях нормальной утилизации всех линков не добиться. и когда покупаются 3x300, то первый линк загружен под 100%, второй на 30-50%, а третий хорошо если на 10. и то, чтоб этого добиться надо танцевать с бубном :) например делать не просто тупой ethChan, а три L3 линка с динамикой, к примеру.
вот в том и кривость ес, что в реальных условиях нормальной утилизации всех линков не добиться. и когда покупаются 3x300, то первый линк загружен под 100%, второй на 30-50%, а третий хорошо если на 10. и то, чтоб этого добиться надо танцевать с бубном :) например делать не просто тупой ethChan, а три L3 линка с динамикой, к примеру.
вот так:
Гм. Вы видимо не до конца понимаете как оно работает.
Во всех ваших примерах у вас что src, что dst mac, ip, port будут в количестве одной штуки. Что здесь можно сбалансировать? Ну не умеет оно per-packet.
Во всех ваших примерах у вас что src, что dst mac, ip, port будут в количестве одной штуки. Что здесь можно сбалансировать? Ну не умеет оно per-packet.
я-то как раз прекрасно понимаю как оно работает. в том и заключается кривость ethChan, что оно очень ограниченно-применимо.
Как вы в данной схеме сможете загрузить 2х100?
извращенно исключительно.
сделать оба линка между маршрутизаторами именно L3 и маршрутизируемыми, навесить на оба линка равные веса. это уже будет балансирвока per-flow, что значительно лучше чем то, что есть у ethChan. а можно ещё включить per-packet и тогда совершенно хорошо получится.
второе — собрать их в бандл ppp-multilink, а он уже сам разберется, у ppp есть свой нормальный механизм packet fragmentation / interleaving.
сделать оба линка между маршрутизаторами именно L3 и маршрутизируемыми, навесить на оба линка равные веса. это уже будет балансирвока per-flow, что значительно лучше чем то, что есть у ethChan. а можно ещё включить per-packet и тогда совершенно хорошо получится.
второе — собрать их в бандл ppp-multilink, а он уже сам разберется, у ppp есть свой нормальный механизм packet fragmentation / interleaving.
Но свитчи-то де-юро L2 ;)
Эээ, нет. Вы неправы. LAG и ECMP на большинстве платформ балансируются одинаково. Либо одинаково хорошо, либо одинаково плохо. Везде сейчас per-flow (кроме MLPPP), вопрос только какие поля включать в хеш, и как приводить хеш к значению линка в LAG или NextHop при ECMP. Чем гибче этот функионал, тем выше цена.
Просто в сравнении со свичами маршрутизаторы — это обычно либо программная коробка, либо существенно более дорогое железо. В обоих случаях гибкость функионала выше. Поэтому вы фактически сраниваете не LAG vs ECMP, а функционал свичей класса C3750/EX4200 с функционалом тех же Cisco 6500/7600, Juniper MX или программными коробками. Да, C3750/EX4200 при данном сравнении заведо хуже балансируют, что при LAG, что при ECMP. Собственно, это одно из отличий больших L3-свичей от полноценных маршрутизаторов.
Просто в сравнении со свичами маршрутизаторы — это обычно либо программная коробка, либо существенно более дорогое железо. В обоих случаях гибкость функионала выше. Поэтому вы фактически сраниваете не LAG vs ECMP, а функционал свичей класса C3750/EX4200 с функционалом тех же Cisco 6500/7600, Juniper MX или программными коробками. Да, C3750/EX4200 при данном сравнении заведо хуже балансируют, что при LAG, что при ECMP. Собственно, это одно из отличий больших L3-свичей от полноценных маршрутизаторов.
Не подумайте, что я имел в виду, что функционал хеширования у MX и 6500/7600 сколько-нибудь сравним. 7600 в смысле гибкости балансировки ближе к 3750, чем к MX. Просто пример оборудования разных классов.
спасибо, я пробовал сделать per-flow в цыскиной реализации LACP/PaGP (пробовал и то и другое). как писал ниже — не взлетело.
я вобщем-то вообще ничего не сравниваю. я изначально говорю, что не надо так превозносить LAG, а сразу нужно говорить о его ограничениях. а то появляется очень много начнающих одминов которые смотрят на LAG (LACP/PaGP) как не серебрянную пулю, а потом ходят за дополнительным бюджетом либо на линк потолще, либо на железо потяжелее :( мне тут подобную схему с полгода назад пытались предложить коллеги из Англии, блин.
я вобщем-то вообще ничего не сравниваю. я изначально говорю, что не надо так превозносить LAG, а сразу нужно говорить о его ограничениях. а то появляется очень много начнающих одминов которые смотрят на LAG (LACP/PaGP) как не серебрянную пулю, а потом ходят за дополнительным бюджетом либо на линк потолще, либо на железо потяжелее :( мне тут подобную схему с полгода назад пытались предложить коллеги из Англии, блин.
А чем эта схема концептуально лучше-то?
Да-да-да. В черновиках давно висит текст про балансировку.
P. S. Передача файлов может быть и в несколько потоков :)
P. S. Передача файлов может быть и в несколько потоков :)
Тут написано «файла».
Если «файлов» и настроена балансировка по L4, то можно и за 100 выпрыгнуть.
Если «файлов» и настроена балансировка по L4, то можно и за 100 выпрыгнуть.
Один файл можно передавать в несколько потоков одновременно :)
Ну этого не было в условии :)
ещё в условии не было, что L4-балансинг у цыски нифига не работает. проверено на 3845 и 6509, ios 12.4.24 и 12.2.33SX
и ещё бывают не только файлы. попробуйте заставить любую СУДБ, Оракл, мускуль, мсскуль, реплицировать в несколько потоков, пожалуйста?
Понимаете, если что-то очень хочется обосрать, то это не составляет особого труда. Я не силен в СУБД, но догадываюсь что многопоточности там быть не может исходя из соображений целостности.
Собственно, непонятно, о чем дискуссия. Балансировка в 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'ов :)
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'ов :)
ещё вариант, как я написал уже выше — сделать несколько L3 каналов с равными весами маршрутизации и включить балансировку per-packet. если это не телеметрия от Фобос-Грунта, то нормально будет работать :)
Я там уже ответил :)
Сомневаюсь, что это универсально хорошо. Как способ решить конкретную проблему повышения емкости линка для конкретного приложения — может быть. А если для всего трафика пакеты одной TCP-сессии начнут ходить разными путями и потом пересобираться на получателе — сомневаюсь, что это круто. А уж если понадобится поверх этого CoS сделать, то ууу…
Сомневаюсь, что это универсально хорошо. Как способ решить конкретную проблему повышения емкости линка для конкретного приложения — может быть. А если для всего трафика пакеты одной TCP-сессии начнут ходить разными путями и потом пересобираться на получателе — сомневаюсь, что это круто. А уж если понадобится поверх этого CoS сделать, то ууу…
да не скажите, нормально там всё будет. если счет идет на сотни мегабит, то tcp вообще ничего не заметит, а джиттер из-за параллельных веток будет не такой страшный, чтоб пакеты умерли в деджиттер буффере телефона :)
да, две ветки дискуссии — у меня уже шизофрения развивается :)
Статьи так и не появилось или я её пропустил?
В дополнение: цисковские пропорции
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
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
На мой взгляд, все-таки LACP не является полноценной заменой STP (или другой технологии резервирования на L2). Подключение коммутатора уровня доступа к двум коммутаторам агрегации (или коммутатора агрегации к двум коммутаторам ядра), расположенным на одной площадке не обеспечивает необходимого уровня резервирования.
Кроме того, мало что сказано об одном из основных недостатков STP — высоком времени сходимости
Кроме того, мало что сказано об одном из основных недостатков STP — высоком времени сходимости
Непонятно, почему на одной площадке. Пожалуйста, на двух, если надо.
Проглядел в статье упоминание о кластеризации поверх Ethernet. Интересно было бы почитать об этом
Там (в статье) например даже такая ссылка есть. www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pdf
Собственно, ничего особенного в кластеризации через ethernet нету. Это не новость совсем. Просто обычный порт указывается в конфиге как внутренний порт кластера и всего делов. Внутренняя логика (в случае Juniper'а, скажем, это протокол ISIS) включает его в топологию с соответствующим весом — и вперед.
Собственно, ничего особенного в кластеризации через ethernet нету. Это не новость совсем. Просто обычный порт указывается в конфиге как внутренний порт кластера и всего делов. Внутренняя логика (в случае Juniper'а, скажем, это протокол ISIS) включает его в топологию с соответствующим весом — и вперед.
Чего-чего у Juniper ISIS?
Под virtual chassis внутри лежит ISIS. Да, да. И не только у Juniper, насколько я понимаю. Именно он строит топологию и считает кратчайшие пути между интерфейсами. В QFabric помимо этого еще и BGP заточили для анонса MAC-адресов (ага-ага, куда катится мир). Хотя у Cisco тоже есть какое-то датацентровое решение, где они биджипней маки анонсируют.
А где почитать можно? Чего-то я не помню, чтобы Juniper о таком писали.
В книжке «JUNOS Enterprise Switching» (в интернетах найти можно при желании). В CLI есть команда show virtual chassis чего-то там isis database и т. д. На каждом заборе, да, не написано, но никакого секрета в этом нет.
Эх, ошибся.
Слова ISIS там в явном виде нету, но по выводу, в общем, все понятно.
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 там в явном виде нету, но по выводу, в общем, все понятно.
Сколько слышал о высоком времени сходимости — но на практике не сталкивался ни разу. В основном работал с rapid-pvst, при физическом отключении линка ни один пинг не пропадал. Это я к тому, что теория теорией, но на практике вещь хорошая и нужная.
btw, spanning tree с аглицкого, отнюдь не ветвящееся дерево, а вовсе покрывающее или на крайний случай связующее. Хорош уже на STP обзываться :)
Пожалуй, вы правы. Недоглядели :)
Наиболее распространённый русский термин для spanning tree — остовное дерево (хотя его также иногда называют покрывающим деревом, остовом или скелетом графа): ru.wikipedia.org/wiki/Остовное_дерево
Объясните, пожалуйста, как можно говорить, что LAG замена STP и STP морально устаревает, если для реализации LAG необходимо дублировать каждый линк? Возьмем упоминаемый вами в статье MetroEthernet — вы представляете продублировать каждый линк? Да, оптика кладется не одножильная, но себестоимость линка увеличивается в 2 раза, так как надо отдать дополнительные две (или в случае с WDM — одну) жилы. А если коммутаторы не имеют оптических портов (а это далеко не фантастика, мне доводилось работать в телекомах) — дополнительные медиаконвертеры это также дополнительные затраты.
Кластеризация это хорошо, за информацию за неё спасибо, однако хотелось бы увидеть отдельную статью, посвященную именно кластеризации. Особенно интересует кластеризация посредством GigabitEthernet, а не PCI.
За статью скорее плюс, читать было легко и приятно.
Кластеризация это хорошо, за информацию за неё спасибо, однако хотелось бы увидеть отдельную статью, посвященную именно кластеризации. Особенно интересует кластеризация посредством GigabitEthernet, а не PCI.
За статью скорее плюс, читать было легко и приятно.
Есть такая штука, как multichassis etherchannel — причем она есть отнюдь не тольо у цыски. автор привел хороший линк на документ от Juniper. Так вот в случае с MC-LAG (multichassis links aggregation) — нет необходимаости дублировать каждый линк. Можно треугольничками, можно колечками.
Я вас правильно понял? Три коммутатора соединяются в треугольник (кольцо), линки не дублируются, при этом для защиты от петель используется не STP, а MC-LAG? Какое преимущество такого способа построения перед STP? Про время сходимости прошу не упоминать, rapid-pvst работает достаточно быстро.
да, вы меня совершенно правильно поняли. преимущество — автоматическая балансировка нагрузке в каналах MC-LAG. Вобщем с STP тоже можно балансировать нагрузку раскидав виланы по разным линкам, но во-первых, нужны виланы, а он может быть и всего один, а во-вторых это руками надо делать. MC-LAG это сделает сам и автоматически. опять же, отлаживать проблемы на ethChan проще, чем с stp.
а если используется не просто EthChan, а вендор-специфичная технология — то ещё и виртуализации добиться можно. Всмысле, когда все железки будут выглядеть как будто одна. Цыскин VPS, у Juniper своя технология, не помню названия
а если используется не просто EthChan, а вендор-специфичная технология — то ещё и виртуализации добиться можно. Всмысле, когда все железки будут выглядеть как будто одна. Цыскин VPS, у Juniper своя технология, не помню названия
Поизучаю на досуге, спасибо.
Посмотрел по интернету… насколько я понял, MC-LAG это удел тяжеловесов? 7600, ASR 9000 и т.д.? Тогда уж извольте, это никак не конкурент. STP работает на, не побоюсь этого сказать, самых популярных 29xx Catalyst, на коммутаторах иных производителей. Так что, закидайте меня камнями, но пока хоронить STP еще рано.
Простите за оффтоп, но в чём вы такие красивые схемы рисуете?
Любой векторный редактор. В данном случае OpenOffice Draw. Библиотека иконок — в ней весь секрет, ее Juniper дает только тем, кому надо :)
И ещё один оффтоп — у вас замечательный фак по МХам, только сегодня как раз прочитал.
Пора, кстати, чуточку его проапдейтить в связи с выходом MX5/10/40 и аки объявленной поддержкой IPFIX на Trio.
Будет интересно.
У нас, правда, MX240, до MX80 в своё время недотерпели.
IPFix хорош, конечно, тем что стандарт… и плох, что хочет Trio и не поддерживается flow-tools (как и Jflow и NetFlow v9, впрочем). Желающие, кстати, приглашаются проголосовать за них у проекта.
P.S. После работы с Juniper'ом не понимаешь, как такое УГ как IOS может вообще до сих пор существовать :) Видимо, только за счёт первокласснейшей документации.
У нас, правда, MX240, до MX80 в своё время недотерпели.
IPFix хорош, конечно, тем что стандарт… и плох, что хочет Trio и не поддерживается flow-tools (как и Jflow и NetFlow v9, впрочем). Желающие, кстати, приглашаются проголосовать за них у проекта.
P.S. После работы с Juniper'ом не понимаешь, как такое УГ как IOS может вообще до сих пор существовать :) Видимо, только за счёт первокласснейшей документации.
Поищите на просторах. маленький редактор — Dia называется. С ним в комплекте идёт парочка библиотек, с помощью которых я такие схемы летом рисовал.
Вот например
Вот например
Эх, после такого заголовка надеялся увидеть что-нибудь про TRILL, например. Вот это было бы действительно интересно.
Эмс… Не понятно, а почему кластеризация это отменяет STP? У нас вот стоят на суперкомпьютерах InfiniBand-овские кластерные коммутаторы, и в них специально сделаны кольца (самими производителями), чтобы и надёжнее было и балансировка нагрузки была эффективнее — это слова изофициального объяснения в документации. Ну, и маршруты по этим кольцам строятся при помощи нескольких вариантов STP.
Я не специалист по сетям, поэтому интересно было бы понять, кто не прав?
Я не специалист по сетям, поэтому интересно было бы понять, кто не прав?
Поскольку модель ВОС (она же ISO/OSI, если вам так больше нравится) забыла наделить канальный уровень
Согласно ГОСТ 24402-88, в котором описана ВОС, этот уровень называется Уровень звена данных, а Канальный уровень — недопустимое название.
Канальный уровень есть в стеке TCP/IP.
Работаю в крупном забугорном провайдере. Есть привычка разносить ядро по разным ДЦ. Кластеризовать их очень неудобно в этом режиме
Ну в ядре-то и без кластеров не должно быть никакого STP.
В прицнипе, достаточно кластеризовать устройства ниже по иерархии и соединять их с ядром при помощи RTG. Это как LAG, только всегда active-passive. Тогда в ядре не нужно кластеризации. Собственно, так и делают часто: все-таки большие модульные свичи только-только стали кластеризоваться.
Приятель просил задать вопрос.
Не могли бы вы чуть подробнее рассказать о режимах LACP? Давно занимаюсь аггрегацией каналов внутри небольшого провайдера, но нигде ни разу не встречал толкового описания разницы: когда, например, у меня есть два линка между двумя свитчами. В первом случае я на свитче1 настраиваю оба порта «активными» на свитче2 оба порта «пассивными». Во втором на свитче1 и свитче2 все порты «активные».
Не могли бы вы чуть подробнее рассказать о режимах LACP? Давно занимаюсь аггрегацией каналов внутри небольшого провайдера, но нигде ни разу не встречал толкового описания разницы: когда, например, у меня есть два линка между двумя свитчами. В первом случае я на свитче1 настраиваю оба порта «активными» на свитче2 оба порта «пассивными». Во втором на свитче1 и свитче2 все порты «активные».
Active — первый инициализирует LACP и шлет negotiation пакеты.
Passive — ожидает установление LACP, и пока не получит negotiation от Active в группу он не войдет и будет работать как обычный порт.
То есть получается ведущий и ведомый.
Passive — ожидает установление LACP, и пока не получит negotiation от Active в группу он не войдет и будет работать как обычный порт.
То есть получается ведущий и ведомый.
И в связке Active-Active они оба шлют пакеты и оба готовы установить соединение. Но такой вариант, мне кажется, несколько неправильным.
Циска рекомендует именно этот вариант
www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_example09186a0080094470.shtml#background
www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_example09186a0080094470.shtml#background
Про active и passive теорию я знаю. Интересуют именно различия в работе при разных настройках.
Автор писал, что в режиме "«активный–пассивный»: пока один линк в «апе», второй в «дауне», при падении основного происходит переключение на резервный." То есть, если у меня будет настроено так: свитч1 — LACP-active (два порта по 100мбит), свитч2 — LACP-passive (два порта по 100мбит), то трафик свыше 100мбит не пройдет, т.е. второй канал будет только как резерв включаться?
Автор писал, что в режиме "«активный–пассивный»: пока один линк в «апе», второй в «дауне», при падении основного происходит переключение на резервный." То есть, если у меня будет настроено так: свитч1 — LACP-active (два порта по 100мбит), свитч2 — LACP-passive (два порта по 100мбит), то трафик свыше 100мбит не пройдет, т.е. второй канал будет только как резерв включаться?
Там автор (то есть я :) еще писал, что не надо путать LAG и LACP. LAG в решиме active/active или active/passive — это то, что вы процитировали. А LACP в режиме active или passive — это то, о чем lumenous (либо устройство слушает и шлет LACP-пакеты, либо только слушает). Совершенно не имеющие отношения друг к другу вещи. Собственно, я бы вам рекомендовал просто разобраться, что такое LACP, зачем он нужен, и вообще нужен ли, тогда и про режимы его работы будет понятно.
Насчёт ненужности это сильно сказано в заголовке. Помнится, была у нас одна железяка сборная, в которой как раз пытались сделать кластеризацию, т.е. две карточки — свичи, третья — клиент — соединяется с обоими свичами. Замаялись, в итоге плюнули на всё, сделали RSTP с прицелом на MSTP и все счастливы.
Все это красиво и замечательно. Но каменный цветок разрушается как только у Juniper EX отъедут мозги и кольцо развалится, пытался высмотреть в статье методы защиты от split-brain, но не нашел. Это замечание следует считать руководством к действию, коллеги :-).
При желании можно избавиться от STP с переходом на Routed Access Layer. Универсальное (вендор-независимое) решение. В большинстве случаев на уровне доступа используются свитчи Cisco Catalyst 2960, 3560, 3750 и реже 45хх — кроме 3750 ни один не поддерживает кластеризацию. Несмотря на уменьшение доли рынка ethernet коммутаторов Cisco, еще в 2010 году они составляли более 73.1%, а следовательно далеко не все могут позволить себе предложенный вами вариант.
Да какая разница. То, что у них там в бумажке нарисовано как distribution-block — это и есть моя схема выше. L3 на самых нижних коммутаторах класса c2960/ex2200 — это глупость. А на следующем звене (c3750/ex4200) — самое то. Девяноста пяти процентам компаний больше звеньев и не надо: на двухуровневой гирлянде можно весьма красиво собрать до пары тысяч пользовательских портов, куда больше-то. Ну, если надо больше, то таки да, в зависимости от задачи может быть либо L2 наверх, либо сразу L3.
У провайдеров никакого L3 не может быть (хотя у нас это одна из форм описанной выше болезни индустрии). В корпоративных же сетях L3 обычно плохо, т. к. ACL на свичах поддерживать — гиблое дело. На Juniper можно красивые масштабируемые решения сделать, чтоб и L3, и подсети между собой не ходили (только туда, куда надо), а на Cisco — вроде нет. До недавних пор по крайней мере PBR'ом точно нельзя было пользоваться для этих целей. Плюс, либо надо на L3-свичах BGP (что или дорого, или вообще не бывает), либо пользовательские сети прям OSFP анонсировать, что тоже имеет ряд минусов. В любом случае, все это не вендорно-независимо, не очень гибко и либо довольно сложно в поддержке и траблшутинге, либо немасштабируемо. Короче, no silver bullet.
У провайдеров никакого L3 не может быть (хотя у нас это одна из форм описанной выше болезни индустрии). В корпоративных же сетях L3 обычно плохо, т. к. ACL на свичах поддерживать — гиблое дело. На Juniper можно красивые масштабируемые решения сделать, чтоб и L3, и подсети между собой не ходили (только туда, куда надо), а на Cisco — вроде нет. До недавних пор по крайней мере PBR'ом точно нельзя было пользоваться для этих целей. Плюс, либо надо на L3-свичах BGP (что или дорого, или вообще не бывает), либо пользовательские сети прям OSFP анонсировать, что тоже имеет ряд минусов. В любом случае, все это не вендорно-независимо, не очень гибко и либо довольно сложно в поддержке и траблшутинге, либо немасштабируемо. Короче, no silver bullet.
Если мы говорим о трёх уровневой иерархической модели, то это модель для построения кампусных сетей, а не операторских. К тому же операторов тоже надо разделять. И что значит «У провайдеров никакого L3 не может быть»? Еще как может. В данном случае не принциально вырожденная двухуровневая модель с совмещенным уровнем ядра/распределения или трехуровневая модель, Routed Access Layer применим в обоих случаях.
У Cisco есть Catalyst 6500 VSS, который позволяет организовать предложенную вами схему.
У Cisco есть Catalyst 6500 VSS, который позволяет организовать предложенную вами схему.
>Если мы говорим о трёх уровневой иерархической модели, то это модель для построения кампусных сетей, а не операторских.
Ну да. Просто в бумажке, на которую вы дали ссылку, предполагается L3 между вторым и первым (типа, ядром) уровнями гирлянды (routed access layer или как оно там). В жизни (кампусной, ага, сети) это слишком сильное упрощение, так не бывает. Во-первых нужна фильтрация, которую такое решение очень затрудняет, во-вторых — обычно требуется возможность проброса VLAN'ов (тот же голос) по всей сети.
Плюс, я хотел сказать, что три уровня иерархии свичей — это весьма и весьма крупный кампус (не первые тысячи пользовательских портов). В большинстве случаев обычно достаточно двух уровней. Но если нужно три, то механизмов реализации сегодня уже предостаточно, в т. ч. даже допускающих мультивендорность, я с этим и не спорю. И вообще нигде речь не шла, что, скажем, Juniper или какой-то другой вендор в рассматриваемой области предлагает что-то принципиально прям иное (QFabric vs Trill оставим за скобками, это про другое).
Собственно, по-моему у нас с вами спору-то в этой части нету.
>И что значит «У провайдеров никакого L3 не может быть»?
На доступе не может. Особенно, если ШПД для физлиц, впрочем, и юриков тоже так не наагрегируешься. Ну, то есть, в жизни, конечно, еще не то может, особенно в наших краях (весьма популярный способ, да), но это противоречит всему, чему можно противоречить. Несколько тысяч абонентов, и все, привет, дальше не масштабируется. Исключением можно считать, пожалуй, пакетную подсистему сетей мобильных операторов, но там это обстоятельство тянет за собой неслабое количество архитектурных примочек и стоит соответствующих денег.
Ну да. Просто в бумажке, на которую вы дали ссылку, предполагается L3 между вторым и первым (типа, ядром) уровнями гирлянды (routed access layer или как оно там). В жизни (кампусной, ага, сети) это слишком сильное упрощение, так не бывает. Во-первых нужна фильтрация, которую такое решение очень затрудняет, во-вторых — обычно требуется возможность проброса VLAN'ов (тот же голос) по всей сети.
Плюс, я хотел сказать, что три уровня иерархии свичей — это весьма и весьма крупный кампус (не первые тысячи пользовательских портов). В большинстве случаев обычно достаточно двух уровней. Но если нужно три, то механизмов реализации сегодня уже предостаточно, в т. ч. даже допускающих мультивендорность, я с этим и не спорю. И вообще нигде речь не шла, что, скажем, Juniper или какой-то другой вендор в рассматриваемой области предлагает что-то принципиально прям иное (QFabric vs Trill оставим за скобками, это про другое).
Собственно, по-моему у нас с вами спору-то в этой части нету.
>И что значит «У провайдеров никакого L3 не может быть»?
На доступе не может. Особенно, если ШПД для физлиц, впрочем, и юриков тоже так не наагрегируешься. Ну, то есть, в жизни, конечно, еще не то может, особенно в наших краях (весьма популярный способ, да), но это противоречит всему, чему можно противоречить. Несколько тысяч абонентов, и все, привет, дальше не масштабируется. Исключением можно считать, пожалуй, пакетную подсистему сетей мобильных операторов, но там это обстоятельство тянет за собой неслабое количество архитектурных примочек и стоит соответствующих денег.
Странно, что никто не вспомнил про такой стремительно набирающий популярность протокол, как Ethernet Automatic Protection Switching. Исключительно хорошая штука, замечательная своей скоростью сходимости.
Такая штука есть у многих вендоров, производящих metro-оборудование.
Я вспомнил, но пока вспоминал название, пока искал линк на описание, пока проверял, что напишу не боян — вы меня опередили. От себя замечу, если в простых конфигурациях что-то и отправит на свалку STP, то ИМХО как раз решения типа EAPS, ибо почти то же самое, в плане стабильности, делают на порядок проще и быстрее.
А чем это от ethernet ring protection отличается?
Ну, собственно, да. Но это для небольших провайдеров штука, плюс по-моему там же обязательно должны быть кольца. Или нет? Да и утверждение о том, что оно есть везде, где хошь, по-моему немножко излишне оптимистично. В том-то, блин, и дело, что метро-эзернета толком в америке не бывает. А раз так, то все там на это смотрят сквозь пальцы. На китайцах все надежда, но на них одних, скажем честно, далеко не уедешь.
Ну, собственно, да. Но это для небольших провайдеров штука, плюс по-моему там же обязательно должны быть кольца. Или нет? Да и утверждение о том, что оно есть везде, где хошь, по-моему немножко излишне оптимистично. В том-то, блин, и дело, что метро-эзернета толком в америке не бывает. А раз так, то все там на это смотрят сквозь пальцы. На китайцах все надежда, но на них одних, скажем честно, далеко не уедешь.
А это он и есть :) Просто у разных производителей по разному называется, но в RFC всё же пошёл под этим названием.
В Америке много чего нет, даже 220 вольт в розетке, и то нет :D А для построения колец, да на десятке (10GbE), в пределах города милое дело (и дешевле, чем MPLS'ое городить).
В Америке много чего нет, даже 220 вольт в розетке, и то нет :D А для построения колец, да на десятке (10GbE), в пределах города милое дело (и дешевле, чем MPLS'ое городить).
Это правда, только
а) где же такое счастье и почем? :)
б) к сожалению нишево это очень. Для юрлиц VPN там и т. д. — боюсь, это весьма условно можно назвать провайдерским решением. Ethernet-кольца — удел в первую очередь ШПДшников, там это по понятным причинам оправдано. Но что-то я сильно сомневаюсь, что бывают свичи с ринг-протекшеном, которые не жалко в подъезд поставить.
а) где же такое счастье и почем? :)
б) к сожалению нишево это очень. Для юрлиц VPN там и т. д. — боюсь, это весьма условно можно назвать провайдерским решением. Ethernet-кольца — удел в первую очередь ШПДшников, там это по понятным причинам оправдано. Но что-то я сильно сомневаюсь, что бывают свичи с ринг-протекшеном, которые не жалко в подъезд поставить.
STP, не STP, а в логотипе senetsy наблюдается красивое дерево)
Что вы будете делать без STP если вы оператор и подключаете L2 клиентов (ex: Internet Exchange), которые могут иметь между собой линки (L2)?
Буду читать второе предложение статьи со слов «то как минимум» :) Еще есть дурацкие способы LDP VPLS-мультихоминга, например.
я буду радоваться :) потому как я как провайдер просто отдаю трубу, у этих клиентов случится броадкаст-шторм и в какой-то момент моя труба загрузиться на всё 100% и я как оператор их с удовольствием протарифицирую :)
Кстати, а где такие IX, на которых разрешают больше одного мака на порту?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О ненужности Spanning Tree