что такое vpc cisco
Есть ли стекирование в коммутаторах Cisco Nexus?
Когда речь заходит о коммутаторах Cisco Nexus, один из первых вопросов, который мне задают: поддерживается ли на них стекирование? Услышав отрицательней ответ, следует логичное «Почему?».
Ответ – стек коммутаторов может служить единой точкой отказа. При этом Nexus позиционируется, как коммутатор в ЦОД, где отказоустойчивость стоит на одном из первых мест.
«Но вы ведь сами писали (часть 1, часть 2, VSS/IRF), что на базе стека можно построить отказоустойчивую инфраструктуру! Получается, обманывали?». Нет, ни в коем случае. Каждая технология уместна там, где её минусы не настолько критичны для работы сети, а плюсы дают ощутимые преимущества. Вот и со стеком ситуация аналогичная.
Стекирование обладает двумя основными преимуществами:
Поддержка MC-LAG (в терминах Cisco – Port channel) позволяет:
Общий control plane предоставляет ещё один приятный бонус — единую точку маршрутизации трафика в стеке. А значит необходимости настраивать протоколы обеспечения резервирования шлюза по умолчанию (First Hop Redundancy Protocols) нет.
Таким образом, стекирование предполагает общий control plane и management plane. Несмотря на все достоинства, это возможная точка отказа. И хоть аппаратно коммутаторы независимы, бывают сбои (не связанные с железом), при которых стек может перестать корректно функционировать. Например, если control plane на основном коммутаторе «зависнет» из-за утечки оперативной памяти. Последствия могут быть различными: потеря управления стеком, прекращение работы различных протоколов (например, LACP). При этом стек может продолжать передавать трафик. Ведь ASIC’и заполнены необходимыми данными и фактически не зависят от работы control plane. Но все динамические агрегации (MC-LAG) «развалятся», так как пакеты LACP перестанут отправляться на соседнее устройство.
Ещё одна возможная проблема – ситуация, когда сразу несколько коммутаторов решают, что они являются активными («split brain»). Так как конфигурация у них идентичная, имеем в сети два устройства с одинаковой адресацией. Происходит это из-за разрыва управляющего канала. Конечно же, существуют технологии, направленные на борьбу с таким явлением. В этом случае коммутаторы используют дополнительные механизмы отслеживания состояния соседей. Да и управляющий канал на некоторых типах стека сложно разорвать. Но не стоит сбрасывать со счетов такую ситуацию.
Таким образом, стек – хорошее решение для сетей, где его поломка не фатальна. Да, его нельзя назвать полностью отказоустойчивым решением. Но вероятность наступления критической ситуации не так велика. И с лихвой может окупиться теми преимуществами, которые он предоставляет.
Коммутаторы Nexus позиционируются как решение для сред (в первую очередь ЦОД’ов), где очень важна отказоустойчивость. Поэтому на этих устройствах стекирование вообще отсутствует. Замечу, область применения Nexus не ограничена только ЦОДами. Они могут использоваться, в том числе, при построении корпоративной сети.
Но стекирование имеет весомые плюсы. Поэтому 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. Причём это зависит достаточно сильно от модели Nexus’а. Стоит внимательно смотреть configuration guide. В общем, как обычно, у всего есть свои плюсы и минусы.
vPC в среде FabricPath носит название vPC+.
В случае классического vPC синхронизация происходит через выделенный канал peer link. В случае работы vPC в рамках ACI фабрики, канал peer link не требуется. Вся синхронизация происходит через фабрику.
В плане единой точки управления всеми коммутаторами отсутствие стекирования компенсируется следующими моментами:
Так как вся логика FEX’ов реализуется на родительском Nexus’е, FEX’ы и родительский коммутатор – единая точка отказа. На FEX’ах нет локальной коммутации. Пакеты между соседними портами передаются через родительское устройство. А значит имеем повышенную нагрузку на канал между ними.
Стоит помнить: чтобы решение было отказоустойчивым в нём не должно быть зависимых частей. Любые технологии, протоколы, обеспечивающие отказоустойчивость, могут также являться причиной отказов. Более того благодаря им, проблемы могут переходить с одного устройства на другое. Ни что не идеально. Поэтому если вопрос отказоустойчивости является определяющим, нужно стараться строить сеть таким образом, чтобы влияние устройств друг на друга было минимальным.
antiCisco blogs
блоги по технологиям и оборудованию cisco от инструкторов
Virtual PortChannel
vPC по сути своей является расширением всем нам известного классического PortChannel. Он позволяет соединить какое-либо сетевое устройство (свитч, сервер) с двумя коммутаторами Cisco Nexus так, что для этого downlink-устройства соединение (логически) будет выглядеть так
Терминология
vPC peer link
Вы можете сконфигурировать только два коммутатора для работы внутри vPC-домена, т.е. следующие топологии не поддерживаются:
После настройки vPC peer link (сами настройки мы рассмотрим в конце статьи) коммутаторы договариваются между собой о том кто из них будет primary, а кто secondary (выбор идет на основе наименьшего MAC, либо приоритета). По сути, кто из них кто роли не играет (это важно только в определенных failover-ситуациях). Если primary выходит из строя, то secondary подхватывает его роль.
Прим. В случае настройки vPC между Nexus7000 настоятельно рекомендуется использовать разные линейные модули для peer-link
По peer-link’у почти никогда не передается регулярный трафик. По нему бегает лишь unknown unicast, multicast/broadcast. Достигается это благодаря тому, что все MAC-адреса, таблицы IGMP snooping’а, ARP-таблицы и пр. синхронизируются между peer-устройствами посредством протокола Cisco Fabric Services.
Если vPC peer link падает, то проверяется доступность соседа через peer-keepalive линк. Если сосед жив, то secondary свитч гасит все свои vPC порты чтобы не допустить петель в сети. Соответственно весь трафик бегает через primary устройство. Если же связи нет и по keepalive-линку Вы спокойно можете получить состояние DualActive. Именно по этому рекомендую для peer link и peer-keepalive использовать разные физические интерфейсы.
Peer-keepalive link
Как я уже упоминал, peer-keepalive используется коммутаторами для периодической отсылки keepalive’ов и мониторинга состояния соседа. Это обычный L3-интерфейс, соответственно между свитчами должна быть L3-связность (как она будет реализована не важно – хоть через прямой L2-линк, хоть через облако с IGP).
По умолчанию keepalive летают раз в секунду. Вы можете настроить как keepalive interval, так и hold-timeout (по умолчанию последний равен 3 секундам). Таймер hold запускает в момент падения vPC peer link. В течение этого интервала времени secondary vPC peer игнорирует все keepalive сообщения для того, чтобы сетка смогла конвергировать.
Также есть понятие просто timeout’а. Этот таймер стартует в момент, когда счетчик hold-timeout достигает нуля. В течение timeout-интервала secondary vPC peer слушает hello keepalive от primary устройства. При получении единичного hello на secondary-устройстве блокируются все порты. Если же keepalive так и не будет получен, то secondary берет на себя роль active.
Данная фича позволяет vPC свитчу быть гейтом для пакетов, которые адресованы на МАС-адрес vPC соседа. Таким образом достигается оптимизация использования vPC peer линка. При включении данной технологии NX-OS отключает IP redirect на всех vlan-интерфейсах, которые относятся к vPC домену.
Compatibility параметры
Большинство настроек на интерфейсах двух коммутаторов в vPC домене должны быть идентичны. Если это не так, то могут быть большие проблемы (например, на одном свитче настроен trunk, а на другом access). Соответственно за конфигурацией на vPC пирах надо следить. Как только вы включаете vPC, автоматически протол активируется CFSoE (Cisco Fabric Services over Ethernet), который следит за идентичностью конфигураций.
Прим. Два vPC пира имеют разные control и management-plane. Соответственно и настраиваются они по-отдельности. CFSoE лишь может сравнить конфиги устройств.
Ниже приведен список параметров, которые обязаны совпадать:
Параметры, которые желательно должны совпадать:
Если какие-то из обязательных параметров не совпадают, то «проблемные» интерфейсы secondary устройства гасятся. Такая проверка у циски называется consistency parameter check. Работает она per vlan basis.
vPC номер
После создания vPC домена и vPC peer link, Вы настраиваете portchannel в сторону нижестоящего устройства. Каждому такому portchannel Вы должны назначить некий номер (vPC number), который должен быть одинаковым на обоих vPC пирах.
Типовые схемы vPC
Ниже на картинках Вы увидите типовые схемы, в которых внедряется vPC.
Взаимодействие vPC и других технологий
vPC и LACP
При построении LACP-соседства между vPC доменом и обычным коммутатором в качестве LACP ID используется MAC-адрес vPC домена.
vPC и STP
После перехода с классической топологии на vPC начинается конвергенция STP. Для STP vPC peer-link является постоянно активным. Primary vPC коммутатор управляет всем STP процессом: синхронизирует STP состояния со вторым коммутатором используя CFSoE. В служебных сообщениях BPDU в поле Bridge ID выставляется MAC-адрес vPC домена.
vPC и ARP
Таблица ARP’а также синхронизируется между участниками vPC посредством CFSoE (для этого необходимо ввести команду ip arp synchronize.
Ограничения и правила vPC
Конфигурация и верификация
В целом настройка vPC не представляет собой большой сложности.
Прим. Нужно лишь отдавать себе отчет о том, на какой платформе вы его строите (5k/7k) – ибо они поддерживают разные топологии (которые могут меняться в зависимости от версии NX—OS). За актуальной информацией обращайтесь на design zone по адресу http://cisco.com/go/srnd, раздел Data Center.
В этой конкретной статье мы рассмотрим один пример построения vPC на Nexus7000. Топология представлена ниже.
Первым делом необходимо включить поддержку vPC командой feature vpc.
(*) — local vPC is down, forwarding via vPC peer-link
Peer status : peer link not configured
vPC keep-alive status : peer is alive
Configuration consistency status: failed
Configuration consistency reason: vPC peer-link does not exists
vPC role : none established
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : —
После поднятия peer-keepalive приходит время создать peer link. Для этого сначала помещаем нужные интерфейсы в trunk PortChannel, а затем внутри интерфейса даем команду vpc peer—link. Обращаю Ваше внимание на то, что если для peer-keepalive используются SVI-интерфейсы, то запретите данную vlan внутри peer-link.
(*) — local vPC is down, forwarding via vPC peer-link
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status: success
vPC role : secondary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : —
vPC Peer-link status
id Port Status Active vlans
Если Вы видите что домен у Вас не поднимается, то скорее всего на 2ух коммутаторах где-то различаются настройки. Для проверки используйте следующую команду:
N7K-1# show vpc consistency-parameters global
Type 1 : vPC will be suspended in case of mismatch
Name Type Local Value Peer Value
STP Mode 1 Rapid-PVST Rapid-PVST
STP Disabled 1 VLANs 91 VLANs 91
STP MST Region Name 1 customer Customer
STP MST Region Revision 1 1 1
STP MST Region Instance to 1
STP Loopguard 1 Disabled Disabled
STP Bridge Assurance 1 Enabled Enabled
STP Port Type, Edge 1 Normal, Disabled, Normal, Disabled,
BPDUFilter, Edge BPDUGuard Disabled Disabled
STP MST Simulate PVST 1 Enabled Enabled
Interface-vlan admin up 2 40-43,50,60,70-71,91,1 40-43,50,60,70-
Allowed VLANs — 40-43,50,60,91,100-103 9,40-
Local suspended VLANs — — —
После поднятия непосредственно vPC домена остается лишь помещать необходимы интерфейсы в сторону коммутаторов/серверов/FEX’ов внутрь vPC. Делается это командой vpc в режиме конфигурирования необходимого интерфейса. Этот номер должен быть идентичным на обоих vPC пирах. После этого интерфейс добавится в вывод команды show vpc.
(*) — local vPC is down, forwarding via vPC peer-link
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status: success
Number of vPCs configured : 1
Peer Gateway : Disabled
Dual-active excluded VLANs : —
vPC Peer-link status
id Port Status Active vlans
id Port Status Consistency Reason Active vlans
1 Po1 up success success 1-20,100
Также хотелось бы остановить внимание на команде vpc orphan—ports suspend, которая задается в режиме конфигурирования интерфейса. Делает она следующее: если vPC домен развалился, то необходимо погасить данный порт в случае, если он является orphan. Полные конфиги представлены ниже.
Network notes
Записи из мира сетевых технологий
воскресенье, 8 января 2017 г.
Cisco Nexus vPC, FEX
N7K(config)#vpc domain 1
N7K(config-vpc-domain)#role priority 1
vPC роль не вытесняемая (non-preemptive)!
Роли 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 vpc
N7K(config)#feature lacp
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 только к одному из коммутаторов).
Рекомендации по настройке Peer Keepalive:
-Использовать отдельный L3 Etherchannel на двух разных линейных картах (1GE/10GE), в отдельном VRF. (предпочтительный вариант для N7K)
-Использовать Mgmt0 интерфейсы коммутаторов (предпочтительный вариант для N5K, можно использовать и с N7K, соединив интерфейсы супервизоров через обычный L2 коммутатор, не напрямую!)
-Использовать SVI (не рекомендуется к использованию, может привести к развалу vPC в некоторых случаях).
В случае использования SVI интерфейсов для Peer Keepalive крайне желательно (можно сказать обязательно) использовать отдельный L2 Trunk между коммутаторами и отдельный не vPC VLAN (на vPC Peer линке не разрешать этот VLAN). А при использовании MST так же настроить отдельный Instance.
Как и в случае с Peer Link, для N7K должен использоваться одинаковый тип линейных карт на каждом из vPC пиров.
1.2 vPC Loop Prevention и Orphan:
Для защиты от петель vPC использует следующее правило:
Трафик, который пришел на коммутатор с vPC Peer Link не может быть передан на vPC Member Port, но может быть передан на Orphan порт или L3 интерфейс. За это правило отвечает механизм «vPC Check».
1.3 vPC Consistency:
В случае несовпадения какого-либо из 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]
-После создания vPC Peer-Link на нём так же включается STP Bridge Assurance.
-Только vPC Primary коммутатор генерирует BPDU, но при этом он может не являться STP Root. В случае конфигурации по умолчанию vPC Primary будет являться STP Root (т.к. выборы происходят на основе наименьшего системного MAC, как и в STP). Каждый коммутатор использует свой System MAC в качестве BID (Root ID). Для нижестоящих устройств Root Primary коммутатора.
-vPC Secondary только передает полученные BPDU от нижестоящих коммутаторов Primary пиру через Peer Link.
-vPC пиры синхронизируют состояние STP портов (STP Port States) на своих vPC Member интерфейсах.
-По умолчанию каждый коммутатор имеет свой BID=System MAC+Priority.
У vPC для STP есть оптимизация под названием «Peer-switch», которая позволяет видеть оба vPC пира как единый STP Root. Коммутаторы используют общий Virtual BID, который формируется из vPC system-mac и приоритета. Эта оптимизация позволяет не перестраивать STP дерево в случае падения Primary vPC пира и не тратить время на сходимость (актуально в Hybrid Setup дизайне).
Если нижестоящий коммутатор подключен по vPC (vPC-attached): Root BID.
Если нижестоящий коммутатор подключен по STP (STP-attached): Root BID; Bridge MAC.
Настройка vPC peer-switch:
N7K1#vpc domain 1
N7K1#peer-switch
!
N7K2#vpc domain 1
N7K2#peer-switch
Более простым вариантом является опция под названием STP pseudo-information.
Она позволяет независимо настраивать STP Bridge Priority и STP Root Priority для STP-attached коммутаторов, позволяя тем самым выполнять настройки по балансировке для каждого VLAN.
2.Сценарии vPC, примеры настройки
2.1 Classic vPC:
vPC настраивается между двумя коммутаторами N7K, в качестве нижестоящего коммутатора используется N5K (либо любой другой, либо сервер) на котором настраивается обычный LACP.
N7K1(config)#vrf context KEEPALIVE
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 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)
!
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
Команды для проверки:
#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(config)#vpc domain 1
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
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
Для vPC-attached коммутаторов Root ID будет идентичен с Bridge ID и иметь значение 0023.04ee.be01, а priority=0.
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.
— Т.к. 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
Плюсы и минусы использования FEX:
+ Стоимость FEX ниже, чем стоимость полноценных коммутаторов N3K, N5K, N6K.
+ Единая точка управления с родительского коммутатора всеми FEX.
— Переподписка (минимум 2:1).
— Не очень оптимальны при большом количестве East-West трафика.
#install feature-set fex
#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
4.1 vPC+FEX (Host vPC):
Рекомендуемый дизайн, поддерживается как на N5K/N6K, так и на N7K. vPC строится только от FEX до серверов, каждый FEX подключается только к 1 родительскому коммутатору (Single-homed FEX).
Команды для проверки:
#show fex [detail]
#show interfaces status fex 101
#show interface fex-fabric
С точки зрения конфигурации для EvPC не нужно настраивать vPC от FEX в сторону серверов (host vPC mode), коммутатор сам выполняет эту настройку, автоматически присваивая внутренний номер vPC, настройка вручную не поддерживается.
