이 페이지에서

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

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

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

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

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

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

SRX 시리즈 방화벽의 링크 서비스 큐잉 인터페이스는 주니퍼 네트웍스 M Series 및 T 시리즈 라우팅 플랫폼에서 다음 인터페이스가 제공하는 서비스로 구성됩니다. 멀티링크 서비스 인터페이스(), 링크 서비스 인터페이스(ml-fpc/pic/portls-fpc/pic/port), 링크 서비스 지능형 큐잉 인터페이스(lsq-fpc/pic/port). M Series 및 T 시리즈 라우팅 플랫폼의 멀티링크 서비스, 링크 서비스 및 링크 서비스 지능형 큐잉(IQ) 인터페이스가 PIC(Physical Interface Card)에 설치되어 있지만, SRX 시리즈 방화벽의 링크 서비스 큐잉 인터페이스는 내부 인터페이스에만 해당하며 물리적 매체 또는 PIM(Physical Interface Module)과 관련이 없습니다.

참고:

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

이 섹션에는 다음 주제가 포함되어 있습니다.

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

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

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

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

링크 서비스 예외

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

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

멀티클래스 MLPPP 구성

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

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

참고:

동일한 번들에 LFI 및 다중 클래스 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일 수 있습니다. 문과 no-fragmentation 명령문은 multilink-class 상호 배타적입니다.

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

LFI를 통한 큐잉

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

예를 들어, 대기열 Q0이 단편화 임계값 128로 구성되고, 1분기는 단편화 없이 구성되며, Q2는 단편화 임계값 512로 구성된다고 가정합니다. Q0은 패킷 크기 512로 트래픽 흐름을 수신하고 있습니다. 1분기에는 64바이트의 음성 트래픽을 수신하고 있으며, 2분기에는 128바이트 패킷으로 트래픽 흐름을 수신하고 있습니다. 다음으로 Q0의 스트림은 구성 링크의 Q0으로 단편화되고 큐업됩니다. 또한 2분기의 모든 패킷은 구성 링크의 Q0에서 대기되고 있습니다. 단편화가 구성되지 않아 1분기 스트림은 LFI로 간주됩니다. Q0 및 2분기의 모든 패킷은 구성 링크의 Q0에서 대기하고 있습니다. 1분기 모든 패킷은 구성 링크의 2분기에 큐업됩니다.

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

구성 링크의 2분기 큐잉

멀티링크 번들에서 서비스 클래스 를 사용할 때, 멀티링크 번들의 모든 Q2 트래픽은 패킷의 소스 주소, 대상 주소 및 IP 프로토콜에서 계산된 해시를 기반으로 구성 링크의 2분기까지 대기열에 연결됩니다. IP 페이로드가 TCP 또는 UDP 트래픽인 경우 해시에는 소스 포트 및 대상 포트도 포함됩니다. 이 해시 알고리즘의 결과로 하나의 트래픽 플로우에 속한 모든 트래픽이 하나의 구성 링크 중 2분기에 대기됩니다. 구성 링크에 대한 이러한 트래픽 전달 방법은 번들이 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] 포함합니다.

포워딩당 클래스 단편화 임계값을 설정하려면 단편화 맵에 문을 포함합니다 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 링크 레이어 오버헤드에 대해 별도로 설정하도록 번들 대역폭 비율을 구성할 수 있습니다. 이를 위해 링크 레이어 오버헤드 문을 포함합니다.

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

[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 번들 구성을 참조하십시오.
MLFR을 구성하려면 예: 멀티링크 프레임 릴레이 FRF.15 구성 또는 예: 멀티링크 프레임 릴레이 FRF.16 구성을 참조하십시오.
CRTP를 구성하려면 예: 압축된 실시간 전송 프로토콜 구성을 참조하십시오.

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

구성이 제대로 작동하는지 확인합니다.

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

목적

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

작업

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

디바이스 R0 및 디바이스 R1에서 이 예에서 사용된 두 개의 디바이스는 예: MLPPP 번들 구성에 설명된 대로 MLPPP 및 LFI를 구성합니다.
CLI에서 명령을 입력 ping 하여 R0과 R1 사이에 연결이 설정되었는지 확인합니다.
R0에서 R1까지 각각 10개의 데이터 패킷, 200바이트씩 전송합니다.
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 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으로 업그레이드

이 예는 멀티링크 서비스를 위해 ls-0/0/0에서 lsq-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으로 변경합니다. [서비스 클래스] 계층에서 구성된 경우 단편화 맵을 삭제하고 lsq-0/0/0에 할당된 경우 단편화 맵을 삭제합니다. [인터페이스] 계층에서 lsq-0/0/0에 대해 구성된 경우 멀티링크 최대 클래스를 삭제할 수 있습니다. 그런 다음 [인터페이스] 계층에서 lsq-0/0/0으로 구성된 경우 link-layer-overhead를 삭제합니다.

포워딩 클래스에서 단편화가 구성되지 않고 단편화 맵이 lsq-0/0/0에 할당되면 ls-0/0/0 인터페이스에 대한 인터리브 패킷 조각을 구성합니다. 마지막으로, LFI 패킷의 분류기를 대기열 2를 참조하도록 구성합니다. (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에 대해 구성된 경우 멀티링크 최대 클래스를 삭제합니다.

참고:
멀티링크 최대 클래스는 지원되지 않으며 구성되지 않을 가능성이 큽니다.
lsq-0/0/0용으로 구성된 경우 링크 레이어 오버헤드를 삭제합니다.

lsq-0/0/0:0용으로 구성된 경우 링크 레이어 오버헤드를 삭제합니다.

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

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

문제
솔루션

문제

설명

지터와 지연을 테스트하기 위해 세 개의 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 및 을(를) 어그리게이션하는 멀티링크 번들에 lsq-0/0/0.0 의해 연결되어 있다고 가정해se-1/0/1봅니다. 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)+1바이트(유휴 상태이거나 플래그 포함)
MLPPP 캡슐화는 6바이트에서 8바이트 사이를 추가합니다.

PPP 헤더 4바이트+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	구성 링크의 3분기 전송 패킷은 구성 링크 간에 교환된 keepalive 메시지를 위한 것입니다. 따라서 번들의 3분기 패킷은 계산되지 않았습니다.

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

대기열에 있는 패킷 수는 전송된 수와 일치합니다. 숫자가 일치하는 경우 패킷이 손실되지 않았습니다. 전송보다 더 많은 패킷이 대기열에 추가되면 버퍼가 너무 작아서 패킷이 누락됩니다. 구성 링크의 버퍼 크기는 출력 단계에서 혼잡을 제어합니다. 이 문제를 해결하려면 구성 링크의 버퍼 크기를 늘려야 합니다.
Q0(600)을 전송하는 패킷 수는 멀티링크 번들에서 수신된 대규모 및 소형 데이터 패킷 수(100+500)와 일치합니다. 숫자가 일치하면 모든 데이터 패킷이 Q0으로 올바르게 전송됩니다.
멀티링크 번들(400)의 2분기 전송 패킷 수는 멀티링크 번들에서 수신된 음성 패킷 수와 일치합니다. 숫자가 일치하는 경우, 모든 음성 LFI 패킷이 2분기 올바르게 전달되었습니다.

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

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

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

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

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

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

결과를 사용하여 로드 밸런싱을 확인합니다.

주니퍼 네트웍스 디바이스와 타사 디바이스 간의 PVC에서 패킷이 누락된 이유 결정

문제
솔루션

문제

설명

주니퍼 네트웍스 디바이스와 타사 디바이스에서 T1, E1, T3 또는 E3 인터페이스 사이에 영구적인 가상 서킷(PVC)을 구성하고 있으며 패킷이 누락되고 핑이 실패합니다.

솔루션

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

이를 해결하기 위해 두 피어 모두에서 멀티링크 번들을 구성하고 멀티링크 번들에 단편화 임계값을 구성합니다.