Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

LSP 레이블

MPLS 레이블 개요

LSP를 따라 이동하는 패킷은 레이블(20비트, 0~1,048,575 범위의 부호 없는 정수)로 식별됩니다. 수신 라우터의 푸시 레이블의 경우, 이 범위에서는 레이블이 제한되지 않습니다. 전송 정적 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) 대상 도달 불가 메시지도 생성하지 않습니다.

패킷은 후입선출 스택으로 구성된 여러 레이블을 전달할 수 있습니다. 이것을 레이블 스택이라고 합니다. 특정 라우터에서, 레이블이 지정된 패킷의 전달 방법은 전적으로 스택의 최상위 레이블에 따라 결정됩니다.

그림 1은(는) 하나의 레이블에 대한 인코딩을 보여줍니다. 인코딩은 데이터 링크 레이어 헤더 다음과 네트워크 레이어 헤더 앞에 나타납니다.

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

그림 2는 서비스 등급(CoS) 비트(EXP 또는 실험 비트라고도 함)의 용도를 보여줍니다. 비트 20과 비트 21은 대기열 번호를 지정합니다. 비트 22는 RED(random early detection) 드롭 프로파일을 지정하는 데 사용되는 PLP(packet loss priority) 비트입니다. 서비스 등급 및 서비스 등급 비트에 관한 자세한 내용은 MPLS LSP의 서비스 등급 구성을 참조하십시오.

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

MPLS 레이블에서의 작업

라우터는 다음 레이블 작업을 지원합니다:

  • 푸시 - 패킷 상단에 새로운 레이블을 추가합니다. IPv4 패킷의 경우, 새로운 레이블은 첫 번째 레이블입니다. TTL(Time-to-Live) 및 비트가 IP 패킷 헤더에서 파생됩니다. MPLS 서비스 등급(CoS)은 대기열 수에서 파생됩니다. 푸시 작업이 기존 MPLS 패킷에서 수행되면, 두 개 이상의 레이블이 있는 패킷을 갖게 됩니다. 이것은 레이블 스태킹이라고 합니다. 맨 위의 레이블은 비트 설정이 0이어야 하며, 하위 수준에서 CoS 및 TTL을 파생할 수도 있습니다. 레이블 스택의 새로운 맨 위의 레이블은 하위 레이블의 TTL 값과 관계없이 항상 TTL을 255로 초기화합니다.

  • 팝 - 패킷 시작에서 레이블을 삭제합니다. 레이블이 제거될 경우, TTL은 레이블에서 IP 패킷 헤더로 복사되고 기본 IP 패킷이 본래의 IP 패킷으로 전달됩니다. 패킷(레이블 스태킹)에서 여러 레이블이 있는 경우, 맨 위의 레이블 제거는 또 다른 MPLS 패킷을 생성합니다. 새로운 최고 레이블은 이전 최고 레이블에서 CoS 및 TTL을 파생할 수도 있습니다. 이전 최고 레이블에서 팝된 TTL 값은 새로운 최고 레이블로 다시 작성되지 않습니다.

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

  • 다중 푸시 - 기존 패킷의 맨 위에 여러 레이블(최대 3개)을 추가합니다. 이 작업은 여러 번의 푸시와 동일합니다.

  • 스왑 및 푸시 - 레이블 스택의 기존 맨 위를 새로운 레이블로 대체한 다음, 맨 위에 또 다른 새로운 레이블을 푸시합니다.

MPLS 레이블 작업 이해

전통적인 패킷 전송 패러다임에서, 패킷이 하나의 스위치에서 다음 스위치로 이동할 때 각 홉에서 독립적인 전송 결정이 이루어집니다. 이 분석 및 라우팅 테이블 정보에 기반하여 IP 네트워크 헤더가 분석되고 다음 홉이 선택됩니다. MPLS 환경에서 패킷이 MPLS 터널(즉, MPLS 트래픽에 사용하는 경로)에 들어갈 때 패킷 헤더는 단 한 번만 분석됩니다.

IP 패킷이 레이블 스위칭 경로(LSP)에 들어갈 때 수신 PE(Provider Edge) 스위치가 패킷을 조사하고 대상에 기반하여 레이블을 지정하고 패킷 헤더에 레이블을 배치합니다. 레이블은 IP 라우팅 정보에 기반하여 전달된 패킷에서 레이블과 관련된 정보에 기반으로 전달된 패킷으로 변환됩니다. 패킷은 LSP의 다음 제공업체 스위치에 전달됩니다. 이 스위치 및 LSP의 모든 부수적인 스위치는 레이블 패킷에서 어떠한 IP 라우팅 정보도 검사하지 않습니다. 오히려 레이블 포워딩 테이블 내 정보를 찾기 위해 레이블을 사용합니다. 그런 다음 오래된 레이블을 새로운 레이블로 교체하고 패킷을 경로의 다음 스위치에 전달합니다. 패킷이 송신 PE 스위치에 도달할 때 레이블이 제거되고 패킷이 다시 본래의 IP 패킷이 되며 IP 라우팅 정보에 기반하여 전달됩니다.

이 주제는 다음에 대해 설명합니다.

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

패킷이 MPLS 네트워크에 들어가면 LSP에 할당됩니다. 각 LSP는 MPLS 레이블(32비트) 앞에서 짧은 (20비트) 고정 길이 값인 레이블로 식별됩니다. 레이블은 포워딩 테이블에 대한 조회 색인으로 사용됩니다. 각 레이블의 경우, 이 테이블은 포워딩 정보를 저장합니다. 캡슐화 패킷에서 추가적인 구문 분석 또는 조회 작업이 수행되지 않기 때문에 MPLS는 패킷 페이로드 내의 다른 프로토콜 전송을 지원합니다.

그림 3은(는) 하나의 레이블에 대한 인코딩을 보여줍니다. 인코딩은 데이터 링크 레이어 헤더 다음과 네트워크 레이어 헤더 앞에 나타납니다.

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

예약 레이블

0~1,048,575 레이블. 0~999,999 레이블은 내부용입니다.

일부 예약 레이블(범위 0~15)은 효과적으로 정의된 의미를 갖습니다. 다음 예약 레이블은 QFX 시리즈 및 EX4600 장치에 의해 사용됩니다.

  • 0, IPv4 명시적 NULL 레이블 - 유일한 레이블 항목(레이블 스택이 없는 경우)인 경우에만 이 값이 유효합니다. 이는 수신 시 레이블이 나타나야 함을 의미합니다. IP 버전 4(IPv4) 패킷에 기반하여 포워딩이 계속됩니다.

  • 1, 라우터 경고 레이블 - 최상위 레이블 값이 1인 패킷이 수신된 경우, 처리를 위해 로컬 소프트웨어 모듈로 전달됩니다.

  • 3, 암시적 NULL 레이블 - 이 레이블은 다운스트림 스위치가 레이블 표시하도록 요청하는 신호 프로토콜(RSVP)에서만 사용합니다. 캡슐화에는 실제로 나타나지 않습니다. 값이 3인 레이블은 데이터 패킷에 실제 레이블로 사용하지 않아야 합니다. 이 레이블에는 페이로드 유형(IPv4 또는 IPv6)이 포함되어 있지 않습니다.

MPLS 레이블 작업

QFX 시리즈 및 EX4600 장치는 다음 MPLS 레이블 작업을 지원합니다.

  • 푸시

  • 스왑

주:

QFX 및 EX4600 장치가 레이블 스택에서 레이블 스택에 붙이거나(푸시 작업) 레이블 스택에서 제거(팝 작업)을 할 수 있는 레이블 수에는 제한이 있습니다.

  • 푸시 작업의 경우 세 개의 레이블까지 지원합니다.

  • 팝 작업의 경우 세 개의 레이블까지 지원합니다.

푸시 작업은 새로운 레이블을 IP 패킷 맨 위에 고정합니다. IPv4 패킷의 경우, 새로운 레이블은 첫 번째 레이블입니다. 패킷 헤더에서 TTL(Time to Live) 필드 값은 IP 패킷 헤더에서 파생됩니다. 이미 MPLS 레이블이 있는 패킷에 푸시 작업을 적용할 수 없습니다.

팝 작업은 패킷 시작부터 레이블을 제거합니다. 레이블이 제거될 경우, TTL은 레이블에서 IP 패킷 헤더로 복사되고 기본 IP 패킷이 본래의 IP 패킷으로 전달됩니다.

스왑 작업을 수행하면 IP 패킷에서 기존 MPLS 레이블이 제거되고 다음에 기반하여 새로운 MPLS 레이블로 대체됩니다.

  • 유입 인터페이스

  • 라벨

  • 레이블 포워딩 테이블

그림 4은(는) 레이블 없는 IP 패킷이 수신 PE 스위치의 고객 에지 인터페이스(ge-0/0/1)에 도달하는 것을 보여줍니다. 수신 PE 스위치는 패킷을 조사하고 패킷의 대상을 송신 PE 스위치로 식별합니다. 수신 PE 스위치는 패킷에 레이블 100을 적용하고 MPLS 패킷을 나가는 MPLS 코어 인터페이스(ge-0/0/5)에 보냅니다. MPLS 패킷은 공급자 스위치를 통해 MPLS 터널에 전송되고, 레이블 100이 포함된 인터페이스 ge-0/0/5에 도달합니다. 공급자 스위치는 레이블 100을 레이블 200으로 스왑하고 MPLS 패킷을 코어 인터페이스(ge-0/0/7)를 통해 터널의 다음 홉으로 전송합니다. 이 홉은 송신 PE 스위치입니다. 송신 PE 스위치는 코어 인터페이스(ge-0/0/7)를 통해 MPLS 패킷을 수신하고, MPLS 레이블을 제거하고, 고객 에지 인터페이스(ge-0/0/1)의 IP 패킷을 터널을 벗어난 대상에 보냅니다.

그림 4: MPLS 레이블 스와핑MPLS 레이블 스와핑

그림 4은(는) 수신 PE 스위치에서 송신 PE 스위치까지 한 방향으로 통과할 때 패킷 경로를 나타냅니다. 그러나 MPLS 구성을 적용하면 트래픽을 역방향으로 이동할 수 있습니다. 따라서 각 PE 스위치는 수신 스위치와 송신 스위치로 모두 작동합니다.

PHP(Penultimate-Hop Popping) 및 UHP(Ultimate-Hop Popping)

스위치는 기본적으로 MPLS 구성에서 IP를 사용하여 PHP(Penultimate-Hop Popping)를 구현합니다. PHP에서, PPS(Penultimate Provider Switch)는 MPLS 레이블을 팝업하고 트래픽을 송신 PE 스위치로 전달합니다. 그런 다음, 송신 PE 스위치는 IP 경로를 조회하고 트래픽을 전달합니다. 이렇게 하면 송신 PE 스위치에서 처리 부하를 줄일 수 있습니다. 이 스위치가 MPLS 레이블에 대한 팝 작업을 책임지지 않기 때문입니다.

  • 기본으로 광고되는 레이블은 레이블 3(Implicit Null 레이블)입니다. 레이블 3이 광고될 경우, PHP(Penultimate-Hop Popping)가 레이블을 제거하고 패킷을 송신 PE 스위치로 보냅니다.

  • UHP(Ultimate-Hop Popping)가 활성화된 경우, 레이블 0(IPv4 명시적 NULL 레이블)이 광고되고 LSP의 송신 PE 스위치가 레이블을 제거합니다.

MPLS 레이블 관리자 이해하기

MPLS 레이블 관리자는 Junos Trio Chipset이 설치된 MPC(Modular Port Concentrators)를 사용해 플랫폼에 지원되는 LSI, 동적인, 블록, 정적인 것과 같은 다양한 레이블 유형을 관리하는데 사용됩니다. 이 라인 카드는 디바이스에 enhanced-ip 명령이 구성될 때 더 높은 유연성과 확장성을 제공합니다.

label-space 명령의 기존 행동은 유지되며 권장되지 않습니다. 각 레이블 유형에 대한 여러 범위와 같은 추가 기능을 제공하기 위해 [edit protocols mpls label usage] 계층 아래 label-range 명령이 도입되었으며, label-space 구성과는 독립적입니다. 각 레이블 유형에 한 가지 범위가 필요한 경우에만 스타일을 선택할 수 있습니다.

디바이스 상에 구성된 enhanced-ip 명령에는 다음 기능이 최적화됩니다.

  • IS-IS(Intermediate System to Intermediate System) 라우팅 프로토콜을 통해 SRGB(segment-routing global block)에 사용할 수 있는 시스템 전역 레이블 풀을 정의할 수 있습니다.

  • 플랫폼이 규모를 지원할 수 있는 경우 적어도 16,000으로 vrf-table-label 공간을 늘립니다.

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

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

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

특수 MPLS 레이블

일부 예약된 레이블(0~15 범위에서)은 의미가 잘 정의되어 있습니다. 자세한 내용은 RFC 3032, MPLS 레이블 스택 인코딩을 참조하십시오.

  • 0, IPv4 명시적 Null 레이블 - 이 값은 유일한 레이블 항목(레이블 스택이 없는 경우)인 경우에만 유효합니다. 이는 수신 시 레이블이 나타나야 함을 의미합니다. IP 버전 4(IPv4) 패킷에 기반하여 포워딩이 계속됩니다.

  • 1, 라우터 경고 레이블 - 최상위 레이블 값이 1인 패킷이 수신된 경우, 처리를 위해 로컬 소프트웨어 모듈로 전달됩니다.

  • 2, IPv6 명시적 NULL 레이블 - 이 값은 고유한 레이블 항목(레이블 스택이 없는 경우)인 경우에만 유효합니다. 이는 수신 시 레이블이 나타나야 함을 의미합니다. IP 버전 6(IPv6) 패킷에 기반하여 포워딩이 계속됩니다.

  • 3, 암시적 Null 레이블 - 이 레이블은 제어 프로토콜(LDP 또는 RSVP)에서 다운스트림 라우터에 의한 레이블 팝핑을 요청하기 위해서만 사용됩니다. 캡슐화에는 실제로 나타나지 않습니다. 값이 3인 레이블은 데이터 패킷에 실제 레이블로 사용하지 않아야 합니다. 이 레이블에는 페이로드 유형(IPv4 또는 IPv6)이 포함되어 있지 않습니다.

  • 4~6 - 할당되지 않음.

  • 7, 엔트로피 레이블 표시기 - 이 레이블은 엔트로피 레이블이 레이블 스택에 있을 때 사용되며 엔트로피 레이블 앞에 옵니다.

  • 8~15 - 할당되지않음.

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

송신 라우터는 끝에서 두 번째 라우터에 3을 최종 레이블로 사용하도록 간단히 신호를 보낼 수 있으며, 이는 penultimate-hop 레이블 팝핑을 수행하라는 요청입니다. 송신 라우터는 레이블이 지정된 패킷을 처리하지 않으며, 대신 페이로드(IPv4, IPv6 또는 기타)를 직접 수신하여 송신에서 MPLS 조회를 한 번 줄입니다.

레이블 스택 패킷의 경우, 송신 라우터는 끝에서 두 번째 라우터에 의해 이미 팝핑된 최상위 레이블이 있는 MPLS 레이블 패킷을 수신합니다. 송신 라우터는 레이블 0 또는 2를 사용하는 레이블 스택 패킷을 수신할 수 없습니다. 일반적으로 끝에서 두 번째 라우터에서 레이블 3을 요청합니다.

혼합 모드 개요에서 엔트로피 레이블 지원

Junos OS 릴리스 14.2 부터 엔트로피 레이블은 강화된 IP 구성이 없이 엔트로피 레이블을 구성할 수 있는 혼합 모드 섀시에서 지원됩니다. 엔트로피 레이블은 ECMP 경로 또는 링크 어그리게이션 그룹을 통해 전송 라우터가 MPLS 트래픽을 로드 밸런싱하도록 도와줍니다. 엔트로피 레이블은 심층 패킷 검사에 의존하기보다는 트래픽 로드 밸런싱을 위해 라우터에서 사용하는 로드 밸런싱 레이블을 도입하여 레이블 스택 깊이가 증가하는 대신 전달 플레인의 패킷 처리 요구를 줄입니다. Junos OS 는 MPC나 MIC가 있는 MX 시리즈 라우터에 대해서만 엔트로피 레이블을 지원하고 강화된 IP 모드로 활성화할 수 있습니다. 그러나 코어 쪽의 인터페이스에 MPC 또는 MIC에 구성된 엔트로피 레이블이 있고 다른 쪽 끝에는 DPS(Dense Port Concentrator) 라인 카드가 있는 경우 패킷 드롭으로 이어집니다. 이를 피하기 위해 엔트로피 레이블은 이제 엔트로피 레이블이 강화된 IP 구성 없이 구성할 수 있는 혼합 모드에서 지원됩니다. 이를 통해 MX 시리즈 라우터 DPC는 접속 위치(POP) 아웃 엔트로피 레이블을 지원할 수 있습니다. 그러나 이것은 플로우 레이블을 지원하지 않습니다.

MPLS LSP를 위한 추상 홉(Abstract Hop) 개요

추상 홉은 관리 그룹, 확장된 관리 그룹, SRLGs(hared Risk Link Groups)와 같은 기존 트래픽 엔지니어링 제약 조건의 논리적 결합이며, MPLS LSP(레이블 스위칭 경로)를 설정하기 위한 제약 조건으로 시퀀싱되어 사용할 수 있는 사용자 정의 그룹 또는 라우터 클러스터가 생성됩니다. 추상 홉은 기존 경로의 제약 사항 한계를 극복하고 MPLS 트래픽 엔지니어링 기능에 몇 가지 이점을 제공합니다.

추상 홉 이해하기

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

실제 홉 제약 조건의 결점은 실패 시나리오에서 라우터 홉이 다운되거나 연결된 인터페이스의 대역폭 사용률이 포화 상태가 되면 경로가 다운된다는 것입니다(또는 로컬이나 엔드투엔드 보호에 의존함). 다른 대체 라우터를 사용하여 LSP를 복구하거나 설정할 수 있지만 LSP는 운영자가 경로 제약 조건으로 다른 라우터 홉 시퀀스를 구성하여 경로를 다시 가져오거나 보호 경로를 해제할 때까지 다운 상태를 유지합니다.

관리 그룹 또는 색상 사양 제약 조건은 실제 홉 제약 조건의 이러한 한계를 어느 정도 극복합니다. 이때, 그룹의 라우터 중 하나가 중단되거나 해당 링크 용량이 포화 상태가 되어도 LSP 설정에 영향을 주지 않습니다. 이는 경로 제약 조건에 사용할 다음 홉 라우터가 미리 선택되지 않아 LSP가 운영자의 개입 없이 동일한 관리 그룹이나 색상을 보유한 다른 라우터를 따라 설정되기 때문입니다. 그러나 라우터 그룹 제약 조건의 결점은 홈 제약 조건 간에 시퀀스가 지정될 수 없다는 것입니다.

추상 홉은 사용자 정의 라우터 그룹을 생성하여 이러한 결점을 극복하며, 각 멤버 라우터는 사용자 정의 제약 조건을 충족합니다. 사용자 정의 제약 조건은 관리 그룹, 확장된 관리 그룹, SRLGs(hared Risk Link Groups)와 같은 기존 트래픽 엔지니어링의 논리적 결합입니다. 경로 제약 조건에 사용되는 추상 홉 시퀀스를 지정하여 라우터 그룹 간에 순서 지정이 수행됩니다. 그 결과 추상 홉이 실제 홉 제약 조건 사양의 순서 지정 속성과 기타 트래픽 엔지니어링 제약 조건과 함께 제공되는 복원력을 결합합니다.

경로는 실제 및 추상 홉을 제약 조건으로 사용할 수 있습니다. 실제 홉을 사용할 때 실제 홉과 함께 라우터 시퀀스를 지정하는 대신(R1, R2, … Rn) 경로 제약 조건으로 라우터 그룹이나 추상 홉의 정렬된 집합을 지정합니다(G1, G2, … Gn). 지정된 각 라우터 그룹(예: Gi)은 사용자 정의 라우터 집합(R1, R2, Rj, … Rn)으로 구성됩니다. 그룹 라우터 중 하나가 중단되면(예: 그룹 Gi의 Router Rj), 다른 라우터(예: 동일한 그룹 Gi의 Router Rk)가 중단된 라우터(즉, Router Rj)를 대체하기 위해 경로 계산에 의해 선택됩니다. 이는 경로 제약 조건이 시퀀싱되고 개별 라우터의 시퀀스 대신 추상 홉 시퀀스를 거쳐야 하기 때문입니다.

추상 홉 사용의 이점

추상 홉은 사용자 정의 라우터 그룹입니다. 개별 라우터의 시퀀스를 사용하는 실제 홉 제약 조건과 마찬가지로 레이블 스위칭 경로(LSP) 설정에 추상 홉 시퀀스를 사용할 수 있습니다. 추상 홉을 사용하면 시퀀싱된 경로 제약 조건에 복원력을 제공합니다. 또한 추상 홉을 사용하면 다음과 같은 이점을 제공합니다.

제약 조건 결합 시퀀스 지정

현재 여러 속성을 충족하는 링크를 통해 이동 가능한 경로를 지정할 수 있습니다. 이러한 경로 제약 조건은 복합 제약 조건 조합이라고 합니다. 예를 들어 그린 컬러의 저지연 링크를 포함하고 SRLG north를 제외하는 제약 조건(Ci)이 있습니다.

그러나 복합 제약 조건 조합의 시퀀스로 경로를 지정하는 것은 지원되지 않습니다. 예를 들어, 시퀀싱된 제약 조건(C1, C2, Ci, …Cn)은 저지연 그린 링크, 지연 없는 블루 링크, 그리고 저지연 레드 링크를 포함합니다.

이러한 시퀀싱된 복합 제약 조건 조합에 대한 필요성은 각 영역에서 다른 링크 선호도(속성) 요건을 갖춘 지리적 영역의 시퀀스를 통해 경로를 설정해야 할 때 발생합니다. 추상 홉은 컴퓨팅 노드가 각 제약 조건 조합(예: Ci)을 사용자 정의 라우터 그룹, 즉 추상 홉과 매핑할 수 있도록 허용하여 이러한 요건을 충족합니다.

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

현재 경로 제약 조건 사양 기능을 사용하면 전체 경로를 따라 특정 속성의 링크를 포함하거나 제외할 수 있습니다(예: 경로에서 SRLG west 제외). 그러나 조건부로 속성을 제외 또는 포함하거나 경로의 다양한 부분에 속성을 다르게 제외 또는 포함하도록 적용하는 것은 지원되지 않습니다(예: 레드 링크를 횡단할 때만 SRLG west 제외).

이를 해결하기 위해 새 관리 그룹을 만들어 SRLG west를 포함하지 않는 모든 레드 링크를 식별하고 해당 관리 그룹과 함께 적절하게 모든 관련 링크를 구성할 수 있습니다. 이러한 접근 방식의 결점은 새 관리 그룹 구성원을 반영하려면 네트워크 전체의 구성 변경이 필요하다는 것입니다.

대신 추상 홉을 사용하여 구성 변경 사항을 수신 라우터에만 포함시킬 수 있습니다. 수신 라우터에서 제약 조건 조합이 추상 홉에 매핑되므로 전송 노드에서 새로운 구성 없이 앞에서 언급한 요건을 충족합니다.

중앙 집중식 및 분산 경로 계산 패러다임 조합

MPLS 경로의 트래픽 엔지니어링은 분산 컴퓨팅 또는 컴퓨팅 경로에 대한 중앙 집중식 컨트롤러로 수행할 수 있습니다. 두 계산 유형의 조합을 하이브리드 계산 패러다임이라고 합니다. 하이브리드 계산 접근 방식의 핵심 기능은 PCE(Path Computation Element)라고 하는 중앙 집중식 컨트롤러가 경로마다 경로 계산 지시문을 PCC(Path Computation Client)라고 하는 수신 라우터에 느슨하게 지정하는 것과 수신 라우터에서 이를 경로 계산을 위한 입력으로 사용하는 것입니다.

추상 홉 시퀀스는 중앙 집중식 컨트롤러의 가이드라인 역할로 제공됩니다. 추상 홉은 컨트롤러에 경로 제약 조건과 속성을 결합할 수 있는 유연성을 제공합니다. 이를 통해 컨트롤러는 제약 조건에서 시퀀스 요소에 구축할 수도 있습니다. 컨트롤러는 경로가 취해야 할 각 홉을 지정할 필요가 없으므로 수신 라우터가 가이드라인이나 지시문 한계 내에서 작동할 여지를 남겨둡니다.

표 1은(는) 하이브리드 계산 패러다임의 핵심 기능을 나열하고 이 접근 방식을 현재 경로 계산 방법과 비교합니다.

표 1: 추상 홉을 위한 하이브리드 계산

기능

분산 CSPF(Constrained Shortest Path First)

중앙 집중식 CSPF(Constrained Shortest Path First)

하이브리드 CSPF(Constrained Shortest Path First)

대규모 네트워크에서 빈번한 변경에 대응

 

전체적으로 정교한 경로 계산

 

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

 

복원(단일 실패 지점 없음)

 

예측 가능성

 

거의 실시간으로 네트워크 부하에 대응

 

실전 테스트(조기 도입 대비)

 

추상 홉의 Junos OS 구현

순서 인식 추상 홉 기능은 Junos OS 릴리스 17.1에서 소개됩니다. 다음 섹션은 Junos OS 추상 홉 구현에 대해 설명합니다.

추상 홉 정의

추상 홉은 사용자가 레이블 스위칭 경로(LSP) 설정에 사용하도록 정의할 수 있는 라우터 그룹입니다. 사용자는 구성 속성이라고 하는 이기종 링크 속성 또는 제약 조건의 논리적 조합을 정의하여 그룹에 포함할 라우터를 제어할 수 있습니다. 정의된 구성 속성을 충족하는 링크가 있는 라우터는 추상 홉을 나타내는 라우터 그룹으로 만듭니다.

구성 속성과 추상 홉의 매핑은 컴퓨팅 노드 또는 설정 중인 LSP 수신에 대해 로컬입니다. 그 결과, 추상 홉에는 연관된 IGP(Interior Gateway Protocol) 업데이트나 신호 전송 프로토콜 확장이 없으며, 네트워크에서 추상 홉을 구현할 때 전송 노드에 대한 새로운 구성이 필요하지 않습니다.

구성 목록을 사용하면 사용자 정의 이름으로 식별되는 구성 트래픽 엔지니어링 속성 집합을 정의할 수 있습니다. 구성 목록은 다음 구성문 중 하나를 사용하여 추상 홉 정의에 사용됩니다.

  • include-any-list—지정된 구성 속성 중 하나라도 링크에 대해 True이면 링크는 constituent-list를 충족합니다.

  • include-all-list—지정된 모든 구성 속성이 링크에 대해 True이면 링크는 constituent-list를 충족합니다.

  • exclude-all-list—지정된 구성 속성 중 어느 것도 링크에 대해 True가 아니면 링크는 constituent-list를 충족합니다.

  • exclude-any-list—지정된 구성 속성 중 하나 이상이 링크에 대해 True가 아니면 링크는 constituent-list를 충족합니다.

추상 홉은 앞에서 언급한 범주에 속할 수 있는 constituent-list 참조의 논리적 조합으로 정의됩니다. 이를 위해 추상 홉 정의에 논리 연산자인 ANDOR을(를) 포함하고 구성 목록에 적용합니다.

  • OR—추상 홉 정의의 constituent-list 참조 중 하나 이상이 연결된 노드가 추상 홉의 일부가 되도록 링크에 의해 충족되어야 합니다.

  • AND—추상 홉 정의의 모든 constituent-list 참조가 연결된 노드가 추상 홉의 일부가 되도록 링크에 의해 충족되어야 합니다.

샘플 추상 홉 정의

예를 들어, 추상 홉 hopA의 정의는 다음과 같습니다.

추상 홉 hopA는 나오는 링크가 다음 링크 속성의 논리적 조합을 각각 만족하는 모든 라우터를 포함해야 합니다.

  • hopA—((administrative group red && Srlg south) || (administrative group green || Srlg north)), 여기에서:

    • administrative group redSrlg south은(는) include-all 구성 목록에 속합니다(이 예시에서 listA1).

    • administrative group greenSrlg north은(는) include-any 구성 목록에 속합니다(이 예시에서 listA2).

    • ||은(는) OR 연산자입니다.

추상 홉 hopA의 구성은 다음과 같습니다.

  • hopA configuration

Verifying Abstract Hop Configuration

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

여기에서 출력 필드 Credibility은(는) 사용 중인 IGP(Interior Gateway Protocol)와 관련된 신뢰성을 나타냅니다.

show ted database extensive local 명령의 출력은 트래픽 엔지니어링 데이터베이스에서 캡처된 보기를 제공합니다. 키워드 local이(가) 추가되어 출력에 모든 로컬 계측이 포함됨을 나타냅니다. 명령 출력은 추상 홉을 링크 속성의 연관된 논리적 조합을 충족하는 링크의 속성으로 표시합니다.

추상 홉 hopA는 저지연 AND SRLG west용이며, 추상 홉 hopB는 SRLG west 제외용입니다. 그림 5은(는) 이러한 추상 홉의 수신 뷰를 표시합니다.

그림 5: 추상 홉의 수신 뷰추상 홉의 수신 뷰

경로 제약 조건에서 추상 홉 사용

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

경로 제약 조건에서 추상 홉 또는 실제 홉을 사용하려면 대상에 하나 이상의 CSPF(Constrained Shortest Path First) 패스가 필요하며, 일반적으로 홉당 하나의 패스가 필요합니다. 실제 홉이 경로 제약 조건으로 제공되면 제약 조건 계산에 경로 제약 조건의 홉 수만큼 많은 패스가 포함되며, 여기서 각 패스는 제약 조건 목록의 홉에 도달할 때 종료됩니다. 각 패스의 시작 지점은 이전 패스의 대상이며, 첫 번째 패스는 수신 라우터를 시작 시점으로 사용합니다.

또는 경로 제약이 엄격하거나 느슨한 추상 홉을 사용할 때 제약 조건 계산은 각 패스가 제약 조건 목록에서 후속 추상 홉을 처리하는 패스로 구성됩니다. 이 경우, 두 개 이상의 노드가 패스 대상이 됩니다. 노드 집합은 패스에 대한 실행 가능한 라우터 집합이라고 합니다.

추상 홉은 다음을 사용하여 구성원 노드를 트래버스합니다.

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

  • 모든 링크

구성원 노드를 트래버스하는 추상 홉 수단은 경로 제약 조건을 정의할 때 추상 홉 한정자(strict, loose, loose-link)를 사용하여 제어됩니다. 예를 들어, 추상 홉 hopA는 다른 한정자를 사용하여 다르게 처리됩니다.

  • Strict—제약 조건 목록에서 마지막으로 처리된 홉 이후의 경로는 다음 추상 홉 처리를 위해 실행 가능한 시작 시점인 hopA의 구성원이 있는 노드에 도달하기 전에 추상 홉 hopA의 구성원을 갖는 링크 또는 노드만 트래버스합니다.

  • Loose—제약 조건 목록에서 마지막으로 처리된 홉 이후의 경로는 다음 추상 홉 처리를 위해 실행 가능한 시작 지점인 추상 홉 구성원 hopA가 있는 노드에 도달하기 전에 hopA의 추상 홉 구성원을 갖지 않는 모든 실제 노드를 트래버스할 수 있습니다.

  • Loose-link—제약 조건 목록에서 마지막으로 처리된 홉 이후의 경로는 다음 추상 홉 처리를 위해 실행 가능한 시작 지점인 추상 홉 구성원 hopA가 있는 노드에 도달하기 전에 hopA의 추상 홉 구성원을 갖지 않는 모든 실제 노드를 트래버스할 수 있습니다. 그러나 경로는 동일한 과정 중에 추상 홉 hopA 구성원 링크를 하나 이상 트래버스해야 합니다.

    즉, loose-link 유형의 추상 홉은 제약 조건에서 실행 가능한 라우터 중 하나가 연관된 추상 홉 구성원 링크를 통해 도달할 수 있는 경우에만 처리됩니다.

샘플 추상 홉 사양

표 2은(는) 경로 제약 조건에서 추상 홉을 사용하는 것에 대한 샘플 사용 사례를 제공합니다.

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

경로 제약 조건의 목적

추상 홉 한정자

구성

실행 가능한 라우터 집합

선호도

hopA를 충족하는 링크만 갖는 hopA 구성원 노드를 트래버스합니다.

Strict

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

추상 hopA의 모든 구성원. 즉, A1, A2…An.

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

hopA의 구성원이지만 반드시 hopA를 충족시키는 링크는 아닌 노드를 트래버스합니다.

Loose

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

추상 hopA의 모든 구성원. 즉, A1, A2…An.

없음 (모든 종류의 링크)

hopA를 충족하는 하나 이상의 링크를 사용하여 hopA 구성원 노드를 트래버스합니다.

Loose-link

주:

loose-link 한정자는 loose로 간주되며, 동일한 추상 홉에 대해 strict가 뒤따릅니다. 즉, hopA loose-link는 hopA loose 및 hopA strict와 동일합니다.

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

이 경우, 경로 제약 조건에서 hopA와 연관된 두 개의 계산 패스가 있습니다. 두 패스에 대해 실행 가능한 라우터 집합은 다음과 같습니다.

추상 hopA의 모든 구성원. 즉, A1, A2…An.

주:

경로 계산 중에 라우터는 한 번만 트래버스됩니다.

이 경우, 경로 제약 조건에서 hopA와 연관된 두 개의 계산 패스가 있습니다. 두 패스에 대한 선호도는 다음과 같습니다.

  • Pass 1—없음 (모든 종류의 링크)

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

hopA를 충족하는 링크만 갖는 hopA 구성원 노드를 트래버스하고 hopB를 충족하는 링크만 갖는 hopB 구성원 노드가 뒤따릅니다.

Strict

[edit protocols mpls]
Path path_hopA_hopB_s {
    hopA abstract strict;
    hopB abstract strict;
}
  • hopA—hopA와 hopB의 구성원 세트의 교집합.

    주:

    추상 홉 뒤에 strict 추상 홉이 오면 두 구성원 세트의 교집합이 실행 가능한 라우터 집합으로 간주됩니다.

  • hopB—추상 hopB의 모든 구성원. 즉, B1, B2…Bn.

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

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

hopA를 충족하는 링크만 갖는 hopA 구성원 노드를 트래버스하고 모든 링크를 갖는 hopB 구성원 노드가 뒤따릅니다.

Strict 및 loose

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

  • hopB—추상 hopB의 모든 구성원. 즉, B1, B2…Bn.

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

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

모든 종류의 링크를 갖는 hopA 구성원 노드를 트래버스하고 모든 링크를 갖는 hopB 구성원 노드가 뒤따릅니다.

Loose

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

  • hopB—추상 hopB의 모든 구성원. 즉, B1, B2…Bn.

없음 (모든 링크를 선택)

모든 종류의 링크를 갖는 hopA 구성원 노드를 트래버스하고 hopB를 충족하는 링크만 갖는 hopB 구성원 노드가 뒤따릅니다.

Loose 및 strict

[edit protocols mpls]
Path path_hopA_l_hopB_s {
    hopA abstract loose;
    hopB abstract strict;
}
  • hopA—hopA 및 hopB 구성원 교집합.

    추상 홉 뒤에 strict 추상 홉이 오면 두 구성원 세트의 교집합이 실행 가능한 라우터 집합으로 간주됩니다.

  • hopB—추상 hopB의 모든 구성원. 즉, B1, B2…Bn.

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

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

그림 6은(는) 추상 홉 hopA, hopB, hopC의 경로 제약 조건을 각각 loose, strict, loose 추상 홉 한정자로 표시합니다.

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

추상 홉에 대한 CSPF(Constrained Shortest Path First) 패스는 다음과 같습니다.

  • hopA와 연관된 Pass 1

    • 실행 가능한 라우터—Routers R1 및 R2(hopB는 strict 추상 홉이므로 hopA와 hopB의 교집합)

    • 선호도—없음 (hopA가 loose이므로)

  • hopB와 연관된 Pass 2

    • 실행 가능한 라우터—Routers R1, R2, R3, R4

    • 선호도—hopB-compliant 링크만 선택 (hopB가 strict 추상 홉이므로)

  • hopC와 연관된 Pass 3

    • 실행 가능한 라우터—Routers R5, R6, R7, 송신 라우터

    • 선호도—없음 (hopC가 loose 추상 홉이므로)

경로 계산 및 역추적

각 CSPF(Constrained Shortest Path First) 패스의 실행 가능한 라우터 집합에서 가장 가까운 라우터가 해당 패스에 대해 파악된 선호도를 충족하는 링크를 사용하여 도달할 경우, 패스와 연관된 추상 홉이 처리됩니다. 이렇게 도달한 실행 가능한 라우터는 다음 제약 조건 패스를 위한 시작 역할을 합니다. 제약 조건 패스가 실패하고 수신 라우터가 시작 라우터로 사용되지 않는 경우 패스는 이전 패스로 역추적되고 처리 과정이 반복됩니다.

샘플 역추적

CSPF(Constrained Shortest Path First) 패스 p(첫 번째 패스 이외)가 실패하면 현재 패스 p의 시작 지점 역할을 하는 이전 패스(p – 1)의 exit 라우터는 이전 패스(p – 1)의 실행 가능한 라우터 집합에서 자격이 상실됩니다. 그럼 다음 이전 패스(p – 1)가 다시 실행되어 실행 가능한 라우터 집합에서 패스 (p – 1)에 대해 다음으로 적합한 exit 라우터나 대상을 찾습니다.

이렇게 확인된 라우터는 패스 P에 대해 새로운 시작 라우터 역할을 합니다. 이 과정은 실패가 발생하고 탐색되지 않는 실행 가능한 라우터가 있는 한 반복됩니다.

show mpls lsp abstract-hop-computation name lsp-name 명령은 LSP마다 관련된 다양한 계산 패스와 각 패스에 대해 적격한 exit 라우터를 제공합니다. 또한 명령 출력은 패스당 선호도와 패스 시 선택한 현재 시작 라우터를 보여줍니다. 각 실행 가능한 라우터의 경우, 역추적 상태가 표시되며, 이 경우 유효하거나 자격이 없는 경우가 표시됩니다.

여기에서 출력 필드 Credibility은(는) 사용 중인 IGP(Interior Gateway Protocol)와 관련된 신뢰성을 나타냅니다.

예: MPLS LSP를 위한 추상 홉(Abstract Hop) 구성

본 예시는 MPLS 레이블 스위치 경로(LSP)에 대한 추상 홉을 구성하는 방법을 보여줍니다. 추상 홉은 기존 트래픽 엔지니어링 제약의 주요 기능을 결합하여 사용자가 MPLS LSP에 대한 순서 인식 및 탄력적인 경로 제약 조건을 지정할 수 있도록 해줍니다.

요구 사항

이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.

  • M Series 멀티서비스 에지 라우터, MX 시리즈 5G 유니버설 라우팅 플랫폼, T 시리즈 코어 라우터, PTX 시리즈 패킷 전송 라우터로 조합될 수 있는 6개의 디바이스입니다.

  • Junos OS 릴리스 17.1 이상 모든 디바이스에서 실행.

시작하기 전에:

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

  • 디바이스 라우터 ID 및 자치 시스템(AS) 번호를 구성합니다.

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

  • 모든 디바이스에서 최단 경로 우선(OSPF) 또는 기타 내부 게이트웨이 프로토콜을 구성합니다.

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

개요

Junos OS 릴리스 17.1은 사용자 정의 라우터 클러스터 또는 그룹인 추상 홉을 소개합니다. 실시간 홉 제약(엄격한 또는 느슨한) 시퀀스와 유사 추상 홉 시퀀스는 레이블 스위치 경로(LSP)를 설정하는 데 사용될 수 있습니다. 경로는 실제 및 추상 홉을 제약 조건으로 사용할 수 있습니다.

추상 홉은 관리 그룹, 확장된 관리 그룹 및 SRLG와 같은 트래픽 엔지니어링 제약의 논리적 결합이며, 실제 홉의 명령 속성과 같습니다. 따라서 추상 홉의 시퀀스가 경로 제약에 사용되는 경우 해당 속성이라고 지칭되는 링크 또는 노드 속성의 논리적 조합을 충족하는 라우터 그룹 간에 명령이 수행됩니다.

추상 홉을 구성하려면 다음을 참조하십시오.

  • [edit protocols mpls] 계층 수준에서 constituent-list list-name 명령문을 포함하여 구성 트래픽 엔지니어링 속성을 가진 구성 요소를 생성합니다.

  • [edit protocols mpls abstract-hop abstract-hop-name] 계층 수준에서 추상 홉 정의에 있는 구성 요소를 포함합니다.

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

MPLS LSP에 대한 추상 홉을 구성할 때 다음 지침을 고려하십시오.

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

  • IPv6 목적지는 추상 홉 제약(IPv4 대상 작업)에서 지원되지 않습니다.

  • 추상 홉은 엄격하거나 느슨한 제약 일 수 있습니다.

  • Junos OS 릴리스 17.1의 추상 홉은 영역 내 MPLS LSP에 대해서만 제공되며 도메인 간 또는 영역 간 LSP에 대해서는 제공되지 않습니다.

  • 추상 홉 제약은 일반 지점 간 LSP에서만 활성화됩니다. 다른 유형의 MPLS LSP는 지점 대 여러 지점 LSP, 외부 제어 양방향 LSP, 동적 컨테이너 LSP, RSVP 자동 메쉬 LSP, 영역 간 LSP가 있으며 추상 홉 구성으로 지원되지 않습니다.

  • 추상 홉은 LSP에 대한 전체 최단 경로를 계산할 수 없습니다.

  • 추상 홉은 동일한 경로 제약에서 두 번 이상 언급해서는 안 됩니다.

  • 추상 홉 제약 사양은 GRES(Graceful Routing Engine Switchover), 통합된 ISSU(in-service software upgrade), NSR(nonstop routing)에 대한 지원이 영향을 미치지 않습니다.

  • 추상 홉 제약 사양은 전체 네트워크 성능에 영향을 주지 않습니다. 그러나 제한된 최단 경로에 대한 초기 계산에 걸리는 시간이 추상 홉 구성으로 더 증가합니다. 추상 홉 LSP의 설정 시간은 추상 홉 구성이 없이 LSP를 설정하는 시간보다 더 큽니다.

토폴로지

그림 7은/는 추상 홉으로 구성된 샘플 네트워크 토폴로지를 보여줍니다. 디바이스 R0 및 R3은 각각 호스트(Host 1과 Host 2)에 각각 연결되어 있습니다. 디바이스 R4 및 R5는 각각 디바이스 R0, R1, R2 및 R3에 각각 연결되어 있습니다. 디바이스 R1 및 R2는 서로 직접 연결됩니다.

디바이스 R0 및 R3은 동일한 자치 시스템(AS 64496)에서 구성됩니다. MPLS LSP는 디바이스 R0에서 디바이스 R3까지 1차 주 경로와 2개의 보조 경로(대기 및 비대기 보조 경로)로 구성됩니다.

4개의 구성 목록(c1, c2, c3 c4)는 3개의 SRLG(g1, g2 g3), 3개의 관리 그룹 (초록, 파랑, 빨강) 그리고 1개의 확장된 관리 그룹(금색)을 사용하여 생성됩니다. 3개의 추상 홉(ah1, ah2, ah3)은 구성된 구성 요소를 사용하여 정의되고 경로 제약으로 지정됩니다. 추상 홉 ah1은 기본 경로에 대한 제약으로 지정되고, 추상 홉 ah2와 ah3는 각각 2차 대기 경로와 2차 비대기 경로에 대한 제약으로 지정됩니다.

그림 7: 추상 홉 경로 제약 구성하기추상 홉 경로 제약 구성하기

구성

CLI 빠른 구성

이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣은 다음, 구성 모드에서 commit을 입력합니다.

디바이스 R0

디바이스 R1

디바이스 R2

디바이스 R3

디바이스 R4

디바이스 R5

절차

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 관한 정보는 CLI 사용자 가이드에서 구성 모드에서 CLI 편집기 사용을 참조하십시오.

디바이스 R0 구성:

  1. 디바이스 R0에서 향상된 네트워크 서비스 사용을 활성화합니다.

  2. 루프백 인터페이스를 포함하여 디바이스 R0의 인터페이스를 구성합니다.

  3. 디바이스 R0에 대한 라우터 ID 및 자동 시스템 번호를 할당합니다.

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

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

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

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

  8. 트래픽 엔지니어링 속성을 통해 디바이스 R0의 인터페이스를 할당합니다.

  9. LSP 디바이스 R0을 디바이스 R3과 함께 구성하고 LSP에 기본 및 2차 경로 속성을 할당합니다.

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

  11. 추상적 홉 정의에 대한 구성 트래픽 엔지니어링 속성을 가진 구성 요소를 생성합니다.

  12. 구성된 구성 요소와 해당 운영자를 할당하여 추상 홉을 정의합니다.

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

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

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

  16. 패킷 당 기준으로 로드 밸런싱 기능을 활성화하기 위해 디바이스 R0에 대한 정책 구성을 구성합니다.

  17. 로드 밸런스 정책을 포워딩 테이블로 내보내십시오.

결과

구성 모드에서 show chassis, show interfaces, show routing-options, show protocolsshow policy-options 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

검증

구성이 올바르게 작동하고 있는지 확인합니다.

추상 홉 구성 확인

목적

추상 홉 멤버쉽 테이블을 표시하는 show mpls abstract-hop-membership 명령을 실행하여 디바이스 R0에 대한 추상 홉 정의 구성원을 확인합니다.

작업

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

의미

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

추상 홉 경로 계산 확인

목적

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

작업

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

의미

show mpls lsp abstract-hop-computation 명령 출력은 LSP 당 관련된 다양한 계산 패스와 각 패스에 대한 적격 출구 장비를 제공합니다. 또한 명령 출력은 패스당 친화성 및 패스 시 선택한 현재 시작 디바이스를 보여줍니다. 각 실행 가능한 라우터 (디바이스)의 경우, 역추적 상태가 표시되며, 이 경우 유효하거나 자격이 없는 경우가 표시됩니다.

Credibility 필드는 사용 중인 내부 게이트웨이 프로토콜(최단 경로 우선(OSPF))에 연관된 신뢰성 값을 나타냅니다.

MPLS 레이블의 최대 수 구성

MPLS 응용 프로그램에 대해 구성하는 인터페이스의 경우 MPLS가 작동할 수 있는 최대 레이블 수를 설정할 수 있습니다.

기본적으로 최대 레이블 수는 3개입니다. 4개 또는 5개의 레이블이 필요한 응용 프로그램의 경우 최대 레이블을 4개 또는 5개로 변경할 수 있습니다.

Junos OS 릴리스 19.1R1부터, 출력 패킷 포워딩 엔진(PFE)에 의해 푸시될 수 있는 최대 레이블 수를 활용할 수 있습니다. 여기서 MPLS 다음 홉에 푸시될 수 있는 레이블 수는 디바이스가 푸시할 수 있는 레이블 수이거나, 또는 출력 인터페이스의 에 따라 구성된 maximum-labels 입니다 family mpls. 이중 더 작은 수가 선택됩니다. 이 지원은 MPC 및 MIC 인터페이스가 있는 MX 시리즈 라우터와 3세대 FPC가 있는 PTX 시리즈 라우터에서 사용할 수 있습니다.

주:

PTX 시리즈 라우터에서 입력 PFE에 의해 푸시될 수 있는 최대 레이블 수는 4개이고 출력 PFE는 8개입니다.

향상된 레이블 푸시 기능은 세그먼트 라우팅 트래픽 엔지니어링 LSP 및 RSVP-TE 팝 앤 포워드 LSP와 같은 기능에 유용합니다. MPLS 다음 홉을 사용하는 애플리케이션의 모든 기존 기능은 향상된 레이블 푸시 기능으로 계속 작동합니다. 여기에는 다음이 포함됩니다.

  • MPLS LSP에 대한 lsping, traceroute 및 BFD와 같은 모든 OAM 유틸리티

  • MPLS LSP에 대한 lspmon 및 LMDM과 같은 모니터링 유틸리티

show route tableshow route forwarding-table 명령 출력은 다음 홉 구성 요소당 최대 16개의 레이블을 표시하도록 향상되었습니다.

예:

주:

인터페이스의 최대 MPLS 레이블 수가 수정되면 MPLS 인터페이스가 반송됩니다. 해당 인터페이스의 모든 LDP 및 RSVP 세션이 재시작되어 해당 인터페이스를 통해 모든 LSP가 플랩됩니다.

예를 들어 VPN 서비스를 제공하는 고객을 위해 2계층 서비스 프로바이더 VPN 서비스를 구성한다고 가정합니다. 서비스 프로바이더 VPN은 공급자 서비스 프로바이더(계층 1 ISP)와 고객 서비스 프로바이더(계층 2 ISP) 사이의 2계층 관계입니다. 서비스 프로바이더 VPN에서, 공급자 서비스 프로바이더는 고객 서비스 프로바이더를 위한 VPN 백본 네트워크를 제공합니다. 고객 서비스 프로바이더는 차례로 최종 고객에게 계층 3 VPN 서비스를 제공합니다. 고객 서비스 프로바이더는 레이블이 부착된 트래픽을 공급자 서비스 프로바이더에 전송하여 공급자 서비스 프로바이더의 네트워크 반대편에 있는 다음 홉으로 전달합니다. 이 시나리오에는 3개의 레이블 스택이 필요합니다. 공급자 서비스 프로바이더 VPN에 대한 레이블 하나와 고객 서비스 프로바이더 VPN에 대한 레이블 하나, 전송 경로에 대한 세 번째 레이블 하나가 있습니다.

FR(Fast Rerout) 서비스를 추가하는 경우 공급자 서비스 프로바이더 네트워크에 있는 PE 라우터가 네 번째 레이블(재루팅 레이블)을 지원하도록 구성해야 합니다. 고객 서비스 프로바이더가 신호 프로토콜로 LDP를 사용하고 있고 공급자 서비스 프로바이더가 RSVP를 사용하는 경우, 공급자 서비스 프로바이더는 RSVP 터널 서비스를 통해 LDP를 지원해야 합니다. 이 추가 서비스는 총 5개의 레이블에 대한 추가 레이블이 필요합니다.

고객 서비스 프로바이더에 있어서, 공급자 서비스 프로바이더의 VPN에 연결하는 데 사용하는 라우터는 PE 라우터입니다. 그러나 공급자는 이 디바이스를 CE 라우터로 간주합니다.

표 3은(는) 레이블 요구 사항을 개괄적으로 보여줍니다.

표 3: 3, 4 또는 5 MPLS 레이블을 사용하기 위한 샘플 시나리오

필수 레이블 수

시나리오

3

서비스 프로바이더 VPN 또는 두 개의 레이블이 있고 FR(Fast Reroute)이 가능한 VPN

4

서비스 프로바이더 및 FR(Fast Reroute) 결합

5

FR(Fast Reroute)이 가능한 서비스 프로바이더 및 LDP를 실행하는 고객 서비스 프로바이더, RSVP를 실행하는 공급자 서비스 프로바이더

최대 레이블 수를 구성하고 모니터링하려면,

  1. 논리적 인터페이스의 최대값을 지정합니다. 이 구성을 서비스 프로바이더의 PE 라우터에 적용합니다.
  2. 구성을 확인합니다.

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

최종 홉 라우터에서 레이블이 접속 위치(POP)하도록 MPLS 구성

레이블 스위치 경로(LSP)의 송신 라우터에서 통지되는 레이블 값을 제어할 수 있습니다. 기본으로 통지되는 레이블은 레이블 3(잠재적 Null 레이블)입니다. 레이블 3이 광고되면 Penultimate-Hop 라우터가 레이블을 제거하고 패킷을 송신 라우터로 보냅니다. 최종 홉 팝핑을 가능하게 함으로써 레이블 0(IPv4 명시적 Null 레이블)이 통지됩니다. UHP(Ultimate-Hop Popping)는 MPLS 네트워크를 트래버스하는 모든 패킷이 레이블을 포함하도록 합니다.

주:

주니퍼 네트웍스 라우터는 수신 레이블을 기반으로 패킷을 대기열에 넣습니다. 다른 벤더의 라우터는 패킷을 다르게 대기열에 넣을 수 있습니다. 여러 벤더의 라우터가 포함된 네트워크에서 작업할 때는 이 사실을 염두에 두십시오.

최종 홉 라우터에 레이블이 팝핑하도록 MPLS 구성을 하려면 explicit-null문을 포함합니다.

이 명령문은 다음의 계층 수준에서 구성하실 수 있습니다.

  • [edit protocols mpls]

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

BGP(Border Gateway Protocol) 피어로 명시적 Null 레이블 광고하기

IPv4 (inet) 체계만을 위해 라우팅 그룹의 BGP 피어는 inet labeled-unicast와 inet6 labeled-unicast NLRI에 대한 연결된 경로(직접 또는 루프백 루트)에 대한 명시적 Null 레이블을 제공할 수 있습니다. 기본적으로 피어는 레이블 3을 광고합니다(암시적 NULL). explicit-null 명령문이 활성화되면 피어는 레이블 0을 광고합니다(명시적 NULL). 명시적 NULL 레이블은 MPLS 네트워크를 통과하는 패킷에 레이블이 항상 존재하도록 보장합니다. 암시적 NULL 레이블을 사용하면 끝에서 두 번째(Penultimate) 홉 라우터는 레이블을 제거하고 일반 IP 패킷으로 패킷을 송신 라우터에 보냅니다. 끝에서 두 번째 홉이 다른 공급 업체의 라우터인 경우 끝에서 이로 인해 두 번째 홉 라우터에서 패킷 대기열에 문제가 발생할 수 있습니다. 일부 다른 공급 업체는 수신 레이블이 아닌 나가는 레이블의 CoS(class of service) 비트를 기반으로 패킷을 대기열에 넣을 수 있습니다.

명시적 Null 레이블을 광고하려면 다음의 명령문을 구성에 포함시킵니다.

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

connected-only 명령문은 명시적 Null 레이블을 광고할 필요가 있습니다.

명시적 NULL 레이블을 연결된 경로에 대한 광고되는지 확인하기 위해 show route advertising-protocol bgp neighbor-address 명령을 사용합니다.

EX 시리즈 스위치에서 MPLS 레이블 작업 이해하기

전통적인 패킷 전송 패러다임에서, 패킷이 하나의 스위치에서 다음 스위치로 이동할 때 각 홉에서 독립적인 전송 결정이 이루어집니다. 이 분석 및 라우팅 테이블 정보에 기반하여 IP 네트워크 헤더가 분석되고 다음 홉이 선택됩니다. MPLS 환경에서 패킷이 MPLS 터널(즉, MPLS 트래픽에 사용하는 경로)에 들어갈 때 패킷 헤더는 단 한 번만 분석됩니다.

IP 패킷이 레이블 스위칭 경로(LSP)에 들어갈 때 수신 PE(Provider Edge) 스위치가 패킷을 조사하고 대상에 기반하여 레이블을 지정하고 패킷 헤더에 레이블을 배치합니다. 레이블은 IP 라우팅 정보에 기반하여 전달된 패킷에서 레이블과 관련된 정보에 기반으로 전달된 패킷으로 변환됩니다. 패킷은 LSP의 다음 제공업체 스위치에 전달됩니다. 이 스위치 및 LSP의 모든 부수적인 스위치는 레이블 패킷에서 어떠한 IP 라우팅 정보도 검사하지 않습니다. 오히려 레이블 포워딩 테이블 내 정보를 찾기 위해 레이블을 사용합니다. 그런 다음 오래된 레이블을 새로운 레이블로 교체하고 패킷을 경로의 다음 스위치에 전달합니다. 패킷이 송신 PE 스위치에 도달할 때 레이블이 제거되고 패킷이 다시 본래의 IP 패킷이 되며 IP 라우팅 정보에 기반하여 다시 전달됩니다.

이 주제는 다음에 대해 설명합니다.

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

패킷이 MPLS 네트워크에 들어가면 LSP에 할당됩니다. 각 LSP는 MPLS 레이블(32비트) 앞에서 짧은 (20비트) 고정 길이 값인 레이블로 식별됩니다. 레이블은 포워딩 테이블에 대한 조회 색인으로 사용됩니다. 각 레이블의 경우, 이 테이블은 포워딩 정보를 저장합니다. 캡슐화 패킷에서 추가적인 구문 분석 또는 조회 작업이 수행되지 않기 때문에 MPLS는 패킷 페이로드 내의 다른 프로토콜 전송을 지원합니다.

주:

주니퍼 네트웍스 EX3200 및 EX4200 이더넷 스위치에 대한 MPLS 구현 기능은 단일 레이블 패킷만 지원합니다. 그러나 주니퍼 네트웍스 EX8200 이더넷 스위치에 대한 MPLS 구현 기능은 세 개의 레이블을 가진 패킷을 지원합니다.

그림 8은(는) 하나의 레이블에 대한 인코딩을 보여줍니다. 인코딩은 데이터 링크 레이어 헤더 다음과 네트워크 레이어 헤더 앞에 나타납니다.

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

예약 레이블

0~1,048,575 레이블. 0~999,999 레이블은 내부용입니다.

일부 예약 레이블(범위 0~15)은 효과적으로 정의된 의미를 갖습니다. 다음 예약 레이블은 스위치에 의해 사용됩니다.

  • 0, IPv4 명시적 NULL 레이블 - 유일한 레이블 항목(레이블 스택이 없는 경우)인 경우에만 이 값이 유효합니다. 이는 수신 시 레이블이 나타나야 함을 의미합니다. IP 버전 4(IPv4) 패킷에 기반하여 포워딩이 계속됩니다.

  • 1, 라우터 경고 레이블 - 최상위 레이블 값이 1인 패킷이 수신된 경우, 처리를 위해 로컬 소프트웨어 모듈로 전달됩니다.

  • 2, IPv6 명시적 NULL 레이블 - 이 값은 고유한 레이블 항목(레이블 스택이 없는 경우)인 경우에만 유효합니다. 이는 수신 시 레이블이 나타나야 함을 의미합니다.

  • 3, 암시적 NULL 레이블 - 이 레이블은 다운스트림 스위치가 레이블 표시하도록 요청하는 신호 프로토콜(RSVP)에서만 사용합니다. 캡슐화에는 실제로 나타나지 않습니다. 값이 3인 레이블은 데이터 패킷에 실제 레이블로 사용하지 않아야 합니다. 이 레이블에는 페이로드 유형(IPv4 또는 IPv6)이 포함되어 있지 않습니다.

스위치에서 MPLS 레이블 작업

EX 시리즈 스위치는 다음 레이블 작업을 지원합니다.

  • 푸시

  • 스왑

푸시 작업은 새로운 레이블을 IP 패킷 맨 위에 고정합니다. IPv4 패킷의 경우, 새로운 레이블은 첫 번째 레이블입니다. 패킷 헤더에서 TTL(Time to Live) 필드 값은 IP 패킷 헤더에서 파생됩니다. 이미 MPLS 레이블이 있는 패킷에 푸시 작업을 적용할 수 없습니다.

팝 작업은 패킷 시작부터 레이블을 제거합니다. 레이블이 제거될 경우, TTL은 레이블에서 IP 패킷 헤더로 복사되고 기본 IP 패킷이 본래의 IP 패킷으로 전달됩니다.

스왑 작업을 수행하면 IP 패킷에서 기존 MPLS 레이블이 제거되고 다음에 기반하여 새로운 MPLS 레이블로 대체됩니다.

  • 유입 인터페이스

  • 라벨

  • 레이블 포워딩 테이블

그림 9은(는) 수신 PE 스위치의 고객 에지 인터페이스(ge-0/0/1)에 도착하는 레이블이 없는 상태의 IP 패킷을 나타냅니다. 수신 PE 스위치는 패킷을 조사하고 패킷의 대상을 송신 PE 스위치로 식별합니다. 수신 PE 스위치는 패킷에 레이블 100을 적용하고 MPLS 패킷을 발신 MPLS 코어 인터페이스(ge-0/0/5)로 보냅니다. MPLS 패킷은 PS(Provider Switch)를 통해 MPLS 터널로 전송되며 이 패킷은 여기에서 레이블 100이 있는ge-0/0/5 인터페이스에 도착합니다. PS(Provider Switch)는 레이블 100을 레이블 200으로 스왑하고 MPLS 패킷을 코어 인터페이스(ge-0/0/7)를 통해 터널의 다음 홉으로 전송합니다. 이 홉은 송신 PE 스위치입니다. 송신 PE 스위치는 코어 인터페이스(ge-0/0/7)를 통해 MPLS 패킷을 수신하고, MPLS 레이블을 제거하고, 고객 에지 인터페이스(ge-0/0/1)의 IP 패킷을 터널을 벗어난 대상에 보냅니다.

그림 9: MPLS 레이블 스와핑MPLS 레이블 스와핑

그림 9은(는) 수신 PE 스위치에서 송신 PE 스위치까지 한 방향으로 통과할 때 패킷 경로를 나타냅니다. 그러나 MPLS 구성을 적용하면 트래픽을 역방향으로 이동할 수 있습니다. 따라서 각 PE 스위치는 수신 스위치와 송신 스위치로 모두 작동합니다.

PHP(Penultimate-Hop Popping) 및 UHP(Ultimate-Hop Popping)

스위치는 기본적으로 MPLS 구성에서 IP를 사용하여 PHP(Penultimate-Hop Popping)를 구현합니다. PHP에서, PPS(Penultimate Provider Switch)는 MPLS 레이블을 팝업하고 트래픽을 송신 PE 스위치로 전달합니다. 그런 다음, 송신 PE 스위치는 IP 경로를 조회하고 트래픽을 전달합니다. 이렇게 하면 송신 PE 스위치에서 처리 부하를 줄일 수 있습니다. 이 스위치가 MPLS 레이블에 대한 팝 작업을 책임지지 않기 때문입니다.

EX8200 스위치에서 기본적으로 PHP를 사용하거나 UHP(Ultimate-Hop Popping)를 구성할지 선택할 수 있습니다.

  • 기본으로 광고되는 레이블은 레이블 3(Implicit Null 레이블)입니다. 레이블 3이 광고될 경우, PHP(Penultimate-Hop Popping)가 레이블을 제거하고 패킷을 송신 PE 스위치로 보냅니다.

  • UHP(Ultimate-Hop Popping)가 활성화된 경우, 레이블 0(IPv4 명시적 NULL 레이블)이 광고되고 LSP의 송신 PE 스위치가 레이블을 제거합니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

릴리스
설명
19.1R1
Junos OS 릴리스 19.1R1부터, 출력 패킷 포워딩 엔진(PFE)에 의해 푸시될 수 있는 최대 레이블 수를 활용할 수 있습니다. 여기서 MPLS 다음 홉에 푸시될 수 있는 레이블 수는 디바이스가 푸시할 수 있는 레이블 수이거나, 또는 출력 인터페이스의 에 따라 구성된 maximum-labels 입니다 family mpls. 이중 더 작은 수가 선택됩니다. 이 지원은 MPC 및 MIC 인터페이스가 있는 MX 시리즈 라우터와 3세대 FPC가 있는 PTX 시리즈 라우터에서 사용할 수 있습니다.
14.2
Junos OS 릴리스 14.2 부터 엔트로피 레이블은 강화된 IP 구성이 없이 엔트로피 레이블을 구성할 수 있는 혼합 모드 섀시에서 지원됩니다.