업그레이드 실패의 영향을 받는 17.12의 Catalyst AP 검증 및 복구

소개

이 문서에서는 AP가 Cisco 버그 ID CSCwf25731 및 CSCwf37271의 영향을 받는 경우의 복구 절차에 대해 설명합니다.

컨텍스트

현재 17.12.4/5/6/6a을 실행 중이거나 이전에 이러한 버전을 실행했던 시스템에 업그레이드 또는 APSP를 적용하면 AP 스토리지의 디스크 공간 부족으로 인한 이미지 설치 실패로 인해 트리거되는 특정 조건에서 영향을 받는 AP 모델(아래의 영향을 받는 액세스 포인트 목록을 확인하십시오)이 부팅 루프에 들어갈 수 있습니다. 이 절차에는 액세스 포인트 이미지 업그레이드가 포함되므로 일상적인 작업이나 SMU에는 영향을 주지 않지만 ISSU, 전체 컨트롤러 코드 업그레이드 또는 APSP 설치 시에는 위험합니다.

구성 해결 방법이 없으므로 이 문서에 언급된 필수 업그레이드 사전 검사 단계가 필요한 추가 프로세스를 따라야 합니다.

이 문제를 해결하려면 AP가 업그레이드를 시도하기 전에 WLC에 특정 APSP 버전 수정(아래의 고정 코드 표에 표시됨)을 설치하거나, 이후 릴리스로 이미 이동했지만 영향을 받은 버전을 실행한 경우 정리 APSP(17.15.4d 및 17.18.2에 사용 가능)를 사용해야 합니다. 시스템의 기록을 잘 모르는 경우에도 해당 버전이 사용자 환경에 있는 경우 업그레이드 또는 APSP 설치 전에 스토리지 검사를 수행하는 것이 좋습니다.

근본 원인 세부 정보

17.12.4~17.12.6a를 실행하는 AP는 영구 로그 파일을 생성하는 라이브러리 버그의 영향을 받습니다. /storage/cnssdaemon.log 이 파일은 매일 5MB씩 증가하며 재부팅해도 지워지지 않으므로 결국 디바이스의 저장 공간이 소모됩니다. 따라서 AP가 부트 파티션 1(Part1)에서 실행되고 있고 부트 파티션 2(Part2)가 로그 파일 때문에 가득 차면 업그레이드 프로세스가 실패하는데, 이는 새 이미지를 부트 파티션 2에 저장할 수 없기 때문이며 잠재적으로 부트 루프가 발생할 수 있습니다. 이를 방지하려면 이 문서의 지침에 따라 추가 업그레이드를 시도하기 전에 스토리지를 지우거나 AP가 파티션 2에서 부팅되었는지 확인해야 합니다.

영향을 받는 코드 및 액세스 포인트

영향을 받는 액세스 포인트

이 문제가 발생할 수 있는 액세스 포인트 모델은 다음과 같습니다. 네트워크에서 이러한 특정 모델을 사용하지 않을 경우, 해당 환경은 영향을 받지 않으며 추가 조치가 필요하지 않습니다.

• Catalyst 9124(I/D/E)
• Catalyst 9130(I/E)
• Catalyst 9136I
• Catalyst 9162I
• Catalyst 9163E
• Catalyst 9164I
• Catalyst 9166(I/D1)
• Catalyst IW9167(I/E)

영향을 받는 코드

네트워크에서 이를 확인하려면 모든 WLC에서 다음 명령을 실행하고 WLC에 있는 코드가 아래 표에 나열되는지 확인합니다.

#show version | in Version

또는 AP에서도 동일한 작업을 수행할 수 있습니다. 기본 또는 백업 이미지가 표에 나열된 이미지에서 영향을 받는 이미지를 실행 중인지 확인하려면 출력을 확인합니다.

#show version | in Image

참고: 참고: 일반적으로 네트워크가 실행되고 있지 않고 과거에 17.12.6/6a에서 17.12.4, 17.12.5를 실행하지 않은 경우에는 이 문제를 적용할 수 없습니다.

고정 코드

다음 표에는 이 버그에 대한 수정 사항이 포함된 WLC 소프트웨어 버전 및 해당 APSP(액세스 포인트 서비스 팩)가 나열되어 있습니다. 아래 나열된 버전의 경우 현재 이 수정 사항은 이 문서를 작성할 때 APSP 설치를 통해서만 사용할 수 있습니다.

업그레이드 경로 및 버그 적용 가능성

아래 표를 사용하여 현재 WLC 및 AP 소프트웨어 버전이 이 버그에 적용되는지 여부와 수행할 업그레이드 단계를 확인하십시오. 현재 구축이 버그 적용 가능 및 업그레이드 경로 테이블에 있는 릴리스와 일치하는 경우 추가 업그레이드를 시도하기 전에 업그레이드 사전 검사 섹션에 설명된 스토리지 사전 검사를 수행해야 합니다.

버그를 적용할 수 없음 및 업그레이드 경로

다음 표에서는 WLC 및 AP가 이 버그에 적용되지 않는지 보여줍니다.

버그 적용 가능 및 업그레이드 경로

다음 표에서는 WLC 및 AP가 이 버그에 적용되는지를 보여줍니다.

업그레이드 사전 검사

사용자 환경이 이 버그의 영향을 받는 경우 다음 필수 단계를 수행하여 안전한 복구 및 업그레이드를 확인하십시오.

1. 식별: 버그에 적용할 수 있는 특정 액세스 포인트를 식별하기 위해 수동 또는 자동화된 사전 검사를 실행합니다. 자동화된 사전 확인을 사용하는 것이 좋습니다.
2. 복구: 플래그가 지정된 AP에 대해서는 Recovery 섹션에서 설명한 복구 절차를 수행합니다.
3. 확인: 사전 검사를 다시 실행하여 모든 디바이스가 정상이고 스토리지 문제가 해결되었는지 확인합니다.
4. 업그레이드: 고정 버전 표에 나열된 고정 APSP로 업그레이드를 진행합니다.

수동 사전 검사

1. WLC에서 Primary 및 Backup 이미지 열을 확인하여 액세스 포인트가 영향을 받는 릴리스를 실행 중인지 확인할 수 있습니다(위의 Affected Codes 섹션 확인).

9800-l#show ap image
Total number of APs  : 4

Number of APs
        Initiated                  : 0
        Downloading                : 0
        Predownloading             : 0
        Completed downloading      : 0
        Completed predownloading   : 0
        Not Supported              : 0
        Failed to Predownload      : 0
        Predownload in progress    : No

AP Name             Primary Image          Backup Image            Predownload Status   Predownload Version  Next Retry Time   Retry Count   Method
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ap117.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap217.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap317.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap417.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A

두 이미지 파티션을 모두 확인하려면 다음 명령을 실행하여 AP 레벨에서 직접 유사한 확인을 수행할 수도 있습니다.

AP# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209
Primary Boot Image Hash: 93ef1e703a5e7c5a4f97b8f59b220f52d94dd17c527868582c0048caad6397a9f3526c644f94a52bb70a104385690065ad0d652aa3fed607f24920d7e5ed5b5c
Backup Boot Image Hash: 4bbe4a0d9edc3cad938a7de399d3c2e08634643a2623bae65973ef00deb154b8eb7c7917eeecdd46e3e2ddc7be80139475e19fb3040b08aa715de196a733252b
1 Multigigabit Ethernet interfaces

백업 이미지가 part2에 있는지 확인하기 위해 활성 부트 파티션을 확인합니다. "show boot" 명령을 사용하고 "BOOT path-list"가 part1을 가리키는지 확인합니다. 이는 AP가 현재 기본 파티션에서 실행 중이며, 문제를 일으킬 수 있는 보조 파트로 업그레이드하려고 시도하고 있음을 나타냅니다.

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1
Console Baudrate: 9600 Enable Break:

2. /dev/ubivol/part2 파티션을 확인하여 현재 파일 시스템 사용량을 확인합니다. "Use%"가 100%에 가까우면 파티션이 모두 소진되어 업그레이드가 실패하고 부팅 루프가 트리거될 수 있습니다.

AP# show filesystems
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                880.9M         0    880.9M   0% /dev
/sysroot                883.8M    219.6M    664.1M  25% /
tmpfs                     1.0M     56.0K    968.0K   5% /dev/shm
tmpfs                   883.8M         0    883.8M   0% /run
tmpfs                   883.8M         0    883.8M   0% /sys/fs/cgroup
/dev/ubivol/part1       372.1M     79.7M    292.4M  21% /part1
/dev/ubivol/part2       520.1M    291.3M    228.9M  56% /part2

3. 두 파티션이 손상되지 않았는지 확인하기 위해 두 파티션의 이미지 무결성을 확인합니다. 기본 및 백업 이미지의 모든 필드는 상태가 "정상"으로 표시되어야 합니다. 필드가 다르게 표시되면 프로세스를 중지하고 즉시 TAC 케이스를 여십시오.

AP# show image integrity
/part1(Backup) 17.12.5.209
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good
/part2(primary) 17.12.5.41
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good

자동화된 사전 검사

자동화된 사전 확인을 위해 WLAN Poller 툴을 활용합니다. 이 도구를 사용하면 모든 액세스 포인트에서 필요한 명령을 동시에 실행하여 영향을 받는 액세스 포인트를 식별할 수 있습니다. 다음 링크에서 직접 다운로드할 수 있습니다. https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/#wlan-poller

단계:

1. 추출 - WLAN Poller 파일을 원하는 디렉토리로 추출합니다.

2. 구성 - 특정 자격 증명 및 컨트롤러 IP 주소를 입력했는지 확인하기 위해 "config.ini" 파일을 다음 매개 변수로 업데이트합니다.

wlc_type: 2
mode: ssh
ap_mode: ssh

; set global WLC credentials
wlc_user: 
wlc_pasw: 
wlc_enable: 

; set global AP credentials
ap_user: 
ap_pasw: 
ap_enable: 

[WLC-1]
active: True
ipaddr: 
mode: ssh

3. 명령 목록 준비 - "cmdlist_cos" 및 "cmdlist_cos_qca"의 기본 내용을 주석 처리(해시 기호 "#" 추가)한 다음 두 파일에 다음 명령을 추가합니다.

# snippet to download the Debug image on COS APs
# show version | in Compiled
# archive download-sw /reload tftp:///
# 
show clock
show version
show flash
show flash | i cnssdaemon.log
show boot
show filesystems
show image integrity

4. 실행 - ".\wlanpoller.exe"를 사용하여 도구를 실행합니다. 이 도구는 모든 액세스 포인트에 SSH를 적용하고 명령 출력을 수집합니다.

5. 데이터 검색 - 완료되면 새로 생성된 /data 폴더로 이동합니다. 하위 디렉토리를 따라 개별 AP 출력 파일이 포함된 최종 폴더로 이동합니다.

6. 분석 - 공식 박스 링크에서 "ap_detection_script.py"를 다운로드하고 "data" 폴더에 저장한 후 실행합니다.

7. 결과 검토 - 문제가 있는 상태의 AP 목록을 보려면 생성된 "Status_check_results.log"를 엽니다. 이러한 디바이스에는 업그레이드를 진행하기 전에 복구 단계(아래의 복구 섹션에 설명되어 있음)가 필요합니다. 여기에는 결과를 해석하는 방법에 대한 설명이 나와 있습니다.

AP는 파티션 1 또는 파티션 2에서 부팅할 수 있습니다. 한 파티션이 활성 상태이면 다른 파티션은 이미지 또는 APSP 다운로드에 사용됩니다. 논리 저장소 파티션은 파티션 2에 영구적으로 매핑되며 변경할 수 없습니다. 이 문제는 파티션 1에서 현재 부팅되는 액세스 포인트에만 영향을 줍니다. "current_boot_partition_check" 열을 확인하여 AP에서 사용하는 현재 파티션이 무엇인지 확인할 수 있습니다. 예:

위의 예에서 3개의 AP를 통해 다음과 같은 결론을 내릴 수 있습니다.

• AP 이름: AP1 테스트(필요한 조치): AP가 "current_boot_partition_check" 열에 part1 "True Sensitive"가 표시되면 "part2_mem_utilization_check" 열을 선택해야 합니다. 이 열에 "True Susable"도 표시되면 AP가 영향을 받습니다.

  • 예: 테스트 AP1이 영향을 받음(Part1 및 Part2 가용 공간에서 부팅: 51.9MB)이며 복구가 필요합니다.

• AP 이름: 테스트 AP2(파티션 1): AP에 part1 "True Sensitive"가 표시되지만 "part2_mem_utilization_check"에 "False Not Sensitive"가 표시되면 AP는 안전합니다.

  • 예: 테스트 AP2는 파티션 2(part2)에 충분한 공간이 있으므로 영향을 받지 않습니다. 그러나 cnssdaemon.log 파일이 AP에 계속 있으므로 향후 문제를 해결하기 위해 APSP를 설치하는 것이 좋습니다.

• AP 이름: 테스트 AP3(파티션 2): AP가 "current_boot_partition_check" 열에 part2 "False Not Sensitive"를 표시하면 영향을 받지 않습니다. 더 이상 확인할 필요가 없습니다.

참고: 참고: "참/거짓 감수성" 상태 옆의 "part2_mem_utilization_check" 열에 나타나는 숫자 값은 파티션 2에서 사용 가능한 공간의 양을 나타냅니다.

• 모든 액세스 포인트: AP에 "이미지 무결성 검사: "image_integrity_check" 열 아래의 "Failed(실패)"에 TAC 케이스를 열어 보십시오.

복구

스크립트는 각 AP의 특정 상태에 따라 가장 효율적인 복구 방법을 권장합니다. 식별된 영향 받는 AP에 대해 아래의 세부 단계를 수행합니다.

AP 이미지 파티션 스왑

1. AP 격리 - AP가 WLC와 연결되어 있지 않은지 확인합니다.
   1. AP 가입 프로필에서 SSH가 활성화되어 있고 AP가 SSH에 액세스할 수 있는지(또는 콘솔 사용) 확인합니다.
   2. AP가 WLC에 연결되어 있지 않지만 AP에 대한 SSH 액세스 권한이 있는지 확인합니다. 이 작업은 게이트웨이에 ACL을 설정하거나 AP를 격리 VLAN으로 이동하는 방법으로 수행할 수 있습니다. AP가 WLC에 액세스하면 AP가 부팅 Part1로 되돌아갈 수 있으며 영향을 받는 상태로 돌아갑니다.

2. 부팅 경로 구성 - 영향을 받는 AP에서 부팅 경로를 파티션 2로 설정합니다.

AP# config boot path 2

3. 재부팅 - 파티션 2에서 이미지를 로드하려면 AP를 다시 시작합니다.

AP# reload

4. 업그레이드 - 현재 코드에 필요한 APSP를 WLC에 설치합니다. 또는 코드를 업그레이드할 경우 새 코드로 이동하고 APSP도 설치되어 있는지 확인합니다.

5. 재연결 - 컨트롤러 업그레이드가 완료되면 AP와 WLC 간의 통신 스토퍼를 제거합니다. AP가 WLC에 조인하고 부트 Part1에서 새로운 고정 이미지를 자동으로 다운로드합니다.

6. 재확인 - 고정 릴리스로 업그레이드한 후 AP의 두 파티션을 모두 확인하여 백업 슬롯에 버기 이미지가 남아 있지 않은지 확인합니다.

7. 유지 관리 - 장기 안정성을 유지하고 향후 부팅 루프를 방지하려면 정상 작동이 확인된 이미지로 백업 파티션을 덮어쓰는 것이 좋습니다. 소규모 그룹의 경우 AP에서 직접 아카이브 "download-sw"를 사용합니다. 대규모 구축의 경우 AP 이미지 활성화를 트리거하지 않고 백업 파티션을 업데이트하려면 WLC AP 사전 다운로드를 수행합니다.

AP 셸 액세스 복구

TAC(Technical Assistance Center)는 영향을 받는 액세스 포인트의 셸에서 직접 cnssdaemon.log 파일을 지워 수동 복구를 수행할 수 있습니다. 영향의 크기에 따라 다음 두 가지 방법이 있습니다.

• 영향을 받는 AP 수: 영향받는 AP가 적은 경우 TAC는 다음 두 가지 방법 중 하나를 사용하여 진행할 수 있습니다.

  • 수동 셸 액세스: 셸을 통해 각 액세스 포인트에 개별적으로 액세스하여 로그 파일을 수동으로 지웁니다.

  • 자동화된(대량) 셸 액세스: RADKit 툴을 사용하여 영향을 받는 모든 AP에 대한 정리 프로세스를 자동화합니다.

• 다수의 영향을 받는 AP: TAC는 Radkit 툴을 사용해야 하며, 따라서 모든 영향을 받는 AP에 대한 대량 셸 액세스가 동시에 가능하므로 정리 프로세스를 효율적으로 실행할 수 있습니다.

참고: 효율성과 일관성을 보장하려면 AP 셸 액세스 복구 절차에 RADKit를 사용하는 것이 좋습니다.

참고: Radkit를 다운로드하려면 다음 링크를 사용하십시오. Radkit 최신 버전을 다운로드합니다. Radkit를 설치하려면 다음 비디오를 따르십시오. Radkit 설치

TAC 케이스 열기 시기

다음 조건 중 하나가 발생하면 즉시 TAC 케이스를 엽니다.

• 복구 실패: AP 이미지 AP 이미지 파티션 스왑 절차가 실패하거나 사용자 환경에서 구현할 수 없습니다.
• 무결성 문제: 수동 또는 자동화된 사전 점검에서는 "이미지 무결성 검사: 모든 AP에 대한 "실패" 상태입니다.
• 스토리지 소모: 업그레이드/APSP 설치 후 "/dev/ubivol/part2" 파티션의 사용량이 여전히 매우 높습니다.

Cisco TAC는 AP 셸에 액세스하여 cnssdaemon.log 파일을 수동으로 지우고 고급 복구 작업을 수행하여 디바이스를 복원할 수 있습니다.

FAQ

Q: 이 문제는 전체 코드 업그레이드에만 적용됩니까? 아니면 APSP 설치에도 영향을 미칩니까?

A : 이 문제는 두 시나리오 모두에 영향을 미칩니다. 사용자 환경이 이 버그의 기준을 충족하는 경우 전체 코드 업그레이드 또는 APSP 설치(버그 픽스가 있는 APSP 포함) 중에 문제가 발생할 수 있습니다. 업데이트 또는 APSP를 적용하기 전에 복구 단계를 수행해야 하는지 확인하려면 업그레이드 사전 검사 섹션을 완료하십시오.

Q: WLC 및 AP가 17.9.x(또는 이전 버전)에 있으며 17.12.x로 업그레이드해야 하는데 어떻게 해야 합니까?

A : 17.9.x에서 17.12.x로 직접 업그레이드할 수 있습니다. 그러나 AP 모델이 이 버그에 영향을 받기 쉬운 경우 업그레이드 직후에 권장 APSP를 설치해야 합니다.

Q: WLC 및 AP가 17.9.x(또는 이전 버전)에 있으며 17.15.x 이상으로 업그레이드해야 합니다.

A : 가능한 시나리오는 두 가지입니다.

• 직접 업그레이드: 사용자 환경에서 직접 업그레이드를 허용하는 경우(대상 코드의 릴리스 정보를 통해 확인하십시오), 업그레이드를 진행한 다음 해당 대상 코드의 APSP를 설치하십시오.
• 중간 업그레이드: 업그레이드 경로를 따라야 하는 경우(예: 17.9.x → 17.12.x → 17.15.x), 같은 날 17.15.x로 전체 시퀀스를 완료하는 것이 좋습니다. cnssdaemon.log 파일은 매일 5MB씩 증가하므로 업그레이드를 완료하면 파일이 중요한 크기에 도달하지 못하게 됩니다. 당일 업그레이드가 불가능한 경우 17.12.x 스테이지에서 APSP를 설치한 다음 17.15.x로 이동하여 해당 APSP를 설치해야 합니다.

Q: 나는 이미 17.15.x에 있다. 그럼 제가 이 버그에 영향을 받지 않은 건가요?

A : 꼭 그렇지는 않습니다. AP가 이전에 버전 17.12.4, 17.12.5 또는 17.12.6/6a(9800-L/40/80/CL에서)를 실행한 경우 문제가 있는 로그 파일이 이미 생성되어 스토리지에 남아 있을 수 있습니다. 나머지 파일을 정리하려면 Upgrade Prechecks(업그레이드 사전 검사) 섹션을 따르는 것이 좋습니다.

Q: 17.15에서 처음 지원되었던 9800-M, 9800-H1 또는 9800-H2 플랫폼을 사용하고 있는데, 영향을 받습니까?

A : 가능한 시나리오는 두 가지입니다.

• WLC에 처음 합류한 기업 AP가 9800-M/H1/H2를 최초의 컨트롤러로 연결한 경우 영향을 받지 않습니다.
• 이전 WLC 조인: 이러한 AP가 9800-M/H1/H2로 이동하기 전에 영향을 받는 버전(17.12.4/5/6/6a)을 실행하는 다른 컨트롤러에 이미 조인된 경우에도 문제가 되는 파일이 있을 수 있습니다. 이 경우 업그레이드 사전 검사 섹션을 따르십시오.

Q: 랩 테스트와 단계별 업그레이드를 위한 별도의 WLC가 있는데 어떻게 처리해야 할까요?

A : 해당 환경의 모든 WLC에서 적절한 APSP가 실행되고 있는지 확인합니다. cnssdaemon.log 파일은 매일 5MB씩 증가하므로, WLC를 실행하는 WLC에 조인하는 모든 AP는 테스트를 위해 일시적으로 이 버그에 영향을 받을 가능성이 있습니다.