Это правда, только
а) где же такое счастье и почем? :)
б) к сожалению нишево это очень. Для юрлиц VPN там и т. д. — боюсь, это весьма условно можно назвать провайдерским решением. Ethernet-кольца — удел в первую очередь ШПДшников, там это по понятным причинам оправдано. Но что-то я сильно сомневаюсь, что бывают свичи с ринг-протекшеном, которые не жалко в подъезд поставить.
Под virtual chassis внутри лежит ISIS. Да, да. И не только у Juniper, насколько я понимаю. Именно он строит топологию и считает кратчайшие пути между интерфейсами. В QFabric помимо этого еще и BGP заточили для анонса MAC-адресов (ага-ага, куда катится мир). Хотя у Cisco тоже есть какое-то датацентровое решение, где они биджипней маки анонсируют.
Ну, собственно, да. Но это для небольших провайдеров штука, плюс по-моему там же обязательно должны быть кольца. Или нет? Да и утверждение о том, что оно есть везде, где хошь, по-моему немножко излишне оптимистично. В том-то, блин, и дело, что метро-эзернета толком в америке не бывает. А раз так, то все там на это смотрят сквозь пальцы. На китайцах все надежда, но на них одних, скажем честно, далеко не уедешь.
Да какая разница. То, что у них там в бумажке нарисовано как distribution-block — это и есть моя схема выше. L3 на самых нижних коммутаторах класса c2960/ex2200 — это глупость. А на следующем звене (c3750/ex4200) — самое то. Девяноста пяти процентам компаний больше звеньев и не надо: на двухуровневой гирлянде можно весьма красиво собрать до пары тысяч пользовательских портов, куда больше-то. Ну, если надо больше, то таки да, в зависимости от задачи может быть либо L2 наверх, либо сразу L3.
У провайдеров никакого L3 не может быть (хотя у нас это одна из форм описанной выше болезни индустрии). В корпоративных же сетях L3 обычно плохо, т. к. ACL на свичах поддерживать — гиблое дело. На Juniper можно красивые масштабируемые решения сделать, чтоб и L3, и подсети между собой не ходили (только туда, куда надо), а на Cisco — вроде нет. До недавних пор по крайней мере PBR'ом точно нельзя было пользоваться для этих целей. Плюс, либо надо на L3-свичах BGP (что или дорого, или вообще не бывает), либо пользовательские сети прям OSFP анонсировать, что тоже имеет ряд минусов. В любом случае, все это не вендорно-независимо, не очень гибко и либо довольно сложно в поддержке и траблшутинге, либо немасштабируемо. Короче, no silver bullet.
Стягивают тот или иной первый уровень (xDSL или xPON, если ШПД для физлиц или прям оптический ethernet, если юрлица) от абонента/клиента в крупные узлы (АТС всю жизнь у нас это называлось), в которых ставят не говнохабы по три копейки, а нечто взрослое. Это взрослое либо (победнее) собирают гирляндой с (раньше с минимумом STP, теперь все больше как описано выше), либо подключают к IP/MPLS сети на базе псевдопроводов или VPLS.
Собственно, это написано в любом учебнике, так всю жизнь делали и у нас (см. классическую телефонию или Стрим). И, конечно, понятно, с чем связаны сложности организации нормальной инфраструктуры сетей доступа у нас. Поэтому, да, весь этот говнометроэзернет с STP лезет из всех щелей. Только из этого не следует, что так надо делать. Это у нас такая болезнь индустрии.
STP, как многократно уже было сказано, никто не отменял. Но только, если тот или иной продукт поддерживает STP, это не значит, что им нужно обставлять полрегиона, соединять абы как (как сможете линии проложить или любымими кольцами), включать STP и ждать счастья. Не случиться, к сожалению.
Там автор (то есть я :) еще писал, что не надо путать LAG и LACP. LAG в решиме active/active или active/passive — это то, что вы процитировали. А LACP в режиме active или passive — это то, о чем lumenous (либо устройство слушает и шлет LACP-пакеты, либо только слушает). Совершенно не имеющие отношения друг к другу вещи. Собственно, я бы вам рекомендовал просто разобраться, что такое LACP, зачем он нужен, и вообще нужен ли, тогда и про режимы его работы будет понятно.
Ну да. Собственно, я когда писал эту статью (в данном случае senetsy=salium), там был подраздел «Слово о балансировке», но много получилось и совсем далеко от темы. Убрал, висит в черновиках как набросок для отдельной статьи.
Не подумайте, что я имел в виду, что функционал хеширования у MX и 6500/7600 сколько-нибудь сравним. 7600 в смысле гибкости балансировки ближе к 3750, чем к MX. Просто пример оборудования разных классов.
Сомневаюсь, что это универсально хорошо. Как способ решить конкретную проблему повышения емкости линка для конкретного приложения — может быть. А если для всего трафика пакеты одной TCP-сессии начнут ходить разными путями и потом пересобираться на получателе — сомневаюсь, что это круто. А уж если понадобится поверх этого CoS сделать, то ууу…
Эээ, нет. Вы неправы. LAG и ECMP на большинстве платформ балансируются одинаково. Либо одинаково хорошо, либо одинаково плохо. Везде сейчас per-flow (кроме MLPPP), вопрос только какие поля включать в хеш, и как приводить хеш к значению линка в LAG или NextHop при ECMP. Чем гибче этот функионал, тем выше цена.
Просто в сравнении со свичами маршрутизаторы — это обычно либо программная коробка, либо существенно более дорогое железо. В обоих случаях гибкость функионала выше. Поэтому вы фактически сраниваете не LAG vs ECMP, а функционал свичей класса C3750/EX4200 с функционалом тех же Cisco 6500/7600, Juniper MX или программными коробками. Да, C3750/EX4200 при данном сравнении заведо хуже балансируют, что при LAG, что при ECMP. Собственно, это одно из отличий больших L3-свичей от полноценных маршрутизаторов.
В прицнипе, достаточно кластеризовать устройства ниже по иерархии и соединять их с ядром при помощи RTG. Это как LAG, только всегда active-passive. Тогда в ядре не нужно кластеризации. Собственно, так и делают часто: все-таки большие модульные свичи только-только стали кластеризоваться.
Ну тогда, вам в ООН за наградой :) Хотя plain ethernet для провайдерских сетей — это, к сожалению, наша большая боль. Больше только netflow для биллинга.
Коллеги из какой-нибудь Америки вообще сначала не понимают, о чем речь, когда с ними разговаривают о кольцах с STP. Когда понимают — хватаются за голову, мол, дикая страна.
«Кроме того, Spanning Tree, хоть и теряет свою актуальность как механизм построения отказоустойчивой топологии и балансировки, но, как уже было сказано, остается актуальным способом защиты от человеческой ошибки. Поэтому, если, например, на коммутаторе включен по умолчанию протокол RSTP или PVST+, не стоит его выключать, если только вы не уверены, что знаете точно, зачем именно. Желательно также, чтоб на всех коммутаторах использовался один протокол, но это уже совсем другая история.»
а) где же такое счастье и почем? :)
б) к сожалению нишево это очень. Для юрлиц VPN там и т. д. — боюсь, это весьма условно можно назвать провайдерским решением. Ethernet-кольца — удел в первую очередь ШПДшников, там это по понятным причинам оправдано. Но что-то я сильно сомневаюсь, что бывают свичи с ринг-протекшеном, которые не жалко в подъезд поставить.
Ну, собственно, да. Но это для небольших провайдеров штука, плюс по-моему там же обязательно должны быть кольца. Или нет? Да и утверждение о том, что оно есть везде, где хошь, по-моему немножко излишне оптимистично. В том-то, блин, и дело, что метро-эзернета толком в америке не бывает. А раз так, то все там на это смотрят сквозь пальцы. На китайцах все надежда, но на них одних, скажем честно, далеко не уедешь.
У провайдеров никакого L3 не может быть (хотя у нас это одна из форм описанной выше болезни индустрии). В корпоративных же сетях L3 обычно плохо, т. к. ACL на свичах поддерживать — гиблое дело. На Juniper можно красивые масштабируемые решения сделать, чтоб и L3, и подсети между собой не ходили (только туда, куда надо), а на Cisco — вроде нет. До недавних пор по крайней мере PBR'ом точно нельзя было пользоваться для этих целей. Плюс, либо надо на L3-свичах BGP (что или дорого, или вообще не бывает), либо пользовательские сети прям OSFP анонсировать, что тоже имеет ряд минусов. В любом случае, все это не вендорно-независимо, не очень гибко и либо довольно сложно в поддержке и траблшутинге, либо немасштабируемо. Короче, no silver bullet.
Собственно, это написано в любом учебнике, так всю жизнь делали и у нас (см. классическую телефонию или Стрим). И, конечно, понятно, с чем связаны сложности организации нормальной инфраструктуры сетей доступа у нас. Поэтому, да, весь этот говнометроэзернет с STP лезет из всех щелей. Только из этого не следует, что так надо делать. Это у нас такая болезнь индустрии.
STP, как многократно уже было сказано, никто не отменял. Но только, если тот или иной продукт поддерживает STP, это не значит, что им нужно обставлять полрегиона, соединять абы как (как сможете линии проложить или любымими кольцами), включать STP и ждать счастья. Не случиться, к сожалению.
Сомневаюсь, что это универсально хорошо. Как способ решить конкретную проблему повышения емкости линка для конкретного приложения — может быть. А если для всего трафика пакеты одной TCP-сессии начнут ходить разными путями и потом пересобираться на получателе — сомневаюсь, что это круто. А уж если понадобится поверх этого CoS сделать, то ууу…
Просто в сравнении со свичами маршрутизаторы — это обычно либо программная коробка, либо существенно более дорогое железо. В обоих случаях гибкость функионала выше. Поэтому вы фактически сраниваете не LAG vs ECMP, а функционал свичей класса C3750/EX4200 с функционалом тех же Cisco 6500/7600, Juniper MX или программными коробками. Да, C3750/EX4200 при данном сравнении заведо хуже балансируют, что при LAG, что при ECMP. Собственно, это одно из отличий больших L3-свичей от полноценных маршрутизаторов.
Коллеги из какой-нибудь Америки вообще сначала не понимают, о чем речь, когда с ними разговаривают о кольцах с STP. Когда понимают — хватаются за голову, мол, дикая страна.