이 페이지의 내용

링크 서비스 인터페이스 개요
링크 서비스 구성 개요
링크 서비스 인터페이스 확인
내부 인터페이스 LSQ-0/0/0 구성 이해
예: 멀티링크 서비스를 위해 ls-0/0/0에서 lsq-0/0/0으로 업그레이드
링크 서비스 인터페이스 문제 해결

링크 서비스 인터페이스 구성

주니퍼 네트웍스 디바이스는 MLPP, MLFR 및 CRTP와 lsq-0/0/0 같은 멀티링크 서비스를 포함하는 링크 서비스 큐잉 인터페이스에서 링크 서비스를 지원합니다. 아래 주제에서는 링크 서비스 개요, 구성 세부 사항 및 SRX 시리즈 방화벽의 링크 서비스 검증에 대해 설명합니다.

링크 서비스 인터페이스 개요

링크 서비스에는 멀티링크 서비스인 MLPPP(Multilink Point-to-Point Protocol), MLFR(Multilink Frame Relay) 및 CRTP(Compressed Real-Time Transport Protocol)가 포함됩니다. 주니퍼 네트웍스 디바이스는 링크 서비스 큐잉 인터페이스에서 링크 서비스를 lsq-0/0/0 지원합니다.

멀티링크 서비스 및 CRTP를 지원하기 위해 주니퍼 네트웍스 디바이스에서 링크 서비스 큐잉 인터페이스(lsq-0/0/0)를 구성합니다.

SRX 시리즈 방화벽의 링크 서비스 큐잉 인터페이스는 주니퍼 네트웍스 M 시리즈 및 T 시리즈 라우팅 플랫폼에서 멀티링크 서비스 인터페이스(), 링크 서비스 인터페이스(ml-fpc/pic/portls-fpc/pic/port) 및 링크 서비스 지능형 큐잉 인터페이스(lsq-fpc/pic/port)가 제공하는 서비스로 구성됩니다. M 시리즈 및 T 시리즈 라우팅 플랫폼의 멀티링크 서비스, 링크 서비스 및 링크 서비스 지능형 큐잉(IQ) 인터페이스는 물리적 인터페이스 카드(PIC)에 설치되지만, SRX 시리즈 방화벽의 링크 서비스 큐잉 인터페이스는 내부 인터페이스일 뿐이며 물리적 매체 또는 물리적 인터페이스 모듈(PIM)과 연결되지 않습니다.

메모:

(ls-fpc/pic/port)는 SRX 시리즈 방화벽에서 지원되지 않습니다.

이 섹션에서는 다음 항목을 다룹니다.

링크 서비스 인터페이스에서 사용 가능한 서비스
링크 서비스 예외
멀티클래스 MLPPP 구성
LFI를 사용한 큐잉
압축된 실시간 전송 프로토콜 개요
포워딩 클래스별 단편화 구성
링크 레이어 오버헤드 구성

링크 서비스 인터페이스에서 사용 가능한 서비스

링크 서비스 인터페이스는 기본적으로 사용할 수 있는 논리적 인터페이스 입니다. 표 1 에는 인터페이스에서 사용할 수 있는 서비스가 요약되어 있습니다.

표 1: 링크 서비스 인터페이스에서 사용 가능한 서비스
서비스	목적	추가 정보
MLPPP 및 MLFR 캡슐화를 통한 멀티링크 번들	여러 구성 링크를 하나의 더 큰 논리적 번들로 통합하여 추가 대역폭, 로드 밸런싱 및 중복성을 제공합니다. 메모: DCAC(Dynamic Call Admission Control) 구성은 링크 서비스 인터페이스에서 지원되지 않습니다.	예: MLPPP 번들 구성 예: 멀티링크 프레임 릴레이 FRF.15 구성 예: 멀티링크 프레임 릴레이 FRF.16 구성
LFI(Link Fragmentation and Interleaving)	큰 데이터 패킷을 분할하고 지연에 민감한 음성 패킷을 작은 패킷과 인터리빙하여 링크의 지연과 지터 를 줄입니다.	링크 단편화 및 인터리빙 구성 이해
CRTP(Compressed Real-Time Transport Protocol)	음성 및 비디오 패킷에서 RTP(Real-Time Transport Protocol)로 인해 발생하는 오버헤드를 줄입니다.	압축된 실시간 전송 프로토콜 개요
CoS(Class-of-Service) 분류자, 포워딩 클래스, 스케줄러 및 스케줄러 맵, 셰이핑 속도	다음과 같이 CoS를 구성하여 지연에 민감한 패킷에 더 높은 우선 순위를 제공합니다. 분류자 - 음성, 데이터 및 네트워크 제어 패킷과 같은 다양한 유형의 트래픽을 분류합니다. 포워딩 클래스 - 서로 다른 유형의 트래픽을 서로 다른 출력 대기열로 보냅니다. 단편화 맵 - 포워딩 클래스와 멀티링크 클래스 간의 매핑, 포워딩 클래스와 프래그먼트 임계값을 정의합니다. 포워딩 클래스 및 멀티링크 클래스 매핑에서 드롭 타임아웃을 구성할 수 있습니다. 스케줄러 및 스케줄러 맵 - 지연 버퍼, 전송 속도 및 전송 우선 순위와 같은 출력 대기열에 대한 속성을 정의합니다. Shaping rate(셰이핑 속도) - 인터페이스별로 특정 대역폭 사용량을 정의합니다.	예: 인터페이스 셰이핑 속도 구성 포워딩 클래스별 단편화 구성

링크 서비스 예외

SRX 시리즈 방화벽에서의 링크 및 멀티링크 서비스 구현은 다음과 같은 예외를 제외하면 M 시리즈 및 T 시리즈 라우팅 플랫폼에서의 구현과 유사합니다.

링크 및 멀티링크 서비스에 대한 지원은 , 및 ls-fpc/pic/port 인터페이스 대신 ml-fpc/pic/port인터페이스에서 이루어집니다lsq-0/0/0. lsq-fpc/pic/port
LFI가 활성화되면 단편화된 패킷은 패킷당 및 단편당 로드 밸런싱을 활성화하기 위해 구성 링크에서 라운드 로빈 방식으로 대기열에 추가됩니다. LFI를 사용한 큐잉을 참조하십시오.
유닛당 스케줄링 지원은 모든 유형의 구성 링크(모든 유형의 인터페이스)에서 이루어집니다.
CRTP(Compressed Real-Time Transport Protocol)에 대한 지원은 MLPPP 및 PPP 모두에 대해 제공됩니다.

멀티클래스 MLPPP 구성

주니퍼 네트웍스 디바이스의 경우 lsq-0/0/0 MLPPP 캡슐화를 통해 멀티클래스 MLPPP를 구성할 수 있습니다. 다중 클래스 MLPPP를 구성하지 않으면 다른 클래스의 조각을 인터리브할 수 없습니다. 단일 패킷의 모든 조각은 다른 패킷의 조각이 전송되기 전에 전송되어야 합니다. 단편화되지 않은 패킷은 다른 패킷의 단편 간에 인터리빙되어 단편화되지 않은 패킷에서 볼 수 있는 대기 시간을 줄일 수 있습니다. 실제로 지연에 민감한 트래픽은 일반 PPP 트래픽으로 캡슐화되고 대량 트래픽은 멀티링크 트래픽으로 캡슐화됩니다. 이 모델은 지연 시간에 민감한 트래픽의 단일 클래스가 있고 대기 시간에 민감한 트래픽보다 우선 순위가 높은 트래픽이 없는 한 작동합니다. 링크 서비스 PIC에서 사용되는 LFI에 대한 이러한 접근 방식은 두 가지 수준의 트래픽 우선 순위만 지원하며, 이는 M 시리즈 및 T 시리즈 라우팅 플랫폼에서 지원하는 4-8개의 포워딩 클래스를 전달하기에 충분하지 않습니다.

멀티클래스 MLPPP를 사용하면 대량 트래픽이 포함된 단일 멀티링크 번들을 통해 전송되는 여러 클래스의 지연 시간에 민감한 트래픽을 가질 수 있습니다. 실제로 멀티클래스 MLPPP는 서로 다른 클래스의 트래픽이 서로 다른 지연 시간을 보장할 수 있도록 합니다. 멀티클래스 MLPPP를 사용하면 각 포워딩 클래스를 별도의 멀티링크 클래스로 매핑하여 우선순위와 지연을 보장할 수 있습니다.

메모:

멀티클래스 MLPPP는 기능의 상위 집합을 나타내므로 동일한 번들에 LFI 및 멀티클래스 MLPPP를 모두 구성할 필요도 없고 지원되지도 않습니다. 멀티클래스 MLPPP를 구성하면 LFI가 자동으로 활성화됩니다.

Junos OS PPP 구현은 주소 필드 압축 및 프로토콜 필드 압축 PPP NCP 옵션의 협상을 지원하지 않으며, 이는 소프트웨어가 항상 전체 4바이트 PPP 헤더를 전송한다는 것을 의미합니다.

멀티클래스 MLPPP의 Junos OS 구현은 공통 헤더 바이트의 압축을 지원하지 않습니다.

다중 클래스 MLPPP는 여러 링크를 사용할 때 발생하는 패킷 순서 문제를 크게 단순화합니다. 멀티클래스 MLPPP가 없으면 단일 플로우에 속하는 모든 음성 트래픽이 단일 링크로 해시되어 패킷 순서 문제를 방지합니다. 멀티클래스 MLPPP를 사용하면 음성 트래픽을 우선 순위가 높은 클래스에 할당하고 여러 링크를 사용할 수 있습니다.

링크 서비스 IQ 인터페이스에서 멀티클래스 MLPPP를 구성하려면 링크가 번들에 가입할 때 협상해야 하는 멀티링크 클래스 수를 지정해야 하며, 포워딩 클래스를 멀티클래스 MLPPP 클래스로 매핑해야 합니다.

링크가 번들에 합류할 때 협상해야 하는 멀티링크 클래스 수를 지정하려면 문을 포함합니다.multilink-max-classes

다음 계층 수준에서 이 문을 포함할 수 있습니다.

[edit interfaces interface-name unit logical-unit-number]
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]

멀티링크 클래스의 수는 1개에서 8개까지 가능합니다. 각 포워딩 클래스에 대한 멀티링크 클래스의 수는 협상할 멀티링크 클래스의 수를 초과해서는 안 됩니다.

포워딩 클래스를 멀티클래스 MLPPP 클래스로 매핑하도록 지정하려면 계층 수준에서 명령문을 포함합니다multilink-class.[edit class-of-service fragmentation-maps forwarding-class class-name]

멀티링크 클래스 인덱스 번호는 0에서 7까지 가능합니다. multilink-class 명령문과 명령문은 no-fragmentation 상호 배타적입니다.

협상된 멀티링크 클래스의 수를 보려면 명령을 실행합니다 show interfaces lsq-0/0/0.logical-unit-number detail .

LFI를 사용한 큐잉

LFI 또는 비 LFI 패킷은 도착하는 대기열을 기반으로 구성 링크의 대기열에 배치됩니다. 단편화, 비단편화 또는 LFI 패킷이 대기열에 있는 동안에는 대기열 번호가 변경되지 않습니다.

예를 들어, 대기열 Q0이 단편화 임계값 128로 구성되고, Q1이 단편화 없이 구성되며, Q2가 단편화 임계값 512로 구성된다고 가정합니다. Q0은 패킷 크기가 512인 트래픽 스트림을 수신하고 있습니다. Q1은 64바이트의 음성 트래픽을 수신하고 Q2는 128바이트 패킷의 트래픽 스트림을 수신합니다. 다음으로, Q0의 스트림이 조각화되어 구성 링크의 Q0으로 대기열에 추가됩니다. 또한 Q2의 모든 패킷은 구성 링크의 Q0에 대기합니다. Q1의 스트림은 단편화가 구성되지 않았기 때문에 LFI로 간주됩니다. Q0 및 Q2의 모든 패킷은 구성 링크의 Q0에 대기됩니다. Q1의 모든 패킷은 구성 링크의 Q2에 대기됩니다.

를 사용하여 lsq-0/0/0LFI 패킷과 비 LFI 패킷에 CRTP를 적용할 수 있습니다. CRTP로 인해 대기열 번호는 변경되지 않습니다.

구성 링크의 Q2에 대한 대기열

멀티링크 번들에서 서비스 등급 을 사용할 때, 멀티링크 번들의 모든 Q2 트래픽은 패킷의 소스 주소, 목적지 주소 및 IP 프로토콜에서 계산된 해시를 기반으로 구성 링크의 Q2로 대기열에 추가됩니다. IP 페이로드가 TCP 또는 UDP 트래픽인 경우 해시에는 원본 포트와 대상 포트도 포함됩니다. 이 해시 알고리즘의 결과로, 하나의 트래픽 플로우에 속하는 모든 트래픽은 하나의 구성 링크의 Q2에 대기됩니다. 구성 링크로의 트래픽 전달 방법은 번들이 LFI로 설정되지 않은 경우를 포함하여 항상 적용됩니다.

압축된 실시간 전송 프로토콜 개요

RTP(Real-Time Transport Protocol)는 네트워크 오디오 및 비디오 애플리케이션의 다양한 구현 간에 상호 운용성을 달성하는 데 도움이 될 수 있습니다. 그러나 경우에 따라 IP, UDP 및 RTP 헤더를 포함하는 헤더가 전화 접속 모뎀과 같은 저속 회선을 사용하는 네트워크에서 너무 클 수 있습니다(약 40바이트). CRTP(Compressed Real-Time Transport Protocol)를 구성하여 저속 링크에서 네트워크 오버헤드를 줄일 수 있습니다. CRTP는 IP, UDP 및 RTP 헤더를 2바이트 컨텍스트 ID(CID)로 대체하여 헤더 오버헤드를 상당히 줄입니다.

그림 1 은 CRTP가 40바이트 헤더를 2바이트 헤더로 줄여 음성 패킷에서 RTP 헤더를 압축하는 방법을 보여줍니다.

그림 1: CRTP CRTP

링크 서비스 인터페이스에서 MLPPP 또는 PPP 논리적 인터페이스 캡슐화를 사용하여 CRTP를 구성할 수 있습니다. 예: MLPPP 번들 구성을 참조하십시오.

실시간 및 비실시간 데이터 프레임은 실시간 트래픽에 과도한 지연을 일으키지 않고 저속 링크에서 함께 전송됩니다. 링크 단편화 및 인터리빙 구성 이해하기를 참조하십시오.

포워딩 클래스별 단편화 구성

의 lsq-0/0/0 경우, 특정 포워딩 클래스에 대한 단편화 속성을 지정할 수 있습니다. 각 포워딩 클래스의 트래픽은 멀티링크 캡슐화(단편화 및 시퀀싱) 또는 캡슐화되지 않은(단편화 없이 해시됨)일 수 있습니다. 기본적으로 모든 포워딩 클래스의 트래픽은 멀티링크 캡슐화됩니다.

MLPPP 인터페이스의 대기열에 대한 단편화 속성을 구성하지 않는 경우, 계층 수준에서 설정하는 [edit interfaces interface-name unit logical-unit-number fragment-threshold] 단편화 임계값은 MLPPP 인터페이스 내의 모든 포워딩 클래스에 대한 단편화 임계값입니다. MLFR FRF.16 인터페이스의 경우, 계층 수준에서 설정하는 [edit interfaces interface-name mlfr-uni-nni-bundle-options fragment-threshold] 단편화 임계값은 MLFR FRF.16 인터페이스 내의 모든 포워딩 클래스에 대한 단편화 임계값입니다.

구성의 아무 곳에서나 최대 프래그먼트 크기를 설정하지 않은 경우, 패킷이 번들의 모든 링크 중 최소 최대 전송 단위(MTU) 또는 최대 수신 재구성 단위(MRRU)를 초과하면 패킷이 여전히 단편화됩니다. 캡슐화되지 않은 플로우는 하나의 링크만 사용합니다. 플로우가 단일 링크를 초과하는 경우, 패킷 크기가 MTU/MRRU를 초과하지 않는 한 포워딩 클래스는 멀티링크 캡슐화되어야 합니다.

구성의 어느 곳에서나 최대 단편화 크기를 설정하지 않더라도 또는 [edit interfaces interface-name mlfr-uni-nni-bundle-options] 계층 수준에서 mrru 문을 포함하여 MRRU를 [edit interfaces lsq-0/0/0 unit logical-unit-number] 구성할 수 있습니다. MRRU는 최대 전송 단위(MTU)와 유사하지만 링크 서비스 인터페이스에 특정합니다. 기본적으로 MRRU 크기는 1504바이트이며 1500바이트에서 4500바이트까지 구성할 수 있습니다.

대기열에서 단편화 속성을 구성하려면 계층 수준에서 명령문을 [edit class-of-service] fragmentation-maps 포함합니다.

포워딩 클래스별 단편화 임계값을 설정하려면 단편화 맵에 명령문을 포함합니다 fragment-threshold . 이 문은 각 멀티링크 프래그먼트의 최대 크기를 설정합니다.

대기열의 트래픽을 멀티링크 캡슐화가 아닌 캡슐화되지 않도록 설정하려면 단편화 맵에 명령문을 포함합니다 no-fragmentation . 이 문은 이 대기열에서 수신된 패킷에 추가 단편화 헤더가 추가되지 않고 정적 링크 로드 밸런싱을 사용하여 순차적 패킷 전달을 보장하도록 지정합니다.

지정된 포워딩 클래스에 대해 또는 no-fragmentation 문 중 하나를 fragment-threshold 포함할 수 있습니다. 두 문은 상호 배타적입니다.

명령문을 사용하여 multilink-class 포워딩 클래스를 멀티클래스 MLPPP에 매핑합니다. 지정된 포워딩 클래스에 대해 또는 no-fragmentation 문 중 하나를 multilink-class 포함할 수 있습니다. 두 문은 상호 배타적입니다.

단편화 맵을 멀티링크 PPP 인터페이스 또는 MLFR FRF.16 DLCI와 연결하려면 계층 수준에서 문을 [edit class-of-service interfaces interface-name unit logical-unit-number] 포함합니다fragmentation-map.

링크 레이어 오버헤드 구성

링크 레이어 오버헤드는 시리얼 링크의 비트 스터핑으로 인해 구성 링크에서 패킷 드롭을 일으킬 수 있습니다. 비트 스터핑은 데이터가 제어 정보로 해석되는 것을 방지하는 데 사용됩니다.

기본적으로 총 번들 대역폭의 4%는 링크 레이어 오버헤드를 위해 따로 할당됩니다. 대부분의 네트워크 환경에서 평균 링크 레이어 오버헤드는 1.6%입니다. 따라서 안전 장치로 4%를 권장합니다.

주니퍼 네트웍스 디바이스의 경우 lsq-0/0/0 , 링크 레이어 오버헤드를 위해 따로 설정할 번들 대역폭의 백분율을 구성할 수 있습니다. 이를 위해 link-layer-overhead 문을 포함합니다.

다음 계층 수준에서 이 문을 포함할 수 있습니다.

[edit interfaces interface-name mlfr-uni-nni-bundle-options]
[edit interfaces interface-name unit logical-unit-number]
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]

0%에서 50%까지 값을 구성할 수 있습니다.

링크 서비스 구성 개요

시작하기 전에:

장치 하드웨어를 설치합니다.
기본 연결을 설정합니다. 장치에 대한 시작 가이드를 참조하십시오.
물리적 및 논리적 인터페이스와 주니퍼 네트웍스 인터페이스 규칙에 대한 기본적인 이해가 있어야 합니다. 인터페이스 이해를 참조하십시오

네트워크에서 링크 서비스 인터페이스를 사용하는 방법을 계획합니다. 링크 서비스 인터페이스 개요를 참조하십시오.

인터페이스에서 링크 서비스를 구성하려면 다음 작업을 수행합니다.

LFI(Link Fragmentation and Interleaving)를 구성합니다. 예: 링크 단편화 및 인터리빙 구성을 참조하십시오.
분류자 및 포워딩 클래스를 구성합니다. 예: 분류자 및 포워딩 클래스 정의를 참조하십시오.
스케줄러 맵을 구성합니다. 스케줄러 맵 정의 및 적용 방법 이해하기를 참조하십시오.
인터페이스 셰이핑 속도를 구성합니다. 예: 인터페이스 셰이핑 속도 구성
MLPPP 번들을 구성합니다. 예: MLPPP 번들 구성을 참조하십시오.
MLFR을 구성하려면 예: 멀티링크 프레임 릴레이 FRF.15 구성 또는 예: 멀티링크 프레임 릴레이 FRF.16 구성을 참조하십시오.
CRTP 를 구성하려면 예: 압축된 실시간 전송 프로토콜 구성을 참조하십시오.

링크 서비스 인터페이스 확인

구성이 올바르게 작동하고 있는지 확인합니다.

링크 서비스 인터페이스 통계 확인
링크 서비스 CoS 구성 확인

목적

링크 서비스 인터페이스 통계를 확인합니다.

행동

이 섹션에서 제공하는 샘플 출력은 예: MLPPP 번들 구성에 제공된 구성을 기반으로 합니다. 구성 링크가 번들에 올바르게 추가되고 패킷이 올바르게 단편화 및 전송되는지 확인하려면 다음 작업을 수행합니다.

디바이스 R0 및 디바이스 R1에서 이 예에서 사용된 두 디바이스는 예: MLPPP 번들 구성에 설명된 대로 MLPPP 및 LFI를 구성합니다.
CLI에서 명령을 입력하여 ping R0과 R1 사이에 연결이 설정되었는지 확인합니다.
R0에서 R1까지 각각 200바이트씩 10개의 데이터 패킷을 전송합니다.
R0의 CLI에서 명령을 입력합니다 show interfaces interface-name statistics .

이 출력은 인터페이스 정보의 요약을 보여줍니다. 다음 정보를 확인합니다.

Physical interface- 물리적 인터페이스는 Enabled입니다. 인터페이스가 로 표시되면 다음 중 하나를 수행합니다.Disabled
- CLI 구성 편집기에서 구성 계층 수준의 문을 [edit interfaces interface-name] 삭제합니다disable.
- J-Web 구성 편집기에서 페이지의 확인란을 Interfaces>interface-name 지웁니다Disable.
Physical link- 물리적 링크는 Up입니다. 의 링크 상태는 Down 인터페이스 모듈, 인터페이스 포트 또는 물리적 연결에 문제가 있음을 나타냅니다(링크 레이어 오류).
Last flappedLast Flapped- 시간은 예상 값입니다. Last Flapped 시간은 물리적 인터페이스를 마지막으로 사용할 수 없게 되었다가 다시 사용할 수 있게 된 시간을 나타냅니다. 예기치 않은 플래핑은 링크 레이어 오류일 가능성이 있음을 나타냅니다.
Traffic statistics- 인터페이스에서 수신 및 전송된 바이트 및 패킷 수와 속도. 인바운드 및 아웃바운드 바이트와 패킷 수가 물리적 인터페이스의 예상 처리량과 일치하는지 확인합니다. 통계를 지우고 새 변경 사항만 보려면 명령을 사용합니다 clear interfaces statistics interface-name .
Queue counters- 대기열의 이름과 수는 구성된 대로입니다. 이 샘플 출력은 10개의 데이터 패킷이 전송되었고 어떤 패킷도 손실되지 않았음을 보여줍니다.
Logical interface—구성한 멀티링크 번들의 이름—lsq-0/0/0.0.
Bundle options- 단편화 임계값이 올바르게 구성되고 단편 인터리빙이 활성화됩니다.
Bundle errors- 번들에 의해 삭제된 모든 패킷 및 조각.
Statistics- 프래그먼트 및 패킷이 디바이스에 의해 올바르게 수신 및 전송됩니다. 트래픽 방향(입력 또는 출력)에 대한 모든 참조는 디바이스와 관련하여 정의됩니다. 디바이스가 수신한 입력 조각은 입력 패킷으로 어셈블됩니다. 출력 패킷은 디바이스 외부로 전송하기 위해 출력 조각으로 분할됩니다.

이 예에서는 200바이트의 데이터 패킷 10개가 전송되었습니다. 단편화 임계값이 128바이트로 설정되었기 때문에 모든 데이터 패킷이 두 개의 단편으로 단편화되었습니다. 샘플 출력은 10개의 패킷과 20개의 프래그먼트가 올바르게 전송되었음을 보여줍니다.
Link- 구성 링크가 이 번들에 추가되고 프래그먼트 및 패킷을 올바르게 수신 및 전송하고 있습니다. 구성 링크에서 전송되는 결합된 프래그먼트 수는 번들에서 전송된 프래그먼트 수와 같아야 합니다. 이 샘플 출력은 번들이 20개의 프래그먼트와 2개의 구성 링크 se-1/0/0.0 및 se-1/0/1.0.0 올바르게 전송된 10+10=20 프래그먼트를 전송했음을 보여줍니다.
Destination 및 Local—멀티링크 번들의 원격 측 및 멀티링크 번들의 로컬 측의 IP 주소. 이 샘플 출력은 대상 주소가 R1의 주소이고 로컬 주소가 R0의 주소임을 보여줍니다.

링크 서비스 CoS 구성 확인

목적
행동

목적

링크 서비스 인터페이스에서 CoS 구성을 확인합니다.

행동

CLI에서 다음 명령을 입력합니다.

show class-of-service interface interface-name
show class-of-service classifier name classifier-name
show class-of-service scheduler-map scheduler-map-name

이 섹션에서 제공하는 샘플 출력은예: MLPPP 번들 구성에 제공된 구성을 기반으로 합니다.

이 출력 예는 구성된 CoS 구성 요소의 요약을 보여줍니다. 다음 정보를 확인합니다.

Logical Interface- 멀티링크 번들 및 번들에 적용된 CoS 구성 요소의 이름입니다. 샘플 출력은 멀티링크 번들이 lsq-0/0/0.0이고 CoS 스케줄러 매핑 s_map 이 적용되었음을 보여줍니다.
Classifier—분류자에 할당된 코드 포인트, 포워딩 클래스 및 손실 우선순위. 샘플 출력은 기본 분류자 ipprec-compatibility이(가) 인터페이스에 적용 lsq-0/0/0 되었고 분류자가 classify_input 인터페이스에 적용 ge-0/0/1 되었음을 보여줍니다.
Scheduler- 각 스케줄러에 할당된 전송 속도, 버퍼 크기, 우선순위 및 손실 우선순위. 샘플 출력에는 데이터, 음성 및 네트워크 제어 스케줄러가 구성된 모든 값과 함께 표시됩니다.

내부 인터페이스 LSQ-0/0/0 구성 이해

링크 서비스 인터페이스는 내부 인터페이스 전용입니다. 물리적 매체 또는 PIM과 관련이 없습니다. SRX 시리즈 방화벽 내에서 패킷은 링크 묶음 또는 압축을 위해 이 인터페이스로 라우팅됩니다.

더 이상 사용되지 않는 ls-0/0/0 대신 내부 인터페이스 lsq-0/0/0을 링크 서비스 큐잉 인터페이스로 사용하도록 구성을 업그레이드해야 할 수도 있습니다. 수정된 구성을 롤백하여 ls-0/0/0을 사용할 수도 있습니다.

예: 멀티링크 서비스를 위해 ls-0/0/0에서 lsq-0/0/0으로 업그레이드

이 예는 멀티링크 서비스에 대해 ls-0/0/0에서 lsq-0/0/0으로 업그레이드하는 방법(또는 변경 사항을 되돌리는 방법)을 보여줍니다.

요구 사항
개요
구성
확인

요구 사항

이 절차는 lsq-/0/0/0 대신 ls-0/0/0을 계속 사용하거나 이전 인터페이스로 되돌려야 하는 경우에만 필요합니다.

개요

이 예에서는 링크 서비스 내부 인터페이스의 이름을 ls-0/0/0에서 lsq-0/0/0으로 또는 그 반대로 바꿉니다. 구성에서 모든 ls-0/0/0의 이름을 lsq-0/0/0으로 바꾸고 단편화를 추가하지 않음으로써 단편화 맵을 구성합니다. 대기열 2의 이름 뒤에, 대기열 2가 구성된 경우 또는 확실한 전달 후에 단편화를 지정하지 않습니다. 그런 다음 이전 단계에서 구성한 단편화 맵을 lsq-0/0/0에 연결하고 인터리브 조각이 구성된 멀티링크 번들의 단위 번호를 6으로 지정합니다.

그런 다음 구성을 lsq-0/0/0에서 ls-0/0/0으로 롤백합니다. 구성의 모든 발생 항목을 lsq-0/0/0에서 ls-0/0/0으로 바꿉니다. 단편화 맵이 [class-of-service] 계층에 구성된 경우 삭제하고, 단편화 맵이 lsq-0/0/0에 할당된 경우 삭제합니다. [interfaces] 계층에서 lsq-0/0/0에 대해 구성된 경우 multilink-max-classes를 삭제할 수 있습니다. 그런 다음 [interfaces] 계층에서 lsq-0/0/0에 대해 구성된 경우 link-layer-overhead를 삭제합니다.

포워딩 클래스에서 단편화가 구성되지 않고 단편화 맵이 lsq-0/0/0에 할당된 경우, ls-0/0/0 인터페이스에 대한 인터리브 단편을 구성합니다. 마지막으로, 대기열 2를 참조하도록 LFI 패킷에 대한 분류자를 구성합니다. (ls-0/0/0 인터페이스는 대기열 2를 LFI 대기열로 취급합니다.)

구성

절차

CLI 빠른 구성
단계별 절차
결과

CLI 빠른 구성

ls-0/0/0에서 lsq-0/0/0으로 신속하게 업그레이드하려면(또는 변경 사항을 되돌리려면) 다음 명령을 복사하여 CLI에 붙여넣습니다.

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 이 작업을 수행하는 방법에 대한 지침은 구성 모드에서 CLI 편집기 사용을 참조하십시오.

ls-0/0/0에서 lsq-0/0/0으로 업그레이드하거나 해당 변경 사항을 되돌리려면:

구성에서 ls-0/0/0의 모든 발생의 이름을 바꿉니다.

단편화 맵을 구성합니다.

멀티링크 번들의 유닛 번호를 지정합니다.

구성의 모든 발생에 대해 구성을 롤백합니다.

서비스 등급에서 단편화 맵을 삭제합니다.

단편화 맵이 lsq-0/0/0 인터페이스에 할당된 경우 삭제합니다.

lsq-0/0/0에 대해 구성된 경우 멀티링크 최대 클래스를 삭제합니다.

메모:
multilink-max-classes는 지원되지 않으며 구성되지 않았을 가능성이 높습니다.
lsq-0/0/0에 대해 구성된 경우 link-layer-overhead를 삭제합니다.

lsq-0/0/0:0에 대해 구성된 경우 link-layer-overhead를 삭제합니다.

ls-0/0/0 인터페이스에 대한 인터리브 조각을 구성합니다.

결과

구성 모드에서 명령을 입력하여 show class-of-service 구성을 확인합니다. 출력이 의도한 구성을 표시하지 않으면, 이 예의 구성 지침을 반복하여 수정합니다.

디바이스 구성을 마쳤으면 구성 모드에서 을 입력합니다 commit .

확인

구성이 올바르게 작동하고 있는지 확인합니다.

링크 서비스 내부 인터페이스 ls-0/0/0 - lsq-0/0/0 확인

목적
행동

목적

링크 서비스 내부 인터페이스 ls-0/0/0이 lsq-0/0/0으로 변경되었는지 확인합니다.

행동

운영 모드에서 명령을 입력합니다 show class-of-service .

링크 서비스 인터페이스 문제 해결

링크 서비스 인터페이스에서 구성 문제를 해결하려면:

구성 링크에 적용되는 CoS 구성 요소 결정
멀티링크 번들에서 지터 및 지연의 원인 파악
LFI 및 로드 밸런싱이 올바르게 작동하는지 확인
주니퍼 네트웍스 디바이스와 타사 디바이스 간의 PVC에서 패킷이 손실되는 이유 확인

구성 링크에 적용되는 CoS 구성 요소 결정

문제
용액

문제

묘사

멀티링크 번들을 구성하고 있지만, MLPPP 캡슐화가 없는 트래픽이 멀티링크 번들의 구성 링크를 통과합니다. 모든 CoS 구성 요소를 구성 링크에 적용합니까, 아니면 멀티링크 번들에 충분히 적용하고 있습니까?

용액

스케줄러 맵을 멀티링크 번들 및 해당 구성 링크에 적용할 수 있습니다. 스케줄러 맵을 사용하여 여러 CoS 구성 요소를 적용할 수 있지만 필요한 것만 구성합니다. 불필요한 전송 지연을 방지하기 위해 구성 링크의 구성을 단순하게 유지하는 것이 좋습니다.

표 2 에는 멀티링크 번들 및 해당 구성 링크에 적용될 CoS 구성 요소가 나와 있습니다.

표 2: 멀티링크 번들 및 구성 링크에 적용된 CoS 구성 요소
CoS 구성 요소	멀티링크 번들	구성 링크	설명
분류자	예	아니요	CoS 분류는 전송 측이 아닌 인터페이스의 수신 측에서 이루어지므로 구성 링크에 분류자가 필요하지 않습니다.
포워딩 클래스	예	아니요	포워딩 클래스는 대기열과 연결되며, 대기열은 스케줄러 맵에 의해 인터페이스에 적용됩니다. 대기열 할당은 구성 링크에서 미리 결정됩니다. 멀티링크 번들의 Q2에 있는 모든 패킷은 구성 링크의 Q2에 할당되고 다른 모든 대기열의 패킷은 구성 링크의 Q0에 대기됩니다.
스케줄러 맵	예	예	다음과 같이 멀티링크 번들 및 구성 링크에 스케줄러 맵을 적용합니다. 전송 속도 - Q0 및 Q2에 구성된 전송 속도의 상대적 순서가 멀티링크 번들과 같이 구성 링크에서 동일한지 확인합니다. 스케줄러 우선 순위 - Q0 및 Q2에 구성된 스케줄러 우선 순위의 상대적 순서가 멀티링크 번들과 동일한 구성 링크에서 동일한지 확인합니다. 버퍼 크기 - 멀티링크 번들의 모든 비 LFI 패킷이 구성 링크의 Q0에서 전송되므로, 구성 링크의 Q0에 있는 버퍼 크기가 충분히 큰지 확인합니다. RED 드롭 프로파일 - 멀티링크 번들에서만 RED 드롭 프로파일을 구성합니다. 구성 링크에 RED 드롭 프로파일을 구성하면 버퍼 크기를 변경하고 변동을 도입하는 역 압력 메커니즘이 적용됩니다. 이 동작으로 인해 구성 링크에 조각 드롭이 발생할 수 있으므로 RED 드롭 프로필을 구성 링크의 기본 설정으로 유지해야 합니다.
유닛당 스케줄러 또는 인터페이스 수준 스케줄러의 셰이핑 속도	아니요	예	단위당 스케줄링은 엔드포인트에서만 적용되므로, 이 셰이핑 속도를 구성 링크에만 적용합니다. 앞서 적용된 모든 구성은 구성 링크 구성으로 덮어씁니다.
정확한 전송 속도 또는 대기열 수준 셰이핑	예	아니요	구성 링크에 적용된 인터페이스 수준 셰이핑은 대기열의 모든 셰이핑보다 우선합니다. 따라서 멀티링크 번들에만 전송 속도 정확한 쉐이핑을 적용합니다.
규칙 다시 작성	예	아니요	재작성 비트는 단편화 중에 패킷에서 단편으로 자동으로 복사됩니다. 따라서 멀티링크 번들에서 구성한 내용은 단편에서 구성 링크로 전달됩니다.
가상 채널 그룹	예	아니요	가상 채널 그룹은 멀티링크 번들 이전의 패킷에만 적용되는 방화벽 필터 규칙을 통해 식별됩니다. 따라서 구성 링크에 가상 채널 그룹 구성을 적용할 필요가 없습니다.

멀티링크 번들에서 지터 및 지연의 원인 파악

문제
용액

문제

묘사

지터와 지연 시간을 테스트하려면 IP 패킷 스트림 3개를 보냅니다. 모든 패킷의 IP 우선 순위 설정은 동일합니다. LFI 및 CRTP를 구성한 후에는 혼잡하지 않은 링크에서도 지연 시간이 증가했습니다. 지터와 지연 시간을 줄이려면 어떻게 해야 할까요?

용액

지터와 지연 시간을 줄이려면 다음을 수행합니다.

각 구성 링크에서 셰이핑 속도를 구성했는지 확인합니다.
링크 서비스 인터페이스에서 셰이핑 속도를 구성하지 않았는지 확인합니다.
구성된 셰이핑 속도 값이 물리적 인터페이스 대역폭과 동일한지 확인합니다.
셰이핑 속도가 올바르게 구성되었는데도 지터가 지속되면 주니퍼 네트웍스 기술 지원 센터(JTAC)에 문의하십시오.

LFI 및 로드 밸런싱이 올바르게 작동하는지 확인

문제
용액

문제

묘사

이 경우 여러 서비스를 지원하는 단일 네트워크가 있습니다. 네트워크는 데이터 및 지연에 민감한 음성 트래픽을 전송합니다. MLPPP 및 LFI를 구성한 후, 지연과 지터가 거의 없이 음성 패킷이 네트워크를 통해 전송되는지 확인합니다. 음성 패킷이 LFI 패킷으로 처리되고 로드 밸런싱이 올바르게 수행되는지 어떻게 알 수 있습니까?

용액

LFI가 활성화되면 데이터(비 LFI) 패킷이 MLPPP 헤더로 캡슐화되고 지정된 크기의 패킷으로 단편화됩니다. LFI(Delay-Sensitive, Voice) 패킷은 PPP로 캡슐화되어 데이터 패킷 조각 사이에 인터리브됩니다. 대기열 및 로드 밸런싱은 LFI 패킷과 비 LFI 패킷에 대해 다르게 수행됩니다.

LFI가 올바르게 수행되는지 확인하려면 패킷이 구성된 대로 단편화되고 캡슐화되는지 확인합니다. 패킷이 LFI 패킷으로 처리되는지 또는 비 LFI 패킷으로 처리되는지 확인한 후 로드 밸런싱이 올바르게 수행되는지 확인할 수 있습니다.

Solution Scenario—두 개의 주니퍼 네트웍스 디바이스 R0 및 R1이 두 개의 시리얼 링크 se-1/0/0 및 se-1/0/1를 통합하는 멀티링크 번들 lsq-0/0/0.0 로 연결되어 있다고 가정해 보겠습니다. R0 및 R1에서 MLPPP 및 LFI는 링크 서비스 인터페이스에서 활성화되고 단편화 임계값은 128바이트로 설정됩니다.

이 예에서는 패킷 생성기를 사용하여 음성 및 데이터 스트림을 생성했습니다. 패킷 캡처 기능을 사용하여 수신 인터페이스에서 패킷을 캡처하고 분석할 수 있습니다.

다음 두 데이터 스트림이 멀티링크 번들로 전송되었습니다.

200바이트의 데이터 패킷 100개(단편화 임계값보다 큼)
60바이트의 데이터 패킷 500개(단편화 임계값보다 작음)

다음 두 개의 음성 스트림이 멀티링크 번들로 전송되었습니다.

소스 포트 100에서 200바이트의 음성 패킷 100개
소스 포트 200에서 200바이트의 음성 패킷 300개

LFI 및 로드 밸런싱이 올바르게 수행되는지 확인하려면,

메모:

이 예에서는 명령 출력의 중요한 부분만 표시되고 설명됩니다.

패킷 단편화를 확인합니다. 운영 모드에서 명령을 입력하여 show interfaces lsq-0/0/0 큰 패킷이 올바르게 조각화되었는지 확인합니다.

Meaning- 출력은 멀티링크 번들에서 디바이스를 전송하는 패킷의 요약을 보여줍니다. 멀티링크 번들에 대한 다음 정보를 확인합니다.

총 전송 패킷 수 = 1000
총 통과 조각 수=1100
단편화된 데이터 패킷 수 = 100

멀티링크 번들에서 전송된 총 패킷 수(600 + 400)는 전송 패킷 수(1000)와 일치하여 손실된 패킷이 없음을 나타냅니다.

전송 프래그먼트 수는 전송 패킷 수를 100배 초과하여 100개의 대용량 데이터 패킷이 올바르게 프래그먼트화되었음을 나타냅니다.

Corrective Action- 패킷이 올바르게 단편화되지 않은 경우, 단편화 임계값 구성을 확인합니다. 지정된 단편화 임계값보다 작은 패킷은 단편화되지 않습니다.

패킷 캡슐화를 확인합니다. 패킷이 LFI 또는 비 LFI 패킷으로 취급되는지 확인하려면 캡슐화 유형을 결정합니다. LFI 패킷은 PPP로 캡슐화되며, 비 LFI 패킷은 PPP와 MLPPP로 캡슐화됩니다. PPP 및 MLPPP 캡슐화는 서로 다른 오버헤드를 가지므로 패킷 크기가 다릅니다. 패킷 크기를 비교하여 캡슐화 유형을 결정할 수 있습니다.

단편화되지 않은 작은 데이터 패킷에는 PPP 헤더와 단일 MLPPP 헤더가 포함됩니다. 큰 단편화된 데이터 패킷에서 첫 번째 단편에는 PPP 헤더와 MLPPP 헤더가 포함되지만 연속된 단편에는 MLPPP 헤더만 포함됩니다.

PPP 및 MLPPP 캡슐화는 패킷에 다음과 같은 바이트 수를 추가합니다.

PPP 캡슐화는 7바이트를 추가합니다.

4바이트의 헤더+2바이트의 FCS(Frame Check Sequence)+유휴 상태이거나 플래그를 포함하는 1바이트
MLPPP 캡슐화는 6바이트에서 8바이트 사이를 추가합니다.

4바이트의 PPP 헤더+2 - 4바이트의 멀티링크 헤더

그림 2 는 PPP 및 MLPPP 헤더에 추가된 오버헤드를 보여줍니다.

그림 2: PPP 및 MLPPP 헤더 PPP and MLPPP Headers

CRTP 패킷의 경우, 캡슐화 오버헤드와 패킷 크기는 LFI 패킷보다 훨씬 작습니다. 자세한 내용은 예: 압축된 실시간 전송 프로토콜 구성을 참조하십시오.

표 3 은 각각 70바이트의 데이터 패킷과 음성 패킷에 대한 캡슐화 오버헤드를 보여줍니다. 캡슐화 후 데이터 패킷의 크기는 음성 패킷의 크기보다 큽니다.

표 3: PPP 및 MLPPP 캡슐화 오버헤드
패킷 유형	캡슐화	초기 패킷 크기	캡슐화 오버헤드	캡슐화 후의 패킷 크기
음성 패킷(LFI)	증권 시세 표시기	70바이트	4 + 2 + 1 = 7바이트	77 바이트
짧은 시퀀스의 데이터 조각(비 LFI)	메이저리그PPP	70바이트	4 + 2 + 1 + 4 + 2 = 13바이트	83바이트
긴 시퀀스의 데이터 조각(비 LFI)	메이저리그PPP	70바이트	4 + 2 + 1 + 4 + 4 = 15바이트	85바이트

운영 모드에서 명령을 입력하여 show interfaces queue 각 대기열에서 전송된 패킷의 크기를 표시합니다. 전송된 바이트 수를 패킷 수로 나누어 패킷 크기를 구하고 캡슐화 유형을 결정합니다.

로드 밸런싱을 확인합니다. 운영 모드에서 멀티링크 번들 및 해당 구성 링크에 명령을 입력하여 show interfaces queue 패킷에 대해 로드 밸런싱이 적절하게 수행되는지 확인합니다.

Meaning- 이러한 명령의 출력은 링크 서비스 인터페이스 및 해당 구성 링크의 각 대기열에서 전송 및 대기열에 있는 패킷을 보여줍니다. 표 4 는 이러한 값의 요약을 보여줍니다. (전송된 패킷 수가 모든 링크의 대기열 패킷 수와 같기 때문에 이 테이블에는 대기열에 있는 패킷만 표시됩니다.)

표 4: 대기열에서 전송된 패킷 수
대기열에 있는 패킷	번들 lsq-0/0/0.0	구성 링크 se-1/0/0	구성 링크 se-1/0/1	설명
Q0의 패킷	600	350	350	구성 링크를 통과하는 총 패킷 수(350+350 = 700)가 멀티링크 번들에서 대기 중인 패킷 수(600)를 초과했습니다.
Q2의 패킷	400	100	300	구성 링크를 통과하는 총 패킷 수는 번들의 패킷 수와 같습니다.
Q3의 패킷	0	19	18	구성 링크의 Q3을 통과하는 패킷은 구성 링크 간에 교환되는 keepalive 메시지를 위한 것입니다. 따라서 번들의 Q3에는 패킷이 계산되지 않았습니다.

멀티링크 번들에서 다음을 확인합니다.

대기열에 있는 패킷 수는 전송된 패킷 수와 일치합니다. 숫자가 일치하면 패킷이 삭제되지 않은 것입니다. 전송된 패킷보다 대기열에 더 많은 패킷이 있는 경우 버퍼가 너무 작기 때문에 패킷이 손실되었습니다. 구성 링크의 버퍼 크기는 출력 단계에서 혼잡을 제어합니다. 이 문제를 해결하려면 구성 링크의 버퍼 크기를 늘려야 합니다.
Q0(600)을 전송하는 패킷 수는 멀티링크 번들에서 수신된 크고 작은 데이터 패킷 수(100+500)와 일치합니다. 숫자가 일치하면 모든 데이터 패킷이 Q0을 올바르게 전송한 것입니다.
멀티링크 번들(400)에서 Q2를 전송하는 패킷 수는 멀티링크 번들에서 수신된 음성 패킷의 수와 일치합니다. 숫자가 일치하면 모든 음성 LFI 패킷이 Q2를 올바르게 전송합니다.

구성 링크에서 다음을 확인합니다.

Q0을 전송하는 총 패킷 수(350+350)는 데이터 패킷 및 데이터 조각 수(500+200)와 일치합니다. 숫자가 일치하면 단편화 후의 모든 데이터 패킷이 구성 링크의 Q0을 올바르게 전송합니다.

패킷이 두 구성 링크를 모두 전송하여 비 LFI 패킷에서 로드 밸런싱이 올바르게 수행되었음을 나타냅니다.
구성 링크에서 Q2(300+100)를 전송하는 총 패킷 수는 멀티링크 번들에서 수신된 음성 패킷 수(400)와 일치합니다. 숫자가 일치하면 모든 음성 LFI 패킷이 Q2를 올바르게 전송합니다.

전송된 se-1/0/0소스 포트 100 의 LFI 패킷 및 전송된 소스 포트 200 se-1/0/1의 LFI 패킷 . 따라서 모든 LFI(Q2) 패킷은 소스 포트를 기반으로 해시되었으며 두 구성 링크를 모두 올바르게 전송했습니다.

Corrective Action- 패킷이 하나의 링크만 전송한 경우 다음 단계를 수행하여 문제를 해결합니다.

물리적 링크가 (작동) 또는 down (사용할 수 없음)인지 up 확인합니다. 사용할 수 없는 링크는 PIM, 인터페이스 포트 또는 물리적 연결에 문제가 있음을 나타냅니다(링크 레이어 오류). 링크가 작동하면 다음 단계로 이동합니다.
비 LFI 패킷에 대해 분류자가 올바르게 정의되어 있는지 확인합니다. 비 LFI 패킷이 Q2까지 대기열에 추가되도록 구성되지 않았는지 확인합니다. Q2까지 대기열에 있는 모든 패킷은 LFI 패킷으로 처리됩니다.
LFI 패킷에서 소스 주소, 대상 주소, IP 프로토콜, 소스 포트 또는 대상 포트 값 중 하나 이상이 다른지 확인합니다. 모든 LFI 패킷에 대해 동일한 값이 구성된 경우, 패킷은 모두 동일한 플로우로 해시되고 동일한 링크를 전송합니다.

결과를 사용하여 부하 분산을 확인합니다.

주니퍼 네트웍스 디바이스와 타사 디바이스 간의 PVC에서 패킷이 손실되는 이유 확인

문제
용액

문제

묘사

주니퍼 네트웍스 디바이스와 타사 디바이스의 T1, E1, T3 또는 E3 인터페이스 간에 영구 가상 회로(PVC)를 구성하고 있는데 패킷이 손실되고 ping이 실패합니다.

용액

타사 디바이스가 주니퍼 네트웍스 디바이스와 동일한 FRF.12를 지원하지 않거나 다른 방식으로 FRF.12를 지원하는 경우, PVC의 주니퍼 네트웍스 디바이스 인터페이스는 FRF.12 헤더가 포함된 단편화된 패킷을 폐기하고 이를 "폴리싱된 폐기"로 간주할 수 있습니다.

해결 방법으로, 두 피어 모두에서 멀티링크 번들을 구성하고 멀티링크 번들에서 단편화 임계값을 구성합니다.