로드밸런싱 MPLS 트래픽
MPLS 레이블을 기반으로 로드 밸런싱 구성
로드 밸런싱은 지원되는 플랫폼의 MPLS 흐름에 대해 패킷 단위로 발생합니다. 엔트로피 또는 랜덤 분포는 패킷을 다음 홉으로 균일하게 분배하는 데 필수적입니다. 기본적으로 로드 밸런싱을 사용하여 트래픽 분산을 지원할 때 Junos OS는 해시 알고리즘을 사용하여 포워딩 테이블에 설치할 다음 홉 주소를 선택합니다. 대상에 대한 다음 홉 집합이 변경될 때마다 해시 알고리즘을 통해 다음 홉 주소가 다시 선택됩니다. 해시 알고리즘을 사용하여 일련의 동일 비용 레이블 스위치 경로(LSP)에서 트래픽을 로드 밸런싱하는 방법을 구성할 수 있습니다.
VPLS 및 VPWS 트래픽의 엔트로피를 보장하기 위해 Junos OS는 IP 헤더와 최대 3개의 MPLS 레이블(소위 최상위 레이블)의 데이터를 기반으로 해시를 생성할 수 있습니다.
경우에 따라 레이블을 사용하는 네트워크 기능(예: MPLS Fast Reroute 및 RFC 3107, RSVP 및 VPN)의 수가 증가함에 따라 상위 3개 레이블의 데이터가 정적이 되어 엔트로피를 위한 충분한 소스가 아닐 수 있습니다. 결과적으로 로드 밸런싱이 왜곡되거나 잘못된 패킷 전달 발생률이 증가할 수 있습니다. 이러한 경우 레이블 스택 하단의 레이블을 사용할 수 있습니다(자격은 아래 표 1 참조). 맨 위 레이블과 맨 아래 레이블은 동시에 사용할 수 없습니다.
MPC 카드는 일반 해시 키 구성을 지원하지 않습니다. MPC 기반 해시 키 구성이 유효하려면 구성이 필요합니다.enhanced-hash-key
로드 밸런싱은 다음 조건이 적용될 때 트래픽을 균등하게 분산하는 데 사용됩니다.
-
동일한 대상에 대한 서로 다른 인터페이스를 통해 여러 개의 동일 비용 다음 홉이 있습니다.
-
어그리게이션 인터페이스를 통해 단일 다음 홉이 있습니다.
LSP는 equal-cost 다음 홉 중 하나를 무작위로 선택하고 독점적으로 사용하여 배치를 로드 밸런싱하는 경향이 있습니다. 무작위 선택은 각 전송 라우터에서 독립적으로 이루어지며, 내부 게이트웨이 프로토콜(IGP) 메트릭만 비교합니다. 대역폭이나 혼잡 수준은 고려하지 않습니다.
이 기능은 어그리게이션 이더넷 및 어그리게이션 SONET/SDH 인터페이스와 여러 개의 equal-cost MPLS 다음 홉에 적용됩니다. 또한 T 시리즈, MX 시리즈, M120 및 M320 라우터에서만 레이어 2 이더넷 유사 회선을 통한 IPv4 트래픽에 대한 로드 밸런싱을 구성할 수 있습니다. 또한 IP 정보를 기반으로 이더넷 유사 회선에 대한 로드 밸런싱을 구성할 수도 있습니다. 해시 키에 IP 정보를 포함하는 옵션은 이더넷 서킷 크로스 커넥트(CCC) 연결을 지원합니다.
MPLS 레이블 정보를 기반으로 부하를 분산하려면 명령문을 구성합니다.family mpls
[edit forwarding-options hash-key] family mpls { all-labels; bottom-label-1; bottom-label-2; bottom-label-3; label-1; label-2; label-3; no-labels; no-label-1-exp; payload { ether-pseudowire; ip { disable; layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
다음 계층 수준에서 이 문을 포함할 수 있습니다.
-
[edit forwarding-options hash-key]
표 1 은 가능한 모든 MPLS LSP 로드 밸런싱 옵션에 대한 자세한 정보를 제공합니다.
| 성명서 |
지원되는 플랫폼 |
MPLS LSP 로드 밸런싱 옵션 |
|---|---|---|
|
|
MX 시리즈 및 PTX 시리즈 |
Junos OS 릴리스 19.1R1 이전에는 패킷 포워딩 엔진에서 흐름의 고유성을 식별하기 위해 해시 키에 최대 8개의 MPLS 레이블이 포함되었습니다. PTX 시리즈 라우터에서 이 값은 기본적으로 설정됩니다. Junos OS 릴리스 19.1R1부터 MPC 및 MIC 인터페이스가 있는 MX 시리즈 라우터의 경우 최대 16개의 수신 MPLS 레이블이 해시 키에 포함됩니다. |
|
|
DPC(I-칩)가 탑재된 MX 시리즈. M10i, M7i, M120에서는 지원되지 않습니다. |
해시 키를 계산하는 데 맨 아래 레이블을 사용합니다(예: 맨 위 레이블이 필요한 엔트로피 수준에 대한 충분한 변수를 제공하지 않는 경우). |
|
|
DPC(I-칩)가 탑재된 MX 시리즈. M10i, M7i, M120에서는 지원되지 않습니다. |
해시 키를 계산하기 위해 아래에서 두 번째 레이블을 사용합니다(예: 맨 위의 레이블이 필요한 엔트로피 수준에 대한 충분한 변수를 제공하지 않는 경우). |
|
|
DPC(I-칩)가 탑재된 MX 시리즈. M10i, M7i, M120에서는 지원되지 않습니다. |
해시 키를 계산하기 위해 아래에서 세 번째 레이블을 사용합니다(예: 맨 위 레이블이 필요한 엔트로피 수준에 대한 충분한 변수를 제공하지 않는 경우). |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 첫 번째 레이블을 포함합니다. 단일 레이블 패킷에 이 옵션을 사용합니다. |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 두 번째 레이블을 포함합니다. 또한 옵션을 구성 |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 세 번째 레이블을 포함합니다. 또한 옵션과 옵션을 구성 |
|
|
모두 |
해시 키에서 MPLS 레이블을 제외합니다. |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에서 맨 위 레이블의 EXP 비트를 제외합니다. 또한 옵션을 구성 레이어 2 VPN의 경우 라우터에서 패킷 재정렬 문제가 발생할 수 있습니다. 트래픽 버스트로 인해 고객 트래픽 대역폭이 제한을 초과하게 되면 트래픽이 플로우 중간에 영향을 받을 수 있습니다. 그 결과 패킷이 재정렬될 수 있습니다. 해시 키에서 EXP 비트를 제외하면 이러한 재정렬 문제를 피할 수 있습니다. |
|
|
모두 |
해시 키에 포함할 IP 패킷 페이로드의 일부를 구성할 수 있습니다. PTX 시리즈 패킷 전송 라우터의 경우, 이 값은 기본적으로 설정됩니다.
참고: ACX5448 시리즈 라우터
payload 에서는 하위 옵션이 지원되지 않으며 지원되지 않는 구성을 방지하기 위해 숨겨졌습니다. 기존 구성에 명령이 포함된
set forwarding-options hash-key family mpls payload ip 경우 플랫폼에 다음 경고가 표시됩니다.
Warning: configuration block ignored: unsupported platform (acx5448) |
|
|
PTX 시리즈 |
해시 키에서 IP 페이로드를 제외합니다. |
|
|
M120, M320, MX 시리즈, T 시리즈 |
레이어 2 이더넷 유사 회선을 통한 IPv4 트래픽 로드 밸런싱. |
|
|
모두 |
해시 키에 IPv4 또는 IPv6 주소를 포함합니다. 또한 또는 |
|
|
모두 |
해시 키에는 레이어 3 IP 정보만 포함합니다. 해시 키에서 모든 |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
소스 및 대상 포트 필드 정보를 포함합니다. 기본적으로 소스 및 대상 포트 필드의 최상위 바이트와 최소 바이트가 해시 키에 사용됩니다. 해시 키에 사용할 특정 바이트를 선택하려면 계층 수준에서 |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 대상 포트의 최하위 바이트를 포함합니다. 다른 |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 대상 포트의 가장 중요한 바이트를 포함합니다. 다른 |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 소스 포트의 최하위 바이트를 포함합니다. 다른 |
|
|
M 시리즈, MX 시리즈, T 시리즈 |
해시 키에 소스 포트의 가장 중요한 바이트를 포함합니다. 다른 |
다음 예는 MPLS LSP 로드 밸런싱을 구성할 수 있는 방법을 보여줍니다.
-
해시 키에 IP 주소와 첫 번째 레이블을 포함하려면:
-
M 시리즈, MX 시리즈 및 T 시리즈 라우터의 경우, 계층 수준에서 문과
ip문에 대한payload옵션을 구성label-1합니다.[edit forwarding-options hash-key family mpls][edit forwarding-options hash-key family mpls] label-1; payload { ip; } -
PTX 시리즈 패킷 전송 라우터의 경우,
all-labels및ip payload옵션이 기본적으로 구성되므로 구성이 필요하지 않습니다.
-
-
(M320 및 T 시리즈 라우터만 해당) 해시 키에 IP 주소와 첫 번째 및 두 번째 레이블을 모두 포함하려면, 계층 수준에서 문에 대한
payloadandlabel-2옵션과ip옵션을 구성label-1합니다.[edit forwarding-options hash-key family mpls][edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }참고:M320 및 T 시리즈 라우터에서만 이러한 문 조합을 포함할 수 있습니다. M Series 멀티서비스 에지 라우터에 포함하면 첫 번째 MPLS 레이블과 IP 페이로드만 해시 키에 사용됩니다.
-
T 시리즈 라우터의 경우, 계층 수준에서 ,
label-2, 및label-3옵션을 포함하여label-1적절한 로드 밸런싱을 보장합니다.[edit forwarding-options hash-key family mpls][edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
-
(M 시리즈, MX 시리즈, T 시리즈 라우터만 해당) 레이어 2 VPN의 경우 라우터에서 패킷 재정렬 문제가 발생할 수 있습니다. 트래픽 버스트로 인해 고객 트래픽 대역폭이 제한을 초과하게 되면 트래픽이 플로우 중간에 영향을 받을 수 있습니다. 그 결과 패킷이 재정렬될 수 있습니다. 해시 키에서 EXP 비트를 제외하면 이러한 재정렬 문제를 피할 수 있습니다. 해시 계산에서 첫 번째 레이블의 EXP 비트를 제외하려면 계층 수준에서
[edit forwarding-options hash-key family mpls]문을 포함no-label-1-exp합니다.[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
예: 로드 밸런싱 MPLS 네트워크
동일한 송신 라우터에 여러 RSVP LSP를 구성할 때, 가장 낮은 메트릭의 LSP가 선택되어 모든 트래픽을 전송합니다. 모든 LSP가 동일한 메트릭을 갖는 경우, LSP 중 하나가 무작위로 선택되고 모든 트래픽이 이를 통해 전달됩니다. 모든 LSP에 트래픽을 균등하게 분산하기 위해 구성된 로드 밸런싱 유형에 따라 수신 또는 전송 라우터에서 로드 밸런싱을 구성할 수 있습니다.
그림 1 은 동일한 송신 라우터(R0)에 구성된 4개의 LSP가 있는 MPLS 네트워크를 보여줍니다. 로드 밸런싱은 수신 라우터 R1에서 구성됩니다. 예제 네트워크는 OSPF 영역이 0.0.0.0인 내부 게이트웨이 프로토콜(IGP)으로 최최단 경로 우선(OSPF)을 사용합니다. IGP는 Junos OS의 기본값인 CSPF(Constrained Shortest Path First) LSP에 필요합니다. 또한 예제 네트워크는 정책을 사용하여 BGP 트래픽을 생성합니다.
그림 1에 표시된 네트워크는 다음 구성 요소로 구성됩니다.
-
AS 65432를 사용하는 풀 메시 내부 BGP(IBGP) 토폴로지
-
모든 라우터에서 MPLS 및 RSVP 활성화
-
라우터 R1 및 R0 에 대한 send-statics 정책으로 네트워크에 새 경로를 보급할 수 있습니다.
-
R1과 R0 사이의 단방향 LSP 4개, R0과 R1 사이의 역방향 LSP 1개는 양방향 트래픽을 허용합니다
-
수신 라우터 R1에 구성된 로드 밸런싱
그림 1에 표시된 네트워크는 BGP 풀메쉬 네트워크입니다. 경로 리플렉터 및 컨페더레이션은 BGP가 학습된 경로를 전파하는 데 사용되지 않기 때문에 각 라우터는 BGP를 실행하는 다른 모든 라우터와 BGP 세션이 있어야 합니다.
로드 밸런싱 MPLS 네트워크를 위한 라우터 구성
목적
이 항목의 구성은 로드 밸런싱 네트워크 토폴로지에 설명된 예제 네트워크에 있는 6개의 로드 밸런싱된 라우터에 대한 것입니다.
작업
라우터의 구성을 표시하려면 다음 Junos OS CLI 운영 모드 명령을 사용합니다.
user@host> show configuration | no-more
샘플 출력 1
다음 구성 출력은 에지 라우터 R6에 대한 것입니다.
user@R6> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.6.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.6.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/2.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
샘플 출력 2
다음 구성 출력은 수신 라우터 R1에 대한 것입니다.
user@R1> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.13/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.1.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.1.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
forwarding-table {
export lbpp; #Routes exported to forwarding table
}
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path lsp 1 { #First LSP
to 192.168.0.1; # Destination of the LSP
install 10.0.90.14/32 active; # The prefix is installed in the
primary via-r4; # inet.0 routing table
}
label-switched-path lsp2 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp3 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp4 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r4;
}
path via-r2 { #Primary path to spread traffic across interfaces
10.0.29.2 loose;
}
path via-r4 {
10.0.24.2 loose;
}
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; #Allows advertising of a new route
group internal {
type internal;
local-address 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options { #Load balancing policy
policy-statement lbpp {
then {
load-balance per-packet;
}
}
policy-statement send-statics { #Static route policy
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
샘플 출력 3
다음 구성 출력은 전송 라우터 R2에 대한 것입니다.
user@R2> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.1/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.1/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.144/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.2.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface so-0/0/1.0;
interface fe-0/1/0.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.2.1;
neighbor 192.168.1.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
샘플 출력 4
다음 구성 출력은 전송 라우터 R4에 대한 것입니다.
user@R4> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.2/30;
}
family mpls; # MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.1/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.146/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.4.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.4.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
샘플 출력 5
다음 구성 출력은 전송 라우터 R9에 대한 것입니다.
user@R9> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.2/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.2/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.206/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.9.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.9. 1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.9.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.0.1;
neighbor 192.168.6.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
샘플 출력 6
다음 구성 출력은 송신 라우터 R0에 대한 것입니다.
user@R0> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.11.1/24;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.207/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.10.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.0.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path r0-r6 {
to 192.168.6.1;
}
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.0.1;
export send-statics; #Allows advertising of a new route
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.10.0/24 exact;
}
then accept;
}
}
}
의미
샘플 출력 1에서 6은 예: 로드 밸런싱 MPLS 네트워크에 표시된 예시 네트워크에서 6개 라우터 모두에 대한 기본 인터페이스, 라우팅 옵션, 프로토콜 및 정책 옵션 구성을 보여줍니다.
네트워크의 모든 라우터는 MPLS, RSVP 및 BGP를 활성화합니다. OSPF는 IGP로 구성되며, 관련 인터페이스에는 기본 IP 정보 및 MPLS 지원이 있습니다.
또한 모든 라우터에는 중복 RID 문제를 방지하기 위해 계층 수준에서 [edit routing-options] 수동으로 구성된 RID(라우터 ID)가 있습니다. 이 passive 문은 프로토콜이 루프백(lo0) 인터페이스를 통해 실행되지 않고 루프백(lo0) 인터페이스가 네트워크 전체에 올바르게 보급되도록 하기 위해 최단 경로 우선(OSPF) 구성에 포함됩니다.
R6, R2, R4 및 R9에 대한 샘플 출력 1, 3, 4 및 5는 전송 레이블 스위치 라우터의 기본 구성을 보여줍니다. 기본 구성에는 MPLS에 대해 활성화된 모든 인터페이스, 수동으로 구성된 RID 및 관련 프로토콜(RSVP, MPLS, BGP 및 OSPF)이 포함됩니다.
수신 라우터 R1의 샘플 출력 2는 기본 구성과 R0에 구성된 4개의 LSP(lsp1에서 lsp4)를 보여줍니다. 4개의 LSP는 lsp1 및 lsp4의 경우 R4를 통하고, lsp2 및 lsp3의 경우 R2를 통해 느슨한 홉을 지정하는 서로 다른 기본 경로로 구성됩니다.
트래픽을 생성하기 위해 R1에는 계층 수준에서 [edit routing-options static route] 구성된 고정 경로(100.100.1.0/24)가 있습니다. 접두사는 계층 수준의 send-statics 정책 [edit policy-options send statics] 에 포함되므로 경로가 BGP 경로가 될 수 있습니다.
또한 수신 라우터 R1에서 로드 밸런싱은 패킷당 옵션을 사용하여 구성되며 정책은 계층 수준에서 [edit routing-options forwarding-table] 내보내집니다.
송신 라우터 R0 의 샘플 출력 6은 양방향 트래픽을 생성하는 데 사용되는 하나의 LSP(r0-r6)에서 R6 을 보여줍니다. 최단 경로 우선(OSPF)은 LSP를 IGP에 보급하기 전에 양방향 IGP 도달 가능성이 필요합니다. LSP가 IGP에 보급되더라도 LSP를 통해 Hello 메시지나 라우팅 업데이트가 발생하지 않고 사용자 트래픽만 LSP를 통해 전송됩니다. 라우터는 IGP 데이터베이스의 로컬 복사본을 사용하여 양방향 도달 가능성을 확인합니다.
또한 R0에는 계층 수준에서 [edit routing-options static route] 구성된 정적 경로(100.100.10.0/24)가 있습니다. 접두사는 계층 수준의 send-statics 정책 [edit policy-options send statics] 에 포함되므로 경로가 BGP 경로가 될 수 있습니다.
ACX 시리즈 라우터에서 MPLS 레이블을 기반으로 로드 밸런싱 구성
표 2 는 가능한 모든 MPLS LSP 로드 밸런싱 옵션에 대한 자세한 정보를 제공합니다.
ACX 시리즈 라우터는 MPLS에서 패킷당 기준으로 로드 밸런싱을 수행할 수 있습니다. 로드 밸런싱은 IP 헤더와 최대 3개의 MPLS 레이블 모두에 있는 정보에 대해 수행할 수 있으며, 이를 통해 다음 홉으로 보다 균일한 MPLS 트래픽을 배포할 수 있습니다. 이 기능은 기본적으로 지원되는 플랫폼에서 활성화되며 구성이 필요하지 않습니다.
로드 밸런싱은 통합 인터페이스 또는 LAG 번들을 통해 단일 다음 홉이 있을 때 트래픽을 균등하게 분산하는 데 사용됩니다. MPLS 레이블을 사용한 로드 밸런싱은 LAG 인터페이스에서만 지원되며 ECMP(Equal-cost 다중 경로) 링크에는 지원되지 않습니다.
기본적으로 로드 밸런싱을 사용하여 트래픽 분산을 지원할 때 Junos OS는 해시 알고리즘을 사용하여 포워딩 테이블에 설치할 다음 홉 주소를 선택합니다. 대상에 대한 다음 홉 집합이 어떤 식으로든 변경될 때마다 다음 홉 주소는 해시 알고리즘을 통해 다시 선택됩니다. 어그리게이션 이더넷(ae) 인터페이스의 인터페이스 간 트래픽 로드 밸런싱을 위해 해시 알고리즘을 사용하는 방법을 구성할 수 있습니다.
LSP는 인터페이스 번들에서 ae- 인터페이스 중 하나를 무작위로 선택하고 독점적으로 사용하여 배치를 로드 밸런싱하는 경향이 있습니다. 무작위 선택은 각 전송 라우터에서 독립적으로 이루어지며, 내부 게이트웨이 프로토콜(IGP) 메트릭만 비교합니다. 대역폭이나 혼잡 수준은 고려하지 않습니다.
MPLS 레이블 정보를 기반으로 부하를 분산하려면 명령문을 구성합니다.family mpls
[edit forwarding-options hash-key] family mpls { all-labels; label-1; label-2; label-3; no-labels; payload { ether-pseudowire; ip { layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
계층 수준에서 이 문을 포함할 수 있습니다.[edit forwarding-options hash-key]
페이로드 ip(user@host# set forwarding-options hash-key family mpls payload ip)를 구성할 때 및 port-data 구성 layer-3-only 은 필수입니다.
적절한 해시 키 구성이 없는 로드 밸런싱 기능으로 인해 예측할 수 없는 동작이 발생할 수 있습니다.
ACX7000 시리즈 디바이스는 port-data.
레이어 2 VPN/유사 회선 터널 종료의 경우, 최대 2개의 레이블이 해싱에 사용되며 페이로드 MAC 목적지와 소스 주소를 선택적으로 선택할 수 있습니다. 이러한 컨트롤은 위에 표시된 해시 키 구성에서 제품군 mpls에서 ether-pseudowire 노브를 지원하는 데 사용할 수 있습니다. 그러나 ACX2000 및 ACX4000은 TDM 유사 회선을 지원하므로 ether-pseudowire 노브는 TDM 유사 회선을 사용하지 않을 때만 사용해야 합니다.
레이어 3 VPN 터널 종료의 경우, 보유 및 페이로드 IP 소스 및 대상 주소에 최대 2개의 레이블이 사용되며 레이어 4 소스 및 대상 포트를 선택적으로 선택할 수 있습니다. 이러한 컨트롤은 위에 표시된 해시 키 구성에서 family mpls의 ip 포트 데이터 노브를 지원하는 데 사용할 수 있습니다. 그러나 레이어 4 포트 MSB 및 LSB는 개별적으로 선택할 수 없으므로 destination-lsb 또는 destination-msb 노브 또는 source-lsb 또는 source-msb 노브 중 하나가 각각 레이어 4 대상 또는 소스 포트를 선택합니다.
LSR의 경우 최대 3개의 레이블이 해싱에 사용됩니다. 처음 세 레이블을 구문 분석할 때 BOS가 보이면 BCM은 페이로드의 첫 번째 니블을 검사합니다. 니블이 4인 경우 페이로드는 IPv4로 처리되고 첫 번째 니블이 6이면 페이로드는 IPv6으로 처리되며 이러한 경우 페이로드 소스 및 대상 IP 주소가 해싱에 추측적으로 사용될 수 있습니다. 이러한 컨트롤은 해시 키 구성에서 제품군 mpls의 ip 포트 데이터 노브를 지원하는 데 사용할 수 있습니다. 그러나 레이어 4 포트는 LSR의 경우 해싱에 사용할 수 없으며 레이어 3 전용 노브만 적용됩니다. BCM은 세 개의 MPLS 레이블을 초과하는 필드에 대한 해싱 지원을 주장하지 않습니다. LSR의 경우 단일 유사 회선 세션에 대한 로드 밸런싱이 수행되지 않으며, 해당 세션과 관련된 모든 트래픽이 동일한 MPLS 레이블 세트를 전달하기 때문입니다.
LSR AE 인터페이스의 로드 밸런싱은 더 많은 수의 MPLS 세션, 즉 최소 10개 세션에 대해 달성할 수 있습니다. 이는 CCC/VPLS/L3VPN에 적용됩니다. 레이어 3 VPN의 경우, 레이어 3 주소도 해시 입력 기능에 대해 레이블과 함께 설명되므로 트래픽이 멤버 링크 전체에 균등하게 분산되지 않을 수 있습니다.
LER 시나리오의 경우, ACX5048 및 ACX5096의 경우 "family mpls" 계층 아래 payload 옵션을 구성하여 레이어 3 및 레이어 4 필드를 기반으로 해싱할 수 있습니다. LER의 해싱은 레이블을 기반으로 하지 않습니다. 레이어 3 서비스의 경우 페이로드를 "레이어 3 전용"으로 언급하고 레이어 4 서비스의 경우 "port-data"를 지정해야 합니다. 또한 LER 라우터에서 해시 키를 구성하는 동안 레이블 수를 언급할 수 있습니다.
LER 및 LSR 로드 밸런싱 동작은 CCC/VPLS/레이어 3 VPN 및 기타 IP MPLS 시나리오에 적용됩니다.
이 기능은 어그리게이션 이더넷 및 어그리게이션 SONET/SDH 인터페이스에 적용됩니다. 또한 레이어 2 이더넷 유사 회선을 통해 IPv4 트래픽에 대한 로드 밸런싱을 구성할 수 있습니다. 또한 IP 정보를 기반으로 이더넷 유사 회선에 대한 로드 밸런싱을 구성할 수도 있습니다. 해시 키에 IP 정보를 포함하는 옵션은 이더넷 서킷 크로스 커넥트(CCC) 연결을 지원합니다.
| 성명서 |
MPLS LSP 로드 밸런싱 옵션 |
|---|---|
|
|
해시 키에 첫 번째 레이블을 포함합니다. 단일 레이블 패킷에 이 옵션을 사용합니다. |
|
|
해시 키에 두 번째 레이블을 포함합니다. 또한 옵션을 구성 |
|
|
해시 키에 세 번째 레이블을 포함합니다. 또한 옵션과 옵션을 구성 |
|
|
해시 키에서 MPLS 레이블을 제외합니다. |
|
|
해시 키에 포함할 IP 패킷 페이로드의 일부를 구성할 수 있습니다. PTX 시리즈 패킷 전송 스위치의 경우, 이 값은 기본적으로 설정됩니다. |
|
|
해시 키에서 IP 페이로드를 제외합니다. |
|
|
레이어 2 이더넷 유사 회선을 통한 IPv4 트래픽 로드 밸런싱. |
|
|
해시 키에 IPv4 또는 IPv6 주소를 포함합니다. 또한 또는 |
|
|
해시 키에는 레이어 3 IP 정보만 포함합니다. 해시 키에서 모든 |
|
|
소스 및 대상 포트 필드 정보를 포함합니다. 기본적으로 소스 및 대상 포트 필드의 최상위 바이트와 최소 바이트가 해시 키에 사용됩니다. 해시 키에 사용할 특정 바이트를 선택하려면 계층 수준에서 |
|
|
해시 키에 대상 포트의 최하위 바이트를 포함합니다. 다른 |
|
|
해시 키에 대상 포트의 가장 중요한 바이트를 포함합니다. 다른 |
|
|
해시 키에 소스 포트의 최하위 바이트를 포함합니다. 다른 |
|
|
해시 키에 소스 포트의 가장 중요한 바이트를 포함합니다. 다른 |
해시 키에 IP 주소와 첫 번째 레이블을 포함하려면, 계층 수준에서 문과 ip 문을 위한 payload 옵션을 구성 label-1 합니다.[edit forwarding-options hash-key family mpls]
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
해시 키에 IP 주소와 첫 번째 및 두 번째 레이블을 모두 포함하려면, 계층 수준에서 문에 대한 payload and label-2 옵션과 ip 옵션을 구성 label-1 합니다.[edit forwarding-options hash-key family mpls]
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
계층 수준에서 , label-2, 및 label-3 옵션을 포함하여 label-1적절한 로드 밸런싱을 보장합니다.[edit forwarding-options hash-key family mpls]
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
MPLS 캡슐화 페이로드 로드 밸런싱 개요
라우터는 MPLS에서 패킷당 기준으로 로드 밸런싱을 수행할 수 있습니다. 로드 밸런싱은 IP 헤더와 최대 3개의 MPLS 레이블 모두에 있는 정보에 대해 수행될 수 있으며, 이를 통해 다음 홉으로 보다 균일한 MPLS 트래픽을 배포할 수 있습니다.
로드 밸런싱은 다음 조건이 적용될 때 트래픽을 균등하게 분산하는 데 사용됩니다.
-
동일한 대상에 대한 서로 다른 인터페이스를 통해 여러 개의 동일 비용 다음 홉이 있습니다.
-
어그리게이션 인터페이스를 통해 단일 다음 홉이 있습니다.
기본적으로 로드 밸런싱을 사용하여 트래픽을 분산하는 경우 해시 알고리즘을 사용하여 포워딩 테이블에 설치할 다음 홉 주소를 선택합니다. 대상에 대한 다음 홉 집합이 어떤 식으로든 변경될 때마다 다음 홉 주소는 해시 알고리즘을 통해 다시 선택됩니다.
MPLS를 통한 이더넷 또는 이더넷 유사 회선과 같은 다중 전송 계층 네트워크의 경우, 해시 알고리즘은 페이로드의 외부 헤더를 넘어 내부 헤더를 살펴보고 균일한 분포를 생성해야 합니다. 내부 캡슐화를 결정하기 위해 PFE는 고정된 페이로드 오프켓에서 특정 코드 또는 숫자의 존재에 의존합니다. 예를 들어 IPv4 패킷에 대한 페이로드 유형 0X800 또는 프로토콜 번호 4의 존재 여부가 있습니다. Junos OS에서는 MPLS ether-pseudowire 페이로드에서 이더넷 프레임의 시작을 나타내는 옵션을 구성할 zero-control-word 수 있습니다. 숫자 값이 모두 0인 4바이트인 이 제어 단어를 확인하면, 해시 생성기는 MPLS ether-pseudowire 패킷에서 제어 단어의 끝에서 이더넷 프레임의 시작을 가정합니다.
DPC I-칩 기반 카드의 경우 계층 수준에서 옵션을 구성 zero-control-word 하고, MPC 카드의 경우 계층 수준에서 [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] 옵션을 구성 zero-control-word [edit forwarding-options hash-key family mpls ether-pseudowire] 합니다.
로드 밸런싱을 위한 MPLS 캡슐화 페이로드 구성
기본적으로 로드 밸런싱을 사용하여 트래픽을 분산하는 경우 해시 알고리즘을 사용하여 포워딩 테이블에 설치할 다음 홉 주소를 선택합니다. 대상에 대한 다음 홉 집합이 어떤 식으로든 변경될 때마다 다음 홉 주소는 해시 알고리즘을 통해 다시 선택됩니다. MPLS ether-pseudowire 페이로드에서 이더넷 프레임의 시작을 나타내는 옵션을 구성 zero-control-word 합니다. 숫자 값이 모두 0인 4바이트인 이 제어 단어를 볼 때, 해시 생성기는 MPLS 이더넷 유사 회선 패킷에서 제어 단어의 끝에서 이더넷 프레임의 시작을 가정합니다.
로드 밸런싱을 위해 MPLS 캡슐화 페이로드 구성을 시작하기 전에 라우팅 및 신호 프로토콜을 구성하십시오.
로드 밸런싱을 위해 MPLS 캡슐화 페이로드를 구성하려면 다음을 수행합니다.
zero-control-word 합니다.
-
DPC I-칩 기반 카드의 경우, 계층 수준에서 옵션을 구성
zero-control-word합니다.[edit forwarding-options hash-key family mpls ether-pseudowire][edit forwarding-options hash-key family mpls ether-pseudowire] user@host# set zero-control-word
-
MPC 카드의 경우, 계층 수준에서 옵션을 구성
zero-control-word합니다.[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire][edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] user@host# set zero-control-word
정책 기반 다중 경로 경로 개요
세그먼트 라우팅 네트워크의 코어에는 여러 전송 프로토콜이 있을 수 있습니다. 세그먼트 라우팅 SR-TE LDP 또는 RSVP 경로와 SR-TE IP 경로를 결합하고 라우팅 정보 베이스(라우팅 테이블라고도 함)에 다중 경로 경로를 설치할 수 있습니다. 그런 다음 정책 구성을 통해 다중 경로 경로를 사용하여 선택적 서비스 트래픽을 조정할 수 있습니다.
- 정책 기반 다중 경로 경로 이해
- 정책 기반 다중 경로 라우팅의 이점
- 경로 확인을 위한 정책 기반 다중 경로 라우팅
- 정책 기반 다중 경로 경로를 사용한 샘플 경로 확인
- CoS(Class-of-Service) 포워딩 정책 개선
- 정책 일치 프로토콜 개선 사항
- 정책 기반 다중 경로 라우팅 구성이 네트워크 성능에 미치는 영향
정책 기반 다중 경로 경로 이해
네트워크에는 서비스 트래픽을 해결하는 데 사용되는 IGP, 레이블링된 IGP, RSVP, LDP 및 세그먼트 라우팅 트래픽 엔지니어링(SR-TE) 프로토콜과 같은 다양한 전송 프로토콜이 있습니다. 그러나 서비스 트래픽을 해결하기 위해 전송 프로토콜의 조합을 사용할 수는 없습니다. 정책 기반 다중 경로 기능이 도입됨에 따라 세그먼트 라우팅 트래픽 엔지니어링(SR-TE) LDP 또는 RSVP 경로와 SR-TE IP 경로를 결합하여 라우팅 정보 베이스에 설치되는 다중 경로 경로를 생성할 수 있습니다. 정책 구성을 통해 다중 경로 경로를 통해 BGP 서비스 경로를 해결하고 다른 접두사에 대해 트래픽을 다르게 조정할 수 있습니다.
다중 경로 경로는 로드 밸런싱에 사용되는 경로 항목의 다음 홉을 결합했습니다. 다중 경로 경로 항목의 모든 지원 경로는 동일한 라우팅 정보 베이스에 있어야 합니다. 지원 경로가 다른 라우팅 정보 베이스에 있는 경우 구성 문을 사용하여 rib-group 특정 라우팅 정보 베이스에 경로 항목을 추가할 수 있습니다.
정책을 사용하여 다중 경로 경로를 구성하여 다음 홉이 함께 결합될 경로 목록을 선택할 수 있습니다. 계층 수준에서 [edit routing-options rib routing-table-name] 문과 policy 함께 문을 포함 policy-multipath 하면 정책 기반 다중 경로 경로가 생성됩니다.
정책 기반 다중 경로 기능은 IP 및 IPv6 프로토콜 모두에 대해 지원되며 계층 수준에서 [edit routing-instances] 구성할 수 있습니다.
예를 들면 다음과 같습니다.
[edit routing-options] user@host# set rib inet.3 policy-multipath policy example-policy [edit policy-options] user@host# set policy-statement example-policy from example-conditions user@host# set policy-options policy-statement example-policy then accept
구성된 정책은 주어진 접두사에 대한 각 경로 항목에 적용됩니다. 다중 경로 경로는 둘 이상의 경로(활성 경로 포함)가 정책을 통과할 때만 생성됩니다. 정책에 구성된 모든 작업 명령(예: 적용)은 활성 경로를 사용하여 평가됩니다. 비활성 경로의 경우, 경로가 다중 경로 경로에 참여할 수 있는지 여부를 확인하기 위해 정책이 적용됩니다. 다중 경로 라우팅은 활성 경로의 모든 속성을 상속합니다. 이러한 속성은 다중 경로 정책 구성을 사용하여 수정할 수 있습니다.
policy-multipath, Junos OS 및 Junos OS Evolved는 활성 경로의 기본 설정을 사용하는 대신 적격 경로 중에서 가장 적은 선호(가장 높은 수치) 경로의 선호 값을 할당합니다. 경로에 대한
policy-multipath 정책을 통해 적용된 사용자 구성 기본 설정을 무시하고 항상 적격 경로 항목에서 가장 높은 기본 설정 값을 적용합니다.
Junos OS 및 Junos OS Evolved는 로 구성된 policy-multipathBGP 경로에 대한 메트릭 2 값을 올바르게 보고합니다. 경로의 활성 접두사가 SR-TE이고 확인 중인 경우, 시스템은 경로 메트릭에 메트릭 2 값을 정확하게 반영합니다. 이러한 수정을 통해 라우팅 결정이 정확한 지표를 기반으로 하여 전반적인 네트워크 성능과 안정성을 향상시킬 수 있습니다.
정책 기반 다중 경로 라우팅의 이점
-
코어 네트워크 프로토콜을 결합하여 선택적 트래픽을 조정할 수 있는 유연성을 제공합니다.
-
다중 경로 경로를 사용하여 가중치가 적용된 균등비용 다중 경로로 네트워크 성능을 최적화합니다.
경로 확인을 위한 정책 기반 다중 경로 라우팅
세그먼트 라우팅 트래픽 엔지니어링(SR-TE) LDP 또는 RSVP 경로와 SR-TE IP 경로를 결합하고 라우팅 정보 베이스에 다중 경로 경로를 설치할 수 있습니다. 정책 기반 다중 경로 경로는 라우팅 정보 베이스의 활성 항목이 아닙니다. 정책 구성에 의해 다중 경로 경로가 생성되면 활성 경로 대신 프로토콜 다음 홉을 해결하는 데 사용됩니다. 다중 경로 경로 다음 홉은 각 구성 경로의 다음 홉 게이트웨이를 병합하여 생성됩니다.
경로 해결을 위해 정책 기반 다중 경로 경로를 구성할 때 다음 사항을 고려하십시오.
-
다중 경로 경로의 멤버 경로가 라우터 다음 홉 이외의 다음 홉 또는 다음 홉을 라우터 다음 홉으로 포워딩하는 간접 라우터 다음 홉을 가리키는 경우, 이러한 다음 홉은 무시됩니다.
-
구성 경로가 간접 다음 홉을 가리키는 경우 forwarding-next 홉의 게이트웨이가 병합되고 간접 다음 홉은 무시됩니다.
-
총 게이트웨이 수가 디바이스에서 지원되는 수를
maximum-ecmp초과하면 게이트웨이만maximum-ecmp유지되고 다른 모든 게이트웨이는 무시됩니다. -
가중치가 낮은 게이트웨이가 선호됩니다. 멤버 경로 중 하나에 간접 다음 홉의 단일리스트가 있고 각 다음 홉이 포워딩 다음 홉을 가리키고 있는 경우, 간접 다음 홉과 포워딩 다음 홉 모두에 가중치 값이 있을 수 있습니다. 이러한 경우 게이트웨이의 가중치 값은 두 수준에서 가중치의 결합 효과를 반영하도록 업데이트됩니다.
정책 기반 다중 경로 경로를 사용한 샘플 경로 확인
예를 들어, 아래 출력에 표시된 바와 같이 목적지 10.1.1.1/32에 대한 세그먼트 라우팅 트래픽 엔지니어링 LSP, 레이블 IS-IS 경로 및 LDP LSP가 있다고 가정해 보겠습니다.
10.1.1.1/32 *[SPRING-TE/8] 00:00:58, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:15:57, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:09:27, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
여기서 세그먼트 라우팅 LSP는 10.1.1.1 목적지에 대한 활성 경로 항목이며, 기본적으로 이 경로만 10.1.1.1을 통해 해결되는 모든 서비스를 해결하는 데 사용됩니다.
서비스 경로를 해결하기 위해 둘 이상의 프로토콜을 사용해야 하는 경우, 프로토콜을 결합하도록 정책 다중 경로 를 구성하여 이를 달성할 수 있습니다. 예를 들어, 서비스 해결을 위해 세그먼트 라우팅 및 LDP 경로가 필요한 경우, 접두사 10.1.1.1에 대한 세그먼트 라우팅 및 LDP 경로를 결합하도록 구성 policy-multipath 해야 합니다.
예를 들면 다음과 같습니다.
[edit policy-options] user@host# set rib inet.3 policy-multipath policy example-policy user@host# set policy-statement abc term 1 from protocol spring-te user@host# set policy-statement abc term 1 from protocol ldp user@host# set policy-statement abc term 1 from route-filter 10.1.1.1/32 exact user@host# set policy-statement abc term 1 then accept
이 구성을 통해 세그먼트 라우팅 및 LDP 프로토콜의 구성 경로 항목을 사용하는 접두사 10.1.1.1/32에 대한 정책 기반 다중 경로 경로를 생성합니다.
다음과 같이 명령 출력을 사용하여 show route 다중 경로 경로를 볼 수 있습니다.
10.1.1.1/32 *[SPRING-TE/8] 00:10:28, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:25:27, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:18:57, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[Multipath/8] 00:03:13, metric 1, metric2 30
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
명령 출력에서 다중 경로 경로가 세그먼트 라우팅과 LDP 경로의 다음 홉을 결합한다는 것을 확인할 수 있습니다. 다중 경로 경로는 활성화되지 않으며 기본적으로 경로 기본 설정 및 메트릭은 활성 경로와 동일합니다.
poilcy 기반 다중 경로 경로에 대해 다음과 같은 조합을 사용할 수 있습니다. 그러나 active-route는 다중 경로의 일부가 아니므로 LDP/L-IS-IS의 다중 경로를 생성할 수 없습니다.
-
세그먼트 라우팅 트래픽 엔지니어링 LSP 및 LDP LSP.
-
세그먼트 라우팅 트래픽 엔지니어링 LSP 및 레이블 IS-IS 경로.
-
세그먼트 라우팅 트래픽 엔지니어링 LSP, LDP LSP 및 레이블 IS-IS 경로.
그러나 활성 경로가 다중 경로 경로의 일부가 아니므로 LDP의 다중 경로 경로를 생성하고 IS-IS에 레이블을 지정할 수 없습니다.
동일한 구성에서 프로토콜 다음 홉 10.1.1.1로 구성된 정적 경로 1.2.3.4/32가 있다고 가정하면, 이 경로는 세그먼트 라우팅 트래픽 엔지니어링 LSP와 LDP LSP 모두에서 다중 경로 경로를 사용하여 해결됩니다.
예를 들면 다음과 같습니다.
10.1.3.4/32 *[Static/5] 00:00:12, metric2 1
to 10.12.1.1 via ge-0/0/0.1
> to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
CoS(Class-of-Service) 포워딩 정책 개선
서비스 등급 기반 포워딩의 경우, 구성 문을 사용해야 forwarding-policy next-hop-map 합니다.
Junos OS 릴리스 19.1R1 이전에는 서비스 등급 기반 포워딩에서 지원되는 일치 조건이 다음과 같습니다.
-
next-hop- 발신 인터페이스 또는 다음 홉 주소를 기반으로 다음 홉을 일치시킵니다.
-
lsp-next-hop- LSP 이름의 정규식을 사용하여 명명된 LSP를 일치시킵니다.
-
non-lsp-next-hop- LSP 이름이 없는 모든 LSP를 일치시킵니다.
정책 기반 다중 경로 경로 기능을 사용하면 특정 접두사에 대한 레이블 없이 모든 다음 홉을 일치시킬 수도 있습니다. 이렇게 하려면 계층 수준에서 옵션을 활성화 non-labelled-next-hop 해야 [edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name 합니다.
예를 들면 다음과 같습니다.
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
정책 일치 프로토콜 개선 사항
Junos OS 릴리스 19.1R1 이전에는 정책을 사용하여 계층 수준에서 [edit policy-options policy-statement statement-name] 문을 사용하여 from protocol 프로토콜을 일치시키면 모든 프로토콜 경로(레이블이 지정된 경로와 레이블가 지정되지 않은 프로토콜 경로)가 일치했습니다. 정책 기반 다중 경로 경로 기능을 사용하면 레이블이 지정된 프로토콜 경로를 구체적으로 일치시킬 수 있습니다.
레이블이 지정된 프로토콜을 일치시키기 위한 옵션은 다음과 같습니다.
-
l-isis- 레이블이 지정된 IS-IS 경로와 일치합니다. 이
isis옵션은 레이블 IS-IS 경로를 제외한 IS-IS 경로와 일치합니다. -
l-ospf—레이블된 OSPF 경로를 일치시킵니다. 이
ospf옵션은 OSPFv2, OSPFv3 및 레이블 OSPF를 포함한 모든 OSPF 경로와 일치합니다.
예를 들면 다음과 같습니다.
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
정책 기반 다중 경로 라우팅 구성이 네트워크 성능에 미치는 영향
정책 기반 다중 경로 경로를 구성할 때 라우팅 정보 베이스의 경로가 변경되면 정책이 평가되어 다중 경로 경로를 생성해야 하는지 확인합니다. 이 기능을 사용하려면 멤버 경로가 동일한 라우팅 정보 베이스에 있어야 하므로 문은 rib-group 다른 라우팅 정보 베이스의 경로를 병합하는 데 사용됩니다. 애플리케이션 수준에서 문을 구성 rib-group 하면 시스템의 경로 수가 늘어납니다.
라우팅 정보 베이스에 여러 경로가 있는 경우 경로를 지속적으로 변경하면 다중 경로 정책이 재평가됩니다. 이는 네트워크 성능에 영향을 미칠 수 있습니다. 필요한 경우에만 정책 기반 다중 경로 경로 기능을 구성하는 것이 좋습니다.
MPLS 트래픽의 IP 기반 필터링 및 선택적 포트 미러링 이해
MPLS 패킷에서 IP 헤더는 MPLS 헤더 바로 뒤에 옵니다. IP 기반 필터링 기능은 내부 페이로드의 최대 8개의 MPLS 레이블을 검사하여 IP 매개 변수를 기반으로 MPLS 트래픽을 필터링할 수 있는 심층 검사 메커니즘을 제공합니다. 필터링된 MPLS 트래픽은 또한 모니터링 디바이스로 포트 미러링되어 코어 MPLS 네트워크에서 네트워크 기반 서비스를 제공할 수 있습니다.
IP 기반 MPLS 트래픽 필터링
Junos OS 릴리스 18.4R1 이전에는 IP 매개 변수를 기반으로 한 필터링이 MPLS 제품군 필터에 지원되지 않았습니다. IP 기반 필터링 기능이 도입됨에 따라 소스 및 대상 주소, 레이어 4 프로토콜 유형, 소스 및 대상 포트와 같은 IP 매개 변수를 기반으로 MPLS 태그가 지정된 IPv4 및 IPv6 패킷에 인바운드 및 아웃바운드 필터를 적용할 수 있습니다.
IP 기반 필터링 기능을 사용하면 인터페이스 수신 시 MPLS 패킷을 필터링할 수 있으며, 여기서 필터링은 MPLS 패킷의 내부 페이로드에 대한 일치 조건을 사용하여 수행됩니다. 그런 다음 선택적 MPLS 트래픽을 논리 터널을 사용하여 원격 모니터링 디바이스로 포트 미러링할 수 있습니다.
IP 기반 필터링을 지원하기 위해 적절한 필터가 적용되기 전에 레이어 3 및 레이어 4 헤더로 내부 페이로드를 구문 분석하기 위해 MPLS 패킷을 심층 검사할 수 있는 추가 일치 조건이 추가되었습니다.
IP 기반 필터링 기능은 MPLS 태그가 지정된 IPv4 및 IPv6 패킷에서만 지원됩니다. 즉, MPLS 필터는 IP 페이로드가 MPLS 레이블 바로 뒤에 올 때만 MPLS 매개 변수와 일치합니다.
MPLS 페이로드가 유사 회선, inet 및 inet6 이외의 프로토콜 또는 레이어 2 VPN 또는 VPLS와 같은 기타 캡슐화를 포함하는 다른 시나리오에서는 IP 기반 필터링 기능이 지원되지 않습니다.
MPLS 트래픽의 IP 기반 필터링을 위해 다음과 같은 일치 조건이 추가되었습니다.
-
IPv4 소스 주소
-
IPv4 대상 주소
-
IPv6 소스 주소
-
IPv6 대상 주소
-
프로토콜
-
소스 포트
-
목적지 포트
-
소스 IPv4 접두사 목록
-
대상 IPv4 접두사 목록
-
소스 IPv6 접두사 목록
-
대상 IPv6 접두사 목록
MPLS 트래픽의 IP 기반 필터링에는 다음과 같은 일치 조합이 지원됩니다.
-
소스 및 대상 주소는 IPv4 및 IPv6 접두사 목록과 조건이 일치합니다.
-
소스 및 대상 포트 주소와 프로토콜 유형이 IPv4 및 IPv6 접두사 목록과 조건이 일치합니다.
MPLS 트래픽의 선택적 포트 미러링
포트 미러링은 패킷의 정상적인 처리 및 전달 외에 구성된 대상으로 패킷을 미러링하는 기능입니다. 포트 미러링은 방화벽 필터에 대한 작업으로 적용되며, 이는 모든 인터페이스의 수신 또는 송신에 적용됩니다. 마찬가지로, 선택적 포트 미러링 기능은 IP 매개 변수를 기반으로 필터링되는 MPLS 트래픽을 논리 터널을 사용하여 미러링된 대상으로 미러링하는 기능을 제공합니다.
선택적 포트 미러링을 활성화하기 위해 기존counter의 , accept및 discard 작업 외에 계층 수준에서 [edit firewall family mpls filter filter-nameterm term-name then] 추가 작업이 구성됩니다.
-
port-mirror -
port-mirror-instance
Port Mirroring
이 port-mirror 작업을 통해 디바이스에서 전역으로 포트 미러링이 활성화되며, 이는 모든 패킷 전달 엔진(PFE) 및 관련 인터페이스에 적용됩니다.
MPLS 제품군 필터의 경우, port-mirror 글로벌 포트 미러링에 대한 작업이 활성화됩니다.
Port Mirroring Instance
이 port-mirror-instance 작업을 통해 포트 미러링을 위해 단일 시스템 전체 구성을 사용하는 대신 입력 샘플링 및 포트 미러링 출력 대상에 대해 서로 다른 속성으로 각 인스턴스를 사용자 지정할 수 있습니다.
계층 수준에서 [edit forwarding-options port-mirror] 문을 포함하여 instance port-mirror-instance-name FPC(Flexible PIC Concentrator)당 2개의 포트 미러링 인스턴스만 구성할 수 있습니다. 그런 다음 디바이스 하드웨어에 따라 개별 포트 미러링 인스턴스를 FPC, PIC 또는 (FEB(포워딩 엔진 보드)와 연결할 수 있습니다.
MPLS 제품군 필터의 경우, port-mirror-instance 이 작업은 포트 미러링 인스턴스에 대해서만 활성화됩니다.
두 작업 port-mirror-instance 모두 port-mirror 에서 선택적 포트 미러링 기능이 작동하려면 출력 인터페이스가 제품군 MPLS(레이어 3)가 아닌 레이어 2 제품군으로 활성화되어야 합니다.
샘플 구성
IP 기반 필터링 구성
[edit firewall family mpls filter mpls-filter]
term ipv4-term {
from {
ip-version {
ipv4 {
source-address {
10.10.10.10/24;
}
destination-address {
20.20.20.20/24;
}
protocol tcp {
source-port 100;
destination-port 200;
}
soure-prefix-list ipv4-source-users;
destination-prefix-list ipv4-destination-users;
}
}
exp 1;
}
then port-mirror;
then accept;
then count;
}
term ipv6-term {
from {
ip-version {
ipv6 {
source-address {
2000::1/128;
}
destination-address {
3000::1/128;
}
protocol tcp {
source-port 100;
destination-port 200;
}
source-prefix-list ipv6-source-users;
destination-prefix-list ipv6-destination-users;
}
}
exp 1;
}
then port-mirror-instance port-mirror-instance1;
then accept;
then count;
}
[edit policy-options]
prefix-list ipv4-source-users {
172.16.1.16/28;
172.16.2.16/28;
}
prefix-list ipv6-source-users {
2001::1/128;
3001::1/128;
}
[edit interfaces]
xe-0/0/1 {
unit 0 {
family inet {
address 100.100.100.1/30;
}
family mpls {
filter {
input mpls-filter;
}
}
}
}
선택적 포트 미러링 구성
[edit forwarding-options]
port-mirroring {
input {
rate 2;
run-length 4;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
[edit forwarding-options]
port-mirroring {
instance {
port-mirror-instance1 {
input {
rate 3;
run-length 5;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
}
}
출력 인터페이스 xe-2/0/2.0 는 패밀리 MPLS가 아닌 레이어 2 패밀리에 대해 구성됩니다.
두 작업 port-mirror-instance 모두 port-mirror 에서 선택적 포트 미러링 기능이 작동하려면 출력 인터페이스가 제품군 MPLS(레이어 3)가 아닌 레이어 2 제품군으로 활성화되어야 합니다.
미러링된 대상 구성
[edit interfaces]
xe-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
[edit bridge-domains]
bd {
domain-type bridge;
interface xe-2/0/2.0;
}
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.