Когда мы задумываемся о сети 10гбит, первое что приходит на ум из оборудования - Cisco Nexus.
И первое с чем сталкиваешься, погружаясь в настройки Nexus - отсутствие поддержки традиционной кластеризации в стеке(Stack).

Традиционное стекирование

Как известно, стекирование даёт нам преимущества:

• Единое управление всеми коммутаторами, входящими в стек
• Возможность агрегации линков, подключенных к разным коммутаторам-участниками стека (Multi-Chassis Link Aggregation, MC-LAG)

В сетевом оборудовании есть абстрагированные понятия: "Planes", которые различаются процессами, в них происходящими.
Control Plane - отвечает за логику работы сетевого устройства: маршрутизация, ARP, STP и тд. Заполнение таблиц маршрутизации, MAC адресов и др.
Data Plane - выполняет не посредственную передачу данных.

В стеке один из коммутаторов становится основным (Master), на нем запускается общий для всех control plane, который координирует работу остальных коммутаторов.
Общий control plane позволяет выполнять агрегации линков, единую маршрутизацию, т.е. стек превращается в единый виртуальный коммутатор.
Вместе с этим, общий control plane может зависнуть, с потерей управления и возможным отказом LACP. Также возможна ситуация split brain, когда коммутаторы-участники решают, что они являются активными.
Таким образом, традиционный стек обладает рядом минусов, из-за которых его не поддерживает Nexus.

Стекирование без объединения в стек

Для реализации функций MC-LAG используется технология virtual Port-channel (vPC). Каждый Nexus имеет свой независимый control и management plane. При этом мы можем агрегировать каналы, распределённые между двумя коммутаторам. Безусловно мы не получаем полной независимости устройств. В процессе работы коммутаторы синхронизируют между собой информацию, необходимую для работы агрегации (MAC-адреса, ARP и IGMP записи, состояние портов). Но с точки зрения отказоустойчивости это всё же лучше, чем единый control и management plane. Эта схема более надёжна. Даже если и произойдёт сбой в работе vPC, он будет менее фатален для инфраструктуры.

Однако vPC привносит особые нюансы работы. Настроить его можно только между двумя коммутаторами Nexus, и они оба должны иметь набор идентичных настроек. Некоторые функции требуют небольших дополнительных настроек, которые при работе обычного стека не нужны. Например, корректная маршрутизация трафика между двумя vPC портами предполагает наличие команды «peer-gateway». Иначе можно споткнуться об механизм предотвращения петель при передаче трафика через vPC. Работа динамической маршрутизации через vPC требует «layer3 peer-router».

VPC

VPC, Virtual Port Channel - это особый тип Etherchannel (LAG), который позволяет подключить коммутатор или устройство не к одному коммутатору, а к двум.

Таким образом два физических коммутатора образуют один логический.

VPC - это технология Cisco, которую мы и находим на наших любимых нексусах.
Другие вендоры также имеют похожие технологии.

Как нетрудно догадаться, подключение клиента по двум активным линкам позволяет увеличить пропускную способность, а также устойчивость к сбоям, благодаря избыточности. Подобно LACP, VPC создаёт виртуальный линк, в котором не живет STP и оба линка активны.

VPC Topology

В нашем случае VPC поднят на двух коммутаторах Nexus.
Коммутаторы, участвующие в VPC называются Peers.
Два peers, а также сопутствующие компоненты, как объединение, называются VPC Domain.
Каждый VPC Domain имеет свой уникальный Domain ID.
Коммутатор может находиться только в одном VPC Domain.
Один коммутатор будет Primary role, второй Secondary role.
Оба коммутатора выполняют функции Forward Traffic, но Primary role выполняет обработку Bridge Protocol Data Units (BPDUs), responds to Address Resolution Protocol (ARP) requests.

VPC peer-keepalive link
Peers используют L3 VPC peer-keepalive link для проверки состояния друг друга, heartbeats.
В некоторых случаях, при потере связи по peer-keepalive link, оба коммутатора будут думать, что каждый остался один (Split Brain).
Для предотвращения подобных ситуаций, VPC peer-keepalive link должен быть изолирован в отдельном VRF.

Часто в небольших сетях VPC peer-keepalive link поднимают соединением двух коммутаторов через management интерфейсы. В крупных инсталляциях management интерфейсы могут быть подключены в management network.

И, как упоминалось ранее, для организации VPC peer-keepalive link можно использовать обычные интерфейсы, но в выделенном VRF.

VPC peer-link
VPC peer-link - это высокоскоростное соединение, которое используется для связи между двумя пирами. Он формирует "backplane", через который происходит синхронизация состояний пиров VPC: например синхронизация MAC Addresses. Peer-link также передаёт трафик Broadcast и Multicast.

Host ports
Host ports - это порты на коммутаторе VPC, предназначенные для подключения других устройств.
Host ports бывают двух типов:

• Member ports - это порт, на котором настроен VPC. Всё VLAN-ы настроенные на Member port, должны быть также разрешены и на VPC peer-link. VPC всегда проверяет Member ports на ошибки.
• Orphan ports - это порт, на котором настройки VPC отсутствуют. VLAN-ы настроенные на Orphan port, могу отсутствовать на VPC peer-link

Как упоминалось, VPC постоянно проверяет Member ports на ошибки.
Разделяют на два типа ошибок inconsistency errors:

• Type-1 inconsistency error. Часто возникает, при несовпадении конфигураций. Secondary Switch отключает порт. Primary оставляет в апе. В нашем случае отключится правый зеленый. Трафик продолжит ходить.
• Type-2 inconsistency error. Оба коммутатора оставляют порты в апе, но пишут об ошибке в сислог

VPC и LACP

VPC очень похож на Etherchannel.
Подключаемые устройства всё также используют LACP для негоциации LAG, но различия всё же есть.
В обычном LAG, каждый LACP device использует System-ID. В случае же подключения как разным коробкам, System-ID будет разным, и обычный LACP не собертся.
VPC же использует Domain-ID для обхода этой проблемы.

Пример конфигурации VPC

В данном примере приведён сервер, подключенный к кластеру VPC.
Синим цветом выделена конфигурация интерфейса mgmt, а также peer-keepalive.
VPC peer-keepalive link необходим пирам для проверки состояния друг друга, heartbeats
VPC peer-keepalive link здесь реализован через интерфейсы mgmt. Физически чаще всего это провод, соединяющий коммутаторы непосредственно друг с другом. Здесь самое главное, что коммутаторы были друг для друга доступны, могли пинговать друг друга.

Чёрным цветом выделена конфигурация VPC peer-link, - высокоскоростное соединение, обеспечивающее работу самого стека и через который происходит синхронизация состояний пиров VPC. Как видно, в настройках port-channel присутствует директива vpc peer-link. VPC peer-link должен включать в себя все используемые VLAN для подключения серверов.

Зелёным цветом выделена конфигурация для подключения сервера.
Физически сервер подключается к двум коммутаторам. Тут также описывается обычный port-channel, но этот port-channel живет на двух коммутаторах. Директива vpc 2 должна совпадать на обоих коммутаторах. Если мы будем добавлять следующий сервер, у нас будет соответственно port-channel3, vpc 3, channel-group 2.

VMWare и PVC

Безусловно, для работы с кластером VPC, необходимы настройки и со стороны сервера.
В качестве сервера рассмотрим хост VMWare.

Для начала посмотрим как выглядят настройки для обычного LACP:
Как известно, коммутаторы Сиско поддерживают два типа агрегации физических линков - LACP и Etherchannel. VMware ESX поддерживает оба типа агрегации, однако без активированной лицензии на виртуальные коммутаторы Nexus поддерживается только режим etherchannel.

interface Port-channel1
 description LACP to srv-hv-01
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface GigabitEthernet3/0/9
 description description srv-hv-01
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode on
 spanning-tree portfast trunk
!
interface GigabitEthernet3/0/10
 description description srv-hv-01
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode on
 spanning-tree portfast trunk

Со стороны VMWare:

Рассмотрим вариант подключения VMWare к nexus vPC stack
SW1

interface Ethernet1/5
  description esx01 port 1
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30
  speed 10000
  storm-control broadcast level 20.00
  storm-control multicast level 20.00
  storm-control unicast level 20.00
  storm-control action shutdown
  no shutdown
! 
interface Ethernet1/6
  description esx01 port 2
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30
  speed 10000
  storm-control broadcast level 20.00
  storm-control multicast level 20.00
  storm-control unicast level 20.00
  storm-control action shutdown
  no shutdown

Настройки со стороны VMWare

Использовались материалы:
https://habr.com/ru/companies/cbs/articles/324964/
https://www.cloudflare.com/ru-ru/learning/network-layer/what-is-the-cont...
https://learningnetwork.cisco.com/s/question/0D53i00000Kt2nHCAR/control-...
https://www.youtube.com/watch?v=EaJsb2PNBqg&t=644s
https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-soft...
https://www.k-max.name/vmware/razbiraemsya-s-lacp-i-nic-teaming-v-vmware/
https://sliderweb.ru/blog/post/vmware-link-aggregation-cisco-catalyst