링크 서비스 인터페이스 구성
주니퍼 네트웍스 디바이스는 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 Series 및 T 시리즈 라우팅 플랫폼의 멀티링크 서비스 인터페이스(ml-fpc/pic/port), 링크 서비스 인터페이스(ls-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 에는 인터페이스에서 사용할 수 있는 서비스가 요약되어 있습니다.
서비스 |
목적 |
추가 정보 |
|---|---|---|
MLPPP 및 MLFR 캡슐화를 통한 멀티링크 번들 |
여러 구성 링크를 하나의 더 큰 논리적 번들로 통합하여 추가 대역폭, 로드 밸런싱 및 이중화를 제공합니다.
메모:
DCAC(동적 통화 승인 제어) 구성은 링크 서비스 인터페이스에서 지원되지 않습니다. |
|
링크 단편화 및 인터리빙(LFI) |
큰 데이터 패킷을 분할하고 지연에 민감한 음성 패킷을 작은 패킷과 인터리빙하여 링크의 지연과 지터를 줄입니다. |
|
압축된 실시간 전송 프로토콜(CRTP) |
음성 및 비디오 패킷에서 RTP(Real-Time Transport Protocol)로 인해 발생하는 오버헤드를 줄입니다. |
|
CoS(Class of Service) 분류기, 포워딩 클래스, 스케줄러 및 스케줄러 맵, 속도 셰이핑 |
다음과 같이 CoS를 구성하여 지연에 민감한 패킷에 더 높은 우선 순위를 제공합니다.
|
링크 서비스 예외
SRX 시리즈 방화벽에서의 링크 및 멀티링크 서비스 구현은 M Series 및 T 시리즈 라우팅 플랫폼에서의 구현과 유사하지만, 다음과 같은 예외가 있습니다.
링크 및 멀티링크 서비스에 대한 지원은 ,
lsq-fpc/pic/port,ls-fpc/pic/port인터페이스 대신ml-fpc/pic/port인터페이스에lsq-0/0/0있습니다.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를 사용하면 각 포워딩 클래스를 별도의 멀티링크 클래스로 매핑할 수 있으므로 우선 순위 및 지연 보장을 유지할 수 있습니다.
동일한 번들에 LFI와 멀티클래스 MLPPP를 모두 구성하는 것은 필요하지 않으며 지원되지도 않습니다. 멀티클래스 MLPPP는 기능의 상위 집합을 나타내기 때문입니다. 다중 클래스 MLPPP를 구성하면 LFI가 자동으로 활성화됩니다.
Junos OS PPP 구현은 주소 필드 압축 및 프로토콜 필드 압축 PPP NCP 옵션의 협상을 지원하지 않습니다. 즉, 소프트웨어는 항상 전체 4바이트 PPP 헤더를 전송합니다.
멀티클래스 MLPPP의 Junos OS 구현은 공통 헤더 바이트의 압축을 지원하지 않습니다.
멀티클래스 MLPPP는 여러 링크를 사용할 때 발생하는 패킷 순서 문제를 크게 단순화합니다. 멀티클래스 MLPPP가 없으면 단일 플로우에 속하는 모든 음성 트래픽이 단일 링크로 해시되어 패킷 순서 문제를 방지합니다. 다중 클래스 MLPPP를 사용하면 우선 순위가 높은 클래스에 음성 트래픽을 할당하고 여러 링크를 사용할 수 있습니다.
링크 서비스 IQ 인터페이스에서 멀티클래스 MLPPP를 구성하려면 링크가 번들에 조인할 때 협상해야 하는 멀티링크 클래스 수를 지정하고 포워딩 클래스를 멀티클래스 MLPPP 클래스로 매핑하도록 지정해야 합니다.
링크가 번들에 조인할 때 협상해야 하는 멀티링크 클래스 수를 지정하려면 문을 포함합니다.multilink-max-classes
multilink-max-classes number;
다음 계층 수준에서 이 명령문을 포함시킬 수 있습니다:
[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.
edit class-of-service fragmentation-maps forwarding-classclass-namemultilink-class number
멀티링크 클래스 인덱스 번호는 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(Real-Time Transport Protocol)를 구성할 수 있습니다. CRTP는 IP, UDP 및 RTP 헤더를 2바이트 CID(컨텍스트 ID)로 대체하여 헤더 오버헤드를 상당히 줄입니다.
그림 1 은 CRTP가 40바이트 헤더를 2바이트 헤더로 줄여 음성 패킷의 RTP 헤더를 압축하는 방법을 보여줍니다.
링크 서비스 인터페이스에서 MLPPP 또는 PPP 논리적 인터페이스 캡슐화를 사용하여 CRTP를 구성할 수 있습니다. 예제: MLPPP 번들 구성을 참조하십시오.
실시간 및 비실시간 데이터 프레임은 실시간 트래픽에 과도한 지연을 일으키지 않고 저속 링크에서 함께 전송됩니다. 링크 단편화 및 인터리빙 구성 이해하기를 참조하세요.
포워딩 클래스에 의한 단편화 구성
의 lsq-0/0/0 경우 특정 포워딩 클래스에 대한 단편화 속성을 지정할 수 있습니다. 각 포워딩 클래스의 트래픽은 multilink 캡슐화(단편화 및 시퀀싱) 또는 비캡슐화(단편화 없이 해시)일 수 있습니다. 기본적으로 모든 포워딩 클래스의 트래픽은 다중 링크 캡슐화됩니다.
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바이트까지 구성할 수 있습니다.
대기열에서 단편화 속성을 구성하려면 계층 수준에서 fragmentation-maps 문을 [edit class-of-service] 포함합니다.
[edit class-of-service]
fragmentation-maps {
map-name {
forwarding-class class-name {
fragment-threshold bytes;
multilink-class number;
no-fragmentation;
}
}
}
포워딩 클래스별 단편화 임계값을 설정하려면 단편화 맵에서 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.
[edit class-of-service interfaces]
lsq-0/0/0 {
unit logical-unit-number { # Multilink PPP
fragmentation-map map-name;
}
}
lsq-0/0/0:channel { # MLFR FRF.16
unit logical-unit-number
fragmentation-map map-name;
}
}
링크 레이어 오버헤드 구성
링크 레이어 오버헤드는 직렬 링크의 비트 스터핑(bit stuffing)으로 인해 구성 링크에서 패킷 드롭을 유발할 수 있습니다. 비트 스터핑은 데이터가 제어 정보로 해석되는 것을 방지하는 데 사용됩니다.
기본적으로 총 번들 대역폭의 4%가 링크 레이어 오버헤드를 위해 할당됩니다. 대부분의 네트워크 환경에서 평균 링크 레이어 오버헤드는 1.6%입니다. 따라서 안전 장치로 4%를 권장합니다.
주니퍼 네트웍스 디바이스의 경우 lsq-0/0/0 , 링크 레이어 오버헤드를 위해 따로 설정할 번들 대역폭의 백분율을 구성할 수 있습니다. 이를 위해 명령문을 link-layer-overhead 포함합니다:
link-layer-overhead percent;
다음 계층 수준에서 이 명령문을 포함시킬 수 있습니다:
[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를 구성하려면 예: 압축된 실시간 전송 프로토콜 구성을 참조하십시오.
링크 서비스 인터페이스 확인
구성이 올바르게 작동하고 있는지 확인합니다.
링크 서비스 인터페이스 통계 확인
목적
링크 서비스 인터페이스 통계를 확인합니다.
행동
이 섹션에 제공된 샘플 출력은 예: MLPPP 번들 구성에 제공된 구성을 기반으로 합니다. 구성 링크가 번들에 올바르게 추가되고 패킷이 단편화되어 올바르게 전송되었는지 확인하기 위해 다음 작업을 수행합니다.
이 예에서 사용되는 두 디바이스인 디바이스 R0 및 디바이스 R1에서 예: MLPPP 번들 구성에 설명된 대로 MLPPP 및 LFI를 구성합니다.
CLI에서 명령을 입력하여
pingR0과 R1 사이에 연결이 설정되었는지 확인합니다.R0에서 R1까지 각각 200바이트씩 10개의 데이터 패킷을 전송합니다.
R0의 CLI에서 명령을 입력합니다
show interfaces interface-name statistics.
user@R0> show interfaces lsq-0/0/0 statistics detail
Physical interface: lsq-0/0/0, Enabled, Physical link is Up
Interface index: 134, SNMP ifIndex: 29, Generation: 135
Link-level type: LinkService, MTU: 1504
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Last flapped : 2006-06-23 11:36:23 PDT (03:38:43 ago)
Statistics last cleared: 2006-06-23 15:13:12 PDT (00:01:54 ago)
Traffic statistics:
Input bytes : 0 0 bps
Output bytes : 1820 0 bps
Input packets: 0 0 pps
Output packets: 10 0 pps
...
Egress queues: 8 supported, 8 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 DATA 10 10 0
1 expedited-fo 0 0 0
2 VOICE 0 0 0
3 NC 0 0 0
Logical interface lsq-0/0/0.0 (Index 67) (SNMP ifIndex 41) (Generation 133)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP
Bandwidth: 16mbps
Bundle options:
...
Drop timer period 0
Sequence number format long (24 bits)
Fragmentation threshold 128
Links needed to sustain bundle 1
Interleave fragments Enabled
Bundle errors:
Packet drops 0 (0 bytes)
Fragment drops 0 (0 bytes)
...
Statistics Frames fps Bytes bps
Bundle:
Fragments:
Input : 0 0 0 0
Output: 20 0 1920 0
Packets:
Input : 0 0 0 0
Output: 10 0 1820 0
Link:
se-1/0/0.0
Input : 0 0 0 0
Output: 10 0 1320 0
se-1/0/1.0
Input : 0 0 0 0
Output: 10 0 600 0
...
Destination: 10.0.0.9/24, Local: 10.0.0.10, Broadcast: Unspecified, Generation:144
이 출력은 인터페이스 정보의 요약을 보여줍니다. 다음 정보를 확인합니다:
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-nameshow class-of-service classifier name classifier-nameshow class-of-service scheduler-map scheduler-map-name
이 섹션에 제공된 샘플 출력은예: MLPPP 번들 구성에 제공된 구성을 기반으로 합니다.
user@R0> show class-of-service interface lsq-0/0/0
Physical interface: lsq-0/0/0, Index: 136
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Chassis scheduler map: [default-chassis], Index: 4
Logical interface: lsq-0/0/0.0, Index: 69
Object Name Type Index
Scheduler-map s_map Output 16206
Classifier ipprec-compatibility ip 12
user@R0> show class-of-service interface ge-0/0/1
Physical interface: ge-0/0/1, Index: 140
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Logical interface: ge-0/0/1.0, Index: 68
Object Name Type Index
Classifier classfy_input ip 4330
user@R0> show class-of-service classifier name classify_input
Classifier: classfy_input, Code point type: inet-precedence, Index: 4330
Code point Forwarding class Loss priority
000 DATA low
010 VOICE low
user@R0> show class-of-service scheduler-map s_map
Scheduler map: s_map, Index: 16206
Scheduler: DATA, Forwarding class: DATA, Index: 3810
Transmit rate: 49 percent, Rate Limit: none, Buffer size: 49 percent, Priority:low
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: VOICE, Forwarding class: VOICE, Index: 43363
Transmit rate: 50 percent, Rate Limit: none, Buffer size: 5 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: NC, Forwarding class: NC, Index: 2435
Transmit rate: 1 percent, Rate Limit: none, Buffer size: 1 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
이 출력 예는 구성된 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 빠른 구성
ls-0/0/0에서 lsq-0/0/0으로 신속하게 업그레이드하려면(또는 변경 사항을 되돌리려면) 다음 명령을 복사하여 CLI에 붙여넣으십시오.
For interfaces ls-0/0/0 to lsq-0/0/0 [edit] rename interfaces ls-0/0/0 to lsq-0/0/0 set class-of-service fragmentation-maps map6 forwarding-class assured-forwarding no-fragmentation set class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6
For interfaces lsq-0/0/0 to ls-0/0/0 [edit] rename interfaces lsq-0/0/0 to ls-0/0/0 delete class-of-service fragmentation-maps map6 delete class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6 delete interfaces lsq-0/0/0 unit 6 link-layer-overhead delete interfaces lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead set interfaces ls-0/0/0 unit 6 interleave-fragments
단계별 절차
다음 예제에서는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 자세한 내용은 구성 모드에서 CLI 편집기 사용을 참조하십시오.
ls-0/0/0에서 lsq-0/0/0으로 업그레이드하거나 변경 사항을 되돌리려면:
구성에서 ls-0/0/0의 모든 발생 항목의 이름을 바꿉니다.
[edit] user@host# rename interfaces ls-0/0/0 to lsq-0/0/0
단편화 맵을 구성합니다.
[edit class-of-service fragmentation-maps] user@host# set map6 forwarding-class assured-forwarding no-fragmentation
- 멀티링크 번들의 단위 번호를 지정합니다.
[edit class-of-service ] user@host# set interfaces lsq-0/0/0 unit 6 fragmentation-map map6
구성의 모든 발생에 대한 구성을 롤백합니다.
[edit] user@host# rename interfaces lsq-0/0/0 to ls-0/0/0
서비스 등급에 따른 단편화 맵을 삭제합니다.
[edit] user@host# delete class-of-service fragmentation-maps map6
단편화 맵이 lsq-0/0/0 인터페이스에 할당된 경우 삭제합니다.
[edit class-of-service interfaces] user@host# delete lsq-0/0/0 unit 6 fragmentation-map map6
lsq-0/0/0에 대해 구성된 경우 multilink max 클래스를 삭제합니다.
메모:Multilink-max-classes는 지원되지 않으며 구성되지 않았을 가능성이 높습니다.
lsq-0/0/0에 대해 구성된 경우 link-layer-overhead를 삭제합니다.
[edit interfaces] user@host# delete lsq-0/0/0 unit 6 link-layer-overhead
lsq-0/0/0:0에 대해 구성된 경우 link-layer-overhead를 삭제합니다.
[edit interfaces] user@host# delete lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead
ls-0/0/0 인터페이스에 대한 인터리브 조각을 구성합니다.
[edit interfaces] user@host# set ls-0/0/0 unit 6 interleave-fragments
결과
구성 모드에서 명령을 입력하여 show class-of-service 구성을 확인합니다. 출력이 의도된 구성을 표시하지 않으면, 이 예의 구성 지침을 반복하여 수정합니다.
[edit]
user@host# show class-of-service
interfaces {
lsq-0/0/0 {
unit 6 {
fragmentation-map map6;
}
}
}
fragmentation-maps {
map6 {
forwarding-class {
assured-forwarding {
no-fragmentation;
}
}
}
}
디바이스 구성을 마쳤으면 구성 모드에서 을(를) 입력합니다 commit .
링크 서비스 인터페이스 문제 해결
링크 서비스 인터페이스의 구성 문제를 해결하려면,
- 구성 링크에 어떤 CoS 구성 요소가 적용되는지 결정합니다
- 멀티링크 번들에서 지터 및 지연의 원인 확인
- LFI 및 로드 밸런싱이 올바르게 작동하는지 확인
- 주니퍼 네트웍스 디바이스와 타사 디바이스 사이의 PVC에서 패킷이 드롭되는 이유를 확인합니다
구성 링크에 어떤 CoS 구성 요소가 적용되는지 결정합니다
문제
묘사
멀티링크 번들을 구성하고 있지만, 멀티링크 번들의 구성 링크를 통과하는 MLPPP 캡슐화가 없는 트래픽도 있습니다. 모든 CoS 구성 요소를 구성 링크에 적용합니까, 아니면 멀티링크 번들에 충분히 적용합니까?
용액
스케줄러 맵을 멀티링크 번들 및 해당 구성 링크에 적용할 수 있습니다. 스케줄러 맵으로 여러 CoS 구성 요소를 적용할 수 있지만 필요한 구성 요소만 구성합니다. 불필요한 전송 지연을 방지하기 위해 구성 링크의 구성을 단순하게 유지하는 것이 좋습니다.
표 2 에는 멀티링크 번들 및 해당 구성 링크에 적용될 CoS 구성 요소가 나와 있습니다.
Cos 구성 요소 |
멀티링크 번들 |
구성 링크 |
설명 |
|---|---|---|---|
분류자 |
예 |
아니요 |
CoS 분류는 전송 측이 아닌 인터페이스의 수신 측에서 이루어지므로 구성 링크에는 분류기가 필요하지 않습니다. |
포워딩 클래스 |
예 |
아니요 |
포워딩 클래스 은(는) 대기열과 연결되며, 대기열은 스케줄러 맵에 의해 인터페이스에 적용됩니다. 대기열 할당은 구성 링크에서 미리 결정됩니다. 멀티링크 번들의 Q2에서 나온 모든 패킷은 구성 링크의 Q2에 할당되고, 다른 모든 대기열의 패킷은 구성 링크의 Q0으로 대기열에 추가됩니다. |
스케줄러 맵 |
예 |
예 |
멀티링크 번들 및 구성 링크에 다음과 같이 스케줄러 맵을 적용합니다.
|
단위별 스케줄러 또는 인터페이스 수준 스케줄러의 셰이핑 속도 |
아니요 |
예 |
단위당 스케줄링은 엔드포인트에서만 적용되므로 이 셰이핑 속도를 구성 링크에만 적용합니다. 이전에 적용된 모든 구성은 구성 링크 구성에 의해 덮어쓰기됩니다. |
정확한 전송 속도 또는 큐 레벨 쉐이핑 |
예 |
아니요 |
구성 링크에 적용된 인터페이스 수준 쉐이핑은 대기열의 모든 쉐이핑보다 우선합니다. 따라서 멀티링크 번들에만 transmit-rate exact shaping을 적용합니다. |
규칙 재작성 |
예 |
아니요 |
재작성 비트는 단편화 중에 패킷에서 조각으로 자동으로 복사됩니다. 따라서 멀티링크 번들에 구성하는 내용은 조각에서 구성 링크로 전달됩니다. |
가상 채널 그룹 |
예 |
아니요 |
가상 채널 그룹은 멀티링크 번들 전에 패킷에만 적용되는 방화벽 필터 규칙을 통해 식별됩니다. 따라서 가상 채널 그룹 구성을 구성 링크에 적용할 필요가 없습니다. |
참조
멀티링크 번들에서 지터 및 지연의 원인 확인
문제
묘사
지터와 지연을 테스트하기 위해 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큰 패킷이 올바르게 단편화되었는지 확인합니다.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10Meaning- 출력은 멀티링크 번들의 디바이스를 전송하는 패킷의 요약을 보여줍니다. 멀티링크 번들에 대한 다음 정보를 확인합니다.총 전송 패킷 수 = 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바이트 사이를 추가합니다.
4바이트의 PPP 헤더+2 - 4바이트의 멀티링크 헤더
그림 2 는 PPP 및 MLPPP 헤더에 추가된 오버헤드를 보여줍니다.
그림 2: PPP 및 MLPPP 헤더
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패킷에 대해 로드 밸런싱이 적절하게 수행되는지 확인합니다.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bpsMeaning- 이 명령의 출력은 링크 서비스 인터페이스 및 해당 구성 링크의 각 대기열에서 전송 및 대기열에 있는 패킷을 보여줍니다. 표 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를 올바르게 전송합니다.
전송된 소스 포트
100의 LFI 패킷 및 전송se-1/0/1된 소스 포트200의 LFI 패킷se-1/0/0입니다. 따라서 모든 LFI(Q2) 패킷은 소스 포트를 기반으로 해시되고 두 구성 링크를 모두 올바르게 전송했습니다.
Corrective Action- 패킷이 하나의 링크만 전송한 경우 다음 단계를 수행하여 문제를 해결합니다.물리적 링크가 작동(operational)인지 또는
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 헤더가 포함된 단편화된 패킷을 폐기하고 "폴리싱된 폐기"로 계산할 수 있습니다.
해결 방법으로 두 피어 모두에서 멀티링크 번들을 구성하고 멀티링크 번들에서 단편화 임계값을 구성합니다.