무선 LAN 컨트롤러 CPU 로드 문제 해결
소개
이 문서에서는 Catalyst 9800 Wireless LAN Controller의 CPU 사용량을 모니터링하는 방법에 대해 설명하며, 몇 가지 구성 권장 사항을 다룹니다.
CPU 사용량 이해
CPU 로드 트러블슈팅을 자세히 살펴보기 전에 Catalyst 9800 Wireless LAN Controller에서 CPU를 사용하는 방법의 기본 사항과 소프트웨어 아키텍처에 대한 몇 가지 세부 사항을 이해해야 합니다.
일반적으로 Catalyst 9800 Best Practices 문서는 애플리케이션 수준 문제를 방지할 수 있는 구성 설정 집합을 정의합니다. 예를 들어 mDNS에 대한 위치 필터링을 사용하거나 클라이언트 제외가 항상 활성화되어 있는지 확인합니다. 여기에 표시된 주제와 함께 이러한 권장 사항을 적용하는 것이 좋습니다.
플랫폼 기본 사항
Catalyst 9800 컨트롤러는 서로 다른 네트워크 부하를 대상으로 하며 수평적 확장에 초점을 맞춘 유연한 플랫폼으로 설계되었습니다. 내부 개발 명명은 탄력성을 위해 "e"가 포함된 eWLC로, 동일한 소프트웨어 아키텍처가 소규모 단일 CPU 임베디드 시스템에서 여러 CPU/코어 대규모 어플라이언스로 실행됨을 의미합니다.
각 WLC에는 두 개의 서로 다른 측면이 있습니다.
- 컨트롤 플레인: CLI, UI, Netconf 및 클라이언트와 AP의 모든 온보딩 프로세스와 같은 모든 관리 상호 작용 처리
- 데이터 플레인: 다른 기능 중에서도 CAPWAP, AVC 정책 시행의 실제 패킷 전달 및 역캡슐화 담당
컨트롤 플레인
- 대부분의 Cisco IOS® 프로세스는 고유한 전문 스케줄러 및 모니터링 명령을 사용하여 BinOS(Linux 커널)에서 실행됩니다.
- WNCD(Wireless Network Control Daemon)라는 주요 프로세스 집합이 있으며, 각 프로세스에는 대부분의 무선 활동을 처리하는 로컬 메모리 내 데이터베이스가 있습니다. 각 CPU는 WNCD를 소유하여 모든 사용 가능한 CPU 코어에 로드를 분산시켜 각 시스템으로 보냅니다
- AP 가입 중에 WNCD 전체의 로드 분배가 완료됩니다. AP가 컨트롤러에 대한 CAPWAP 조인을 수행할 때 내부 로드 밸런서는 가능한 규칙 집합을 사용하여 AP를 배포하여 사용 가능한 모든 CPU 리소스를 적절하게 사용합니다.
- Cisco IOS® 코드는 IOSd라는 자체 프로세스에서 실행되며 CPU 스케줄러가 있습니다. 이는 특정 기능(예: CLI, SNMP, 멀티캐스트 및 라우팅)을 처리합니다.
간소화된 보기에서 컨트롤러는 컨트롤 플레인과 데이터 플레인, 즉 punt 간에 통신 메커니즘을 가지며, 네트워크에서 컨트롤 플레인으로 트래픽을 전송하고, 인젝션을 수행하며, 컨트롤 플레인의 프레임을 네트워크로 푸시합니다.
가능한 높은 CPU 문제 해결 조사의 일환으로, 제어 평면에 도달하는 트래픽이 무엇인지 평가하고 높은 로드를 초래할 수 있는 펀트 메커니즘을 모니터링해야 합니다.
데이터 플레인
Catalyst 9800 컨트롤러의 경우 여러 제품 및 기술에 사용되는 패킷 포워딩 엔진을 개발하는 소프트웨어 프레임워크인 Cisco CPP(Packet Processor)의 일부로 실행됩니다.
아키텍처는 상이한 하드웨어 또는 소프트웨어 구현 전반에 걸쳐 공통 기능 세트를 허용한다. 예를 들어, 9800CL과 9800-40의 경우 서로 다른 처리량 범위에서 유사한 기능을 제공합니다.
AP 로드 밸런싱
WLC는 CAPWAP AP 조인 프로세스 동안 CPU 간에 로드 밸런싱을 수행하며, 주요 차별화 요소는 AP 사이트 태그 이름입니다. 각 AP는 클라이언트 활동 및 AP 자체에서 추가된 특정 CPU 로드를 나타냅니다. 이 밸런싱을 수행하는 몇 가지 메커니즘이 있습니다.
- AP가 기본 태그를 사용하는 경우, 모든 CPU/WNCD에서 라운드 로빈 방식으로 밸런싱되며 새로운 각 AP가 다음 WNCD로 조인됩니다. 가장 간단한 방법이지만 다음과 같은 몇 가지 의미가 있습니다.
- 동일한 RF 로밍 도메인의 AP가 WNCD 간 로밍이 빈번하여 추가 프로세스 간 통신이 이루어지기 때문에 이는 최적의 시나리오가 아닙니다. 인스턴스 간 로밍은 적은 비율로 더 느립니다.
- FlexConnect(원격) 사이트 태그의 경우 PMK 키 배포를 사용할 수 없습니다. 즉, Flex 모드의 빠른 로밍을 완료할 수 없으므로 OKC/FT 로밍 모드에 영향을 미칩니다.
일반적으로 기본 태그는 낮은 로드 시나리오(예: 9800 플랫폼의 AP 및 클라이언트 로드의 40% 미만)에서, 빠른 로밍이 필요하지 않은 경우에만 FlexConnect 구축에서 사용할 수 있습니다.
- AP에 사용자 지정 사이트 태그가 있는 경우, AP가 사이트 태그 이름에 처음 속할 때 컨트롤러가 참여하면 사이트 태그가 특정 WNCD 인스턴스에 할당됩니다. 동일한 태그를 사용하는 이후의 모든 추가 AP 조인은 동일한 WNCD에 할당됩니다. 이렇게 하면 동일한 사이트 태그의 AP 간에 하나의 WCND 컨텍스트에서 로밍이 수행됩니다. 이렇게 하면 CPU 사용량이 감소하면서 더 최적의 플로우를 제공합니다. WNCD 간 로밍이 지원되지만 WNCD 내 로밍에서는 최적화되지 않습니다.
- 기본 로드 밸런싱 결정: 태그가 WNCD에 할당되면 로드 밸런서는 해당 시점에 사이트 태그 수가 가장 적은 인스턴스를 선택합니다. 사이트 태그에 포함할 수 있는 총 로드를 알 수 없으며, 최적화되지 않은 밸런싱 시나리오로 이어질 수 있습니다. 이는 AP가 연결되는 순서, 정의된 사이트 태그 수, AP 수가 비대칭인 경우에 따라 달라집니다.
- 정적 로드 밸런싱: WNCD에 대한 사이트 태그 할당의 불균형을 방지하기 위해 버전 17.9.3 이상에서 site load 명령이 도입되었습니다. 이를 통해 관리자는 각 사이트 태그의 예상 로드를 미리 정의할 수 있습니다. 이 기능은 캠퍼스 시나리오 또는 여러 지사를 처리할 때 유용합니다. 각각 서로 다른 AP 카운트에 매핑되어 로드가 WNCD에 고르게 분산되도록 합니다.
하나의 본사를 처리하는 9800-40과 서로 다른 AP 수를 가진 5개의 지사를 처리하는 경우 다음과 같이 구성할 수 있습니다.
wireless tag site office-main
load 120
wireless tag site branch-1
load 10
wireless tag site branch-2
load 12
wireless tag site branch-3
load 45
wireless tag site branch-4
load 80
wireless tag site branch-5
load 5
이 시나리오에서는 기본 사무실 태그를 branch-3 및 branch-4와 동일한 WNCD에 두지 않습니다. 총 6개의 사이트 태그가 있으며 플랫폼에는 5개의 WNCD가 있으며 로드된 가장 높은 사이트 태그가 동일한 CPU에 상주할 가능성이 있습니다. load 명령을 실행하면 예측 가능한 AP 로드 밸런싱 토폴로지를 생성할 수 있습니다.
load 명령은 예상 크기입니다. AP 수를 정확하게 일치시킬 필요는 없지만, 일반적으로 가입할 수 있는 예상 AP로 설정됩니다.
- 단일 컨트롤러로 처리하는 대규모 건물이 있는 시나리오에서는 해당 특정 플랫폼에 대해 WNCD만큼 사이트 태그를 생성하는 것이 더 쉽습니다(예: C9800-40에 5개, C9800-80에 8개). 동일한 영역 또는 로밍 도메인의 AP를 동일한 사이트 태그에 할당하여 WNCD 간 통신을 최소화합니다.
- RF 로드 밸런싱: 이렇게 하면 RRM의 RF 네이버 관계를 사용하여 WNCD 인스턴스 전체에서 AP의 균형을 맞추고 AP가 서로 얼마나 가까운지에 따라 하위 그룹을 만듭니다. AP가 잠시 작동 및 실행된 후 완료해야 하며, 정적 부하 분산 설정을 구성할 필요가 없습니다. 17.12 이상에서 사용할 수 있습니다.
WNCD 수를 찾는 방법
하드웨어 플랫폼의 경우 WNCD 수는 고정되어 있습니다. 9800-40에는 5개, 9800-80에는 8개가 있습니다. 9800CL(가상)의 경우 WNCD 수는 초기 구축 중에 사용된 가상 머신 템플릿에 따라 달라집니다.
일반적으로 시스템에서 실행 중인 WNCD의 수를 확인하려면 모든 컨트롤러 유형에서 이 명령을 실행할 수 있습니다.
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
9800-CL의 경우 다음과 같이 show platform software system all 명령을 실행하여 가상 플랫폼에 대한 세부 정보를 수집할 수 있습니다.
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
AP 로드 밸런싱 모니터링
AP 대 WNCD 할당은 AP CAPWAP 조인 프로세스 중에 적용되며 밸런싱 방법과 상관없이 작업 중에는 변경되지 않습니다. 그렇지 않으면 모든 AP의 연결이 끊기고 다시 참가하는 네트워크 전체의 CAPWAP 재설정 이벤트가 발생합니다.
CLI show wireless loadbalance tag affinity 명령을 실행하면 모든 WNCD 인스턴스에서 AP 로드 밸런스의 현재 상태를 쉽게 확인할 수 있습니다.
98001#show wireless loadbalance tag affinity
Tag Tag type No of AP's Joined Load Config Wncd Instance
---------------------------------------------------------------------------------------------
Branch-tag SITE TAG 10 0 0
Main-tag SITE TAG 200 0 1
default-site-tag SITE TAG 1 NA 2
클라이언트 수 및 CPU 로드에 대해 AP 분배의 상관관계를 분석하려면 WCAE 지원 툴을 사용하여 통화 중에 사용된 show tech 무선을 로드할 수 있습니다. 이 툴에는 연결된 각 AP에서 가져온 WNCD 클라이언트 수가 요약되어 있습니다.
이는 낮은 사용량과 클라이언트 수 동안 적절하게 균형 조정된 컨트롤러의 예입니다.
다른 예는 로드가 더 많은 컨트롤러에 대한 것으로, 정상적인 CPU 사용률을 보여줍니다.
권장되는 AP 로드 밸런싱 메커니즘이란 무엇입니까?
간단히 말해, 다음과 같은 여러 옵션을 요약할 수 있습니다.
- 빠른 로밍이 필요 없는 소규모 네트워크, 컨트롤러 부하의 40% 미만: 기본 태그입니다.
- 빠른 로밍이 필요한 경우(OKC, FT, CCKM) 또는 큰 클라이언트 수:
- 단일 건물: CPU(플랫폼에 따라 다름)만큼 사이트 태그를 생성합니다.
- 17.12 이전 또는 500개 미만의 AP 수: 여러 건물, 지사 또는 대규모 캠퍼스: 물리적 RF 위치별로 site-tag를 생성하고 사이트별로 load 명령을 구성합니다.
- AP가 500개를 초과하는 17.12 이상: RF 로드 밸런싱을 사용합니다.
이 500 AP 임계값은 로드 밸런싱 메커니즘을 적용하는 것이 효과적인 시점을 나타내기 위한 것으로, 기본적으로 100개 단위로 구성된 블록의 AP를 그룹화하기 때문입니다.
AP WNCD 배포 시각화
고급 AP 밸런싱을 적용할 수 있는 시나리오가 있으며, AP가 CPU 간에 분산되는 방식을 세부적으로 제어하는 것이 좋습니다. 예를 들어, 키 로드 메트릭이 클라이언트 카운트인 매우 고밀도 시나리오와 시스템에 있는 AP 수에 초점을 맞추는 시나리오가 있습니다.
이러한 상황을 보여주는 좋은 예는 빌딩에서 수백 개의 AP를 통해 수천 개의 클라이언트를 호스팅할 수 있는 대규모 이벤트입니다. 가능한 한 많은 CPU에 로드를 분산해야 하지만 동시에 로밍을 최적화해야 합니다. 필요한 경우가 아니면 WNCD를 로밍하지 않습니다. 서로 다른 WNCD/사이트 태그의 여러 AP가 동일한 물리적 위치에서 뒤섞이는 상황을 방지하고자 합니다.
WCAE 툴을 사용하여 세부적으로 조정하고 분포의 시각화를 제공하기 위해 AP RF View 기능을 활용할 수 있습니다.
이렇게 하면 AP/WNCD 배포를 볼 수 있습니다. View Type(보기 유형)을 WNCD로 설정하면 됩니다. 각 색상은 WNCD/CPU를 나타내며 RSSI 필터를 -85로 설정하여 신호 연결이 적음을 방지할 수 있습니다. 또한 컨트롤러의 RRM 알고리즘에 의해 필터링됩니다.
앞의 예에서 Cisco EMEA 24에 해당하는 경우, 대부분의 인접 AP가 동일한 WNCD에 걸쳐 클러스터링되며 교차 중복이 매우 제한됨을 확인할 수 있습니다. 동일한 WNCD에 할당된 사이트 태그는 동일한 색상을 받습니다.
컨트롤 플레인 CPU 사용량 모니터링
Cisco IOS XE 아키텍처의 개념을 기억하고 CPU 사용량에 대한 두 가지 주요 보기를 기억해야 합니다. 하나는 Cisco IOS 지원 기록에 기반하며, 다른 하나는 모든 프로세스 및 코어에 대한 CPU를 전체적으로 볼 수 있는 기능입니다.
일반적으로 show processes cpu platform sorted 명령을 실행하여 Cisco IOS XE의 모든 프로세스에 대한 자세한 정보를 수집할 수 있습니다.
9800cl-1#show processes cpu platform sorted
CPU utilization for five seconds: 8%, one minute: 14%, five minutes: 11%
Core 0: CPU utilization for five seconds: 6%, one minute: 11%, five minutes: 5%
Core 1: CPU utilization for five seconds: 2%, one minute: 8%, five minutes: 5%
Core 2: CPU utilization for five seconds: 4%, one minute: 12%, five minutes: 12%
Core 3: CPU utilization for five seconds: 19%, one minute: 23%, five minutes: 24%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19953 19514 44% 44% 44% S 190880 ucode_pkt_PPE0
28947 8857 3% 10% 4% S 1268696 linux_iosd-imag
19503 19034 3% 3% 3% S 247332 fman_fp_image
30839 2 0% 0% 0% I 0 kworker/0:0
30330 30319 0% 0% 0% S 5660 nginx
30329 30319 0% 1% 0% S 20136 nginx
30319 30224 0% 0% 0% S 12480 nginx
30263 1 0% 0% 0% S 4024 rotee
30224 8413 0% 0% 0% S 4600 pman
30106 2 0% 0% 0% I 0 kworker/u11:0
30002 2 0% 0% 0% S 0 SarIosdMond
29918 29917 0% 0% 0% S 1648 inet_gethost
강조할 몇 가지 핵심 사항은 다음과 같습니다.
- ucode_pkt_PPE0 프로세스는 9800L 및 9800CL 플랫폼에서 데이터 플레인을 처리합니다. 100% 이상에서도 높은 활용도를 보일 것으로 예상된다. 이는 구현의 일부이므로 문제가 되지 않습니다.
- 최대 사용량을 지속적인 부하와 구별하고 주어진 시나리오에서 예상되는 것을 격리하는 것이 중요합니다. 예를 들어 show tech wireless와 같은 매우 큰 CLI 출력을 수집하면 수백 개의 CLI 명령이 실행되면서 매우 큰 텍스트 출력이 수집되므로 IOSd, smand 및 pubd 프로세스에 최대 로드가 발생할 수 있습니다. 이는 문제가 되지 않으며 출력이 완료되면 부하가 감소합니다.
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19371 19355 62% 83% 20% R 128120 smand
27624 27617 53% 59% 59% S 1120656 pubd
4192 4123 11% 5% 4% S 1485604 linux_iosd-imag
- 클라이언트 작업 시간이 많은 동안에는 WNCD 코어의 최대 사용률이 예상됩니다. 기능적인 충격 없이 80%의 피크를 확인할 수 있으며, 통상 이상이 없는 것을 확인할 수 있다.
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
21094 21086 25% 25% 25% S 978116 wncd_0
21757 21743 21% 20% 20% R 1146384 wncd_4
22480 22465 18% 18% 18% S 1152496 wncd_7
22015 21998 18% 17% 17% S 840720 wncd_5
21209 21201 16% 18% 18% S 779292 wncd_1
21528 21520 14% 15% 14% S 926528 wncd_3
- 15분 이상 동안 90%보다 높은 프로세스에서 지속적으로 높은 CPU 사용량을 조사해야 합니다.
- show processes cpu sorted 명령을 실행하여 IOSd CPU 사용률을 모니터링할 수 있습니다. 이는 Cisco IOS XE 목록의 linux_iosd-imag 프로세스 부분의 활동에 해당합니다.
9800cl-1#show processes cpu sorted
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
215 81 88 920 1.51% 0.12% 0.02% 1 SSH Process
673 164441 7262624 22 0.07% 0.00% 0.00% 0 SBC main process
137 2264141 225095413 10 0.07% 0.04% 0.05% 0 L2 LISP Punt Pro
133 534184 21515771 24 0.07% 0.04% 0.04% 0 IOSXE-RP Punt Se
474 1184139 56733445 20 0.07% 0.03% 0.00% 0 MMA DB TIMER
5 0 1 0 0.00% 0.00% 0.00% 0 CTS SGACL db cor
6 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o
2 198433 726367 273 0.00% 0.00% 0.00% 0 Load Meter
7 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
10 3254791 586076 5553 0.00% 0.11% 0.07% 0 Check heaps
4 57 15 3800 0.00% 0.00% 0.00% 0 RF Slave Main Th
8 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
- 9800 GUI를 사용하여 IOSd 로드, 코어 사용량 및 데이터 플레인 로드를 빠르게 확인할 수 있습니다.
이는 Monitoring/System/CPU Utilization(모니터링/시스템/CPU 사용률) 탭에서 사용할 수 있습니다.
각 프로세스
프로세스 목록은 컨트롤러 모델 및 Cisco IOS XE 버전에 따라 다릅니다. 몇 가지 주요 프로세스의 목록이며 모든 가능한 항목을 다루지는 않습니다.
| 프로세스 이름 |
기능 |
평가 |
| wncd_x |
대부분의 무선 작업을 처리합니다. 9800 모델에 따라 1개에서 8개 사이의 인스턴스를 가질 수 있습니다. |
바쁜 시간 동안 활용도가 높은 피크 시간을 확인할 수 있습니다. 사용률이 몇 분 동안 95% 이상 고착된 경우 보고합니다. |
| linux_iosd-imag |
Cisco IOS 프로세스 |
대규모 CLI 출력을 수집할 경우 활용도가 높을 것으로 예상됩니다(show tech). SNMP 작업이 많거나 너무 빈번하면 CPU가 높아질 수 있습니다. |
| 녹스 |
웹 서버 |
이 공정은 피크를 나타낼 수 있고, 단지 지속적인 높은 부하에 대해 보고될 수 있다. |
| ucode_pkt_PPE0 |
9800CL/9800L의 데이터 플레인 |
show platform hardware chassis active qfp datapath utilization 명령을 실행하여 이 구성 요소를 모니터링합니다. |
| 에즈만 |
인터페이스용 칩셋 관리자 |
지속적인 높은 CPU는 HW 문제 또는 커널 소프트웨어 문제(보고될 수 있음)를 나타낼 수 있습니다. |
| DBM |
데이터베이스 관리자 |
여기서 지속적인 높은 CPU를 보고할 수 있습니다. |
| odm_X |
Operation Data Manager가 프로세스 간에 통합된 DB 처리 |
로드된 시스템에 높은 CPU가 필요합니다. |
| 밧줄 |
비인가 기능 처리 |
여기서 지속적인 높은 CPU를 보고할 수 있습니다. |
| 스만드 |
Shell Manager는 CLI 구문 분석 및 여러 프로세스 간의 상호 작용을 처리합니다. |
큰 CLI 출력을 처리할 때 높은 CPU가 필요합니다. 로드가 없는 경우에도 지속적으로 높은 CPU를 유지할 수 있습니다. |
| emd |
Shell Manager - CLI 구문 분석 및 여러 프로세스 간의 상호 작용을 처리합니다. |
큰 CLI 출력을 처리할 때 높은 CPU가 필요합니다. 로드가 없는 경우에도 지속적으로 높은 CPU를 유지할 수 있습니다. |
| 술집 |
텔레메트리 처리의 일부 |
대규모 텔레메트리 서브스크립션에 높은 CPU가 필요합니다. 로드가 없는 경우에도 지속적으로 높은 CPU를 유지할 수 있습니다. |
높은 CPU 보호 메커니즘
Catalyst 9800 Wireless LAN Controller는 네트워크 또는 무선 클라이언트 활동에 대한 광범위한 보호 메커니즘을 통해 우발적 또는 의도적인 시나리오로 인한 높은 CPU를 방지합니다. 문제가 되는 장치를 포함할 수 있도록 설계된 몇 가지 주요 기능이 있습니다.
클라이언트 제외
이는 기본적으로 활성화되어 있으며 무선 보호 정책의 일부이며, 정책 프로필에 따라 활성화 또는 비활성화할 수 있습니다. 이렇게 하면 여러 가지 다른 동작 문제를 탐지하고 네트워크에서 클라이언트를 제거한 다음 임시 제외 목록으로 설정할 수 있습니다. 클라이언트가 이 제외된 상태에 있는 동안에는 AP가 해당 AP와 통신하지 않으므로 추가 작업이 수행되지 않습니다.
제외 타이머가 경과하면(기본적으로 60초) 클라이언트가 다시 연결할 수 있습니다.
클라이언트 제외를 위한 몇 가지 트리거가 있습니다.
- ARP 플러드 생성
- 반복된 연결 실패
- 3개 이상의 webauth, PSK 또는 802.1x 인증 오류
- 반복 된 인증 시간 초과 (클라이언트에서 응답 없음)
- 다른 클라이언트에 이미 등록된 IP 주소를 다시 사용하려고 합니다.
클라이언트 제외는 높은 CPU를 초래할 수 있는 여러 가지 높은 활동 유형으로부터 컨트롤러, AP 및 AAA 인프라(Radius)를 보호합니다. 문제 해결 연습 또는 호환성 요구 사항에 필요한 경우가 아니면 제외 방법을 비활성화하는 것은 바람직하지 않습니다.
기본 설정은 거의 모든 경우에 대해 작동하며 제외 시간을 늘리거나 특정 트리거를 비활성화하려면 일부 예외적인 시나리오에만 필요합니다. 예를 들어, 일부 레거시 또는 특수 클라이언트(IOT/의료)에서는 쉽게 패치할 수 없는 클라이언트 측 결함으로 인해 연결 실패 트리거를 비활성화해야 합니다
UI에서 트리거를 사용자 지정할 수 있습니다. 구성/무선 보호/클라이언트 제외 정책:
ARP 제외 트리거는 글로벌 레벨에서 영구적으로 활성화되도록 설계되었지만 각 정책 프로필에서 사용자 정의할 수 있습니다. sh wireless profile policy all 명령을 실행하여 상태를 확인하고 이 특정 출력을 찾을 수 있습니다.
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
데이터 트래픽으로부터 컨트롤 플레인 보호
이는 컨트롤 플레인으로 전송되는 트래픽이 미리 정의된 임계값 집합을 초과하지 않도록 하기 위한 데이터 플레인의 고급 메커니즘입니다. 이 기능을 Punt Policers라고 하며 거의 모든 시나리오에서 이들을 건드릴 필요가 없으며, 그 경우에도 Cisco Support를 사용할 때만 사용해야 합니다.
이 보호의 장점은 네트워크에 대한 자세한 정보를 제공하고, 특정 활동 중 속도가 증가하거나 초당 예상치 못한 높은 패킷이 발생하는 경우 이를 확인할 수 있다는 것입니다.
이는 일반적으로 수정이 거의 필요하지 않은 고급 기능의 일부이므로 CLI를 통해서만 표시됩니다.
모든 펀트 정책의 보기를 수신하려면
9800-l#show platform software punt-policer
Per Punt-Cause Policer Configuration and Packet Counters
Punt Config Rate(pps) Conform Packets Dropped Packets Config Burst(pkts) Config Alert
Cause Description Normal High Normal High Normal High Normal High Normal High
-------------------------------------------------------------------------------------------------------------------------------------------------------------
2 IPv4 Options 874 655 0 0 0 0 874 655 Off Off
3 Layer2 control and legacy 8738 2185 33 0 0 0 8738 2185 Off Off
4 PPP Control 437 1000 0 0 0 0 437 1000 Off Off
5 CLNS IS-IS Control 8738 2185 0 0 0 0 8738 2185 Off Off
6 HDLC keepalives 437 1000 0 0 0 0 437 1000 Off Off
7 ARP request or response 437 1000 0 330176 0 0 437 1000 Off Off
8 Reverse ARP request or repso 437 1000 0 24 0 0 437 1000 Off Off
9 Frame-relay LMI Control 437 1000 0 0 0 0 437 1000 Off Off
10 Incomplete adjacency 437 1000 0 0 0 0 437 1000 Off Off
11 For-us data 40000 5000 442919246 203771 0 0 40000 5000 Off Off
12 Mcast Directly Connected Sou 437 1000 0 0 0 0 437 1000 Off Off
이는 소프트웨어 버전에 따라 160개 이상의 항목이 포함된 큰 목록이 될 수 있습니다. 테이블 출력에서 높은 삭제 횟수에 대해 0이 아닌 값이 있는 항목과 함께 삭제된 패킷 열을 확인합니다. 데이터 수집을 간소화하기 위해 show platform software punt-policer drop-only 명령을 실행하여 드롭이 있는 폴리서 항목만 필터링할 수 있습니다.
이 기능은 ARP 스톰 또는 802.11 프로브 플러드가 있는지 식별하는 데 유용할 수 있습니다(LFTS에 대한 큐 802.11 패킷 및 Linux Forwarding Transport Service의 LFTS 스탠드를 사용함).
무선 통화 허용 제어
최근 모든 유지 관리 릴리스에서 컨트롤러는 높은 CPU에 동적으로 반응하고 지속 불가능한 압력에 직면하여 AP CAPWAP 터널이 활성 상태로 유지되도록 하는 작업 모니터를 가지고 있습니다. 이 기능은 WNCD 로드를 확인하고 새 클라이언트 작업을 제한하여 기존 연결을 처리하고 CAPWAP 안정성을 보호하는 데 사용할 수 있는 충분한 리소스가 남아 있도록 합니다. 이 기능은 기본적으로 활성화되어 있으며 컨피그레이션 옵션은 없습니다.
80% 부하에서 L1, 85% 부하에서 L2, 89% 부하에서 L3의 세 가지 보호 수준이 정의됩니다. 서로 다른 수신 프로토콜을 트리거하는 각 프로토콜은 보호 메커니즘으로 폐기됩니다. 부하가 감소하면 보호가 자동으로 제거됩니다.
정상 네트워크에서는 L2 또는 L3 로드 이벤트를 볼 수 없으며, 이러한 이벤트가 자주 발생하는 경우 조사할 수 있습니다.
모니터링하려면 wireless stats cac:
9800-l# show wireless stats cac
WIRESLESS CAC STATISTICS
---------------------------------------------
L1 CPU Threshold: 80 L2 CPU Threshold: 85 L3 CPU Threshold: 89
Total Number of CAC throttle due to IP Learn: 0
Total Number of CAC throttle due to AAA: 0
Total Number of CAC throttle due to Mobility Discovery: 0
Total Number of CAC throttle due to IPC: 0
CPU Throttle Stats
L1-Assoc-Drop: 0 L2-Assoc-Drop: 0 L3-Assoc-Drop: 0
L1-Reassoc-Drop: 0 L2-Reassoc-Drop: 0 L3-Reassoc-Drop: 0
L1-Probe-Drop: 12231 L2-Probe-Drop: 11608 L3-Probe-Drop: 93240
L1-RFID-Drop: 0 L2-RFID-Drop: 0 L3-RFID-Drop: 0
L1-MDNS-Drop: 0 L2-MDNS-Drop: 0 L3-MDNS-Drop: 0
mDNS 보호
프로토콜로서의 mDNS는 제로 터치 접근 방식을 통해 디바이스 전반에서 서비스를 검색할 수 있지만, 동시에 매우 활성화될 수 있으며, 제대로 구성되지 않을 경우 부하를 크게 줄일 수 있습니다.
필터링 없이 mDNS를 사용하면 다음과 같은 여러 가지 요인으로 인해 WNCD CPU 사용률을 쉽게 높일 수 있습니다.
- 무제한 학습이 포함된 mDNS 정책에서는 컨트롤러가 모든 디바이스에서 제공하는 모든 서비스를 가져옵니다. 이렇게 하면 수백 개의 항목이 포함된 대규모 서비스 목록이 생성될 수 있습니다.
- 필터링하지 않고 정책을 설정하면 컨트롤러가 지정된 서비스를 제공하는 사용자를 묻는 각 클라이언트에 대규모 서비스 목록을 푸시합니다.
- 일부 mDNS 관련 서비스는 모든 무선 클라이언트에서 제공되므로 OS 버전별로 서비스 수와 활동이 증가합니다.
다음 명령을 실행하여 서비스당 mDNS 목록 크기를 확인할 수 있습니다.
9800-l# show mdns-sd service statistics
Service Name Service Count
-----------------------------------------------------------------------------
_ipp._tcp.local 84
_ipps._tcp.local 52
_raop._tcp.local 950
_airplay._tcp.local 988
_printer._tcp.local 13
_googlerpc._tcp.local 12
_googlecast._tcp.local 70
_googlezone._tcp.local 37
_home-sharing._tcp.local 7
_cups._sub._ipp._tcp.local 26
이는 주어진 쿼리가 얼마나 큰 값을 얻을 수 있는지에 대한 아이디어를 제공할 수 있다. 문제 자체를 나타내는 것이 아니라 추적되는 것을 감시하는 방법에 불과하다. 몇 가지 중요한 mDNS 컨피그레이션 권장 사항이 있습니다.
- mDNS 전송을 단일 프로토콜로 설정합니다.
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
기본적으로 IPv4 전송을 사용하며, 성능을 위해 IPv6 또는 IPv4 중 하나만 사용하는 것이 좋습니다.
- 바인딩되지 않은 쿼리/응답을 방지하려면 항상 mDNS 서비스 정책에서 위치 필터를 설정합니다. 일반적으로 사이트 태그를 사용하는 것이 좋지만 필요에 따라 다른 옵션도 사용할 수 있습니다.
도움이 더 필요합니다.
CPU 로드가 높고 이전 단계가 도움이 되지 않는 경우, 케이스를 통해 CX(Customer Experience)에 연락하고 이 데이터를 시작점으로 추가합니다.
- 기본 데이터에는 AP/컨트롤러 컨피그레이션, 네트워크, RF 작동 값이 포함됩니다.
show tech-support wireless
- 모든 컨트롤러 추적을 보관합니다. 이 명령은 다음 명령을 실행하여 수집할 수 있는 블랙박스 개념과 유사한 대용량 파일입니다.
request platform software trace archive last <days> to-file bootflash:<archive file>
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
3.0 |
03-Aug-2026
|
새로운 소개, 맞춤법, 문법, 가로줄을 별도의 섹션/가독성으로 삽입하고 CCW 오류를 수정했습니다. |
2.0 |
06-Jun-2025
|
Cisco의 대외화 지침을 준수하기 위해 대체 텍스트, 스타일 요구 사항, 기계 번역, 브랜딩 요구 사항 및 서식 업데이트 |
1.0 |
09-May-2024
|
최초 릴리스 |
피드백