Catalyst 9000 스위치의 네트워크 관련 오디오 문제 해결
소개
이 문서에서는 VoIP(Voice over IP) 환경에서 네트워크 관련 오디오 문제를 해결하는 방법에 대해 설명합니다.
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- QoS
- VoIP 네트워크
- SPAN(Switchport Analyzer)
- 와이어샤크
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- Catalyst 9200
- Catalyst 9300
- Catalyst 9400
- Catalyst 9500
- Catalyst 9600
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
VoIP 인프라에서 오디오의 품질은 다음과 같은 증상이 있는 네트워크 관련 문제의 영향을 받을 수 있습니다.
- 음성 또는 오디오의 간격이 간헐적으로 발생합니다.
- 단방향 오디오.
- 단일 사용자가 아니라 동일한 VLAN을 공유하거나 동일한 액세스 스위치를 공유하는 등 공통된 특성을 가진 사용자 그룹으로 격리됩니다.
네트워크 관련 문제를 해결하려면 음성 패킷의 소스에서 대상까지 명확한 토폴로지를 지정하는 것이 중요합니다. 음성 패킷이 전환되거나 라우팅되는 네트워크의 어느 지점에서든 문제 진단을 시작할 수 있습니다. 그러나 액세스 레이어에서 트러블슈팅을 시작하고 라우팅 레이어로 이동하는 것이 좋습니다.
네트워크 다이어그램
패스에서 캡처 포인트를 선택합니다. A(하나의 IP 전화에 가장 가까운 위치), B(라우팅 전), C(대상에 가장 가까운 위치)일 수 있습니다.
SPAN 캡처는 대화의 양쪽을 식별하고 추가 분석을 위해 캡처에서 지터 또는 패킷 손실과 같은 다른 변수와 함께 각 오디오를 추출하기 위해 일반적으로 양방향(TX 및 RX)으로 수행됩니다.
캡처 포인트를 결정한 후 스위치에 SPAN 컨피그레이션을 설정합니다.
Switch(config)#monitor session 1 source interface Gig1/0/1 both
Switch(config)#monitor session 1 destination interface Gig1/0/6 encapsulation replicate
Switch#show monitor session all
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/6
Encapsulation : Replicate
Ingress : DisabledWireshark를 사용하는 PC/랩톱에서 선택한 캡처 지점의 오디오 흐름을 캡처하기 위해 테스트 통화를 시작합니다.
캡처 분석
1. Wireshark를 사용하여 가져온 패킷 캡처를 열고 Statistics > Conversations로 이동합니다. 관련된 장치의 IP 주소(IP Phone 소스 및 대상)를 기반으로 오디오 대화를 찾습니다.
2. 일반적으로 오디오 스트림은 UDP 프로토콜에 의해 전달되며, 대부분의 경우 Wireshark가 내장된 오디오를 추출하기에 적합한 형식으로 디코딩되지 않습니다. 그 다음 단계는 UDP 스트림을 오디오 형식으로 디코딩하는 것이며, 기본적으로 RTP가 사용됩니다. 스트림의 패킷을 마우스 오른쪽 버튼으로 클릭한 다음 Decode as(다음으로 디코딩)를 클릭합니다.
3. 현재 열을 찾고 RTP를 선택합니다. OK(확인)를 클릭합니다.
Wireshark는 전체 UDP 스트림을 RTP로 디코딩하므로 콘텐츠를 분석할 수 있습니다.
4. RTP 통계를 확인하여 오디오 스트림에 지터 또는 손실이 있는지 확인합니다. 분석을 보려면 Telephony(텔레포니) > RTP > RTP Stream Analysis(RTP 스트림 분석)로 이동합니다.
지터: 네트워크를 통해 음성 패킷을 전송하는 데 걸리는 시간 지연입니다. 이는 네트워크 혼잡 또는 경로 변경으로 인해 발생하는 경우가 많습니다. 이 측정값은 30ms 미만이어야 합니다.
손실: 오디오 스트림의 일부로 수신되지 않은 패킷입니다. 패킷 손실은 1%를 초과할 수 없습니다.
5. Telephony(텔레포니) > RTP(RTP) > RTP Streams(RTP 스트림)에서 이 스트림의 오디오 파를 변환합니다.
6. 스트림을 선택하여 오디오로 변환하고 [스트림 재생]을 클릭합니다.
오디오 웨이브가 표시되어야 하며 재생 버튼을 사용하여 오디오 데이터를 들을 수 있습니다. 오디오를 들으면 스트림에 끊긴 음성이 있는지 단방향 오디오 문제가 있는지 확인하는 데 도움이 됩니다.
7. Export(내보내기) > File Synchronized Audio(파일 동기화된 오디오)를 클릭하여 스트림을 확장자가 .wav인 오디오 파일로 내보냅니다.
문제 해결
SPAN 기능을 사용하여 Wireshark로 캡처를 수집하고 분석한 후에는 지터, 패킷 손실 또는 단방향 오디오와 관련된 문제인지 파악할 수 있습니다. 패킷 캡처에서 발견된 문제가 있는 경우 다음 단계는 RTP 오디오 스트림에 영향을 줄 수 있는 일반적인 문제가 있는지 캡처한 디바이스를 확인하는 것입니다.
오디오 고르지 않음
불충분한 대역폭, 지터 및/또는 패킷 손실은 오디오 캡처에서 끊어진 음성 또는 왜곡을 듣는 일반적인 원인이 될 수 있다.
1. 캡처의 지터가 30ms 이상인지 확인합니다. 이 경우, 이는 QoS 정책 또는 라우팅 문제로 인해 패킷 수신에 시간 지연이 발생할 수 있음을 나타냅니다.
2. 캡처에서 손실된 패킷이 1%를 초과하는지 확인합니다. 이 값이 높은 경우 오디오 스트림 흐름의 경로를 따라 패킷 삭제를 찾아야 합니다.
3. 경로에 포함된 인그레스 및 이그레스 인터페이스의 삭제를 확인합니다.
Switch#show interface Gi1/0/1 | inc drops
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol dropsSwitch#show interfaces Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Gi1/0/1 0 0 0 0 0 0인터페이스에 증가 입/출력 삭제 또는 기타 증가 오류가 없는지 확인합니다.
4. 경로에 포함된 인터페이스에서 QoS 이그레스(egress) 정책을 확인합니다. 트래픽이 Priority 대기열에 매핑/분류되어 있고 이 대기열에 삭제되지 않았는지 확인합니다.
Switch#show platform hardware fed switch 1 qos queue stats interface Gi1/0/1
----------------------------------------------------------------------------------------------
AQM Global counters
GlobalHardLimit: 3976 | GlobalHardBufCount: 0
GlobalSoftLimit: 15872 | GlobalSoftBufCount: 0
----------------------------------------------------------------------------------------------
High Watermark Soft Buffers: Port Monitor Disabled
----------------------------------------------------------------------------------------------
Asic:0 Core:1 DATA Port:0 Hardware Enqueue Counters
----------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
-- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 707354 2529238 0 <<< Priority Q
1 0 0 0 1858516 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
Asic:0 Core:1 DATA Port:0 Hardware Drop Counters
--------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
-- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0 <<< Priority Q Drops
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0 단방향 오디오
전화 통화가 설정되면 상대방 중 한 명만 오디오를 수신합니다. 이 문제의 일반적인 원인은 연결 문제, 라우팅 문제 또는 NAT/방화벽 문제와 관련이 있습니다.
1. 대상 서브넷 또는 대상 게이트웨이에 ping을 수행하여 양방향 연결이 가능한지 확인합니다.
Switch#ping 192.168.1.150
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.150, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms2. 소스에서 대상 서브넷 및 viceversa로 traceroute를 수행합니다. 이는 패스에 있는 홉 수와 대칭 홉인지를 확인하는 데 도움이 될 수 있습니다.
Switch#traceroute 192.168.1.150
Type escape sequence to abort.
Tracing the route to 192.168.1.150
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.2.12 2 msec * 1 msec
2 192.168.1.12 2 msec * 1 msec
3 192.168.1.150 2 msec 2 msec 1 msec3. 각 서브넷의 게이트웨이 장치에 최적의 라우팅이 있고 통신에 영향을 줄 수 있는 비대칭 경로가 없는지 확인합니다.
4. 오류가 발생한 방향으로 오디오 트래픽이 표시된 마지막 디바이스에서 패킷 캡처를 수행합니다. 이렇게 하면 오디오 흐름이 끊긴 경로의 디바이스를 격리하는 데 도움이 됩니다. 이는 NAT 또는 방화벽 디바이스를 통해 ping 트래픽을 허용할 수 있지만 특정 오디오 트래픽이 차단되거나 제대로 변환되지 않을 수 있기 때문에 중요합니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
2.0 |
01-Aug-2023 |
마지막 섹션에 문제 격리에 대한 추가 정보 추가 |
1.0 |
27-Jul-2023 |
최초 릴리스 |
피드백