이 페이지의 내용

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

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

주니퍼 네트웍스 디바이스는 MLPP, MLFR 및 CRTP와 같은 멀티링크 서비스를 포함하는 링크 서비스 대기열 인터페이스에서 lsq-0/0/0 링크 서비스를 지원합니다. 아래 주제에서는 링크 서비스의 개요, 구성 세부 정보 및 링크 서비스 확인에 대해 설명합니다.

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

링크 서비스에는 멀티링크 서비스인 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)를 구성합니다.

링크 서비스 큐잉 인터페이스는 멀티링크 서비스 인터페이스(ml-fpc/pic/port ), 링크 서비스 인터페이스(ls-fpc/pic/port ) 및 링크 서비스 지능형 큐잉 인터페이스(lsq-fpc/pic/port )의 인터페이스에서 제공하는 서비스로 구성됩니다. 멀티링크 서비스, 링크 서비스 및 링크 서비스 지능형 큐잉(IQ) 인터페이스가 물리적 인터페이스 카드(PIC)에 설치되지만, 링크 서비스 큐잉 인터페이스는 내부 인터페이스일 뿐이며 물리적 매체 또는 물리적 인터페이스 모듈 (PIM)과 연결되지 않습니다.

메모:

(ls-fpc/pic/port )는 지원되지 않습니다.

이 섹션에서는 다음과 같은 주제를 다룹니다.

링크 서비스 인터페이스에서 사용할 수 있는 서비스
링크 서비스 예외
멀티클래스 MLPPP 구성
LFI를 사용한 큐잉
Compressed Real-Time Transport Protocol 개요
포워딩 클래스에 의한 단편화 구성
링크 레이어 오버헤드 구성

링크 서비스 인터페이스에서 사용할 수 있는 서비스

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

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

링크 서비스 예외

링크 및 멀티링크 서비스 구현은 다음과 같은 예외를 제외하고는 다른 라우팅 플랫폼의 구현과 유사합니다.

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

멀티클래스 MLPPP 구성

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

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

메모:

동일한 번들에 LFI와 멀티클래스 MLPPP를 모두 구성할 필요도 없고 멀티클래스 MLPPP도 지원되지 않습니다. 멀티클래스 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 클래스로의 매핑을 지정하려면 계층 수준에서 [edit class-of-service fragmentation-maps forwarding-class class-name] 문을 포함 multilink-class 합니다.

다중 링크 클래스 색인 번호는 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/0CRTP는 LFI 및 비 LFI 패킷에 적용될 수 있습니다. CRTP로 인해 대기열 수에는 변화가 없습니다.

구성 링크의 Q2에 대기열

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

Compressed Real-Time Transport Protocol 개요

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 Uncompressed header: 40-byte header plus 10-byte payload. Compressed header: 2-byte header plus 10-byte payload.

링크 서비스 인터페이스에서 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] 계층 수준에서 [edit interfaces lsq-0/0/0 unit logical-unit-number] MRRU 문을 포함하여 MRRU를 구성할 수 있습니다. MRRU는 MTU와 유사하지만 링크 서비스 인터페이스에만 적용됩니다. 기본적으로 MRRU 크기는 1504바이트이며, 1500바이트에서 4500바이트까지 구성할 수 있습니다.

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

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

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

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

이 multilink-class 문을 사용하여 포워딩 클래스를 다중 클래스 MLPPP에 매핑할 수 있습니다. 지정된 포워딩 클래스에 대해 OR 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)을 구성합니다. 예: 링크 단편화 및 인터리빙 구성을 참조하십시오.
분류자 및 포워딩 클래스를 구성합니다. 예: 분류자 및 포워딩 클래스 정의를 참조하십시오.
스케줄러 맵을 구성합니다. 스케줄러 맵 정의 및 적용 방법 이해를 참조하십시오.
인터페이스 쉐이핑 속도를 구성합니다. 예: 인터페이스 셰이핑 속도 구성을 참조하십시오
MLPPP 번들을 구성합니다. 예: MLPPP 번들 구성을 참조하십시오.
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 구성 편집기에서 페이지의 확인란의 Disable 선택을 취소합니다 Interfaces>interface-name .
Physical link—물리적 링크는 Up입니다. 링크 상태는 Down 인터페이스 모듈, 인터페이스 포트 또는 물리적 연결(링크 레이어 오류)에 문제가 있음을 나타냅니다.
Last flapped- Last 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개의 조각과 두 개의 구성 링크를 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과 연결되지 않습니다. 패킷은 링크 번들링 또는 압축을 위해 이 인터페이스로 라우팅됩니다.

더 이상 사용되지 않는 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 패킷 스트림을 보냅니다. 모든 패킷은 동일한 IP 우선순위 설정을 갖습니다. LFI 및 CRTP를 구성한 후 혼잡하지 않은 링크에서도 지연 시간이 증가했습니다. 지터와 지연을 줄이려면 어떻게 해야 할까요?

용액

지터와 지연을 줄이려면 다음을 수행하십시오.

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

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

문제
용액

문제

묘사

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

용액

LFI가 활성화되면 데이터(비 LFI) 패킷이 MLPPP 헤더로 캡슐화되고 지정된 크기의 패킷으로 단편화됩니다. 지연에 민감한 음성(LFI) 패킷은 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바이트+프레임 검사 시퀀스(FCS) 2바이트+유휴 상태이거나 플래그를 포함하는 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)	PPP	70바이트	4 + 2 + 1 = 7바이트	77 바이트
짧은 시퀀스의 데이터 조각(비 LFI)	MLPPP	70바이트	4 + 2 + 1 + 4 + 2 = 13바이트	83바이트
긴 시퀀스의 데이터 조각(비 LFI)	MLPPP	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)를 초과했습니다.
2분기 패킷	400	100	300	구성 링크를 통과하는 총 패킷 수는 번들의 패킷 수와 같습니다.
3분기 패킷	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 패킷 및 전송된 se-1/0/1소스 포트 200 의 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 헤더를 포함하는 단편화된 패킷을 폐기하고 이를 "폴리싱된 폐기"로 간주할 수 있습니다.

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