양방향 액티브 측정 프로토콜 이해하기
TWAMP(Two-Way Active Measurement Protocol)를 사용하여 네트워크에서 두 디바이스 간의 네트워크 성능을 측정하는 방법에 대해 알아보십시오.
RFC 5357에 기술된 TWAMP(Two-Way Active Management Protocol)는 단방향 기능 대신 양방향 또는 왕복 측정을 제공하는 OWAMP(One-Way Active Management Protocol)의 확장입니다. 왕복 지연은 호스트 클럭 동기화가 필요하지 않고 원격 지원이 단순한 에코 기능일 수 있기 때문에 양방향 측정이 유용합니다. 그러나 이 목적을 위한 ICMP(Internet Control Message Protocol) 에코 요청/응답(ping에서 사용)에는 몇 가지 단점이 있습니다. TWAMP는 타임스탬프를 사용하여 다른 방법보다 더 높은 정확도로 양방향 또는 왕복 메트릭을 측정하기 위한 개방형 프로토콜을 정의합니다(처리 지연도 고려될 수 있음).
기능 탐색기: 양방향 액티브 측정 프로토콜을 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.
플랫폼별 TWAMP 동작 섹션에서 플랫폼 관련 참고 사항을 검토하십시오.
TWAMP의 이점
-
TWAMP 프로브 구성은 전용 디바이스 사용 없이 네트워크 엔드투엔드를 활성화, 테스트, 모니터링 및 문제 해결하는 데 도움이 됩니다.
-
TWAMP 타임스탬프는 다른 방법보다 더 나은 정확도(처리 지연도 고려될 수 있음)로 양방향 또는 왕복 메트릭을 제공합니다.
-
TWAMP는 SLA(서비스 수준 계약) 준수 여부를 확인하는 데 자주 사용되며 TWAMP 기능은 종종 이러한 맥락에서 사용됩니다.
-
왕복 지연은 호스트 클럭 동기화가 필요없기 때문에 양방향 측정이 단방향 측정보다 더 효율적입니다. 이는 리플렉터가 패킷에 자체 시퀀스 번호를 배치하기 때문에 가능합니다.
동일한 디바이스에 RPM 클라이언트 및 TWAMP 서버를 구성하지 않는 것이 좋습니다. 이는 RPM 프로브 결과에 몇 가지 문제를 야기할 수 있습니다.
TWAMP(Two-Way Active Measurement Protocol)에 대해 이해하기
일반적으로 TWAMP는 특정 역할을 수행하는 두 디바이스의 인터페이스 간에 작동합니다. TWAMP는 SLA(서비스 수준 계약) 준수 여부를 확인하는 데 자주 사용되며 TWAMP 기능은 종종 이러한 맥락에서 제공됩니다. TWAMP는 정의된 여러 요소 사이에서 실행되는 두 개의 관련 프로토콜을 사용합니다.
-
TWAMP-Control—테스트 세션을 시작, 시작 및 종료합니다. TWAMP-Control 프로토콜은 Control-Client 엘리먼트와 Server 엘리먼트 사이에서 실행됩니다.
-
TWAMP-Test—두 TWAMP 요소 간에 테스트 패킷을 교환합니다. TWAMP-Test 프로토콜은 Session-Sender 엘리먼트와 Session-Reflector 엘리먼트 사이에서 실행됩니다.
그림 1에 4가지 요소가 나와 있습니다.
의 4가지 요소
4개의 다른 TWAMP 디바이스가 TWAMP Control-Client, Server, Session-Sender 및 Session-Reflector의 4가지 논리적 역할을 수행할 수 있지만 다른 디바이스는 다른 역할을 수행할 수 있습니다. 일반적인 구현 작업을 통해 하나의 디바이스(TWAMP 컨트롤러 또는 TWAMP 클라이언트로 알려져 있음)에서 제어 클라이언트 및 세션 발신자의 역할과 다른 디바이스(TWAMP 응답자 또는 TWAMP 서버로 알려져 있음)에서 서버 및 세션 리플렉터의 역할을 결합할 수 있습니다. 이 경우, 각 디바이스는 TWAMP-Control(제어 클라이언트와 서버 간) 및 TWAMP-Test(세션 발신자 및 세션 리플렉터) 프로토콜을 모두 실행합니다.
구현된 TWAMP 클라이언트-서버 아키텍처는 다음과 같습니다.
-
TWAMP 클라이언트
-
Control-Client는 TWAMP 테스트 세션을 설정, 시작 및 중지합니다.
-
Session-Sender는 TWAMP 서버의 Session-Reflector로 전송되는 TWAMP 테스트 패킷을 생성합니다.
-
-
TWAMP 서버
-
세션 리플렉터는 테스트 패킷이 수신되면 측정 패킷을 다시 전송하지만 이러한 정보의 기록을 유지하지는 않습니다.
-
서버는 TWAMP 클라이언트와의 하나 이상의 세션을 관리하고 TCP 포트에서 제어 메시지를 수신합니다.
-
이러한 요소를 TWAMP 클라이언트 및 TWAMP 서버 프로세스로 패키징하는 방법은 그림 2에 나와 있습니다.
TWAMP 라이트 지원
RFC 5357의 부록 I에 정의된 TWAMP Light는 테스트 파라미터가 협상되는 대신 사전 정의된 TWAMP의 상태 비저장 버전입니다. 테스트 포트에서 서버가 수신한 모든 테스트 패킷은 다시 반영되고 즉시 잊혀집니다. 이를 지원하는 디바이스의 경우 IPv6 링크-로컬 대상 주소를 포함하여 IPv6 대상 주소를 구성할 수도 있습니다.
기능 탐색기: 양방향 액티브 측정 프로토콜을 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.
간단한 양방향 액티브 측정 프로토콜(STAMP) 지원
RFC 8762, Simple Two-Way Active Measurement Protocol에 정의된 바와 같이, STAMP는 RFC 5357, TWAMP(Two-Way Active Measurement Protocol )의 부록 I에 정의된 TWAMP Light 작동 모드를 표준화하고 확장합니다. STAMP를 지원하는 디바이스의 경우 STAMP 호환 리플렉터는 대칭 페이로드 크기(RFC 6038에 따름)를 보장하고 반영된 페이로드의 시퀀스 번호가 클라이언트 프레임에서 복사되는지 또는 독립적으로 생성되는지에 따라 상태 비저장 또는 상태 저장 모드에서 작동합니다. 상태 저장 리플렉터는 드롭이 발생한 방향을 감지할 수 있습니다. 이전 릴리스에서는 대칭 페이로드와 상태 비저장 리플렉션을 지원했습니다. 상태 저장 리플렉션, STAMP 표준의 완전한 준수 및 클라이언트에 대한 단방향 드롭 값을 지원합니다. STAMP 클라이언트뿐만 아니라 TWAMP-Managed-mode 클라이언트에 대해서도 단방향 드롭 값을 지원합니다. 진화한 Junos OS의 경우, STAMP는 계층 레벨에서 [edit services monitoring twamp server light] 구성됩니다. 스테이트풀 리플렉션은 문으로 stateful-sequence 구성됩니다. 서버의 경우 에 대한 offload-type 새로운 기본값은 이제 pfe-timestamp inline-timestamp.
기능 탐색기: STAMP(Simple Two-Way Active Measurement Protocol)를 사용하여 플랫폼 및 릴리스 지원을 확인하십시오.
정적 경로 추적
Junos OS Evolved 릴리스 24.4R1부터 정적 경로 추적 지원을 Junos OS Evolved로 확장했으며 TWAMP(Two-Way Active Measurement Protocol) 테스트 지원도 포함했습니다. TWAMP 프로브를 사용하여 링크 상태를 감지하고 프로브 결과에 따라 선호 경로 상태를 변경할 수 있습니다. 추적된 정적 경로는 IPv4 또는 IPv6일 수 있으며, 각 IPv4 및 IPv6 추적 정적 경로는 최대 16개의 다음 홉을 지원합니다. 또한 각 IPv4 또는 IPv6 대상 접두사에 대한 메트릭, 경로 기본 설정 및 태그 값을 구성할 수 있습니다. 그러나 Junos OS Evolved 디바이스에서는 이 기능을 다르게 구성합니다. 계층 수준에서 문을 [edit routing-options] 구성합니다sla-tracking. 다른 명령인 show route sla-tracking을 사용하여 이러한 경로에 대한 정보를 볼 수도 있습니다.
경로 구성을 위한 세그먼트 라우팅 지원
Junos OS Evolved 릴리스 24.4R1부터 SR 아키텍처를 광범위하게 지정하는 RFC 8402에 정의된 세그먼트 라우팅(SR)에 대한 TWAMP(Two-Way Active Measurement Protocol) 지원이 추가되었습니다. 주니퍼는 TWAMP 프로브에 대해 두 가지 유형의 SR을 지원합니다.
-
SR-MPLS: 각각 세그먼트 끝 노드를 나타내는 레이블 목록을 사용합니다.
-
SRv6: RFC 8754에 도입된 유형 4 IPv6 라우팅 헤더를 사용하며, 각 세그먼트 엔드 노드는 IPv6 주소 또는 IPv6 세그먼트 식별자(SID)로 표시됩니다.
리플렉터에 도달할 TWAMP 프로브의 SR-MPLS 또는 SRv6 세그먼트 목록을 지정할 수 있습니다. 또한 리플렉터에서 클라이언트로의 반환 경로에 대해 동일한 정보를 지정할 수 있습니다. 이 반환 경로 정보는 세그먼트 라우팅 유형에 따라 세그먼트 라우팅 네트워크용 단순 TWAMP(STAMP) 확장, draft-ietf-ippm-stamp-srpm에서 제안된 확장, 즉 반환 경로 TLV 및 반환 세그먼트 목록 하위 TLV를 적절하게 사용하여 프로브 자체에 포함됩니다. TWAMP 프로브는 라우팅 엔진 또는 패킷 포워딩 엔진 중 하나에서 타임스탬프가 수행됩니다.
이 기능을 구성하려면 계층 수준에서 명령문을 포함 source-routing 하십시오 [edit services monitoring twamp client control-connection name test-session session-name .
Junos OS Evolved TWAMP 지원의 차이점
TWAMP에 대한 Junos OS Evolved 지원은 다음으로 제한됩니다.
-
제어 세션 및 테스트 세션에만 해당되는 IPv4 및 IPv6 트래픽. 진화한 Junos OS 릴리스 21.4R1부터 클라이언트 목록, 제어 연결 및 테스트 세션에 대해 IPv6 소스 및 대상 주소(링크-로컬 주소 제외)가 지원됩니다.
-
프로브 통계 및 기록
-
세션 상태 제어 및 테스트
-
테스트 세션 프로브 생성 및 수신, 반사
IPv4 트래픽을 위해 라우팅 엔진 또는 패킷 포워딩 엔진이 설정한 타임스탬프. IPv6 트래픽의 경우, 라우팅 엔진에 의해서만 타임스탬프가 설정됩니다. IPv6 트래픽의 경우, Junos OS Evolved 22.3R1부터 패킷 포워딩 엔진 타임스탬프를 지원합니다. Junos OS Evolved 릴리스 22.3R1 이전에는 IPv6 트래픽
서버용 Junos OS Evolved 릴리스 23.4R1부터 문의 기본값은offload-type의 경우 계층 수준의 문을[edit services monitoring twamp client control-connection name test-session name]로none구성해야 합니다. 지원되는 디바이스에 대해 Junos OS Evolved 릴리스 22.4R1부터 문의 옵션을offload-type구성inline-timestamping하여 하드웨어에서 인라인으로 설정한 타임스탬프를 활성화할 수 있습니다.offload-type이제pfe-timestampinline-timestamp.-
시스템 로그 메시지 및 SNMP 트랩을 통해서만 오류 보고
-
인증되지 않은 모드만
TWAMP에 대한 Junos OS Evolved 지원에는 Junos OS에 포함되지 않은 몇 가지 기능도 포함됩니다.
-
Junos OS Evolved 릴리스 23.4R1부터 RFC 8762, STAMP(Simple Two-Way Active Measurement Protocol )를 지원합니다. RFC 8762는 RFC 5357, TWAMP(Two-Way Active Measurement Protocol )의 부록 I에 정의된 TWAMP Light 작동 모드를 표준화하고 확장합니다. 자세한 내용은 STAMP(Simple Two-Way Active Measurement Protocol) 지원을 참조하십시오.
-
진화한 Junos OS 릴리스 24,4R1부터 이 기능을 지원하는 디바이스에 대해 TWAMP를 사용한 정적 경로 추적을 지원합니다. 자세한 내용은 정적 경로 추적을 참조하십시오.
-
Junos OS Evolved 릴리스 24.4R1부터 이를 지원하는 PTX 라우터에 대해 RFC 8402에 정의된 세그먼트 라우팅(SR)을 위한 TWAMP(Two-Way Active Measurement Protocol) 지원이 추가되었습니다. 자세한 내용은 경로 구성을 위한 세그먼트 라우팅 지원을 참조하십시오.
플랫폼별 TWAMP 동작
기능 탐색기: 양방향 액티브 측정 프로토콜을 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.
다음 표를 사용하여 플랫폼에 대한 플랫폼별 동작을 검토합니다.
| 플랫폼 | 차이점 |
|---|---|
| ACX 시리즈 |
|
| EX 시리즈 |
제어 클라이언트와 세션 전송자(TWAMP 클라이언트)가 모두 동일한 주니퍼 네트웍스 라우터에 상주합니다. 그러나 TWAMP 클라이언트에서는 서버와 세션 반영자가 동일한 시스템에 있을 필요가 없습니다. 따라서 Juniper TWAMP 클라이언트는 제3자 서버 구현과 함께 작동할 수 있습니다. |
| MX 시리즈 |
|
| PTX 시리즈 |
|
| QFX 10000 시리즈 |
제어 클라이언트와 세션 전송자(TWAMP 클라이언트)가 모두 동일한 주니퍼 네트웍스 라우터에 상주합니다. 그러나 TWAMP 클라이언트에서는 서버와 세션 반영자가 동일한 시스템에 있을 필요가 없습니다. 따라서 Juniper TWAMP 클라이언트는 제3자 서버 구현과 함께 작동할 수 있습니다. |
| QFX5000 시리즈(Junos OS Evolved) |
진화한 Junos OS의 경우, TWAMP는 계층 레벨에서 |
| SRX 시리즈(SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200 디바이스 및 vSRX 가상 방화벽 인스턴스) |
|
MX 시리즈의 경우, 아래 표는 RPM 클라이언트 및 서버 지원, TWAMP 클라이언트(제어 구성 요소 포함) 및 TWAMP 서버(응답자 구성 요소 포함) 지원, 타임스탬핑을 수행하는 하드웨어 간의 관계를 보여줍니다.
| TWAMP 기능 지원 |
라우팅 엔진 타임스탬프 |
MS-PIC/MS-DPC 타임스탬프 |
MS-MIC/MS-MPC 타임스탬프 |
패킷 포워딩 엔진(마이크로커널) 타임스탬프 |
패킷 포워딩 엔진(LU) 타임스탬프( |
| RPM 클라이언트 |
예 |
예 |
예 |
예 |
아니요 |
| RPM 서버 |
예 |
예 |
예 |
예 |
아니요 |
| TWAMP 클라이언트 |
아니요 |
아니요 |
아니요 |
예 |
예 |
| TWAMP 서버 |
아니요 |
예 |
아니요 |
예(응답자 구성 필요 없음) |
예 |
서비스 인터페이스(sp-및 ms-si- 인터페이스)에 대한 지원은 모두 약간 다릅니다.
표 3 은 MX 시리즈 TWAMP 및 MPC, MS-MIC/MPC 및 인라인에서의 관련 타임스탬프 지원에 대한 정보를 제공합니다.
| 특징 |
역할 |
IP 버전 |
지원(Y/N) |
인라인(Inline) 타임스탬프 |
MPC의 타임스탬프(hardware-timestamp) |
MPC의 타임스탬프(si-interface) |
MS-MIC/MPC의 타임스탬프(delegate-probes) |
|---|---|---|---|---|---|---|---|
| TWAMP (트왐프) |
클라이언트 |
IPv4 (IPv4) |
Y |
N |
Y(μ초) 최대 프로브 500개 |
Y(μ초) 최대 프로브 500개 |
N |
| IPv6 (IPv6) |
N |
N |
N |
N |
N |
||
| 서버
|
IPv4 (IPv4) |
Y |
N |
Y(μ초) 최대 프로브 500개 |
Y(μ초) 최대 프로브 500개 |
N |
|
| IPv6 (IPv6) |
N |
N |
N |
N |
N |