무선 LAN 컨트롤러 CPU 로드 문제 해결

소개

이 문서에서는 Catalyst 9800 Wireless LAN Controller의 CPU 사용량을 모니터링하는 방법과 몇 가지 구성 권장 사항에 대해 설명합니다.

CPU 사용량 이해

CPU 로드 트러블슈팅을 자세히 살펴보기 전에 Catalyst 9800 Wireless LAN Controller에서 CPU를 사용하는 방법의 기본 사항과 소프트웨어 아키텍처에 대한 몇 가지 세부 사항을 이해해야 합니다.

일반적으로 Catalyst 9800 Best Practices 문서는 애플리케이션 수준 문제를 방지할 수 있는 올바른 컨피그레이션 설정 집합을 정의합니다. 이를테면 mDNS에 대한 위치 필터링을 사용하거나 클라이언트 제외가 항상 활성화되도록 보장합니다. 여기에 표시된 주제와 함께 이러한 권장 사항을 적용하는 것이 좋습니다.

플랫폼 기본 사항

Catalyst 9800 컨트롤러는 유연한 플랫폼으로 설계되어 다양한 네트워크 부하를 대상으로 하며 수평적 확장에 초점을 맞춥니다. 내부 개발 이름은 "elastic"에 e를 붙인 "eWLC"로, 동일한 소프트웨어 아키텍처를 소형 단일 CPU 임베디드 시스템에서 여러 CPU/코어 대규모 어플라이언스로 실행할 수 있음을 의미합니다.

각 WLC에는 두 개의 서로 다른 "측면"이 있습니다.

• 컨트롤 플레인: CLI, UI, Netconf 및 클라이언트와 AP에 대한 모든 온보딩 프로세스와 같은 모든 "관리" 상호 작용을 처리합니다.
• 데이터 플레인: 기타 기능 중에서도 CAPWAP의 실제 패킷 전달 및 역캡슐화, AVC 정책 시행을 담당합니다.

컨트롤 플레인

• 대부분의 Cisco IOS-XE 프로세스는 BinOS(Linux Kernel)에서 실행되며 자체 특수 스케줄러 및 모니터링 명령이 있습니다.
• 로컬 메모리 내 데이터베이스가 있는 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는 클라이언트 활동에서 추가된 특정 CPU 로드와 AP 자체를 나타내는 개념입니다. 이 밸런싱을 수행하는 몇 가지 메커니즘이 있습니다.

• AP가 "default-tag"를 사용하는 경우 모든 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 이상에서 사이트 로드 명령을 도입하여 관리자가 각 사이트 태그의 예상 로드를 미리 정의할 수 있도록 했습니다. 이 기능은 로드가 WNCD에 균일하게 분산되도록 각기 다른 AP 카운트에 매핑된 캠퍼스 시나리오 또는 여러 지사를 처리할 때 특히 유용합니다.

예를 들어, AP 수가 다른 본사 1개와 지사 5개를 처리하는 9800-40의 경우 다음과 같이 구성할 수 있습니다.

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 CAPWAP 조인 프로세스 중에 WAN에 대한 AP 할당이 적용되므로 모든 AP의 연결이 끊기고 다시 조인하는 네트워크 전반의 CAPWAP 재설정 이벤트가 없는 한 밸런싱 방법과 상관없이 작동 중에 AP가 변경되지 않을 것으로 예상됩니다.

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 wireless가져온 파일을 로드하는 것입니다. 이 툴에는 연결된 각 AP에서 가져온 WNCD 클라이언트 수가 요약되어 있습니다.

사용량이 적고 클라이언트 수가 적은 경우 적절하게 균형 조정된 컨트롤러의 예:

다른 예로, 로드가 더 많은 컨트롤러의 경우 정상적인 CPU 사용률을 보여줍니다.

권장되는 AP 로드 밸런싱 메커니즘은 무엇입니까?

간단히 말해, 다음과 같은 여러 옵션을 요약할 수 있습니다.

• 소규모 네트워크, 빠른 로밍이 필요 없으며 컨트롤러 부하의 40% 미만: 기본 태그.
• 빠른 로밍이 필요한 경우(OKC, FT, CCKM) 또는 대규모 클라이언트 수:
  • 단일 건물: CPU만큼 많은 사이트 태그 생성(플랫폼에 따라 다름)
  • 17.12 이전 또는 500개 미만의 AP 수: 여러 건물, 지사 또는 대규모 캠퍼스: 물리적 RF 위치당 사이트 태그를 생성하고 사이트당 로드 명령을 구성합니다.
  • 17.12 이상(500개 이상의 AP 사용): RF 로드 밸런싱을 사용합니다.


이 500 AP 임계값은 로드 밸런싱 메커니즘을 적용하는 것이 효과적인 시점을 나타내기 위한 것으로, 기본적으로 100개 단위로 구성된 블록의 AP를 그룹화하기 때문입니다.

AP WNCD 배포 시각화

고급 AP 밸런싱을 수행하려는 시나리오가 있으며, AP가 CPU 전체에 분산되는 방식을 세부적으로 제어하는 것이 좋습니다. 예를 들어, 주요 로드 메트릭이 클라이언트 카운트인 경우 시스템에 있는 AP 수만 집중적으로 보는 것이 아니라 클라이언트 카운트인 매우 고밀도 시나리오가 있습니다.


이러한 상황을 보여주는 좋은 예는 대규모 이벤트입니다. 빌딩에서는 수백 개가 넘는 AP를 사용하는 수천 개의 클라이언트를 호스팅할 수 있습니다. 따라서 되도록 많은 CPU에 로드를 분산하면서 동시에 로밍을 최적화해야 합니다. 따라서 필요한 경우가 아니면 WNCD를 로밍하지 않습니다. 서로 다른 WNCD/사이트 태그의 여러 AP가 동일한 물리적 위치에서 뒤섞이는 "소금 및 후추" 상황을 방지하고자 합니다.

WCAE 툴을 사용하여 세부적으로 조정하고 분포를 시각화할 수 있도록 하며 AP RF View 기능을 활용할 수 있습니다.

이렇게 하면 AP/WNCD 배포를 볼 수 있습니다. WNCD로 View Type 설정하면 됩니다. 여기서 각 색상은 WNCD/CPU를 나타냅니다. 또한 RSSI 필터를 -85로 설정하여 컨트롤러의 RRM 알고리즘에 의해 필터링되는 낮은 신호 연결을 방지할 수 있습니다.

앞의 예에서는 Cisco EMEA 24에 해당하는 경우, 대부분의 인접 AP가 동일한 WNCD에서 매우 제한된 교차 중복으로 잘 클러스터링되어 있음을 확인할 수 있습니다.

동일한 WNCD에 할당된 사이트 태그는 동일한 색상을 가져옵니다.

컨트롤 플레인 CPU 사용량 모니터링

Cisco IOS-XE 아키텍처의 개념을 기억하고 CPU 사용량에 대한 두 가지 주요 "보기"가 있다는 점을 기억해야 합니다. 하나는 Cisco IOS 지원 이력이 있으며, 다른 하나는 모든 프로세스와 코어에 대한 CPU를 전체적으로 보여주는 기능입니다.

일반적으로 이 명령을 사용하여 Cisco IOSshow processes cpu platform sorted-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%보다 높은 높은 높은 사용률을 항상 볼 것으로 예상됩니다. 이는 구현의 일환으로서 이것이 문제가 되는 것은 아니다.
• 최대 사용량과 지속 부하를 구분하여 주어진 시나리오에서 예상되는 것을 격리하는 것이 중요합니다. 예를 들어 수백 개의 CLI 명령이 실행된 상태에서 매우 큰 텍스트 출력이 수집될 때 IOSd, smand, pubd 프로세스에서 최대 부하를 생성할 수 있는 것처럼show tech wireless 매우 큰 CLI 출력을 수집하는 경우, 이는 문제가 되지 않으며 출력이 완료된 후 로드가 다운됩니다.



   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

• 한 프로세스에서 90% 이상, 15분 이상 지속되는 높은 CPU 사용량을 조사해야 합니다.
  
  
• 명령을 사용하여 IOSd CPU 사용률을 모니터링할 수 있습니다show processes cpu sorted. 이는 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 있습니다.

각 프로세스는 무엇입니까?

정확한 프로세스 목록은 컨트롤러 모델 및 Cisco IOS-XE 버전에 따라 달라집니다. 주요 프로세스의 일부이며, 모든 가능한 항목을 다루지는 않습니다.

프로세스 이름	어떤 기능을 합니까?	평가
wncd_x	대부분의 무선 작업을 처리합니다. 9800 모델에 따라 1~8개의 인스턴스를 가질 수 있습니다	바쁜 시간 동안 활용도가 높은 정점을 확인할 수 있었습니다. 사용률이 몇 분 동안 95% 이상 고착된 경우 보고합니다.
linux_iosd-imag	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를 보고해야 합니다.
스만드	셸 관리자. CLI 구문 분석 및 여러 프로세스 간 상호 작용을 처리합니다.	큰 CLI 출력을 처리하는 동안 높은 CPU가 필요합니다. 로드가 없는 경우 지속적으로 높은 CPU를 보고해야 합니다.
emd	셸 관리자. CLI 구문 분석 및 여러 프로세스 간 상호 작용을 처리합니다.	큰 CLI 출력을 처리하는 동안 높은 CPU가 필요합니다. 로드가 없는 경우 지속적으로 높은 CPU를 보고해야 합니다.
술집	텔레메트리 처리의 일부	대규모 텔레메트리 서브스크립션에 높은 CPU가 필요합니다. 로드가 없는 경우 지속적으로 높은 CPU를 보고해야 합니다.

높은 CPU 보호 메커니즘

Catalyst 9800 Wireless LAN Controller는 네트워크 또는 무선 클라이언트 활동에 대한 광범위한 보호 메커니즘을 제공하여 우발적 또는 의도적인 시나리오로 인한 높은 CPU를 방지합니다. 문제가 되는 장치를 포함할 수 있도록 설계된 몇 가지 주요 기능이 있습니다.

클라이언트 제외

이는 기본적으로 활성화되어 있으며 무선 보호 정책의 일부이며, 정책 프로필에 따라 활성화 또는 비활성화할 수 있습니다. 이렇게 하면 여러 가지 다른 동작 문제를 탐지하고 네트워크에서 클라이언트를 제거한 다음 "임시 제외 목록"으로 설정할 수 있습니다. 클라이언트가 이 제외된 상태에 있는 동안에는 AP가 해당 AP와 통신하지 않으므로 추가 작업이 수행되지 않습니다.

제외 타이머가 경과하면(기본적으로 60초) 클라이언트가 다시 연결할 수 있습니다.

클라이언트 제외를 위한 몇 가지 트리거가 있습니다.

• 반복된 연결 실패
• 3개 이상의 webauth, PSK 또는 802.1x 인증 오류
• 반복 된 인증 시간 초과 (클라이언트에서 응답 없음)
• 다른 클라이언트에 이미 등록된 IP 주소를 다시 사용하려고 합니다.
• ARP 플러드 생성

클라이언트 제외는 높은 CPU를 초래할 수 있는 여러 가지 높은 활동 유형으로부터 컨트롤러, AP 및 AAA 인프라(Radius)를 보호합니다. 일반적으로 문제 해결 연습 또는 호환성 요구 사항에 필요한 경우가 아니면 제외 방법을 비활성화하는 것은 바람직하지 않습니다.

기본 설정은 거의 모든 경우에 적용되며 일부 예외적인 경우에만 제외 시간을 늘리거나 특정 트리거를 비활성화하는 데 필요합니다. 예를 들어, 일부 레거시 또는 특수 클라이언트(IOT/의료)에서는 쉽게 패치할 수 없는 클라이언트 측 결함으로 인해 연결 실패 트리거를 비활성화해야 할 수 있습니다

UI에서 트리거를 사용자 지정할 수 있습니다. Configuration/Wireless Protection/Client Exclusion Policies(구성/무선 보호/클라이언트 제외 정책):

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 프로브 플러드가 있는지 확인하는 데 유용할 수 있습니다(큐 "802.11 Packets to LFTS"를 사용합니다). LFTS는 Linux Forwarding Transport Service의 약자입니다.

무선 통화 허용 제어

최근 모든 유지 관리 릴리스에서 컨트롤러는 높은 CPU에 동적으로 대응하고 지속 불가능한 압력에 직면하여 AP CAPWAP 터널이 활성 상태를 유지하도록 활동 모니터를 제공합니다.

이 기능은 기존 연결을 처리하고 CAPWAP 안정성을 보호할 수 있는 충분한 리소스가 남아 있는지 확인하기 위해 WNCD 로드를 확인하고 새 클라이언트 활동을 제한하기 시작합니다.

이는 기본적으로 활성화되어 있으며 컨피그레이션 옵션이 없습니다.

보호 메커니즘으로 각기 다른 수신 프로토콜 삭제를 트리거하는 세 가지 보호 수준이 정의됩니다(80% 로드의 경우 L1, 85% 로드의 경우 L2, 89%). 부하가 감소하면 바로 보호가 자동으로 제거됩니다.

정상적인 네트워크에서는 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는 "제로 터치(zero-touch)" 접근 방식을 통해 디바이스 전반에서 서비스를 검색할 수 있지만 동시에 매우 활성화되고, 올바르게 구성되지 않은 경우 부하를 크게 유도할 수 있습니다.

mDNS는 필터링 없이 다음과 같은 여러 가지 요인으로 인해 WNCD CPU 사용률을 쉽게 높일 수 있습니다.

1. 무제한 학습이 포함된 mDNS 정책에서는 컨트롤러가 모든 디바이스에서 제공하는 모든 서비스를 가져옵니다. 이렇게 하면 수백 개의 항목이 포함된 매우 큰 서비스 목록이 생성될 수 있습니다.
2. 필터링 없이 설정된 정책: 컨트롤러가 지정된 서비스를 제공하는 사용자를 묻는 각 클라이언트에 대규모 서비스 목록을 푸시하게 됩니다.
3. 일부 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에 연락하고 이 데이터를 시작점으로 추가하십시오.

• 기본 데이터에는 AP/컨트롤러 컨피그레이션, 네트워크 및 RF 운영 값이 포함됩니다.

show tech-support wireless 

• 모든 컨트롤러 추적을 보관합니다. 이는 "블랙박스" 개념과 유사한 대용량 파일이며, 다음 명령을 사용하여 수집할 수 있습니다.

request platform software trace archive last <days> to-file bootflash:<archive file>