Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

LSP 레이블

MPLS Label 개요

LSP를 따라 이동하는 패킷은 레이블(20비트, 범위 0 ~ 1,048,575)의 비인가 정수로 식별됩니다. ingress 라우터의 푸시 레이블의 경우 이 범위의 레이블을 제한하지 않습니다. 전송 정적 LSP에서 수신 레이블의 경우 레이블 값은 1,000,000~1,048,575로 제한됩니다.

MX 시리즈, PTX 시리즈 및 T 시리즈 라우터에서 인트로피 및 플로우 레이블의 값은 16에서 1,048,575로 제한됩니다.

MPLS 레이블 할당

이 Junos OS 라우터 또는 스위치당 레이블 값이 할당됩니다. 이 설명의 나머지는 라우터를 사용하여 두 가지 모두를 모두 커버합니다. 디스플레이 출력에는 레이블만 표시됩니다(예: 01024 멀티캐스트 패킷에 대한 레이블은 유니캐스트 패킷의 레이블과 독립적입니다. 현재, Junos OS 레이블은 지원하지 않습니다.

패킷 플로우와 연계된 다운스트림 라우터에 의해 레이블이 할당됩니다. 레이블이 지정된 패킷을 수신하는 라우터(넥스 홉 라우터)는 수신 레이블을 할당하는 역할을 담당합니다. 인식되지 않는 레이블(미해지)을 포함하는 수신 패킷은 삭제됩니다. 인식되지 않은 레이블의 경우 라우터는 레이블을 분석하여 네트워크 레이어 헤더를 분석하려고 시도하지 않으며, ICMP(Internet Control Message Protocol) 대상 메시지를 생성하지도 않습니다.

패킷은 마지막 스택으로 구성되는 많은 레이블을 전달할 수 있습니다. 이를 Label 스택이라고 합니다. 특정 라우터에서, 라벨링된 패킷을 포용하는 방법에 대한 결정은 스택 맨 위에 있는 Label에 독점적으로 기반이 됩니다.

그림 1 은 단일 레이블의 인코딩을 보여줍니다. 인코딩은 데이터 링크 레이어 헤더 이후, 네트워크 레이어 헤더 이전으로 나타납니다.

그림 1: 레이블 인코딩레이블 인코딩

그림 2 서비스 등급 비트(EXP 또는 실험 비트)의 용도를 설명합니다. Bits 20 및 21은 큐 번호를 지정합니다. 비트 22는 RED(Random Early Detection) 드롭 프로파일을 지정하는 데 사용되는 PLP(Packet Loss Priority) 비트입니다. 서비스 등급 및 CoS(Class-of-Service)비트에 대한 자세한 내용은 LSP를 위한 서비스 등급 MPLS 참조하십시오.

그림 2: 서비스 등급 비트서비스 등급 비트

레이블에서 MPLS 작업

라우터는 다음과 같은 레이블 작업을 지원합니다.

  • 푸시—패킷 맨 위에 새로운 레이블을 추가합니다. IPv4 패킷의 경우, 새로운 레이블은 첫 번째 레이블입니다. TTL(Time-to-Live) 및 비트는 IP 패킷 헤더에서 파생됩니다. CoS(MPLS 서비스 등급)는 큐 번호에서 파생됩니다. 푸시 작업이 기존 패킷에서 수행되는 MPLS, 2개 이상의 레이블이 있는 패킷이 있는 것입니다. 이를 레이블 스태킹(Label Stacking)이라고 합니다. 상단 레이블은 비트 세트를 0으로 설정해야 합니다. 하위 수준에서 CoS 및 TTL을 파생할 수 있습니다. Label 스택 내 새로운 Top Label은 항상 TTL을 255로 초기화합니다.

  • Pop—패킷 시작에서 레이블을 제거합니다. 레이블이 제거되면 TTL은 Label에서 IP 패킷 헤더로 복사되고 기본 IP 패킷이 네이티브 IP 패킷으로 전달됩니다. 패킷(Label Stacking)에 있는 여러 레이블의 경우, 상단 레이블을 제거하면 다른 패킷 MPLS 수 있습니다. 새로운 Top Label은 이전 상단 레이블에서 CoS 및 TTL을 파생할 수 있습니다. 이전의 상위 Label에서 popped TTL 값은 다시 새로운 상위 레이블로 작성되지 않습니다.

  • 스왑—Label 스택 맨 위에 있는 Label을 새 Label으로 교체합니다. S 및 CoS 비트는 이전 Label에서 복사되고 TTL 값이 복사 및 감소됩니다(명령문이 구성되지 않는 no-decrement-ttlno-propagate-ttl 한). 전송 라우터는 모든 깊이의 Label 스택을 지원

  • 다중 푸시—기존 패킷 위에 여러 레이블(최대 3개까지)을 추가합니다. 이 작업은 여러 번 푸시하는 데 동일합니다.

  • 스왑 및 푸시—기존 Label 스택의 맨 위에 새로운 Label을 추가한 다음, 상단에 또 다른 레이블을 푸시합니다.

레이블 MPLS 이해

기존의 패킷 포링 패러다임에서 패킷이 스위치에서 다음 스위치로 이동하면 각 홉에서 독립적인 포우링 결정이 내리게 됩니다. IP 네트워크 헤더를 분석하고 이 분석을 기반으로 다음 홉을 선택하며 라우팅 테이블의 정보에 따라 선택됩니다. 네트워크 MPLS 환경에서 패킷 헤더 분석은 패킷이 MPLS 터널에 들어갈 때 한 번만 수행됩니다(즉, 트래픽과 트래픽에 사용되는 MPLS 합니다.

IP 패킷이 LSP(Label-Switched Path)에 들어오면 수신 PE(Provider Edge) 스위치가 패킷을 검사하고 대상을 기준으로 Label을 할당하여 패킷의 헤더에 레이블을 배치합니다. 이 레이블은 IP 라우팅 정보를 기반으로 전달되는 패킷에서 레이블과 연관된 정보를 기반으로 전달되는 패킷으로 변환합니다. 그런 다음 패킷은 LSP의 다음 제공업체 스위치로 전달됩니다. 이 스위치와 LSP의 모든 후속 스위치는 라벨링된 패킷의 IP 라우팅 정보를 조사하지 않습니다. 오히려, 레이블을 사용하여 레이블 포워들 테이블에서 정보를 찾아야 합니다. 그런 다음 이전 레이블을 새로운 레이블로 교체하고 패킷을 경로의 다음 스위치로 전달합니다. 패킷이 egress PE 스위치에 도달하면 레이블이 제거되고 패킷이 다시 네이티브 IP 패킷이 되고 IP 라우팅 정보를 기반으로 포워드됩니다.

이 주제는 다음을 설명합니다.

MPLS 레이블 스위칭 경로 및 MPLS 레이블

패킷이 네트워크로 MPLS LSP에 할당됩니다. 각 LSP는 LSP의 전면에 짧은(20비트), 고정 길이 값(MPLS 32비트)으로 식별됩니다. 레이블은 Label 포워싱 테이블에 대한 룩업 인덱스로 사용됩니다. 각 레이블에 대해 이 테이블은 포우링 정보를 저장합니다. 캡슐화된 패킷에서 추가 파스킹 또는 룩업이 수행되지 MPLS 패킷 페이로드 내의 다른 프로토콜의 전송을 지원할 수 있습니다.

그림 3 단일 레이블의 인코딩을 보여줍니다. 인코딩은 데이터 링크 레이어 헤더 이후, 네트워크 레이어 헤더 이전으로 나타납니다.

그림 3: 레이블 인코딩레이블 인코딩

예약 레이블

레이블은 0에서 1,048,575까지 범위가 있습니다. Labels 0 ~ 999,999는 내부 사용을 위한 것입니다.

예약된 레이블 중 일부는(범위 0에서 15까지)는 의미를 잘 정의하고 있습니다. 다음과 같은 예약 레이블은 QFX 시리즈 및 EX4600 디바이스에서 사용됩니다.

  • 0, IPv4 Explicit Null Label—이 값은 유일한 Label 엔트리인 경우(레이블 스태킹이 없는 경우) 유효합니다. 라벨이 수신 시 터지기만 되어야 하다는 표시입니다. IP 버전 4(IPv4) 패킷을 기반으로 포링이 계속됩니다.

  • 1, 라우터 경고 레이블—패킷이 1의 상위 레이블 값과 함께 수신될 때, 처리를 위해 로컬 소프트웨어 모듈로 전달됩니다.

  • 3, Implicit Null Label—이 레이블은 시그널링 프로토콜(RSVP)에서만 다운스트림 스위치의 Label Popping을 요청하는 데 사용됩니다. 실제로 캡슐화에는 나타나지 않습니다. 3 값이 있는 레이블은 데이터 패킷에서 실제 레이블로 사용되어서도 안 됩니다. 이 레이블에는 페이로드 유형(IPv4 또는 IPv6)이 없습니다.

MPLS 레이블 작업

QFX Series 및 EX4600 장치는 다음과 같은 MPLS 레이블 작업을 지원합니다.

  • 밀어

  • 스왑

주:

QFX 및 EX4600 디바이스가 Label 스택에 부착(푸시 작업)을 수행하거나 Label 스택에서 제거(pop 작업)할 수 있는 레이블 수에는 제한이 있습니다.

  • 푸시 작업을 위해—3개의 레이블이 지원됩니다.

  • Pop 작업을 위해—3개의 레이블이 지원됩니다.

푸시 작업은 IP 패킷 맨 위에 새로운 레이블을 부착합니다. IPv4 패킷의 경우, 새로운 레이블은 첫 번째 레이블입니다. 패킷 헤더에서 TTL(Live To Live) 필드 값의 시간은 IP 패킷 헤더에서 도출됩니다. 푸시 작업은 이미 1개 레이블이 있는 패킷에 MPLS 수 없습니다.

POP 작업은 패킷 시작에서 레이블을 제거합니다. 레이블이 제거되고 나면 TTL은 Label에서 IP 패킷 헤더로 복사되고 기본 IP 패킷이 네이티브 IP 패킷으로 전달됩니다.

스왑 연산은 IP 패킷에서 기존 MPLS 레이블을 제거하고 다음에 따라 MPLS 새로운 MPLS 레이블로 대체합니다.

  • 수신 인터페이스

  • 라벨

  • 레이블 포우링 테이블

그림 4 수신 PE 스위치의 고객 에지 인터페이스(ge-0/0/1)에 도착하지 않은 IP 패킷을 보여줍니다. ingress PE 스위치는 패킷을 검사하고 패킷의 대상을 egress PE 스위치로 식별합니다. ingress PE 스위치는 Label 100을 패킷에 적용하고 MPLS 코어 인터페이스(ge-0/0/5)로 MPLS 패킷을 전송합니다. MPLS 패킷은 제공업체 스위치를 통해 MPLS 전송되는 것으로, 인터페이스 ge-0/0/5에 Label 100이 도착합니다. 제공업체 스위치는 Label 100을 Label 200으로 교체하고 코어 인터페이스(ge-0/0/7)를 통해 MPLS 패킷을 egress PE 스위치인 터널의 다음 홉으로 전달합니다. egress PE 스위치는 코어 인터페이스(ge-0/0/7)를 통해 MPLS 패킷을 수신하고, MPLS Label을 제거하고, 고객 에지 인터페이스(ge-0/0/1)에서 터널을 넘어 있는 목적지로 IP 패킷을 전송합니다.

그림 4: MPLS 레이블 스왑 교체MPLS 레이블 스왑 교체

그림 4 수신 PE 스위치에서 egress PE 스위치로의 한 방향으로 통과하는 패킷 경로를 보여줍니다. 그러나 이 MPLS 구성을 통해 트래픽이 역방향으로 이동할 수 있습니다. 따라서 각 PE 스위치는 ingress 스위치와 egress 스위치 모두로 작동됩니다.

Penultimate-Hop Popping 및 Ultimate-Hop Popping

이 스위치는 기본적으로 IP over MPLS PHP(Penultimate-hop popping)MPLS 수 있습니다. PHP를 통해 penultimate 제공업체 스위치는 MPLS 레이블을 파핑하고 트래픽을 egress PE 스위치로 전달합니다. 그런 다음, egress PE 스위치가 IP 루트 룩업을 수행하고 트래픽을 전달합니다. 이는 egress PE 스위치의 프로세싱 부하가 MPLS 때문에 감소합니다.

  • 기본으로 보급된 레이블은 Label 3(Implicit Null Label)입니다. Label 3가 광고되는 경우, Penultimate-hop 스위치는 해당 라벨을 제거하고 egress PE 스위치로 패킷을 전송합니다.

  • 궁극의 홉 포핑이 활성화되면 Label 0(IPv4 Explicit Null Label)이 광고되어 LSP의 egress PE 스위치가 해당 Label을 제거합니다.

주니 MPLS 이해

MPLS Label Manager는 LSI, 동적, 블록 및 정적과 같은 다양한 레이블 유형을 관리하는 데 사용됩니다. 이 유형은 Junos Trio 칩셋이 장착된 모듈형 포트 컨센트러터(MPC)를 사용하여 플랫폼에서 지원됩니다. 이들 라인 카드는 장비에서 명령어를 구성할 때 더욱 뛰어난 유연성과 enhanced-ip 확장성을 제공합니다.

명령의 기존 동작은 그대로 label-space 유지됩니다. 권장되지 않습니다. 각 레이블 유형에 대한 다중 범위와 같은 추가 기능을 제공하기 위해 명령어는 구성에 독립적인 계층 아래에 label-range[edit protocols mpls label usage]label-space 도입됩니다. 각 레이블 유형에 대해 단 하나의 범위만 필요한 경우 두 가지 스타일 중 하나를 선택할 수 있습니다.

장비에서 구성된 명령어에 따라 다음과 같은 enhanced-ip 기능이 최적화됩니다.

  • SRGB(Segment-Routing Global Block)에서 사용할 시스템 전체 글로벌 레이블 풀을 라우팅 프로토콜을 통해 IS-IS(Intermediate System to Intermediate System) 수 있습니다.

  • 플랫폼이 확장을 지원할 수 있는 경우 vrf-table-label 공간을 최소 16,000개까지 늘리다.

  • 정적 VRF 테이블 레이블에서 사용할 레이블 값을 지정할 수 있습니다.

  • 지원되는 Label 애플리케이션 유형에서 사용할 레이블 값 범위를 지정할 수 있습니다.

  • SRGB 및 레이블 유형 범위를 동적으로 변경할 수 있습니다.

특수 MPLS 레이블

일부 예약 레이블(0에서 15 범위)은 의미를 잘 정의하고 있습니다. 자세한 내용은 RFC 3032, label Stack 인코딩 MPLS 를 참조하십시오.

  • 0, IPv4 Explicit Null Label—이 값은 유일한 레이블 엔트리인 경우(레이블 스태킹이 없는 경우) 합법적입니다. 수신 시 라벨이 부착되어야 하다는 표시입니다. IP 버전 4(IPv4) 패킷을 기반으로 포링이 계속됩니다.

  • 1, 라우터 경고 레이블—패킷이 1의 상위 레이블 값과 함께 수신될 때, 처리를 위해 로컬 소프트웨어 모듈로 전달됩니다.

  • 2, IPv6 Explicit Null Label—이 값은 유일한 레이블 엔트리인 경우(레이블 스태킹이 없는 경우) 합법적입니다. 라벨이 수신 시 터지기만 되어야 하다는 표시입니다. IP 버전 6(IPv6) 패킷을 기반으로 포링이 계속됩니다.

  • 3, Implicit Null Label—이 레이블은 제어 프로토콜(LDP 또는 RSVP)에서만 다운스트림 라우터에 의해 레이블 Popping을 요청하는 데 사용됩니다. 실제로 캡슐화에는 나타나지 않습니다. 3값의 레이블은 데이터 패킷에서 실제 레이블로 사용되어선 안 됩니다. 이 레이블에는 페이로드 유형(IPv4 또는 IPv6)이 없습니다.

  • 4~6—미지정.

  • 7, Entropy Label 지표—이 레이블은 Entropy Label이 Label 스택에 있으며 Entropy Label에 선행할 때 사용됩니다.

  • 8 ~15— 미해지원.

특수 레이블은 일반적으로 LSP의 egress와 Penultimate 라우터 간에 사용됩니다. LSP가 IPv4 패킷만 전달하도록 구성되는 경우, egress 라우터는 Penultimate 라우터에 0을 최종 홉 레이블로 사용하도록 신호를 전송할 수 있습니다. IPv6 패킷만 전달하도록 LSP가 구성된 경우, egress 라우터는 Penultimate 라우터에 2를 최종 홉 레이블로 사용하도록 신호를 전송할 수 있습니다.

egress 라우터는 단순히 Penultimate 라우터에 마지막 레이블로 3을 사용하게 하여 Penultimate-hop Label Popping을 수행하기 위한 요청일 수 있습니다. egress 라우터는 라벨링된 패킷을 처리하지 않습니다. 대신 페이로드(IPv4, IPv6 또는 기타)를 직접 수신하여 egress에 대한 하나의 MPLS 줄입니다.

Label-Stacked 패킷의 경우, egress 라우터는 penultimate MPLS 상단 Label이 있는 MPLS 패킷을 수신합니다. egress 라우터는 Label 0 또는 2를 사용하는 Label-Stacked 패킷을 수신할 수 없습니다. 일반적으로 Penultimate 라우터에서 Label 3을 요청합니다.

혼합 모드의 Entropy Label 지원 개요

Junos OS Release 14.2에서 시작하여, inentropy Label은 혼합 모드 섀시에서 지원됩니다. 이 섀시는 향상된 IP 구성 없이도 로피 레이블을 구성할 수 있습니다. entropy Label은 전송 라우터가 ECMP 경로 또는 링크 MPLS 트래픽을 전송하는 데 도움을 니다. 이 로피 레이블은 라우터가 사용하는 로드 밸런싱 레이블을 도입하여 트래픽에 심층 패킷 검사 로드 밸런싱하기 때문에 레이블 스택 깊이가 증가하는 대신 포울 플레인에서 패킷 처리 요구 사항을 줄일 수 있습니다. Junos OS MX 시리즈 라우터에서만 로피 레이블(entropy Label)을 지원하며 고급 ip 모드로 활성화할 수 있습니다. 그러나 이로 인해 코어 대면 인터페이스에 MPC 또는 MIC에서 엔트로피 레이블이 구성되어 있으며, 다른 코어 대면 연결의 다른 엔드에 라인 카드가 있는 경우 패킷 DPS(Dense Port Concentrator) 있습니다. 이를 방지하기 위해, 이제 entropy Label은 고급 IP 구성 없이도 entropy Label을 구성할 수 있는 혼합 모드에서 지원됩니다. 이를 통해 MX 시리즈 라우터 DC는 pop out entropy Label을 지원할 수 있습니다. 그러나 이는 플로우 레이블을 지원하지 않습니다.

LSP를 위한 추상적 MPLS 개요

추상 홉은 관리 그룹, 확장 관리 그룹 및 SRLG(Shared Risk Link Group)와 같은 기존 트래픽 엔지니어링 제약 조건을 논리적으로 결합하여, LSP(Label-Switched Path) 설정을 위한 제약 조건으로 시퀀스를 지정하고 사용할 수 있는 라우터의 사용자 정의 그룹 또는 클러스터를 MPLS 수 있습니다. 추상 홉은 기존 경로 제약 사양의 한계를 극복하고 네트워크의 트래픽 엔지니어링 기능에 MPLS.

추상 홉 이해

LSP를 MPLS 설정하는 경로 제약 조건은 실제 홉의 형태로 개별 라우터로 지정하거나 관리 그룹 또는 컬러 사양을 통해 라우터 세트로 지정할 수 있습니다. 경로 제약 조건이 실제 홉(엄격한 또는 느슨)을 사용하는 경우, LSP는 라우터의 지정된 시퀀스(예: R1, R2, ... Rn). 경로 제약 조건이 관리 그룹 또는 컬러 사양을 사용하는 경우, 지정된 기준을 충족하는 라우터 그룹이 특정 라우터를 선택하지 않고 LSP를 설정하는 데 사용하며, 실제 홉 제약 조건과 달리, 해당 제약 조건에서 사용되는 여러 라우터 그룹 간 시퀀스가 없습니다.

실제 홉 제약의 단점은 장애 시나리오에서 라우터 홉이 다운되거나 연결된 인터페이스의 대역폭 활용도가 포화 상태인 경우 경로가 다운되거나 로컬 또는 엔드투엔드 보호에 의존하는 것입니다. LSP를 복구하거나 설정하는 데 다른 대체 라우터가 제공될 수 있는 경우도 하지만, 운영자가 다른 라우터 홉 시퀀스를 경로 제약 조건으로 구성하거나 보호 경로를 디스어그리게이트하기 위한 경로 제약으로 구성할 때까지 LSP는 계속 다운됩니다.

관리 그룹 또는 컬러 사양 제약 조건은 특정 범위까지 실제 홉 제약 조건의 한계를 극복합니다. 그룹 내 라우터 중 하나에서 다운되거나 링크 용량이 포화 상태인 경우 LSP 설정은 영향을 받지 않습니다. 경로 제약 조건에서 사용할 다음 홉 라우터를 먼저 선택하지 못하고 운영자의 개입 없이도 동일한 관리 그룹 또는 색상을 사용하는 다른 라우터를 따라 LSP가 설정되기 때문에, 그러나 라우터 그룹 제약 조건의 단점은 홉 제약 조건 가운데 시퀀스를 지정할 수 없다는 것입니다.

각 구성원 라우터가 사용자 정의 제약 조건을 충족하는 사용자 정의 라우터 그룹을 생성하여 이러한 단점을 극복합니다. 사용자 정의 제약 조건은 관리 그룹, 확장 관리 그룹 및 SRLG(Shared Risk Link Groups)과 같은 기존 트래픽 엔지니어링 제약 조건의 논리적 조합입니다. 경로 제약 조건에서 사용되는 추상 홉 시퀀스를 지정하여 라우터 그룹에서 순서 지정이 수행됩니다. 그 결과, 추상 홉은 실제 홉 제약 조건 사양의 주문 속성과 다른 트래픽 엔지니어링 제약 조건의 탄력성에 결합됩니다.

경로는 실제 홉과 추상 홉의 조합을 제약으로 사용할 수 있습니다. 추상 홉을 사용하는 경우 라우터 시퀀스(R1, R2, ... Rn)실제 홉과 함께, 순서대로 라우터 그룹 또는 추상 홉(G1, G2, ... Gn)을 경로 제약 조건으로 정의합니다. 예를 들어, 각 지정된 라우터 그룹인 Gi는 사용자 정의 라우터 세트(R1, R2, Rj등)로 구성됩니다. Rn. 그룹 내 라우터 중 하나가 다운되는 경우, 그룹 Gi의Router Rj라고 할 수 있습니다. 다른 라우터는 동일한 그룹G에서 Router Rk라고합니다. 저는 경로 계산에 의해 선택되어 다운된 라우터(즉, Router Rj)를대체하게 됩니다. 그 이유는 경로 제약 조건이 시퀀스되어 개별 라우터의 시퀀스가 아닌 추상 홉 시퀀스를 통과해야 합니다.

추상 홉(Abstract Hops)을 사용할 때의 이점

추상 홉은 사용자 정의 라우터 그룹입니다. 개별 라우터 시퀀스를 사용하는 실제 홉 제약 조건과 마찬가지로, 추상 홉 시퀀스를 LSP(Label-Switched Path)를 설정하는 데 사용할 수 있습니다. 추상 홉을 사용하면 시퀀스된 경로 제약에 대한 탄력성 제공 추상 홉을 사용할 때의 다른 이점은 다음과 같습니다.

제약 조건 조합의 시퀀스 지정

현재, 여러 속성을 충족하는 링크를 통과할 수 있는 경로를 지정할 수 있습니다. 이와 같은 경로 제약 조건은 복합 제약 조건 조합이라고 불리며, 예를 들어, 초록색의 짧은 대기 링크를 포함하며 SRLG north를 제외한 제약 조건(Ci)을 예로 들 수 있습니다.

그러나 복합 제약 조건 조합의 시퀀스로 경로를 지정하는 데는 지원이 없습니다. 예를 들어 시퀀스된 제약 조건(C1, C2, Ci, ... Cn) 저지연 초록 링크, 대기 시간이 짧은 파란색 링크, 짧은 대기시간의 적색 링크가 포함된다.

이와 같은 시퀀스 복합 제약 조건의 조합에 대한 요구는 각 지역에 서로 다른 링크 연결성(속성) 요구 사항을 가지는 지리적 지역 시퀀스를 통해 경로를 설정해야 하는 경우 발생합니다. 추상화 홉은 컴퓨팅 노드가 각 제약 조건 조합(예: Ci)과 사용자 정의 라우터 그룹(즉, 추상 홉)을 매핑하도록 허용하여 이 요구 사항을 충족합니다.

전송 노드에서 새로운 네트워크 구성 방지

현재 경로 제약 조건 사양 기능을 통해 전체 경로를 따라 특정 속성의 링크를 포함하거나 제외할 수 있습니다. 예를 들어 SRLG West를 경로에서 제외하는 경우를 예로 들 수 있습니다. 그러나 조건부로 속성을 제외하거나 포함하거나 경로의 여러 부분에 속성을 제외하거나 포함하기 위한 지원이 없습니다. 예를 들어 적색 링크를 선회할 때만 SRLG West를 제외합니다.

이를 위해 SRLG를 서쪽으로 포함하지 않은 빨간색 링크를 모두 식별하고 해당 관리 그룹에 적합한 모든 관련 링크를 구성하기 위해 새로운 관리 그룹을 만들 수 있습니다. 이 접근 방식의 단점은 네트워크 전반에 걸쳐 새로운 관리 그룹 멤버십을 반영하기 위해 구성 변경이 필요하다는 것입니다.

추상 홉을 사용하여 구성 변경을 ingress 라우터에만 포함될 수 있습니다. ingress 라우터에서 제약 조건 조합은 추상 홉에 매핑되므로 전송 노드에서 새로운 구성을 구성할 필요 없이도 전한 요구 사항을 충족할 수 있습니다.

중앙 집중식 및 분산형 경로 계산 패러다임의 결합

분산 컴퓨팅이나 컴퓨팅 MPLS 중앙 컨트롤러를 통해 경로의 트래픽 엔지니어링을 실현할 수 있습니다. 두 컴퓨팅 유형의 조합을 하이브리드 컴퓨팅 패러다임이라고 합니다. 하이브리드 컴퓨팅 접근 방식의 핵심 기능은 PCE(Path Computation Element)라고 불리며, ingress 라우터(PCC)에 경로 계산 지시어를 느슨하게 지정하고 이를 경로 계산을 위한 입력으로 사용하는 ingress 라우터의 기능을 사용하는 기능입니다.

추상 홉의 시퀀스는 중앙 컨트롤러에서 지침으로 사용할 목적으로 사용됩니다. 추상 홉은 컨트롤러가 경로 제약 조건 및 속성에 연계할 수 있는 유연성을 제공합니다. 또한 컨트롤러가 제약 조건의 시퀀스 요소에 빌드할 수 있습니다. 컨트롤러가 필요한 각 홉을 지정할 필요가 없습니다. 이 경우 ingress 라우터가 지침 또는 지시선의 한계 내에서 작동할 수 있는 여지가 남습니다.

표 1 하이브리드 컴퓨팅 패러다임의 주요 기능을 나열하고 이러한 접근 방식과 현재 경로 계산 방법을 비교한 방법을 제공합니다.

표 1: 추상 홉을 위한 하이브리드 컴퓨팅

기능

분산형 최단 경로 우선

중앙 집중식 최단 경로 우선

하이브리드 최단 경로 우선

대규모 네트워크의 빈번한 변화에 대응

 

글로벌 뷰를 통해 정교한 경로 계산

 

경로 계산에 비즈니스 로직 통합

 

장애 복구력(단일 장애 지점 없음)

 

예측

 

실시간에 가까운 네트워크 로드에 대응

 

현장 테스트(조기 도입 vs.

 

Junos OS 홉 구현

순서 인식 추상 홉 기능은 Junos OS 릴리스 17.1에서 소개됩니다. 다음 섹션에서는 추상 홉의 구현을 Junos OS:

추상 홉 정의

추상 홉은 사용자가 LSP(Label-Switched Path) 설정에 사용할 수 있도록 정의할 수 있는 라우터 그룹입니다. 사용자는 이기종 링크 속성 또는 구성 요소 속성이라고 하는 제약 조건의 논리적 조합을 정의하여 그룹에 포함할 라우터를 제어할 수 있습니다. 정의된 구성 속성을 충족하는 링크가 있는 라우터는 추상 홉을 표현하는 라우터 그룹에 연결됩니다.

추상 홉과 구성 속성의 매핑은 컴퓨팅 노드 또는 설정되는 LSP의 ingress에 로컬로 매핑됩니다. 그 결과, 추상 홉은 내부 게이트웨이 프로토콜 업데이트 또는 시그널링 프로토콜 확장과 관련이 없는 것은 아니며, 네트워크에서 추상 홉을 구현하기 위해 전송 노드에서 새로운 구성을 요구하지 않습니다.

사용자 정의 이름로 식별되는 여러 가지의 트래픽 엔지니어링 속성을 정의할 수 있습니다. 구성 목록은 다음 구성 명령문을 사용하여 추상 홉 정의에서 사용됩니다.

  • include-any-list—링크에 대해 지정된 속성이 있는 경우 링크는 사용자 목록을 충족합니다.

  • include-all-list—링크에 대해 지정된 모든 속성이 해당되는 경우 링크는 사용자 목록을 충족합니다.

  • exclude-all-list—지정된 속성 중 링크에 대해 해당 속성이 없는 경우 링크는 사용자 목록을 충족합니다.

  • exclude-any-list—링크에 대해 지정된 속성 중 하나 이상이 해당되지 않는 경우 링크는 사용자 목록을 충족합니다.

추상 홉은 앞서 언급한 범주에 속할 수 있는 구성 목록 참조의 논리적 조합으로 정의됩니다. 이를 위해 논리적 운영자 및 추상 홉 정의에 포함되고 구성 목록에 ANDOR 적용됩니다.

  • OR—추상 홉 정의에 있는 구성 목록 참조 중 최소 하나는 첨부된 노드가 추상 홉의 일부가 되어야 하는 링크에 만족해야 합니다.

  • AND—추상 홉 정의에 있는 모든 구성 목록 참조는 연결된 노드가 추상 홉의 일부가 되어야 하는 링크에 만족해야 합니다.

샘플 추상 홉 정의

추상 홉 홉A의 정의는 다음과 같습니다.

추상 홉 홉A는 각기 다음과 같은 링크 속성의 논리적 조합을 충족하는 emanating 링크를 가진 모든 라우터를 포함해야 합니다.

  • hopA—(관리 그룹 red & Srlg south) || (관리 그룹 그린 || Srlg north)), 여기서:

    • 관리 그룹 red 및Srlg south는 전체 사용자 목록(listA1, 이 예에서)에 속합니다.

    • 관리 그룹 녹색Srlg north는 포함할 수 있는 사용자 목록(이 예에서는 listA2)에 속합니다.

    • || 운영자입니다.

추상 홉 홉A에 대한 구성은 다음과 같습니다.

  • hopA configuration

Verifying Abstract Hop Configuration

show mpls abstract hop membership <abstract hop name> 명령은 추상 홉의 멤버를 보는 데 사용됩니다. 명령 출력은 트래픽 엔지니어링 데이터베이스 노드 매핑에 대한 추상적 홉을 제공합니다.

여기에서 출력 필드는 내부 게이트웨이 프로토콜 사용 Credibility 시의 신뢰성을 나타냅니다.

명령의 show ted database extensive local 출력은 트래픽 엔지니어링 데이터베이스에서 캡처된 뷰를 제공합니다. 키워드는 출력에 로컬 측정소가 포함될 것을 local 표시하기 위해 추가됩니다. 명령 출력은 링크 속성의 관련 논리적 조합을 충족하는 링크의 속성으로 추상 홉을 보여줍니다.

추상 홉 홉A는 저지연 및 SRLG West를 위한 것으로, SRLG west를 제외한 추상 홉 홉B는 홉 홉B를 추상화합니다. 그림 5 은 이러한 추상 홉의 ingress 뷰를 표시합니다.

그림 5: 추상 홉의 Ingress View추상 홉의 Ingress View

경로 제약에서 추상 홉 사용

사용자는 각 추상 홉 정의와 고유 식별자를 연관합니다. 이 식별자는 경로 제약 조건의 추상 홉을 참조하는 데 사용됩니다. 추상 홉 시퀀스는 실제 IP 홉의 사용 방식과 유사하게 경로 제약 조건으로 지정할 수 있습니다. 경로 제약 조건은 실제 IP 홉에 의해 인터리브되는 추상 홉 시퀀스일 수도 있습니다.

경로 제약 조건에서 추상 홉 또는 실제 홉을 사용하려면 대상에 대한 두 개 이상의 제한적 Shortest Path First 패스(일반적으로 홉당 1개)가 필요합니다. 실제 홉이 경로 제약 조건으로 제공되는 경우, 제약 조건 계산은 경로 제약 조건에서 각 패스가 제약 조건의 홉에 도달할 때 끝나는 홉 수만큼 패스를 수반합니다. 각 통과의 시작점은 이전 통과의 대상이 며, 첫 번째 통과는 ingress 라우터를 시작점으로 사용하게 됩니다.

또는 경로 제약 조건이 엄격한 추상 홉 또는 느슨한 추상 홉을 사용하는 경우, 제약 조건 계산은 각 패스가 제약 조건 목록에서 후속 추상 홉을 처리하는 통과로 구성됩니다. 이러한 경우, 두 개 이상의 노드가 통과의 대상이 될 수 있는 것으로 확인됩니다. 노드 집합을 통과를 위한 유의미한 라우터 세트라고 합니다.

추상적 홉은 다음을 사용하여 구성원 노드를 전달합니다.

  • 정의된 구성 요소의 논리적 조합을 충족하는 링크

  • 모든 종류의 링크

멤버 노드를 거치는 추상 홉의 수단은 추상적 홉 쿼터(strict, loose, loose-link)를 사용하여 경로 제약 조건을 정의하는 데 사용할 수 있습니다. 예를 들어, 추상 홉 홉A는 다음과 같은 여러 가지 예로 다른 홉 홉(qualifiers)을 통해 다르게 처리됩니다.

  • Strict—제약 조건 목록에서 마지막 처리된 홉을 경로는 추상 홉 홉(abstract hopA)의 멤버십을 갖는 링크 또는 노드만을 통해 다음 추상 홉 처리를 위한 실현 가능한 시작 지점인 hopA의 멤버십을 갖는 노드에 도달합니다.

  • Loose—제약 조건 목록에서 마지막 처리된 홉을 경로는 홉A의 홉 멤버십을 추상화하지 않은 실제 노드를 통해 다음 추상 홉 처리를 위한 실질적인 시작점인 추상 홉 멤버십 hopA로 노드에 도달할 수 있습니다.

  • Loose-link—제약 조건 목록에서 마지막 처리된 홉을 경로는 홉A의 홉 멤버십을 추상화하지 않은 실제 노드를 통해 다음 추상 홉 처리를 위한 실질적인 시작점인 추상 홉 멤버십 hopA로 노드에 도달할 수 있습니다. 그러나 경로는 동일한 과정에 있는 추상 홉A 멤버십의 링크 하나 이상을 통해 전달해야 합니다.

    즉, loose-link 유형에 대한 추상적 홉은 관련 추상 홉 멤버십 링크를 통해 제약 조건에 있는 가능한 라우터에 도달할 수 있는 경우만 처리된다고 합니다.

샘플 추상 홉 사양

표 2 경로 제약 조건에서 추상 홉을 사용할 수 있는 샘플 사용 사례를 제공합니다.

표 2: 경로 제약에서 추상 홉 사용

경로 제약의 목적

추상 홉 한정자

구성

유선 라우터 세트

선호도

hopA의 구성원인 Traverse 노드는 hopA를 충족하는 링크만 취합니다.

엄격한

[edit protocols mpls]
Path path_hopA_s {
    hopA abstract strict;
}

추상 홉A의 모든 멤버. 즉, A1, A2... An.

hopA(추상 hopA를 충족하는 링크 선택).

hopA의 구성원이지만 hopA를 충족하는 링크가 아닌 Traverse 노드

느슨한

[edit protocols mpls]
Path path_hopA_l {
    hopA abstract loose;
}

추상 홉A의 모든 멤버. 즉, A1, A2... An.

없음(모든 종류의 링크).

hopA를 충족하는 하나 이상의 링크를 취하여 hopA의 구성원인 Traverse 노드

느슨한 링크

주:

느슨한 링크 한정자(loose-link qualifier)는 느슨한 다음에 동일한 추상 홉에 대해 엄격한 것으로 표시됩니다. 즉, hopA 느슨한 링크는 hopA loose 및 hopA strict과 동일합니다.

[edit protocols mpls]
Path path_hopA_ll {
    hopA abstract loose-link;
}

이 경우 경로 제약 조건에서 hopA와 연관된 두 개의 연산 통과가 있습니다. 두 패스 모두에서 사용할 수 있는 라우터 세트는

추상 홉A의 모든 멤버. 즉, A1, A2... An.

주:

경로 계산 중에 라우터가 한 번만 전달됩니다.

이 경우 경로 제약 조건에서 hopA와 연관된 두 개의 연산 통과가 있습니다. 두 패스의 효율성은

  • 패스 1—없음(모든 종류의 링크).

  • 패스 2—hopA(추상 홉A를 충족하는 링크 선택).

홉A의 구성원인 Traverse 노드는 hopA를 충족하는 링크만 사용하고, 홉B를 충족하는 링크만 사용하고 홉B를 충족하는 링크만 있는 노드가 그 뒤를 이을 수 있습니다.

엄격한

[edit protocols mpls]
Path path_hopA_hopB_s {
    hopA abstract strict;
    hopB abstract strict;
}
  • hopA—hopA 및 hopB 멤버 집합의 교차

    주:

    추상 홉이 엄격한 추상 홉에 따라 두 구성원 세트의 교차점은 가능한 라우터 세트로 간주됩니다.

  • hopB—추상 홉B의 모든 멤버. 즉, B1, B2... Bn.

  • hopA—hopA(추상 hopA를 충족하는 링크 선택).

  • hopB—hopB(추상 홉B를 충족하는 링크만 선택).

홉A의 구성원인 Traverse 노드는 hopA를 충족하는 링크만 사용하고, 모든 종류의 링크를 홉B의 구성원인 노드가 그 뒤를 이을 수 있습니다.

엄격하고 느슨한

[edit protocols mpls]
Path path_hopA_s_hopB_l {
    hopA abstract strict;
    hopB abstract loose;
}
  • hopA—추상적 hopA의 모든 구성원. 즉, A1, A2... An.

  • hopB—추상 홉B의 모든 멤버. 즉, B1, B2... Bn.

  • hopA—hopA(추상 hopA를 충족하는 링크 선택).

  • hopB—없음(링크를 선택).

모든 종류의 링크를 취하여 hopA의 구성원인 Traverse 노드와 모든 종류의 링크를 홉B의 구성원인 노드가 그 뒤를 이을 수 있습니다.

느슨한

[edit protocols mpls]
Path path_hopA_l_hopB_l {
    hopA abstract loose;
    hopB abstract loose;
}
  • hopA—추상적 hopA의 모든 구성원. 즉, A1, A2... An.

  • hopB—추상 홉B의 모든 멤버. 즉, B1, B2... Bn.

없음(링크를 선택).

모든 종류의 링크를 취하여 hopA의 구성원인 Traverse 노드와 홉B를 충족하는 링크만 취하는 홉B의 구성원인 노드가 그 뒤를 이을 수 있습니다.

느슨하고 엄격한

[edit protocols mpls]
Path path_hopA_l_hopB_s {
    hopA abstract loose;
    hopB abstract strict;
}
  • hopA—hopA 및 hopB 멤버의 교차

    추상 홉이 엄격한 추상 홉에 따라 두 구성원 세트의 교차점은 가능한 라우터 세트로 간주됩니다.

  • hopB—추상 홉B의 모든 멤버. 즉, B1, B2... Bn.

  • hopA—없음(링크를 선택).

  • hopB—hopB(추상 홉B를 충족하는 링크만 선택).

그림 6 각각 느슨하고 엄격한 느슨한 추상 홉 쿼터를 통해 추상 홉 홉A, 홉B 및 홉C에 대한 경로 제약 조건을 표시합니다.

그림 6: 추상 홉을 위한 샘플 경로 제약 조건추상 홉을 위한 샘플 경로 제약 조건

추상 홉에 대한 제약이 있는 Shortest Path First 패스는 다음과 같습니다.

  • hopA와 관련된 패스 1

    • Viable 라우터—라우터 R1 및 R2(hopB가 엄격한 추상 홉이기와 홉B의 교차점).

    • Affinity—없음(hopA가 느슨해지기만 하여).

  • 홉B와 연관된 패스 2

    • 유선 라우터—라우터 R1, R2, R3, R4

    • Affinity—홉B 호환 링크만 선택(홉B는 엄격한 추상 홉이기 입니다).

  • hopC와 연관된 패스 3

    • 유선 라우터—라우터 R5, R6, R7 및 egress 라우터.

    • Affinity—없음(hopC가 느슨한 추상 홉이기만 하여).

경로 계산 및 백트래킹

각 제약을 받지 않는 Shortest Path First 패스에서, 유력 라우터 세트의 가장 가까운 라우터에 도달하면 패스에 대한 효율성을 충족하는 링크가 도달하면 패스와 연관된 추상 홉을 처리합니다. 따라서 도달한 유수의 라우터는 다음 제약 조건 통과를 위한 출발점 역할을 합니다. 제약 조건이 통과하지 못하고 시작 라우터로 ingress 라우터가 없는 경우, 패스가 이전 통과로 백트러킹되고 프로세스가 반복됩니다.

샘플 백트래킹

제한적인 Shortest Path First 패스 p(첫 번째 패스 이외에)에 장애가 발생하면 현재 패스 p에 대해 시작된 이전 패스(p – 1)의 출구 라우터는 이전 패스 세트의 유력한 라우터 세트에서 비격식적으로 처리됩니다(p – 1). 그런 다음 이전 통과(p – 1)가 다시 실행되어 실행 가능한 라우터 세트에서 패스 p – 1에 대한 다음 최상의 출구 라우터 또는 대상을 찾을 수 있습니다.

따라서 결정된 라우터는 패스 p를 위한 새로운 시작 라우터의 역할을 합니다. 이 절차는 장애가 발생하고 탐색할 수 없는 유의미한 라우터가 있는 한 반복됩니다.

이 명령은 LSP 및 각 통과에 대한 적격 종료 라우터와 관련된 다양한 연산 show mpls lsp abstract-hop-computation name lsp-name 패스를 제공합니다. 명령 출력은 통과당 효율성을 제공하며, 통과를 위해 선택한 현재 시작 라우터를 보여줍니다. 각 실용 라우터의 경우 백트래킹의 상태가 표시되어 유효하거나 자격이 박격화될 수 있습니다.

출력 필드는 사용하는 내부 게이트웨이 프로토콜과 관련된 Credibility 신뢰성을 나타냅니다.

예를 들면 다음과 같습니다. LSP를 위한 추상 홉 MPLS 구성

이 예에서는 LSP(Label-Switched Path)에 대한 MPLS 홉을 구성하는 방법을 보여줍니다. 추상 홉은 기존 트래픽 엔지니어링 제약 조건의 주요 기능을 결합하여 사용자가 LSP에 대한 주문 인식 및 탄력적인 경로 제약 조건을 MPLS 수 있도록 합니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • 멀티 서비스 에지 라우터, MX 시리즈 5G M Series, 유니버설 라우팅 플랫폼 코어 T 시리즈, PTX 시리즈 라우터를 조합할 패킷 전송 라우터.

  • Junos OS Release 17.1 이상이 모든 장치에서 실행됩니다.

시작하기 전에 다음을 할 수 있습니다.

  • 디바이스 인터페이스를 구성합니다.

  • 디바이스 라우터 ID를 구성하고 AS(Autonomous System) 번호를 할당합니다.

  • 모든 디바이스에서 RSVP를 구성합니다.

  • 모든 최단 경로 우선(OSPF) 구성하거나 다른 모든 내부 게이트웨이 프로토콜을 구성합니다.

  • 모든 디바이스에서 관리 그룹, 확장 관리 그룹 및 SRLG(Shared Risk Link Groups)를 구성합니다.

개요

Junos OS Release 17.1은 사용자 정의 라우터 클러스터 또는 그룹인 추상 홉을 도입합니다. 실제 홉 제약 조건의 시퀀스(엄격한 또는 느슨한)와 마찬가지로, 추상 홉 시퀀스는 LSP(Label-Switched Path)를 설정하는 데 사용할 수 있습니다. 경로는 실제 홉과 추상 홉의 조합을 제약으로 사용할 수 있습니다.

추상 홉은 실제 홉의 주문 속성과 함께 관리 그룹, 확장 관리 그룹 및 SRLG와 같은 기존 트래픽 엔지니어링 제약 조건의 논리적 조합입니다. 그 결과, 추상 홉 시퀀스가 경로 제약 조건에서 사용될 경우, 구성 속성이라고 하는 링크 또는 노드 속성의 논리적 조합을 충족하는 라우터 그룹 사이에서 순서가 수행됩니다.

추상 홉 구성:

  • 계층 수준에서 명령문을 포함해 여러 트래픽 엔지니어링 속성을 포함한 요소 목록을 constituent-list list-name[edit protocols mpls] 생성합니다.

  • 계층 수준에서 추상 홉 정의에 포함된 사용자 [edit protocols mpls abstract-hop abstract-hop-name] 목록을 포함합니다.

  • 계층 수준에서 추상 홉을 사용하는 경로 제약 [edit protocols mpls path path-name] 조건을 정의합니다.

LSP를 위한 추상 홉을 구성할 때 고려할 MPLS 지침을 따릅니다.

  • 추상 홉은 디바이스의 마스터 라우팅 인스턴스에서만 지원됩니다.

  • IPv6 대상은 추상 홉 제약 조건에서 지원되지 않습니다(IPv4 대상만 작동).

  • 추상적 홉은 엄격한 제약 조건 또는 느슨한 제약 조건일 수 있습니다.

  • Junos OS Release 17.1의 추상 홉 지원은 도메인 간 또는 영역 LSP가 아니라 LSP 내 MPLS 영역에만 제공됩니다.

  • 일반 점대점(point-to-point) LSP에만 추상 홉 제약이 활성화됩니다. 다른 유형의 MPLS LSP, 외부 제어 양방향 LSP, 동적 컨테이너 LSP, RSVP automesh LSP 및 영역 간 LSP와 같은 기타 유형의 LSP는 추상 홉 구성으로 지원되지 않습니다.

  • 추상 홉은 LSP에 대한 전체 최단 경로의 계산을 지원하지 않습니다.

  • 추상 홉을 동일한 경로 제약 조건에서 두 번 이상 언급하면 안 됩니다.

  • 추상 홉 제약 조건 사양은 GRES(Graceful 라우팅 엔진 Switchover), 통합 ISSU(서비스 중 소프트웨어 업그레이드) 및 NSR(NonStop Routing)에 대한 지원에 영향을 미치지 않습니다.

  • 추상 홉 제약 조건 사양은 전체 네트워크 성능에 영향을 미치지 않습니다. 그러나 제한적인 최단 경로 1차 계산에 들이는 시간이 추상 홉 구성으로 증가합니다. 추상 홉 LSP의 설정 시간은 추상 홉 구성 없이 LSP를 설정하는 데 들이는 시간 이상입니다.

토폴로지

그림 7 추상 홉으로 구성된 샘플 네트워크 토폴로지의 예시를 제공합니다. 디바이스 R0과 R3은 각각 호스트(호스트 1 및 호스트 2)에 연결됩니다. 디바이스 R4와 R5는 Devices R0, R1, R2 및 R3에 각각 연결됩니다. 디바이스 R1과 R2도 서로 직접 연결됩니다.

디바이스 R0 및 R3는 동일한 자율 시스템(AS 64496)으로 구성됩니다. LSP MPLS 1개의 기본 경로와 2개의 보조 경로(대기 및 비스탠바이 보조 경로)가 있는 Device R0에서 Device R3로 구성됩니다.

c1, c2, c3 및 c4의 네 가지 멤버 목록은 3개의 SRLG(g1, g2, g3), 3개의 관리 그룹(녹색, 파란색, 빨간색), 1개의 확장 관리 그룹(골드)을 사용하여 생성됩니다. 3개의 추상 홉(ah1, ah2, ah3)은 구성된 구성 목록을 사용하여 정의되고 경로 제약 조건으로 지정됩니다. 추상 홉 ah1은 기본 경로의 제약 조건으로 지정되는 반면, 추상 홉 ah2 및 ah3은 보조 대기 경로와 보조 비스탠바이 경로에 대한 제약 조건으로 각각 지정됩니다.

그림 7: 추상 홉 경로 제약 조건 구성추상 홉 경로 제약 조건 구성

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경하고, 계층 수준에서 명령어를 CLI 입력한 다음 구성 모드에서 [edit]commit 입력합니다.

디바이스 R0

디바이스 R1

디바이스 R2

디바이스 R3

디바이스 R4

디바이스 R5

절차

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 CLI 사용자 가이드의 CLI 편집기사용 CLI 참조하십시오.

Device R0을 구성하려면:

  1. Device R0에서 향상된 IP 네트워크 서비스를 활성화합니다.

  2. 루프백 인터페이스를 포함하여 Device R0에서 인터페이스를 구성합니다.

  3. Device R0에 라우터 ID 및 자율 시스템 번호를 할당합니다.

  4. SRLG 정의를 구성합니다.

  5. 확장 관리 그룹 정의를 구성합니다.

  6. 관리 그룹 정의를 구성합니다.

  7. 관리 MPLS 제외한 Device R0의 모든 인터페이스에서 디바이스를 구성합니다.

  8. 구성된 트래픽 엔지니어링 속성을 장비 R0의 인터페이스를 할당합니다.

  9. Device R0과 Device R3을 연결하는 LSP를 구성하고 기본 및 보조 경로 속성을 LSP에 할당합니다.

  10. R0-R31 LSP에 대한 기본 및 보조 경로를 정의합니다.

  11. 추상 홉 정의를 위해 여러 트래픽 엔지니어링 속성을 사용하여 여러 목록을 생성합니다.

  12. 구성된 구성 목록과 해당 오퍼레이터를 할당하여 추상 홉을 정의합니다.

  13. 추상 홉 정의를 포함하여 구성된 경로에 대한 제약 조건을 정의합니다.

  14. 디바이스 R0에서 RSVP를 구성합니다. Host1에 연결하는 관리 인터페이스 및 인터페이스를 제외한 Device R0의 모든 인터페이스에서 RSVP를 활성화하고 대역폭 값을 할당합니다.

  15. 관리 최단 경로 우선(OSPF) 디바이스 R0의 모든 인터페이스에서 구성하고 트래픽 엔지니어링 기능을 할당합니다.

  16. Device R0에 정책을 구성하여 패킷당 로드 밸런싱을 실행합니다.

  17. 로드 밸런싱 정책을 포딩 테이블로 내보낼 수 있습니다.

결과

구성 모드에서 , , 및 명령어를 입력하여 show chassisshow interfacesshow routing-optionsshow protocolsshow policy-options 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

확인

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

추상 홉 구성 검증

목적

Device R0에서 추상 홉 멤버를 추상 홉 멤버로 표시하는 명령을 발행하여 해당 멤버를 show mpls abstract-hop-membership 검증합니다.

실행

작동 모드에서 명령을 show mpls abstract-hop-membership 실행합니다.

의미

명령 show mpls abstract-hop-membership 출력은 트래픽 엔지니어링 데이터베이스 노드 매핑에 대한 추상적 홉을 제공합니다. 이 필드는 사용 중 내부 게이트웨이 프로토콜과 관련된 신뢰성 Credibility 최단 경로 우선(OSPF).

추상 홉 경로 계산 검증

목적

디바이스 R0에서 LSP에 대한 추상적 계산 전 처리를 명령을 발행하여 show mpls lsp abstract-computation 검증합니다.

실행

작동 모드에서 명령을 show mpls lsp abstract-computation 실행합니다.

의미

명령 출력은 LSP에 포함되는 다양한 컴퓨팅 패스와 각 패스에 대한 적격 exit show mpls lsp abstract-hop-computation devces를 제공합니다. 명령 출력은 통과당 효율성을 제공하며, 통과를 위해 선택한 현재 시작 디바이스를 보여줍니다. 각각의 실용 라우터(디바이스)에 대해 백트래킹의 상태가 표시되고, 백트래킹의 상태는 유효하거나 검증되지 않은 상태로 표시됩니다.

이 필드는 사용 중 내부 게이트웨이 프로토콜과 연관된 신뢰성 Credibility 최단 경로 우선(OSPF).

최대 MPLS 레이블 수 구성

애플리케이션을 위해 구성하는 인터페이스의 경우 MPLS 작동할 수 있는 최대 레이블 수를 MPLS 수 있습니다.

기본적으로 레이블의 최대 개수는 3개입니다. 최대 4개 또는 5개 레이블이 필요한 애플리케이션에 대해 최대 4개 또는 레이블 5개로 변경할 수 있습니다.

Junos OS Release 19.1R1(egress 패킷 전달 엔진)에 의해 푸시될 수 있는 최대 레이블 수를 활용할 수 있습니다. 즉, 다음 홉에 대해 푸시할 수 있는 레이블의 수는 MPLS 디바이스가 푸시할 수 있는 레이블 maximum-labels 수 또는 발신 인터페이스에서 구성된 최대 레이블 family mpls 수입니다. 이 지원은 MPC 및 MIC 인터페이스를 사용하는 MX 시리즈 라우터와 제 3세대FPC를 사용하는 PTX 시리즈 라우터에서 지원됩니다.

향상된 레이블 푸시 기능은 세그먼트 라우팅 트래픽 엔지니어링 LSP 및 RSVP-트래픽 엔지니어링(TE) Pop-and-forward LSP와 같은 기능에 유용합니다. 차세대 홉을 사용하는 애플리케이션의 모든 MPLS 증가된 Label Push 기능과 계속 연동됩니다. 여기에는 다음이 포함됩니다.

  • LSP를 위한 lsping, traceroute 및 BFD와 같은 MPLS 유틸리티.

  • LSP를 위한 lspmon 및 LM DM MPLS 유틸리티 모니터링

및 명령 출력은 다음 홉 컴포넌트당 show route table 최대 show route forwarding-table 16개 레이블을 표시하기 위해 향상됩니다.

몇 가지 예를 들면 다음과 같습니다.

주:

인터페이스의 최대 MPLS 레이블 수가 변경될 경우 인터페이스는 MPLS 바운스됩니다. 인터페이스의 모든 LDP 및 RSVP 세션이 재시작되어 인터페이스상에서 모든 LSP가 플랩(flap)됩니다.

예를 들어 VPN 서비스를 제공하는 고객을 위해 2계층 캐리어의 VPN 서비스를 구성하고, 캐리어의 VPN은 서비스 제공업체(Tier 1 ISP)와 고객 캐리어(Tier 2 ISP) 간의 2계층 관계입니다. 캐리어의 VPN에서, 서비스 제공업체는 고객 캐리어를 위한 VPN 백본 네트워크를 제공합니다. 이에 따라 고객 캐리어는 최종 고객에게 Layer 3 VPN 서비스를 제공합니다. 고객 캐리어는 레이블이 붙은 트래픽을 서비스 제공업체의 통신 사업자 네트워크에 있는 다음 홉으로 전달합니다. 이 시나리오에는 3-Label 스택이 필요합니다. 서비스 프로바이더 VPN을 위한 또 다른 레이블, 고객 캐리어 VPN을 위한 또 다른 레이블, 전송 경로를 위한 세 번째 레이블 등 3개 레이블을 사용합니다.

Fast Reroute 서비스를 추가하는 경우 서비스 프로바이더 네트워크의 PE 라우터를 네 번째 레이블(Reroute Label)을 지원하도록 구성해야 합니다. 고객 통신 사업자가 신호 전송 프로토콜로 LDP를 사용하고 서비스 제공업체가 RSVP를 사용하는 경우, 서비스 제공업체는 RSVP 터널 서비스를 통해 LDP를 지원해야 합니다. 이 추가 서비스에는 총 5개의 레이블을 위해 추가 Label이 필요합니다.

고객 통신 사업자에 대해 공급업체의 VPN에 연결하는 데 사용하는 라우터는 PE 라우터입니다. 그러나 서비스 제공업체들은 이 장치를 네트워크 라우터로 고객 에지(CE) 있습니다.

표 3 레이블 요구 사항을 요약합니다.

표 3: 3, 4 또는 5 또는 5 라벨을 사용할 MPLS 시나리오

필요한 레이블 수

시나리오

3

2개의 레이블 및 Fast Reroute를 사용하는 캐리어의 VPN 또는 VPN

4

캐리어의 캐리어와 Fast Reroute의 조합

5

RSVP를 실행하는 프로바이더 캐리어와 LDP를 실행하는 고객 캐리어가 있는 Carrier-of-carrier

최대 레이블 개수를 구성하고 모니터링하는 경우:

  1. 논리적 인터페이스에서 최대값을 지정합니다. 통신 사업자 PE 라우터에 이 구성을 적용합니다.
  2. 구성을 검증합니다.

    명령 출력에는 논리적 인터페이스 Maximum labels: 5 유닛 0의 필드가 포함됩니다.

궁극적인 MPLS 라벨을 팝업으로 구성

LSP(Label-Switched Path)의 egress 라우터에 광고된 레이블 값을 제어할 수 있습니다. 기본 광고 레이블은 Label 3(Implicit Null Label)입니다. Label 3가 광고되는 경우 Penultimate-hop 라우터는 라벨을 제거하고 송신 라우터로 패킷을 전송합니다. 궁극의 홉 Popping을 활성화함으로써 Label 0(IPv4 Explicit Null Label)을 광고합니다. 궁극의 홉(hop) popping은 네트워크상을 통과하는 모든 패킷에 MPLS 포함되도록 보장합니다.

주:

주니퍼 네트웍스 레이블에 따라 패킷을 대기열로 지정합니다. 다른 벤더의 라우터는 패킷을 다르게 큐에 대기할 수 있습니다. 여러 벤더의 라우터가 포함된 네트워크를 사용할 때 염두에 두어하십시오.

궁극의 MPLS 라벨을 팝업하도록 구성하기 위해 다음 명령문을 explicit-null 포함하십시오.

다음 계층 수준에서 이 명령문을 구성할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

피어에 명시적 Null BGP(Border Gateway Protocol) 광고

IPv4 () 패밀리만이 BGP(Border Gateway Protocol) 그룹의 피어는 inet inet Labeled-unicast 및 inet6 Label-unicast NLRI에 대한 연결된 경로 세트(직접 및 루프백 경로)에 대해 명시적인 NULL 레이블을 전송할 수 있습니다. 기본적으로 피어는 Label 3( 암시적 NULL)을 광고합니다. explicit-null명령문이 활성화되면 피어가 Label 0(명시적 NULL)을 광고합니다. 명시적 NULL 레이블은 네트워크 네트워크를 통과하는 패킷에 항상 레이블이 MPLS 있습니다. 내재된 NULL 레이블이 사용되는 경우 penultimate hop 라우터는 라벨을 제거하고 패킷을 일반 IP 패킷으로 송신 라우터에 전송합니다. 이로 인해 Penultimate hop이 다른 벤더의 라우터인 경우 Penultimate hop 라우터에서 패킷을 올바르게 큐에 대기하는 데 문제가 발생할 수 있습니다. 일부 다른 벤더는 수신 레이블이 아닌 전송 레이블의 CoS 비트에 따라 패킷을 큐에 대기합니다.

명시적 null Label을 표시하려면 구성에 다음 명령문을 포함하십시오.

이 명령문을 포함할 수 있는 계층 수준 목록은 이 명령문에 대한 명령문 요약 섹션을 참조하십시오.

명시적 null 레이블을 표시하려면 connected-only 명령문이 필요합니다.

연결된 경로에 대해 명시적 NULL 레이블이 광고되고 있는지 확인하려면 명령을 show route advertising-protocol bgp neighbor-address 사용하여

EX MPLS 스위치의 레이블 작동에 대한 이해

기존의 패킷 포링 패러다임에서 패킷이 스위치에서 다음 스위치로 이동하면 각 홉에서 독립적인 포우링 결정이 내리게 됩니다. IP 네트워크 헤더를 분석하고 이 분석을 기반으로 다음 홉을 선택하며 라우팅 테이블의 정보에 따라 선택됩니다. 네트워크 MPLS 환경에서 패킷 헤더 분석은 패킷이 MPLS 터널에 들어갈 때 한 번만 수행됩니다(즉, 트래픽과 트래픽에 사용되는 MPLS 합니다.

IP 패킷이 LSP(Label-Switched Path)에 들어오면 수신 PE(Provider Edge) 스위치가 패킷을 검사하고 대상을 기준으로 Label을 할당하여 패킷의 헤더에 레이블을 배치합니다. 이 레이블은 IP 라우팅 정보를 기반으로 전달되는 패킷에서 레이블과 연관된 정보를 기반으로 전달되는 패킷으로 변환합니다. 그런 다음 패킷은 LSP의 다음 제공업체 스위치로 전달됩니다. 이 스위치와 LSP의 모든 후속 스위치는 라벨링된 패킷의 IP 라우팅 정보를 조사하지 않습니다. 오히려, 레이블을 사용하여 레이블 포워들 테이블에서 정보를 찾아야 합니다. 그런 다음 이전 레이블을 새로운 레이블로 교체하고 패킷을 경로의 다음 스위치로 전달합니다. 패킷이 egress PE 스위치에 도달하면 레이블이 제거되고 패킷이 다시 네이티브 IP 패킷이 되고 IP 라우팅 정보를 기반으로 다시 포워드됩니다.

이 주제는 다음을 설명합니다.

MPLS 레이블 스위칭 경로 및 MPLS 레이블에 대한 추가

패킷이 네트워크로 MPLS LSP에 할당됩니다. 각 LSP는 LSP의 전면에 짧은(20비트), 고정 길이 값(MPLS 32비트)으로 식별됩니다. 레이블은 Label 포워싱 테이블에 대한 룩업 인덱스로 사용됩니다. 각 레이블에 대해 이 테이블은 포우링 정보를 저장합니다. 캡슐화된 패킷에서 추가 파스킹 또는 룩업이 수행되지 MPLS 패킷 페이로드 내의 다른 프로토콜의 전송을 지원할 수 있습니다.

주:

EX3200 MPLS EX3200 및 주니퍼 네트웍스 EX4200 이더넷 스위치 패킷 상에서 구현되는 것은 단일 레이블 패킷만 지원됩니다. 그러나 MPLS 주니퍼 네트웍스 EX8200 이더넷 스위치 3개 레이블로 패킷을 지원하고 있습니다.

그림 8 단일 레이블의 인코딩을 보여줍니다. 인코딩은 데이터 링크 레이어 헤더 이후, 네트워크 레이어 헤더 이전으로 나타납니다.

그림 8: 레이블 인코딩레이블 인코딩

예약 레이블

레이블은 0에서 1,048,575까지 범위가 있습니다. Labels 0 ~ 999,999는 내부 사용을 위한 것입니다.

예약된 레이블 중 일부는(범위 0에서 15까지)는 의미를 잘 정의하고 있습니다. 다음 예약 레이블은 스위치에서 사용됩니다.

  • 0, IPv4 Explicit Null Label—이 값은 유일한 Label 엔트리인 경우(레이블 스태킹이 없는 경우) 유효합니다. 라벨이 수신 시 터지기만 되어야 하다는 표시입니다. IP 버전 4(IPv4) 패킷을 기반으로 포링이 계속됩니다.

  • 1, 라우터 경고 레이블—패킷이 1의 상위 레이블 값과 함께 수신될 때, 처리를 위해 로컬 소프트웨어 모듈로 전달됩니다.

  • 2, IPv6 Explicit Null Label—이 값은 유일한 레이블 엔트리인 경우(레이블 스태킹이 없는 경우) 합법적입니다. 라벨이 수신 시 터지기만 되어야 하다는 표시입니다.

  • 3, Implicit Null Label—이 레이블은 시그널링 프로토콜(RSVP)에서만 다운스트림 스위치의 Label Popping을 요청하는 데 사용됩니다. 실제로 캡슐화에는 나타나지 않습니다. 3 값이 있는 레이블은 데이터 패킷에서 실제 레이블로 사용되어서도 안 됩니다. 이 레이블에는 페이로드 유형(IPv4 또는 IPv6)이 없습니다.

MPLS 레이블 작업 관리

EX Series 스위치는 다음과 같은 레이블 연산을 지원한다.

  • 밀어

  • 스왑

푸시 작업은 IP 패킷 맨 위에 새로운 레이블을 부착합니다. IPv4 패킷의 경우, 새로운 레이블은 첫 번째 레이블입니다. 패킷 헤더에서 TTL(Live To Live) 필드 값의 시간은 IP 패킷 헤더에서 도출됩니다. 푸시 작업은 이미 1개 레이블이 있는 패킷에 MPLS 수 없습니다.

POP 작업은 패킷 시작에서 레이블을 제거합니다. 레이블이 제거되고 나면 TTL은 Label에서 IP 패킷 헤더로 복사되고 기본 IP 패킷이 네이티브 IP 패킷으로 전달됩니다.

스왑 연산은 IP 패킷에서 기존 MPLS 레이블을 제거하고 다음에 따라 MPLS 새로운 MPLS 레이블로 대체합니다.

  • 수신 인터페이스

  • 라벨

  • 레이블 포우링 테이블

그림 9 수신 PE 스위치의 고객 에지 인터페이스()에 도착하지 않은 ge-0/0/1 IP 패킷을 보여줍니다. ingress PE 스위치는 패킷을 검사하고 패킷의 대상을 egress PE 스위치로 식별합니다. ingress PE 스위치는 Label 100을 패킷에 적용하고 송신 코어 인터페이스()로 MPLS 패킷을 MPLS ge-0/0/5 있습니다. 이 MPLS 패킷은 제공업체 스위치를 통해 MPLS 전송되어 ge-0/0/5 Label 100과 인터페이스에 도착합니다. 제공업체 스위치는 Label 100을 Label 200으로 교체하고 코어 인터페이스를 통해 MPLS 패킷을 egress PE 스위치인 터널의 다음 홉으로 ge-0/0/7 전달합니다. egress PE 스위치는 코어 인터페이스를 통해 MPLS 패킷을 수신하고 MPLS Label을 제거하고 고객 에지 인터페이스()에서 터널을 넘어 있는 목적지로 IP 패킷을 ge-0/0/7ge-0/0/1 전송합니다.

그림 9: MPLS 레이블 스왑 교체MPLS 레이블 스왑 교체

그림 9 수신 PE 스위치에서 egress PE 스위치로의 한 방향으로 통과하는 패킷 경로를 보여줍니다. 그러나 이 MPLS 구성을 통해 트래픽이 역방향으로 이동할 수 있습니다. 따라서 각 PE 스위치는 ingress 스위치와 egress 스위치 모두로 작동됩니다.

Penultimate-Hop Popping 및 Ultimate-Hop Popping

이 스위치는 기본적으로 IP over MPLS PHP(Penultimate-hop popping)MPLS 수 있습니다. PHP를 통해 penultimate 제공업체 스위치는 MPLS 레이블을 파핑하고 트래픽을 egress PE 스위치로 전달합니다. 그런 다음, egress PE 스위치가 IP 루트 룩업을 수행하고 트래픽을 전달합니다. 이는 egress PE 스위치의 프로세싱 부하가 MPLS 때문에 감소합니다.

스위치에서 EX8200, 기본 PHP를 사용하거나 궁극적인 홉 Popping을 구성하도록 선택할 수 있습니다.

  • 기본으로 보급된 레이블은 Label 3(Implicit Null Label)입니다. Label 3가 광고되는 경우, Penultimate-hop 스위치는 해당 라벨을 제거하고 egress PE 스위치로 패킷을 전송합니다.

  • 궁극의 홉 포핑이 활성화되면 Label 0(IPv4 Explicit Null Label)이 광고되어 LSP의 egress PE 스위치가 해당 Label을 제거합니다.

출시 내역 표
릴리스
설명
19.1R1
Junos OS Release 19.1R1(egress 패킷 전달 엔진)에 의해 푸시될 수 있는 최대 레이블 수를 활용할 수 있습니다. 즉, 다음 홉에 대해 푸시할 수 있는 레이블의 수는 MPLS 디바이스가 푸시할 수 있는 레이블 수 또는 발신 인터페이스에서 구성된 최대 레이블 family mpls 수입니다. 이 지원은 MPC 및 MIC 인터페이스를 사용하는 MX 시리즈 라우터와 제 3세대FPC를 사용하는 PTX 시리즈 라우터에서 지원됩니다.
14.2
Junos OS Release 14.2에서 시작하여, inentropy Label은 혼합 모드 섀시에서 지원됩니다. 이 섀시는 향상된 IP 구성 없이도 로피 레이블을 구성할 수 있습니다.