Cisco Service Assurance Agent 및 Internetwork Performance Monitor를 사용하여 VoIP(Voice over IP) 네트워크에서 서비스 품질 관리

다운로드 옵션

PDF (297.0 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (250.2 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (327.8 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2017년 8월 29일

문서 ID:13938

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 VoIP(Voice over IP) 네트워크에서 QoS(Quality of Service)를 측정하기 위해 Cisco SAA(Service Assurance Agent) 및 IPM(Internetwork Performance Monitor)을 사용하는 방법에 대해 설명합니다.이 정보는 실제 IP 텔레포니 프로젝트를 기반으로 합니다.이 문서에서는 제품 자체가 아니라 제품 적용에 초점을 둡니다.Cisco SAA 및 IPM에 대해 이미 알고 있어야 하며 필요한 제품 설명서에 액세스할 수 있어야 합니다.다른 문서에 대한 참조는 관련 정보를 참조하십시오.

참고: Cisco IOS® 소프트웨어의 Cisco SAA 기능은 이전의 RTR(Response Time Reporter)로 알려져 있습니다.

대규모 VoIP 네트워크를 관리하는 경우 네트워크의 음성 품질을 객관적으로 모니터링하고 보고하는 데 필요한 툴을 갖추고 있어야 합니다.사용자 피드백은 주관적이고 불완전한 경우가 많기 때문에 사용자 피드백에만 의존하는 것은 불가능합니다.음성 품질 문제는 일반적으로 네트워크 QoS 문제로 인해 발생합니다.따라서 음성 품질 문제를 식별할 때 네트워크 QoS를 관리 및 모니터링하는 두 번째 도구가 필요합니다.이 문서의 예제는 Cisco SAA 및 IPM을 이 용도로 사용합니다.

Cisco CVM(Voice Manager)은 Telemate.net과 함께 음성 품질을 관리하는 데 사용됩니다.각 통화에 대해 Cisco IOS 게이트웨이에 의해 계산된 ICPIF(Disable/Calculated Planning Disable Factor)를 통해 통화의 음성 품질을 보고합니다.이를 통해 네트워크 관리자는 음성 품질이 좋지 않은 사이트를 식별할 수 있습니다.자세한 내용은 Cisco CVM(Voice Manager)을 사용한 음성 품질 관리 및 텔레메이트를 참조하십시오.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 또는 하드웨어 버전으로 제한되지 않지만 이 문서의 예에는 다음 소프트웨어 및 하드웨어 버전이 사용됩니다.

Cisco IOS Software 릴리스 12.1(4)
Windows NT용 IPM 2.5
Catalyst 4500 Series 스위치

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

VoIP 네트워크의 QoS 문제

패킷화된 음성 네트워크에서 몇 가지 요인으로 인해 음성 품질이 저하될 수 있습니다.

패킷 손실
과도한 지연
과도한 지터

WAN에서 패킷 스위치 서비스를 사용하는 경우(예: ATM, 프레임 릴레이 또는 IP Virtual Private Network), 이러한 수치를 지속적으로 모니터링하는 것이 특히 중요합니다. 캐리어 네트워크에서 정체, 에지 디바이스에서 잘못 구성된 트래픽 셰이핑 또는 캐리어 측에서 잘못 구성된 폴리싱으로 인해 패킷 손실 또는 과도한 버퍼링이 발생할 수 있는 여러 시나리오가 있습니다.캐리어가 패킷을 삭제하는 경우 에지 디바이스에 명백한 증거가 없습니다.따라서 인그레스(ingress)에 트래픽을 전달하고 이그레스(egress)에 성공적으로 도착했는지 확인할 수 있는 Cisco SAA와 같은 엔드 투 엔드 툴이 필요합니다.

Cisco SAA 및 IPM으로 QoS 관리

Cisco SAA 및 IPM 구성 요소는 다음과 같습니다.

RTR 프로브
RTR 응답자
IPM 콘솔

RTR 프로브는 RTR 응답자에게 패킷 버스트를 전송합니다.RTR 응답자는 이를 돌려 프로브로 보냅니다.이 간단한 작업을 통해 프로브는 패킷 손실 및 왕복 지연 시간을 측정할 수 있습니다.지터를 측정하기 위해 프로브는 패킷 버스트를 시작하기 전에 제어 패킷을 응답자에게 전송합니다.제어 패킷은 버스트의 각 패킷 간에 예상되는 밀리초(밀리초)를 응답자에게 알립니다.그런 다음 응답자는 버스트 중에 패킷 간 지연을 측정하며, 예상 간격의 모든 편차는 지터로 기록됩니다.

IPM 콘솔은 QoS 모니터링을 제어합니다.SNMP(Simple Network Management Protocol)를 통해 관련 정보로 RTR 프로브를 프로그래밍합니다. 또한 SNMP를 통해 결과를 수집합니다.RTR 프로브에 명령줄 인터페이스 Cisco IOS 컨피그레이션이 필요하지 않습니다.

RTR responder 글로벌 컨피그레이션 명령을 실행하여 RTR 응답자를 수동으로 구성합니다.

RTR 프로브 및 응답자는 Cisco IOS Software 릴리스 12.0(5)T 이상을 실행해야 합니다.최신 12.1 메인스트림(Mainstream) 유지보수 릴리스가 권장됩니다.이 문서의 예에서 RTR 프로브 및 응답자는 릴리스 12.1(4)을 실행하고 있습니다. 사용 중인 IPM 버전은 Windows NT용 IPM 2.5입니다.이 버전의 Cisco.com에서 패치를 사용할 수 있습니다.이 패치는 IPM이 잘못된 IP 우선 순위 설정으로 RTR 프로브를 구성하는 문제를 수정하므로 중요합니다.

설계

Cisco SAA 및 IPM 솔루션을 구축하기 전에 다음 사항을 염두에 두고 설계 작업을 수행해야 합니다.

RTR 프로브 및 responder 배치
프로브에서 responder로 전송되는 트래픽 유형

프로브 및 대응자의 배치를 결정할 때 고려해야 할 몇 가지 사항이 있습니다.첫째, QoS 측정은 문제 사이트뿐만 아니라 모든 사이트에 적용됩니다.이는 IPM이 지정된 사이트에 대해 보고하는 지연 및 지터 번호가 동일한 네트워크의 다른 사이트와 비교할 때 가장 유용하기 때문입니다.따라서 QoS가 우수하고 QoS가 불량한 사이트를 측정하고자 합니다.또한 트래픽 패턴이나 네트워크 변경 사항으로 인해 성능이 우수한 사이트가 내일 열악한 사이트가 될 수도 있습니다.음성 품질에 영향을 주고 사용자가 보고하기 전에 이를 탐지합니다.

둘째, CPU 사용률이 중요합니다.이미 사용 중인 라우터가 RTR 구성 요소를 적시에 서비스하지 못할 수 있으므로 결과가 왜곡될 수 있습니다.또한 단일 라우터에 프로브 인스턴스를 너무 많이 배치하는 경우 CPU 사용률 문제가 발생할 수 있습니다. 단, 이전에는 존재하지 않았던 경우도 있습니다.이 문서의 예제 네트워크에 대해 선택한 접근 방식(대부분의 네트워크에서 작동해야 함)은 RTR 프로브를 원격/브랜치 라우터에 배치하는 것입니다.이러한 라우터는 일반적으로 단일 LAN을 비교적 느린 WAN 서비스에 연결합니다.따라서 브랜치 라우터는 CPU 사용률이 매우 낮으며 RTR에 쉽게 대응할 수 있습니다.이 설계의 또 다른 이점은 가능한 한 많은 라우터에 로드를 분산한다는 것입니다.프로브가 특정 양의 SNMP 폴링을 사용하므로 프로브가 responder가 되기 보다는 프로브가 되는 것이 더 중요하다는 점을 기억하십시오.

이 설계에서는 RTR 응답자를 코어에 배치해야 합니다.응답자들은 많은 조사에 응답할 것이기 때문에, 그 조사보다 더 바빠질 것입니다.따라서 강력한 설계는 응답자로만 작동하는 전용 라우터를 구축합니다.대부분의 조직은 이러한 기능을 수행할 수 있는 폐기된 라우터를 선반에 두고 있습니다.이더넷 인터페이스가 있는 모든 라우터면 충분합니다.또는 코어/디스트리뷰션 라우터가 응답자로 두 배 증가할 수 있습니다.이 섹션의 네트워크 다이어그램은 두 시나리오를 모두 보여줍니다.

다음 명령을 사용하여 가능한 한 많은 라우터에 로드를 분산하고 RTR CPU 사용량을 모니터링합니다.

Router# show processes cpu | i Rtt|PID

PID  Runtime(ms)  Invoked  uSecs  5Sec   1Min   5Min    TTY Process
67           0         7      0   0.00%  0.00%  0.00%   0 Rtt Responder

응답자와 프로브를 매칭하는 경우 프로브와 responder 간에 일관된 토폴로지를 유지하는 것이 좋습니다.예를 들어 모든 프로브 및 응답자는 동일한 수의 라우터, 스위치 및 WAN 링크로 구분해야 합니다.그래야 사이트 간에 IPM 결과를 직접 비교할 수 있습니다.

이 예에서는 200개의 원격 사이트와 4개의 코어/배포 사이트가 있습니다.각 디스트리뷰션 사이트의 Catalyst 4500은 전용 RTR responder 역할을 합니다.각 200개의 원격 라우터는 RTR 프로브 역할을 합니다.각 프로브는 직접 연결된 배포 사이트에 있는 응답자를 대상으로 합니다.

프로브가 응답자에게 보낸 트래픽의 버스트에는 음성에 지정된 것과 동일한 QoS 수준이 네트워크별로 주어져야 합니다.이는 RTR 프로브의 트래픽이 엄격한 우선 순위 큐잉이 적용되도록 라우터에서 LLQ(Low Latency Queuing) 또는 RTP(Routing Table Protocol) 우선 순위 컨피그레이션을 조정해야 한다는 의미일 수 있습니다.RTP 패킷에 대한 프로브를 구성하는 경우 목적지 UDP(User Datagram Protocol) 포트만 제어할 수 있으며 소스 포트는 제어할 수 없습니다.이 예제 네트워크의 일반적인 LLQ 라우터 컨피그레이션에는 RTR 패킷을 음성과 동일한 대기열로 구체적으로 분류하는 액세스 목록이 있습니다.

class-map VoiceRTP
  match access-group name IP-RTP

policy-map 192Kbps_site
  class VoiceRTP
    priority 110

ip access-list extended IP-RTP
  deny   ip any any fragments
  permit udp 10.0.16.0 0.255.239.255
             range 16384 32768 10.0.16.0 0.255.239.255
             range 16384 32768 precedence critical
  permit udp any any eq 20000 precedence critical
  permit udp any eq 20000 any precedence critical

IP-RTP 액세스 목록에는 다음과 같은 분류 라인이 있습니다.

ip any any 프래그먼트 거부

레이어 4 액세스 목록이 암시적으로 허용하므로 모든 IP 프래그먼트를 거부합니다.
허용 udp 10.0.16.0 0.255.239.255 범위 16384 32768 10.0.16.0 범위 0.255.239.255 16384 32768 precedication critical

IP 우선 순위가 5로 설정된 음성 서브넷에서 RTP 패킷을 허용합니다.
허용 사용자 데이터그램 프로토콜 any eq 20000 우선 순위 중요

RTR 프로브에서 RTR 응답자로 가는 RTP 패킷을 허용합니다.
허용 udp any eq 20000 우선 순위 중요

RTR 응답자로부터 RTR 프로브로 다시 돌아가는 RTP 패킷을 허용합니다.

RTR 트래픽을 추가해도 LLQ 대기열이 초과 가입되어 실제 음성 패킷이 삭제되는 원인이 되지 않습니다.표준 Default60ByteVoice IPM 작업은 다음 매개 변수를 사용하여 RTP 패킷의 버스트를 전송합니다.

요청 페이로드:60바이트

참고: RTP 헤더와 음성입니다.28바이트(IP/UDP)를 추가하여 L3 데이터그램 크기를 가져옵니다.
간격:20밀리초
패킷 수:10

즉, 버스트 중에 RTR은 35.2Kbs의 LLQ 대역폭을 소비합니다.LLQ에 충분한 대역폭이 없는 경우 새 IPM 작업을 생성하고 패킷 간격을 늘립니다.이 IPM 컨피그레이션 창에 표시된 매개변수를 사용하여 버스트는 1Kbps의 대역폭만 사용합니다.

결과

이 섹션의 테이블은 IPM 보고서의 예입니다.이 보고서에는 3개의 RTR 프로브 인스턴스가 포함되어 있습니다.서로 다른 응답자를 대상으로 하거나 다른 페이로드를 사용하는 여러 RTR 프로브 인스턴스로 하나의 물리적 프로브를 구성할 수 있습니다.

다음은 각 열의 의미입니다.

평균:

IPM은 샘플링 시간당 평균을 계산합니다.그런 다음 이러한 시간당 평균은 일별, 주별 또는 월별 평균을 얻기 위해 긴 기간에 걸쳐 계산됩니다.즉, 일일 보고서의 경우 IPM은 지난 24시간 동안의 각 시간에 대한 평균을 계산합니다.그런 다음 이 24개의 평균 평균으로 일별 평균을 계산합니다.

평균 최대:

이 값은 차트의 각 일, 주 및 월에 대한 모든 시간당 최대값의 평균입니다.다시 말해, 일일 보고서의 경우, IPM은 지난 24시간 동안 각각 보고된 가장 큰 샘플을 가져갑니다.그런 다음 이 24개 샘플의 평균으로 일별 최대 평균을 계산합니다.

% 초과:

컬렉터에 대해 구성된 임계값을 초과한 샘플 비율입니다.

오류 %:

오류가 발생한 패킷의 백분율입니다.지터 프로브는 다음과 같은 여러 유형의 오류를 보고합니다.

SD Packet Loss(SD 패킷 손실) - 소스와 대상 간에 손실된 패킷
DS Packet Loss(DS 패킷 손실) - 대상과 소스 간에 손실된 패킷
Busies(비즈니스) - 이전 RTT 작업이 완료되지 않아 RTT(왕복 시간) 작업을 시작할 수 없는 횟수입니다.
시퀀스 - 예기치 않은 시퀀스 식별자로 받은 RTT 작업 완료 수입니다.이러한 문제가 발생할 수 있는 몇 가지 가능한 원인은 다음과 같습니다.
- 중복 패킷을 받았습니다.
- 시간 초과된 응답을 받았습니다.
- 손상된 패킷을 받았으며 탐지되지 않았습니다.
Drops(삭제) - 다음 중 하나가 발생한 횟수입니다.
- 필요한 내부 리소스(예: 메모리 또는 SNA(Systems Network Architecture) 하위 시스템)를 사용할 수 없으므로 RTT 작업을 시작할 수 없습니다.
- 작업 완료를 인식할 수 없습니다.
MIA(Missing in Action) - 방향을 확인할 수 없는 손실된 패킷의 수입니다.
Late(지연) - 시간 제한 후 도착한 패킷 수입니다.

이 정보에서 발생하는 질문은 VoIP 네트워크에서 어떤 지연, 지터 및 오류 값을 허용할 수 있는가입니다.불행히도 이 질문에 대한 간단한 답은 없다.허용되는 값은 코덱의 유형, 지터 버퍼 크기 및 기타 요인에 따라 달라집니다.또한 이러한 변수 간에는 상호 의존성이 있습니다.패킷 손실이 클수록 더 적은 지터가 허용될 수 있습니다.

실행 가능한 지연 및 지터 수치를 얻는 가장 좋은 방법은 동일한 네트워크의 유사 사이트를 비교하는 것입니다.192Kbps 연결 사이트를 모두 포함했지만 1개의 보고서 지터 값이 약 50ms이고 나머지 사이트에서 100ms 지터를 보고하는 경우 명목상 값에 관계없이 문제가 발생합니다.IPM은 전체 네트워크에 대해 지속적인 24x7 지연 및 지터 측정을 제공할 수 있으며 지연 및 지터 비교를 위한 벤치마크로 사용할 기준을 제공할 수 있습니다.

그러나 오류도 다르다.원칙적으로 0이 아닌 오류 백분율은 빨간색 플래그입니다.RTR 패킷에는 음성 패킷과 동일한 QoS 처리가 제공됩니다.네트워크 QoS 및 통화 허용 제어가 강력한 경우 혼잡 수준이 없으므로 음성 또는 RTR 패킷에 패킷 손실 또는 과도한 지연이 발생할 수 있습니다.따라서 IPM 오류 카운트가 0이 될 수 있습니다."정상"으로 간주될 수 있는 유일한 오류는 CRC(cyclic redundancy check) 오류이지만, 품질 인프라에서는 이러한 오류는 드물어야 합니다.자주 전화하면 음질에 대한 위험이 따릅니다.