양방향 능동 측정 프로토콜에 대한 이해
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가지 요소
네 개의 다른 TWAMP 디바이스가 TWAMP 제어 클라이언트, 서버, 세션 발신자 및 세션 리플렉터의 네 가지 논리적 역할을 수행할 수 있지만, 다른 디바이스는 다른 역할을 수행할 수 있습니다. 일반적인 구현은 하나의 디바이스(TWAMP 컨트롤러 또는 TWAMP 클라이언트로 알려져 있음)에서 제어 클라이언트 및 세션 발신자의 역할과 다른 디바이스(TWAMP 응답자 또는 TWAMP 서버로 알려져 있음)에서 서버 및 세션 리플렉터의 역할을 결합합니다. 이 경우 각 디바이스는 TWAMP-Control(Control-Client와 Server 간) 및 TWAMP-Test(Session-Sender와 Session-Reflector 간) 프로토콜을 모두 실행합니다.
구현된 TWAMP 클라이언트-서버 아키텍처는 다음과 같습니다.
-
TWAMP 클라이언트
-
Control-Client는 TWAMP 테스트 세션을 설정, 시작 및 중지합니다.
-
세션 발신자는 TWAMP 서버의 세션 리플렉터로 전송되는 TWAMP 테스트 패킷을 생성합니다.
-
-
TWAMP 서버
-
세션 리플렉터는 테스트 패킷이 수신될 때 측정 패킷을 다시 전송하지만 이러한 정보에 대한 기록을 유지하지는 않습니다.
-
서버는 TWAMP 클라이언트와의 하나 이상의 세션을 관리하고 TCP 포트에서 제어 메시지를 수신합니다.
-
이러한 요소를 TWAMP 클라이언트 및 TWAMP 서버 프로세스로 패키징하는 방법이 그림 2에 나와 있습니다.
TWAMP 조명 지원
RFC 5357의 부록 I에 정의된 TWAMP Light는 테스트 매개변수가 협상되는 대신 사전 정의된 TWAMP의 상태 비저장 버전입니다. 테스트 포트의 서버가 수신한 모든 테스트 패킷은 다시 반사되어 즉시 잊혀집니다. 이를 지원하는 디바이스의 경우 IPv6 link-local 대상 주소를 포함하여 IPv6 대상 주소를 구성할 수도 있습니다.
기능 탐색기: 양방향 활성 측정 프로토콜을 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인합니다.
간단한 STAMP(Two-Way Active Measurement Protocol) 지원
RFC 8762, 단순 양방향 액티브 측정 프로토콜에 정의된 바와 같이, STAMP는 RFC 5357의 부록 I, TWAMP( Two-Way Active Measurement Protocol )에 정의된 TWAMP Light 운영 모드를 표준화하고 확장합니다. STAMP를 지원하는 디바이스의 경우, STAMP 호환 리플렉터는 RFC 6038에 따라 대칭 페이로드 크기를 보장하고, 반사된 페이로드의 시퀀스 번호가 클라이언트 프레임에서 복사되었는지 또는 독립적으로 생성되는지에 따라 상태 비저장 또는 상태 저장 모드에서 작동합니다. 상태 저장 리플렉터는 드롭이 발생한 방향을 감지할 수 있습니다. 이전 릴리스에서는 대칭 페이로드와 상태 비저장 리플렉션을 지원했습니다. 스테이트풀 리플렉션, STAMP 표준에 대한 완전한 준수, 클라이언트에 대한 단방향 드롭 값을 지원합니다. STAMP 클라이언트뿐만 아니라 TWAMP 관리 모드 클라이언트에 대해서도 단방향 드롭 값을 지원합니다. Junos OS Evolved의 경우, 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 디바이스에서는 이 기능을 다르게 구성합니다. 계층 수준에서 문을 구성 sla-tracking 합니다. [edit routing-options] 또한 다른 명령 을 show route sla-tracking사용하여 이러한 경로에 대한 정보를 볼 수 있습니다.
경로 구성을 위한 세그먼트 라우팅 지원
이를 지원하는 PTX 라우터에 대한 Junos OS Evolved 릴리스 24.4R1부터, 이를 지원하는 MX 라우터에 대한 Junos OS 릴리스 25.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 프로브는 라우팅 엔진 또는 패킷 포워딩 엔진에서 타임스탬프가 지정됩니다.
Junos OS Evolved에 대해 이 기능을 구성하려면 계층 수준에서 [edit services monitoring twamp client control-connection name test-session session-name] 문을 포함 source-routing 합니다. Junos OS에 대해 이 기능을 구성하려면 계층 수준에서 [edit services rpm twamp client control-connection name test-session session-name] 문을 포함 source-routing 합니다.
타임스탬프
대부분의 플랫폼에서 기본적으로 타임스탬프는 패킷 포워딩 엔진 호스트 프로세서에서 설정됩니다. 프로브 메시지 통신의 지연 시간을 감안하여 프로브 패킷의 타임스탬프를 패킷 포워딩 엔진 하드웨어로 오프로드할 수 있습니다. 이러한 종류의 타임스탬핑을 인라인 타임스탬핑이라고 하며, 패킷이 디바이스를 떠나기 직전에 생성기 또는 리플렉터의 하드웨어에서 타임스탬프가 수행됩니다. 이 오프로드 및 인라인 타임스탬프에 대한 지원은 릴리스, 플랫폼 및 라인 카드 지원에 따라 다릅니다.
-
Junos OS: Junos OS 릴리스 25.4R1 이전에는 OR
sp-인터페이스를 구성si-하여 인라인 타임스탬프를 활성화할 수 있었습니다. Junos OS 릴리스 25.4R1부터는 이를 지원하는 MX 라인 카드에 대해 옵션을offload-type inline-timestamp사용하여 패킷 포워딩 엔진 하드웨어로 타임스탬핑을 오프로드할 수 있습니다. 이 인라인 타임스탬핑 기능은 Flex Algo 및 SR-MPLS도 지원합니다.인터페이스가 TWAMP용 MX 라우터에 구성된 경우
si-, 이 옵션이 타임스탬핑의 기본값입니다. 인터페이스 구현을si-디버깅하려면 또는nonepfe-timestamp옵션을 구성해야 합니다.,
[edit services rpm twamp server], 또는[edit services rpm twamp server light]계층 수준[edit services rpm twamp client control-connection name test-session name]중 하나에서 문을 구성offload-type (inline-timestamp | none | pfe-timestamp)합니다. -
Junos OS Evolved: 타임스탬프는 IPv4 트래픽에 대한 라우팅 엔진 또는 패킷 포워딩 엔진에 의해 설정됩니다. IPv6 트래픽의 경우, 타임스탬프는 라우팅 엔진에 의해서만 설정됩니다. IPv6 트래픽의 경우 Junos OS Evolved 22.3R1부터 패킷 포워딩 엔진 타임스탬프를 지원합니다. Junos OS Evolved 릴리스 22.3R1 이전에는 IPv6 트래픽
offload-type의 경우 계층 수준의 문을[edit services monitoring twamp client control-connection name test-session name]로 구성해야 합니다.none지원되는 디바이스용 Junos OS Evolved 릴리스 22.4R1부터는 하드웨어에 의해 인라인으로 설정된 타임스탬프를 활성화하도록 문 옵션을offload-type구성할inline-timestamping수 있습니다. 서버용 Junos OS Evolved 릴리스 23.4R1부터 문의 기본값offload-type은 이제pfe-timestampinline-timestamp. Junos OS Evolved 릴리스 25.4R1부터 인라인 타임스탬핑 기능은 Flex Algo 및 SR-MPLS도 지원합니다.
Junos OS Evolved TWAMP 지원의 차이점
TWAMP에 대한 Junos OS Evolved 지원은 다음과 같이 제한됩니다.
-
IPv4 및 IPv6 트래픽은 제어 세션 및 테스트 세션에만 해당됩니다. Junos OS Evolved 릴리스 21.4R1부터 IPv6 소스 및 대상 주소(link-local 주소 제외)가 클라이언트 목록, 제어 연결 및 테스트 세션에 지원됩니다.
-
프로브 통계 및 기록
-
세션 상태 제어 및 테스트
-
테스트 세션 프로브 생성 및 수신, 리플렉션
-
시스템 로그 메시지 및 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 Evolved 릴리스 24.4R1부터는 이 기능을 지원하는 디바이스에 대해 TWAMP를 사용한 정적 경로 추적을 지원합니다. 자세한 내용은 정적 경로 추적 을 참조하십시오.
플랫폼별 TWAMP 동작
기능 탐색기: 양방향 활성 측정 프로토콜을 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인합니다.
다음 표를 사용하여 플랫폼의 플랫폼별 동작을 검토하십시오.
| 플랫폼 | 의 차이점 |
|---|---|
| ACX 시리즈 |
|
| EX 시리즈 |
제어 클라이언트와 세션 전송자(TWAMP 클라이언트)는 모두 동일한 주니퍼 네트웍스 라우터에 있습니다. 그러나 TWAMP 클라이언트는 서버와 세션 반영자가 동일한 시스템에 있을 것을 요구하지 않습니다. 따라서 주니퍼 TWAMP 클라이언트는 타사 서버 구현과 함께 작동할 수 있습니다. |
| MX 시리즈 |
|
| PTX 시리즈 |
|
| QFX10000 시리즈 |
제어 클라이언트와 세션 전송자(TWAMP 클라이언트)는 모두 동일한 주니퍼 네트웍스 라우터에 있습니다. 그러나 TWAMP 클라이언트는 서버와 세션 반영자가 동일한 시스템에 있을 것을 요구하지 않습니다. 따라서 주니퍼 TWAMP 클라이언트는 타사 서버 구현과 함께 작동할 수 있습니다. |
| QFX5000 시리즈(Junos OS Evolved) |
Junos OS Evolved의 경우, 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은 MPC, MS-MIC/MPC 및 인라인에서 MX 시리즈 TWAMP 및 관련 타임스탬프 지원에 대한 정보를 제공합니다.
| 특징 |
역할 |
IP 버전 |
지원(Y/N) |
타임스탬프 인라인 |
MPC의 타임스탬프(하드웨어 타임스탬프) |
MPC(si-interface)의 타임스탬프 |
MS-MIC/MPC(delegate-probes)의 타임스탬프 |
|---|---|---|---|---|---|---|---|
| TWAMP |
매니지드 클라이언트 |
IPv4 |
Y |
N |
Y(μsec) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
N |
| IPv6 |
N |
N |
N |
N |
N |
||
| 관리 서버 |
IPv4 |
Y |
N |
Y(μsec) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
N |
|
| IPv6 |
N |
N |
N |
N |
N |
| 특징 |
역할 |
IP 버전 |
지원(Y/N) |
타임스탬프 인라인 |
MPC의 타임스탬프(하드웨어 타임스탬프) |
MPC(si-interface)의 타임스탬프 |
MS-MIC/MPC(delegate-probes)의 타임스탬프 |
|---|---|---|---|---|---|---|---|
| TWAMP |
라이트 클라이언트 |
IPv4 |
Y |
Y(μsec)(릴리스 25.4R1부터) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
N |
| IPv6 |
Y |
Y(μsec)(릴리스 25.4R1부터) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
N |
||
| 라이트 서버 |
IPv4 |
Y |
Y(μsec)(릴리스 25.4R1부터) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
N |
|
| IPv6 |
Y |
Y(μsec)(릴리스 25.4R1부터) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
Y(μsec) 최대 1000개 프로브 |
N |