Коммутаторы : Коммутаторы Cisco Nexus серии 7000

Пример конфигурации Nexus 7000 vPC Автофункции восстановления

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает, как настроить действительный PortChannel (vPC) автофункция восстановления на Nexus 7000.

Внесенный вирусным Bhutta, специалистом службы технической поддержки Cisco.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Общие сведения

Почему нам нужно Auo-восстановление vPC?

Существует две основных причины для этого усовершенствования vPC:

  • В простое ЦОД или перебое в питании, оба узла vPC, которые состоят из Коммутаторов Nexus 7000, выключены. Иногда, только один из узлов может быть восстановлен. Так как другой Nexus 7000 все еще выключен, vPC peer-link и ссылка одноранговой поддержки активности vPC также выключены. В этом сценарии vPC не продвигается даже для Nexus 7000, который уже включен. Все конфигурации vPC должны быть удалены из port-channel на том Nexus 7000, чтобы заставить port-channel работать. Когда другой Nexus 7000 продвигается, необходимо снова изменить конфигурацию для включения конфигурации vPC для всего vPCs. В Выпуске 5.0 (2) и позже, можно настроить команду восстановления повторной загрузки под конфигурацией vPC domain для рассмотрения этой проблемы.
  • По некоторым причинам vPC peer-link уходит. Так как одноранговая поддержка активности vPC все еще включена, vPC, вторичное одноранговое устройство выключает все свои участвующие порты vPC из-за двойного активного обнаружения. Следовательно весь трафик проходит vPC основной коммутатор. По некоторым причинам vPC основной коммутатор также уходит. Эта проблема коммутатора черные дыры, трафик начиная с vPCs на вторичном одноранговом устройстве все еще выключен, потому что это обнаружило двойное активное обнаружение перед vPC основной коммутатор, ушла.

В Выпуске 5.2 (1) и позже, автофункция восстановления vPC объединяет эти два усовершенствования.

!--- конфигурацию

Конфигурация автовосстановления vPC является прямой. Необходимо настроить автовосстановление под vPC domain на обоих узлах vPC.

Это - пример конфигурации:

На коммутаторе S1

S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc
Legend:
               (*) - local vPC is down, forwarding via vPC peer-link
vPC domain id                    : 1 
Peer status                      : peer adjacency formed ok    
vPC keep-alive status            : peer is alive
Configuration consistency status : success
Per-vlan consistency status      : success
Type-2 consistency status        : success
vPC role                         : primary
Number of vPCs configured        : 5 
Peer Gateway                     : Enabled
Peer gateway excluded VLANs      : -
Dual-active excluded VLANs       : -
Graceful Consistency Check       : Enabled
Auto-recovery status             : Enabled (timeout = 240 seconds)

vPC Peer-link status
---------------------------------------------------------------------
id  Port  Status Active vlans  
--  ----  ------ --------------------------------------------------
1   Po1   up     1-112,114-120,800,810
                                
vPC status
-----------------------------------------------------------------------
id  Port  Status Consistency Reason                    Active vlans
--  ----  ------ ----------- ------                    ------------
10  Po40  up    success    success                   1-112,114-1
                                                         20,800,810    

На коммутаторе S2

S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2# show vpc
Legend:
              (*) - local vPC is down, forwarding via vPC peer-link
vPC domain id                    : 1 
Peer status                      : peer adjacency formed ok    
vPC keep-alive status            : peer is alive               
Configuration consistency status : success
Per-vlan consistency status      : success
Type-2 consistency status        : success
vPC role                         : secondary
Number of vPCs configured        : 5 
Peer Gateway                     : Enabled
Peer gateway excluded VLANs      : -
Dual-active excluded VLANs       : -
Graceful Consistency Check       : Enabled
Auto-recovery status             : Enabled (timeout = 240 seconds)

vPC Peer-link status
---------------------------------------------------------------------
id  Port  Status Active vlans  
--  ----  ------ --------------------------------------------------
1   Po1   up    1-112,114-120,800,810
                                 
vPC status ----------------------------------------------------------------------
id  Port  Status Consistency Reason                    Active vlans
--  ----  ------ ----------- ------                    ------------
40  Po40  up    success    success                   1-112,114-1
                                                         20,800,810    

Как действительно работает автовосстановление?

В этом разделе рассматриваются каждое поведение, упомянул в фоновом режиме Раздел сведений отдельно. Предположение - то, что автовосстановление vPC настроено и сохранено к загрузочной конфигурации на обоих коммутаторах S1 и S2.

  1. Перебой в питании отключает и узлы Nexus 7000 vPC одновременно и только один коммутатор, в состоянии продвинуться.
    116187-configure-vPC-01.jpg
    • S1 и S2 оба включены. vPC сформирован правильно с одноранговой ссылкой и одноранговой поддержкой активности на.
    • И S1 и S2 выключаются одновременно.
    • Теперь только один коммутатор в состоянии включиться. Например, S2 является единственным коммутатором, который включается.
    • S2 ждет таймаута автовосстановления vPC (по умолчанию составляет 240 секунд, которые могут быть настроены с задержкой повторной загрузки автовосстановления x команда, где x составляет 240-3600 секунд), чтобы проверить, включаются ли или vPC peer-link или одноранговое состояние поддержки активности. Если какая-либо из этих ссылок идет (одноранговая ссылка или одноранговое состояние поддержки активности), автовосстановление не инициировано.
    • После таймаута, если обе ссылки все еще выключены (одноранговая ссылка, а также одноранговое состояние поддержки активности), автовосстановление vPC включает, и S2 становится основным и инициирует для включения его локального vPC. С тех пор нет никаких узлов, проверка согласованности обойдена.
    • Теперь S1 продвигается. В это время S2 сохраняет свою основную роль, и S1 берет дополнительную роль, проверка согласованности выполнена, и соответствующие меры приняты.
  2. vPC peer-link выключается сначала, и затем основной узел vPC выключается.
    116187-configure-vPC-02.jpg
    • S1 и S2 и включены и vPC, сформирован правильно с одноранговой ссылкой и одноранговой поддержкой активности на.
    • По некоторым причинам vPC peer-link уходит сначала.
    • Так как одноранговая поддержка активности vPC все еще включена, она обнаруживает двойное активное обнаружение. VPC вторичный S2 выключает весь свой локальный vPCs.
    • Теперь vPC основной S1 уходит или перезагружается.
    • Этот простой также выключает ссылку одноранговой поддержки активности vPC.
    • S2 ждет трех последовательных одноранговых сообщений поддержки активности, которые будут потеряны. По некоторым причинам или vPC peer-link продвигается или S2, получает одноранговое сообщение поддержки активности, и автовосстановление не включает.
    • Однако, если одноранговая ссылка остается прочь, и три последовательных одноранговых сообщения поддержки активности потеряны, автовосстановление vPC включает.
    • S2 принимает роль основного и включает его локального vPC, который обходит проверку согласованности.
    • Когда S1 завершает повторную загрузку, S2 сохраняет свою роль основных, и S1 становится вторичным, проверка согласованности выполнена, и соответствующие меры приняты.

Примечание: Как объяснено в обоих сценариях, коммутатор, который не приостанавливает его роль vPC с автовосстановлением vPC, продолжает оставаться основным даже после того, как идет одноранговая ссылка. Другой узел берет роль вторичного устройства и приостанавливает его собственного vPC, пока проверка согласованности не завершена.

Пример:

S1 выключен. S2 становится в рабочем состоянии основным как ожидалось. Одноранговая ссылка и одноранговая поддержка активности и все ссылки vPC разъединены от S1. S1 не включен. Так как S1 полностью изолирован, он включает vPC (невзирая на то, что физические соединения не работают), из-за автовосстановления, и берет роль основного. Теперь, если одноранговая ссылка или одноранговая поддержка активности связаны между S1 и S2, S1 поддерживает роль основных, и S2 становится вторичным. Эта конфигурация заставляет S2 приостанавливать своего vPC, пока и vPC peer-link и одноранговая поддержка активности не включены, и проверка согласованности завершена. Этот сценарий вызывает трафик к черной дыре, так как S2 vPC вторичен, и физические соединения S1 выключены.

Я должен включить автовосстановление vPC?

Это - полезный прием для включения автовосстановления в среде vPC.

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

В этой ситуации каждый участвующий порт vPC продолжает объявлять тот же ID Протокола управления агрегацией каналов, который это сделало перед двойным активным сбоем.

Топология vPC внутренне защищает от петель в случае двойных активных сценариев. В наихудшем случае существуют дублированные кадры. Несмотря на это, как механизм предотвращения петель, каждый коммутатор вперед Bridge Protocol Data Units (BPDU) с тем же Идентификатором моста BPDU как до vPC двойной активный сбой.

В то время как не интуитивный, это все еще возможно и выбираемо продолжить передавать трафик от уровня доступа до уровня агрегации без отбрасываний для текущих трафиков, при условии, что таблицы протокола разрешения адресов (ARP) уже заполнены на обоих Cisco Nexus узлы серии 7000 для всех необходимых хостов.

Если новые MAC-адреса должны быть изучены таблицей ARP, проблемы могли бы возникнуть. Проблемы возникают, потому что ответ ARP от сервера мог бы быть хеширован к одному Cisco Nexus устройство серии 7000 а не к другому, который лишает возможности трафик течь правильно.

Предположим, однако, что перед сбоем в ситуации, просто описанной, трафик был одинаково распределен и Cisco Nexus устройства серии 7000 корректным PortChannel и Равной стоимостью, Многопутевой (ECMP) конфигурация. В этом случае трафик от сервера к серверу и клиента к серверу продолжает предупреждение, что одиночно подключенные хосты, связанные непосредственно к Cisco Nexus, серии 7000, не будут в состоянии связаться (из-за отсутствия одноранговой ссылки). Кроме того, новые MAC-адреса, изученные на одном Cisco Nexus, серии 7000, не могут быть изучены на узле, потому что это вызвало бы ответный трафик, который поступает в одноранговый Cisco Nexus устройство серии 7000 для затопления.

См. страницу 19 программного обеспечения Cisco NX-OS Действительный PortChannel: Основные понятия для получения дополнительной информации.

Проверка

В настоящее время для этой конфигурации нет процедуры проверки.

Устранение неполадок

Для этой конфигурации в настоящее время нет сведений об устранении проблем.

Дополнительные сведения



Document ID: 116187