Catalyst 9800에서 고가용성 SSO 설정 | 빠른 시작 설명서

소개

이 문서에서는 Catalyst 9800 WLC에서 RP+RMI 방식으로 고가용성 SSO(Stateful Switchover)를 설정하는 방법을 설명합니다.

사전 요구 사항

요구 사항

Cisco에서는 다음 사항에 대해 숙지할 것을 권장합니다.

• Catalyst wireless 9800 컨피그레이션 모델
• HA SSO 설명서에서 다루는 고가용성 개념

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• Catalyst 9800-CL (v. 17.12.3).

HA SSO 설정에는 이러한 주소 중 3개만 필요할 수 있지만, 여기서는 컨트롤러 GUI에 대한 액세스를 간소화하기 위해 WMI(Wireless Management Interface)와 동일한 네트워크에서 4개의 IP 주소를 사용했습니다.

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

배경 정보

무선 컨트롤러의 고가용성 SSO 기능을 통해 액세스 포인트는 활성 무선 컨트롤러 및 활성 무선 컨트롤러와의 CAPWAP 터널을 설정하여 AP 및 클라이언트 데이터베이스의 미러 복사본을 대기 무선 컨트롤러와 공유할 수 있습니다. 전환이 발생하면(즉, 활성 컨트롤러에 장애가 발생하여 대기 컨트롤러가 작업을 수행하는 경우) 조인된 AP가 검색 상태가 되지 않고 클라이언트의 연결이 끊어지지 않습니다. AP와 활성 상태의 무선 컨트롤러 간에는 한 번에 하나의 CAPWAP 터널만 유지됩니다.

두 유닛은 전용 RP 포트(또는 VM의 가상 인터페이스)를 통해 피어 연결을 형성하며 두 컨트롤러는 관리 인터페이스에서 동일한 IP 주소를 공유합니다. RP 인터페이스는 런타임에 대량 및 증분 설정을 동기화하고 HA 쌍의 두 컨트롤러의 작동 상태를 확인하는 데 사용됩니다. 또한 RMI + RP가 사용되면 대기 컨트롤러와 활성 컨트롤러에는 모두 게이트웨이 연결성을 보장하는 데 사용되는 IP 주소를 할당한 RMI(Redundancy Management Interface)가 있습니다. 실행 상태인 액세스 포인트의 CAPWAP 상태도 활성 무선 컨트롤러에서 핫 대기 무선 컨트롤러로 동기화되므로 활성 무선 컨트롤러에 장애가 발생할 경우 액세스 포인트를 완전한 상태로 전환할 수 있습니다. 활성 무선 컨트롤러에 장애가 발생하면 AP가 검색 상태가 되지 않고, 대기 무선 컨트롤러가 활성 무선 컨트롤러 역할을 대신하여 네트워크에 서비스를 제공합니다.

구성

네트워크 다이어그램

설정

이 예에서는 동일한 Cisco IOS 소프트웨어 버전을 실행하는 두 개의 9800-CL 인스턴스 간에 HA(High Availability) SSO(stateful switchover)가 구성됩니다. 이 인스턴스는 분리된 WMI와 액세스 가능한 GUI로 구성되었습니다.

• 첫 번째 IP 주소 10.48.39.130(WLC1이라고 함).
• 두 번째 IP 주소 10.48.39.133(WLC2라고 함)

이러한 IP 주소 외에도 동일한 서브넷(및 VLAN)에 2개의 추가 IP 주소, 즉 10.48.39.131과 10.48.39.132가 사용되었습니다.. 이는 섀시 1(WLC1) 및 섀시 2(WLC2)에 대한 RMI(Redundancy Management Interface) IP 주소입니다.

HA 설정을 시작하기 전의 두 디바이스에 대한 인터페이스 설정은 이 예에서 제공하는 것과 유사해야 합니다.

WLC1#show running-config | s interface
interface GigabitEthernet1
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet2
 switchport trunk allowed vlan 39
 switchport mode trunk
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet3
 negotiation auto
 no mop enabled
 no mop sysid
interface Vlan1
 no ip address
 shutdown
 no mop enabled
 no mop sysid
interface Vlan39
 ip address 10.48.39.130 255.255.255.0
 no mop enabled
 no mop sysid
wireless management interface Vlan39

WLC2#show running-config | s interface
interface GigabitEthernet1
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet2
 switchport trunk allowed vlan 39
 switchport mode trunk
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet3
 negotiation auto
 no mop enabled
 no mop sysid
interface Vlan1
 no ip address
 shutdown
 no mop enabled
 no mop sysid
interface Vlan39
 ip address 10.48.39.133 255.255.255.0
 no mop enabled
 no mop sysid
wireless management interface Vlan39

이 예에서 WLC1은 기본 컨트롤러(섀시 1)로 지정되고 WLC2는 보조 컨트롤러(섀시 2)로 지정됩니다. 즉, 2개의 컨트롤러로 구성된 HA 쌍은 WLC1의 설정을 사용하며 프로세스 이후 WLC2 중 하나가 손실됩니다.

1단계. (선택 사항) 컨트롤러의 시작 설정 파일과 실행 설정 파일을 백업합니다.

잘못된 처리를 수행하는 경우 설정이 손실될 수 있습니다. 이 문제를 방지하려면 HA 설정에 사용된 두 컨트롤러에서 시작 설정과 실행 설정을 모두 백업하는 것이 좋습니다. 이 작업은 9800 GUI 또는 CLI를 사용하여 손쉽게 수행할 수 있습니다.

GUI에서 다음과 같이 표시되어야 합니다.

9800 GUI의 Administration(관리) > Management(관리) > Backup & Restore(백업 및 복원) 탭(스크린샷 참조)에서 컨트롤러에서 현재 사용 중인 시작 및 실행 중인 컨피그레이션을 다운로드할 수 있습니다.

이 예에서는 시작(왼쪽) 및 설정(오른쪽)이 WLC의 GUI에 액세스하는 데 사용되는 브라우저를 호스팅하는 디바이스에 HTTP를 통해 직접 다운로드됩니다. Transfer Mode 필드를 사용하면 백업할 파일의 전송 모드 및 대상을 쉽게 조정할 수 있습니다.

CLI에서:

WLCx#copy running-config tftp://
    
    
      /run-backup_x.cfg Address or name of remote host [ 
     
       ]? Destination filename [run-backup_x.cfg]? !! 19826 bytes copied in 1.585 secs (12509 bytes/sec) WLCx#copy startup-config tftp:// 
      
        /start-backup_x.cfg Address or name of remote host [ 
       
         ]? Destination filename [start-backup_x.cfg]? !! 20482 bytes copied in 0.084 secs (243833 bytes/sec) 
        
       
      
    

  를 시작/실행 설정 파일이 복사되는 TFTP 서버 IP로 교체합니다.

2단계. (선택 사항) 네트워크 연결성을 확인합니다.

두 WLC GUI 또는 CLI에서 간단한 연결 테스트, 즉 두 디바이스에서 게이트웨이를 ping하고 디바이스 간에 ping을 수행할 수 있습니다. 이렇게 하면 두 컨트롤러가 HA를 설정하는 데 필요한 연결성을 갖출 수 있습니다.

GUI에서 다음과 같이 표시되어야 합니다.

9800 GUI의 Troubleshooting 탭에 있는 Ping 및 Traceroute 툴을 사용하여 이 그림에 표시된 대로 컨트롤러 자체 간 그리고 각 WLC와 네트워크 게이트웨이 간의 연결을 테스트할 수 있습니다.

CLI에서:

WLCx#ping 10.48.39.133  
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.48.39.133, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
WLCx#ping 10.48.39.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.48.39.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

3단계. RMI + RP 페어링 유형으로 이중화를 구성합니다.

각 디바이스 간의 연결성이 보장되면 컨트롤러 간에 리던던시(redundancy)를 설정할 수 있습니다. 이 화면 캡처는 9800 GUI의 Administration(관리) > Device(디바이스) 페이지의 Redundancy(이중화) 탭에서 컨피그레이션을 수행하는 방법을 보여줍니다.

구성된 필드와 그 용도를 검토합니다.

• 이중화 구성: WLC 간 이중화를 사용하려면 이 옵션을 활성화해야 합니다.

• 이중화 페어링 유형: 이 설명서에서는 RMI 컨피그레이션을 사용하는 HA SSO를 다루므로, 이중화 관리 인터페이스와 이중화 포트를 모두 사용하여 구성된 페어링 유형은 RMI + RP여야 합니다. 리던던시(redundancy) 포트만 사용하여 리던던시(redundancy)를 구성하도록 선택할 수도 있습니다. 그러나 RP만 선택한 경우 게이트웨이의 연결성은 확인되지 않고 중복 WLC 상태만 확인합니다.

• RMI IP for Chassis 1/2: 이 필드는 제공된 IP 주소를 두 인스턴스 모두에 대해 지정된 리던던시(redundancy) 인터페이스에 할당합니다. 이 예에서는 섀시 1과 2의 RMI IP는 이전에 설명하고 네트워크 다이어그램에 표시된 대로 각각 10.48.39.131 및 10.48.39.132로 설정되었습니다.

• HA Interface: 가상 어플라이언스를 사용할 때 하이퍼바이저의 vNIC(Virtual Network Interface Card)와 가상 머신의 네트워크 인터페이스 간의 매핑을 다양한 방법으로 설정할 수 있습니다. 따라서 리던던시(redundancy)에 사용되는 인터페이스는 Cisco Catalyst 9800-CL에 대해 설정 가능합니다. 여기서는 9800-CL 구축 가이드에서 권장하는 대로 GigabitEthernet 3이 사용되었습니다.
  
  

  참고: 물리적 C9800 어플라이언스를 사용할 경우, HA 및 RP에서 사용되는 인터페이스는 기본 인터페이스이며 구성할 수 없습니다. 실제로 하드웨어 9800 WLC에는 네트워크와 분리된 전용 리던던시(redundancy) 인터페이스가 있습니다.

• 관리 게이트웨이 장애 조치: ha SSO 컨피그레이션 가이드에 자세히 설명된 대로 이 이중화 방법은 게이트웨이에 ICMP(Internet Control Message Protocol) ping을 주기적으로 전송하여 수행하는 기본 게이트웨이 확인을 구현합니다. 활성 컨트롤러와 대기 컨트롤러 모두 RMI IP를 이러한 확인의 소스 IP로 사용합니다. 이러한 메시지는 1초 간격으로 전송됩니다.

• Gateway Failure Interval: 게이트웨이가 연결 불가능으로 선언되기 전에 게이트웨이 확인이 연속적으로 실패해야 하는 시간을 나타냅니다. 기본적으로 이 시간은 8초로 구성됩니다. 게이트웨이 확인은 매초마다 전송되므로, 게이트웨이에 연결하는 데 8번 연속 실패했음을 나타냅니다.

• 로컬/원격 IP: 섀시 1 및 2에 대해 구성된 RP IP입니다. 이러한 IP 주소는 169.254.x.x로 자동 생성됩니다. 여기서 x.x는 관리 인터페이스의 마지막 두 옥텟에서 파생됩니다.

• Keep Alive 타이머: ha SSO 컨피그레이션 가이드에 자세히 설명된 대로, 액티브 섀시와 스탠바이 섀시는 서로 킵얼라이브 메시지를 보내 둘 다 계속 사용할 수 있도록 합니다. Keep Alive Timer는 각 섀시 간에 2개의 keep alive 메시지 전송을 분리하는 시간입니다. 기본적으로 keep-alive 메시지는 100ms마다 전송됩니다. VM 인프라에서 약간의 지연(스냅샷 등)이 발생할 때마다 남용 전환을 방지하기 위해 9800-CL로 이 값을 늘리는 것이 좋습니다.

• 연결 유지 재시도: 이 필드는 피어가 다운되었다고 주장하기 전에 피어 keepalive retry 값을 구성합니다. Keep-alive 타이머와 재시도 기본값이 모두 사용되는 경우, 100ms 시간 간격으로 전송된 keep-alive 메시지 5개가 응답하지 않는 경우(즉, 리던던시(redundancy) 링크가 500ms 동안 중단된 경우) 피어가 클레임 중단된 것입니다.

• 섀시 번호 재지정: 어플라이언스에서 사용해야 하는 섀시 번호(1 또는 2).

  • WLC2(10.48.39.133)에서는 섀시의 번호가 2로 다시 지정됩니다. 기본적으로 섀시 번호는 1입니다. RP 포트의 IP 주소는 RMI에서 파생됩니다. 두 컨트롤러의 섀시 번호가 동일하면 로컬 RP 포트 IP 파생은 동일하며 검색이 실패합니다. 액티브-액티브 시나리오를 방지하려면 섀시의 번호를 재지정합니다.

• 활성 섀시 우선순위: ha 쌍에서 사용해야 하는 컨피그레이션을 정의하는 데 사용되는 우선순위. 우선순위가 가장 높은 어플라이언스가 다른 어플라이언스에 복제됩니다. 따라서 우선순위가 가장 낮은 섀시의 설정이 손실됩니다.

  • WLC1(10.48.39.130)에서 활성 섀시 우선순위가 2로 설정되었습니다. 이는 이 섀시가 생성된 HA 쌍에서 활성 섀시로 선택되었는지(따라서 해당 컨피그레이션이 사용되었는지) 확인하기 위한 것입니다.

이러한 설정이 완료되면 Apply 버튼을 사용하여 설정을 컨트롤러에 적용합니다.

CLI에서

먼저 두 디바이스에서 모두 RMI를 설정하는 데 사용되는 가상 인터페이스에 보조 IP 주소를 구성합니다.

WLC1#configure terminal
WLC1(config)#interface vlan 39
WLC1(config-if)# ip address 10.48.39.131 255.255.255.0 secondary
WLC1(config-if)# end

WLC2#configure terminal
WLC2(config)#interface vlan 39
WLC2(config-if)# ip address 10.48.39.132 255.255.255.0 secondary
WLC2(config-if)# end

그런 다음 두 디바이스 모두에서 이중화를 활성화합니다.

WLC1#configure terminal
WLC1(config)#redundancy
WLC1(config-red)#mode sso
WLC1(config-red)#end

WLC2#configure terminal
WLC2(config)#redundancy
WLC2(config-red)#mode sso
WLC2(config-red)#end

WLC1과 같은 섀시 우선순위를 구성하는 것이 기본 컨트롤러가 됩니다.

WLC1#show chassis 
Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP
-------------------------------------------------------------------------------------
*1       Active   0001.0202.aabb     1      V02     Ready                169.254.39.131
WLC1#chassis 1 priority 2 
WLC1#show chassis 
Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP
-------------------------------------------------------------------------------------
*1       Active   0001.0202.aabb     2      V02     Ready                169.254.39.131

보조 컨트롤러가 되는 WLC2의 섀시 번호를 다시 지정합니다.

WLC2#show chassis 
Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP
-------------------------------------------------------------------------------------
*1       Active   0001.0202.aabb     1      V02     Ready                169.254.39.132 
WLC2#chassis 1 renumber 2
WLC2#show chassis 
Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP
-------------------------------------------------------------------------------------
*2       Active   0001.0202.aabb     1      V02     Ready                169.254.39.132 

마지막으로, 두 디바이스 모두에서 RMI를 구성합니다.

WLC1#chassis redundancy ha-interface GigabitEthernet 3
WLC1#configure terminal
WLC1(config)#redun-management interface Vlan39 chassis 1 address 10.48.39.131 chassis 2 address 10.48.39.132
WLC1(config)#end

WLC2#chassis redundancy ha-interface GigabitEthernet 3
WLC2#configure terminal
WLC2(config)#redun-management interface Vlan39 chassis 1 address 10.48.39.131 chassis 2 address 10.48.39.132
WLC2(config)#end

4단계. 컨트롤러 다시 로드

HA 쌍이 형성되고 설정이 적용되려면 3단계에서 수행한 설정을 저장한 후 두 컨트롤러를 동시에 다시 로드해야 합니다.

GUI에서:

두 GUI의 Administration Reload(관리 다시 로드) 페이지를 사용하여 이 화면 캡처에 표시된 대로 컨트롤러를 다시 시작할 수 있습니다.

 

CLI에서:

WLCx#reload
Reload command is being issued on Active unit, this will reload the whole stack
Proceed with reload? [confirm]

다음을 확인합니다.

HA 쌍의 두 컨트롤러가 서로를 검색하고 원하는 HA 쌍을 생성하면 하나의 컨트롤러(기본)가 GUI 또는 CLI에서 2개의 섀시를 모니터링할 수 있습니다.

GUI에서:

9800 GUI에서 이중화 컨피그레이션을 모니터링하려면 이 화면 캡처에 표시된 대로 Monitoring(모니터링) > General(일반) > System(시스템) 페이지에서 Redundancy(이중화) 탭으로 이동합니다.

CLI에서:

WLC#show chassis rmi  
Chassis/Stack Mac Address : 0050.568d.cdf4 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP                RMI-IP
--------------------------------------------------------------------------------------------------------
*1       Active   0050.568d.cdf4     2      V02     Ready                169.254.39.131     10.48.39.131
 2       Standby  0050.568d.2a93     1      V02     Ready                169.254.39.132     10.48.39.132

WLC#show redundancy 
Redundant System Information :
------------------------------
       Available system uptime = 22 minutes
Switchovers system experienced = 0
              Standby failures = 0
        Last switchover reason = none

                 Hardware Mode = Duplex
    Configured Redundancy Mode = sso
     Operating Redundancy Mode = sso
              Maintenance Mode = Disabled
                Communications = Up

Current Processor Information :
-------------------------------
               Active Location = slot 1
        Current Software state = ACTIVE
       Uptime in current state = 22 minutes
                 Image Version = Cisco IOS Software [Cupertino], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.9.2, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2022 by Cisco Systems, Inc.
Compiled Wed 02-Nov-22 15:12 by mcpre
                          BOOT = bootflash:packages.conf,12;
                   CONFIG_FILE = 
        Configuration register = 0x102
               Recovery mode   = Not Applicable
             Fast Switchover   = Enabled
                Initial Garp   = Enabled

Peer Processor Information :
----------------------------
              Standby Location = slot 2
        Current Software state = STANDBY HOT 
       Uptime in current state = 20 minutes
                 Image Version = Cisco IOS Software [Cupertino], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.9.2, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2022 by Cisco Systems, Inc.
Compiled Wed 02-Nov-22 15:12 by mcpre
                          BOOT = bootflash:packages.conf,12;
                   CONFIG_FILE = 
        Configuration register = 0x102

문제 해결

One Stop-Shop Reflex

일반적  에는 HA 쌍의 HA 페일오버와 현재 상태를 올바르게 파악할 수 있는 명령이 포함되지 않습니다.show tech wireless 대부분의 HA 관련 명령을 단일 작업에서 포함하려면 이 명령을 수집합니다.

WLC#show tech wireless redundancy

Show 명령

리던던시(redundancy) 포트의 상태를 확인하기 위해 다음 명령을 사용할 수 있습니다.

WLC#show chassis detail
Chassis/Stack Mac Address : 0050.568d.2a93 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP
-------------------------------------------------------------------------------------
 1       Standby  aaaa.aaaa.aaaa     2      V02     Ready                169.254.39.131 
*2       Active   bbbb.bbbb.bbbb     1      V02     Ready                169.254.39.132 



         Stack Port Status             Neighbors     
Chassis#  Port 1     Port 2           Port 1   Port 2 
--------------------------------------------------------
  1         OK         OK               2        2 
  2         OK         OK               1        1 
WLC#show chassis rmi 
Chassis/Stack Mac Address : 0050.568d.2a93 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP                RMI-IP
--------------------------------------------------------------------------------------------------------
 1       Standby  aaaa.aaaa.aaaa     2      V02     Ready                169.254.39.131     10.48.39.131
*2       Active   bbbb.bbbb.bbbb     1      V02     Ready                169.254.39.132     10.48.39.132

이 명령은 첫 번째 단계 문제 해결에 도움이 되는 섀시 번호와 리던던시(redundancy) 포트 상태를 표시합니다.

keepalive 포트에서 keepalive 카운터를 확인하려면 다음 명령을 사용할 수 있습니다.

WLC#show platform software stack-mgr chassis active R0 sdp-counters
Stack Discovery Protocol (SDP) Counters

---------------------------------------

Message                 Tx Success    Tx Fail       Rx Success    Rx Fail       
------------------------------------------------------------------------------
Discovery               162054        2             28            0             
Neighbor                23            3             12            0             
Keepalive               189856        1665          187970        0             
SEPPUKU                 0             0             0             0             
Standby Elect Req       2             0             0             0             
Standby Elect Ack       0             0             2             0             
Standby IOS State       0             0             4             0             
Reload Req              0             0             0             0             
Reload Ack              0             0             0             0             
SESA Mesg               0             0             0             0             
RTU Msg                 0             0             0             0             
Disc Timer Stop         1             0             2             0             

---------------------------------------

WLC#show platform software stack-mgr chassis standby R0 sdp-counters
Stack Discovery Protocol (SDP) Counters

---------------------------------------

Message                 Tx Success    Tx Fail       Rx Success    Rx Fail       
------------------------------------------------------------------------------
Discovery               14            2             19            0             
Neighbor                6             2             5             0             
Keepalive               175905        0             176196        0             
SEPPUKU                 0             0             0             0             
Standby Elect Req       0             0             1             0             
Standby Elect Ack       1             0             0             0             
Standby IOS State       2             0             0             0             
Reload Req              0             0             0             0             
Reload Ack              0             0             0             0             
SESA Mesg               0             0             0             0             
RTU Msg                 0             0             0             0             
Disc Timer Stop         1             0             0             0             

---------------------------------------

WLC#show platform software stack-mgr chassis standby R0 peer-timeout
Peer Chassis    Peer-timeout (ms)   50% Mark            75% Mark            
--------------------------------------------------------------------------
2               500                 0                   0                   

기타 명령

다음 명령을 사용하여 컨트롤러의 이중화 포트에서 패킷 캡처를 수행할 수 있습니다.

WLC#test wireless redundancy packetdump start 
Redundancy Port PacketDump Start

Packet capture started on RP port.

WLC#test wireless redundancy packetdump stop  
Redundancy Port PacketDump Stop

Packet capture stopped on RP port.

이 명령을 사용하여 캡처한 캡처는 컨트롤러의  에 이름 으로 저장됩니다.bootflash:  haIntCaptureLo.pcap

이 명령을 사용하여 이중화 포트에서 keepalive 테스트를 실행할 수도 있습니다.

WLC#test wireless redundancy rping 
Redundancy Port ping

PING 169.254.39.131 (169.254.39.131) 56(84) bytes of data.
64 bytes from 169.254.39.131: icmp_seq=1 ttl=64 time=0.316 ms
64 bytes from 169.254.39.131: icmp_seq=2 ttl=64 time=0.324 ms
64 bytes from 169.254.39.131: icmp_seq=3 ttl=64 time=0.407 ms

--- 169.254.39.131 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2025ms
rtt min/avg/max/mdev = 0.316/0.349/0.407/0.041 ms

자세한 내용 확인

실제 설정이 변수에 어떻게 적용되는지 보여주는 ROMMON 변수 설정을 보려면 이 명령을 사용할 수 있습니다.

WLC#show romvar
ROMMON variables:
 MCP_STARTUP_TRACEFLAGS = 00000000:00000000
 SWITCH_NUMBER = 2
 CONFIG_FILE = 
 BOOTLDR = 
 STACK_1_1 = 0_0
 BOOT = bootflash:packages.conf,12;
 LICENSE_SUITE = 
 CHASSIS_HA_IFNAME = GigabitEthernet3
 CHASSIS_HA_IFMAC = 00:50:56:8D:2A:93
 SWITCH_PRIORITY = 1
 RMI_INTERFACE_NAME = Vlan39
 RMI_CHASSIS_LOCAL_IP = 10.48.39.132
 RMI_CHASSIS_REMOTE_IP = 10.48.39.131
 CHASSIS_HA_LOCAL_IP = 169.254.39.132
 CHASSIS_HA_REMOTE_IP = 169.254.39.131
 CHASSIS_HA_LOCAL_MASK = 255.255.255.0
 RET_2_RTS = 
 LICENSE_BOOT_LEVEL = ,csr1000v:csr1000v;
 BSI = 0
 RET_2_RCALTS = 
 RANDOM_NUM = 193112462

이 명령은 섀시의 우선순위, RMI 및 RP 세부 정보, 피어 시간 초과와 함께 더욱 유용한 세부정보를 표시합니다. 

또한 WLC에서 HA SSO를 실행하는 프로세스(stack_mgr 및 rif_mgr)를 모니터링할 수 있습니다.

이렇게 하려면 명령을 사용하여 텍스트 파일에 대한 always-on 추적을 수집합니다. 여기서 시간 매개변수를 조정하여 문제를 해결할 수 있습니다. 

show logging process stack_mgr start last 30 minutes to-file bootflash:stack_mgr_logs.txt 
show logging process rif_mgr start last 30 minutes to-file bootflash:rif_mgr_logs.txt 

일반적인 시나리오

User Forced

전환 기록을 보면 사용자가 명령을 사용하여 컨트롤러 간 전환을 시작했을 때 나타나는 사용자 강제 전환을 볼 수redundancy force-switchover있습니다.

WLC#show redundancy switchover history
Index  Previous  Current  Switchover             Switchover
       active    active   reason                 time
-----  --------  -------  ----------             ----------
   1       1        2     user forced            11:38:23 Central Fri Mar 10 2023

Active Unit Removed

전환 기록을 살펴보면 액티브 유닛이 제거된 것을 확인할 수 있으며, 이는 두 컨트롤러 간의 이중화 포트에서 통신 손실을 가리킵니다.

WLC#show redundancy switchover history
Index  Previous  Current  Switchover             Switchover
       active    active   reason                 time
-----  --------  -------  ----------             ----------
   2       2        1     active unit removed    11:55:36 Central Fri Mar 10 2023

이는 두 컨트롤러 간의 링크가 중단되는 경우 발생할 수 있지만, WLC 유닛 하나가 갑자기 중단(정전)되거나 충돌하는 경우에도 발생할 수 있습니다. 두 WLC를 모두 모니터링하여 예기치 않은 충돌/재부팅을 나타내는 시스템 보고서가 있는지 확인하는 것이 좋습니다.

Active Lost GW

전환 이력을 보면 RMI 포트에서 게이트웨이와의 통신 손실을 가리키는 Active lost GW를 볼 수 있습니다.

WLC#show redundancy switchover history 
Index  Previous  Current  Switchover             Switchover
       active    active   reason                 time
-----  --------  -------  ----------             ----------
   3       1        2     Active lost GW         12:00:26 Central Fri Mar 10 2023

활성 컨트롤러와 게이트웨이 간의 링크가 중단되면 이러한 현상이 발생합니다.

추가 고려 사항

Catalyst 9800-CL용 HA SSO

가상 환경에서는 레이턴시가 도입되는 것을 받아들여야 하며, 레이턴시는 HA가 적절히 용인하는 것이 아닙니다. HA SSO는 섀시 결함을 빠르고 효율적으로 탐지하는 경향이 있으므로 이는 합법적입니다. 이를 위해 각 섀시는 RP 및 RMI 링크의 킵얼라이브와 RMI의 게이트웨이를 향하는 ping을 사용하여 다른 섀시의 상태를 확인합니다(WMI 중 하나가 동일해야 함). 이러한 사항 중 하나라도 누락된 경우, 스택은 HA SSO 가이드의 System and Network Fault Handling(시스템 및 네트워크 결함 처리)에 설명된 증상에 따라 반응합니다.

Catalyst 9800의 가상 HA SSO 스택으로 작업할 때 RP 링크를 통해 킵얼라이브가 누락되어 스위치오버가 발생하는 것이 일반적입니다. 이는 가상화된 환경에 의해 도입된 레이턴시 때문일 수 있습니다.

HA SSO 스택에서 RP keepalive 삭제로 인한 문제를 확인하려면 stack/rif 관리자 로그를 사용할 수 있습니다.

! Keepalives are missed
004457: Feb  4 02:15:50.959 Paris: %STACKMGR-6-KA_MISSED: Chassis 1 R0/0: stack_mgr: Keepalive missed for 2 times for Chassis 2
! Chassis is removed
%STACKMGR-6-CHASSIS_REMOVED_KA: Chassis 1 R0/0: stack_mgr: Chassis 2 has been removed from the stack due to keepalive failure.
! RP link is down
004469: Feb  4 02:17:28.707 Paris: %RIF_MGR_FSM-6-RP_LINK_DOWN: Chassis 1 R0/0: rif_mgr: Setting RP link status to DOWN
! Dual active detection
004470: Feb  4 02:17:28.707 Paris: %STACKMGR-1-DUAL_ACTIVE_CFG_MSG: Chassis 1 R0/0: stack_mgr: Dual Active Detection links are not available anymore 

두 섀시가 모두 작동 중이면 스위치오버는 RP의 삭제로 인해 듀얼 액티브 탐지를 생성합니다.

이러한 상황에서는 이러한 불필요한 전환을 방지하기 위해 HA 킵얼라이브 매개변수를 변경하는 것이 도움이 될 수 있습니다. 두 가지 매개변수를 구성할 수 있습니다.

1. Keep Alive Timer(킵얼라이브 타이머): 각 섀시 간에 2개의 킵얼라이브 메시지를 보내는 시간을 구분하는 시간입니다.
2. Keep Alive Retries(킵얼라이브 재시도 횟수): 피어를 다운이라고 선언하기 위해 누락해야 하는 킵얼라이브 횟수입니다.

기본적으로 keep alive 타이머는 1ms로 설정되고 retries는 5ms로 설정됩니다. 즉, RP 링크에서 keepalive 5ms가 누락되면 전환이 발생합니다. 이러한 값은 가상 구축에 비해 너무 낮을 수 있습니다. RP 킵얼라이브가 누락되어 반복적인 전환이 발생하는 경우, 이러한 매개변수를 늘려 스택을 안정화해 보십시오.

GUI에서:

9800 GUI에서 HA SSO 킵얼라이브 매개변수를 모니터링하거나 수정하려면 이 스크린샷에 표시된 대로 Administration(관리) > Device(디바이스) 페이지에서 Redundancy(이중화) 탭으로 이동합니다.

CLI에서:

WLC#chassis redundancy keep-alive retries <5-10> 
WLC#chassis redundancy keep-alive timer <1-10>

이러한 매개변수의 컨피그레이션과 함께 또 다른 최적화는 HA SSO 스택의 이러한 동작에 도움이 될 수 있습니다. 물리적 어플라이언스의 경우 하드웨어는 일반적으로 단일 와이어를 사용하여 섀시를 다른 섀시에 연결할 수 있습니다. 가상 환경에서 각 섀시에 대한 RP 포트의 상호 연결은 vSwitch(가상 스위치)를 통해 이루어져야 하는데, 이 경우 물리적 연결에 비해 레이턴시가 다시 발생할 수 있습니다. 전용 vSwitch를 사용하여 RP 링크를 생성하는 것은 레이턴시로 인한 HA 킵얼라이브의 손실을 방지할 수 있는 또 다른 최적화입니다. 이 내용은 Cisco Catalyst 9800-CL Wireless Controller for Cloud Deployment Guide에도 설명되어 있습니다. 따라서 가장 좋은 방법은 9800-CL VM 간의 RP 링크에 전용 vSwitch를 사용하고 다른 트래픽이 이를 방해하지 않도록 하는 것입니다.

Catalyst 9800 HA SSO Inside ACI Deployments

HA SSO 스택에서 전환이 발생하면 새로 활성화된 섀시는 GARP(Gratuitous ARP) 메커니즘을 사용하여 네트워크에서 MAC-IP 매핑을 업데이트하고 컨트롤러 전용 트래픽을 수신하는지 확인합니다. 특히 섀시는 GARP를 전송하여 WMI의 새 소유자가 되고 CAPWAP 트래픽이 적절한 섀시에 도달하도록 합니다.

섀시가 활성화된다는 것은 실제로 단일 GARP를 보내는 것이 아니라, 네트워크의 모든 디바이스가 IP를 MAC으로 업데이트하는지 확인하기 위해 GARP를 버스트하는 것입니다. 이 버스트는 ACI의 ARP 학습 기능을 압도할 수 있으므로 ACI를 사용할 경우 Catalyst 9800 구성에서 이 버스트를 최대한 줄이는 것이 좋습니다.

CLI에서:

WLC# configure terminal
WLC(config)# redun-management garp-retransmit burst 0 interval 0

전환 중에 9800에서 시작된 GARP 버스트를 제한하는 것과 더불어 이 플랫폼에서 빠른 전환 기능을 비활성화하는 것이 좋습니다. 빠른 전환이 구성된 경우 활성 컨트롤러는 대기 컨트롤러에 작동 중임을 알리는 명시적 알림을 보냅니다. 이를 사용하는 동안 HA 스택을 구성하는 두 WLC 사이에 인터리빙 트래픽이 존재할 수 있습니다(AP 및 클라이언트 삭제 중). 두 WLC 중 하나가 중단될 때까지 말입니다. 따라서 이 기능을 비활성화하면 ACI 구축에서 작업하는 동안 무선 인프라를 안정화하는 데 도움이 됩니다.

CLI에서:

WLC#configure terminal
WLC(config)#no redun-management fast-switchover

ACI 네트워크 내부에서 Catalyst 9800을 HA SSO로 구축할 때 고려해야 할 사항에 대한 자세한 내용은 Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide의 Information About Deploying ACI Network in Controller 섹션에서 확인할 수 있습니다.

참조

• 17.3 HA SSO 설명서
• 17.6 HA SSO 설명서