Vpc cisco что это

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, настройка вручную не поддерживается.

Источник

Есть ли стекирование в коммутаторах 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’ах нет локальной коммутации. Пакеты между соседними портами передаются через родительское устройство. А значит имеем повышенную нагрузку на канал между ними.

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

Источник

Virtual Port Channel Operations

Available Languages

Download Options

Table of Contents

Virtual Port Channel Operations

This chapter describes the best practices and operational procedures for the virtual port channel (vPC) feature on Cisco Nexus 5000 Series switches that run Cisco NX-OS Release 5.0(2)N2(1) and earlier releases.

This chapter includes the following sections:

Information About vPC Operations

A vPC allows links that are physically connected to two different Cisco Nexus 5000 Series switches to appear as a single port channel to a third switch. The third switch can be a Cisco Nexus 2000 Series Fabric Extender or a switch, server, or any other networking device. A vPC can provide Layer 2 multipath capability which allows you to create redundancy by increasing bandwidth, enabling multiple parallel paths between nodes, and load-balancing traffic where alternative paths exist.

For a quick overview of vPC configurations, see the Virtual PortChannel Quick Configuration Guide at the following URL: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/configuration_guide_c07-543563.html

vPC Consistency Checks

This section includes the following topics:

Type 1 and Type 2 Consistency Check Parameters

Before a Cisco Nexus 5000 Series switch brings up a vPC, the two Cisco Nexus 5000 Series switches in the same vPC domain exchange configuration information to verify if both switches have compatible configurations for a vPC topology. Depending on the severity of the impact of possible mismatched configurations, some configuration parameters are considered as Type 1 consistency check parameters while others are considered as Type 2.

When a mismatch in Type 1 parameters occur, the following applies:

Note The graceful consistency check is a new feature introduced in Cisco NX-OS Release 5.0(2)N2(1) and is enabled by default. For more details, see the “Graceful Consistency Check” section.

When Type 2 parameters exist, a configuration mismatch generates a warning syslog message. The vPC on the Cisco Nexus 5000 Series switch remains up and running. The global configuration, such as Spanning Tree Protocol (STP), and the interface-level configurations are included in the consistency check.

The show vpc consistency-parameters global command lists all global consistency check parameters. Beginning with Cisco NX-OS Release 5.0(2)N1(1), QoS parameters have been downgraded from Type 1 to Type 2.

This example shows how to display all global consistency check parameters:

Use the show vpc consistency-parameters interface port-channel number command to display the interface-level consistency parameters.

This example shows how to display the interface-level consistency parameters:

The Cisco Nexus 5000 Series switch conducts vPC consistency checks when it attempts to bring up a vPC or when you make a configuration change.

In the interface consistency parameters shown in the above output, all configurations except the Allowed VLANs are considered as Type 1 consistency check parameters. The Allowed VLAN (under the trunk interface) is considered as a Type 2 consistency check parameter. If the Allowed VLAN ranges are different on both VLANs that means that only common VLANs are active and trunked for the vPC while the remaining VLANs are suspended for this port channel.

Graceful Consistency Check

Beginning with Cisco NX-OS Release 5.0(2)N2(1) and later releases, when a Type 1 mismatch occurs, by default, the primary vPC links are not suspended. Instead, the vPC remains up on the primary switch and the Cisco Nexus 5000 Series switch performs Type 1 configurations without completely disrupting the traffic flow. The secondary switch brings down its vPC until the inconsistency is cleared.

However, in Cisco NX-OS Release 5.0(2)N2(1) and earlier releases, this feature is not enabled for dual-homed FEX ports. When Type-1 mismatches occur in this topology, the VLANs are suspended on both switches. The traffic is disrupted on these ports for the duration of the inconsistency.

To minimize disruption, we recommend that you use the configuration synchronization feature for making configuration changes on these ports.

To enable a graceful consistency check, use the graceful consistency-check command. Use the no form of this command to disable the feature. The graceful consistency check feature is enabled by default.

This example shows how to enable a graceful consistency check:

This example shows that the vPC ports are down on a secondary switch when an STP mode mismatch occurs:

This example shows that the vPC ports and the VLANs remain up on the primary switch when an STP mode mismatch occurs:

This example shows that the vPC ports are down on a secondary switch when an interface-level Type 1 inconsistency occurs:

This example shows that the vPC ports and the VLANs remain up on the primary switch when an interface-level Type 1 inconsistency occurs:

Configuring Per-VLAN Consistency Checks

Beginning with Cisco NX-OS Release 5.0(2)N2(1), the Cisco Nexus 5000 Series switch performs Type-1 consistency checks on a per-VLAN basis when you enable or disable STP on a VLAN. VLANs that do not pass this consistency check are brought down on the primary and secondary switches while other VLANs are not affected.

When you enter the no spanning-tree vlan number command on one peer switch, only the specified VLAN is suspended on both peer switches; the other VLANs remain up.

Note Per-VLAN consistency checks are not dependent on whether graceful consistency checks are enabled.

This example shows the active VLANs before suspending a specified VLAN:

This example shows that VLAN 5 is suspended but the remaining VLANs are up:

Identifying Inconsistent vPC Configurations

The show vpc command displays the vPC status and the vPC consistency check result for the global consistency check and the interface-specific consistency check.

This example shows the global vPC consistency check failed because of the mismatched Network QoS configuration:

You can use the show vpc consistency-parameters global command to identify the configuration difference between two vPC peer switches.

This example shows the global consistency check failed because the STP mode was configured differently on the two vPC switches:

You can use the show vpc command also shows the vPC consistency check result for each vPC and the reason for the consistency check failure.

This example shows how to display the vPC consistency check status:

If the consistency check fails, the consistency check is not performed on vPC member ports that are down.

If the consistency check has succeeded and the port is brought down, the consistency check shows that it was successful.

You can use the show vpc consistency-parameters interface ethernet slot/port command to identify the configuration difference that leads to a consistency check failure for a specified interface or port channel.

This example shows how to display configuration differences that lead to consistency check failures.

Bypassing a vPC Consistency Check When a Peer Link is Lost

The vPC consistency check message is sent by the vPC peer link. The vPC consistency check cannot be performed when the peer link is lost. When the vPC peer link is lost, the operational secondary switch suspends all of its vPC member ports while the vPC member ports remain on the operational primary switch. If the vPC member ports on the primary switch flaps afterwards (for example, when the switch or server that connects to the vPC primary switch is reloaded), the ports remain down due to the vPC consistency check and you cannot add or bring up more vPCs.

Beginning with Cisco NX-OS Release 5.0(2)N2(1), the auto-recovery feature brings up the vPC links when one peer is down. This feature performs two operations:

Note The auto-recovery feature in Cisco NX-OS Release 5.0(2)N2(1) and later releases replaces the reload restore feature in Cisco NX-OS Release 5.0(2)N1(1) and earlier releases.

The auto-recovery feature is disabled by default. To enable auto-recovery, enter the auto-recovery command in the vPC domain mode.

This example shows how to enable the auto-recovery feature and to set the reload delay period:

Источник