목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

배경 정보

구성

다음을 확인합니다.

문제 해결

관련 정보

소개

이 문서에서는 Nexus 7000에서 vPC(virtual PortChannel) 자동 복구 기능을 구성하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

vPC Auto-Recovery가 필요한 이유

이 vPC가 향상된 이유는 두 가지가 있습니다.

- 데이터 센터 중단 또는 정전 시 Nexus 7000 스위치로 구성된 vPC 피어 모두 꺼집니다.경우에 따라 피어 중 하나만 복원할 수 있습니다.다른 Nexus 7000이 아직 꺼져 있으므로 vPC peer-link 및 vPC peer-keepalive 링크도 꺼져 있습니다.이 시나리오에서는 이미 켜져 있는 Nexus 7000에 대해서도 vPC가 켜지지 않습니다.포트 채널이 작동하도록 Nexus 7000의 포트 채널에서 모든 vPC 컨피그레이션을 제거해야 합니다.다른 Nexus 7000이 켜지면 모든 vPC에 대한 vPC 컨피그레이션을 포함하도록 컨피그레이션을 다시 변경해야 합니다.릴리스 5.0(2) 이상에서는 vPC 도메인 컨피그레이션 아래 reload restore 명령을 구성하여 이 문제를 해결할 수 있습니다.

- 어떤 이유로 vPC 피어 링크는 해제됩니다.vPC peer-keepalive가 계속 켜져 있으므로 vPC 보조 피어 디바이스는 듀얼 액티브 탐지로 인해 모든 vPC 멤버 포트를 끕니다.따라서 모든 트래픽이 vPC 기본 스위치를 통과합니다.어떤 이유로 vPC 기본 스위치도 꺼집니다.이 스위치 문제는 vPC 기본 스위치가 꺼지기 전에 듀얼 액티브 탐지를 탐지했기 때문에 보조 피어 디바이스의 vPC가 여전히 꺼져 있기 때문에 트래픽에 블랙홀(black holes)이 발생합니다.

릴리스 5.2(1) 이상에서 vPC 자동 복구 기능은 이러한 두 가지 개선 사항을 병합합니다.

구성

vPC 자동 복구 구성은 간단합니다.두 vPC 피어의 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 피어를 동시에 종료하며 하나의 스위치만 켜질 수 있습니다.

- S1과 S2가 모두 켜져 있습니다.vPC는 peer-link 및 peer-keepalive on으로 올바르게 구성되었습니다.

- S1 및 S2 전원이 동시에 꺼집니다.

- 이제 하나의 스위치만 전원을 켜고 사용할 수 있습니다.예를 들어 S2는 전원이 켜지는 유일한 스위치입니다.

- S2는 vPC Peer-link 또는 peer-keepalive 상태의 전원이 켜졌는지 확인하기 위해 vPC 자동 복구 시간 초과(기본값은 240초)를 기다립니다. auto-recovery reload-delay x 명령은 여기서 x는 240-3600초)입니다.이러한 링크 중 하나가 켜져 있으면(peer-link 또는 peer-keepalive 상태) 자동 복구가 트리거되지 않습니다.

- 시간 초과 후 두 링크가 모두 꺼져 있는 경우(peer-link 및 peer-keepalive 상태), vPC 자동 복구가 활성화되고 S2가 기본 가 되어 로컬 vPC의 전원을 켜기 시작합니다.피어가 없으므로 일관성 검사를 우회합니다.

- 이제 S1이 시작됩니다.현재 S2는 기본 역할을 유지하고 S1은 보조 역할을 수행하며 일관성 확인이 수행되고 적절한 작업이 수행됩니다.

2. vPC 피어 링크의 전원이 먼저 꺼진 다음 기본 vPC 피어의 전원이 꺼집니다.

- S1과 S2는 모두 켜져 있고 vPC는 피어 링크 및 peer-keepalive on으로 올바르게 구성됩니다.

- 어떤 이유로 vPC 피어 링크가 먼저 꺼집니다.

- vPC peer-keepalive가 여전히 켜져 있으므로 듀얼 액티브 탐지를 탐지합니다.vPC 보조 S2는 모든 로컬 vPC를 끕니다.

- 이제 vPC 기본 S1이 꺼지거나 다시 로드됩니다.

- 이 중단은 vPC peer-keepalive 링크도 끕니다.

- S2는 3개의 연속된 피어-keepalive 메시지가 손실되기를 기다립니다.어떤 이유로, vPC 피어 링크가 켜지거나 S2가 peer-keepalive 메시지를 수신하고 자동 복구가 활성화되지 않습니다.

- 그러나 peer-link가 꺼져 있고 연속된 피어-keepalive 메시지 3개가 손실되면 vPC 자동 복구가 활성화됩니다.

- S2는 기본 역할을 수행하며 일관성 검사를 우회하는 로컬 vPC를 활성화합니다.

- S1이 다시 로드를 완료하면 S2는 기본 역할을 유지하고 S1은 보조 역할을 수행하며 일관성 검사가 수행되고 적절한 작업이 수행됩니다.

참고:두 시나리오에서 설명한 것처럼, vPC 자동 복구에서 vPC 역할을 일시 중지하지 않는 스위치는 피어 링크가 켜져 있는 후에도 계속 기본 스위치로 유지됩니다.다른 피어는 보조 역할을 수행하고 일관성 검사가 완료될 때까지 자체 vPC를 일시 중단합니다.

예:

S1의 전원이 꺼져 있습니다.S2는 예상대로 운영 기본 유닛이 됩니다.피어 링크 및 peer-keepalive 및 모든 vPC 링크가 S1에서 분리됩니다. S1의 전원이 켜져 있지 않습니다.S1은 완전히 격리되어 있으므로 자동 복구로 인해 물리적 링크가 중단되더라도 vPC의 전원을 켜고 기본 역할을 수행합니다.이제 피어 링크 또는 peer-keepalive가 S1과 S2 간에 연결되어 있으면 S1은 기본 역할을 유지하고 S2는 보조 역할을 수행합니다.이 컨피그레이션으로 인해 vPC 피어 링크 및 피어-keepalive의 전원이 켜지고 일관성 검사가 완료될 때까지 S2는 vPC를 일시 중단합니다.이 시나리오에서는 S2 vPC가 보조 이고 S1 물리적 링크가 해제되어 트래픽이 블랙홀으로 이동합니다.

vPC 자동 복구를 활성화해야 합니까?

vPC 환경에서 자동 복구를 활성화하는 것이 좋습니다.

vPC 자동 복구 기능이 이중 활성 시나리오를 생성할 가능성이 약간 있습니다.예를 들어, 피어-링크를 먼저 손실한 다음 peer-keepalive를 분실한 경우 듀얼-액티브 시나리오가 발생합니다.

이러한 상황에서 각 vPC 멤버 포트는 듀얼 액티브 장애 전에 수행한 것과 동일한 Link Aggregation Control Protocol ID를 계속 광고합니다.

vPC 토폴로지는 듀얼 액티브 시나리오의 경우 루프로부터 본질적으로 보호합니다.최악의 경우 중복 프레임이 있습니다.그럼에도 불구하고 루프 방지 메커니즘으로 각 스위치는 vPC 이중 활성 장애 이전과 동일한 BPDU 브리지 ID를 사용하여 BPDU(Bridge Protocol Data Units)를 전달합니다.

직관적이지는 않지만, 필요한 모든 호스트에 대해 두 Cisco Nexus 7000 Series 피어 모두에 ARP(Address Resolution Protocol) 테이블이 이미 채워져 있는 경우, 현재 트래픽 플로우에 대한 삭제 없이 액세스 레이어에서 어그리게이션 레이어로 트래픽을 계속 전달하는 것이 여전히 가능하고 바람직합니다.

ARP 테이블에서 새 MAC 주소를 학습해야 하는 경우 문제가 발생할 수 있습니다.서버의 ARP 응답이 한 Cisco Nexus 7000 Series 디바이스로 해시될 수 있고 다른 디바이스로 해시될 수 있기 때문에 트래픽이 올바르게 플로우될 수 없습니다.

그러나 방금 설명한 장애 발생 이전에 올바른 PortChannel 및 ECMP(Equal Cost Multipath) 컨피그레이션을 통해 트래픽이 두 Cisco Nexus 7000 Series 디바이스 모두에 균등하게 분산되었다고 가정해 보겠습니다.이 경우 서버-서버 및 클라이언트-서버 트래픽은 Cisco Nexus 7000 Series에 직접 연결된 단일 연결 호스트가 통신할 수 없다는 주의 사항을 계속 따릅니다(피어 링크 부족). 또한 한 Cisco Nexus 7000 Series에서 학습한 새 MAC 주소는 피어에서 학습할 수 없습니다. 이는 피어 Cisco Nexus 7000 Series 디바이스에 도착하는 반환 트래픽이 플러딩될 수 있기 때문입니다.

Cisco NX-OS Software Virtual PortChannel의 19페이지를 참조하십시오.자세한 내용은 기본 개념입니다.

다음을 확인합니다.

현재 이 구성에 대해 사용 가능한 확인 절차가 없습니다.

문제 해결

현재 이 컨피그레이션에 사용할 수 있는 특정 문제 해결 정보가 없습니다.

관련 정보

- 기술 지원 및 문서 − Cisco Systems