Почему дни OTV сочтены?

Грубый перевод статьи из блога HBS https://www.hbs.net/Blogs/2021/OTV-is-Dead-Long-Live-EVPN-VXLAN! Автор: Wes Sudman Дата: 23.08.2021

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

Связи центра обработки данных (DCI) существуют как наша высокоскоростная форма связи между этими центрами обработки данных.
Когда дело доходит до DCI, в игру могут вступить несколько технологий.
Традиционно наша связь была на уровне 3 между этими сайтами, что было нормально для маршрутизации между ними, но как насчет уровня 2?
С появлением vMotion компании стремились использовать эти связи для переноса рабочих нагрузок между центрами обработки данных.
Одно предостережение заключалось в том, что для этого требовалось подключение уровня 2. Здесь в игру вступает ОТВ.

Но разве мы не можем просто использовать канал DCI уровня 2?
Это представляет другую проблему: остовное дерево.
OTV был разработан Cisco не только для решения этой проблемы расширения уровня 2 по сети уровня 3, но и для ограничения топологии связующего дерева одним контроллером домена.
Еще одна проблема, которую он решил, заключалась в том, что FHRP также нужно было сегментировать, чтобы мы могли иметь сетевые шлюзы в обоих DC. Звучит здорово, верно?
Первоначально он поставил множество галочек, чтобы удовлетворить потребности того времени.

Так почему он мертв?
Есть несколько причин. Во-первых, это его собственность.
1) Вы должны использовать оборудование Cisco, и оно доступно только на ASR и Nexus 7K.
2) Во-вторых, вы можете «балансировать нагрузку» по обоим каналам только с помощью идентификаторов VLAN.
Ваши «четные» VLAN используют один канал, а «нечетные» VLAN — другой.
Это помогло разделить трафик, но вряд ли было эффективным способом сделать это.
И теперь, когда 80 процентов трафика ЦОД идет с востока на запад, требуется более высокая эффективность.
3) Последняя причина — конвергенция.
OTV плохо справляется со сбоями и использует 240-секундный таймер, прежде чем трафик будет возвращен на нарушенный канал. Четыре минуты кажутся вечностью, когда речь идет о простое сети! Итак, каков ответ?

VXLAN EVPN. Это открытый стандарт. Может работать с несколькими поставщиками.
Обеспечивает более эффективную маршрутизацию/коммутацию и быструю сходимость.
Это все, чем является OTV. Ну а в чем минус?
Сложность. И именно здесь производители вмешались со своими собственными решениями, чтобы упростить процесс. ACI или DCNM от Cisco, Apstra от Juniper, BigSwitch и многие другие используют VXLAN EVPN для своих решений «Fabric».
Хотя я не могу однозначно сказать, что ACI Cisco прост, он позволяет выполнять всю настройку в графическом интерфейсе,
что избавляет инженера от необходимости углубляться в сорняки VXLAN EVPN Fabric.
Хотя понимание логики работы этой технологии определенно полезно для устранения неполадок, это не совсем необходимо.

Итак, ОТВ совсем мертв? Еще нет. Но он стоит одной ногой в могиле.
По мере того, как все больше и больше поставщиков выпускают свое решение VXLAN EVPN, оно, по сути, противопоставило OTV всему миру.
Итак, возможно, пришло время взглянуть на вашу сеть, чтобы убедиться, что вы не остались в дураках с умирающей технологией.