Wi-Fi 처리량 테스트 및 모니터링 가이드 검증
소개
이 문서에서는 대규모 Wi-Fi 네트워크에서 처리량 문제를 모니터링하고 해결하는 방법을 설명합니다.
컨텍스트
Wi-Fi 네트워크에서는 최종 사용자가 인식하는 문제 유형이 많지 않습니다.
보고된 문제의 범위는 다음과 같습니다.
- 연결할 수 없는 클라이언트;
- 갑자기 연결이 끊기거나
- 사용자 디바이스 상의 애플리케이션의 인지된 속도는 만족스럽지 않다.
이러한 단순한 증상 이면에는 다양한 유형의 문제가 있을 수 있습니다. 대부분 DNS 문제, 인터넷 연결 문제 등 실제 Wi-Fi 네트워크와 관련이 없습니다. Cisco Catalyst Center와 같은 관리 서버는 관리자에게 특정 문제를 해결할 수 있도록 도와주며, 이 문서에서는 Catalyst Center를 통해 쉽게 확인하고 해결할 수 있는 여러 유형의 일상적인 문제에 대해 자세히 다루지 않습니다. 대신, 이 문서에서는 최종 사용자의 모호한 피드백(예: 네트워크 속도가 느림), 이를 테스트하는 방법, 네트워크 전반에서 실제 처리량을 검증하는 방법 등에 초점을 맞추고 있습니다. 속도와 관련된 문제를 실행 가능한 항목으로 분류하여 전반적인 최종 사용자 경험을 개선하는 방법 이 문서의 세부 사항은 다음과 같습니다.
최대 예상 처리량 정의
각 네트워크의 첫 번째 질문은, 잠재적으로 현실적으로 도달할 수 있는 최대 속도는 얼마인가?입니다. Wi-Fi는 공유 매체이기 때문에, 경험하는 속도는 동일한 순간 및 동일한 채널에서 Wi-Fi를 사용하는 클라이언트 및 디바이스의 수에 직접 의존합니다. 달성할 수 있는 최대 속도는 단일 클라이언트 디바이스와 단일 액세스 포인트를 아무도 동일한 Wi-Fi 채널을 사용하지 않는 격리된 장소에 두는 것을 의미합니다. 이 조건에서, 요인은 최대 속도 종속을 결정 합니다.
- 사용된 Wi-Fi 프로토콜(Wi-Fi 5, Wi-Fi 6 등)
- 클라이언트와 액세스 포인트의 하드웨어 기능(안테나 수, 공간 스트림 수, 액세스 포인트의 이더넷 연결 등)
- 컨피그레이션(채널 폭 및 기타 컨피그레이션 세부사항)
이러한 요인을 알면 Lab 조건에서 도달할 수 있는 최대 실시간 처리량을 예측할 수 있습니다. 클라이언트가 액세스 포인트에 연결할 때 보고하는 데이터 속도를 확인할 수 있습니다. 이 데이터 속도는 테스트에서 증명할 수 있는 실제 처리량이 아닙니다. 이는 Wi-Fi가 관리 오버헤드가 있는 반이중 매체이기 때문입니다(프레임이 승인되어야 하고 신호가 전송되어야 하는 등). 또한 보다 나은 수신과 디코딩을 위해 프레임 사이에 짧은 침묵이 있습니다. 즉, 데이터가 전송될 때 문서화된 데이터 속도로 전송되지만 데이터가 항상 전송되는 것은 아닙니다.
관리 및 제어 프레임은 수신을 보장하기 위해 훨씬 낮은 데이터 속도로 전송됩니다. 실제 처리량 테스트에서 사용되는 데이터 속도의 약 65~70%를 달성할 수 있습니다. 예를 들어, 클라이언트가 연결 중이고 866Mbps의 데이터 전송을 보고하는 경우 실제 테스트는 600Mbps의 전송 속도를 보고해야 합니다. 사용 중인 구성 매개 변수와 관련 장치의 하드웨어 기능을 알고 있는 경우, 어떤 최대 데이터 전송률(및 이 섹션에 설명된 백분율 계산을 사용하여 처리량)을 달성할 수 있는지 결정할 수 있습니다.
보고된 데이터 전송률과 달성하고자 하는 데이터 전송률이 일치하지 않을 경우 컨피그레이션을 통해 문제 해결 프로세스를 시작하고 다양한 매개변수를 확인하여 공백이 있는 위치를 파악할 수 있습니다. 예를 들어 5Ghz 대역에서 20Mhz 채널 폭으로 방송하는 액세스 포인트 모델 C9120과 일반적인 2개의 공간 스트림 Wi-Fi 6 클라이언트가 있는 경우 완벽하게 깨끗한 RF(무선 주파수) 환경에서 이를 계산할 수 있습니다. 단일 클라이언트를 사용하면 단일 파일 전송에서 160-200Mbps를 달성할 수 있습니다.
처리량 테스트 및 검증 설명서 가이드 Wi-Fi 6/6E 및 Wi-Fi 7 무선 처리량 검증 및 테스트를 참조하십시오.
기본 환경 설정
일반적인 상황에서 귀하의 장소에서 무엇을 기대할 수 있는지 아는 것이 중요합니다. 구축이 롤아웃되기 전에 기술자가 빈 사이트를 방문하여 속도 테스트를 실행하여 예상 수치를 기록하는 경우가 많습니다. 일단 직원/고객이 들어오면 현장은 바쁘게 돌아가고 실제 경험은 많이 달라진다. 구축이 실행되면 기술자를 파견하여 각 영역의 실제 경험을 측정함으로써 평균적으로 하루 동안 네트워크가 어떻게 수행되고 있는지 알아보는 것이 좋습니다. 여기에는 네트워크가 만족스러운 수준으로 작동할 때 무선 장치당 평균 클라이언트 수 및 속도 테스트로 달성한 평균 처리량이 포함됩니다.
경험의 편차 찾기
네트워크를 관리할 때 갑자기 오프라인으로 전환되는 주요 경고문 또는 디바이스를 쉽게 모니터링할 수 있습니다. 이 문서에서는 작동하고 있는 무선 네트워크를 찾아내는 방법이라는 어려운 부분에 초점을 맞추고 있지만, 그에 따라 수준 낮은 최종 사용자 경험을 제공합니다.
문제의 증거 찾기(수동 테스트)
네트워크를 직접 테스트하고 운영 방식을 파악하고 관리 시스템과 대시보드를 모니터링합니다. 오프라인 상태로 보고된 항목이 없습니다. 한 걸음 뒤로 물러서서 휴식을 취할 수 있습니다. 아니면 할 수 있겠어?
최종 사용자의 성능 저하 보고서를 기다리는 것은 이미 너무 늦었다는 것을 의미합니다. 사용자가 피드백을 제공할 때쯤이면, 그 문제는 지속되었고, 당신은 대부분의 성악가들로부터 들을 뿐이다. 다른 많은 사용자들이 헬프 데스크에 문의하지 않고 불만을 경험하여 네트워크 평판에 악영향을 미쳤을 가능성이 있습니다. 성능 문제가 발생할 경우 이를 어떻게 파악합니까?
1. Cisco Catalyst Center의 클라이언트 보증 대시보드
Cisco Catalyst Center Assurance 대시보드에는 클라이언트 상태에 대한 전체 그래프가 표시됩니다. 잘못된 자격 증명 또는 서비스 범위 에지에서 신호 강도가 약해지는 등의 요인으로 인해 일부 연결 장애가 발생할 수 있습니다. 100% 건강을 위해 노력하는 대신 환경에 대한 현실적인 기준을 정하십시오. 90년대의 상태 점수는 일반적으로 최적의 성능을 나타냅니다.
어떤 클라이언트가 비정상 상태인지를 한눈에 파악할 수 있습니다.
- AP(액세스 포인트)에서 멀리 떨어져 있습니까?
- 인증 문제입니까?
이 그래프에는 각 범주의 비율이 표시됩니다.
- 페이지의 끝으로 스크롤합니다.
- 상태가 좋지 않은 클라이언트 디바이스를 표시하도록 목록을 필터링합니다.
- 데이터를 분석하여 반복 패턴을 식별합니다.
이 예에서는 다음을 수행합니다.
- 2.4GHz 대역에 연결되는 디바이스는 환경이 더 나빠질 수 있습니다.
- 디바이스는 2.4Ghz 대역에서 신호 강도가 낮다고 보고했습니다.
- 디바이스는 동일한 물리적 위치를 공유합니다.
2 . Cisco Catalyst Center의 네트워크 보증 대시보드 및 디바이스 360
잠재적인 문제를 파악할 수 있는 좋은 방법은 Cisco Catalyst Center의 Network Assurance 페이지를 확인하는 것입니다. 클라이언트 수를 기준으로 상위 액세스 포인트를 보여주는 위젯이 있습니다.
네트워크의 최상위 액세스 포인트에 40개의 클라이언트가 연결되어 있으면 괜찮습니다. 이는 다른 모든 AP(액세스 포인트)의 클라이언트 수가 더 적다는 것을 의미합니다. 반면, 상위 AP의 클라이언트 수가 비정상적으로 많은 경우, 클라이언트 환경이 특히 좋지 않다고 가정할 수 있습니다(이러한 클라이언트가 비활성 상태이고 네트워크에 있지 않은 경우). "AP별" 조사로 이동하고 이 위젯에서 보고된 상위 AP를 확대하면 현재 상태를 파악할 수 있습니다.
클라이언트 수의 또 다른 보기는 Catalyst Center의 Network Hierarchy(네트워크 계층) 페이지에 있는 맵에 있습니다. 플로어 뷰 페이지에서 뷰 옵션(View Options) > 액세스 포인트(Access Points)를 클릭하고 디스플레이를 연결(Assoc)으로 변경합니다. AP당 클라이언트 수를 표시할 클라이언트
맵을 활용하려면 다음 단계를 검토하십시오.
- 맵을 사용하면 클라이언트 수가 많은 액세스 포인트(AP)를 식별하고 밀도가 현재 활동에 의해 정당화되는지 평가할 수 있습니다.
- 인접 AP를 검사하여 클라이언트 로드를 공유하는지 확인합니다.
- 한 AP가 비정상적으로 높은 클라이언트 수를 보고하는 반면 네이버가 0을 보고하는 경우, 이는 잠재적인 문제를 나타내므로 이를 조사합니다.
- 과도한 TX(Transmit Power) 전력 또는 안테나 컨피그레이션 차이로 인해 한 AP가 불균형한 수의 클라이언트를 유치하게 되는 등의 RF 설계 결함을 확인합니다.
이 맵은 각 AP에 연결된 클라이언트에 대한 훌륭한 개요를 제공합니다
클라이언트 수가 많은 AP를 식별한 후 AP 이름을 검색하여 Device 360 페이지를 엽니다. 상태 그래프는 AP 상태가 현재 좋지 않은지 또는 지난 24시간 동안 유지되었는지를 보여줍니다.
같은 페이지에 해당 AP와 관련된 문제 목록이 있습니다. 이 경우 두 무선 장치 모두 사용률이 높습니다.
이벤트 뷰어는 해당 AP와 관련된 특정 이벤트를 식별합니다. 예를 들어, RRM 알고리즘이 너무 자주 실행되어 연결된 클라이언트에 영향을 주는 채널 변경이 반복될 수 있거나, 간섭 또는 기타 문제로 인해 라디오가 재설정될 수 있습니다.
장치 360 페이지의 끝에서 보기를 RF로 설정하고 특정 라디오를 선택하여 문제의 원인을 평가하기 위한 데이터에 액세스합니다. 클라이언트 수가 많으면 클라이언트 활동에 따라 성능이 달라지므로 반드시 문제가 있는 것은 아닙니다. 클라이언트가 거의 없는 경우에도 AP가 계속 사용 중이면 문제가 발생합니다. 채널 사용률은 주요 지표 역할을 합니다. 채널 사용률이 100% 또는 심지어 70%에 도달할 경우 클라이언트가 중간 액세스 경합을 벌여 지연 및 충돌이 발생합니다. 그래프는 총 채널 사용률과 해당 부하에 대한 AP 기여도를 비교할 수 있게 합니다.
예를 들어, 80% 채널 사용률은 누군가가 80% 시간을 채널을 통해 전송하는 것을 의미합니다. AP에 40% Rx 및 40% Tx 사용률이 표시되는 경우, 이 AP만 전송 및 수신 간 로드 밸런싱을 통해 채널 사용 빈도를 유지합니다. 결합된 Rx 및 Tx 사용률이 총 채널 사용률과 크게 다를 경우, 다른 AP(비인가 또는 관리됨)는 동일한 채널을 사용하여 간섭이 발생합니다.
이 그림에서는 채널 사용률이 91%인 AP를 보여 줍니다.
그래프는 사용률의 7%가 다른 AP 및 비 Wi-Fi 소스에서 발생하며, AP는 시간의 82%를 전송하고 시간의 2%를 수신합니다. 클라이언트 수 및 총 처리량이 많으면 하나 이상의 클라이언트가 대용량 파일을 다운로드할 가능성이 높습니다. 간섭 그래프는 Wi-Fi 전송 또는 비 Wi-Fi 간섭이 채널을 계속 사용하는지 여부를 확인하는 데 도움이 됩니다.
일반적으로 클라이언트 수 및 채널 사용률이 가장 높은 AP를 모니터링합니다. 이 부하가 정당한지, 그리고 해당 영역의 최종 사용자 환경에 부정적인 영향을 미치는지 평가합니다.
3 . AI 분석
AI 분석은 고정된 임계값에 의존하지 않고 기본 사용량에 적응하는 지능형 모니터링을 제공합니다. 네트워크 히트맵에는 클라이언트 수 추세가 표시되며, 한 주 동안 밀도가 가장 높은 AP가 강조 표시됩니다. 또한 클라이언트 연결이 0인 AP도 식별하는데, 이는 다른 유형의 문제를 나타냅니다. 이러한 인스턴스는 무선 리부팅으로 상태가 해결되는 소프트웨어 장애, 즉 마운팅 또는 안테나 문제와 같은 물리적 문제를 시사합니다.
Trends and Insights 페이지에는 채널 사용률 또는 클라이언트 활동이 높은 AP가 나열됩니다. 이 목록을 사용하여 가장 바쁜 영역을 교차 확인하거나 이상 징후를 식별합니다.
인프라의 활성 테스트
활성 테스트를 통해 사용자 보고서 중 사용자 환경이 열악한 것을 확인할 수 있습니다. 테스트는 실제 트래픽과 다릅니다. 사용자는 대용량 파일 전송보다 애플리케이션 성능의 우선 순위를 지정합니다. 애플리케이션 동작은 다음과 같습니다.
- 비디오: 버퍼링을 통해 가변 대역폭을 소비하고 지터를 허용합니다(예: 720p 또는 4K의 비디오 분산). 트래픽은 주기적인 버스트로 표시됩니다.
- 음성: 최소한의 대역폭을 사용하지만 낮은 레이턴시 및 지터가 필요합니다. 종종 QoS(Quality of Service) 태깅을 사용하여 우선 순위를 지정합니다.
- 데이터: 콘텐츠 및 사용자 상호 작용에 따라 데이터를 버스트로 다운로드합니다.
처리량 테스트는 프로토콜의 최대 전송 속도를 최대화하며, 이는 실제 애플리케이션의 과부하 특성과 다릅니다. 실제 애플리케이션을 테스트하는 것은 사용자 행동을 모방하지만 객관적인 지표가 부족하여 네트워크 성능에 대한 주관적인 평가만 제공합니다.
인기 웹 사이트는 엔드 투 엔드 대역폭을 테스트합니다. 인터넷, 라우팅 및 방화벽 문제로부터 무선 성능을 격리하려면 Iperf와 같은 전용 처리량 테스트 툴을 사용합니다.
이 도구는 클라이언트와 서버 간의 처리량을 테스트합니다. 서버를 이동하면 여러 네트워크 섹션을 확인할 수 있습니다. 다음 배치 지침을 따르십시오.
- 로컬 스위칭 또는 패브릭 기반 무선의 경우 Iperf 서버를 AP와 동일한 스위치에 배치합니다.
- 중앙 스위칭의 경우 서버를 WLC(Wireless LAN Controller)와 동일한 스위치에 이상적으로 클라이언트 VLAN에 배치합니다.
- 고정된 트래픽의 경우 트래픽이 종료되는 앵커 WLC와 동일한 스위치에 서버를 배치합니다.
고정이 아닌 WLAN을 테스트하여 고정 자체가 처리량에 영향을 미치는지 확인합니다. 테스트에는 하나의 클라이언트만 사용하십시오. 단일 클라이언트가 전체 가용 통신 시간을 소비할 수 있습니다. 여러 클라이언트를 사용하면 결과가 분할되고 충돌이 증가하여 데이터가 부정확해집니다. 타사 툴이 이 이 프로세스를 자동화할 수 있지만, 테스트 빈도를 제한하여 다른 클라이언트의 중단을 방지합니다.
처리량 문제 해결
처리량 문제를 식별하고 격리하려면 다음 단계를 수행합니다.
- 테스트를 시작하기 전에 RF 환경이 사용 중인지 확인합니다. 채널 활용도가 높으면 처리량 결과가 감소합니다. 사용률이 높은 경우, 공동 채널 간섭을 확인하고 RF 설계를 재고하십시오. 채널 폭을 줄이거나, 비인가 디바이스를 제거하거나, 지향성 안테나를 사용하는 것을 고려하십시오. AP를 더 추가하는 것이 항상 해결책은 아닙니다.
- OTA(over-the-air) 캡처를 수행하여 802.11 재시도를 분석합니다. 재시도 백분율이 높으면 RF 문제가 있음을 나타냅니다. 데이터 속도, 프로토콜 및 공간 스트림을 확인합니다. 효율적인 전송은 빠른 데이터 프레임 다음에 블록 ACK를 표시합니다. 반대로, 모든 프레임 또는 과도한 RTS(Request-to-Send)/CTS(Clear-to-Send) 프레임 이후의 일반 ACK는 낮은 처리량을 나타냅니다.
- WLAN에서 여러 보안 유형 테스트 클라이언트와 AP 보안 설정 간의 비호환성으로 인해 처리량이 저하될 수 있습니다.
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
2.0 |
08-Jul-2026
|
맞춤법, 문법, 문장 구조, 간격, 별도의 섹션에 삽입된 행, 대체 텍스트 및 CCW 알림 업데이트 |
1.0 |
04-Mar-2024
|
최초 릴리스 |
피드백