изменение роли vPC, как вернуться к фактической роли

[keen4.net]

просьба ответить

[Jevgeni Rõžov]

Здравствуйте, Вы все еще не ответили на первоначальный вопрос — как заставить рабочее вторичное устройство Nexus стать рабочим основным? Перезагрузка рабочего основного устройства не входит в вопрос.

[Daniel ElHani]

Из всего, что я прочитал, похоже, что есть только два «некрасивых» способа достичь этого: 1- перезагрузить вторичный коммутатор (работающий в качестве основного) или 2- переключить (закрыть/открыть) соединение с одноранговым узлом на
вторичном коммутаторе (работающем в качестве основного) — я предполагаю, что приоритеты ролей настроены правильно И да, ожидается кратковременное прерывание Надеюсь, кто-нибудь знает третий, менее жесткий подход С уважением Ps: похоже, что второй метод даже не является вариантом (NOS5.x)! http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/design_guide_c07-625857.html#_Toc271759447 упоминает, что если канал keepalive не отключается, роль не изменится! Но подключение keep alive вместе с peer link приведет к разделению мозга, поэтому, похоже, вариант 1 является единственным безопасным вариантом.

[Billm]

Если вы используете код версии 7, то есть следующее: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x_chapter_0100... Настройка бесперебойной смены ролей vPC Выполните следующие действия, чтобы включить бесперебойное изменение роли vPC.
Перед началом
• Убедитесь, что функция vPC включена.
• Убедитесь, что соединение vPC peer link работает.
• Проверьте приоритет ролей устройств.
Процедура
Команда или действие
Цель
Шаг
vpc role preempt
Пример:
switch#
vpc role preempt
switch(config)#
Включить бесперебойное изменение роли vPC.
Шаг 2
show vpc role
Пример:
switch(config)#
show vpc role
(Необязательно) Проверьте функцию бесперебойного изменения роли vPC.
Пример настройки бесперебойного изменения роли vPC:
switch#
show vpc role
vPC Role status

vPC role : secondary
vPC system-mac : 00:23:04:ee:be:01
vPC system-priority : 32667
vPC local system-mac : 8c:60:4f:03:84:41
vPC local role-priority : 32668
vPC peer system-mac : 8c:60:4f:03:84:43
vPC peer role-priority : 32667 ! Configure vPC hitless role change on the device! switch(config)#
vpc role preempt
! The following is an output from the show vpc role command after the
vPC hitless feature is configured switch(config)#
show vpc role
vPC Role status

vPC role : primary
vPC system-mac : 00:00:00:00:00:00
vPC system-priority : 32667
vPC local system-mac : 8c:60:4f:03:84:41
vPC local role-priority : 32666
vPC peer system-mac : 8c:60:4f:03:84:43
vPC peer role-priority : 32667 switch(config)# Сценарий использования для изменения роли vPC
Функция бесперебойного изменения роли vPC может использоваться в следующих сценариях:
Запрос на изменение роли — когда необходимо изменить роли одноранговых устройств в домене vPC.
Перезагрузка основного коммутатора — когда устройства запускаются после перезагрузки и роли определены, можно использовать функцию бесперебойной смены ролей vPC для восстановления ролей. Например, после перезагрузки, если основное устройство принимает роль рабочего вторичного устройства, а вторичное устройство принимает роль рабочего основного устройства, можно изменить роли одноранговых устройств vPC на их исходные определенные роли с помощью
команды
vpc role
preempt
.

Примечание
Перед переключением роли vPC всегда проверяйте приоритет существующей роли устройства.
Двойное активное восстановление — в сценарии двойного активного восстановления основной коммутатор vPC продолжает быть (рабочим) основным, но вторичный коммутатор vPC становится целевым основным коммутатором и поддерживает работоспособность своих портов-членов vPC. Вы можете использовать функцию vPC hitless и восстановить роли устройств. После двойного активного восстановления, если одна сторона является рабочим первичным устройством, а другая — рабочим вторичным устройством, вы можете использовать команду
vpc role
preempt
, чтобы восстановить роли устройств как первичные и вторичные.

[Abhi_d_koenig]

Просто выполните следующую команду AGPRI# vpc role preempt
Убедитесь, что peer-switch включен и работает («show spanning-tree summary»). Продолжить (да/нет)? [нет] да
AGPRI#

[Stuff]

Пробовал это в режиме настройки на 5596s и получил сообщение «сервис не отвечает». Я разочарован, что они не поддерживают эту команду.

[Stephan Grohmann]

Уважаемые [коллеги] , я считаю, что утверждение о победе более высокого приоритета роли является неверным. Cisco четко заявляет, что победу в выборе одерживает более НИЗКИЙ приоритет роли. https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/212589-understanding-vpc-election-process.html#anc7 Приоритет роли vPC Вы также можете использовать команду «role priority» в режиме домена vPC, чтобы повлиять на процесс выбора vPC. Диапазон значений составляет от 1 до 65636, а значение по умолчанию — 32667. Более низкое значение означает, что этот коммутатор имеет больше шансов стать основным vPC. С уважением, Стефан

[tudor bucenica]

Привет,
Cisco рекомендует сопоставить основную роль vPC (операционную) с корнем STP и HSRP active.
Если вы хотите изменить операционную роль с одного устройства на другое, измените приоритет роли домена vpc (меньший выигрывает выборы). Это не является превентивной мерой.
!!Во время окна обслуживания!! шаги должны быть следующими (вы хотите сделать A основным операционным; B в настоящее время является основным операционным):

1. измените приоритет роли на устройстве A; приоритет роли
   домена
   vpc 1 lower_value_than_B_priority
2. Проверьте sticky bit на обоих устройствах
   «show sys internal vpcm info all | i i stick» Пример вывода:
   N7K# show system internal vpcm info all | i i sticky
   Sticky Master: FALSE
   Коммутатор B должен иметь значение FALSE, а A — TRUE. 3. Если B по-прежнему имеет значение TRUE, повторно примените к нему текущее настроенное значение. Это означает повторное применение исходной конфигурации для приоритета роли. Если приоритет роли является стандартным, повторно примените стандартное значение. Эта операция повторно инициирует бит sticky.
   vpc domain 1
   role priority same_priority_as_before 4. Снова проверьте вывод команды «show sys internal vpcm info all | i i stick». Теперь значение B должно быть FALSE, а A — TRUE. 5. Закройте соединение vPC peer link (НЕ соединение keep-alive). 6. Проверьте, изменилась ли роль, с помощью show vpc brief 7. Восстановите соединение vPC peer. Справочная информация
   — проверьте бит Sticky. См. раздел «Вариант 1. Поэтапный подход» в этом документе
   https://www.cisco.com/c/en/us/support/docs/interfaces-modules/nexus-7000-series-supervisor-1-module/119033-technote-nexus-00.html#anc7

• «Вы также можете настроить, какое из устройств vPC будет основным. Изменение приоритета устройств vPC peer может привести к сбоям в работе интерфейсов в вашей сети. Если вы хотите снова настроить приоритет роли, чтобы одно устройство vPC стало основным, настройте приоритет роли как на основном устройстве vPC с более низким значением приоритета, так и на вторичном устройстве vPC с более высоким значением. Затем отключите портовый канал, который является одноранговым соединением vPC на обоих устройствах, введя команду shutdown, и, наконец, снова включите портовый канал на обоих устройствах, введя команду no shutdown». Взято отсюда
  https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/interfaces/configuration/guide/b-Cisco-Nexus-7000-Series-NX-OS-Interfaces-Configuration-Guide-Book/configuring-vpcs.html

[M_Neman]

Это сообщение, похоже, слишком старое, и я надеюсь, что вы нашли решение. Если нет, то, исходя из моего опыта (у нас была такая же проблема)
,
вам нужно следовать рекомендациям
[Евгения Рёжова]
: 1. либо перезагрузите вторичный коммутатор 2. либо отключите/не отключайте соседние ссылки. В нашем случае мы обновляли программное обеспечение, и оба коммутатора пришлось перезагрузить.

[robert.lorrison]

Наткнулся на эту ветку в поиске Google. Автор сообщения столкнулся с проблемой, когда настроенный вторичный коммутатор (Nexus-9K-2, приоритет роли vPC 2) работал в качестве основного, несмотря на то, что у него был явно БОЛЕЕ ВЫСОКИЙ приоритет, чем у Nexus-9K-1 (приоритет роли vPC 1). Обычно это происходит во время обновления программного обеспечения, когда вторичный коммутатор перезагружается первым, принимает на себя управление при перезагрузке основного коммутатора и остается в этом состоянии после возобновления работы основного коммутатора. Причина этого заключается в том, что (в отличие от HSRP или VRRP) роли Nexus vPC НЕ перехватывают управление автоматически. К счастью
,
есть простое решение (как упомянул
[Abhi_d_koenig]
), просто введите команду «vpc role preempt» в привилегированном режиме EXEC на настроенном основном коммутаторе. Он запросит настроенные приоритеты ролей vPC на обоих коммутаторах и подтвердит, что может перехватить приоритет. Вы должны увидеть предупреждение о сводке spanning-tree и подтверждение того, что peer-switch включен и работает, если это так, то все в порядке. Это также является частью процедуры плавного (без сбоев) изменения роли vPC.

[johnlloyd_13]

Привет, я столкнулся с той же проблемой, когда сначала перезагрузил вторичный узел Nexus, а затем первичный. Ping работал с перебоями, и SSH/AAA переключились на локального пользователя для этого сайта. Вторичный узел стал «вторичным, рабочим первичным», а первичный — «первичным, рабочим вторичным». Я попытался отключить peerlink во вторичном (рабочем первичном), но это не решило проблему. Выполнил «vpc role preempt» во вторичном узле, чтобы восстановить исходную настройку VPC, и трафик нормализовался. Мои вопросы: 1. Является ли лучшей практикой сначала обновить основной коммутатор Nexus, независимо от конфигурации preempt? 2. «Preempt» настроен только в первичном коммутаторе Nexus, поэтому, когда я сначала перезагружаю вторичный, а затем первичный, формируется исходная настройка VPC? 3. Может ли кто-нибудь поделиться «лучшей практикой» настройки VPC для основного и вторичного коммутатора Nexus, чтобы я мог предотвратить подобную проблему, когда вторичный коммутатор застревает в «операционном основном» режиме?