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, ...)
• 클라이언트와 액세스 포인트의 하드웨어 기능(안테나 수, 공간 스트림 수, 액세스 포인트의 이더넷 연결 등)
• 구성(채널 폭, ...)

이러한 요인을 알면 실험실 조건에서 도달할 수 있는 최대 실제 처리량을 예측할 수 있습니다.

빠른 아이디어를 얻으려면 클라이언트가 액세스 포인트에 연결할 때 보고하는 데이터 속도를 확인합니다. 이 데이터 속도는 테스트에서 증명할 수 있는 실제 처리량이 아닙니다. Wi-Fi는 관리 오버헤드(프레임이 승인되어야 하고, 신호가 전송되어야 함)가 있으며, 수신 및 디코딩 향상을 위해 프레임 간의 침묵도 짧아지는 반이중 매체이기 때문입니다. 즉, 데이터를 전송할 때 문서화된 데이터 전송률로 전송되지만 데이터가 항상 전송되는 것은 아닙니다. 관리 및 제어 프레임은 수신을 보장하기 위해 훨씬 낮은 데이터 속도로 전송됩니다. 실제 처리량 테스트에서 사용되는 데이터 속도의 65~70% 달성을 고려할 수 있습니다. 예를 들어 클라이언트가 연결 중이고 866Mbps의 데이터 전송을 보고하면 실제 테스트에서는 600Mbps의 전송 속도를 보고해야 합니다.

사용 중인 컨피그레이션 매개변수와 관련 디바이스의 하드웨어 기능을 알고 있는 경우, 어떤 최대 데이터 속도(및 따라서 이 섹션에 설명된 백분율 계산을 사용하여 처리량)를 달성할 수 있어야 하는지도 파악할 수 있습니다.

보고된 데이터 전송률과 달성하고자 하는 데이터 전송률이 일치하지 않을 경우 컨피그레이션을 통해 문제 해결 프로세스를 시작하고 다양한 매개변수를 확인하여 공백이 있는 위치를 파악할 수 있습니다.

한 가지 예: 5Ghz 대역에서 20Mhz 채널 너비로 방송하는 액세스 포인트 모델 C9120과 일반적인 2개의 공간 스트림 Wi-Fi 6 클라이언트가 있는 경우, 완벽하게 깨끗한 RF(Radio Frequency) 환경에서 단일 클라이언트를 사용하여 단일 파일 전송에서 160~200Mbps를 달성할 수 있음을 계산할 수 있습니다.

처리량 테스트 및 검증에 대한 자세한 내용은 https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html을 참조하십시오.

기본 환경 설정

일반적인 상황에서 귀하의 장소에서 무엇을 기대할 수 있는지 아는 것이 중요합니다. 구축이 시작되기 전에 기술자가 빈 사이트를 방문하여 속도 테스트를 실행하고 예상 수치를 문서화하는 경우가 많습니다.

그러면 직원들이나 손님들이 들어와서 현장은 바쁘게 돌아가고, 실제 경험은 많이 달라진다.

구축이 실행되면 각 영역의 실제 경험을 측정하는 기술자를 파견하여 평균적으로 좋은 날에 네트워크가 어떻게 나타나는지 메모하는 것이 좋습니다.

여기에는 네트워크가 만족스러운 수준으로 작동할 때 무선 장치당 평균 클라이언트 수 및 속도 테스트로 달성한 평균 처리량이 포함됩니다.

경험의 편차를 찾습니다.

네트워크를 운영할 때 갑자기 중단되는 주요 경고문 또는 디바이스를 쉽게 모니터링할 수 있습니다. 이 문서에서는 여전히 작동하지만 수준 낮은 최종 사용자 경험을 제공하는 무선 네트워크를 찾아내는 방법이라는 어려운 부분을 중점적으로 다룹니다.

문제의 증거 찾기(수동 테스트)

네트워크를 직접 테스트했습니다. 정상적으로 작동하며 관리 시스템과 대시보드를 모니터링하고 있다는 것을 알고 있습니다. 아무것도 다운된 것으로 보고되지 않습니다. 한 걸음 물러나서 휴식을 취할 수 있습니다. 아니면 할 수 있겠어?

경험 부족에 대해 불평하는 최종 사용자의 메아리를 기다리면 너무 늦을 가능성이 있습니다. 엔드 유저가 불만을 제기하면 해당 문제는 오랫동안 진행되어 왔으며, 해당 문제를 들을 수 있을 만큼 목소리를 높인 소수의 사용자에게만 이야기를 들어줍니다.

수많은 사용자가 이미 불만을 느끼고 있습니다. 사용자나 헬프데스크에 아무 말도 하지 않았지만 네트워크에 나쁜 평판을 주었습니다.

그렇다면, 문제는 어떻게 하면 나쁜 경험이 발생하는 즉시 그것을 찾아낼 수 있는가 하는 것입니다.

1. Cisco Catalyst Center의 클라이언트 보증 대시보드

Cisco Catalyst Center 보증 대시보드에는 클라이언트 상태에 대한 전체 그래프가 있습니다.

누군가가 잘못된 키를 입력했기 때문에 연결할 수 없거나 장치가 커버리지의 맨 끝에 있기 때문에 연결할 수 없는 클라이언트가 항상 있습니다. 따라서 100%의 건강한 클라이언트에 도달하기를 바라지 않지만 귀하의 환경에 대한 건강한 클라이언트의 좋은 비율을 숙지하십시오.

90년대라는 것은 일반적으로 좋은 소식이다.

건강하지 않은 고객에게 어떤 일이 일어나고 있는지 한눈에 확인할 수 있습니다.

• AP(액세스 포인트)에서 멀리 떨어져 있습니까?
• 인증 문제입니까?

이 그래프에서 각 범주의 비율을 쉽게 알 수 있다.

같은 범위의 아이디어에서 해당 페이지의 맨 아래로 스크롤하여 상태가 좋지 않은 것으로 보고된 클라이언트 디바이스를 표시하도록 필터링할 수 있습니다. 그런 다음 패턴이 있으면 찾아낼 수 있습니다.

• 이러한 디바이스는 모두 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(연결)로 변경합니다. Clients" - AP당 클라이언트 수를 표시합니다.

맵 기법의 장점은 클라이언트 수가 높은 AP가 있는 위치를 확인하고 높은 카운트가 정당화될 수 있는지 평가할 수 있다는 것입니다(주어진 순간에 군중이 그 위치에 모이는 좋은 이유가 있을 수 있음).

또한 인접한 AP도 살펴볼 수 있습니다. AP가 일부 로드를 공유하면 상황이 양호합니다. 한 AP의 클라이언트 수가 비정상적으로 많은 반면 인접한 AP의 클라이언트 수가 전혀 없는 경우 이 상황은 더 의심스럽습니다.

인접한 AP에 문제가 있거나(클라이언트 수가 0인 경우) RF 설계로 인해 문제가 있는 AP가 인접한 AP에 비해 모든 클라이언트를 끌어들일 수 있습니다(예: 훨씬 높은 TX 전력 및/또는 서로 다른 안테나 때문).

이 맵은 각 AP에 연결된 클라이언트에 대한 훌륭한 개요를 제공합니다

클라이언트 수가 매우 많은 잠재적으로 문제가 있는 AP를 식별한 경우 해당 AP 이름을 검색하고 디바이스 360 페이지를 열 수 있습니다.

상태 그래프는 해당 AP의 상태가 방금 나빴거나 최근 하루 이상 지속적으로 나빴던 경우 개요를 제공합니다.

같은 페이지에 해당 AP와 관련된 문제 목록이 있습니다. 이 경우, 두 무선 장치 모두 높은 활용률을 보이고 있음이 분명합니다.

이벤트 뷰어는 해당 AP와 관련된 특정 이벤트가 있었는지 여부를 알려줄 수 있습니다.

예를 들어, RRM 알고리즘이 너무 자주 실행되도록 설정되어 채널 변경이 자주 발생하여 연결된 클라이언트에 영향을 주거나, 다양한 문제나 간섭으로 인해 라디오가 끊임없이 자체적으로 재설정되는 경우가 있습니다.

디바이스 360 페이지의 끝에서 보기를 "RF"로 설정하고 특정 라디오를 선택할 수 있으며 문제의 원인을 평가할 수 있는 흥미로운 정보가 있습니다.

많은 클라이언트를 보유하고 있다고 해서 반드시 문제가 되는 것은 아닙니다. 모두 활성 상태에 따라 달라집니다.

일부 클라이언트가 있더라도 AP가 바쁘고 열악한 환경을 제공할 수 있는 경우도 있습니다. 실제 지표는 채널 사용률입니다.

채널 사용률이 100%(심지어 70% 시작)에 가까워지면 클라이언트는 중간 액세스, 지연 및 충돌을 경험하기 위해 치열한 경쟁을 시작합니다.

이 그래프를 통해 전체 채널 사용률과 이 AP 부분의 책임을 비교할 수 있습니다.

예를 들어, 채널 사용률이 80%인 경우, 이는 채널을 통해 전송되는 "누군가"가 있는 시간의 80%를 의미합니다. AP가 40%의 Rx 사용률과 40%의 Tx 사용률을 표시하는 경우, 이 AP만이 채널을 계속 사용(즉, 다른 AP가 전송하지 않음)할 책임이 있으며 수신과 전송의 균형이 잘 맞는다는 것을 알 수 있습니다. AP가 결합된 Rx 및 Tx 사용률이 채널 사용률과 거리가 먼 경우, 이는 다른 AP(비인가 또는 관리형)가 동일한 채널을 사용하여 동일한 채널 간섭을 일으키고 있음을 의미합니다.

이 스크린샷은 채널 사용량이 매우 많은 AP(91%)를 보여 줍니다.

그래프에 따르면 이러한 사용률 중 7%만이 다른 AP 및 비 WiFi 소스 때문이며 AP가 시간의 82% 동안 전송 중이며 수신 시간은 2%에 불과합니다.

클라이언트 수 및 총 처리량은 하나 이상의 클라이언트가 대용량 파일을 다운로드하고 있음을 나타냅니다.

간섭 그래프를 사용하면 채널이 Wi-Fi 전송 또는 실제 간섭(비 Wi-Fi)에 의해 사용 중인지 여부를 확인할 수 있습니다.

결론적으로, 클라이언트 수가 가장 많고 채널 사용률이 가장 높은 AP를 관리해야 합니다. 그런 다음 이 로드가 정당한지 아닌지, 그리고 해당 영역의 최종 사용자에게 좋지 않은 환경을 유발하는지 평가해야 합니다.

3. AI 분석

AI 분석을 통해 더 지능적인 모니터링을 제공합니다. 모니터링은 더 이상 고정된 임계값을 기반으로 하지 않지만 기준 사용량을 조정합니다.

네트워크 히트맵에서는 클라이언트 수를 발전시켜 일주일 동안 클라이언트 수가 가장 많은 AP를 찾아낼 수 있습니다. 또한 클라이언트가 끊임없이 연결되지 않는 AP를 쉽게 찾을 수 있습니다. 반대 문제도 문제입니다.

이러한 AP에 물리적 문제(마운팅 문제, 안테나 문제 등)가 있거나, 라디오가 고정된 경우(그리고 해당 AP를 재부팅하여 해결한 경우) 소프트웨어 문제가 있을 수 있습니다.

Trends and Insights(추세 및 인사이트) 페이지는 높은 채널 사용률 또는 클라이언트 활동을 정기적으로 보여주는 AP 목록을 제공하므로 가장 바쁜 지역과 일치하는지 또는 비정상적인 부분이 있는지 쉽게 교차 확인할 수 있습니다.

인프라에 대한 적극적인 테스트

사용자가 특정 영역에서 좋지 않은 경험을 보고하면 적극적으로 테스트하여 피드백을 확인하고자 한다. 일반적인 테스트는 실제 클라이언트 트래픽과 많은 차이가 있음을 이해하는 것이 중요합니다.

사용자는 일반적으로 자신이 선호하는 애플리케이션을 사용하려고 하며, 애플리케이션이 작동하면 만족합니다. 대용량 파일은 거의 전송할 수 없습니다. 즐겨 사용하는 애플리케이션의 동작이 다를 수 있습니다.

• 온디맨드 비디오: 이 옵션은 모든 양의 대역폭을 소비할 수 있습니다(예를 들어 비디오가 720p 또는 4K인 경우에 따라 다름).
  • 몇 초 또는 몇 분 전에 비디오를 버퍼링하므로 지터에 매우 적합합니다. 패턴은 짧은 시간 동안 큰 파일 전송과 같은 모양을 하다가 다음 프리로드가 발생할 때까지 버퍼에서 비디오가 재생되는 동안 침묵합니다.
• 음성 통화: 이는 무시할 수 있는 양의 대역폭을 소비하지만 지연 및 지터에 매우 민감합니다.
  • 이는 잠재적으로 QoS(Quality of Service) 태깅을 사용할 수 있으므로 최선형 트래픽과 다른(우선순위가 지정된) 경험을 할 수 있습니다.
• 데이터: 소셜 미디어 애플리케이션은 버스트 단위로 데이터를 다운로드합니다.
  • 양은 콘텐츠 및 사용자가 스크롤하는 속도에 따라 달라집니다.

일반적인 처리량 테스트 애플리케이션은 프로토콜을 최대화하여 가능한 한 가장 빠른 전송 속도를 달성합니다. 즉, 미디어를 예약하고 가능한 한 많은 데이터 프레임을 연결하여 전송합니다. 이는 기본적으로 매우 과부하 상태인 실제 애플리케이션(파일 전송 제외)과 동일한 사용 유형을 나타내지 않습니다.

실제 애플리케이션을 테스트하면 사용자 행동을 모방하지만 실제 메트릭 및 수치를 비교할 수는 없습니다. 네트워크가 원활하거나 원활하지 않을 때만 주관적인 느낌을 받는다.

처리량 테스트의 경우, 많은 웹 사이트가 인기를 끌며 클라이언트와 인터넷 사이의 전체 대역폭을 테스트하는 최종 사용자 환경을 잘 보여 줍니다. 그러나 무선 네트워크를 인터넷 연결, 라우팅 및 방화벽 문제와 별도로 검증하려면 Iperf와 같은 전용 처리량 테스트 도구(https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047)를 사용하는 것이 좋습니다.

이 도구를 사용하면 네트워크에 있는 클라이언트와 서버 간의 특정 테스트를 수행할 수 있습니다. 이렇게 하면 서버를 네트워크의 특정 위치로 이동하고 더 긴 네트워크 섹션의 처리량을 테스트하여 각 섹션을 검증할 수 있습니다. 먼저 로컬 스위칭이나 패브릭 기반 무선의 경우 무선 클라이언트가 있는 AP와 동일한 스위치에, 중앙 스위칭의 경우 WLC(Wireless LAN Controller)와 동일한 스위치(가능한 경우 클라이언트 VLAN)에 Iperf 서버를 배치합니다.

앵커 WLC를 사용하는 경우, 트래픽이 종료되는 앵커 WLC와 동일한 스위치에 Iperf 서버를 배치해야 합니다. 경우에 따라 고정되지 않은 WLAN(무선 LAN)을 생성하여 잠재적으로 실망스러운 처리량 결과가 고정되지 않은 WLAN에 비해 고정으로 인해 발생하는지 확인하는 것이 유용할 수 있습니다.

여러 클라이언트를 동시에 사용하여 처리량 테스트를 수행하는 것은 정말 이해가 되지 않습니다. 처리량 테스트에서는 이 단일 클라이언트가 가용 채널 통신 시간 전체를 사용할 것으로 예상됩니다. 따라서 두 클라이언트가 동시에 처리량 테스트를 수행할 경우 각각 적어도 절반으로 분할된 결과를 볼 수 있습니다. 더 많은 클라이언트가 사용되는 경우, 충돌이 숫자로 발생하기 시작하며 그 결과는 더 이상 대표적이지 않습니다.

네트워크 테스트를 자동화하는 ^다양한 타사 툴이 있습니다. 한 영역에서 처리량을 테스트하는 동안 테스트 기간 동안 모든 통신 시간을 효과적으로 사용한다는 점에 유의하십시오. 그러면 네트워크를 너무 자주 테스트하는 것은 다른 클라이언트에 지장을 주기 때문에 좋지 않은 방법입니다.

처리량 문제 해결

처리량 문제를 식별하면 몇 가지 사항을 확인하여 문제를 격리할 수 있습니다.

• 테스트를 시작하기 전에 RF 환경이 이미 사용 중인 경우 격리합니다. Channel Utilization(채널 사용률)이 높을수록(테스트 외부) 처리량 테스트 결과가 낮아집니다. 채널 사용률 문제가 확인되면 동일한 채널의 동일한 영역에 다른 AP가 있는지 확인하고 RF 설계를 재고하십시오. 채널 폭을 줄이고, 비인가를 없애고, 더 집중적인 커버리지의 서로 다른 안테나를 사용하는 것이 모두 좋은 옵션입니다. AP를 더 추가하는 것이 항상 좋은 방법은 아닙니다.
• 처리량 테스트의 OTA(Over-The-Air) 캡처를 확인하고 802.11 레이어에서 많은 데이터 재시도가 있는지 확인합니다(모든 데이터 프레임의 백분율). 재시도 횟수가 많다는 것은 RF 환경이 잠재적으로 문제가 된다는 것을 의미합니다. 또한 어떤 데이터 속도가 사용되고 있는지, 잠재적으로 최적화되지 않은 프로토콜이 사용되고 있는지 또는 공간 스트림의 수가 사용되고 있는지 확인합니다. 대용량 데이터 전송은 무선 캡처에서 매우 특징입니다. 소스와 대상이 같고 서로 간의 델타 시간이 매우 짧으며 블록 ACK가 뒤따르는 수십 개의 데이터 프레임이 표시됩니다. 전송이 모든 데이터 프레임 후에 일반 ACK를 사용하거나 많은 request-to-send/clear-to-send를 사용하는 것이 특징이라면 낮은 처리량을 쉽게 설명할 수 있습니다.
• WLAN의 모든 보안 유형에서 처리량 문제가 발생하는지 확인합니다. 클라이언트와 AP 간의 특정 보안 비호환성으로 인해 처리량이 저하될 수 있습니다.