myst

А молотком можно шурупы заколачивать, и?

и зачем в теме про "свич" упоминание линукс?

если поднапрячься и прочитать всю фразу целиком, то можно самому ответить на свой же вопрос.

Да вот только у ТС заявлен функционал л3 в ядро, а нексусы ну такое себе для подобного рода задач, разве что самые старшие.

Только насквозь конченный будет в корпоративном сегменте в голову ставить некротики.

джамбо надо выбрать по минимальному для всех участников.

Раздел превратился в какую-то помойку.

Именно так!

Казалось бы причем тут это... не, если у вас непрерывная сеть в одном физическом сегменте то без б, можно и бродкастом. Но если есть соседи за л3 за нафига нужны 2 разные модели конфигурации. сразу делать на L3 PTP.

@VolanD666 Совершенно согласен. В 21м веке бродкаст домены должны умереть. Л3 как минимум дебажить сильно проще, как и ptp.

притом что никакого отличия, аналогия прямая. и работает все это точно так же. где я вообще про поддержку? даже бу сервер на порядок надежнее нового самосбора, причину см. выше.

17 это больше чем в 3 раза дороже чем 4 и вообще непонятно к чему этот пассаж ох дааааааааааа, а щас что-то взяло и баз поменялось. но нет, это так не работает. у тебя либо фонарик на дешевом диоде в непрогнозируемо малым временем службы и тусклым свечением и батарейкой от фирмы дядюшки ляо которую этот диод высасывает за 2 часа, либо качественный дорогой cree у которого есть вполне себе mtbf и фонарь с контроллером и батарей с гарантированной работой 5+ часов. Разница в качестве комплектующих и цене.

Ещё раз #3 если в FIB есть запись, она в принципе уже никак не может обрабатываться "как-то по другому". На вашей же схеме это розовая стрелочка. Она там не бывает "настолько не корректной" что вдруг начнет обрабатываться CPU. Она может вести в "некорретном" направлении но процесс отправки в данном случае уже фрейма будет обработан штатно.

Ещё раз, оно либо есть в FIB либо нет. Как-то "не так" маршрут туда установить невозможно. Если оно обрабатывается на CPU это ошибка никак не связана с источником получения маршрута и уж тем более никак источник не связан с дальнейшей _коммутацией_ обработкой пакетов. Вы вообще путаете RIB и FIB но и это не относится к процессу прохождения пакетов с интерфейса на интерфейс.

Нет это не так. Стоимость и качество элементной базы может отличаться на много порядков. валом. другой вопрос что в начале 2000 мат. плата была "дорогим удовольствием" для среднестатистического обывателя, теперь же она из разряда пошел и купил новую.

какое отношение роут (неважно откуда полученный) имеет к скорости? Он либо есть в таблички маршрутизации либо его нет. Либо есть связность L3 либо её нет.

да вот как раз OTV это понятно но в моем случае "продаться вендору" вот вообще не вариант. не, возникает некая ясность "arp suppression с генерацией /32 + l3 evpn" вроде именно то что мне нужно.

Вобщем, до лаб пока не дошло, не понятен один момент, как обрабатывать переезд ВМ(хоста) с одним и тем же адресом из ЦОД А в ЦОД Б с точки зрения маршрутизации? Допустим я выделяю /24 на каждый Leaf. Но в случае переезда хоста в резервный ЦОД мне как-то надо анонсировать специфику /32? Где-то задним умом понимаю что это надо делать на гипервизорах, но на данный момент в качестве системы виртуализации выступает Hyper-V и беглое гугленье по ключам "hyperv, bgp, vxlan" вообще не дало никаких внятных результатов.

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

а сколько если не секрет?

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

Тут пока есть место для маневра, хотелось бы хотя бы концептуально определиться, ответить себе на вопросы.

ну таки тут какраз наоборот, уход от вендор специфик фабрик циско. mp-bgp vxlan isis/ospf вообще ниразу не вендорспецифик, так же как и клоза в которую можно пихать что угодно в отличии "от". И в добавок это не про SDN вообще опять же в отличии "от", хотя оно и упростит жизнь конечно. а вот " L2 QinQ между ЦОД" на 5000 км ожидаемо работать не будет. Вы походу то что я хочу в точности наоборот прочитали.

и что даже аргументы будут? хотя да, десктоп тазики под ногами это же самый верный способ проблем избежать. дада, админы локалхоста и обсуждают удел которых офис на 15 компуктеров и "мальчик почини мне чайник тыжпрограммист".

Доброго коллеги, помогите наподумать. Есть задачка обеспечить катастрофоустройчивость цод, причем на приличном расстоянии (до 5000 км). Сейчас есть некий цод на нексус фабриках, почти классическое collapsed core и куча филиалов подключенных к бизнесовым ресурсам в ядре. Необходимо убить сразу нескольких кроликов. 1) Сделать резервный ЦОД, но по некоторым внутренним соображениям это возможно только на достаточно удаленном расстоянии 2) Реализовать хотя бы теплое (с горячим такое сложно кмк) резервирование сервисов 3) Докучи сюда реализовать частичное распределение сервисов (для пула филиалов А приоритетный ЦОД А и сервисы специфичные для этих филиалов там же, для пула филиалов Б... ну вы поняли). 4) В случае отказа одного из ЦОД, все бизнеса автоматом поднимаются из бэкапов/снапшотов во втором цод с теми же адресами, настройками итд. Филиалы соответственно уже статически терминированы и в ЦОД А и в ЦОД Б. Время простоя в таком случае как мне видется это время старта всех сервисов + время на разгребание неучтенки (ну как обычно). 5) Сейчас виртуализация это хайперви (не ко столу будет упомянуто) и виам, но варианты тоже думаются. Поскольку у нас КИИ, РФ в забавным законодательством, итд тихонько смотрим в сторону вывода из эксплуатации циско фабрик, развертывания Клоза, EVPN + vxlan. Но лично я практического опыта с этим не имел, кое-что из прочитанного не складывается. Например: у нас падает сервис в ЦОД А, каким-то образом (не важно каким) этот сервис с готового образа поднимается в ЦОД Б. Как там обрабатывается миграция IP (но не всей подсети) географически и насколько быстро? Я так понимаю туннелируются ARP. Ещё вопрос: у нас ЦОД А совмещен с ГО, так вот в случае дизастера в ГО нам надо что бы сервисы (тут понятно) и вланы уползали очень избирательно в ЦОД Б, подсети рядовых пользователей ГО там точно не нужны. Посидят, покурят на время дизастера. Я так понимаю указываем что туннелировать во vni? Ещё важный вопрос одна и та же подсеть, в ней живут сервисы которые расположены и в ЦОД А и в ЦОД Б... Как там будет с доступностью сервисов в ЦОД Б из ГО который присоединен к ЦОД А? Я так понимаю все-таки туннелировать надо. Ещё вопрос. Туннели от филиалов до ЦОД А и ЦОД Б треминируются на впн роутеры, внутри предположим (обсуждаемо) ospf. Как будет обрабатываться маршрутная информация если сервис из А уполз в Б. Как филиал узнает куда слать пакет?