vPC (Virtual Port-Channel) - технология виртуализиции, доступная на коммутаторах Cisco Nexus (кроме Nexus 2K). Позволяет два Nexus коммутатора объединять в единое логическое L2 устройство с точки зрения нижестоящих коммутаторов или устройств (серверов).
Технология относится к семейству протоколов под названием MCEC - Multichassis EtherChannel (MLAG; vPC это вариант реализации MLAG от Cisco), в чем-то даже похожа на технологии объединения коммутаторов Catalyst - VSS и StackWise. Основное отличие от VSS состоит в том, что в vPC каждый коммутатор имеет независимый Control Plane и Management Plane, это дает гарантию того, что при отказе какого-либо компонента в ПО (OSPF процесс, например), сеть продолжит функционировать, в отличие от VSS, где сбой OSPF на Active коммутаторе не вызовет переключения Control Plane на Standby.
1.Компоненты vPC и терминология
vPC строится на базе двух коммутаторов, называемых vPC пирами (vPC peers). Один из них имеет роль vPC primary, второй vPC secondary. Primary коммутатор отвечает за генерацию BPDU (при этом данный коммутатор может и не быть STP Root), отвечает на ARP запросы, и именно он продолжает работать при потере vPC Peer Link-а. Для того, чтобы посмотреть, какой из коммутаторов является primary, а какой secondary используется команда:
В vPC существуют так же следующие статусы пиров (в случае перезагрузки или выхода из строя primary vPC пира):
"secondary, operational primary" - коммутатор был изначально выбран как secondary, но в результате отказа второго коммутатора, в данный момент он работает как primary.
"primary, operational secondary" - коммутатор был изначально выбран как primary, но после возврата его в работу после сбоя или перезагрузки, например, он работает как secondary в данный момент.
Роли primary и secondary влияют так же на поведение коммутаторов в случае разрыва vPC Peer-Link. Secondary коммутатор выключает все vPC Member интерфейсы и VLAN интерфейсы (SVI), участвующие в vPC. После чего весь трафик течет через vPC primary.
1.1 Описание компонент и порядок настройки:
vPC нужно настраивать в строго определенном порядке:
1) Настройка vPC домена
2) Настройка vPC Peer Keepalive, убедиться что "peer is alive"
3) Настройка vPC Peer Link
4) Настройка vPC Member Ports
Перед началом настройки необходимо глобально включить функционал vPC и LACP на коммутаторе:
Номер vPC домена используется для генерации vPC system-mac, который является общим для двух коммутаторов.
vPC system-mac:
00:23:04:ee:be:xx, где xx - номер vPC домена в шестнадцатеричной системе.
vPC local system-mac:
Уникальный MAC адрес коммутатора, либо VDC (если речь о Nexus 7K).
vPC system-mac используется, когда 2 коммутатора (Nexus 7K, например) представляются как единое логическое L2 устройство, vPC local system-mac используется в ситуации, когда каждое устройство выступает самостоятельно (например, когда присутствует Orphan порты).
Оба типа MAC адреса используются в качестве LACP system ID (vPC system-mac при построении LACP к vPC паре; vPC local system-mac при построении LACP только к одному из коммутаторов).
2) vPC Peer Keepalive - используется для трекинга vPC пира и обнаружения сценария dual active, в случае, если vPC Peer Link вышел из строя.
Для создания этого линка может быть использован любой L3 интерфейс коммутатора.
Рекомендации по настройке Peer Keepalive:
-Использовать отдельный L3 Etherchannel на двух разных линейных картах (1GE/10GE), в отдельном VRF. (предпочтительный вариант для N7K)
-Использовать Mgmt0 интерфейсы коммутаторов (предпочтительный вариант для N5K, можно использовать и с N7K, соединив интерфейсы супервизоров через обычный L2 коммутатор, не напрямую!)
-Использовать SVI (не рекомендуется к использованию, может привести к развалу vPC в некоторых случаях).
Для функции Keepalive используется UDP 3200, интервал отправки сообщений - 1 сек. (по умолчанию).
3) vPC Peer Link - L2 Trunk, используется для синхронизации Control Plane информации (таблица MAC адресов, STP информация, HSRP информация и т.д.) между vPC пирами, используя CFS (Cisco Fabric Services) протокол. Может так же служить для передачи vPC VLAN-ов и non-vPC VLAN-ов (рекомендуется передавать только vPC VLAN используя для них static pruning #switchport trunk allowed vlan). Для других VLAN рекомендуется использовать отдельный линк. Все VLAN, используемые на Member портах должны быть обязательно разрешены на Peer Link.
Но, как правило, Peer Link не используется для передачи Data трафика (Unicast), пока не возникнет Orphan состояние. В минимальной конфигурации должно использоваться не менее 2-х 10GE интерфейсов для формирования Peer Link, а для N7K должны так же использоваться одинаковые линейные карты (точнее тип карт должен быть одинаковым) на каждой стороне.
4) vPC Member Ports - интерфейсы, находящиеся в L2 Port-Channel и смотрящие в сторону нижестоящих коммутаторов (серверов), через эти интерфейсы проходит Data трафик. VLAN-ы, которые разрешены на этих портах называются vPC VLAN-ами. Назначенные номера vPC должны совпадать на двух коммутаторах. Обычно, для простоты конфигурации и траблшутинга, номер vPC (vPC ID) выбирается таким же как номер Port-Channel интерфейса.
L2 Port-Channel становится vPC Member портом после того, как на Port-Channel интерфейсе (Po) вводится команда #vpc <vpc-id>.
Как и в случае с Peer Link, для N7K должен использоваться одинаковый тип линейных карт на каждом из vPC пиров.
1.2 vPC Loop Prevention и Orphan:
Для защиты от петель vPC использует следующее правило:
Трафик, который пришел на коммутатор с vPC Peer Link не может быть передан на vPC Member Port, но может быть передан на Orphan порт или L3 интерфейс. За это правило отвечает механизм "vPC Check".
Orphan (eng: сирота) - ситуация, когда нижестоящее устройство имеет только одно подключение к одному из коммутаторов Nexus, формирующих vPC пару. Таких ситуаций следует избегать, но если все же есть необходимость подключить Orphan устройство, то это подключение должно быть выполнено к vPC Primary!
1.3 vPC Consistency:
Для корректной работы vPC ряд настроек и параметров на коммутаторах (vPC пирах) должен совпадать.
vPC различает два типа совпадения параметров (два типа consistency, если проще) - Type 1 и Type 2. Для работы vPC обязательно должны совпадать Type-1 параметры (существуют как глобальные - global, так и для интерфейсов - interface), например:
- STP протокол (PVST, Rapid-PVST, MSTP)
- BPDU Filter, BPDU Guard, Loop Guard
- Настройки MST региона
- Режим LACP, скорость и дуплекс на портах
В случае несовпадения какого-либо из Type-1 параметров vPC отключается на secondary коммутаторе: "Type1: vPC will be suspended in case of mismatch".
В случае несовпадения Type 2 параметров vPC продолжает работу, но генерируется предупреждающее log-сообщение, которое говорит о необходимости привести всё к одинаковому виду. Примеры таких параметров:
- MAC aging
- Настройки ACL
- Параметры QoS
- Port Security
- DHCP Snooping
- HSRP, GLBP, протоколы маршрутизации
- Interface VLAN (при несовпадении возможны потери пакетов)!!!
Для проверки параметров используется команда:
-После создания vPC Peer-Link на нём так же включается STP Bridge Assurance.
-Только vPC Primary коммутатор генерирует BPDU, но при этом он может не являться STP Root. В случае конфигурации по умолчанию vPC Primary будет являться STP Root (т.к. выборы происходят на основе наименьшего системного MAC, как и в STP). Каждый коммутатор использует свой System MAC в качестве BID (Root ID). Для нижестоящих устройств Root ID=BID Primary коммутатора.
-vPC Secondary только передает полученные BPDU от нижестоящих коммутаторов Primary пиру через Peer Link.
-vPC пиры синхронизируют состояние STP портов (STP Port States) на своих vPC Member интерфейсах.
-По умолчанию каждый коммутатор имеет свой BID=System MAC+Priority.
vPC peer-switch:
У vPC для STP есть оптимизация под названием "Peer-switch", которая позволяет видеть оба vPC пира как единый STP Root. Коммутаторы используют общий Virtual BID, который формируется из vPC system-mac и приоритета. Эта оптимизация позволяет не перестраивать STP дерево в случае падения Primary vPC пира и не тратить время на сходимость (актуально в Hybrid Setup дизайне).
Приоритет STP должен при этом быть настроен одинаковым для всех VLAN - иначе оба коммутатора не будут выполнять роль общего STP Root коммутатора! (т.к. BID=MAC+Priority).
Если нижестоящий коммутатор подключен по vPC (vPC-attached): Root ID = Bridge ID = Virtual BID.
Если нижестоящий коммутатор подключен по STP (STP-attached): Root ID = Virtual BID; Bridge ID = System MAC.
Настройка vPC peer-switch:
При настройке Peer-switch теряется гибкость управления для STP в случае STP-attached устройств, т.к. оба коммутатора становятся STP Root, то нет возможности настроить балансировку по классической схеме с использованием разных Root коммутаторов для разных VLAN.
Можно настраивать балансировку путем изменения STP Cost на нижестоящем коммутаторе, но этот подход не очень гибкий, хотя имеет место быть.
А настройки на основе приоритетов портов не дадут никакого результата, т.к. в любом случае для выбора кратчайшего пути STP сперва анализирует Lowest sender BID - а это System MAC каждого коммутатора Nexus, т.е. в любом случае в приоритете будет только один из них.
Более простым вариантом является опция под названием STP pseudo-information.
Она позволяет независимо настраивать STP Bridge Priority и STP Root Priority для STP-attached коммутаторов, позволяя тем самым выполнять настройки по балансировке для каждого VLAN.
1.5 vPC и HSRP:
---
2.Сценарии vPC, примеры настройки
2.1 Classic vPC:
vPC настраивается между двумя коммутаторами N7K, в качестве нижестоящего коммутатора используется N5K (либо любой другой, либо сервер) на котором настраивается обычный LACP.
N7K1:
Команды для проверки:
#sh interface status
#sh run interface po1 membership
#sh vpc
#sh etherchannel summary
#sh lacp neighbor
#show vpc consistency-parameters global
2.2 Hybrid vPC Design(STP-attached switch):
На коммутаторах настраивается vPC, но в сторону нижестоящего устройства (коммутатора) используется STP. Используется STP peer-switch и STP pseudo-information для балансировки.
N7K1:
2.3 Back-to-Back vPC:
vPC настраивается на N7K в сторону N5K и наоборот. Между коммутаторами при этом получается один большой Port-Channel.
Настройка коммутаторов N7K1 и N7K2 полностью соответствует настройкам из примера 2.1 (Classic vPC).
Номер Port-channel интерфейса, как и VPC ID на коммутаторах N5K1, N5K2 может быть использован отличный от номера Port-channel интерфейса и VPC ID на N7K1 и N7K2.
N5K1:
Рекомендуемый дизайн, поддерживается как на N5K/N6K, так и на N7K. vPC строится только от FEX до серверов, каждый FEX подключается только к 1 родительскому коммутатору (Single-homed FEX).
N7K1:
#show fex [detail]
#show interfaces status fex 101
#show interface fex-fabric
4.2 vPC+FEX (EvPC):
Дизайн поддерживается только на N5K/N6K. vPC строится как от FEX до серверов (Host vPC), так и внутри фабрики (Fabric vPC), каждый FEX подключается к двум родительским коммутаторам (Dual-homed FEX). ISSU в таком дизайне не поддерживается, т.к. вызывает перезагрузку обоих FEX при обновлении одного из Parent коммутаторов.
Т.к. в таком дизайне конфигурацией каждого FEX могут управлять оба Parent коммутатора, то очень легко сделать несоответствие в конфигурации для одних и тех же FEX портов с разных родительских коммутаторов (например, N5K1 e101/1/1 - access VLAN10; N5K2 e101/1/1 - access VLAN20), и при этом с точки зрения Control-Plane ошибки не будет, а вот с точки зрения Data-Plane будут проблемы.
Для N5K/N6K поддерживается функционал Config Sync, с помощью которого можно синхронизировать конфигурации на разных Parent коммутаторах. Как правило его применяют именно в таком дизайне, хотя можно использовать и без EvPC.
С точки зрения конфигурации для EvPC не нужно настраивать vPC от FEX в сторону серверов (host vPC mode), коммутатор сам выполняет эту настройку, автоматически присваивая внутренний номер vPC, настройка вручную не поддерживается.
N5K1:
Технология относится к семейству протоколов под названием MCEC - Multichassis EtherChannel (MLAG; vPC это вариант реализации MLAG от Cisco), в чем-то даже похожа на технологии объединения коммутаторов Catalyst - VSS и StackWise. Основное отличие от VSS состоит в том, что в vPC каждый коммутатор имеет независимый Control Plane и Management Plane, это дает гарантию того, что при отказе какого-либо компонента в ПО (OSPF процесс, например), сеть продолжит функционировать, в отличие от VSS, где сбой OSPF на Active коммутаторе не вызовет переключения Control Plane на Standby.
1.Компоненты vPC и терминология
vPC строится на базе двух коммутаторов, называемых vPC пирами (vPC peers). Один из них имеет роль vPC primary, второй vPC secondary. Primary коммутатор отвечает за генерацию BPDU (при этом данный коммутатор может и не быть STP Root), отвечает на ARP запросы, и именно он продолжает работать при потере vPC Peer Link-а. Для того, чтобы посмотреть, какой из коммутаторов является primary, а какой secondary используется команда:
#show vpc roleВыбор роли (role priority) осуществляется на основе настраиваемого приоритета (1-65535). Коммутатор с меньшим значением приоритета выбирается как vPC primary. В случае, если приоритет одинаковый, primary становится тот, у кого меньше системный MAC адрес. Настраивается приоритет внутри vPC домена, например:
N7K(config)#vpc domain 1vPC роль не вытесняемая (non-preemptive)!
N7K(config-vpc-domain)#role priority 1
В vPC существуют так же следующие статусы пиров (в случае перезагрузки или выхода из строя primary vPC пира):
"secondary, operational primary" - коммутатор был изначально выбран как secondary, но в результате отказа второго коммутатора, в данный момент он работает как primary.
"primary, operational secondary" - коммутатор был изначально выбран как primary, но после возврата его в работу после сбоя или перезагрузки, например, он работает как secondary в данный момент.
Роли primary и secondary влияют так же на поведение коммутаторов в случае разрыва vPC Peer-Link. Secondary коммутатор выключает все vPC Member интерфейсы и VLAN интерфейсы (SVI), участвующие в vPC. После чего весь трафик течет через vPC primary.
1.1 Описание компонент и порядок настройки:
vPC нужно настраивать в строго определенном порядке:
1) Настройка vPC домена
2) Настройка vPC Peer Keepalive, убедиться что "peer is alive"
3) Настройка vPC Peer Link
4) Настройка vPC Member Ports
Перед началом настройки необходимо глобально включить функционал vPC и LACP на коммутаторе:
N7K(config)#feature vpc1) vPC домен (vPC domain) - Определяет 2 коммутатора, участвующих в vPC. Номер vPC домена (vPC domain ID) должен совпадать на коммутаторах, каждый коммутатор может принадлежать только к одному vPC домену!
N7K(config)#feature lacp
Номер vPC домена используется для генерации vPC system-mac, который является общим для двух коммутаторов.
vPC system-mac:
00:23:04:ee:be:xx, где xx - номер vPC домена в шестнадцатеричной системе.
vPC local system-mac:
Уникальный MAC адрес коммутатора, либо VDC (если речь о Nexus 7K).
vPC system-mac используется, когда 2 коммутатора (Nexus 7K, например) представляются как единое логическое L2 устройство, vPC local system-mac используется в ситуации, когда каждое устройство выступает самостоятельно (например, когда присутствует Orphan порты).
Оба типа MAC адреса используются в качестве LACP system ID (vPC system-mac при построении LACP к vPC паре; vPC local system-mac при построении LACP только к одному из коммутаторов).
2) vPC Peer Keepalive - используется для трекинга vPC пира и обнаружения сценария dual active, в случае, если vPC Peer Link вышел из строя.
Для создания этого линка может быть использован любой L3 интерфейс коммутатора.
Рекомендации по настройке Peer Keepalive:
-Использовать отдельный L3 Etherchannel на двух разных линейных картах (1GE/10GE), в отдельном VRF. (предпочтительный вариант для N7K)
-Использовать Mgmt0 интерфейсы коммутаторов (предпочтительный вариант для N5K, можно использовать и с N7K, соединив интерфейсы супервизоров через обычный L2 коммутатор, не напрямую!)
-Использовать SVI (не рекомендуется к использованию, может привести к развалу vPC в некоторых случаях).
Для функции Keepalive используется UDP 3200, интервал отправки сообщений - 1 сек. (по умолчанию).
#show vpc peer-keepaliveВ случае использования SVI интерфейсов для Peer Keepalive крайне желательно (можно сказать обязательно) использовать отдельный L2 Trunk между коммутаторами и отдельный не vPC VLAN (на vPC Peer линке не разрешать этот VLAN). А при использовании MST так же настроить отдельный Instance.
3) vPC Peer Link - L2 Trunk, используется для синхронизации Control Plane информации (таблица MAC адресов, STP информация, HSRP информация и т.д.) между vPC пирами, используя CFS (Cisco Fabric Services) протокол. Может так же служить для передачи vPC VLAN-ов и non-vPC VLAN-ов (рекомендуется передавать только vPC VLAN используя для них static pruning #switchport trunk allowed vlan). Для других VLAN рекомендуется использовать отдельный линк. Все VLAN, используемые на Member портах должны быть обязательно разрешены на Peer Link.
Но, как правило, Peer Link не используется для передачи Data трафика (Unicast), пока не возникнет Orphan состояние. В минимальной конфигурации должно использоваться не менее 2-х 10GE интерфейсов для формирования Peer Link, а для N7K должны так же использоваться одинаковые линейные карты (точнее тип карт должен быть одинаковым) на каждой стороне.
4) vPC Member Ports - интерфейсы, находящиеся в L2 Port-Channel и смотрящие в сторону нижестоящих коммутаторов (серверов), через эти интерфейсы проходит Data трафик. VLAN-ы, которые разрешены на этих портах называются vPC VLAN-ами. Назначенные номера vPC должны совпадать на двух коммутаторах. Обычно, для простоты конфигурации и траблшутинга, номер vPC (vPC ID) выбирается таким же как номер Port-Channel интерфейса.
L2 Port-Channel становится vPC Member портом после того, как на Port-Channel интерфейсе (Po) вводится команда #vpc <vpc-id>.
Как и в случае с Peer Link, для N7K должен использоваться одинаковый тип линейных карт на каждом из vPC пиров.
1.2 vPC Loop Prevention и Orphan:
Для защиты от петель vPC использует следующее правило:
Трафик, который пришел на коммутатор с vPC Peer Link не может быть передан на vPC Member Port, но может быть передан на Orphan порт или L3 интерфейс. За это правило отвечает механизм "vPC Check".
Orphan (eng: сирота) - ситуация, когда нижестоящее устройство имеет только одно подключение к одному из коммутаторов Nexus, формирующих vPC пару. Таких ситуаций следует избегать, но если все же есть необходимость подключить Orphan устройство, то это подключение должно быть выполнено к vPC Primary!
1.3 vPC Consistency:
Для корректной работы vPC ряд настроек и параметров на коммутаторах (vPC пирах) должен совпадать.
vPC различает два типа совпадения параметров (два типа consistency, если проще) - Type 1 и Type 2. Для работы vPC обязательно должны совпадать Type-1 параметры (существуют как глобальные - global, так и для интерфейсов - interface), например:
- STP протокол (PVST, Rapid-PVST, MSTP)
- BPDU Filter, BPDU Guard, Loop Guard
- Настройки MST региона
- Режим LACP, скорость и дуплекс на портах
В случае несовпадения какого-либо из Type-1 параметров vPC отключается на secondary коммутаторе: "Type1: vPC will be suspended in case of mismatch".
В случае несовпадения Type 2 параметров vPC продолжает работу, но генерируется предупреждающее log-сообщение, которое говорит о необходимости привести всё к одинаковому виду. Примеры таких параметров:
- MAC aging
- Настройки ACL
- Параметры QoS
- Port Security
- DHCP Snooping
- HSRP, GLBP, протоколы маршрутизации
- Interface VLAN (при несовпадении возможны потери пакетов)!!!
Для проверки параметров используется команда:
#show vpc consistency-parameters [interface | global | vpc number]1.4 vPC и STP:
-После создания vPC Peer-Link на нём так же включается STP Bridge Assurance.
-Только vPC Primary коммутатор генерирует BPDU, но при этом он может не являться STP Root. В случае конфигурации по умолчанию vPC Primary будет являться STP Root (т.к. выборы происходят на основе наименьшего системного MAC, как и в STP). Каждый коммутатор использует свой System MAC в качестве BID (Root ID). Для нижестоящих устройств Root ID=BID Primary коммутатора.
-vPC Secondary только передает полученные BPDU от нижестоящих коммутаторов Primary пиру через Peer Link.
-vPC пиры синхронизируют состояние STP портов (STP Port States) на своих vPC Member интерфейсах.
-По умолчанию каждый коммутатор имеет свой BID=System MAC+Priority.
vPC peer-switch:
У vPC для STP есть оптимизация под названием "Peer-switch", которая позволяет видеть оба vPC пира как единый STP Root. Коммутаторы используют общий Virtual BID, который формируется из vPC system-mac и приоритета. Эта оптимизация позволяет не перестраивать STP дерево в случае падения Primary vPC пира и не тратить время на сходимость (актуально в Hybrid Setup дизайне).
Приоритет STP должен при этом быть настроен одинаковым для всех VLAN - иначе оба коммутатора не будут выполнять роль общего STP Root коммутатора! (т.к. BID=MAC+Priority).
Если нижестоящий коммутатор подключен по vPC (vPC-attached): Root ID = Bridge ID = Virtual BID.
Если нижестоящий коммутатор подключен по STP (STP-attached): Root ID = Virtual BID; Bridge ID = System MAC.
Настройка vPC peer-switch:
N7K1#vpc domain 1STP pseudo-information:
N7K1#peer-switch
!
N7K2#vpc domain 1
N7K2#peer-switch
При настройке Peer-switch теряется гибкость управления для STP в случае STP-attached устройств, т.к. оба коммутатора становятся STP Root, то нет возможности настроить балансировку по классической схеме с использованием разных Root коммутаторов для разных VLAN.
Можно настраивать балансировку путем изменения STP Cost на нижестоящем коммутаторе, но этот подход не очень гибкий, хотя имеет место быть.
А настройки на основе приоритетов портов не дадут никакого результата, т.к. в любом случае для выбора кратчайшего пути STP сперва анализирует Lowest sender BID - а это System MAC каждого коммутатора Nexus, т.е. в любом случае в приоритете будет только один из них.
Более простым вариантом является опция под названием STP pseudo-information.
Она позволяет независимо настраивать STP Bridge Priority и STP Root Priority для STP-attached коммутаторов, позволяя тем самым выполнять настройки по балансировке для каждого VLAN.
1.5 vPC и HSRP:
---
2.Сценарии vPC, примеры настройки
2.1 Classic vPC:
vPC настраивается между двумя коммутаторами N7K, в качестве нижестоящего коммутатора используется N5K (либо любой другой, либо сервер) на котором настраивается обычный LACP.
N7K1(config)#vrf context KEEPALIVEN7K2:
N7K1(config-vrf)#interface e1/2
N7K1(config-if)#no switchport
N7K1(config-if)#vrf member KEEPALIVE
N7K1(config-if)#ip address 192.168.0.1/30
N7K1(config-if)#no shut
!
N7K1(config)#vpc domain 1
N7K1(config-vpc-domain)#peer-keepalive destination 192.168.0.2 vrf KEEPALIVE source 192.168.0.1
!
!Проверка vPC keep-alive status: peer is alive (#show vpc)
!
N7K1(config)#interface e1/1, e2/1
N7K1(config-if-range)#channel-group 1 mode active
N7K1(config-if-range)#no shut
N7K1(config-if-range)#interface po1
N7K1(config-if)#switchport
N7K1(config-if)#switchport mode trunk
N7K1(config-if)#vpc peer-link
!
!Проверка Peer status: peer adjacency formed ok; Configuration consistency status: success (#show vpc)
!
N7K1(config)#interface e1/17, e2/17
N7K1(config-if-range)#channel-group 10 mode active
N7K1(config-if-range)#no shut
N7K1(config-if-range)#interface po10
N7K1(config-if)#switchport
N7K1(config-if)#switchport mode trunk
N7K1(config-if)#vpc 10
N7K2(config)#vrf context KEEPALIVEN5K:
N7K2(config-vrf)#interface e1/2
N7K2(config-if)#no switchport
N7K2(config-if)#vrf member KEEPALIVE
N7K2(config-if)#ip address 192.168.0.2/30
N7K2(config-if)#no shut
!
N7K2(config)#vpc domain 1
N7K2(config-vpc-domain)#peer-keepalive destination 192.168.0.1 vrf KEEPALIVE source 192.168.0.2
!
!Проверка vPC keep-alive status: peer is alive (#show vpc)
!
N7K2(config)#interface e1/1, e2/1
N7K2(config-if-range)#channel-group 1 mode active
N7K2(config-if-range)#no shut
N7K2(config-if-range)#interface po1
N7K2(config-if)#switchport
N7K2(config-if)#switchport mode trunk
N7K2(config-if)#vpc peer-link
!
!Проверка Peer status: peer adjacency formed ok; Configuration consistency status: success (#show vpc)
!
N7K2(config)#interface e1/17, e2/17
N7K2(config-if-range)#channel-group 10 mode active
N7K2(config-if-range)#no shut
N7K2(config-if-range)#interface po10
N7K2(config-if)#switchport
N7K2(config-if)#switchport mode trunk
N7K2(config-if)#vpc 10
N5K(config)#interface e1/1 - 4"force" - команда позволяет сформировать Port-Channel на интерфейсах с разными изначальными настройками, копирует все настройки с первого интерфейса в группе на оставшиеся.
N5K(config-if-range)#channel-group 10 [force] mode active
N5K(config-if-range)#no shut
N5K(config-if-range)#interface po10
N5K(config-if)#switchport
N5K(config-if)#switchport mode trunk
Команды для проверки:
#sh interface status
#sh run interface po1 membership
#sh vpc
#sh etherchannel summary
#sh lacp neighbor
#show vpc consistency-parameters global
2.2 Hybrid vPC Design(STP-attached switch):
На коммутаторах настраивается vPC, но в сторону нижестоящего устройства (коммутатора) используется STP. Используется STP peer-switch и STP pseudo-information для балансировки.
N7K1:
N7K1(config)#vpc domain 1N7K2:
N7K1(config-vpc-domain)#peer-switch
!
N7K1(config)#spanning-tree pseudo-information
N7K1(config-pseudo)#vlan 10,20 root priority 0
N7K1(config-pseudo)#vlan 10 designated priority 4096
N7K1(config-pseudo)#vlan 20 designated priority 61440
N7K2(config)#vpc domain 1Для vPC-attached коммутаторов Root ID будет идентичен с Bridge ID и иметь значение 0023.04ee.be01, а priority=0.
N7K2(config-vpc-domain)#peer-switch
!
N7K2(config)#spanning-tree pseudo-information
N7K2(config-pseudo)#vlan 10,20 root priority 0
N7K2(config-pseudo)#vlan 10 designated priority 61440
N7K2(config-pseudo)#vlan 20 designated priority 4096
2.3 Back-to-Back vPC:
vPC настраивается на N7K в сторону N5K и наоборот. Между коммутаторами при этом получается один большой Port-Channel.
Настройка коммутаторов N7K1 и N7K2 полностью соответствует настройкам из примера 2.1 (Classic vPC).
Номер Port-channel интерфейса, как и VPC ID на коммутаторах N5K1, N5K2 может быть использован отличный от номера Port-channel интерфейса и VPC ID на N7K1 и N7K2.
N5K1:
N5K1(config)#interface mgmt 0N5K2:
N5K1(config-if)#ip address 192.168.0.1/30
N5K1(config-if)#no shut
!
N5K1(config)#vpc domain 2
N5K1(config-vpc-domain)#peer-keepalive destination 192.168.0.2
!
N5K1(config)#interface e1/1 - 2
N5K1(config-if-range)#channel-group 1 mode active
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po1
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode trunk
N5K1(config-if)#vpc peer-link
!
N5K1(config)#interface e1/11 - 12
N5K1(config-if-range)#channel-group 10 mode active
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po10
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode trunk
N5K1(config-if)#vpc 10
!
!Настройка vPC в сторону сервера
!
N5K1(config)#interface e1/20
N5K1(config-if-range)#channel-group 20 mode active
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po20
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode trunk
N5K1(config-if)#vpc 20
N5K2(config)#interface mgmt 03.Cisco FEX
N5K2(config-if)#ip address 192.168.0.2/30
N5K2(config-if)#no shut
!
N5K2(config)#vpc domain 2
N5K2(config-vpc-domain)#peer-keepalive destination 192.168.0.1
!
N5K2(config)#interface e1/1 - 2
N5K2(config-if-range)#channel-group 1 mode active
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po1
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode trunk
N5K2(config-if)#vpc peer-link
!
N5K2(config)#interface e1/11 - 12
N5K2(config-if-range)#channel-group 10 mode active
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po10
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode trunk
N5K2(config-if)#vpc 10
!
!Настройка vPC в сторону сервера
!
N5K2(config)#interface e1/20
N5K2(config-if-range)#channel-group 20 mode active
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po20
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode trunk
N5K2(config-if)#vpc 20
FEX (Fabric Externder) - семейство VNTag (IEEE 802.1BR) "коммутаторов" Cisco Nexus 2000 (N2K). Позиционируются как ToR устройства. FEX не поддерживают локальную коммутацию и не имею консоли для управления.
Для их работы обязательно необходим родительский коммутатор (Parent Switch), через которого происходит вся коммутация и управление. В качестве Parent могут выступать Cisco Nexus 5K,6K,7K,9K. Для родительского коммутатора FEX выступает в роли удаленной линейной карты (Remote Line Card).
Особенности FEX:
- Т.к. FEX это не Ethernet коммутатор, STP на них не используется.
- На всех нижестоящих портах(в сторону серверов/хостов) по умолчанию включены: BPDU Guard, STP Edge, BPDU Filter.
- В случае использования FEX c N7K, порты на FEX могут быть как L2, так и L3
- В случае использования FEX c N5K/N6K, порты на FEX могут быть только как L2
- FEX ID для Parent коммутатора #fex associate <100-199>
Плюсы и минусы использования FEX:
+ Стоимость FEX ниже, чем стоимость полноценных коммутаторов N3K, N5K, N6K.
+ Единая точка управления с родительского коммутатора всеми FEX.
- Переподписка (минимум 2:1).
- Не очень оптимальны при большом количестве East-West трафика.
Включение FEX функционала на N5K/N6K:
По-умолчанию все FEX используют так называемый "static pinning". Т.е. N2K статически мапирует свои нижестоящие интерфейсы (Host facing interfaces) к Uplink интерфейсам (Fabric interfaces). Если Fabric интерфейс только 1, то все порты FEX будут соответствовать только одному этому Fabric интерфейсу, по которому происходит подключение к родительскому коммутатору. Но если Fabric интерфейса 2 и более, то FEX произведет статическое соответствие своих Host интерфейсов к вышестоящим интерфейсам фабрики, разделив их поровну.
Например, при наличии 2-х Fabric интерфейсов половина FEX портов будет соответствовать первому Fabric интерфейсу, другая половина второму. При выходе из строя одного Fabric интерфейса, половина Host портов на FEX так же станет недоступна (они будут выключены), динамического перераспределения этих портов на рабочий Fabric интерфейс не произойдет до тех пор, пока не перезагрузится FEX коммутатор! После перезагрузки все Host интерфейсы перераспределятся на рабочий Fabric интерфейс.
Именно поэтому между Parent коммутатором и FEX рекомендуется использовать Port-Channel. Все нижестоящие порты FEX в этом случае мапируются к одному единственному Port-Channel интерфейсу и трафик распределяется, используя механизмы хеширования (Dynamic pinning).
4.Примеры настройки FEX
4.1 vPC+FEX (Host vPC):Для их работы обязательно необходим родительский коммутатор (Parent Switch), через которого происходит вся коммутация и управление. В качестве Parent могут выступать Cisco Nexus 5K,6K,7K,9K. Для родительского коммутатора FEX выступает в роли удаленной линейной карты (Remote Line Card).
Особенности FEX:
- Т.к. FEX это не Ethernet коммутатор, STP на них не используется.
- На всех нижестоящих портах(в сторону серверов/хостов) по умолчанию включены: BPDU Guard, STP Edge, BPDU Filter.
- В случае использования FEX c N7K, порты на FEX могут быть как L2, так и L3
- В случае использования FEX c N5K/N6K, порты на FEX могут быть только как L2
- FEX ID для Parent коммутатора #fex associate <100-199>
Плюсы и минусы использования FEX:
+ Стоимость FEX ниже, чем стоимость полноценных коммутаторов N3K, N5K, N6K.
+ Единая точка управления с родительского коммутатора всеми FEX.
- Переподписка (минимум 2:1).
- Не очень оптимальны при большом количестве East-West трафика.
#feature fexВключение FEX функционала на N7K:
#install feature-set fexFEX pinning:
#feature-set fex
По-умолчанию все FEX используют так называемый "static pinning". Т.е. N2K статически мапирует свои нижестоящие интерфейсы (Host facing interfaces) к Uplink интерфейсам (Fabric interfaces). Если Fabric интерфейс только 1, то все порты FEX будут соответствовать только одному этому Fabric интерфейсу, по которому происходит подключение к родительскому коммутатору. Но если Fabric интерфейса 2 и более, то FEX произведет статическое соответствие своих Host интерфейсов к вышестоящим интерфейсам фабрики, разделив их поровну.
Например, при наличии 2-х Fabric интерфейсов половина FEX портов будет соответствовать первому Fabric интерфейсу, другая половина второму. При выходе из строя одного Fabric интерфейса, половина Host портов на FEX так же станет недоступна (они будут выключены), динамического перераспределения этих портов на рабочий Fabric интерфейс не произойдет до тех пор, пока не перезагрузится FEX коммутатор! После перезагрузки все Host интерфейсы перераспределятся на рабочий Fabric интерфейс.
Именно поэтому между Parent коммутатором и FEX рекомендуется использовать Port-Channel. Все нижестоящие порты FEX в этом случае мапируются к одному единственному Port-Channel интерфейсу и трафик распределяется, используя механизмы хеширования (Dynamic pinning).
4.Примеры настройки FEX
Рекомендуемый дизайн, поддерживается как на N5K/N6K, так и на N7K. vPC строится только от FEX до серверов, каждый FEX подключается только к 1 родительскому коммутатору (Single-homed FEX).
N7K1(config)#vrf context KEEPALIVEN7K2:
N7K1(config-vrf)#interface e1/2
N7K1(config-if)#no switchport
N7K1(config-if)#vrf member KEEPALIVE
N7K1(config-if)#ip address 192.168.0.1/30
N7K1(config-if)#no shut
!
N7K1(config)#vpc domain 1
N7K1(config-vpc-domain)#peer-keepalive destination 192.168.0.2 vrf KEEPALIVE source
192.168.0.1
!
!Проверка vPC keep-alive status: peer is alive (#show vpc)
!
N7K1(config)#interface e1/1, e2/1
N7K1(config-if-range)#channel-group 1 mode active
N7K1(config-if-range)#no shut
N7K1(config-if-range)#interface po1
N7K1(config-if)#switchport
N7K1(config-if)#switchport mode trunk
N7K1(config-if)#vpc peer-link
!
!Проверка Peer status: peer adjacency formed ok; Configuration consistency status: success (#show vpc)
!
N7K1(config)#interface e1/17 - 18, e2/17 - 18
N7K1(config-if-range)#channel-group 101
N7K1(config-if-range)#no shut
N7K1(config-if-range)#interface po101
N7K1(config-if)#switchport
N7K1(config-if)#switchport mode fex-fabric
N7K1(config-if)#fex associate 101
!
!Проверка FEX (#show fex detail)
!
N7K1(config)#interface e101/1/1
N7K1(config-if-range)#channel-group 10 mode active
N7K1(config-if-range)#no shut
N7K1(config-if-range)#interface po10
N7K1(config-if)#switchport
N7K1(config-if)#switchport mode trunk
N7K1(config-if)#vpc 10
N7K2(config)#vrf context KEEPALIVEКоманды для проверки:
N7K2(config-vrf)#interface e1/2
N7K2(config-if)#no switchport
N7K2(config-if)#vrf member KEEPALIVE
N7K2(config-if)#ip address 192.168.0.2/30
N7K2(config-if)#no shut
!
N7K2(config)#vpc domain 1
N7K2(config-vpc-domain)#peer-keepalive destination 192.168.0.1 vrf KEEPALIVE source
192.168.0.2
!
!Проверка vPC keep-alive status: peer is alive (#show vpc)
!
N7K1(config)#interface e1/1, e2/1
N7K1(config-if-range)#channel-group 1 mode active
N7K1(config-if-range)#no shut
N7K1(config-if-range)#interface po1
N7K1(config-if)#switchport
N7K1(config-if)#switchport mode trunk
N7K1(config-if)#vpc peer-link
!
N7K2(config)#interface e1/17 - 18, e2/17 - 18
N7K2(config-if-range)#channel-group 102
N7K2(config-if-range)#no shut
N7K2(config-if-range)#interface po102
N7K2(config-if)#switchport
N7K2(config-if)#switchport mode fex-fabric
N7K2(config-if)#fex associate 102
!
!Проверка FEX (#show fex detail)
!
N7K2(config)#interface e102/1/1
N7K2(config-if-range)#channel-group 10 mode active
N7K2(config-if-range)#no shut
N7K2(config-if-range)#interface po10
N7K2(config-if)#switchport
N7K2(config-if)#switchport mode trunk
N7K2(config-if)#vpc 10
#show fex [detail]
#show interfaces status fex 101
#show interface fex-fabric
4.2 vPC+FEX (EvPC):
Дизайн поддерживается только на N5K/N6K. vPC строится как от FEX до серверов (Host vPC), так и внутри фабрики (Fabric vPC), каждый FEX подключается к двум родительским коммутаторам (Dual-homed FEX). ISSU в таком дизайне не поддерживается, т.к. вызывает перезагрузку обоих FEX при обновлении одного из Parent коммутаторов.
Т.к. в таком дизайне конфигурацией каждого FEX могут управлять оба Parent коммутатора, то очень легко сделать несоответствие в конфигурации для одних и тех же FEX портов с разных родительских коммутаторов (например, N5K1 e101/1/1 - access VLAN10; N5K2 e101/1/1 - access VLAN20), и при этом с точки зрения Control-Plane ошибки не будет, а вот с точки зрения Data-Plane будут проблемы.
Для N5K/N6K поддерживается функционал Config Sync, с помощью которого можно синхронизировать конфигурации на разных Parent коммутаторах. Как правило его применяют именно в таком дизайне, хотя можно использовать и без EvPC.
С точки зрения конфигурации для EvPC не нужно настраивать vPC от FEX в сторону серверов (host vPC mode), коммутатор сам выполняет эту настройку, автоматически присваивая внутренний номер vPC, настройка вручную не поддерживается.
N5K1:
N5K1(config)#interface mgmt 0N5K2:
N5K1(config-if)#ip address 192.168.0.1/30
N5K1(config-if)#no shut
!
N5K1(config)#vpc domain 1
N5K1(config-vpc-domain)#peer-keepalive destination 192.168.0.2
!
N5K1(config)#interface e1/1 - 2
N5K1(config-if-range)#channel-group 1 mode active
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po1
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode trunk
N5K1(config-if)#vpc peer-link
!
!Конфигурация ниже должна быть идентична на двух N5K
!
N5K1(config)#interface e1/10
N5K1(config-if-range)#channel-group 101
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po101
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode fex-fabric
N5K1(config-if)#fex associate 101
N5K1(config-if)#vpc 101
!
N5K1(config)#interface e1/11
N5K1(config-if-range)#channel-group 102
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po102
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode fex-fabric
N5K1(config-if)#fex associate 102
N5K1(config-if)#vpc 102
!
N5K1(config)#interface e101/1/1
N5K1(config-if-range)#channel-group 10 mode active
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po10
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode trunk
!
N5K1(config)#interface e102/1/1
N5K1(config-if-range)#channel-group 10 mode active
N5K1(config-if-range)#no shut
N5K1(config-if-range)#interface po10
N5K1(config-if)#switchport
N5K1(config-if)#switchport mode trunk
N5K2(config)#interface mgmt 0
N5K2(config-if)#ip address 192.168.0.2/30
N5K2(config-if)#no shut
!
N5K2(config)#vpc domain 1
N5K2(config-vpc-domain)#peer-keepalive destination 192.168.0.1
!
N5K2(config)#interface e1/1 - 2
N5K2(config-if-range)#channel-group 1 mode active
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po1
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode trunk
N5K2(config-if)#vpc peer-link
!
!Конфигурация ниже должна быть идентична на двух N5K
!
N5K2(config)#interface e1/10
N5K2(config-if-range)#channel-group 101
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po101
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode fex-fabric
N5K2(config-if)#fex associate 101
N5K2(config-if)#vpc 101
!
N5K2(config)#interface e1/11
N5K2(config-if-range)#channel-group 102
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po102
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode fex-fabric
N5K2(config-if)#fex associate 102
N5K2(config-if)#vpc 102
!
N5K2(config)#interface e101/1/1
N5K2(config-if-range)#channel-group 10 mode active
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po10
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode trunk
!
N5K2(config)#interface e102/1/1
N5K2(config-if-range)#channel-group 10 mode active
N5K2(config-if-range)#no shut
N5K2(config-if-range)#interface po10
N5K2(config-if)#switchport
N5K2(config-if)#switchport mode trunk
Отличная статья!
ОтветитьУдалить