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

소개

이 문서에서는 액세스 포인트가 Cisco 버그 ID CSCwf25731 및 CSCwf37271의 영향을 받는 경우의 검증 및 복구 절차에 대해 설명합니다.

대화식 지원

CCO 자격 증명으로 로그인하면 Cisco AI Assistant for Support를 통해 네트워크에 이 버그가 적용되는지 여부와 적용 가능한 경우 복구 옵션을 결정할 수 있습니다. 시작하려면 다음을 수행합니다.

1. 문서의 오른쪽 아래에 있는 Cisco AI Assistant for Support 아이콘을 클릭합니다.
   • 
2. Cisco 자격 증명을 사용하여 로그인합니다.
3. 로그인한 후 브라우저 탭/문서를 새로 고칩니다.
4. 오른쪽 아래 모서리에 있는 봇 아이콘을 클릭하여 이 문서와 관련된 질문을 시작합니다.
   
   • 

가장 좋은 결과를 얻으려면 간단한 질문으로 시작하여 점차 복잡성을 증가시킵니다. 응답이 만족스럽지 않은 경우 엄지 손가락 아래로 아이콘을 클릭하여 피드백을 제공해 주십시오. Cisco AI Assistant for Support에 대한 답변이 명확하지 않은 경우 언제든지 이 문서를 다시 참조할 수 있습니다.

컨텍스트

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

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

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

근본 원인 세부 정보

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

WLC# show version | in Version

또는 액세스 포인트에서도 같은 작업을 수행할 수 있습니다. 기본 또는 백업 이미지가 표에 나열된 이미지에서 영향을 받는 이미지를 실행 중인지 확인하려면 출력을 확인합니다.

AP# show version | in Image

컨트롤러 영향 코드	액세스 포인트 영향 받는 이미지
17.12.4	17.12.4.0에서 17.12.4.212로
17.12.5	17.12.5.0에서 17.12.5.208로
17.12.6/6a	17.12.6.0에서 17.12.6.200으로

고정 코드

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

컨트롤러 및 APSP 고정 코드	액세스 포인트 고정 이미지
17.12.4 + APSP13	17.12.4.213
17.12.5 + APSP9	17.12.5.209
17.12.6a + APSP1	17.12.6.201
17.12.7a	17.12.7.13
17.15.3 + APSP12	17.15.3.212
17.15.4b + APSP6	17.15.4.206
17.15.4d + APSP1	17.15.4.225
17.15.5	17.15.5.36
17.18.1 + APSP3	17.18.1.203
17.18.2 + APSP1	17.18.2.201

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

아래 표를 사용하여 현재 WLC 및 액세스 포인트 소프트웨어 버전이 이 버그에 적용되는지 여부와 수행할 업그레이드 단계를 확인하십시오. 현재 구축이 Bug applicable and upgrade path table(버그 해당 및 업그레이드 경로 테이블)의 릴리스와 일치하는 경우 추가 업그레이드를 시도하기 전에 Upgrade Prechecks(업그레이드 사전 검사) 섹션에 설명된 스토리지 사전 검사를 수행해야 합니다.

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

다음 표는 WLC 및 액세스 포인트가 이 버그에 적용되지 않는지를 보여줍니다.

현재 코드	대상 코드	버그 적용 가능성	업그레이드 전 - 사전 확인 필요	대상/업그레이드 경로	업그레이드 사전 확인	의견
17.3.x/17.6.x/17.9 x	17.12.x	아니요	아니요	17.12.4 + APSPx 17.12.5 + APSPx17.12.6a + APSPx17.12.7	아니요	대상 릴리스 정보 확인
17.9.x	모두(17.12.4/5/6/6a 제외)	아니요	아니요	대상 업그레이드 경로 팔로우	아니요	17.9.1에서 .5로 업그레이드하는 경우 17.15로 직접 업그레이드할 수 없습니다. 자세한 내용은 17.9.6 이상을 사용하십시오. 릴리스 정보 확인
17.12.1~17.12.3	모두(17.12.4/5/6/6a 제외)	아니요	아니요	대상 업그레이드 경로 팔로우	일반 프로세스	대상 릴리스 정보 확인
17.15+신규 구축	모두	아니요	아니요	모두	아니요
17.18.+새로운 구축	모두	아니요	아니요	모두	아니요

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

다음 표에서는 WLC 및 액세스 포인트가 이 버그에 적용되는지를 보여줍니다.

현재 코드	대상 코드	버그 적용 가능성	업그레이드 전 - 사전 확인 필요	대상/업그레이드 경로	업그레이드 사전 확인	의견
17.12.4/5/6/6a	17.12.x(4,5,6,6a 등), APSP	예	예: 업그레이드 사전 검사 섹션을 참조하십시오.	17.12.4 + APSP, 17.12.5 + APSP, 17.12.6a + APSP, 17.12.7	예	고정 APSP를 설치한 후 향후 17.12 업그레이드를 위해 추가 사전 점검이 필요하지 않습니다
17.12.4/5/6/6a	17.15.x / 17.18.x	예	예: 업그레이드 사전 검사 섹션을 참조하십시오.	각 17.12.x APSP를 업그레이드한 다음 17.15.x + APSP 또는 17.18.x + APSP로 업그레이드합니다.	첫 17.12 APSP 업그레이드의 경우 예, 이후 업그레이드의 경우 아니요.
모든 릴리스이지만 이전 이미지는 17.12.4/5/6/6a 중 하나입니다.	17.15.x	예	예: 업그레이드 사전 검사 섹션을 참조하십시오.	17.15.x + APSP	예
모든 릴리스이지만 이전 이미지는 17.12.4/5/6/6a 중 하나입니다.	17.18.x	예	예: 업그레이드 사전 검사 섹션을 참조하십시오.	17.18.x + APSP	예

업그레이드 사전 검사

액세스 포인트의 파티션 2(part2)에 코드 또는 APSP 설치를 위한 충분한 여유 공간이 있는지 확인하려면 다음 단계를 수행하여 스토리지 공간을 안전하게 복구해야 합니다.

1. 식별: 버그에 적용할 수 있는 특정 액세스 포인트를 식별하기 위해 수동 또는 자동화된 사전 검사를 실행합니다. 자동화된 사전 확인을 사용하는 것이 좋습니다.
2. 복구: 2부의 빈 공간으로 플래그가 지정된 액세스 포인트의 경우 공간 복구 섹션에서 설명한 복구 절차를 수행합니다.
3. 확인: 사전 검사를 다시 실행하여 모든 장치가 정상이고 part2 문제의 공간 가용성이 해결되었는지 확인합니다.
4. 업그레이드: Fixed Codes(고정 코드) 섹션에 나열된 고정 APSP로 업그레이드를 진행합니다.

두 가지 사전 검사 방법이 있습니다.

• 수동
• 자동화

시간을 절약하고 사람의 실수를 방지하기 때문에 자동화된 방법이 권장됩니다.

수동 사전 검사

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

WLC# show ap image
Total number of APs  : 4

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# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209

활성 부트 파티션을 확인합니다. "show boot" 명령을 사용하여 "BOOT path-list"가 part1을 가리키는지 확인합니다. 이는 액세스 포인트가 현재 기본 파티션에서 실행되고 있으며 보조 부품(part2)으로 업그레이드하려고 시도하여 문제가 발생할 수 있음을 나타냅니다.

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1

2. /dev/ubivol/part2 파티션을 확인하여 현재 파일 시스템 사용량을 확인합니다. "Available(사용 가능)" 열에 85M 미만이 표시되면 파티션에 APSP를 설치할 공간이 부족하여 업그레이드가 실패하고 부팅 루프가 트리거될 수 있습니다.

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

Part1에서 부팅하고 /dev/ubivol/part2에서 사용 가능한 8,500만 개 미만의 액세스 포인트를 나열합니다. 액세스 포인트는 공간 복구가 필요하기 때문입니다. 이 문서의 복구 섹션으로 이동할 수 있습니다.

자동화된 사전 검사

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

단계:

1.Extraction - WLANPoller 파일의 압축을 원하는 디렉토리에 풉니다. 압축을 풀면 다음과 같이 이름이 지정된 두 개의 디렉토리와 애플리케이션이 있습니다.

• 데이터
• 혼동
• WlanPollerGUI

2. 컨피그레이션 - WlanPollerGUI 애플리케이션을 시작하고 다음과 같이 설정을 구성합니다.

작업 유형: WLC 및 AP를 선택합니다. Access PointOnly 옵션의 경우 쉼표로 구분된 형식으로 액세스 포인트를 나열하는 ".txt" 파일을 업로드합니다(예: 192.168.166.105, Timpadil9166). 그런 다음 Enter Credentials(자격 증명 입력)를 클릭합니다.

액세스 포인트 전용 모드의 경우 다음 예제를 따라 ".txt" 파일을 사용하십시오.

자격 증명: WLC IP 주소 및 자격 증명을 입력합니다. 액세스 포인트 사용자 이름, 비밀번호, 액세스 포인트 가입 프로필의 enable 비밀번호를 포함합니다. Save(저장)를 클릭한 다음 Proceed(계속)를 클릭합니다.

워크플로: 액세스 포인트 플래시 검사기 워크플로를 선택하여 필요한 진단 명령을 실행합니다. 그런 다음 Proceed(진행)를 클릭합니다.

CLI 명령 목록: 이 단계는 자동으로 건너뜁니다. 액세스 포인트 플래시 검사기 워크플로에 필요한 명령 목록이 이미 포함되어 있습니다(3단계).

액세스 포인트 필터: 이 선택적 단계에서는 특정 사이트로 필터링할 수 있습니다. 사용하는 경우 확인란을 선택하고 사이트 태그 이름(대/소문자 구분)을 입력합니다. 작업을 마친 후 또는 이 단계를 건너뛰면 Preview를 클릭합니다.

미리보기: 여기에서 WLANPoller 설정을 검토합니다. 필수 CLI 명령은 이전 워크플로 단계에서 미리 채워집니다. 세부 정보를 확인한 후 확인 및 WLANPoller 시작을 클릭하여 SSH 연결 및 데이터 수집을 시작합니다.

3. 결과: 이 도구는 액세스 포인트에 대한 SSH 연결을 설정하여 필요한 명령을 실행합니다. 복구가 필요한 액세스 포인트를 식별하는 데 도움이 되는 결과가 표시됩니다. 이 데이터의 레코드는 WLANPoller 추출 디렉토리 내의 데이터 하위 폴더에 자동으로 저장됩니다.

결과 사전 검사

WLANPoller는 검사에 따라 영향을 받는 액세스 포인트를 다음 옵션 중 하나로 분류합니다.

• 안전 상태이지만 액세스 포인트의 백업 파티션에 버기 이미지가 있습니다. 액세스 포인트는 현재 안전하게 업그레이드할 수 있으며 코드/APSP 설치를 계속할 수 있습니다. 그러나 백업 파티션에는 여전히 민감한 이미지가 포함되어 있습니다.
• 이미지 파티션 스왑으로 복구: 액세스 포인트가 현재 파티션 1에서 부팅되었지만 파티션 2에는 업그레이드를 위한 충분한 공간이 없습니다. 액세스 포인트 부팅 파티션 스왑이 필요합니다.
• devshell로 복구: 파티션에 새 코드 또는 APSP를 설치할 공간이 부족하여 액세스 포인트를 devshell을 통해 복구해야 합니다.
• 이 AP에 대한 이미지 무결성 검사에 실패했습니다. 파티션 1 또는 파티션 2의 이미지가 무결성 검사에 실패했습니다. 수동 개입이 필요할 수 있습니다.

복구

사전 확인 결과에 따라 다음과 같이 네트워크에 가장 적합한 복구 옵션을 선택할 수 있습니다.

결과	복구 옵션
안전 상태이지만 액세스 포인트의 백업 파티션에 버기 이미지가 있습니다.	정보: 코드/APSP 설치를 계속할 수 있습니다.
이미지 파티션 스왑으로 복구	다음 4가지 옵션이 있습니다. 1. 액세스 포인트 핵심 파일을 삭제합니다. 2. 액세스 포인트를 공장 초기화. 3. 액세스 포인트 이미지 부트 파티션 스왑 4. cnssdaemon.log 파일 삭제(액세스 포인트 devshell) 환경 및 리소스 가용성에 가장 적합한 복구 옵션을 선택합니다.
devshell로 복구	2가지 옵션이 있습니다. 1. cnssdaemon.log 파일 삭제(액세스 포인트 devshell). 2. 액세스 포인트를 공장 초기화. 환경 및 리소스 가용성에 가장 적합한 복구 옵션을 선택합니다.
이 액세스 포인트에 대한 이미지 무결성 검사에 실패했습니다.	다음 절차를 따르십시오. TAC 케이스 열기 시기

액세스 포인트의 현재 상태에 따라 두 개의 복구 경로가 있습니다. 액세스 포인트의 상태는 다음과 같을 수 있습니다.

1. 파티션 2의 공간 부족: 이는 코드/APSP 설치를 시도할 때 업그레이드 전 단계(업그레이드 사전 검사 중 발견) 중에 발생합니다.
2. 액세스 포인트 부트루프: 공간이 부족함에도 불구하고 코드/APSP 설치를 시도하면 업그레이드 후에 이 문제가 발생합니다.

액세스 포인트의 가능한 각 상태에 대한 자세한 복구 단계는 아래에 설명되어 있습니다.

파티션 2의 공간 부족

업그레이드 사전 점검에서 파티션 1로 부팅되고 파티션 2에 공간이 부족한 액세스 포인트를 식별한 경우 다음 방법 중 하나를 사용하여 파티션에 공간을 만듭니다.

• 액세스 포인트 핵심 파일 삭제: 액세스 포인트는 코어 덤프를 /dev/ubivol/part2에 저장합니다. 이러한 파일이 있으면 삭제하면 충분한 공간이 확보될 수 있습니다. 삭제 후 업그레이드 사전 확인을 다시 실행하여 사용 가능한 공간이 설치 요구 사항을 충족하는지 확인해야 합니다.
• 액세스 포인트를 출하 시 재설정합니다. 공장 재설정을 수행하면 액세스 포인트가 기본 컨피그레이션으로 돌아갑니다. 이 프로세스에서는 일반적으로 코드/APSP를 성공적으로 설치하기 위해 파티션 2(2부)에 충분한 공간을 제공하여 일시적으로 스토리지에서 cnssdaemon.log 파일을 지웁니다.
• cnssdaemon.log 파일 삭제(액세스 포인트 devshell): 이 프로세스에서는 액세스 포인트 devshell에 액세스하여 cnssdaemon.log 파일을 수동으로 제거합니다. 이렇게 하려면 devshell 환경에 들어가려면 관리 액세스 및 TAC와의 조정이 필요합니다.
• 부팅 파티션 스왑: 파티션 2(part2)에 코드/APSP를 설치할 공간이 부족하지만 이미 기능 이미지가 포함되어 있는 경우, part2에서 액세스 포인트를 부팅하고 일반적으로 사용 가능한 공간이 있는 파티션 1(part1)로 설치를 타겟팅할 수 있습니다.

각 옵션에 대한 세부 정보를 검토하여 요구 사항을 숙지하십시오. 네트워크 환경 및 운영 요구 사항에 가장 부합하는 방법을 선택하십시오.

액세스 포인트 핵심 파일 삭제

SSH를 통해 각 액세스 포인트에 액세스하여 핵심 파일을 수동으로 삭제할 수 있습니다. 또는 WLANPoller를 사용하여 이 프로세스를 자동화하고 여러 액세스 포인트의 대량 모드에서 동시에 삭제를 수행할 수 있습니다.

수동 모드

SSH를 통해 각 액세스 포인트에 액세스하고 다음 명령을 실행합니다.

AP# delete /force cores
AP# reload
Proceed with reload? [confirm] yes

자동화 모드

WLANPoller 응용 프로그램을 시작하고 다음 단계를 수행합니다.

작업 유형: 작업 유형 WLC & AP를 선택합니다.

자격 증명: WLC 및 액세스 포인트 자격 증명을 입력합니다.

워크플로: 선택 사항을 Custom CLI Commands(사용자 지정 CLI 명령)로 업데이트하고 Proceed(진행)를 클릭합니다.

CLI 명령 목록: 표시된 대로 다음 Access Point 명령을 입력합니다. Save(저장)를 클릭한 다음 Proceed(진행)를 클릭합니다.

액세스 포인트 필터: 환경에 특정 필터가 필요하지 않은 경우 모든 확인란을 선택하지 않은 상태로 두고 Preview(미리보기)를 클릭합니다.

미리보기: 요약을 검토한 다음 확인 및 WLANPoller 시작을 누릅니다.

결과: 모든 대상 액세스 포인트에 대해 WLANPoller 실행이 성공적으로 완료되었는지 확인합니다.

복구 후 해당 섹션에 설명된 대로 Upgrade Precheck를 반복합니다. 영향을 받는 액세스 포인트가 여전히 공간 가용성이 낮은지 확인합니다. 그렇다면 여러분의 리소스에 더 적합한 다음 옵션으로 이동하십시오. 목록에서 지워진 경우 복구가 성공하므로 해당 액세스 포인트의 코드/APSP를 계속 진행할 수 있습니다.

액세스 포인트를 공장 초기화

액세스 포인트를 공장 기본값으로 재설정하면 cnssdaemon.log 파일이 일시적으로 삭제됩니다. 코드/APSP 설치를 성공적으로 수행하려면 공장 초기화 후 48시간 내에 코드/APSP 설치를 진행하십시오.

액세스 포인트를 공장 출하 시 재설정하는 방법에는 세 가지가 있습니다.

• WLC(CLI 또는 GUI)를 통해 액세스합니다.

• 액세스 포인트 CLI를 통해

• 액세스 포인트 물리적 재설정 버튼을 통해

WLC CLI를 통해

WLC# clear ap config <APNAME> keep-ip-config

WLC GUI 사용

Configuration(컨피그레이션) > Wireless(무선) > Access Points(액세스 포인트)로 이동합니다. 원하는 액세스 포인트를 선택한 다음 Advanced(고급) > Set to Factory Default(공장 기본값으로 설정)로 이동합니다. Clear Config except Static IP(고정 IP를 제외한 컨피그레이션 지우기) 옵션을 선택하고 Update & Apply to Device(디바이스에 업데이트 및 적용)를 클릭합니다.

액세스 포인트 CLI를 통해

AP# capwap ap erase all 
WARNING :" capwap ap erase all" is altered to perform DATA WIPE on COS AP.
The following files will be cleared as part of this process
1) Config ,Bak config files
2) Crashfiles
3) syslogs
4) Boot variables
5) Pktlogs
6) Manually created files
Are you sure you want continue? [confirm] yes
AP# reload 
Proceed with reload command (cold)? [confirm] yes

Via Access Point(액세스 포인트 모드) 버튼

1. 전원에서 액세스 포인트의 연결을 해제합니다.

2. 모드 단추를 길게 누릅니다.

3. 단추를 계속 누르고 있는 동안 전원을 다시 연결합니다.

4. 액세스 포인트 상태 LED가 빨간색으로 켜지면 모드 버튼을 10초 더 누릅니다.

5. 버튼을 놓습니다.

6. 액세스 포인트가 공장 기본 설정으로 재부팅됩니다.

cnssdaemon.log 파일 삭제(액세스 포인트 devshell)

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

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

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

  • 자동화된(대량) devshell 액세스: RADKit 툴을 사용하여 영향을 받는 모든 액세스 포인트에 대한 cnssdaemon.log 파일의 정리 프로세스를 자동화합니다.

• 다수의 영향을 받는 액세스 포인트: TAC는 RADKit 툴을 사용해야 하며, 이를 통해 자동화된 방식으로 모든 영향을 받는 액세스 포인트에 대한 대량 devshell 액세스를 허용하여 정리 프로세스를 효율적으로 실행할 수 있습니다.

아래 링크를 통해 RADKit 다운로드 및 설치 지침에 액세스:

• RADKit 다운로드
• RADKit 설치

RADKit를 통해 액세스 포인트에서 cnssdaemon.log 파일을 삭제하려면 모든 액세스 포인트가 인벤토리에 나열되어 있는지 확인합니다. 이 작업은 관리자 전용 작업이며 TAC에서 원격으로 수행할 수 없습니다. RADKit 인벤토리에 액세스 포인트를 대량으로 추가하려면 다음 단계를 따르십시오.

1. RADKit의 WLC: WLC가 RADKit 인벤토리에 이미 추가되었는지 확인합니다. 이 프로세스에 대한 도움이 필요한 경우 공식 RADKit 문서에서 여기의 Adding Devices(디바이스 추가) 섹션을 따르십시오

2. WLC 인벤토리 아이콘: Devices(디바이스) 탭 아래에서 WLC를 찾고 Actions(작업) 열에서 Inventory(인벤토리) 아이콘을 클릭합니다.

3. 대량 수입 RADKit에 대한 액세스 포인트 추가 프로세스를 시작하려면 대량 가져오기 단추를 선택합니다.

4. 대량 구성 cnssdaemon.log 파일 삭제가 필요한 모든 액세스 포인트의 확인란을 선택합니다. 장바구니에 추가 아이콘(더하기 기호가 있는 장바구니)을 클릭한 다음 일괄 편집 단추를 선택합니다.

5. 터미널 활성화 및 SSH 구성: Cart Bulk Editor에서 Device Type(디바이스 유형)을 선택하고 Cisco AP OS(Cisco AP OS)를 선택합니다. 액세스 포인트에 대한 SSH 컨피그레이션을 허용하려면 터미널 토글을 활성화합니다.

6. SSH 자격 증명을 구성합니다. SSH(비밀번호)를 클릭하고 액세스 포인트 자격 증명을 입력합니다. 비밀번호 사용 확인란을 선택하고 비밀번호를 입력합니다. 적용 및 지우기를 클릭하여 이러한 설정을 저장하고 창을 닫습니다. AP Join Profile을 통해 WLC에서 SSH가 활성화되어 있으며 사용자 이름과 비밀번호가 최신 상태이고 올바른지 확인합니다.

7. 원격 사용자 추가: 여기 공식 RADKit 문서의 원격 사용자 추가 단계에 따라 TAC 케이스에 할당된 엔지니어의 Cisco CCO ID를 추가합니다.

8. 대상 액세스 포인트 목록 영향을 받는 액세스 포인트의 정확한 이름을 수집합니다(참고: 이는 대/소문자를 구분합니다.) 파일을 TAC 케이스에 업로드합니다.

액세스 포인트 이름으로 설정 및 파일 업로드가 완료되면 Cisco TAC는 RADKit를 통해 필요한 원격 액세스를 통해 cnssdaemon.log 파일의 대량 삭제를 수행합니다.

액세스 포인트 이미지 부트 파티션 스왑

부팅 파티션 스왑은 액세스 포인트별로 수동으로 액세스 포인트를 수행하거나 WLANPoller를 사용하여 액세스 포인트 액세스를 통해 대량으로 자동화할 수 있습니다.

수동

액세스 포인트에 SSH를 연결하고 다음 명령을 실행합니다.

AP# config boot path 2
AP# reload
Proceed with reload? [confirm] yes

자동화

WLANPoller를 사용하여 다른 액세스 포인트에 대한 boot part 명령을 대량으로 실행합니다.

1. 영향을 받는 액세스 포인트 격리 - 영향을 받는 액세스 포인트가 WLC와 연결되어 있지 않은지 확인합니다.
   • 액세스 포인트 조인 프로필에서 SSH가 활성화되어 있고 액세스 포인트가 SSH에 액세스할 수 있는지(또는 콘솔 사용) 확인합니다.
   • 액세스 포인트에 WLC와의 연결이 없지만 액세스 포인트에 대한 SSH 액세스 권한이 있는지 확인합니다. 이는 게이트웨이에 ACL을 보유하거나 액세스 포인트를 격리된 VLAN으로 이동하는 방법으로 수행할 수 있습니다. 액세스 포인트가 WLC에 액세스할 경우 액세스 포인트는 부팅 파티션 1(part1)로 되돌아갈 수 있으며 영향을 받는 상태로 돌아갑니다.

2. 부팅 경로2를 구성하고 영향을 받는 액세스 포인트를 재부팅합니다. - 명령줄을 통해 영향을 받는 액세스 포인트에 부팅 부분을 1에서 2로 변경한 다음 재부팅하도록 지시하도록 WlanPoller를 구성합니다.

작업 유형: AP Only(AP 전용) 옵션을 선택한 다음 텍스트 편집기(대소문자 구분)에서 Access Points IP Address and Name(액세스 포인트 IP 주소 및 이름)을 추가하고 Browse(찾아보기)를 클릭하여 액세스 포인트 IP 주소와 이름이 포함된 파일을 선택합니다. 그런 다음 Enter Credentials(자격 증명 입력)를 클릭합니다.

액세스 포인트 목록 형식:

작업 유형 선택:

자격 증명: 액세스 포인트 자격 증명을 입력하고 Save(저장)를 클릭한 다음 Proceed(계속)를 클릭합니다.

워크플로: Custom CLI Commands(사용자 지정 CLI 명령)를 선택한 다음 Proceed(진행)를 클릭합니다.

CLI 명령 목록: 액세스 포인트가 part2로 부팅되고 다시 로드되도록 명령을 구성합니다. 그런 다음 Save(저장)를 클릭하고 Proceed(진행)를 클릭합니다.

미리보기: 미리 보기에는 액세스 포인트로 실행될 2개의 명령이 표시됩니다. Confirm and Start WlanPoller(확인 및 WlanPoller 시작)를 클릭합니다.

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

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

액세스 포인트 부트루프

먼저 업그레이드 사전 확인을 따르지 않고 코드/APSP 설치를 수행했으며 액세스 포인트가 부트루프로 종료된 경우, 2가지 옵션을 사용할 수 있습니다.

1. Factory reset the Access Points 섹션에 설명된 대로 Factory reset the Access Point with the mode(모드 버튼을 사용하여 액세스 포인트를 공장 초기화) 섹션에 설명되어 있습니다.
2. 콘솔 액세스 권한을 얻고 TAC 케이스를 열어 TAC에서 액세스 포인트 복구를 진행합니다.

TAC 케이스 열기 시기

다음 조건 중 하나가 발생하는 경우 TAC 케이스를 엽니다.

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

FAQ

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

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

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

A : 17.9.x에서 17.12.x로 직접 업그레이드할 수 있습니다. 그러나 액세스 포인트 모델에 이 버그가 발생할 수 있는 경우 업그레이드 직후에 권장 APSP를 설치해야 합니다.

Q: WLC 및 액세스 포인트가 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 : 꼭 그렇지는 않습니다. 액세스 포인트에서 이전에 버전 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에 처음 합류한 기업 액세스 포인트가 9800-M/H1/H2에 처음 컨트롤러로 연결된 경우 영향을 받지 않습니다.
• 이전 WLC 조인: 이러한 액세스 포인트가 9800-M/H1/H2로 이동하기 전에 영향을 받는 버전(17.12.4/5/6/6a)을 실행하는 다른 컨트롤러에 이미 조인된 경우에도 문제가 되는 파일이 있을 수 있습니다. 이 경우 업그레이드 사전 검사 섹션을 따르십시오.

Q: 랩 테스트와 단계별 업그레이드를 위한 별도의 WLC가 있습니다. 어떻게 처리해야 합니까?

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

개정 이력

개정	게시 날짜	의견
4.0	24-Mar-2026	복구 메커니즘 업데이트 및 WLAN 폴러를 사용한 향상된 자동화 기능 포함
3.0	27-Feb-2026	추가 된 FAQ 및 추가 복구 시나리오
2.0	23-Feb-2026	업그레이드 경로 적용 가능성에 대한 세부 정보 추가
1.0	30-Jan-2026	최초 릴리스