Не думаю, что вы правы и «на стабильность сети у хомячков» всем наплевать. Конкуренция на рынке жесткая и если вы сделали плохую сеть или продали плохой сервис, к вам больше не придут — потеряете деньги, а на это продавцам точно не наплевать :)
Как правило, все упирается в бюджет: вот есть (или «можем достать») столько денег, их надо потратить и сделать за эти деньги best. В маленьких масштабах убедить добавить еще чуть денег и построить по-другому можно. В больших — не реально, совсем другие факторы играть начинают…
Ответ, на мой взгляд, очень прост — деньги. Кейс на новую сеть должен сходиться за пять лет. Если длиннее — денег, скороее всего, никто не даст. А в нашей стране и на пятилетний кейс денег найти трудно, инвестороы желают, чтобы кейсы сходились за 3- максимум 4 года. Километр оптики стоит дорого положить и еще дороже обслуживать. Особенно, если ты не являешься владельцем канализации. Поэтому и считают на доступ кольца — в реальной жизни OPEX существенно меньше и есть резервирование. Учитывая, что в больших сетях от 60 до 90 % денег в доступе, такое техническое рещение вытягивает кейс.
Какую версию OpenFlow поддерживаете? Какие «фирменные» фичи?
тестировали на софте, поддерживающим 1.0, про «фирменные фичи» — у НР позиция учавствовать в разработке стандартов, а не изобретать «фирменные фичи»; поэтому, что в стандарте есть, то и поддерживается.
а что именно вы хотите про него услышать? и что понимаете под туннелированием? пробросить контрольный трафик между сеткой и контроллером через туннель? можно.
Анализ нагрузки у Вас есть? Или только в рамках TCP\IP работаете?
опять же, нагрузки какой? по обработке flows на свиче? или нагрузка на контроллер? на свиче, если делать hw flows, процессор не грузится. точнее, грузится не сильнее, чем при традиционной коммутации. на контроллере — зависит (от мощности сервера, вариантов развертывания и т.д.)
Предложенная вами концепция „весь интеллект сети, управляемой через OpenFlow, размещается теперь на контроллерах“ вообще нежизнеспособна, и все с этим согласны.
Ну, во-первых, эта концепция предложена не мной (хотя спасибо, я польщен); во-вторых, если вы думаете, что концепция не жизнеспособна, то не обязательно так считают все остальные. С вами не согласны как минимум полусотни организаций, использующих openflow у себя в сетях.
И, в-третьих, вы снова манипулируете понятиями — major trend означает, что все игроки активно занимаются развитием этой технологии и уже есть вполе конкретные, жизнеспособные результаты; как только основные вендоры выпустят свои контроллеры, технология выйдет в main stream. Использовать или нет — ваше личное дело, ваше мнение снова услышано, спасибо.
Еще раз, цель статьи — показать, как на HP делаются MPLS VPN-ы и при помощи каких технологий правильно защищать их трафик. Эта статья не отвечает цели продемонстрировать, почему в определенных случаях следует делать выбор в сторону MPLS, а не OSPF (и я написал об этом в самом начале статьи).
Чтобы ответить вам по сути, не вызывая следующих вопросов, нужно показать среднюю инсталляцию MPLS сети у заказчика (подробно — какие сервисы живут в сети, какие к ним есть требования, как там TE работает, как синхрится MPLS-ная сигнализация с IGP, по каким правилам LSP динамически простраиваются, как мапятся админ-группы на qos и т.д.), и сравнить с тем, как это может быть сделано на базе классического IGP. Обязательно напишу об этом, как будет время, спасибо, что стараетесь сделать нас лучше :)
Писал уже — ваше право делать с сетями то, что считаете нужным — крутить ручки у OSPF, скрещивать IP FRR с MPLS-ом и т. д. В моем понимании стандартные задачи правильно решать стандартными способами.
Схема, которая приведена в статье — упрощенная схема собранного в лабе стэнда, чтобы протестировать определенный функционал для заказчика. Реальная сеть у заказчика — порядка 20 РЕ/10 P, соединенных оптикой, где-то full mesh, где-то кольцами, c RSVP TE в полный рост.
ТЕ в корпоративной сети затем же, зачем и в провайдерской — защищать трафик и управлять им, писать про это академический пост смысла не вижу.
Статья не про «какую-то архитектуру», а про то, как на практике настроить MPLS VPN на железе HP и защитить его от падения каналов при помощи стандартных механизмов TE. Хотите использовать для этого в MPLS сети IP FRR или крутить ручки у IGP — ваше право. Я бы этого делать не рекомендовал. Время сходимости с ТЕ в этом примере в пределах 200 мс.
Пример упрощенный, QoS в сочетании с MPLS ТЕ — глубокая тема, про которую нужно писать отдельно, другие применения ТЕ в корпоративных сетях (управление трафиком) в этой статье не рассматривались.
Каждому свое. Кому-то хватает IGP, в моей практике многим этого хватать перестало, делают MPLS с TE (эта статья и появилась по результатам очередного PoC для заказчиков). Балансировать трафик через туннели можно, просто не стал перегружать пример. Использовать IP FRR с MPLS лично я смысла не вижу, если уж подняли MPLS, то в нем для этого есть стандартный механизм FRR. Корпоративня сеть отличается от провайдерской, спора нет, но у многих она последнее время так усложняется и предъявляет такие требования к сервису, что люди начинают использовать провайдерские технологии.
Вам явно не с кем поговорить. Пять раз уже вам сказали — все, достаточно, разговор закончен. Нет, опять… Видимо, никто в жизни ваши «замечательные идеи» не слушает, вот и ходите по блогам проповедовать L3, пристаете с фантазиями своими. А их у вас немало, каждый раз что-то новенькое :). То причудится, что вам порекомендовали вебсервер резервировать средствами vMotion, то критические системы при помощи VRRP резервировать… Это не вы здесь кричали фальцетом, что OTV позволяет выбрать первый хоп? Вам сказали, что VPLS позволяет сделать также с VRRP. Точка. Дальше идеи в вашей голове причудливо исказились…
И не стройте здесь из себя Гуру, кого-то учить он все порывается… советы кому-то тут еще дает, «Я, на месте руководства ..»… Таких пионеров не то что увольнять, вообще нужно изолировать от ИТ. Иначе они начитаются «передовых идей» из Инета, половину не поймут или поймут не так (как с VRRP или c FT), и начнут ломать инфраструктуру в потраву своему юношескому идеализму.
И опять, все вокруг вас идиоты, один вы знаете, как правильно жить. Как в анекдоте "- Дорогой, будь осторожнее, передали, что там у тебя кто-то едет по встречке. — Дорогая, здесь их тысячи!". Так обычно бывает, когда ситуация ровно обратная. Все нормальные люди, а вот один… Правильно боитесь свою компанию называть. Узнают, что вы тут мелете — прогонят грязными тряпками.
Это мой последний пост вам. Больше не вижу смысла время на вас тратить, бороться с вашими некомпетентностями/недопониманиями, да еще и в таком тоне. Счастливо оставаться в мире фантазий.
Вы все еще не угомонились? У вас катарсис случится, если показать вам, какого масштаба компании растягивают в своей инфраструктуре VLAN-ы между ЦОД-ами… Всем ясно, что ситуации бывают разные и много таких, в которых L2 DCI предпочтительнее, уже можно больше не подпрыгивать.
L2 DCI не является НИ необходимой, НИ предпочтительной фичей для виртуальной инфраструктуры, более того — растянутые L2 сегменты всегда опасны.
Вот фантазер-то, откуда вы это берете…
Галлюцинации
У вас? Я об этом не подумал, а это многое объясняет…
… в предложенном вами документе открытым текстом писалось «держитесь от L2 DCI подальше».
Это вы вот это "...in some situations, Layer 2 must be extended beyond the single data center..." и вот это "...Such scenarios are becoming more prevalent, as... так перевели? У вас с английским еще хуже, чем с сетями.
Правда, будет уже нудеть «L3 лучше чем L2», ваше мнение все услышали, спасибо. Посчитают нужным — позовут вас строить L3 DCI из балансировщиков.
Как правило, все упирается в бюджет: вот есть (или «можем достать») столько денег, их надо потратить и сделать за эти деньги best. В маленьких масштабах убедить добавить еще чуть денег и построить по-другому можно. В больших — не реально, совсем другие факторы играть начинают…
а что именно вы хотите про него услышать? и что понимаете под туннелированием? пробросить контрольный трафик между сеткой и контроллером через туннель? можно.
опять же, нагрузки какой? по обработке flows на свиче? или нагрузка на контроллер? на свиче, если делать hw flows, процессор не грузится. точнее, грузится не сильнее, чем при традиционной коммутации. на контроллере — зависит (от мощности сервера, вариантов развертывания и т.д.)
Ну, во-первых, эта концепция предложена не мной (хотя спасибо, я польщен); во-вторых, если вы думаете, что концепция не жизнеспособна, то не обязательно так считают все остальные. С вами не согласны как минимум полусотни организаций, использующих openflow у себя в сетях.
И, в-третьих, вы снова манипулируете понятиями — major trend означает, что все игроки активно занимаются развитием этой технологии и уже есть вполе конкретные, жизнеспособные результаты; как только основные вендоры выпустят свои контроллеры, технология выйдет в main stream. Использовать или нет — ваше личное дело, ваше мнение снова услышано, спасибо.
Вы странно воспринимаете написанное, где вы это прочли? Черным по белому сказано, что SDN — это один из major trend развития сетей.
А коммутировать можно не только по MAC, вы правы :)
Резервирование в тех релизах софта, которые мы тестировали, не поддерживается.
Нагрузку специально не тестировали, SYN флуд тоже не устраивали, можете попробовать — поделитесь результатами.
Чтобы ответить вам по сути, не вызывая следующих вопросов, нужно показать среднюю инсталляцию MPLS сети у заказчика (подробно — какие сервисы живут в сети, какие к ним есть требования, как там TE работает, как синхрится MPLS-ная сигнализация с IGP, по каким правилам LSP динамически простраиваются, как мапятся админ-группы на qos и т.д.), и сравнить с тем, как это может быть сделано на базе классического IGP. Обязательно напишу об этом, как будет время, спасибо, что стараетесь сделать нас лучше :)
Не выдергивайте из контекста, я не рекомендую решать стандартные задачи не стандартными для решения этих задач средствами .
Писал уже — ваше право делать с сетями то, что считаете нужным — крутить ручки у OSPF, скрещивать IP FRR с MPLS-ом и т. д. В моем понимании стандартные задачи правильно решать стандартными способами.
Схема, которая приведена в статье — упрощенная схема собранного в лабе стэнда, чтобы протестировать определенный функционал для заказчика. Реальная сеть у заказчика — порядка 20 РЕ/10 P, соединенных оптикой, где-то full mesh, где-то кольцами, c RSVP TE в полный рост.
Статья не про «какую-то архитектуру», а про то, как на практике настроить MPLS VPN на железе HP и защитить его от падения каналов при помощи стандартных механизмов TE. Хотите использовать для этого в MPLS сети IP FRR или крутить ручки у IGP — ваше право. Я бы этого делать не рекомендовал. Время сходимости с ТЕ в этом примере в пределах 200 мс.
Пример упрощенный, QoS в сочетании с MPLS ТЕ — глубокая тема, про которую нужно писать отдельно, другие применения ТЕ в корпоративных сетях (управление трафиком) в этой статье не рассматривались.
И не стройте здесь из себя Гуру, кого-то учить он все порывается… советы кому-то тут еще дает, «Я, на месте руководства ..»… Таких пионеров не то что увольнять, вообще нужно изолировать от ИТ. Иначе они начитаются «передовых идей» из Инета, половину не поймут или поймут не так (как с VRRP или c FT), и начнут ломать инфраструктуру в потраву своему юношескому идеализму.
И опять, все вокруг вас идиоты, один вы знаете, как правильно жить. Как в анекдоте "- Дорогой, будь осторожнее, передали, что там у тебя кто-то едет по встречке. — Дорогая, здесь их тысячи!". Так обычно бывает, когда ситуация ровно обратная. Все нормальные люди, а вот один… Правильно боитесь свою компанию называть. Узнают, что вы тут мелете — прогонят грязными тряпками.
Это мой последний пост вам. Больше не вижу смысла время на вас тратить, бороться с вашими некомпетентностями/недопониманиями, да еще и в таком тоне. Счастливо оставаться в мире фантазий.
Вот фантазер-то, откуда вы это берете…
У вас? Я об этом не подумал, а это многое объясняет…
Это вы вот это "...in some situations, Layer 2 must be extended beyond the single data center..." и вот это "...Such scenarios are becoming more prevalent, as... так перевели? У вас с английским еще хуже, чем с сетями.
Правда, будет уже нудеть «L3 лучше чем L2», ваше мнение все услышали, спасибо. Посчитают нужным — позовут вас строить L3 DCI из балансировщиков.