Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PCEP 구성

PCEP 개요

PCE(Path Computation Element)는 네트워크 그래프를 기반으로 네트워크 경로 또는 경로를 계산하고 계산 제약 조건을 적용할 수 있는 엔터티(구성 요소, 애플리케이션 또는 네트워크 노드)입니다. PCC(Path Computation Client)는 PCE에서 수행할 경로 계산을 요청하는 모든 클라이언트 애플리케이션입니다. PCEP(Path Computation Element Protocol)는 PCC와 PCE 간 또는 두 PCE(RFC 5440에 정의됨) 간의 통신을 가능하게 합니다.

PCEP는 IETF PCE Working Group에서 정의한 TCP 기반 프로토콜로, PCEP 세션을 관리하고 TE LSP(Multidomain Traffic Engineered LSP)에 대한 경로를 요청 및 전송하는 데 사용되는 일련의 메시지 및 개체를 정의합니다. PCE가 PCC의 외부 LSP에 대한 경로 계산을 수행할 수 있는 메커니즘을 제공합니다. PCEP 상호 작용에는 PCC에서 PCE로 보낸 LSP 상태 보고서와 외부 LSP에 대한 PCE 업데이트가 포함됩니다.

그림 1 에서는 MPLS RSVP-TE 지원 네트워크에서 상태 저장 PCE 아키텍처의 클라이언트 측 구현에서 PCEP의 역할을 보여줍니다.

그림 1: PCEP 세션PCEP 세션

TCP 기반 PCEP 세션은 PCC를 외부 PCE에 연결합니다. PCC는 PCEP 세션을 시작하고 PCEP 세션 기간 동안 PCE에 연결된 상태를 유지합니다. PCEP 세션 동안 PCC는 스테이트풀 PCE에서 LSP 매개 변수를 요청합니다. PCE로부터 하나 이상의 LSP 매개 변수를 수신하면 PCC는 TE LSP에 다시 신호를 보냅니다. PCEP 세션이 종료되면 기본 TCP 연결이 즉시 닫히고 PCC는 PCEP 세션 재설정을 시도합니다.

따라서 PCEP 기능에는 다음이 포함됩니다.

  • PCC와 스테이트풀 PCE 간의 LSP 터널 상태 동기화 - 활성 스테이트풀 PCE 연결이 감지되면 PCC는 LSP 상태 동기화라는 절차에서 모든 LSP를 이 PCE에 위임하려고 시도합니다. PCEP를 사용하면 PCC LSP 상태를 PCE에 동기화할 수 있습니다.

  • LSP 터널에 대한 제어를 스테이트풀 PCE로 위임 - 액티브 스테이트풀 PCE는 대역폭, 경로(ERO) 및 우선순위(설정 및 보류)와 같은 컴퓨팅 경로에 대한 하나 이상의 LSP 속성을 제어합니다. PCEP는 경로 계산을 위해 이러한 LSP 위임을 가능하게 합니다.

  • PCEP 세션 내 및 PCEP 세션 전반에 걸쳐 경로 계산의 타이밍 및 시퀀스에 대한 스테이트풀 PCE 제어 – 액티브 스테이트풀 PCE는 대역폭, 경로(ERO) 및 우선순위(설정 및 보류)와 같은 하나 이상의 LSP 속성을 수정합니다. PCEP는 이러한 새로운 LSP 속성을 PCE에서 PCC로 전달한 후 PCC는 지정된 경로에서 LSP를 다시 시그널링합니다.

RSVP-TE를 위한 경로 계산 요소 프로토콜 지원 개요

MPLS RSVP-TE 이해

트래픽 엔지니어링(TE)은 운영 네트워크의 성능 최적화를 다루며, 주로 트래픽 흐름을 기존 물리적 토폴로지에 매핑합니다. 트래픽 엔지니어링을 수행하면 트래픽 플로우를 내부 게이트웨이 프로토콜(IGP)이 선택한 최단 경로에서 나와 네트워크 전체에 걸쳐 잠재적으로 덜 혼잡한 물리적 경로로 이동할 수 있습니다.

대규모의 고밀도 네트워크의 트래픽 엔지니어링의 경우, 오버레이 모델에서 사용할 수 있는 대부분의 기능을 통합된 방식으로 현재 경쟁 제품보다 저렴한 비용으로 제공할 수 있으므로 MPLS 기능을 구현할 수 있습니다. MPLS 트래픽 엔지니어링을 구현하는 주된 이유는 트래픽이 네트워크를 통해 흐르는 경로를 제어하기 위해서입니다. MPLS 트래픽 엔지니어링 구현의 주요 이점은 IP의 CoS(class-of-service) 차별화와 함께 ATM의 트래픽 엔지니어링 기능을 조합하여 제공한다는 것입니다.

MPLS 네트워크에서 데이터 플레인 정보는 레이블 스위칭을 사용하여 전달됩니다. 고객 에지(CE) 라우터에서 프로바이더 에지(PE) 라우터에 도착하는 패킷에는 레이블이 적용된 다음 송신 PE 라우터로 전달됩니다. 레이블은 송신 라우터에서 제거된 다음 IP 패킷으로 적절한 대상에 전달됩니다. MPLS 도메인의 레이블 스위칭 라우터(LSR)는 레이블 배포 프로토콜을 사용하여 LSR 간에 또는 LSR을 통해 트래픽을 전달하는 데 사용되는 레이블의 의미를 전달합니다. RSVP-TE는 LSR 피어가 다른 피어의 레이블 매핑에 대해 학습할 수 있도록 하는 레이블 배포 프로토콜 중 하나입니다.

라우터에서 MPLS 및 RSVP가 모두 활성화되면 MPLS는 RSVP 클라이언트가 됩니다. Junos OS RSVP 소프트웨어의 주요 목적은 LSP(Label-Switched Path) 내에서 동적 신호를 지원하는 것입니다. RSVP는 IP 유니캐스트 및 멀티캐스트 흐름과 같은 리소스를 예약하고 애플리케이션에 대한 QoS(Quality of Service) 매개 변수를 요청합니다. 이 프로토콜은 RSVP가 MPLS 네트워크에서 트래픽 엔지니어링에 사용할 수 있는 LSP를 설정할 수 있도록 MPLS 트래픽 엔지니어링에서 확장됩니다.

MPLS와 RSVP가 결합되면 레이블은 RSVP 흐름과 연결됩니다. LSP가 설정되면 경로를 통과하는 트래픽은 LSP의 수신 노드에 적용된 레이블에 의해 정의됩니다. 레이블과 트래픽의 매핑은 다양한 기준을 사용하여 수행됩니다. 특정 노드에 의해 동일한 레이블 값이 할당된 패킷 세트는 동일한 FEC(Forwarding Equivalence Class)에 속하며 RSVP 플로우를 효과적으로 정의합니다. 이러한 방식으로 트래픽이 LSP에 매핑되면 LSP를 LSP 터널이라고 합니다.

LSP 터널은 단방향 레이블 전환 경로를 설정하는 방법입니다. RSVP-TE는 LSP 설정을 위해 PATH 및 RESV 객체에 사용되는 새로운 객체를 정의하고 기존 객체를 수정함으로써 RSVP 코어 프로토콜을 기반으로 구축됩니다. 새로운 객체인 LABEL-REQUEST 객체(LRO), RECORD-ROUTE 객체(RRO), LABEL 객체 및 ERO(EXPLICIT-ROUTE 객체)는 LSP 터널 구축에 필수적인 LRO 및 LABEL 객체를 제외하고 RSVP 프로토콜과 관련하여 선택 사항입니다.

일반적으로 RSVP-TE는 수신 라우터에서 송신 라우터로의 프레임 전달을 보장하는 레이블 전환 경로를 설정합니다. 그러나 새로운 트래픽 엔지니어링 기능을 통해 MPLS 도메인에서 다음 기능이 지원됩니다.

  • 전체 또는 부분 명시적 경로(RFC 3209)를 사용하여 레이블 전환 경로를 설정할 수 있습니다.

  • 대역폭 및 링크 속성과 같은 요구 사항을 충족하는 링크에 대한 제약 기반 LSP 설정.

  • 수신 및 송신 라우터에서 LSP 터널을 설정하고 관리하는 것과 관련된 엔드포인트 제어.

  • 링크 관리: 트래픽 엔지니어링 LSP의 리소스 인식 라우팅을 수행하고 MPLS 레이블을 프로그래밍하기 위해 링크 리소스를 관리합니다.

  • 보호가 필요한 LSP를 관리하고 이러한 LSP에 백업 터널 정보를 할당하는 MPLS FRR(Fast Reroute).

현재 MPLS RSVP-TE 제한 사항

트래픽 엔지니어링을 위한 RSVP 확장은 더 나은 네트워크 활용을 가능하게 하고 트래픽 클래스의 요구 사항을 충족하지만, 오늘날의 MPLS RSVP-TE 프로토콜 제품군은 분산 특성에 내재된 몇 가지 문제를 가지고 있습니다. 이로 인해 이등분부 용량에 대한 경합 중에 많은 문제가 발생하며, 특히 LSP 하위 집합이 공통 설정을 공유하고 우선 순위 값을 유지하는 LSP 우선 순위 클래스 내에서 더욱 그렇습니다. RSVP-TE의 제한 사항은 다음과 같습니다.

  • 개별 LSP, 디바이스당 대역폭 수요에 대한 가시성 부족 - MPLS RSVP-TE 네트워크의 수신 라우터는 네트워크의 대역폭 수요를 전체적으로 보지 않고도 LSP를 설정합니다. 네트워크 리소스 사용률에 대한 정보는 인터페이스별로 트래픽 클래스별 총 예약 용량으로만 제공됩니다. 개별 LSP 상태는 자체 LSP에 대해서만 각 레이블 에지 라우터(LER)에서 로컬로 사용할 수 있습니다. 그 결과, 수요 패턴과 관련된 많은 문제가 발생하며, 특히 공통 설정 및 유지 우선 순위 내에서 발생합니다.

  • RSVP 시그널링의 비동기적이고 독립적인 특성 - RSVP-TE에서 경로 설정에 대한 제약은 관리자에 의해 제어됩니다. 이와 같이 LSP 터널에 예약된 대역폭은 관리자가 설정하며 터널을 통해 전송되는 트래픽에 대한 제한을 자동으로 의미하지 않습니다. 따라서 트래픽 엔지니어링 링크에서 사용할 수 있는 대역폭은 링크에 대해 구성된 대역폭이며, 링크에 대한 모든 예약의 합계를 제외합니다. 따라서, LSP 터널에 대한 신호 없는 요구는 트래픽 엔지니어링 링크의 대역폭 요구 사항을 준수하는 다른 LSP뿐만 아니라 초과 대역폭을 필요로 하는 LSP의 서비스 저하로 이어집니다.

  • 기본 설정 순서의 동적 또는 명시적 경로 옵션을 기반으로 설정된 LSP - MPLS RSVP-TE 네트워크의 수신 라우터는 도착 순서에 따라 수요에 대한 LSP를 설정합니다. 수신 라우터는 네트워크의 대역폭 수요에 대한 전역 관점을 가지고 있지 않기 때문에 LSP를 설정하기 위해 우선 순위를 사용하면 대역폭 요구가 초과될 때 트래픽이 삭제되거나 LSP가 전혀 설정되지 않을 수 있습니다.

예를 들어, MPLS RSVP-TE로 구성되며, 여기서 A와 G는 레이블 에지 라우터(LER)입니다.그림 2 이러한 수신 라우터는 요구 순서에 따라 독립적으로 LSP를 설정하며 서로의 LSP에 대한 지식이나 제어가 없습니다. 라우터 B, C, D는 송신 라우터 E와 F에 연결되는 중간 또는 전송 라우터입니다.

그림 2: MPLS 트래픽 엔지니어링 예MPLS 트래픽 엔지니어링 예

수신 라우터는 요구가 도착하는 순서에 따라 LSP를 설정합니다. 라우터 G가 G-F에 대해 각각 용량 5의 두 가지 요구를 수신하면 G는 G-B-D-F를 통해 두 개의 LSP(LSP1 및 LSP2)에 신호를 보냅니다. 같은 방식으로, 라우터 A가 A-E에 대한 용량 10의 세 번째 수요를 수신하면 A-B-C-E를 통해 LSP, LSP3에 신호를 보냅니다. 그러나 A-E LSP에 대한 수요가 10에서 15로 증가하면 라우터 A는 B-C 링크의 용량이 더 낮기 때문에 동일한 (A-B-C-E) 경로를 사용하여 LSP3에 신호를 보낼 수 없습니다.

라우터 A는 A-B-D-C-E 경로를 사용하여 LSP3에 대한 수요 증가를 신호했어야 합니다. LSP1과 LSP2는 수신된 수요의 순서에 따라 B-D 링크를 활용했기 때문에 LSP3는 신호를 받지 않습니다.

따라서, 모든 LSP에 대해 적절한 최대 플로우 대역폭을 사용할 수 있지만, LSP3는 잠재적으로 장기간의 서비스 저하를 겪을 수 있습니다. 이는 라우터 A가 글로벌 수요 가시성이 부족하고 수신 라우터 A와 G의 수요 배치에 대한 체계적인 조정이 부족하기 때문입니다.

외부 경로 컴퓨팅 엔터티 사용

MPLS RSVP-TE 경로 계산에서 발견된 현재 제한 사항에 대한 솔루션으로, 사용 가능한 용량과 무관하게 네트워크에서 LSP당, 디바이스당 수요에 대한 글로벌 관점을 가진 외부 경로 컴퓨팅 엔터티가 필요합니다.

현재, MPLS RSVP-TE 네트워크에서는 온라인 및 실시간 제약 기반 라우팅 경로 계산만 제공됩니다. 각 라우터는 네트워크의 다른 라우터와 독립적으로 제약 기반 라우팅 계산을 수행합니다. 이러한 계산은 현재 사용 가능한 토폴로지 정보, 즉 일반적으로 최근이지만 완전히 정확하지는 않은 정보를 기반으로 합니다. LSP 배치는 현재 네트워크 상태에 따라 로컬에 최적화됩니다. MPLS RSVP-TE 터널은 CLI를 사용하여 설정됩니다. 운영자가 TE LSP를 구성하면 수신 라우터가 이를 시그널링합니다.

기존 트래픽 엔지니어링 기능 외에도 MPLS RSVP-TE 기능은 PCE(Path Computation Element)라고 하는 외부 경로 컴퓨팅 엔터티를 포함하도록 확장되었습니다. PCE는 외부 제어를 위해 구성된 수신 라우터의 TE LSP에 대한 경로를 계산합니다. PCE에 연결하는 수신 라우터를 PCC(Path Computation Client)라고 합니다. PCC는 PCE에 의한 외부 경로 컴퓨팅을 용이하게 하기 위해 PCEP(Path Computation Client Protocol)로 구성됩니다.

자세한 정보는 외부 경로 컴퓨팅의 구성 요소을 참조하십시오.

PCC의 TE LSP에 대한 외부 경로 컴퓨팅을 활성화하려면 및 계층 수준에서 문을 포함합니다.lsp-external-controller pccd[edit mpls][edit mpls lsp lsp-name]

외부 경로 컴퓨팅의 구성 요소

외부 경로 컴퓨팅 시스템을 구성하는 구성 요소는 다음과 같습니다.

경로 계산 요소

PCE(Path Computation Element)는 네트워크 그래프를 기반으로 네트워크 경로 또는 경로를 계산하고 계산 제약 조건을 적용할 수 있는 모든 엔터티(구성 요소, 애플리케이션 또는 네트워크 노드)일 수 있습니다. 그러나 PCE는 외부 제어를 위해 구성된 PCC의 TE LSP에 대한 경로만 계산할 수 있습니다.

PCE는 스테이트풀(stateful) 또는 스테이트리스(stateless)일 수 있습니다.

  • 스테이트풀 PCE - 스테이트풀 PCE는 네트워크에서 사용 중인 계산된 경로 및 예약된 리소스 세트와 함께 PCE와 네트워크 상태(토폴로지 및 리소스 정보 측면에서) 간의 엄격한 동기화를 유지합니다. 즉, 스테이트풀 PCE는 PCC의 새로운 요청을 처리할 때 네트워크의 기존 경로(예: TE LSP)에 대한 정보뿐만 아니라 트래픽 엔지니어링 데이터베이스의 정보를 활용합니다.

    상태 저장 PCE에는 두 가지 유형이 있습니다.

    • 패시브 스테이트풀 PCE - PCC와의 동기화를 유지하고 PCC LSP 상태를 학습하여 경로 계산을 더 최적화하지만 이를 제어할 수는 없습니다.

    • 활성 상태 저장 PCE - PCC LSP 상태에 대해 학습하는 것 외에도 PCC LSP를 능동적으로 수정합니다.

      주:

      주 및 백업 활성 스테이트풀 PCE가 있는 중복 구성에서 백업 액티브 스테이트풀 PCE는 장애 조치 시 메인 PCE가 될 때까지 위임된 LSP의 속성을 수정할 수 없습니다. 전환 시 PCE의 선점은 없습니다. 주 PCE는 백업 PCE에 의해 뒷받침되며, 주 PCE가 다운되면 백업 PCE는 주 PCE의 역할을 맡고 이전에 주 PCE였던 PCE가 다시 작동한 후에도 주 PCE로 남아 있습니다.

    스테이트풀 PCE는 다음과 같은 기능을 제공합니다.

    • 오프라인 LSP 경로 계산을 제공합니다.

    • 네트워크를 다시 최적화해야 할 때 LSP 경로 변경을 트리거합니다.

    • 애플리케이션의 대역폭 수요가 증가하면 LSP 대역폭을 변경합니다.

    • 라우터의 다른 LSP 속성(예: ERO, 설정 우선 순위, 보류 우선 순위)을 수정합니다.

    PCE는 네트워크의 대역폭 수요에 대한 글로벌 뷰를 가지고 있으며 경로 계산을 수행하기 위해 트래픽 엔지니어링 데이터베이스를 유지 관리합니다. SNMP 및 NETCONF를 사용하여 MPLS 도메인의 모든 라우터에서 통계 수집을 수행합니다. 이는 PCC의 TE LSP를 오프라인으로 제어하기 위한 메커니즘을 제공합니다. 오프라인 LSP 경로 계산 시스템이 네트워크 컨트롤러에 내장될 수 있지만, PCE는 컴퓨팅 경로 외에도 PCC의 TE LSP에 대한 제어를 제공하는 본격적인 네트워크 컨트롤러처럼 작동합니다.

    스테이트풀 PCE를 사용하면 최적의 경로 계산과 경로 계산 성공률 증가가 가능하지만, TE LSP의 풀 메시의 경우처럼 잠재적으로 상당한 컨트롤 플레인 오버헤드와 상태 측면에서 많은 양의 데이터를 유지 관리하는 신뢰할 수 있는 상태 동기화 메커니즘이 필요합니다.

  • 상태 비저장 PCE - 상태 비저장 PCE는 계산된 경로를 기억하지 않으며, 각 요청 세트는 서로 독립적으로 처리됩니다(RFC 5440).

경로 계산 클라이언트

PCC(Path Computation Client)는 PCE에서 수행할 경로 계산을 요청하는 모든 클라이언트 애플리케이션입니다.

PCC는 한 번에 최대 10개의 PCE에 연결할 수 있습니다. PCC에서 PCE로의 연결은 구성된 고정 경로 또는 연결성을 설정하는 TCP 연결일 수 있습니다. PCC는 연결된 각 PCE에 우선 순위 번호를 할당합니다. LSP 상태 동기화라는 프로세스에서 현재 LSP에 대한 정보와 함께 연결된 모든 PCE에 메시지를 보냅니다. 외부 제어가 활성화된 TE LSP의 경우, PCC는 이러한 LSP를 주 PCE에 위임합니다. PCC는 우선 순위 번호가 가장 낮은 PCE 또는 우선 순위 번호가 없는 경우 먼저 연결하는 PCE를 주 PCE로 선택합니다.

PCC는 PCE로부터 수신한 계산된 경로를 기반으로 LSP에 다시 신호를 보냅니다. 주 PCE와의 PCEP 세션이 종료되면 PCC는 새로운 주 PCE를 선택하고 이전 주 PCE에 위임된 모든 LSP는 새로 사용 가능한 주 PCE에 위임됩니다.

경로 계산 요소 프로토콜

PCEP(Path Computation Element Protocol)는 PCC와 PCE 간(및 두 PCE 간) 간의 통신에 사용됩니다(RFC 5440). PCEP는 IETF PCE Working Group에서 정의한 TCP 기반 프로토콜로, PCEP 세션을 관리하고 다중 도메인 TE LSP에 대한 경로를 요청 및 전송하는 데 사용되는 일련의 메시지 및 개체를 정의합니다. PCEP 상호 작용에는 PCC 메시지뿐만 아니라 MPLS RSVP-TE의 맥락에서 PCE 사용과 관련된 특정 상태에 대한 알림이 포함됩니다. PCEP가 PCE-PCE 통신에 사용되는 경우 요청 PCE는 PCC의 역할을 맡습니다.

따라서 PCEP 기능에는 다음이 포함됩니다.

  • PCC와 스테이트풀 PCE 간의 LSP 터널 상태 동기화.

  • LSP 터널에 대한 제어권을 스테이트풀 PCE에 위임.

PCEP를 사용한 PCE와 PCC 간의 상호 작용

그림 3 는 MPLS RSVP-TE의 맥락에서 PCE, PCC 및 PCEP의 역할 간의 관계를 보여줍니다.

그림 3: PCC 및 RSVP-TEPCC 및 RSVP-TE

PCE와 PCC의 통신은 TCP 기반 PCEP에 의해 활성화됩니다. PCC는 PCEP 세션을 시작하고 PCEP 세션 기간 동안 PCE에 연결된 상태를 유지합니다.

주:

Junos OS 릴리스 16.1부터 RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호할 수 있습니다. PCEP 세션에 MD5 보안 메커니즘을 사용하려면 PCEP 세션의 계층 수준에서 MD5 인증 키를 정의하고 바인딩하는 것이 좋습니다.[edit protocols pcep pce pce-id] 그러나 계층 수준에서 사전 정의된 키 체인 을 사용하여 PCEP 세션을 보호할 수도 있습니다.[edit security authentication-key-chains key-chain] 이 경우, 사전 정의된 키 체인을 계층 수준에서 PCEP 세션 에 바인딩해야 합니다.[edit protocols pcep pce pce-id]

PCE와 PCC는 동일한 키를 사용하여 PCEP 세션의 TCP 연결에서 전송된 각 세그먼트의 신뢰성을 확인하므로, 공격의 대상이 될 수 있고 네트워크의 서비스를 중단시킬 수 있는 디바이스 간의 PCEP 통신을 보호합니다.

MD5 인증을 사용한 PCEP 세션 보안에 대한 자세한 내용은 을(를) 참조하십시오 .PCEP 세션에 대한 TCP-MD5 인증

PCEP 세션이 설정되면 PCC는 다음 작업을 수행합니다.

  1. LSP 상태 동기화 - PCC는 연결된 모든 PCE에 모든 LSP(로컬 및 외부)에 대한 정보를 전송합니다. 외부 LSP의 경우 PCC는 구성 변경, RRO 변경, 상태 변경 등에 대한 정보를 PCE로 보냅니다.

    PCE 시작 LSP의 경우 PCC에 LSP 구성이 없습니다. LSP를 시작하는 PCE는 PCE 시작 LSP를 지원할 수 있는 능력을 표시한 PCC에 LSP 매개 변수를 보냅니다.

    주:

    PCE 시작 LSP에 대한 지원은 Junos OS 릴리스 13.3 이상에서 제공됩니다.

  2. LSP 위임 - LSP 상태 정보가 동기화된 후 PCC는 외부 LSP를 주요 활성 스테이트풀 PCE인 하나의 PCE에 위임합니다. 메인 PCE만 외부 LSP에 대한 파라미터를 설정할 수 있습니다. 주요 PCE가 수정하는 매개 변수에는 대역폭, 경로(ERO) 및 우선 순위(설정 및 보류)가 포함됩니다. 로컬 구성에 지정된 매개변수는 주 PCE에 의해 설정된 매개변수에 의해 대체됩니다.

    주:

    주 PCE와의 PCEP 세션이 종료되면 PCC는 새로운 주 PCE를 선택하고 이전 주 PCE에 위임된 모든 LSP는 새로 사용 가능한 주 PCE에 위임됩니다.

    PCE 시작 LSP의 경우 PCC는 PCE에서 수신한 매개 변수를 사용하여 LSP를 생성합니다. PCC는 PCE 시작 LSP에 고유한 LSP-ID를 할당하고 LSP를 PCE에 자동으로 위임합니다. PCC는 활성 PCEP 세션에 대해 PCE 시작 LSP에 대한 위임을 취소할 수 없습니다.

    PCEP 세션이 종료되면 PCC는 서비스 중단을 방지하기 위해 PCE 시작 LSP를 즉시 삭제하지 않고 두 개의 타이머를 시작합니다.delegation cleanup timeoutlsp cleanup timer 이 시간 동안 활성 스테이트풀 PCE는 LSP에 대한 생성 요청을 전송하여 실패한 PCE가 프로비저닝한 LSP의 제어를 획득할 수 있습니다.

    PCE 시작 LSP에 대한 제어는 의 만료 시 PCC로 되돌아갑니다.delegation cleanup timeout 이(가 ) 만료되고 다른 PCE가 실패한 PCE로부터 LSP에 대한 제어를 획득하지 못한 경우, PCC는 위임되지 않은 PCE 시작 LSP의 로컬 제어를 취합니다.delegation cleanup timeout 나중에, 원래 또는 새로운 활성 스테이트풀 PCE가 로컬로 제어되는 PCE 시작 LSP의 제어를 획득하고자 할 때, PCC는 이러한 LSP를 PCE에 위임하고 타이머가 중지됩니다.lsp cleanup timer

    PCE는 PCE 간의 LSP 전송을 허용하기 위해 PCE 시작 LSP의 위임을 PCC에 반환할 수 있습니다. 이는 PCE 시작 LSP에 대한 을( 를) 트리거합니다.lsp cleanup timer PCC는 실패한 PCE에서 위임되지 않은 PCE 시작 LSP를 제거하기 전에 LSP 정리 타이머가 만료될 때까지 기다립니다.

    만료 되고 다른 PCE가 실패한 PCE에서 LSP에 대한 제어를 획득하지 못한 경우 PCC는 실패한 PCE에서 프로비저닝된 모든 LSP를 삭제합니다.lsp cleanup timer

    주:

    draft-ietf-pce-stateful-pce-09에 따라 PCC에 의한 PCE 시작 LSP 위임 취소는 LSP가 대체 PCE에 다시 위임되기 전에 단절 전 방식으로 이루어집니다. Junos OS 릴리스 18.1R1부터 PCC가 LSP 위임을 취소하려면 이( 가) 보다 크거나 같아야 합니다.lsp-cleanup-timerdelegation-cleanup-timeout 그렇지 않은 경우, PCC에 대한 재위임 타임아웃 간격은 무한대로 설정될 수 있으며, 여기서 해당 PCE에 대한 LSP 위임은 PCE에 의해 설정된 매개변수를 변경하기 위해 PCC에 의해 특정 조치가 취해질 때까지 그대로 유지된다.

  3. LSP 시그널링 - 주요 활성 스테이트풀 PCE에서 하나 이상의 LSP 매개 변수를 수신하면 PCC는 PCE 제공 경로를 기반으로 TE LSP를 다시 시그널링합니다. PCC가 LSP를 설정하지 못하면 PCE에 설정 실패를 알리고 주 PCE가 해당 LSP에 대한 새 매개 변수를 제공할 때까지 기다린 다음 다시 신호를 보냅니다.

    PCE가 불완전한 경로를 지정하거나 경로 엔드포인트만 지정된 느슨한 홉이 있는 경우 PCC는 전체 홉 집합을 찾기 위해 로컬 제약 기반 라우팅을 수행하지 않습니다. 대신, PCC는 시그널링을 위해 RSVP에 PCE 제공 경로를 그대로 제공하며, 경로는 IGP hop-by-hop 라우팅을 사용하여 설정됩니다.

에서 사용된 토폴로지를 고려하면, 에서는 MPLS RSVP-TE 지원 네트워크에서 부분적인 클라이언트측 PCE 구현을 보여줍니다.그림 2그림 4 수신 라우터 A와 G는 TCP 연결을 통해 외부 스테이트풀 PCE에 연결하도록 구성된 PCC입니다.

PCE는 네트워크의 대역폭 수요에 대한 글로벌 뷰를 가지고 있으며 트래픽 엔지니어링 데이터베이스를 조회한 후 외부 경로 계산을 수행합니다. 그런 다음 활성 스테이트풀 PCE는 하나 이상의 LSP 속성을 수정하고 PCC에 업데이트를 보냅니다. PCC는 PCE로부터 수신한 매개 변수를 사용하여 LSP에 다시 신호를 보냅니다.

그림 4: MPLS RSVP-TE에 대한 PCE 예MPLS RSVP-TE에 대한 PCE 예

이러한 방식으로 상태 저장 PCE는 가장 짧은 도메인 간 제약 경로 계산의 특정 문제를 해결하는 데 사용되는 분산 기능의 협력 작업을 제공합니다. 트래픽 스트림이 사용 가능한 리소스에 비효율적으로 매핑되어 네트워크 리소스의 일부 하위 집합은 과다 활용되고 다른 리소스는 충분히 활용되지 않는 혼잡 시나리오를 제거합니다.

외부 컴퓨팅을 사용한 LSP 동작

LSP 유형

클라이언트 측 PCE 구현에는 세 가지 유형의 TE LSP가 있습니다.

  • CLI 제어 LSP - 명령문이 구성되지 않은 LSP를 CLI 제어 LSP라고 합니다.lsp-external-controller pccd 이러한 LSP는 로컬 제어 하에 있지만 PCC는 초기 LSP 동기화 프로세스 중에 CLI 제어 LSP에 대한 정보로 연결된 PCE를 업데이트합니다. 초기 LSP 동기화 후 PCC는 PCE에 신규 및 삭제된 LSP도 알립니다.

  • PCE 제어 LSP - 명령문이 구성된 LSP를 PCE 제어 LSP 라고 합니다.lsp-external-controller pccd PCC는 외부 경로 계산을 위해 PCC 시작 LSP를 주 PCE에 위임합니다.

    PCC는 대역폭, ERO, 우선순위 등 PCE 제어 LSP의 구성된 매개 변수를 PCE에 알립니다. 또한 가능한 경우 RRO를 포함한 LSP를 설정하기 위해 이러한 매개 변수에 사용된 실제 값에 대해서도 PCE에 알립니다.

    PCC는 재구성이 발생했거나 외부 제어 하에 있는 PCE 제어 LSP의 ERO, RRO 또는 상태가 변경된 경우에만 이러한 LSP 상태 보고서를 PCE에 보냅니다.

    PCE에 대한 LSP의 CLI 구성에서 오는 매개 변수에는 두 가지 유형이 있습니다.

    • PCE에 의해 대체되지 않고 즉시 적용되는 매개변수.

    • PCE에 의해 재정의되는 매개 변수입니다. 이러한 매개 변수에는 대역폭, 경로 및 우선 순위(설정 및 보류 값)가 포함됩니다. 제어 모드가 외부에서 로컬로 전환되면 다음 기회에 이러한 매개 변수에 대한 CLI 구성 값이 적용되어 LSP에 다시 신호를 보냅니다. 값은 즉시 적용되지 않습니다.

  • 외부 프로비저닝된 LSP(또는 PCE 시작 LSP) - 명령문이 구성된 LSP를 PCE 시작 LSP 라고 합니다.lsp-provisioning PCE 시작 LSP는 외부 PCE에 의해 동적으로 생성됩니다. 따라서 PCC에 LSP 구성이 없습니다. PCC는 PCE에서 제공하는 매개 변수를 사용하여 PCE 시작 LSP를 생성하고 LSP를 PCE에 자동으로 위임합니다.

    주:

    PCE 시작 LSP에 대한 지원은 Junos OS 릴리스 13.3 이상에서 제공됩니다.

CLI 제어 LSP, PCE 제어 LSP 및 PCE 시작 LSP는 PCC에서 공존할 수 있습니다.

CLI 제어 LSP와 PCE 제어 LSP는 PCC에서 공존할 수 있습니다.

LSP 제어 모드

클라이언트 측 PCE 구현에는 PCC 제어 LSP에 대한 두 가지 유형의 제어 모드가 있습니다.

  • 외부—기본적으로 모든 PCE 제어 LSP는 외부 통제 하에 있습니다. LSP가 외부 통제 하에 있을 때, PCC는 PCE가 제공한 파라미터를 사용하여 LSP를 설정합니다.

  • 로컬—PCE 제어 LSP는 로컬 제어 하에 있을 수 있습니다. LSP가 외부 제어에서 로컬 제어로 전환되면 CLI 구성 매개 변수와 제약 기반 라우팅을 사용하여 경로 계산이 수행됩니다. 이러한 전환은 LSP에 다시 신호를 보내는 트리거가 있는 경우에만 발생합니다. 그때까지 PCC는 PCE가 제공한 매개변수를 사용하여 PCE 제어 LSP에 신호를 보내지만 LSP는 로컬 제어 하에 있습니다.

PCE 제어 LSP는 PCE에 연결되지 않거나 PCE가 LSP 위임을 PCC에 반환할 때 기본 외부 제어 모드에서 로컬 제어로 전환합니다.

CLI 제어 LSP 및 PCE 제어 LSP에 대한 자세한 내용은 을 참조하십시오 .LSP 유형

외부 컴퓨팅에 대해 지원되는 구성 문

표 1 에는 PCE 제어 LSP에 적용되는 MPLS 및 기존 LSP 구성 문이 나열되어 있습니다.

표 1: PCE 제어 LSP에 대한 MPLS 및 기존 LSP 구성의 적용 가능성

PCE 제어 LSP 지원

적용 가능한 LSP 구성 명령문

적용 가능한 MPLS 구성 문

이러한 구성 명령문은 PCE 구성과 함께 구성할 수 있습니다. 그러나 로컬 구성이 사용 중인 경우에만 적용됩니다. PCE 제어 중에 이러한 구성 문은 비활성 상태로 유지됩니다.

  • 관리자 그룹

  • 자동 대역폭

  • 홉 제한

  • 최소 채우기

  • 가장 많이 채우기

  • 임의의

  • 관리자 그룹

  • 관리자 그룹

  • 관리자 그룹 확장

  • 홉 제한

  • CSPF 없음

  • 스마트 최적화 타이머

이러한 구성 문은 PCE 구성과 함께 구성할 수 있지만 PCE 제어 LSP 속성에 의해 재정의됩니다. 그러나 로컬 구성이 사용 중일 때는 이러한 구성 문에 대해 구성된 값이 적용됩니다.

주:

LSP가 스테이트풀 PCE의 제어 하에 있는 동안 CLI를 사용하여 로컬 구성을 변경해도 LSP에 아무런 영향을 미치지 않습니다. 이러한 변경 사항은 로컬 구성이 적용되는 경우에만 적용됩니다.

  • 대역폭

  • 기본

  • 우선순위

  • 우선순위

이러한 구성 명령문은 PCE 구성과 함께 구성할 수 없습니다.

  • P2MP

  • 템플릿

  • p2mp-lsp-다음 홉

나머지 LSP 구성 문은 기존 LSP와 동일한 방식으로 적용할 수 있습니다. PCE 제어 LSP에 대해 위의 구성 문 중 하나를 구성할 때, 구성된 매개 변수가 적용되는 시점을 나타내는 MPLS 로그 메시지가 생성됩니다.

PCE 제어 LSP 보호

Fast Reroute 및 우회 LSP를 포함한 보호 경로는 제약 기반 라우팅을 사용하여 PCC에 의해 로컬에서 계산됩니다. 스테이트풀 PCE는 기본 경로(ERO)만 지정합니다. PCE는 로컬 구성에 LSP 보호를 위한 비대기 보조 경로가 없더라도 비대기 보조 경로를 트리거할 수도 있습니다.

PCE 제어 LSP ERO

PCE 제어 LSP(PCC 위임 LSP 및 PCE 시작 LSP)의 경우 완전한 명시적 ERO(Explicit Route Object) 개체만 PCE에서 PCC로 보내야 합니다. 그렇지 않으면 PCC는 해당 PCEP 세션에 대한 PCUpdate 또는 PCCreate 메시지를 거부합니다.

Junos OS 릴리스 17.2 부터 PCE 제어 LSP에 대해 두 가지 새로운 경로 계산 유형이 도입되었습니다.external cspf local cspfno cspf.

  • - PCC는 PCE가 주니퍼 벤더 TLV(엔터프라이즈 번호:local cspflocal cspf 유형 5의 0x0a4c).

  • no cspf- PCE와 PCC 모두 제약 경로 계산을 수행하지 않습니다. IGP 경로로 LSP를 설정하기 위해 RSVP 모듈에 엔드 포인트 및 제약 조건이 제공됩니다.

    PCC는 다음과 같은 경우에 계산 유형을 사용합니다 .no cspf

    • PCE가 TLV를 전송할 때, 그리고 이 LSP에 대한 Junos OS 구성 또는 일치하는 템플릿이 PCC 위임 LSP에 포함될 때.local cspfno-cspf

    • PCE가 TLV를 전송할 때, 그리고 이 LSP에 대한 Junos OS 구성 템플릿이 PCE 시작 LSP에 포함될 때.local cspfno-cspf

    • PCE가 빈 ERO 또는 느슨한 ERO(ERO 개체에 느슨한 비트가 설정된 경우)와 함께 TLV를 보내 지 않는 경우.local cspf

이러한 새로운 계산 유형을 통해 PCC는 ERO 개체를 느슨한 ERO 또는 빈 ERO로 받아들일 수 있습니다. 경로를 계산할 수 없는 외부 경로 컴퓨팅 엔터티는 분석을 기반으로 대역폭 및 색상과 같은 매개 변수를 수정할 수 있습니다. 이러한 경우 빈 ERO 개체 또는 느슨한 ERO가 사용되며 선택할 경로는 PCC에서 결정합니다.

PCE 제어 Point-to-Multipoint RSVP-TE LSP

PCE와 PCC 간에 PCEP 세션이 설정된 후 PCC는 LSP 상태 동기화를 위해 시스템의 모든 LSP를 PCE에 보고합니다. 여기에는 PCC 제어, PCE 위임 및 PCE 시작 포인트 투 포인트 LSP가 포함됩니다. Junos OS 릴리스 15.1F6 및 16.1R1부터 이 기능은 point-to-multipoint LSP도 보고하도록 확장됩니다. PCE의 경우, 포인트-투-멀티포인트 LSP는 RSVP 포인트-투-멀티포인트 LSP와 유사하며, 여기서 포인트-투-멀티포인트 LSP는 포인트-투-멀티포인트 식별자 아래 그룹화된 포인트-투-포인트 LSP의 집합으로 취급됩니다.

기본적으로 Point-to-Multipoint LSP의 PCE 제어는 PCC에서 지원되지 않습니다. 이 기능을 추가하려면 또는 계층 수준에서 문을 포함합니다.p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] PCC에서 point-to-multipoint 보고서 기능이 구성되면 PCC는 이 기능을 PCE에 보급합니다. PCE가 동일한 포인트-투-멀티포인트 보고 기능을 광고하는 경우, PCC는 LSP 상태 동기화를 위해 완전한 포인트-투-멀티포인트 LSP 트리를 PCE에 보고합니다.

포인트-투-멀티포인트 TE LSP 기능이 있는 PCC는 스테이트풀 PCE에 대한 포인트-투-멀티포인트 TE LSP의 보고, 포인트-투-멀티포인트 업데이트 및 포인트-투-멀티포인트 LSP 이름을 키로 지원하는 LSP 데이터베이스를 지원합니다. 그러나 다음 기능은 Junos OS 릴리스 15.1F6 및 16.1에서 지원되지 않습니다.

  • 정적 Point-to-Multipoint LSP

  • PCE 위임 및 PCE 시작 Point-to-Multipoint LSP

  • 자동 대역폭

  • TE++

  • PCE 요청 및 응답 메시지

  • 템플릿을 사용한 point-to-multipoint LSP 생성

  • PCE 시작 Point-to-Multipoint LSP에서 포워드 엔트리 구성

  • 프로비저닝된 LSP를 가리키는 라우터에서 포워드 엔트리 구성.

PCE 시작 Point-to-Point LSP

Junos OS 릴리스 16.1부터 PCEP 기능이 확장되어 스테이트풀 PCE가 PCC를 통해 트래픽 엔지니어링 LSP를 시작하고 프로비저닝할 수 있습니다. 앞서 LSP는 PCC에서 구성되었으며 PCC는 외부 LSP에 대한 제어를 PCE에 위임했습니다. LSP 상태의 소유권은 PCC에 의해 유지되었습니다. PCE 시작 LSP의 도입으로 PCE는 PCC에서 로컬로 구성된 LSP 없이 동적으로 트래픽 엔지니어링 지점 간 LSP를 시작하고 프로비저닝할 수 있습니다. PCE로부터 PCCreate 메시지를 수신하면 PCC는 PCE 시작 LSP를 생성하고 LSP를 PCE에 자동으로 위임합니다.

기본적으로 PCC는 PCE에서 PCE 시작 포인트-투-포인트 LSP를 프로비저닝하기 위한 요청을 거부합니다. PCC에서 PCE 시작 LSP를 지원하려면 또는 계층 수준에서 lsp-provisioning 문을 포함합니다.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/lsp-provisioning-edit-protocols-pcep-pce.html[edit protocols pcep pce pce-id][edit protocols pcep pce-group group-id]

PCC는 PCE와 PCEP(Path Computation Element Protocol) 세션을 설정하는 동안 PCE 시작 점대점 LSP를 지원할 수 있는 능력을 나타냅니다. PCE는 LSP를 개시할 수 있는 이 능력을 가진 PCC를 선택합니다. PCE는 PCC에 PCE 시작 LSP 매개 변수를 제공합니다. PCE가 시작한 점대점 LSP 매개 변수를 수신하면 PCC는 LSP를 설정하고 LSP ID를 할당하며 LSP를 PCE에 자동으로 위임합니다.

LSP를 시작하는 PCE가 PCE 시작 점대점 LSP 매개 변수를 제공하지 않으면 PCC는 기본 매개 변수를 사용합니다. 선택적 LSP 템플릿은 PCE에서 LSP 매개 변수를 제공하지 않을 때 PCE 시작 점대점 LSP에 대한 값을 지정하도록 구성할 수도 있습니다. PCC에서 PCE 시작 포인트-투-포인트 LSP에 대한 LSP 템플릿을 구성하려면 계층 수준에서 label-switched-path-template 문을 포함합니다.label-switched-path-template[edit protocols mpls lsp-external-controller lsp-external-controller]

PCEP 세션이 종료되면 PCC는 서비스 중단을 방지하기 위해 PCE 시작 LSP 및 를 즉시 삭제하지 않고 두 개의 타이머를 시작합니다.delegation cleanup timeoutlsp cleanup timer 이 시간 동안 활성 상태 저장 PCE는 실패한 PCE가 프로비저닝한 LSP를 제어할 수 있습니다.

PCE는 PCE 간의 LSP 전송을 허용하기 위해 PCE가 시작된 점대점 LSP의 위임을 PCC에 반환할 수 있습니다. 위임 정리 시간 초과 만료 시 PCE 시작 LSP에 대한 제어가 PCC로 되돌아갑니다. 위임 정리 시간 제한이 만료되고 다른 PCE가 실패한 PCE로부터 LSP에 대한 제어를 획득하지 못한 경우, PCC는 위임되지 않은 PCE 시작 LSP를 로컬로 제어합니다. 나중에, 원래 또는 새로운 활성 스테이트풀 PCE가 로컬로 제어되는 PCE 개시 포인트-투-포인트 LSP의 제어를 획득하고자 할 때, PCC는 이러한 LSP를 PCE에 위임하고 LSP 정리 타이머가 중지됩니다.

PCC는 실패한 PCE에서 위임되지 않은 PCE 시작 포인트-투-포인트 LSP를 삭제하기 전에 LSP 정리 타이머가 만료될 때까지 기다립니다. LSP 정리 타이머가 만료되고 다른 PCE가 실패한 PCE에서 LSP에 대한 제어를 획득하지 못한 경우 PCC는 실패한 PCE에서 프로비저닝한 모든 LSP를 삭제합니다.

Junos OS 릴리스 21.1R1부터 PCE 시작 RSVP 기반 point-to-point 및 point-to-multipoint LSP에 대한 NSR(Nonstop Active Routing)을 지원합니다. 기본 라우팅 엔진만이 컨트롤러와의 PCEP 세션을 유지합니다. PCE에서 시작된 모든 P2MP LSP에 대한 멀티캐스트 플로우 사양을 포함하여 PCE에서 시작된 모든 RSVP LSP를 백업 라우팅 엔진과 동기화합니다. 전환 중에는 PCEP 세션이 다운되고 백업 라우팅 엔진이 기본 라우팅 엔진이 되면 다시 설정됩니다. 이는 라우팅 엔진 전환 중에 PCE 시작 RSVP LSP를 통해 전달되는 트래픽의 트래픽 손실을 줄입니다. 이 기능은 NSR이 구성될 때 활성화됩니다.

PCE 시작 우회 LSP

PCE 시작 우회 LSP 이해

네트워크의 백업 보호 경로에 트래픽을 처리하기에 충분한 대역폭이 없기 때문에 링크 또는 노드 장애 시 트래픽 중단이 발생할 수 있습니다. 이러한 네트워크에서는 PCE를 사용하여 모든 경로를 계산할 수 있지만 네트워크 성능을 최적화하기 위해 로컬 보호 경로도 PCE를 통해 제어해야 합니다.

Junos OS 릴리스 19.2R1 이상 릴리스는 인터넷 초안 draft-cbrt-pce-stateful-local-protection-01(2018년 12월 만료), PCE-Stateful을 통한 RSVP-TE Local-Protection을 위한 PCEP 확장에 대한 부분적인 지원을 제공하며, 여기서 PCEP 기능은 스테이트풀 PCE가 보호된 인터페이스에 대한 우회 LSP를 시작, 프로비저닝 및 관리할 수 있도록 확장됩니다. 대역폭 예약이 있는 다중 우회 LSP는 링크 또는 노드를 보호하기 위해 PCE에 의해 시작될 수 있습니다. 우회 LSP의 대역폭은 보호할 수 있는 기본 LSP의 총 대역폭보다 작을 것으로 예상됩니다.

동적 우회 LSP보다 수동 우회 LSP(사용 가능한 경우)를 선호하는 기존 우회 선택 메커니즘은 동적 우회 LSP보다 PCE 프로비저닝 우회 LSP(사용 가능한 경우)를 선호하도록 확장되었습니다. PCE 프로비저닝 우회 LSP는 동적 우회 LSP보다 선호도가 높지만 수동 우회 LSP보다 덜 선호됩니다.

와 같은 모든 운영 우회 LSP에서 수행하는 데 사용되는 일련의 작업은 PCE 시작 우회 LSP에서도 수행할 수 있습니다.clear rsvp session 및 등의 명령을 사용하여 PCE 시작 우회 LSP 통계를 볼 수 있습니다.show path-computation-client status extensiveshow path-computation-client lsp

PCE 시작 우회 LSP의 지원으로 다음을 수행할 수 있습니다.

  • 외부 컨트롤러에서 PCEP를 통해 RSVP 우회 LSP를 생성하며, 우회 LSP는 다음과 같습니다.

    • 링크 또는 노드 보호를 위한 것일 수 있습니다.

    • 0이 아닌 대역폭이 있어야 합니다.

    • 지정된 엄격한 ERO가 있어야 합니다.

  • 기존 PCE 생성 우회 LSP에 대한 대역폭 및 ERO를 업데이트합니다.

  • 기본 LSP의 승인 제어를 위해 우회 LSP 대역폭을 초과 구독합니다. 이는 바이패스별 매개 변수여야 하며 바이패스 LSP당 구독 업데이트를 허용해야 합니다.

PCE 개시 우회 LSP의 이점

PCE 시작 우회 LSP는 다음과 같은 이점을 제공합니다.

  • 장애 발생 후 트래픽에 대한 제어를 강화하고 보호 경로에 대한 보다 확정적인 경로 계산을 제공합니다.

  • LSP의 다양한 경로와 로컬 보호 경로를 유지하는 등 복잡한 제약 조건과 다양성 요구 사항을 충족합니다.

  • 실패 이벤트 중에 링크가 오버로드되지 않도록 합니다.

PCEP 세션 실패 시 PCE 시작 우회 LSP의 동작

PCEP 세션 실패 시, PCE 시작 우회 LSP는 상태 타임아웃 타이머가 만료될 때까지 분리된 상태가 됩니다. PCE 시작 우회 LSP는 상태 시간 초과 타이머 만료 시 정리됩니다. PCE 시작 우회 LSP(PCEP 세션 실패 후)를 제어하기 위해 PCE(기본 PCE 또는 보조 PCE)는 상태 시간 초과 타이머가 만료되기 전에 PCInitiate 메시지를 보냅니다.

PCE 시작 Point-to-Multipoint LSP

Point-to-Multipoint PCE 시작 LSP의 도입으로 PCE는 PCC에서 로컬 LSP를 구성할 필요 없이 동적으로 point-to-multipoint LSP를 시작하고 프로비저닝할 수 있습니다. 이를 통해 PCE는 PCEP(Path Computation Element Protocol) 세션 내에서 그리고 여러 세션 간에 점대다점 경로 계산의 타이밍과 시퀀스를 제어할 수 있으므로 중앙에서 제어되고 배포되는 동적 네트워크를 생성할 수 있습니다.

자세한 내용은 PCE 시작 Point-to-Multipoint LSP를 지원하는 MPLS RSVP-TE에 대한 경로 계산 요소 프로토콜 이해(Understanding Path Computation Element Protocol for MPLS)를 참조하십시오.MPLS에 대한 경로 계산 요소 프로토콜 이해 PCE 시작 Point-to-Multipoint LSP에 대한 지원을 통한 RSVP-TE

PCEP의 SRv6 LSP

세그먼트 라우팅은 MPLS 및 IPv6 포워딩 플레인 모두에 적용할 수 있습니다. PCE(Path Computation Element)는 MPLS 및 IPv6 포워딩 플레인 모두에 대한 SR 경로를 계산합니다. PCEP를 위한 세그먼트 라우팅은 IPv6 포워딩 플레인에서 PCE 시작, 로컬 생성 및 위임 SR LSP와 같은 SR LSP를 지원합니다.

PCEP에서 SRv6 LSP의 이점

  • PCE 시작 SRv6 LSP를 생성할 수 있습니다.
  • 라우터에서 생성된 SRv6 LSP를 컨트롤러에 위임합니다.
  • 라우터에서 로컬로 생성된 LSP를 컨트롤러에 보고합니다.
  • SRv6 네트워크 프로그래밍은 MPLS를 구축하지 않고도 세그먼트 라우팅을 활용할 수 있는 유연성을 제공합니다.

PCEP는 PCE 시작 컬러 및 비컬러 SRv6 LSP의 생성, 업데이트 및 삭제를 지원합니다. PCE 시작 SRv6 LSP가 동일한 IP 또는 색상 기반 IP에 대해 정적 SRv6 LSP와 함께 공존하는 경우, 정적 SRv6 TE LSP 기여 경로가 PCE 시작 SRv6 TE LSP 기여 경로보다 선호됩니다.

SRv6를 지원하도록 PCEP 세션을 구성하려면 [edit protocols pcep pce pce-id] 또는 [] 계층 수준에서 구성 문을 활성화 해야 합니다.srv6-capabilityedit protocols pcep pce-group pce-id 구성 문이 활성화된 경우, [] 계층 수준에서 srv6 구성 문도 활성화해야 하며, 그렇지 않으면 커밋 중에 오류가 표시됩니다.srv6-capabilityedit protocols source-packet-routing

SR-TE용 SRv6을 구성하려면 [edit protocols source-packet-routing] 계층 수준에서 srv6 구성 문을 추가해야 합니다.

[자세한 내용은 SRv6 터널에 대한 SR-TE 정책 이해를 참조하십시오.https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp-egress-traffic-engineering.html#id_unb_hnk_1rb

SRv6 LSP의 최대 세그먼트 목록 깊이를 구성하려면 [] 계층 수준에서 구성 문을 활성화 해야 합니다.maximum-srv6-segment-list-depthedit protocols pcep

자동 대역폭 및 PCE 제어 LSP

Junos OS 릴리스 14.2R4부터 PCE 제어 LSP에 대한 자동 대역폭 지원이 제공됩니다. 이전 릴리스에서는 자동 대역폭 옵션이 PCE 제어 LSP에 적용되지 않았지만, 자동 대역 및 제약 기반 라우팅의 제어 하에 있는 LSP는 PCE 제어 LSP와 공존할 수 있었습니다. 자동 대역폭에 대한 통계 수집은 PCE 제어 LSP의 제어 모드가 외부에서 로컬로 변경될 때만 적용되었습니다. 이는 PCE에 연결되지 않거나 PCE가 LSP 위임을 PCC에 반환할 때 발생했습니다.

PCEP 세션에 대한 TCP-MD5 인증

스테이트풀 PCE 서버는 네트워크 전반의 트래픽 엔지니어링 경로 생성을 자동화하여 네트워크 활용도를 높이고 PCC와의 PCEP 통신을 사용하여 맞춤형 프로그래밍 가능한 네트워킹 경험을 가능하게 합니다. PCC는 LSP 보고서를 PCE 서버로 전송하고, PCE는 LSP를 다시 PCC에 업데이트하거나 프로비저닝합니다. PCEP 세션을 통해 전송되는 데이터는 PCE 서버가 외부 경로 컴퓨팅을 수행하는 데 매우 중요합니다. 따라서 PCEP 통신에 대한 공격으로 네트워크 서비스가 중단될 수 있습니다. 변경된 PCEP 메시지가 PCC에 전송되면 부적절한 LSP가 설정될 수 있습니다. 마찬가지로, 변경된 PCEP 메시지가 PCE에 전송되면 PCE가 네트워크의 잘못된 보기를 학습합니다.

Junos OS 릴리스 16.1은 PCE 기능을 효과적으로 실행하는 데 있어 PCE와 PCC 간의 PCEP 통신의 중요성을 고려하여 RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호하는 기능을 소개합니다. 이 기능은 PCEP 세션을 통해 PCE와 PCC 간의 통신을 보호하며, 이는 공격의 대상이 될 수 있으며 네트워크 서비스를 중단시킬 수 있습니다.

PCEP 세션에 MD5 보안 메커니즘을 사용하려면 PCEP 세션의 계층 수준에서 MD5 인증 키를 정의하고 바인딩하는 것이 좋습니다.[edit protocols pcep pce pce-id] 그러나 계층 수준에서 사전 정의된 키 체인 을 사용하여 PCEP 세션을 보호할 수도 있습니다.[edit security authentication-key-chains key-chain] 이 경우, 사전 정의된 키 체인을 계층 수준에서 PCEP 세션 에 바인딩해야 합니다.[edit protocols pcep pce pce-id]

PCE와의 보안 PCEP 세션을 설정하기 위해 PCC에서 다음 구성이 실행됩니다.

  • MD5 인증 키 사용:

  • 사전 정의된 인증 키체인 사용:

보안 PCEP 세션이 성공적으로 설정되려면 PCE 서버와 PCC 모두에서 사전 공유 인증 키를 사용하여 MD5 인증을 구성해야 합니다. PCE 및 PCC는 동일한 키를 사용하여 PCEP 세션의 TCP 연결에서 전송된 각 세그먼트의 신뢰성을 확인합니다.

주:
  • Junos OS 릴리스 16.1은 도청, 탬퍼링 및 메시지 위조에 대한 보호와 같은 TLS 및 TCP-AO에 대한 지원을 확장하지 않고 PCEP 세션에 대한 TCP-MD5 인증만 지원합니다.

  • PCEP 세션에 보안 메커니즘을 처음 적용하면 세션이 재설정됩니다.

  • MD5가 PCEP 세션의 한 쪽에서 잘못 구성되거나 구성되지 않은 경우 세션이 설정되지 않습니다. PCC와 PCE의 구성이 일치하는지 확인합니다.

  • 이 기능은 세션 인증 메커니즘을 지원하지 않습니다.

  • PCEP 세션에서 사용하는 인증 키 체인을 보려면 및 명령 출력을 사용합니다.show path-computation-client statusshow protocols pcep

  • 명령을 사용하여 인증 오류로 인해 TCP에 의해 손실된 패킷 수를 볼 수 있습니다.show system statistics tcp | match auth

  • 키 체인의 작동은 명령 출력을 사용하여 확인할 수 있습니다 .show security keychain detail

클라이언트 측 PCE 구현이 네트워크 성능에 미치는 영향

상태 저장 데이터베이스의 유지 관리는 간단하지 않을 수 있습니다. 단일 중앙 집중식 PCE 환경에서 상태 저장 PCE는 PCE가 계산한 모든 TE LSP, 실제로 설정된 TE LSP(알 수 있는 경우) 및 TE LSP가 삭제된 시간을 기억하기만 하면 됩니다. 그러나 이러한 요구 사항은 상태, 네트워크 사용 및 처리, 네트워크 전반에 걸친 링크 최적화 측면에서 상당한 제어 프로토콜 오버헤드를 유발합니다. 따라서 상태 저장 PCE 구현의 우려 사항은 다음과 같습니다.

  • 신뢰할 수 있는 동기화 메커니즘은 상당한 컨트롤 플레인 오버헤드를 초래합니다. PCE는 서로 통신하여 상태를 동기화할 수 있지만, 여러 PCE 간에 수행되는 분산 계산을 사용하여 TE LSP를 설정하면 동기화 및 경쟁 조건 회피 문제가 더 크고 복잡해집니다.

  • 대역 외 트래픽 엔지니어링 데이터베이스 동기화는 분산 PCE 계산 모델에 설정된 여러 PCE로 인해 복잡할 수 있으며 경쟁 조건, 확장성 문제 등이 발생하기 쉽습니다.

  • PCE가 모든 경로, 우선 순위 및 계층에 대한 세부 정보를 가지고 있더라도 전체 네트워크 상태를 통합하는 경로 계산은 매우 복잡합니다.

위와 같은 우려에도 불구하고, 상태 저장 PCE의 부분적인 클라이언트 측 구현은 대규모 트래픽 엔지니어링 시스템에서 매우 효과적입니다. 이는 TE LSP 상태의 글로벌 가시성에 대한 요구 사항을 제공하고 제어 중인 시스템 내 디바이스 간 경로 예약의 질서 있는 제어에 대한 요구 사항을 제공함으로써 최적의 리소스 사용 측면에서 빠른 컨버전스와 상당한 이점을 제공합니다.

예: MPLS RSVP-TE를 위한 경로 계산 요소 프로토콜 구성

이 예에서는 PCC(Path Computation Client)에서 트래픽 엔지니어링 레이블 스위칭 경로(TE LSP)에 대해 PCE(Path Computation Element)를 통해 외부 경로 컴퓨팅을 활성화하는 방법을 보여줍니다. 또한 PCE에서 PCC로의 통신을 활성화하기 위해 PCC에서 PCEP(Path Computation Element Protocol)를 구성하는 방법도 보여줍니다.

요구 사항

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

  • ACX 시리즈 라우터, M 시리즈 멀티서비스 에지 라우터, MX 시리즈 5G 유니버설 라우팅 플랫폼, T 시리즈 코어 라우터 또는 PTX 시리즈 전송 라우터의 조합이 될 수 있는 라우터 3개(그 중 하나는 PCC로 구성됨).

  • PCC에서 외부 상태 저장 PCE에 대한 TCP 연결입니다.

  • JSDN 애드온 패키지와 함께 PCC에서 실행되는 Junos OS 릴리스 12.3 이상.

주:

JSDN 추가 기능 패키지는 핵심 Junos OS 설치 패키지와 함께 설치해야 합니다.

시작하기 전에:

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

  2. MPLS 및 RSVP-TE를 구성합니다.

  3. IS-IS 또는 기타 IGP 프로토콜을 구성합니다.

개요

Junos OS 릴리스 12.3부터 MPLS RSVP-TE 기능이 확장되어 PCC에서 상태 저장 PCE 아키텍처(draft-ietf-pce-stateful-pce)의 부분적인 클라이언트 측 구현을 제공합니다.

주:

상태 저장 PCE 아키텍처의 부분적인 클라이언트 측 구현은 인터넷 초안 draft-ietf-pce-stateful-pce의 버전 2를 기반으로 합니다. Junos OS 릴리스 16.1부터 이 구현은 인터넷 초안 draft-ietf-pce-stateful-pce-pce-07에 정의된 대로 버전 7을 지원하도록 업그레이드됩니다. 16.1 이전 릴리스는 이전 버전의 PCE 초안을 지원하므로 이전 릴리스를 실행하는 PCC와 인터넷 초안 draft-ietf-pce-stateful-pce-07을 준수하는 상태 저장 PCE 서버 간에 상호 운용성 문제가 발생합니다.

PCE에 의한 외부 경로 컴퓨팅을 활성화하려면 및 계층 수준에서 PCC 에 명령문을 포함합니다.lsp-external-controller[edit mpls][edit mpls lsp lsp-name]

명령문으로 구성된 LSP는 PCE 제어 LSP라고 하며 기본적으로 PCE의 외부 제어 하에 있습니다.lsp-external-controller 활성 스테이트풀 PCE는 PCC의 이러한 PCE 제어 LSP에 대해 대역폭, 경로(ERO) 및 우선 순위와 같은 CLI에서 설정된 매개 변수를 재정의할 수 있습니다.

PCE에서 PCC로의 통신을 활성화하려면 계층 수준에서 PCC에 PCEP를 구성합니다.[edit protocols]

PCC에서 PCEP를 구성할 때 다음 고려 사항에 유의하십시오.

  • JSDN 추가 기능 패키지는 핵심 Junos OS 설치 패키지와 함께 설치해야 합니다.

  • Junos OS 릴리스 12.3은 스테이트풀 PCE만 지원합니다.

  • PCC는 최대 10개의 상태 저장 PCE에 연결할 수 있습니다. 임의의 주어진 시점에서, PCC가 경로 계산을 위해 LSP를 위임하는 하나의 주 PCE(가장 낮은 우선순위 값을 갖는 PCE 또는 PCE 우선순위가 없는 경우 PCC에 먼저 연결되는 PCE)만이 있을 수 있다.

  • Junos OS 릴리스 12.3의 경우 PCC는 항상 PCEP 세션을 시작합니다. 원격 PCE에 의해 시작된 PCEP 세션은 PCC에 의해 수락되지 않습니다.

  • LSP 보호 및 MBB(make-before-break)와 같은 기존 LSP 기능은 PCE 제어 LSP에서 작동합니다.

  • 자동 대역폭 옵션은 PCE 제어 LSP에 대해 꺼져 있지만, 자동 대역 및 제약 기반 라우팅의 제어 하에 있는 LSP는 PCE 제어 LSP와 공존할 수 있습니다.

  • PCE 제어 LSP는 경로에 대한 lsp-nexthop, 포워딩 인접성, CCC 연결 및 논리 터널과 같은 다른 CLI 구성에서 참조할 수 있습니다.

  • PCE 제어 LSP는 GRES를 지원하지 않습니다.

  • 논리 시스템 하의 PCE 제어 LSP는 지원되지 않습니다.

  • PCE 제어 LSP는 point-to-multipoint LSP가 될 수 없습니다.

  • 양방향 LSP는 지원되지 않습니다.

  • PCE 제어 LSP는 기본 경로 없이 보조 경로를 가질 수 없습니다.

  • PCE 제어 LSP는 외부 경로 계산에 의존하며, 이는 전체 설정 시간, 재라우팅 및 단절 전 접속 기능에 영향을 미칩니다.

  • 기존 LSP의 설정 시간 및 컨버전스 시간(재라우팅, MBB)은 PCE 제어 LSP가 없는 경우 이전 릴리스와 동일합니다. 그러나 PCE 제어 LSP가 있을 때 작은 영향을 볼 수 있습니다.

  • ERO 계산 시간은 로컬 CSPF보다 훨씬 더 길 것으로 예상됩니다.

토폴로지

그림 5: MPLS RSVP-TE를 위한 PCEP 구성MPLS RSVP-TE를 위한 PCEP 구성

이 예에서 PCC는 외부 활성 스테이트풀 PCE에 연결하는 수신 라우터입니다.

라우터 PCC의 외부 LSP는 다음과 같이 계산됩니다.

  1. 라우터 PCC는 CLI를 사용하여 설정된 LSP 터널 구성을 수신합니다. 수신된 구성이 외부 경로 컴퓨팅으로 활성화되었다고 가정하면 라우터 PCC는 일부 LSP 속성(대역폭, 경로 및 우선 순위)이 스테이트풀 PCE의 제어 하에 있음을 인식하고 LSP를 PCE에 위임합니다.

    이 예에서는 외부 LSP가 호출 되고 라우터 PCC에서 라우터 R2로 설정되고 있습니다.PCC-to-R2 에 대한 CLI 구성 ERO는 PCC-R0-R1-R2입니다.PCC-to-R2 에 대한 대역폭은 10m이고 설정 및 보류 우선 순위 값은 모두 4입니다.PCC-to-R2

  2. 라우터 PCC는 PCE 제어 LSP 속성을 검색하려고 시도합니다. 이를 위해 라우터 PCC는 LSP가 구성되었음을 알리는 PCRpt 메시지를 스테이트풀 PCE에 보냅니다. PCRpt 메시지는 LSP의 상태를 전달하고 LSP의 로컬 구성 매개 변수를 포함합니다.

  3. 스테이트풀 PCE는 하나 이상의 위임된 LSP 속성을 수정하고 PCUpd 메시지를 통해 라우터 PCC에 새 LSP 매개 변수를 보냅니다.

  4. 새 LSP 매개 변수를 수신하면 라우터 PCC는 새 LSP를 설정하고 PCE 제공 경로를 사용하여 다시 신호를 보냅니다.

    이 예에서 에 대한 PCE 제공 ERO는 PCC-R3-R2입니다.PCC-to-R2 에 대한 대역폭은 8m이며, 설정 및 유지 우선 순위 값은 모두 3입니다.PCC-to-R2

  5. 라우터 PCC는 새 RRO가 포함된 PCRpt를 스테이트풀 PCE로 전송합니다.

구성

CLI 빠른 구성

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

Pcc

R0

R1

R2

R3

절차

단계별 절차

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

라우터 PCC 구성:

주:

각 라우터에 대한 적절한 인터페이스 이름, 주소 및 기타 매개 변수를 수정한 후 MPLS 도메인의 모든 주니퍼 네트웍스 수신 라우터에 대해 이 절차를 반복합니다.

  1. 인터페이스를 구성합니다.

    MPLS를 활성화하려면 인터페이스가 들어오는 MPLS 트래픽을 삭제하지 않도록 인터페이스에 프로토콜 패밀리를 포함합니다.

  2. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에서 RSVP를 활성화합니다.

  3. 라우터 PCC에서 라우터 R2로 LSP(Label-Switched Path)를 구성하고 PCE에 의한 LSP의 외부 제어를 활성화합니다.

  4. 라우터 PCC에서 라우터 R2로 LSP를 구성합니다. 라우터 R2는 로컬 제어가 가능하며 PCE 제공 LSP 매개 변수에 의해 재정의됩니다.

  5. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에서 MPLS를 활성화합니다.

  6. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에 IS-IS를 구성합니다.

  7. 라우터 PCC가 연결하는 PCE를 정의하고 PCE의 IP 주소를 구성합니다.

  8. TCP 기반 PCEP를 사용하여 PCE에 연결하는 라우터 PCC의 대상 포트를 구성합니다.

  9. PCE 유형을 구성합니다.

결과

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

디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.

검증

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

PCEP 세션 상태 확인

목적

PCE 상태가 up일 때 PCE와 라우터 PCC 간의 PCEP 세션 상태를 확인합니다.

작업

운영 모드에서 show path-computation-client active-pce 명령을 실행합니다.

의미

출력은 라우터 PCC가 연결된 현재 활성 스테이트풀 PCE에 대한 정보를 표시합니다. 출력 필드는 PCE와 라우터 PCC 간 PCEP 세션의 현재 상태를 나타냅니다.PCE status

의 경우 , PCEP 세션의 상태는 이며, 이는 PCEP 피어 간에 PCEP 세션 이 설정되었음을 나타냅니다.pce1PCE_STATE_UP

의 통계는 라우터 PCC가 LSP의 현재 상태를 보고하기 위해 PCE로 보낸 메시지 수를 나타냅니다.PCRpts 통계는 라우터 PCC가 PCE에서 수신한 메시지 수를 나타냅니다.PCUpdates 메시지에는 PCE 제어 LSP에 대한 PCE 수정 매개변수가 포함됩니다.PCUpdates

LSP 제어가 외부인 경우 PCE 제어 LSP 상태 확인

목적

LSP가 외부 제어 하에 있을 때 라우터 PCC에서 라우터 R2로 PCE 제어 LSP의 상태를 확인합니다.

작업

운영 모드에서 show mpls lsp name PCC-to-R2 extensive 명령을 실행합니다.

의미

출력에서 및 출력 필드는 LSP가 외부에서 제어된다는 것을 보여줍니다.LSPtypeLSP Control Status 출력에는 라우터 PCC와 PCE 간에 전송된 PCEP 메시지의 로그도 표시됩니다.

PCE와 라우터 PCC 간의 PCEP 세션이 가동되고 라우터 PCC는 다음과 같은 PCE 제어 LSP 매개 변수를 수신합니다.

  • ERO(경로) - 20.31.4.2 및 20.31.5.2

  • 대역폭 - 8Mbps

  • 우선 순위 - 3, 3(설정 및 보류 값)

LSP 제어가 로컬인 경우 PCE 제어 LSP 상태 확인

목적

LSP 제어가 로컬이 되면 라우터 PCC에서 라우터 R2로 PCE 제어 LSP의 상태를 확인합니다.

작업

운영 모드에서 show mpls lsp name PCC-to-R2 extensive 명령을 실행합니다.

의미

출력 에서 출력 필드는 LSP가 로컬 제어 하에 있음을 보여줍니다.LSP Control Status PCE 제어 LSP는 로컬 제어 하에 있지만 라우터 PCC는 LSP에 다시 신호를 보낼 수 있는 다음 기회까지 PCE에서 제공한 매개 변수를 계속 사용합니다.

이제 출력에는 사용 중인 LSP를 실제 값으로 설정하는 데 사용되는 PCE 제공 매개 변수와 함께 CLI를 사용하여 구성된 LSP 매개 변수가 표시됩니다.

  • 대역폭 - 10Mbps(실제 대역폭: 8Mbps)

  • 우선 순위—4 4(실제 우선 순위 3 3)

LSP를 다시 시그널링하는 트리거에서 라우터 PCC는 로컬 구성 매개 변수를 사용하여 PCE 제어 LSP를 설정합니다.

는 20.31.1.2, 20.31.2.2 및 20.31.8.2입니다.Computed ERO PCE 제어 LSP는 로컬 구성 매개 변수를 사용하여 설정됩니다.

예: PCE 시작 Point-to-Point LSP를 지원하는 MPLS RSVP-TE에 대한 경로 계산 요소 프로토콜 구성

이 예에서는 PCE(Path Computation Element) 시작 트래픽 엔지니어링 LSP(Point-to-Point Label-Switched Path)를 지원하는 기능으로 PCC(Path Computation Client)를 구성하는 방법을 보여줍니다.

요구 사항

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

  • ACX 시리즈, M 시리즈, MX 시리즈 또는 T 시리즈 라우터의 조합이 될 수 있는 라우터 3개.

  • 수신 라우터(PCC)에서 두 개의 외부 상태 저장 PCE에 대한 TCP 연결.

  • PCC에서 실행되는 Junos OS 릴리스 16.1 이상.

시작하기 전에:

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

  • MPLS 및 RSVP-TE(RSVP-Traffic Engineering)를 구성합니다.

  • OSPF 또는 기타 IGP 프로토콜을 구성합니다.

개요

Junos OS 릴리스 16.1부터 PCEP 기능이 확장되어 스테이트풀 PCE가 PCC를 통해 트래픽 엔지니어링 LSP를 시작하고 프로비저닝할 수 있습니다. 앞서 LSP는 PCC에서 구성되었으며 PCC는 외부 LSP에 대한 제어를 PCE에 위임했습니다. LSP 상태의 소유권은 PCC에 의해 유지되었습니다. PCE 시작 LSP의 도입으로 PCE는 PCC에서 로컬로 구성된 LSP 없이 동적으로 트래픽 엔지니어링 지점 간 LSP를 시작하고 프로비저닝할 수 있습니다. PCE로부터 PCCreate 메시지를 수신하면 PCC는 PCE 시작 LSP를 생성하고 LSP를 PCE에 자동으로 위임합니다.

PCC에 대한 PCE 시작 포인트-투-포인트 LSP의 지원을 구성할 때 다음 고려 사항에 유의하십시오.

  • Junos OS 릴리스 13.3은 스테이트풀 PCE만 지원합니다.

  • Junos OS 릴리스 13.3의 경우 PCC는 항상 PCEP 세션을 시작합니다. 원격 PCE에 의해 시작된 PCEP 세션은 PCC에 의해 수락되지 않습니다.

  • LSP 보호 및 MBB(make-before-break)와 같은 기존 LSP 기능은 PCE 시작 LSP에서 작동합니다.

  • PCE 시작 LSP는 GRES(Graceful Routing Engine Switchover)를 지원하지 않습니다.

  • 논리적 시스템에서 PCE 시작 LSP는 지원되지 않습니다.

  • PCE 시작 LSP는 point-to-multipoint LSP가 될 수 없습니다.

  • 양방향 LSP는 지원되지 않습니다.

  • 번호가 지정되지 않은 링크에 대한 RSVP-TE는 지원되지 않습니다. PCE 시작 LSP는 번호가 매겨진 링크만 지원합니다.

  • 세그먼트 라우팅 LSP를 시작하는 PCE는 색상이 없는 세그먼트 라우팅 LSP와 연결된 바인딩 세그먼트 ID(SID) 레이블을 사용하여 PCE 시작 세그먼트 라우팅 LSP 경로를 프로비저닝할 수 있습니다.

    Junos OS 릴리스 18.2R1부터 수신 디바이스에서 정적으로 구성된 무색 세그먼트 라우팅 LSP는 PCEP 세션을 통해 PCE에 보고됩니다. 이러한 색상이 없는 세그먼트 라우팅 LSP에는 연결된 바인딩 SID 레이블이 있을 수 있습니다. 이 기능을 통해 PCE는 레이블 스택에서 이 바인딩 SID 레이블을 사용하여 PCE 시작 세그먼트 라우팅 LSP 경로를 프로비저닝할 수 있습니다.

토폴로지

그림 6: MPLS RSVP-TE를 위한 PCE 시작 Point-to-Point LSP 예MPLS RSVP-TE를 위한 PCE 시작 Point-to-Point LSP 예

이 예에서 PCC는 두 개의 외부 스테이트풀 PCE에 연결하는 수신 라우터입니다. PCE1 및 PCE2.

새로운 요구가 있을 때, 활성 스테이트풀 PCE는 요구 사항을 충족하기 위해 LSP를 동적으로 개시합니다. PCC는 PCE 시작 LSP를 지원하는 기능으로 구성되므로 PCC의 경로 계산은 다음과 같이 수행됩니다.

  1. PCE는 PCC에 PCCreate 메시지를 전송하여 LSP를 시작하고 프로비저닝합니다. PCC는 PCE에서 수신한 매개 변수를 사용하여 PCE 시작 LSP를 설정하고 PCE 시작 LSP를 시작한 PCE에 자동으로 위임합니다.

    이 예에서 PCE1은 PCC에서 PCE 시작 LSP를 시작하고 프로비저닝하는 활성 상태 저장 PCE입니다. PCE 시작 LSP 매개 변수를 수신하면 PCC는 LSP를 설정하고 PCE 시작 LSP를 PCE1에 자동으로 위임합니다.

  2. PCC와 PCE1 간의 PCEP 세션이 종료되면 PCC는 PCE1 시작 LSP에 대해 두 개의 타이머를 시작합니다. 삭제 정리 시간 초과 및 LSP 정리 타이머. 이 시간 동안 PCE1 또는 PCE2는 PCE 시작 LSP의 제어를 획득할 수 있습니다.

  3. PCE2가 LSP 정리 타이머가 만료되기 전에 PCE 시작 LSP에 대한 제어를 획득하면 PCC는 PCE 시작 LSP를 PCE2에 위임하고 LSP 정리 타이머 및 위임 정리 시간 초과가 중지됩니다.

  4. 위임 정리 시간 초과가 만료되고 PCE1과 PCE2 모두 PCE 시작 LSP에 대한 제어권을 획득하지 못한 경우 PCC는 LSP 정리 타이머가 만료될 때까지 위임되지 않은 PCE 시작 LSP를 로컬로 제어합니다.

  5. LSP 정리 타이머가 만료된 후 PCC는 PCE1에서 프로비저닝한 PCE 시작 LSP를 삭제합니다.

구성

CLI 빠른 구성

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

Pcc

R1

R2

절차

단계별 절차

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

PCC 라우터 구성:

주:

각 라우터에 대한 적절한 인터페이스 이름, 주소 및 기타 매개 변수를 수정한 후 MPLS 도메인의 모든 주니퍼 네트웍스 수신 라우터에 대해 이 절차를 반복합니다.

  1. 인터페이스를 구성합니다.

    MPLS를 활성화하려면 인터페이스가 들어오는 MPLS 트래픽을 삭제하지 않도록 인터페이스에 프로토콜 패밀리를 포함합니다.

  2. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 RSVP를 활성화합니다.

  3. PCE에 의한 LSP의 외부 제어를 활성화합니다.

  4. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 MPLS를 활성화합니다.

  5. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 OSPF를 구성합니다.

  6. PCE 그룹을 정의하고 PCE 그룹에 대한 PCE 시작 LSP의 지원을 활성화합니다.

  7. PCC에 연결하는 PCE를 정의합니다.

결과

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

디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.

검증

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

PCC 상태 확인

목적

PCC와 연결된 PCE 간의 PCEP 세션 상태 및 LSP 요약을 확인합니다.

작업

운영 모드에서 show path-computation-client status 명령을 실행합니다.

의미

출력은 활성 스테이트풀 PCE와 PCC 간의 PCEP 세션 상태를 표시합니다. 또한 PCC에 있는 다양한 유형의 LSP에 대한 정보와 연결된 PCE가 프로비저닝하고 위임한 LSP 수에 대한 정보도 표시합니다.

PCE1은 주요 활성 PCE이며 PCC에 의해 자동으로 위임된 하나의 PCE 시작 LSP가 있습니다.

PCE1 상태 확인

목적

기본 활성 상태 저장 PCE의 상태를 확인합니다.

작업

운영 모드에서 show path-computation-client active-pce detail 명령을 실행합니다.

의미

출력은 PCC가 연결된 현재 활성 스테이트풀 PCE에 대한 정보를 표시합니다. 출력 필드는 PCE와 PCC 간 PCEP 세션의 현재 상태를 나타냅니다.PCE status

PCE1의 경우, PCEP 세션의 상태는 이며, 이는 PCEP 세션 이 PCC와 설정되었음을 나타냅니다.PCE_STATE_UP

LSP가 외부적으로 프로비저닝된 경우 PCE 시작 LSP 상태 확인

목적

PCE 시작 LSP의 상태를 확인합니다.

작업

운영 모드에서 show mpls lsp externally-provisioned detail 명령을 실행합니다.

의미

출력 에서 출력 필드는 LSP가 외부적으로 프로비저닝되었음을 보여줍니다.LSPtype

PCC와 PCE1 간의 PCEP 세션이 작동 중이며 PCC는 다음과 같은 PCE 시작 LSP 매개 변수를 수신합니다.

  • ERO(경로) - 10.0.102.10 및 10.0.101.9

  • 대역폭—8Mbps

  • 우선 순위 - 7 0(설정 및 보류 값)

PCE 시작 Point-to-Point LSP를 지원하는 MPLS RSVP-TE에 대한 경로 계산 요소 프로토콜 구성

중앙 집중식 외부 경로 컴퓨팅 엔터티에서 동적으로 생성된 LSP(Label Switched Path)를 지원하는 기능을 갖춘 PCC(Path Computation Client)를 구성할 수 있습니다. 상태 저장 PCE(Path Computaiton Element)를 사용하여 외부 경로 계산을 수행하고 수요가 증가할 때 동적 LSP를 생성할 수 있습니다.

PCC는 PCE가 LSP를 프로비저닝하지 않을 때 PCE가 제공한 LSP 매개 변수 또는 사전 구성된 LSP 템플릿의 매개 변수를 사용하여 PCE 시작 지점 간 LSP를 생성하고 PCE 시작 지점 간 LSP를 해당 PCE에 자동으로 위임합니다. 따라서 PCE 시작 LSP의 경우 PCC에서 로컬로 구성된 LSP가 필요하지 않습니다.

CLI 제어 LSP, PCE 제어 LSP 및 PCE 시작 LSP는 PCC에서 서로 공존할 수 있습니다.

시작하기 전에:

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

  • MPLS 및 RSVP-TE를 구성합니다.

  • OSPF 또는 기타 IGP 프로토콜을 구성합니다.

PCE 시작 포인트-투-포인트 LSP를 지원하도록 PCC를 구성하려면 다음 작업을 완료하십시오.

  1. 구성 모드에서 다음 계층 수준으로 이동하십시오.
  2. PCC가 최대로 수신할 수 있는 분당 메시지 수를 지정합니다.
  3. 연결된 모든 PCE에 대해 PCC가 최대로 허용할 수 있는 외부 프로비저닝된 레이블 전환 경로(LSP)의 수를 지정합니다.
  4. 연결된 PCE에 대한 고유한 사용자 정의 ID를 지정하여 PCE 매개변수를 구성합니다.
  5. PCEP 세션의 연결이 끊어진 후 LSP 제어를 라우팅 프로토콜 프로세스로 반환하기 전에 PCC가 대기해야 하는 시간(초)을 지정합니다.
  6. 연결할 PCE의 IPv4 주소를 지정합니다.
  7. PCE가 사용 중인 TCP 포트 번호를 지정하십시오

    값의 범위는 1에서 65535까지이며 기본값은 4189입니다.

  8. PCEP 세션이 종료된 후 실패한 PCE에서 위임되지 않은 PCE 시작 LSP를 삭제하기 전에 PCC가 대기해야 하는 시간(초)을 지정합니다.
  9. 연결된 PCE에 의해 외부적으로 프로비저닝된 SP를 수락하도록 PCC를 구성합니다. 기본적으로 PCC는 PCE 시작 LSP를 거부합니다.
  10. PCEP 세션이 종료된 후 PCC가 최대 수신할 수 있는 분당 알 수 없는 메시지 수를 지정합니다.

    값의 범위는 1에서 16384까지이며 기본값은 0(사용 안 함 또는 제한 없음)입니다.

  11. PCEP 세션이 종료된 후 PCC가 최대로 수신할 수 있는 분당 알 수 없는 요청 수를 지정합니다.

    값의 범위는 0에서 16384까지이며 기본값은 5입니다. 값이 0이면 이 문이 비활성화됩니다.

  12. PCE 유형을 구성합니다.
  13. PCC가 요청을 다시 보내기 전에 응답을 기다려야 하는 시간(초)을 지정합니다.

    값의 범위는 0초에서 65535초 사이입니다.

  14. 구성을 확인하고 커밋합니다.

샘플 출력

예: PCE 제어 Point-to-Multipoint LSP를 지원하는 MPLS RSVP-TE에 대한 경로 계산 요소 프로토콜 구성

이 예에서는 포인트 투 멀티포인트 트래픽 엔지니어링 레이블 스위칭 경로(TE LSP)를 PCE(Path Computation Element)에 보고하는 기능을 갖춘 PCC(Path Computation Client)를 구성하는 방법을 보여줍니다.

요구 사항

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

  • ACX 시리즈, M 시리즈, MX 시리즈 또는 T 시리즈 라우터의 조합이 될 수 있는 라우터 3개.

  • VRR(Virtual Route Reflector) 기능으로 구성된 가상 머신 1개.

  • VRR에서 외부 스테이트풀 PCE에 대한 TCP 연결입니다.

  • PCC에서 실행되는 Junos OS 릴리스 16.1 이상.

시작하기 전에:

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

  • MPLS 및 RSVP-TE를 구성합니다.

  • OSPF 또는 기타 IGP 프로토콜을 구성합니다.

개요

PCE와 PCC 간에 PCEP 세션이 설정된 후 PCC는 LSP 상태 동기화를 위해 시스템의 모든 LSP를 PCE에 보고합니다. 여기에는 PCC 제어, PCE 위임 및 PCE 시작 포인트 투 포인트 LSP가 포함됩니다. Junos OS 릴리스 15.1F6 및 16.1R1부터 이 기능은 point-to-multipoint LSP도 보고하도록 확장됩니다.

기본적으로 Point-to-Multipoint LSP의 PCE 제어는 PCC에서 지원되지 않습니다. 이 기능을 추가하려면 또는 계층 수준에서 문을 포함합니다.p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id]

토폴로지

그림 7: PCE 제어 Point-to-Multipoint LSP 예PCE 제어 Point-to-Multipoint LSP 예

이 예에서 PCC는 수신 라우터, 라우터 R1은 전송 라우터, 라우터 R2는 송신 라우터입니다. PCC는 PCE에 연결된 VRR(Virtual Route Reflector)에 연결됩니다. PCC, 라우터 R1 및 라우터 R2 사이에는 많은 포인트 투 멀티포인트 인터페이스가 있습니다.

Point-to-Multipoint LSP의 보고는 다음과 같이 실행됩니다.

  1. 라우터 PCC가 포인트-투-멀티포인트 보고 기능을 지원하지 않고 포인트-투-포인트 및 포인트-투-멀티포인트 LSP로 구성된 경우, 포인트-투-포인트 LSP만 연결된 PCE에 보고됩니다. 기본적으로 PCC는 point-to-multipoint LSP 보고 기능을 지원하지 않습니다.

  2. 라우터 PCC가 point-to-multipoint LSP 보고 기능으로 구성된 경우, PCC는 먼저 보고 메시지를 통해 이 기능을 PCE에 보급합니다.

  3. 기본적으로 PCE는 포인트 투 멀티포인트 LSP 기능을 지원합니다. Point-to-Multipoint LSP 기능에 대한 PCC의 광고를 수신하면 PCE는 그 대가로 PCC에 해당 기능을 광고합니다.

  4. PCE의 point-to-multipoint 기능 광고를 수신하면 PCC는 업데이트 메시지를 사용하여 point-to-multipoint LSP의 모든 분기를 PCE에 보고합니다.

  5. 모든 LSP가 PCE에 보고되면 PCE와 PCC 간에 LSP 상태가 동기화됩니다.

구성

CLI 빠른 구성

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

Pcc

R1

R2

R3

절차

단계별 절차

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

PCC 라우터 구성:

  1. 라우터 PCC의 인터페이스를 구성합니다. MPLS를 활성화하려면 인터페이스가 들어오는 MPLS 트래픽을 삭제하지 않도록 인터페이스에 프로토콜 패밀리를 포함합니다.

  2. 라우터 PCC의 AS(Autonomous System) 번호를 구성합니다.

  3. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에서 RSVP를 활성화합니다.

  4. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에서 MPLS를 활성화합니다.

  5. 동적 LSP를 구성하고 LSP에 대한 자동 경로 계산을 비활성화합니다.

  6. Point-to-Multipoint LSP를 구성하고 LSP에 대한 외부 경로 컴퓨팅 엔터티를 정의합니다.

  7. MPLS LSP에 대한 외부 경로 컴퓨팅을 활성화하고 외부 프로비저닝된 LSP에 대한 템플릿을 할당합니다.

  8. 로컬 제어가 있고 PCE 제공 LSP 매개 변수에 의해 재정의되는 LSP를 구성합니다.

  9. 제한된 경로 LSP 계산을 위한 MPLS 관리 그룹 정책을 구성합니다.

  10. 구성된 관리 그룹 정책을 라우터 PCC 인터페이스에 할당합니다.

  11. 트래픽 엔지니어링 데이터베이스(TED) 가져오기 정책을 구성합니다.

  12. BGP 내부 그룹을 구성합니다.

  13. BGP에 대한 트래픽 엔지니어링을 구성하고 내보내기 정책을 할당합니다.

  14. 라우터 PCC의 모든 point-to-multipoint 인터페이스에 OSPF 영역 0을 구성합니다.

  15. 라우터 PCC의 point-to-point 인터페이스에서 OSPF 영역 0을 구성합니다.

  16. OSPF에 대한 트래픽 엔지니어링을 활성화합니다.

  17. 라우터 PCC가 연결하는 PCE를 정의하고 PCE 매개변수를 구성합니다.

  18. 외부 경로 컴퓨팅을 위한 point-to-multipoint LSP 기능을 활성화하도록 라우터 PCC를 구성합니다.

  19. 트래픽 엔지니어링 정책을 구성합니다.

결과

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

검증

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

PCC에서 LSP 구성 확인

목적

Point-to-Multipoint LSP의 LSP 유형과 실행 상태를 확인합니다.

작업

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

의미

출력은 lsp2-pcc LSP를 PCE 제어 LSP로 표시합니다.

PCC에서 PCE 구성 확인

목적

PCE 매개 변수 구성 및 PCE 상태를 확인합니다.

작업

운영 모드에서 show path-computation-client active-pce 명령을 실행합니다.

의미

출력에는 라우터 PCC가 연결된 활성 PCE와 pce1 PCE 매개 변수 및 상태가 표시됩니다.

MPLS에 대한 경로 계산 요소 프로토콜 이해 PCE 시작 Point-to-Multipoint LSP에 대한 지원을 통한 RSVP-TE

Point-to-Multipoint PCE 시작 LSP의 도입으로 PCE는 PCC에서 로컬 LSP를 구성할 필요 없이 동적으로 point-to-multipoint LSP를 시작하고 프로비저닝할 수 있습니다. 이를 통해 PCE는 PCEP(Path Computation Element Protocol) 세션 내에서 그리고 여러 세션 간에 점대다점 경로 계산의 타이밍과 시퀀스를 제어할 수 있으므로 중앙에서 제어되고 배포되는 동적 네트워크를 생성할 수 있습니다.

PCE 시작 Point-to-Multipoint LSP의 이점

Point-to-Multipoint LSP의 동적 생성 및 삭제를 통해 애플리케이션 요구에 대응하여 Point-to-Multipoint 트래픽 엔지니어링 LSP 배치 요구 사항을 충족함으로써 중앙에서 제어되고 구축되는 동적 네트워크를 생성합니다.

PCE 시작 Point-to-Multipoint LSP의 시그널링

PCE 시작 Point-to-Multipoint LSP의 시그널링은 다음과 같습니다.

  • When a new branch is added (Grafting)—새로운 브랜치 하위 LSP만 시그널링되며 전체 point-to-multipoint 트리의 시그널링을 다시 전송하지 않습니다.

    새로운 하위 LSP를 프로비저닝하기 전에 토폴로지 변경이 발생한 경우, PCS(Path Computation Server)는 전체 포인트-투-멀티포인트 트리를 다시 계산하고 PC 업데이트 메시지를 사용하여 포인트-투-멀티포인트 LSP를 업데이트합니다.

  • When a branch is deleted (Pruning)—삭제된 브랜치 하위 LSP는 삭제되며 전체 point-to-multipoint 트리의 재시그널링을 초래하지 않습니다.

  • When a branch sub-LSP parameter is changed—ERO(Explicit Route Object), 대역폭 또는 우선 순위와 같은 하위 LSP 매개 변수의 변경은 최적화로 인해 또는 사용자 요청에 따라 발생할 수 있습니다. 하위 LSP에 대한 재시그널링 요청이 있는 경우, 전체 point-to-multipoint 트리가 재시그널링되고, 모든 브랜치의 새로운 인스턴스가 가동되면 새 인스턴스로의 전환이 발생합니다.

  • When a branch sub-LSP path fails- 장애가 발생한 브랜치 하위 LSP에 대한 오류가 PCS에 보고됩니다. PCS에서 새 ERO를 수신하면 전체 포인트 투 멀티포인트 트리가 장애가 발생한 브랜치 하위 LSP와 함께 다시 시그널링되고 새 인스턴스로의 전환은 MBB(Make-before-Break) 방식으로 발생합니다.

PCEP 세션 실패 후 PCE 시작 Point-to-Multipoint LSP의 동작

PCEP 세션이 실패하면 타이머가 만료될 때까지 PCE 시작 Point-to-Multipoint LSP가 분리됩니다.state timeout 타이머가 만료되면 PCE 시작 LSP가 정리됩니다.state timeout

PCEP 세션 실패 후 PCE 시작 Point-to-Multipoint LSP를 제어하기 위해 기본 또는 보조 PCE는 타이머가 만료되기 전에 메시지를 보냅니다.PCInitiatestate timeout

PCE 시작 Point-to-Multipoint LSP 기능 구성

기본적으로 PCE에 의한 Point-to-Multipoint LSP의 생성 및 프로비저닝은 PCC에서 지원되지 않습니다. 이 기능을 사용하려면 또는 계층 수준에서 및 문을 포함합니다.p2mp-lsp-init-capabilityp2mp-lsp-update-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id]

명령문은 PCE에 의해 point-to-multipoint RSVP-TE LSP를 프로비저닝할 수 있는 기능을 제공합니다.p2mp-lsp-init-capability 명령문은 PCE에 의해 point-to-multipoint RSVP-TE LSP 매개 변수를 업데이트할 수 있는 기능을 제공합니다.p2mp-lsp-update-capability

PCE 시작 Point-to-Multipoint LSP에 대해 지원되는 기능 및 지원되지 않는 기능

PCE 시작 Point-to-Multipoint LSP에서 지원되는 기능은 다음과 같습니다.

  • 인터넷 초안 draft-ietf-pce-stateful-pce-p2mp(2018년 10월 만료), Point-to-Multipoint Traffic Engineering 레이블 스위치 경로에 대한 상태 저장 PCE 사용을 위한 PCE(Path Computation Element) 프로토콜 확장을 부분적으로 준수합니다.

  • Junos OS 릴리스 21.1R1부터 PCE 시작 RSVP 기반 Point-to-Multipoint LSP에 대한 NSR(Nonstop Active Routing)을 지원합니다. 기본 라우팅 엔진만이 컨트롤러와의 PCEP 세션을 유지합니다. PCE에서 시작된 모든 P2MP LSP에 대한 멀티캐스트 플로우 사양을 포함하여 PCE에서 시작된 모든 RSVP LSP를 백업 라우팅 엔진과 동기화합니다. 전환 중에는 PCEP 세션이 다운되고 백업 라우팅 엔진이 기본 라우팅 엔진이 되면 다시 설정됩니다. 이는 라우팅 엔진 전환 중에 PCE 시작 RSVP LSP를 통해 전달되는 트래픽의 트래픽 손실을 줄입니다. 이 기능은 NSR이 구성될 때 활성화됩니다.

다음 기능은 PCE 시작 Point-to-Multipoint LSP에서 지원되지 않습니다.

  • 포인트-투-멀티포인트 로컬 제어 LSP 위임.

  • LSP 제어 위임.

  • IGP 라우팅 도메인 내에서 PCE 발견을 위한 내부 게이트웨이 프로토콜(IGP) 확장.

  • 요청/응답 메시징.

  • 한 포인트 투 멀티포인트 트리에서 다른 포인트 투 멀티포인트 트리로 브랜치 하위 LSP를 직접 이동합니다.

    첫 번째 point-to-multipoint 트리에서 브랜치 하위 LSP를 삭제하고 메시지가 디바이스에서 LSP 제거를 표시한 후 다른 트리에 다시 추가하면 동일한 작업을 수행할 수 있습니다.PCReport

  • IPv6은 지원되지 않습니다.

  • SERO 기반 시그널링은 지원되지 않습니다.

  • Empty-ERO 기능은 지원되지 않습니다.

  • 링크 보호는 지원되지 않습니다.

PCE 시작 Point-to-Multipoint LSP를 MVPN에 매핑

단일 또는 다양한 MVPN 멀티캐스트 플로우(S,G)를 동적으로 생성된 PCE 시작 LSP(Point-to-Multipoint Label-Switched Path)에 연결할 수 있습니다. 이 기능이 작동하기 위해 선택적 흐름 유형만 지정할 수 있습니다. 여기에는 다음이 포함됩니다.

  • MVPN 라우팅 인스턴스에 매핑되는 RD(Route Distinguisher).

  • (S,G)는 멀티캐스트 패킷 및 대상 멀티캐스트 그룹 주소의 소스입니다. 이는 터널에 매핑하기 위해 들어오는 트래픽을 필터링하는 데 사용됩니다.

  • 위에서 언급한 플로우 사양과 일치하는 트래픽을 전송하는 데 사용되는 Point-to-multipoint LSP입니다.

자세한 내용은 인터넷 초안 draft-ietf-pce-pcep-flowspec-05(2020년 2월 16일 만료) 흐름 사양에 대한 PCEP 확장을 참조하십시오.

이 기능의 현재 구현은 초안의 다음 섹션을 구현하지 않습니다.

  • 섹션 3.1.2 — IGP에서 PCE 기능 보급

  • 섹션 3.2 — PCReq 및 PCRep 메시지

  • 섹션 7 - 경로 지정을 제외한 대부분의 플로우 사양이 기능의 현재 구현은 지원되지 않으며 IPv4 멀티캐스트 플로우 사양은 지원되지 않습니다.

PCE 시작 Point-to-Multipoint LSP를 MVPN에 매핑할 수 있도록 하려면 다음을 수행합니다.

  • 계층 수준에 명령문을 포함하여 PCC의 플로우 사양 기능(트래픽 스티어링이라고도 함)에 대한 지원을 나타냅니다.pce_traffic_steering[edit protocols pcep pce pce-id]

  • [edit routing-instances routing-instance-name provider-tunnel] 계층 수준에서 external-controller 문을 포함합니다.

    MVPN에 대한 프로바이더-터널 구성에 의 존재는 이 MVPN 인스턴스에 대한 point-to-multipoint LSP 및 (S,G)가 외부 컨트롤러에 의해 제공될 수 있음을 나타냅니다.external-controller 이를 통해 외부 컨트롤러는 MVPN에 대해 (S,G) 및 point-to-multipoint LSP를 동적으로 구성할 수 있습니다.

PCE 시작 Point-to-Multipoint LSP를 MVPN에 매핑하려면 다음 사항을 고려해야 합니다.

  • 특정 MVPN 인스턴스에 대해 문을 활성화 하지 않으면 PCCD 프로세스가 (S,G)를 동적으로 구성하지 않습니다.external-controller pccd

  • CLI에서 구성을 비활성화하면 해당 특정 MVPN 인스턴스에 대해 동적으로 학습된 멀티캐스트 플로우(S, G)가 삭제되고 외부 컨트롤러에 보고됩니다.external-controller pccd

  • CLI에서 (S,G)가 이미 구성된 경우 로컬 구성의 우선 순위가 더 높으므로 PCC는 (S,G)를 동적으로 구성할 수 없습니다.

  • 특정 (S,G)가 외부 컨트롤러에서 동적으로 학습된 다음 동일한 MVPN 인스턴스에 대해 동일한 (S,G)를 구성하면 동적으로 학습된 (S,G)가 삭제되고 PCC를 통해 외부 컨트롤러에 보고됩니다.

  • 라우팅 프로토콜 프로세스가 재부팅되면 PCCD 프로세스는 모든 (S,G)를 다시 재구성합니다.

  • PCCD 프로세스가 재부팅되면 MVPN은 구성된 모든 PCCD(S,G)를 외부 컨트롤러에 보고합니다.

  • 사용자가 특정 MVPN 인스턴스에 대해 활성화 하면 MVPN은 PCCD 프로세스에 (S,G)를 구성하도록 요청합니다(있는 경우).external-controller pccd

  • 특정 MPVN 인스턴스에 대한 주요 구성 변경 사항이 있는 경우 MVPN은 PCCD 프로세스에 해당 특정 MVPN 인스턴스에 대한 모든 (S,G)를 재구성하도록 요청합니다.

  • PCE 시작 포인트-투-멀티포인트 LSP와 연관된 모든 플로우 사양은 동일한 RD를 가져야 합니다. PC 시작 중에 모든 플로우 사양의 RD가 동일하지 않으면 PC 시작 메시지가 오류와 함께 삭제됩니다.

  • Point-to-Multipoint LSP는 선택적 유형의 플로우 사양과만 연결할 수 있으며, 그렇지 않으면 PC 시작 메시지가 오류와 함께 삭제됩니다.

  • PC 업데이트 중에 새로운 플로우 사양 추가 또는 기존 플로우 사양 업데이트로 인해 모든 플로우 사양에 RD가 동일하지 않은 경우 PCC는 업데이트 메시지를 삭제합니다.

  • PC 업데이트 중에 새로운 플로우 사양 추가 또는 기존 플로우 사양 업데이트로 인해 모든 플로우 사양이 선택 조건을 충족하지 않으면 PCC는 업데이트 메시지를 삭제합니다.

  • MVPN 라우팅 인스턴스와 PCE 시작 Point-to-Multipoint LSP의 매핑 및 MVPN 인스턴스와 정적(로컬로 구성된) point-to-multipoint LSP의 매핑 동작은 사용자 수준에서 동일합니다.

  • 플로우 사양 ID는 하나의 point-to-multipoint LSP에만 연결될 수 있습니다. 동일한 RD 및 (S,G)를 여러 point-to-multipoint LSP에 연결하기 위해 다른 ID와 동일한 RD 및 (S,G)를 가진 여러 플로우 사양을 추가할 수 있습니다.

  • PCEP 매핑 동적(S,G)의 경우, 임계값은 항상 의 기본값 입니다.0

  • 단일 PCE 시작 Point-to-Multipoint LSP에 매핑된 플로우 사양의 수에는 제한이 없습니다.

  • 이 기능의 현재 구현은 다음을 지원하지 않습니다.

    • Point-to-Multipoint LSP와 관련된 포워딩 상태 보고.

    • 포괄적 프로바이더 터널 동적 구성

    • MVPN 수신 복제 터널에 대한 매핑

    • 프로그래밍 가능한 라우팅 프로토콜 프로세스(prpd)

    • MVPN 멀티캐스트 플로우(S,G)에 매핑되는 CLI 구성 Point-to-Multipoint LSP의 보고.

Path Computation Element Protocol에 대한 세그먼트 라우팅 활성화

SUMMARY 트래픽 스티어링을 위해 PCEP(Path Computation Element Protocol)를 사용하여 세그먼트 라우팅 또는 SPRING(Source Packet Routing in Networking) 트래픽 엔지니어링(SR-TE)을 활성화할 수 있습니다. 이러한 지원을 통해 세그먼트 라우팅의 이점은 PCE(Path Computation Element)에 의해 외부적으로 제어되는 LSP(Label Switched Path)로 확장됩니다.

Path Computation Element Protocol 개요를 위한 세그먼트 라우팅

PCEP를 위한 세그먼트 라우팅의 이점

  • 외부 컨트롤러를 통해 LSP를 설정하면 네트워크에서 LSP당 및 디바이스당 대역폭 수요를 전체적으로 볼 수 있어 온라인 및 실시간 제약 기반 경로 계산이 가능합니다.

    세그먼트 라우팅의 장점은 PCE(Path Computation Element)라고도 하는 외부 컨트롤러에 의해 시작되는 LSP로 확장되어 MPLS 네트워크에서 외부 경로 컴퓨팅의 이점을 증대합니다.

  • 위임 기능이 있는 PCC(Path Computation Client, 수신 MX 시리즈 라우터)는 PCEP 세션이 중단될 때 PCE에서 위임된 세그먼트 라우팅 LSP의 제어를 되찾을 수 있습니다. 그렇지 않으면 LSP가 PCC에서 삭제됩니다. 따라서 패킷이 조용히 삭제되거나 삭제되는 상황(null 경로 조건이라고도 함)을 방지하여 LSP 데이터 보호를 보장할 수 있습니다.

트래픽 엔지니어링을 위한 세그먼트 라우팅

세그먼트 라우팅은 IPv4 또는 IPv6 데이터 플레인을 통해 작동할 수 있으며 ECMP(Equal-Cost Multipath)를 지원합니다. IGP 확장이 내장된 세그먼트 라우팅은 레이어 3 VPN, VPWS(Virtual Private Wire Service), VPLS(Virtual Private LAN Service) 및 EVPN(Ethernet VPN)을 비롯한 MPLS의 풍부한 멀티서비스 기능과 통합됩니다.

세그먼트 라우팅-트래픽 엔지니어링(SR–TE) 솔루션의 상위 수준 구성 요소 중 일부는 다음과 같습니다.

  • 링크 특성 광고를 위한 IGP 사용. 이 기능은 RSVP-TE와 유사합니다.

  • 수신 디바이스 또는 PCE에서 CSPF(Constrained Shortest Path First) 사용.

  • 링크의 레이블 광고에 IGP 사용.

    SR-TE 기능:

    1. 수신 디바이스는 통과하려는 링크의 레이블을 쌓아 LSP를 구성합니다.

    2. 링크별 IGP 광고는 레이블 스태킹과 결합되어 수신 디바이스에 소스 라우팅 LSP를 생성하므로 전송 디바이스는 엔드 투 엔드 LSP를 인식하지 못합니다.

    3. LSP는 전송 디바이스에 LSP당 메모리 요구 사항을 두지 않고 에지 노드 간에 생성됩니다. (SR-TE에는 LSP당 시그널링이 없으므로 이러한 LSP의 생성이 가능합니다.)

    4. 이웃별 레이블이 누적되어 많은 수의 레이블을 관리하게 되어 컨트롤 플레인 확장이 발생합니다.

PCEP를 위한 세그먼트 라우팅의 Junos OS 구현

Junos OS는 PCE 시작 LSP와 PCE 위임 LSP의 두 가지 유형의 LSP에 대해 PCEP를 위한 세그먼트 라우팅을 구현합니다.

PCE 시작 세그먼트 라우팅 LSP

PCE 시작 세그먼트 라우팅 LSP는 PCE가 인접 및 노드 세그먼트에 대해 생성하는 LSP입니다

PCE는 다음과 같은 기능을 수행합니다.

  1. 세그먼트 라우팅 LSP의 경로를 계산합니다.

  2. PCEP 세그먼트 라우팅 확장을 사용하여 PCC(Path Computation Client)에 LSP를 프로비저닝합니다.

  3. PCEP 세그먼트 라우팅 확장을 구문 분석합니다.

  4. PCC에 자체 선호 값을 갖고 inet.3 라우팅 테이블에서 사용할 수 있는 터널 경로를 생성하여 다른 터널 경로와 마찬가지로 IP 트래픽 및 서비스를 확인합니다.

PCC는 다음과 같은 기능을 수행합니다.

  1. 소스 S-ERO의 첫 번째 네트워크 액세스 식별자(NAI)를 기반으로 발신 인터페이스를 선택합니다.

    Junos OS는 첫 번째 홉을 엄격한 홉으로 포함하는 S-ERO를 지원합니다. Junos OS는 느슨한 홉 노드 세그먼트 ID(SID)를 기반으로 PCC에서 나가는 인터페이스 선택을 지원하지 않습니다. 그러나 나머지 홉은 느슨할 수 있습니다. 첫 번째 홉을 벗어난 S-ERO에 대해서는 단순히 다음 홉 생성을 위해 레이블을 사용하는 것 외에는 특정 처리가 수행되지 않습니다.

  2. 다음과 같은 경우 S-ERO를 거부합니다.

    • S-ERO에는 레이블이 없습니다.

    • S-ERO는 6개 이상의 홉을 전달합니다.

    PCC는 동일한 메트릭을 가진 동일한 대상에 대한 여러 LSP가 있을 때 ECMP(Equal-Cost Multipath) 경로를 생성합니다.

  3. PCE가 프로비저닝된 후 세그먼트 라우팅 LSP의 변경으로 이어지는 모든 이벤트(예: 레이블이 변경 또는 철회된 경우 또는 LSP가 통과하는 인터페이스 중 하나가 다운된 경우)를 처리할 때까지 기다립니다.

PCEP 세션이 중단되면 PCE 시작 세그먼트 라우팅 LSP:

  1. 300초 동안 유지됩니다.

  2. 300초 후에 PCC에서 삭제됩니다.

자세한 내용은 인터넷 초안 draft-ietf-pce-lsp-setup-type-03.txt(2015년 12월 25일 만료), PCEP 메시지에서 경로 설정 유형 전달을 참조하십시오. 및 draft-ietf-pce-segment-routing-06.txt(2016년 2월 10일 만료), 세그먼트 라우팅을 위한 PCEP 확장.

PCE 위임 세그먼트 라우팅 LSP

PCE 위임 세그먼트 라우팅 LSP는 PCC가 로컬로 구성한 다음 PCE 컨트롤러에 위임하는 LSP입니다.

주:

Junos OS 릴리스 20.1R1은 다음을 지원합니다.

  • IPv4 대상이 있는 비색상 세그먼트 라우팅 LSP에 대한 PCE 위임 기능.

  • 세그먼트 목록의 첫 번째 세그먼트만 외부 컨트롤러에 위임하고 보고합니다. PCE 위임에 대해 여러 세그먼트가 지원되지 않습니다.

PCC는 다음과 같은 방법으로 세그먼트 라우팅 LSP를 외부 컨트롤러(PCE)에 위임할 수 있습니다.

  • Initial delegation- 로컬 LSP는 아직 PCC에서 구성되지 않았으며 LSP의 위임은 LSP가 구성될 때 발생합니다.

  • Delegation of existing LSP- 로컬 LSP는 PCC에서 구성되며, LSP의 위임은 소스 라우팅 경로가 구성된 후에 발생합니다. 즉, 위임 기능은 기존 세그먼트 라우팅 LSP에서 활성화됩니다.

세그먼트 라우팅 LSP를 위임한 후 PCE는 위임된 LSP를 제어하고 경로 계산을 위해 LSP 속성을 수정할 수 있습니다. PCC와 PCE 간의 PCEP 세션이 중단되면 LSP 제어가 PCC로 복귀합니다. PCE 위임 LSP는 PCEP 세션이 중단될 경우 PCE 시작 LSP보다 이점이 있습니다. PCE 시작 LSP의 경우 PCEP 세션이 중단되면 LSP가 PCC에서 삭제됩니다. 그러나 PCE 위임 LSP의 경우 PCEP 세션이 중단되면 PCC는 PCE에서 위임된 LSP의 제어를 회수합니다. 결과적으로 PCE 위임 LSP를 사용하면 세션이 다운될 때 패킷이 조용히 삭제되는 상황(null 경로 조건이라고도 함)을 피할 수 있습니다.

다음 유형의 세그먼트 라우팅 LSP는 PCE 위임 기능을 지원합니다.

  • Static LSPs- 전체 레이블 스택이 정적으로 구성된 정적으로 구성된 소스 라우팅 경로.

  • Auto-translated LSPs- 자동으로 변환되는 정적으로 구성된 소스 라우팅 경로.

  • Computed LSPs- 분산 CSPF(Constrained Shortest Path First)로 계산되는 정적으로 구성된 소스 라우팅 경로.

  • Dynamic LSPs- 마지막 홉 ERO 해상도가 있는 동적 터널 모듈을 통해 트리거되는 동적으로 생성된 터널입니다.

세그먼트 라우팅 LSP의 소스에 따라 PCC에서 위임 기능을 구성할 수 있습니다. 세그먼트 라우팅 LSP의 위임을 활성화하려면 계층 아래의 적절한 수준에서 문을 포함합니다.lsp-external-controller pccd[edit protocols source-packet-routing]

표 2 은(는) 위임 기능이 활성화된 해당 구성 계층 수준에 대한 LSP 소스의 매핑을 보여줍니다.

주:

PCC에서 위임 기능을 구성하기 전에 및 계층 수준에서 문을 포함해야 합니다.lsp-external-controller pccd[edit protocols source-packet-routing][edit protocols mpls]

표 2: 세그먼트 라우팅 LSP 소스와 구성 계층 매핑

세그먼트 라우팅 LSP의 소스

구성 계층

  • 자동 번역 LSP

  • 정적 LSP

의 기본 세그먼트 목록 [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

계산된 LSP(분산 CSPF)

에 있는 소스 라우팅 경로의 기본 세그먼트 목록:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

동적 LSP

에 있는 소스 라우팅 경로 템플릿의 기본 세그먼트 목록:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

명령 출력에서 SR-TE LSP의 제어 상태를 show spring-traffic-engineering 볼 수 있습니다.show spring-traffic-engineering

은(는) 소스 라우팅 경로에 대해 문이 구성될 때 PCEP 상호 작용을 표시합니다.표 3lsp-external-controller

표 3: PCEP 상호 작용 LSP 위임

lsp-external-controller 구성 계층

source-routing-path 위임 상태

PCC와 PCE 간의 PCEP 상호 작용

소스 라우팅 경로의 기본 세그먼트 목록

초기 위임

  1. PCReport 메시지는 위임을 위해 PCE로 전송됩니다. PCReport에는 제약 조건 및 경로 세부 정보(예: ERO)만 포함됩니다.

  2. PCE는 LSP의 경로를 계산하고 경로가 다운 상태임을 보고합니다.

  3. 컨트롤러가 ERO를 계산하고 PCUpdate를 통해 PCC에 결과를 알릴 때까지 로컬 LSP에 의해 경로가 프로그래밍되지 않습니다.

라우팅 프로토콜 프로세스(rpd)가 다시 시작되거나 라우팅 엔진 전환이 발생할 때도 동일한 동작이 나타납니다.

소스 라우팅 경로의 기본 세그먼트 목록

기존 경로의 위임

  1. PCReport는 위임을 위해 PCE로 전송됩니다. PCReport에는 제약 조건 및 경로 세부 정보(예: ERO)만 포함됩니다.

  2. 해당 1차 세그먼트가 PCE에 위임됩니다.

  3. PCE는 LSP의 경로를 계산합니다.

  4. 기본 세그먼트는 PCUpdate가 PCE에서 수신될 때까지 로컬 구성 또는 계산에 의해 결정된 경로에 계속 기여합니다.

    • 기본 세그먼트에 대해 S-BFD(Seamless BFD)가 구성되지 않은 경우 경로에 대한 추가 업데이트가 없으며 LSP 상태도 모니터링되지 않고 PCE에 보고되지 않습니다. 이 지점의 LSP 상태는 해당 지점에서 경로 계산이 성공했는지 여부에 따라 작동 또는 중단으로 보고됩니다.

    • S-BFD가 기본 세그먼트에 대해 구성된 경우, 기본 세그먼트의 상태가 추적되어 PCE에 보고됩니다. BFD가 기본 세그먼트가 다운된 것을 감지하면 해당 기본 경로가 경로에서 제거됩니다. 해당 경로가 지금 실행 중이면 이전에 계산된 것과 동일한 경로가 다시 프로그래밍됩니다.

  5. PCE에서 PCUpdate 메시지를 받으면 SR-TE는 수신된 매개 변수를 사용하여 PCReport 메시지가 전송된 경로를 설정합니다. 그런 다음 프로그래밍된 경로에는 PCE에서 수신된 세그먼트 목록만 포함되며 이전에 프로그래밍된 다른 모든 세그먼트 목록은 제거됩니다. 이러한 경로 재프로그래밍은 단절 전 방식으로 이루어집니다.

소스 라우팅 경로의 기본 세그먼트

위임이 구성되지 않았거나 삭제되었습니다.

PCE의 세그먼트 목록(사용 가능한 경우)은 더 이상 사용되지 않으며 로컬 구성의 계산 결과가 사용됩니다. 세그먼트 목록에 대한 로컬 결과를 사용할 수 있는 경우 해당 세그먼트 목록을 사용하여 단절 전 메이크 방식으로 경로를 프로그래밍합니다.

소스 라우팅 경로의 세그먼트 목록

위임은 LSP가 구성된 후 활성화됩니다.

위임 기능은 소스 라우팅 경로 아래의 기본 세그먼트 목록에 대해 트리거됩니다.

소스 라우팅 경로의 세그먼트 목록

위임이 구성되지 않았거나 삭제되었습니다.

위임 기능은 소스 라우팅 경로 아래의 기본 세그먼트 목록에서 제거됩니다.

소스 라우팅 경로 템플릿의 기본 세그먼트 목록

위임은 LSP가 구성된 후 활성화됩니다.

  • 소스 라우팅 경로 템플릿 아래에서 전체 소스 라우팅 경로에 대해 위임 기능이 트리거됩니다.

    템플릿 구성은 동적 터널 모듈에만 적용할 수 있습니다.

  • 소스 라우팅 경로 템플릿의 기본 경로 아래—구성에 따라 특정 기본 경로에 대해 위임 기능이 트리거됩니다.

소스 라우팅 경로 템플릿의 기본 세그먼트 목록

위임이 구성되지 않았거나 삭제되었습니다.

위임 기능은 템플릿 구성과 일치하는 모든 소스 라우팅 경로 및 기본 경로에서 제거됩니다.

PCEP에 대한 세그먼트 라우팅 제한 사항 및 지원되지 않는 기능

PCEP에 대한 세그먼트 라우팅 지원은 시스템의 성능 부담을 가중시키지 않습니다. 그러나 다음과 같은 제한 사항이 있습니다.

  • SR-TE LSP는 PCC에서 로컬로 보호되지 않습니다. LSP가 6개 이상의 홉인 경우, 일반 IP 트래픽을 전달하는 것 외에는 LSP에서 서비스가 제공되지 않습니다.

  • GRES(Graceful Routing Engine Switchover) 및 통합 ISSU(In-Service Software Upgrade)는 지원되지 않습니다.

  • NSR(Nonstop Active Routing)은 지원되지 않습니다.

  • IPv6은 지원되지 않습니다.

  • PCE 위임 LSP는 다음을 지원하지 않습니다.

    • 컬러 SR-TE LSP

    • IPv6 LSP

    • 소스 라우팅 경로의 보조 세그먼트 목록입니다. 세그먼트 목록의 한 경로만 위임할 수 있습니다.

    • 다중 세그먼트 표준. 세그먼트 목록의 첫 번째 세그먼트만 위임되고 컨트롤러에 보고됩니다.

예: Path Computation Element Protocol에 대한 세그먼트 라우팅 구성

이 예에서는 PCEP(Path Computation Element Protocol)에 대해 세그먼트 라우팅 또는 SPRING(Source Packet Routing in Networking) 트래픽 엔지니어링(SR-TE)을 구성하는 방법을 보여줍니다. 구성에서는 효율적인 트래픽 엔지니어링을 위해 세그먼트 라우팅의 이점과 외부 경로 컴퓨팅의 이점을 활용합니다.

요구 사항

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

  • MX 시리즈 5G 유니버설 라우팅 플랫폼 4개, 수신 MX 시리즈 라우터는 PCC(Path Computation Client)입니다.

  • PCC에서 외부 PCE(Stateful Path Computation Element)로의 TCP 연결입니다.

  • PCE 시작 LSP의 구현을 위해 PCC에서 실행되는 Junos OS 릴리스 17.2 이상.

    PCE 위임 기능을 위해서는 Junos OS 릴리스 20.1R1 이상을 실행해야 합니다.

시작하기 전에:

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

  • MPLS를 구성합니다.

  • IS-IS를 구성합니다.

개요

PCEP를 위한 세그먼트 라우팅의 Junos OS 구현에는 PCE 시작 및 PCE 위임 SR-TE LSP가 포함됩니다.

  • PCE 시작 LSP의 구현은 Junos OS 릴리스 17.2R1에 도입되었으며, 여기서 세그먼트 라우팅의 트래픽 엔지니어링 기능은 PCE에 의해 시작된 LSP에 대한 PCEP 세션에서 지원됩니다. PCE는 인접 및 노드 세그먼트에 대한 LSP를 생성합니다. 터널 경로는 PCE 시작 SR-TE LSP에 해당하는 PCC의 inet.3 라우팅 테이블에 생성됩니다.

  • PCE 위임 LSP의 구현은 Junos OS 릴리스 20.1R1에 도입되었으며, 여기서 PCC에서 로컬로 구성된 IPv4 무색 세그먼트 라우팅 LSP를 PCE 컨트롤러에 위임할 수 있습니다. 그런 다음 PCE는 LSP를 제어하고 경로 계산을 위해 LSP 속성을 수정할 수 있습니다.

PCE 위임 LSP는 PCEP 세션이 중단되는 시점에 PCE 시작 LSP보다 이점이 있습니다. PCE 시작 LSP의 경우 PCEP 세션이 중단되면 LSP가 PCC에서 삭제됩니다. 그러나 PCE 위임 LSP의 경우 PCEP 세션이 중단되면 PCC는 PCE에서 위임된 LSP의 제어를 회수합니다. 그 결과, PCE 위임 LSP를 사용하면 PCEP 세션이 다운될 때 패킷이 조용히 삭제되는 상황(null 경로 조건이라고도 함)을 피할 수 있습니다.

PCEP에 대한 세그먼트 라우팅 활성화:

PCE 시작 세그먼트 라우팅 LSP의 경우:

  1. 계층 수준에서 문을 포함하여 MPLS에 대한 외부 경로 컴퓨팅을 활성화합니다.lsp-external-controller[edit protocols mpls]

    이 구성은 RSVP-TE 확장이 있는 PCEP에도 필요합니다. PCEP에 대한 세그먼트 라우팅이 활성화된 경우 RSVP-TE를 사용하여 PCEP를 비활성화할 수 없습니다.

  2. 계층 수준에서 문을 포함하여 SR-TE에 대한 외부 경로 컴퓨팅을 활성화합니다.lsp-external-controller pccd[edit protocols spring-traffic-engineering]

  3. 계층 수준에서 문을 포함하여 PCE에 대한 세그먼트 라우팅을 활성화합니다.spring-capability[edit protocols pcep pce pce-name]

  4. 선택적으로 계층 수준에서 문을 포함하여 PCE의 최대 SID 깊이를 구성합니다.max-sid-depth number[edit protocols pcep pce pce-name]

    최대 SID 깊이는 노드 또는 노드의 링크에서 지원하는 SID 수입니다. 구성되지 않은 경우 기본 최대 SID 값 5가 적용됩니다.

  5. 선택적으로 계층 수준에서 을 (를) 포함하여 세그먼트 라우팅에 대한 기본 설정 값을 구성합니다.preference preference-value[edit protocol spring-te]

    선호 값은 후보 경로 중 활성 경로 형식으로 경로가 선택되는 순서를 나타내며, 값이 높을수록 선호가 높습니다. 구성되지 않은 경우 기본 기본 설정 값 8이 적용됩니다.

  6. 선택적으로 계층 수준에서 문을 포함하여 문제 해결을 위해 세그먼트 라우팅 로깅을 구성합니다.traceoptions[edit protocols spring-te]

세그먼트 라우팅 LSP의 PCE 위임을 위해 앞서 언급한 단계 외에도 다음을 수행합니다.

  1. 레이블 매개 변수를 사용하여 세그먼트 목록을 정의합니다. 이렇게 하면 PCC에서 로컬로 세그먼트 라우팅 LSP가 생성됩니다.

  2. 세그먼트 라우팅 LSP 소스에 따라 다음 계층 중 하나에 문을 포함하여 PCC에서 로컬로 구성된 LSP의 위임 기능을 활성화합니다.lsp-external-controller pccd

    • 분산 CSPF 및 계층 수준으로 계산되는 정적으로 구성된 소스 라우팅 경로의 경우.[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

    • 전체 레이블 스택이 정적으로 구성된 정적으로 구성된 소스 라우팅 경로와 자동으로 변환되는 소스 라우팅 경로의 경우 - 계층 수준입니다.[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

    • 마지막 홉 ERO 해상도 및 계층 수준이 있는 동적 터널 모듈을 통해 트리거되는 동적으로 생성된 터널의 경우.[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name][edit protocols source-packet-routing source-routing-path-template template-name]

토폴로지

그림 8 은(는) PCE와 PCC(수신 MX 시리즈 라우터) 간에 실행되는 PCEP 세션이 있는 샘플 네트워크 토폴로지를 보여줍니다. 라우터 R1, R2 및 R3은 네트워크의 다른 MX 시리즈 라우터입니다. 이 예에서는 PCC에서 PCEP에 대한 세그먼트 라우팅을 구성합니다. 또한 PCC에서 라우터 R3으로 고정 경로를 구성하여 정적 경로에 대한 트래픽을 라우팅할 때 SR-TE 터널 경로의 사용을 확인합니다.

그림 8: PCEP를 위한 세그먼트 라우팅PCEP를 위한 세그먼트 라우팅

구성

CLI 빠른 구성

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

이 섹션에서는 모든 디바이스(PCC 및 라우터 3개)의 컨피그레이션을 제시하지만 단계별 절차에서는 PCC의 컨피그레이션만 문서화합니다.

Pcc

라우터 R1

라우터 R2

라우터 R3

절차
단계별 절차

이 예에서는 PCC만 구성합니다.

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

PCC를 구성하려면 다음을 수행합니다.

  1. PCC의 인터페이스를 구성합니다.

  2. 라우터 ID를 구성하고 PCC에 대한 AS(Autonomous System) 번호를 할당합니다.

  3. PCC에서 라우터 R3으로의 고정 경로를 구성합니다.

    정적 경로는 확인 목적으로만 생성되며 기능 기능에 영향을 주지 않습니다.

  4. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 RSVP를 구성합니다.

  5. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 MPLS를 구성합니다.

  6. MPLS에 대한 외부 경로 컴퓨팅 기능을 활성화합니다.

  7. 관리 및 루프백 인터페이스를 제외한 PCC의 모든 인터페이스에 IS-IS 레벨 2를 구성합니다.

  8. 세그먼트 라우팅을 위한 SRGB(Segment Routing Global Block) 속성을 구성합니다.

  9. SR-TE에 대한 외부 경로 컴퓨팅 기능을 활성화합니다.

  10. PCE 매개 변수를 구성하고 PCE 및 세그먼트 라우팅 기능에 의한 LSP의 프로비저닝을 활성화합니다.

  11. PCE에 의한 세그먼트 라우팅 LSP의 프로비저닝을 활성화합니다.

  12. PCE에 대한 세그먼트 라우팅 기능을 활성화합니다.

  13. 정적 세그먼트 목록 매개 변수를 정의합니다.static_seg_list_1

  14. PCE 위임을 위해 PCC에서 라우터 R3으로 정적 세그먼트 라우팅 LSP를 구성합니다.

  15. 소스 라우팅 경로에 대한 위임 기능을 활성화합니다.static_srte_lsp_1

    13단계, 14단계, 15단계를 완료하면 PCC가 세그먼트 라우팅 LSP를 PCE에 위임할 수 있습니다.

  16. 구성을 커밋합니다.

결과

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

디바이스(PCC) 구성을 마쳤으면 구성 모드에서 을 입력합니다 .commit

검증

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

IS-IS 인접성 및 레이블 확인
목적

PCC에서 IS-IS 인접성을 확인합니다. SRGB 레이블 범위, 인접 및 노드 세그먼트 값, SPRING 기능 출력 필드를 기록해 둡니다.

작업

운영 모드에서 , , 명령을 실행합니다.show isis adjacency extensiveshow isis database extensiveshow isis overview

의미

PCC와 PCE 사이의 IS-IS 인접성과 PCC와 라우터 R1 사이의 인접성이 작동 중입니다. 출력에는 인접 세그먼트와 노드 세그먼트에 대한 레이블 할당도 표시됩니다.

트래픽 엔지니어링 데이터베이스 확인
목적

PCC에서 트래픽 엔지니어링 데이터베이스 항목을 확인합니다.

작업

운영 모드에서 show ted database extensive 명령을 실행합니다.

의미

트래픽 엔지니어링 데이터베이스에는 PCE가 PCC의 외부 경로 컴퓨팅에 사용하는 라우터 R1, R2 및 R3에서 보급된 항목이 포함됩니다.

SR-TE LSP 확인
목적

PCC에서 SR-TE LSP 생성을 확인합니다.

작업

운영 모드에서 , , 명령을 실행합니다.show path-computation-client lspshow spring-traffic-engineering lsp detailshow route protocol spring-te

의미

출력 결과, PCE가 인접 및 노드 세그먼트에 대해 각각 두 개의 SR-TE LSP 및 을(를) 생성했음을 보여줍니다.adj_sid_lspnode_sid_lsp

세그먼트 라우팅 LSP 은(는) 위임 기능으로 활성화됩니다.static_srte_lsp_1 필드는 PCE 위임 LSP의 제어 및 라우팅 상태를 보여줍니다. 는 PCE가 LSP를 제어하고 있음을 의미합니다. 는 PCE가 소스 라우팅 경로에 대한 ERO를 제공했음을 나타냅니다. Delegation infoExternally controlledExternally routed

터널 경로 생성 확인
목적

PCC의 inet.3 라우팅 테이블에 포함된 SR-TE LSP에 대해 생성된 터널 경로를 확인합니다.

작업

작동 모드에서 명령을 실행합니다 .show route table inet.3 extensive

의미

SR-TE를 프로토콜 레이블로 사용하여 PCE 제어 LSP 대상에 대한 터널 경로가 생성되었습니다.

포워딩 테이블 항목 확인
목적

라우터 R3에 대한 SR-TE LSP 대상이 PCC의 포워딩 테이블에 설치되었는지 확인합니다.

작업

작동 모드에서 명령을 실행합니다 .show route forwarding-table destination ip-address extensive

의미

라우터 R3에 대한 SR-TE LSP 대상 IP 주소는 포워딩 엔트리로 설치됩니다.

정적 경로 전달을 위한 터널 경로 사용 확인
목적

정적 경로가 SR-TE LSP에 대해 생성된 터널 경로를 사용하는지 확인합니다.

작업

운영 모드에서 및 명령을 실행합니다.show route ip-addressshow route forwarding-table destination ip-address

의미

출력은 라우터 R3에 대한 정적 경로가 SR-TE LSP에 대해 생성된 터널 경로를 사용한다는 것을 보여줍니다.

정적 세그먼트 라우팅 레이블 스위칭 경로

세그먼트 라우팅 아키텍처를 사용하면 코어 네트워크의 수신 디바이스가 명시적 경로를 통해 트래픽을 조정할 수 있습니다. 세그먼트 목록을 사용하여 이러한 경로를 구성하여 수신 트래픽이 거쳐야 하는 경로를 정의할 수 있습니다. 수신 트래픽은 레이블이 지정되거나 IP 트래픽일 수 있으며, 이로 인해 수신 디바이스에서의 전달 작업이 레이블 스왑 또는 대상 기반 조회가 될 수 있습니다.

MPLS 네트워크의 정적 세그먼트 라우팅 LSP 이해

소스 패킷 라우팅 또는 세그먼트 라우팅은 수신 라우터가 실제 경로를 결정하기 위해 네트워크의 중간 노드에 의존하지 않고 네트워크의 특정 노드와 링크 집합을 통해 패킷을 조정할 수 있도록 하는 컨트롤 플레인 아키텍처입니다.

세그먼트 라우팅 LSP 소개

세그먼트 라우팅은 소스 라우팅 패러다임을 활용합니다. 디바이스는 세그먼트라고 하는 정렬된 명령 목록을 통해 패킷을 조정합니다. 세그먼트는 토폴로지 또는 서비스 기반의 모든 명령을 나타낼 수 있습니다. 세그먼트는 세그먼트 라우팅 노드 또는 세그먼트 라우팅 도메인 내의 글로벌 노드에 대한 로컬 의미 체계를 가질 수 있습니다. 세그먼트 라우팅은 세그먼트 라우팅 도메인에 대한 수신 디바이스에서만 플로우당 상태를 유지하면서 모든 토폴로지 경로 및 서비스 체인을 통해 플로우를 적용합니다. 세그먼트 라우팅은 포워딩 플레인의 변경 없이 MPLS 아키텍처에 직접 적용할 수 있습니다. 세그먼트는 MPLS 레이블로 인코딩됩니다. 정렬된 세그먼트 목록은 레이블 스택으로 인코딩됩니다. 처리할 세그먼트는 스택의 맨 위에 있습니다. 세그먼트가 완료되면 관련 레이블이 스택에서 팝업됩니다.

세그먼트 라우팅 LSP는 본질적으로 동적이거나 정적일 수 있습니다.

Dynamic segment routing LSPs—세그먼트 라우팅 LSP가 외부 컨트롤러에 의해 생성되고 PCEP(Path Computation Element Protocol) 확장을 통해 수신 디바이스로 다운로드되거나 BGP 세그먼트 라우팅 정책에서 BGP 세그먼트 라우팅 확장을 통해 다운로드되면 LSP가 동적으로 프로비저닝됩니다. 동적 세그먼트 라우팅 LSP의 세그먼트 목록은 PCEP 명시적 경로 객체(ERO) 또는 LSP의 BGP 세그먼트 라우팅 정책에 포함되어 있습니다.

Static segment routing LSPs- 세그먼트 라우팅 LSP가 로컬 구성을 통해 수신 디바이스에서 생성되면 LSP가 정적으로 프로비저닝됩니다.

정적 세그먼트 라우팅 LSP는 계층 수준에서 명령문의 구성에 따라 컬러 LSP와 비컬러 LSP로 더 분류될 수 있습니다.color[edit protocols source-packet-routing source-routing-path lsp-name]

예:

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

여기서 각 1차 및 2차 명령문은 세그먼트 목록을 참조합니다.

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

세그먼트 라우팅 LSP 사용의 이점

  • 정적 세그먼트 라우팅은 전송 라우터의 LSP 포워딩 상태에 의존하지 않습니다. 따라서 코어에서 LSP 포워딩 상태당 프로비저닝 및 유지 관리할 필요가 없습니다.

  • MPLS 네트워크에 더 높은 확장성을 제공합니다.

컬러 정적 세그먼트 라우팅 LSP

명령문으로 구성된 정적 세그먼트 라우팅 LSP를 컬러 LSP라고 합니다.color

컬러 정적 세그먼트 라우팅 LSP 이해

BGP 세그먼트 라우팅 정책과 유사하게, 색상이 지정된 LSP의 수신 경로는 IP 트래픽 매핑을 위한 키로 또는 라우팅 테이블에 설치됩니다.inetcolor.0inet6color.0destination-ip-address, color

정적 색상의 세그먼트 라우팅 LSP에는 라우팅 테이블에 경로가 설치된 바인딩 SID가 있을 수 있습니다 .mpls.0 이 바인딩 SID 레이블은 레이블이 지정된 트래픽을 세그먼트 라우팅 LSP에 매핑하는 데 사용됩니다. 경로의 게이트웨이는 기본 및 보조 경로 아래의 세그먼트 목록 구성에서 파생됩니다.

컬러 세그먼트 라우팅 LSP의 세그먼트 목록

색상이 지정된 정적 세그먼트 라우팅 LSP는 이미 LSP를 해결하는 첫 번째 홉 레이블 모드에 대한 지원을 제공합니다. 그러나 첫 번째 홉 IP 모드는 컬러 세그먼트 라우팅 LSP에 대해 지원되지 않습니다. Junos OS 릴리스 19.1R1부터 커밋 확인 기능이 도입되어 컬러 경로에 기여하는 모든 세그먼트 목록이 모든 홉에 대해 존재하는 최소 레이블을 갖도록 합니다. 이 요구 사항이 충족되지 않으면 커밋이 차단됩니다.

무색 정적 세그먼트 라우팅 LSP

명령문 없이 구성된 정적 세그먼트 라우팅 LSP는 색상이 지정되지 않은 LSP입니다.color PCEP 세그먼트 라우팅 터널과 마찬가지로 수신 경로는 또는 라우팅 테이블에 설치됩니다.inet.3inet6.3

Junos OS는 수신 라우터에서 색상이 없는 정적 세그먼트 라우팅 LSP를 지원합니다. 하나의 소스 라우팅 경로와 하나 이상의 세그먼트 목록을 구성하여 색상이 지정되지 않은 정적 세그먼트 라우팅 LSP를 프로비저닝할 수 있습니다. 이러한 세그먼트 목록은 여러 개의 색상이 지정되지 않은 세그먼트 라우팅 LSP에서 사용할 수 있습니다.

색상이 지정되지 않은 세그먼트 라우팅 LSP 이해

색상이 없는 세그먼트 라우팅 LSP에는 고유한 이름과 대상 IP 주소가 있습니다. 대상에 대한 수신 경로는 inet.3 라우팅 테이블에 설치되며 기본 기본 설정은 8이고 메트릭은 1입니다. 이 경로를 사용하면 색상이 지정되지 않은 서비스를 대상과 관련된 세그먼트 라우팅 LSP에 매핑할 수 있습니다. 색상이 지정되지 않은 세그먼트 라우팅 LSP에 수신 경로가 필요하지 않은 경우 수신 경로를 비활성화할 수 있습니다. 색상이 없는 세그먼트 라우팅 LSP는 바인딩 SID 레이블을 사용하여 세그먼트 라우팅 LSP 스티칭을 달성합니다. 세그먼트 라우팅 LSP를 계층적 방식으로 다른 세그먼트 라우팅 LSP를 구성하는데 추가로 사용될 수 있는 세그먼트로서 모델링하는데 사용될 수 있는 이 레이블. 바인딩 SID 레이블의 전송은 기본적으로 8의 기본 설정과 1의 메트릭을 갖습니다.

Junos OS 릴리스 18.2R1부터 수신 디바이스에서 정적으로 구성된 무색 세그먼트 라우팅 LSP는 PCEP(Path Computation Element Protocol) 세션을 통해 PCE(Path Computation Element)에 보고됩니다. 이러한 색상이 없는 세그먼트 라우팅 LSP에는 연결된 바인딩 서비스 식별자(SID) 레이블이 있을 수 있습니다. 이 기능을 통해 PCE는 레이블 스택에서 이 바인딩 SID 레이블을 사용하여 PCE 시작 세그먼트 라우팅 LSP 경로를 프로비저닝할 수 있습니다.

색상이 없는 세그먼트 라우팅 LSP는 최대 8개의 기본 경로를 가질 수 있습니다. 여러 운영 기본 경로가 있는 경우 패킷 전달 엔진(PFE)은 경로에 구성된 가중치와 같은 로드 밸런싱 요소를 기반으로 경로를 통해 트래픽을 분산합니다. 가중치가 구성된 경로가 없는 경우 ECMP(Equal Cost Multi Path)가 되고, 경로 중 하나 이상의 경로에 0이 아닌 가중치가 구성된 경우 가중치가 부여된 ECMP입니다. 두 경우 모두 하나 또는 일부 경로에 장애가 발생하면 PFE는 나머지 경로에 트래픽을 재조정하여 자동으로 경로 보호를 달성합니다. 색상이 지정되지 않은 세그먼트 라우팅 LSP는 전용 경로 보호를 위한 보조 경로를 가질 수 있습니다. 기본 경로에 장애가 발생하면 PFE는 트래픽을 나머지 기능적 기본 경로로 재조정합니다. 그렇지 않으면 PFE가 트래픽을 백업 경로로 전환하여 경로 보호를 달성합니다. 색상이 지정되지 않은 세그먼트 라우팅 LSP는 수신 및 바인딩 SID 경로에 대한 메트릭 을 지정할 수 있습니다.[edit protocols source-packet-routing source-routing-path lsp-name] 여러 개의 색상이 지정되지 않은 세그먼트 라우팅 LSP는 수신 경로의 다음 홉에 기여하는 동일한 목적지 주소를 갖습니다.

여러 개의 색상이 지정되지 않은 세그먼트 라우팅 LSP는 수신 경로의 다음 홉에 기여하는 동일한 목적지 주소를 갖습니다. 경로가 작동하고 세그먼트 라우팅 LSP가 이러한 모든 세그먼트 라우팅 LSP 중에서 가장 선호되는 경우, 각 세그먼트 라우팅 LSP의 기본 또는 보조 경로마다 게이트웨이 후보로 간주됩니다. 그러나 다음 홉이 보유할 수 있는 최대 게이트웨이 수는 RPD 다중 경로 제한(기본적으로 128개)을 초과할 수 없습니다. 추가 경로가 정리되며, 먼저 보조 경로와 기본 경로가 정리됩니다. 주어진 세그먼트 목록은 이러한 세그먼트 라우팅 LSP에 의해 기본 또는 보조 경로로 여러 번 참조될 수 있습니다. 이 경우, 각각 고유한 세그먼트 라우팅 LSP 터널 ID를 갖는 여러 게이트웨이가 있습니다. 이러한 게이트웨이는 동일한 발신 레이블 스택과 인터페이스를 가지고 있지만 서로 다릅니다. 색상이 지정되지 않은 세그먼트 라우팅 LSP와 색상이 지정된 세그먼트 라우팅 LSP는 동일한 목적지 주소를 가질 수도 있습니다. 그러나 컬러 세그먼트 라우팅 LSP의 목적지 주소는 목적지 주소와 색상 모두로 구성되므로 수신 경로의 다른 목적지 주소에 해당합니다.

주:

색상이 지정되지 않은 정적 세그먼트 라우팅 LSP와 PCEP에서 생성한 세그먼트 라우팅 LSP가 공존하고 동일한 수신 경로에 기여하는 동일한 TO ADDRESS(TO 주소)가 동일한 경우, 이들도 동일한 선호도를 가지고 있는 경우. 그렇지 않으면 가장 선호되는 세그먼트 라우팅 LSP가 경로에 설치됩니다.

색상이 지정되지 않은 세그먼트 라우팅 LSP의 세그먼트 목록

세그먼트 목록은 홉 목록으로 구성됩니다. 이러한 홉은 SID 레이블 또는 IP 주소를 기반으로 합니다. 세그먼트 목록의 SID 레이블 수는 최대 세그먼트 목록 제한을 초과해서는 안 됩니다. LSP 터널에 대한 최대 세그먼트 목록 바인딩이 8개에서 128개로 증가했으며 시스템당 최대 1000개의 터널이 있습니다. 정적 세그먼트 라우팅 LSP당 최대 128개의 기본 경로가 지원됩니다. 계층 수준에서 최대 세그먼트 목록 제한을 구성할 수 있습니다.[edit protocols source-packet-routing]

Junos OS 릴리스 19.1R1 이전에는 색상이 없는 정적 세그먼트 라우팅 LSP를 사용하려면 세그먼트 목록의 첫 번째 홉이 나가는 인터페이스의 IP 주소여야 하고 두 번째에서 번째 홉은 SID 레이블이 될 수 있습니다.n Junos OS 릴리스 19.1R1부터는 무색 정적 LSP의 첫 번째 홉이 이제 IP 주소 외에도 SID 레이블에 대한 지원을 제공하므로 이 요구 사항이 적용되지 않습니다. 첫 번째 홉 레이블 지원으로, 색상이 지정된 정적 LSP와 유사하게 정적 비색상 세그먼트 라우팅 LSP를 해결하기 위해 MPLS FRR(Fast Reroute) 및 가중 동일 비용 다중 경로가 활성화됩니다.

첫 번째 홉 레이블 모드가 적용되려면 세그먼트 목록에 대해 문을 전역적으로 또는 개별적으로 포함해야 하며, 세그먼트 목록의 첫 번째 홉에는 IP 주소와 레이블이 모두 포함되어야 합니다.inherit-label-nexthops 첫 번째 홉에 IP 주소만 포함된 경우 문은 아무런 영향을 미치지 않습니다.inherit-label-nexthops

다음 계층 중 하나에서 구성할 수 있습니다.inherit-label-nexthops 문은 세그먼트 목록 첫 번째 홉에 IP 주소와 레이블이 모두 포함된 경우에만 적용됩니다.inherit-label-nexthops

  • - 계층 수준에서 .Segment list level[edit protocols source-packet-routing segment-list segment-list-name]

  • - 계층 수준에서 .Globally[edit protocols source-packet-routing]

문이 전역으로 구성되면 segment-list 수준 구성보다 우선하며 모든 세그먼트 목록에 구성이 적용됩니다.inherit-label-nexthopsinherit-label-nexthops 문이 전역으로 구성되지 않으면 첫 번째 홉에 레이블과 IP 주소가 모두 있고 문으로 구성된 세그먼트 목록만 SID 레이블을 사용하여 확인됩니다.inherit-label-nexthopsinherit-label-nexthops

PCEP 기반 세그먼트 라우팅 LSP인 동적 무색 정적 LSP의 경우, 세그먼트 수준 구성이 적용되지 않으므로 문을 전역적으로 활성화해야 합니다.inherit-label-nexthops

표 4 은(는) 첫 번째 홉 사양을 기반으로 세그먼트 라우팅 LSP 확인 모드를 설명합니다.

표 4: 첫 번째 홉 사양을 기반으로 하는 무색 정적 LSP 해상도

첫 번째 홉 사양

LSP 해상도 모드

IP 주소만

예:

segment-list path-1 {
    hop-1 ip-address 172.16.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

세그먼트 목록은 IP 주소를 사용하여 확인됩니다.

SID만

예:

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

세그먼트 목록은 SID 레이블을 사용하여 확인됩니다.

IP 주소 및 SID(구성 제외 )inherit-label-nexthops

예:

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

기본적으로 세그먼트 목록은 IP 주소를 사용하여 확인됩니다.

IP 주소 및 SID(구성 포함 )inherit-label-nexthops

예:

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

세그먼트 목록은 SID 레이블을 사용하여 확인됩니다.

명령을 사용하여 inet.3 라우팅 테이블에 설치된 여러 세그먼트 목록이 있는 비컬러 세그먼트 라우팅 트래픽 엔지니어링 LSP를 볼 수 있습니다.show route ip-address protocol spring-te active-path table inet.3

예:

주:

다음과 같은 경우 정적 세그먼트 라우팅 LSP의 세그먼트 목록의 첫 번째 홉 유형으로 인해 커밋이 실패할 수 있습니다.

  • 터널의 세그먼트 목록마다 첫 번째 홉 확인 유형이 다릅니다. 이는 컬러 및 비컬러 정적 세그먼트 라우팅 LSP 모두에 적용됩니다. 그러나 이는 PCEP 기반 LSP에는 적용되지 않습니다. 경로 계산 시 첫 번째 홉 확인 유형의 불일치에 대해 시스템 로그 메시지가 생성됩니다.

    예:

    path-1은 IP 주소 모드이고 path-2는 레이블 모드이므로 터널 커밋이 실패합니다.lsp1

  • 바인딩 SID는 세그먼트 목록 유형이 SID 레이블인 정적 비색 LSP에 대해 활성화됩니다.

    예:

    레이블 세그먼트 목록을 통해 바인딩 SID를 구성하는 것은 색상이 지정된 정적 LSP에 대해서만 지원되며 색상이 지정되지 않은 정적 LSP에 대해서는 지원되지 않습니다.

정적 세그먼트 라우팅 LSP 프로비저닝

세그먼트 프로비저닝은 라우터별로 수행됩니다. 라우터의 특정 세그먼트에 대해 고유한 서비스 식별자(SID) 레이블은 인접 SID 레이블에 대한 동적 레이블 풀 또는 접두사 SID 또는 노드 SID에 대한 세그먼트 라우팅 글로벌 블록(SRGB)에서 할당될 수 있는 원하는 레이블 풀에서 할당됩니다. 인접 SID 레이블은 기본 동작인 동적으로 할당하거나 로컬 정적 레이블 풀(SRLB)에서 할당할 수 있습니다. 그런 다음 SID 레이블에 대한 경로가 mpls.0 테이블에 설치됩니다.

Junos OS는 계층 수준에서 문을 구성 하여 정적 세그먼트 라우팅 LSP를 허용합니다.segment[edit protocols mpls static-label-switched-path static-label-switched-path] 정적 세그먼트 LSP는 Junos OS 정적 레이블 풀에 속하는 고유한 SID 레이블로 식별됩니다. 계층 수준에서 문을 구성 하여 Junos OS 정적 레이블 풀을 구성할 수 있습니다.static-label-range static-label-range[edit protocols mpls label-range]

정적 세그먼트 라우팅 LSP 제한 사항

  • Junos OS는 현재 최대 세그먼트 목록 깊이 레이블 이상을 푸시하기 위해 다음 홉을 구축할 수 없다는 제한이 있습니다. 따라서 최대 SID 레이블(포워딩 다음 홉을 해결하는 데 사용되는 첫 번째 홉의 SID 레이블 제외)을 초과하는 세그먼트 목록은 컬러 또는 비컬러 세그먼트 라우팅 LSP에 사용할 수 없습니다. 또한 MPLS 서비스가 세그먼트 라우팅 LSP에 있거나 세그먼트 라우팅 LSP가 링크 또는 노드 보호 경로에 있는 경우 주어진 세그먼트 라우팅 LSP에 허용되는 실제 수는 최대 제한보다 훨씬 낮을 수 있습니다. 모든 경우에 서비스 레이블, SID 레이블 및 링크 또는 노드 보호 레이블의 총 수는 최대 세그먼트 목록 깊이를 초과해서는 안 됩니다. 계층 수준에서 최대 세그먼트 목록 제한을 구성할 수 있습니다.[edit protocols source-packet-routing] 최대 SID 레이블보다 작거나 같은 여러 개의 색상이 없는 세그먼트 라우팅 LSP를 함께 연결하여 더 긴 세그먼트 라우팅 LSP를 구성할 수 있습니다. 이를 세그먼트 라우팅 LSP 스티칭이라고 합니다. 바인딩-SID 레이블을 사용하여 달성할 수 있습니다.

  • 세그먼트 라우팅 LSP 스티칭은 실제로 경로 수준에서 수행됩니다. 색상이 지정되지 않은 세그먼트 라우팅 LSP에 여러 세그먼트 목록인 여러 경로가 있는 경우, 각 경로는 연결 지점에서 다른 색상이 아닌 세그먼트 라우팅 LSP에 독립적으로 연결될 수 있습니다. 연결 전용 색상이 아닌 세그먼트 라우팅 LSP는 계층 수준에서 문을 구성 하여 수신 경로 설치를 비활성화할 수 있습니다.no-ingress[edit protocols source-packet-routing source-routing-path lsp-name]

  • 색상이 지정되지 않은 정적 세그먼트 라우팅 LSP당 최대 128개의 기본 경로와 1개의 보조 경로가 지원됩니다. 구성에 위반이 있는 경우, 커밋 검사가 실패하고 오류가 발생합니다.

  • LSP 터널에 대한 최대 세그먼트 목록 바인딩이 8개에서 128개로 증가했으며 시스템당 최대 1000개의 터널이 있습니다. 정적 세그먼트 라우팅 LSP당 최대 128개의 기본 경로가 지원됩니다. 제한 사항으로, LSP 경로에 대한 최대 센서 지원은 32000입니다.

  • segment-list가 최대 세그먼트 목록 깊이보다 더 많은 레이블로 구성된 경우 구성 커밋 검사가 오류와 함께 실패합니다.

세그먼트 라우팅 LSP의 동적 생성

각 프로바이더 에지(PE) 디바이스가 다른 모든 PE 디바이스에 연결된 세그먼트 라우팅 네트워크에서는 소수의 세그먼트 라우팅 트래픽 엔지니어링(SR-TE) 경로만 사용될 수 있지만 세그먼트 라우팅 LSP(레이블 전환 경로)를 설정하는 데 많은 양의 구성이 필요합니다. 이러한 LSP의 BGP 트리거 동적 생성을 활성화하여 이러한 구축에서 구성의 양을 줄일 수 있습니다.

동적 세그먼트 라우팅 LSP 템플릿 구성

세그먼트 라우팅 LSP의 동적 생성을 활성화하기 위한 템플릿을 구성하려면 계층 구조에 명령문을 spring-te 포함해야 합니다.spring-te (Dynamic Tunnels)[edit routing-options dynamic-tunnels]

  • 다음은 컬러 동적 세그먼트 라우팅 LSP 템플릿에 대한 샘플 구성입니다.

  • 다음은 비색상 동적 세그먼트 라우팅 LSP 템플릿에 대한 샘플 구성입니다.

동적 세그먼트 라우팅 LSP 해결
컬러 동적 세그먼트 라우팅 LSP 해결

BGP 접두사가 색상 커뮤니티로 할당되면 처음에는 catch-all-route-for-that–particular-color 정책을 통해 해결되고, BGP 접두사를 확인해야 하는 SR-TE 템플릿이 식별됩니다. 그런 다음 대상 SID는 BGP 페이로드 접두사 다음 홉 속성에서 파생됩니다. 예를 들어, BGP 페이로드 접두사의 다음 홉이 디바이스 A에 속하는 IP 주소인 경우, 디바이스 A의 노드-SID가 생성되고 해당 레이블이 준비되어 스택의 맨 아래로 푸시됩니다. BGP 페이로드 접두사는 색상 전용 모드에서 해결되며, 디바이스 A의 노드-SID는 최종 레이블 스택의 맨 아래에 있고 SR-TE 경로 레이블은 맨 위에 있습니다.

최종 LSP 템플릿 이름은 접두사, 색상 및 터널 이름의 조합입니다. 예를 들어, .<prefix>:<color>:dt-srte-<tunnel-name> LSP 이름의 색상은 16진수 형식으로 표시되며 터널 이름의 형식은 RSVP 트리거 터널 LSP 이름과 유사합니다.

색이 지정된 대상 네트워크를 성공적으로 해결하려면 색에 특정 색으로 또는 템플릿을 통해 유효한 템플릿 매핑이 있어야 합니다.color-any 유효한 매핑이 없으면 터널이 생성되지 않고 해결을 요청하는 BGP 경로가 확인되지 않은 상태로 유지됩니다.

컬러링되지 않은 동적 세그먼트 라우팅 LSP 해결

색상이 지정되지 않은 LSP에 대한 catch-all 경로가 inet.3 라우팅 테이블에 추가됩니다. 색상이 지정되지 않은 터널 대상은 매핑 목록에 템플릿 이름이 하나만 있는 다른 구성으로 구성해야 합니다.spring-te 이 템플릿 이름은 동일한 구성으로 구성된 대상 네트워크와 일치하는 모든 터널 경로에 사용됩니다.spring-te 이러한 터널은 기능면에서 RSVP 터널과 유사합니다.

최종 LSP 템플릿 이름은 접두사와 터널 이름의 조합입니다. 예를 들어, .<prefix>:dt-srte-<tunnel-name>

동적 세그먼트 라우팅 LSP 샘플 구성

동적 세그먼트 라우팅 LSP 템플릿은 항상 부분 경로를 전달합니다. 마지막 홉 노드 SID는 프로토콜 다음 홉 주소(PNH) 노드 SID에 따라 터널 생성 시 자동으로 파생됩니다. 동일한 템플릿을 여러 대상에 대한 여러 터널에서 사용할 수 있습니다. 이 경우 부분 경로는 동일하게 유지되며 PNH에 따라 마지막 홉만 변경됩니다. 동적 세그먼트 라우팅 LSP 템플릿은 단일 터널에 공통적이지 않으므로 전체 경로를 전달할 수 없습니다. 전체 경로를 사용할 경우 세그먼트 목록을 사용할 수 있습니다.

컬러 동적 세그먼트 라우팅 LSP

컬러 동적 세그먼트 라우팅 LSP에 대한 샘플 구성:

위에서 언급한 샘플 구성의 경우 경로 항목은 다음과 같습니다.

  1. inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping:

    R1(접두사) -> 10.22.44.55-101(PNH) LSP 터널 이름 = 10.22.44.55:65:dt-srte-tunnel1

  3. inetcolor.0 tunnel route:

    10.22.44.55-101/64 --> &lt;다음 홉>

    10.22.44.55-124/64 --> &lt;다음 홉>

색상이 없는 동적 세그먼트 라우팅 LSP

색상이 지정되지 않은 동적 세그먼트 라우팅 LSP에 대한 샘플 구성:

위에서 언급한 샘플 구성의 경우 경로 항목은 다음과 같습니다.

  1. inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping:

    R1(접두사) -> 10.33.44.55(PNH) LSP 템플릿 이름 = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  3. inet.3 tunnel route: 10.33.44.55/32 --> &lt;다음 홉>

해결되지 않은 동적 세그먼트 라우팅 LSP

해결되지 않은 동적 세그먼트 라우팅 LSP에 대한 샘플 구성:

위에서 언급한 샘플 구성의 경우 경로 항목은 다음과 같습니다.

  1. inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping: R1(접두사) -> 10.33.44.55-124(PNH) 터널이 생성되지 않습니다. (색상에 대한 템플릿을 찾을 수 없음).

세그먼트 라우팅 LSP의 동적 생성 구성을 위한 고려 사항

세그먼트 라우팅 LSP의 동적 생성을 구성할 때 다음 사항을 고려하십시오.

  • 템플릿은 색상 개체와 함께 할당할 수 있습니다. 동적 터널 구성에 색상 객체가 있는 템플릿이 포함된 경우, 색상 객체가 있는 다른 모든 템플릿도 구성해야 합니다.spring-te 모든 대상은 해당 구성 내에서 색상이 지정된 것으로 간주됩니다.

  • 템플릿에는 정의된 색상 목록이 있거나 옵션으로 구성할 수 있습니다.color-any 이 두 옵션은 동일한 구성에서 공존할 수 있습니다.spring-te 이러한 경우 특정 색상으로 할당된 템플릿이 더 높은 선호도를 갖습니다.

  • 구성에서는 하나의 템플릿만 옵션으로 정의할 수 있습니다.spring-tecolor-any

  • 색상-템플릿 매핑은 일대일로 수행됩니다. 하나의 색은 여러 템플릿에 매핑할 수 없습니다.

  • 템플릿 이름은 계층 아래의 문에서 구성해야 하며 옵션을 활성화해야 합니다.spring-te[edit protocols]primary

  • 색상이 지정된 대상과 색상이 지정되지 않은 대상은 동일한 구성에 공존할 수 없습니다.spring-te

  • 서로 다른 구성 문에서 색상 유무에 관계없이 동일한 대상 네트워크를 구성할 수 없습니다.spring-te

  • 색상 이 지정되지 않은 구성에서는 색상 개체 없이 하나의 템플릿만 구성할 수 있습니다.spring-te

동적 세그먼트 라우팅 LSP를 통해 지원되는 서비스

색상이 지정된 동적 세그먼트 라우팅 LSP를 통해 지원되는 서비스는 다음과 같습니다.

  • 레이어 3 VPN

  • BGP EVPN

  • 정책 서비스 내보내기

다음 서비스는 색상이 지정되지 않은 동적 세그먼트 라우팅 LSP를 통해 지원됩니다.

  • 레이어 3 VPN

  • Layer 2 VPN

  • 다중 경로 구성

세그먼트 라우팅에서 여러 터널 소스의 동작

두 소스가 세그먼트 라우팅(예: 정적 및 동적 소스 터널)에서 동일한 대상으로 경로를 다운로드하면 세그먼트 라우팅 기본 설정이 활성 경로 항목을 선택하는 데 사용됩니다. 값이 높을수록 선호도가 높습니다. 기본 설정이 동일하게 유지되는 경우 터널 소스를 사용하여 경로 항목을 결정합니다.

동적 세그먼트 라우팅 LSP 제한 사항

동적 SR-TE LSP는 다음과 같은 특징과 기능을 지원하지 않습니다.

  • IPv6 세그먼트 라우팅 터널.

  • 정적 터널.

  • 6PE는 지원되지 않습니다.

  • 분산 CSPF.

  • sBFD 및 LDP 터널링은 동적 SR-TE LSP 및 템플릿에서 지원되지 않습니다.

  • 템플릿에 B-SID 경로를 설치합니다.

VPN 서비스의 색상 기반 매핑

정적 색상의 BGP 세그먼트 라우팅 트래픽 엔지니어링(SR-TE) LSP를 통해 전송 터널을 해결하기 위해 색상을 프로토콜 다음 홉 제약 조건(IPv4 또는 IPv6 주소 외에)으로 지정할 수 있습니다. 이를 color-IP 프로토콜 다음 홉 확인이라고 하며, 여기서 resolution-map을 구성하고 VPN 서비스에 적용해야 합니다. 이 기능을 사용하면 레이어 2 및 레이어 3 VPN 서비스의 색상 기반 트래픽 스티어링을 활성화할 수 있습니다.

Junos OS는 단일 색상과 관련된 컬러 SR-TE LSP를 지원합니다. VPN 서비스 기능의 색상 기반 매핑은 정적 색상의 LSP 및 BGP SR-TE LSP에서 지원됩니다.

VPN 서비스 컬러링

일반적으로 VPN NLRI가 광고되는 송신 라우터 또는 VPN NLRI가 수신 및 처리되는 수신 라우터에서 VPN 서비스에 색상이 할당될 수 있습니다.

다양한 수준에서 VPN 서비스에 색상을 할당할 수 있습니다.

  • 라우팅 인스턴스당.

  • BGP 그룹당.

  • BGP 인접 라우터당.

  • 접두사당.

색상을 할당하면 색상이 BGP 색상 확장 커뮤니티 형태로 VPN 서비스에 연결됩니다.

다중 색상 VPN 서비스라고 하는 VPN 서비스에 여러 색상을 할당할 수 있습니다. 이러한 경우 마지막으로 첨부된 색상은 VPN 서비스의 색상으로 간주되며 다른 모든 색상은 무시됩니다.

송신 및/또는 수신 디바이스는 여러 정책을 통해 다음 순서로 여러 색상을 할당합니다.

  • 송신 디바이스에 대한 BGP 내보내기 정책.

  • 수신 디바이스에 대한 BGP 가져오기 정책.

  • 수신 디바이스의 VRF 가져오기 정책.

VPN 서비스 컬러링의 두 가지 모드는 다음과 같습니다.

송신 색상 할당

이 모드에서는 송신 디바이스(즉, VPN NLRI의 광고주)가 VPN 서비스의 색상을 지정합니다. 이 모드를 활성화하기 위해 라우팅 정책을 정의하고 계층 수준에서 VPN 서비스의 routing-instance , 그룹 내보내기 또는 그룹 이웃 내보내기 에 적용할 수 있습니다.vrf-export[edit protocols bgp] VPN NLRI는 지정된 색상 확장 커뮤니티를 통해 BGP에 의해 보급됩니다.

예:

또는

주:

라우팅 정책을 BGP 그룹 또는 BGP 인접 라우터의 내보내기 정책으로 적용할 때 정책이 VPN NLRI에 영향을 미치려면 BGP, BGP 그룹 또는 BGP 인접 수준에 문을 포함해야 합니다.vpn-apply-export

라우팅 정책은 레이어 3 VPN 접두사 NLRI, 레이어 2 VPN NRLI 및 EVPN NLRI에 적용됩니다. 색상 확장 커뮤니티는 모든 VPN 경로에 상속되며, 하나 또는 여러 수신 디바이스의 대상 VRF에서 가져와 설치됩니다.

수신 색상 지정

이 모드에서는 수신 디바이스(즉, VPN NLRI의 수신자)가 VPN 서비스의 색상을 지정합니다. 이 모드를 활성화하려면 라우팅 정책을 정의하고 계층 수준에서 VPN 서비스의 routing-instance , 그룹 가져오기 또는 그룹 이웃 가져오기에 적용할 수 있습니다.vrf-import[edit protocols bgp] 라우팅 정책과 일치하는 모든 VPN 경로는 지정된 색상의 확장 커뮤니티에 연결됩니다.

예:

또는

VPN 서비스 매핑 모드 지정

유연한 VPN 서비스 매핑 모드를 지정하려면 명령문을 사용하여 정책을 정의하고 계층 수준에서 VPN 서비스의 routing-instance , 그룹 가져오기 또는 그룹 이웃 가져오기에서 정책을 참조해야 합니다.resolution-mapvrf-import[edit protocols bgp] 라우팅 정책과 일치하는 모든 VPN 경로는 지정된 해상도 맵으로 연결됩니다.

예:

VPN 서비스의 라우팅 인스턴스에 가져오기 정책을 적용할 수 있습니다.

BGP 그룹 또는 BGP 인접 라우터에 가져오기 정책을 적용할 수도 있습니다.

주:

각 VPN 서비스 매핑 모드에는 해상도 맵에 정의된 고유한 이름이 있어야 합니다. 해상도 맵에서는 IP-color의 단일 항목만 지원되며, 여기서 VPN 경로는 색상 지정된 IP 프로토콜 다음 홉을 사용하여 확인됩니다.ip-address:color

Color-IP 프로토콜 다음 홉 해상도

프로토콜 다음 홉 확인 프로세스가 컬러 IP 프로토콜 다음 홉 확인을 지원하도록 향상되었습니다. 컬러 VPN 서비스의 경우, 프로토콜 다음 홉 확인 프로세스는 컬러 및 해상도 맵을 사용하여 의 형태로 컬러 IP 프로토콜 다음 홉을 구축하고, inet6color.0 라우팅 테이블에서 프로토콜 다음 홉을 확인합니다.IP-address:color

색상이 지정된 LSP를 통해 색상이 지정된 레이어 2 VPN, 레이어 3 VPN 또는 EVPN 서비스의 다중 경로 확인을 지원하는 정책을 구성해야 합니다. 그런 다음 해결 프로그램 가져오기 정책으로 관련 RIB 테이블과 함께 정책을 적용해야 합니다.

예:

IP 프로토콜 다음 홉 확인으로 폴백

색상이 지정된 VPN 서비스에 해상도 맵이 적용되지 않은 경우 VPN 서비스는 색상을 무시하고 IP 프로토콜 다음 홉 해상도로 폴백합니다. 반대로, 색상이 지정되지 않은 VPN 서비스에 해상도 맵이 적용된 경우 해상도 맵은 무시되고 VPN 서비스는 IP 프로토콜 다음 홉 확인을 사용합니다.

폴백은 LDP용 RIB 그룹을 사용하여 inet{6}color.0 라우팅 테이블에 경로를 설치함으로써 컬러 SR-TE LSP에서 LDP LSP로 이동하는 간단한 프로세스입니다. 컬러 IP 프로토콜 다음 홉에 대한 가장 긴 접두사 일치는 컬러 SR-TE LSP 경로가 존재하지 않는 경우 일치하는 IP 주소를 가진 LDP 경로가 반환되도록 합니다.

SR-TE를 통한 BGP labeled unicast 색상 기반 매핑

Junos OS 릴리스 20.2R1부터 BGP 레이블 유니캐스트(BGP-LU)는 IPv4 및 IPv6 주소 패밀리 모두에 대해 SR-TE(세그먼트 라우팅-트래픽 엔지니어링)를 통해 IPv4 또는 IPv6 경로를 확인할 수 있습니다. BGP-LU는 BGP 커뮤니티 색상 매핑 및 SR-TE에 대한 정의를 지원합니다.resolution map 컬러 프로토콜 다음 홉이 구성되고 또는 테이블의 컬러 SR-TE 터널 에서 해결됩니다.inetcolor.0inet6color.0 BGP는 색상 기반이 아닌 매핑에 및 테이블을 사용합니다.inet.3inet6.3 이를 통해 라우터에 IPv4 주소가 구성되지 않은 IPv6 전용 네트워크에서 IPv6 다음 홉 주소를 사용하여 BGP-LU IPv6 및 IPv4 접두사를 보급할 수 있습니다. 이 기능을 통해 현재 IS-IS 언더레이가 있는 SR-TE를 통한 BGP IPv6 LU를 지원합니다.

에서 컨트롤러는 SR-TE로 구성된 IPv6 코어 네트워크에서 4가지 색상의 터널을 구성합니다.그림 9 색상이 지정된 각 터널은 정의된 해상도 맵에 따라 대상 라우터 D에 대해 서로 다른 경로를 사용합니다. 컨트롤러는 라우터 D의 2001:db8::3701:2d05 인터페이스에 컬러 SR-TE 터널을 구성합니다. BGP는 정책을 가져와 수신된 접두사 2001:db8::3700:6/128에 색상 및 해상도 맵을 할당합니다. 할당된 커뮤니티 색상을 기반으로 BGP-LU는 할당된 해상도 맵 정책에 따라 BGP IPv6 LU 접두사에 대해 색상이 지정된 다음 홉을 확인합니다.

그림 9: 컬러 IPv6 SR-TE를 통한 BGP IPv6 LU컬러 IPv6 SR-TE를 통한 BGP IPv6 LU

BGP-LU는 다음과 같은 시나리오를 지원합니다.

  • ISIS/OSPF IPv4 SR 확장이 있는 컬러 BGP IPv4 SR-TE를 통한 BGP IPv4 LU.

  • 정적 컬러 및 비컬러 IPv4 SR-TE를 통한 BGP IPv4 LU, ISIS/OSPF IPv4 SR 확장 포함.

  • ISIS IPv6 SR 확장을 사용하여 색상이 지정된 BGP IPv6 SR-TE를 통한 BGP IPv6 LU.

  • 정적 컬러 및 비컬러 IPv6 SR-TE를 통한 BGP IPv6 LU, ISIS IPv6 SR 확장 포함.

  • IPv6 로컬 주소 및 IPv6 인접 주소를 사용하는 IPv6 레이어 3 VPN 서비스.

  • ISIS IPv6 SR 확장을 사용하는 BGP IPv6 SR-TE를 통한 IPv6 레이어 3 VPN 서비스.

  • 정적 색상 및 비색상 IPv6 SR-TE를 통한 IPv6 레이어 3 VPN 서비스, ISIS IPv6 SR 확장 사용.

VPN 서비스의 색상 기반 매핑에 지원되는 기능 및 지원되지 않는 기능

다음과 같은 특징과 기능은 VPN 서비스의 색상 기반 매핑에서 지원됩니다.

  • BGP 레이어 2 VPN(Kompella 레이어 2 VPN)

  • BGP EVPN

  • 단일 IP 색상 옵션이 있는 해상도 맵.

  • IPv4 및 IPv6 프로토콜의 다음 홉 확인이 색칠되어 있습니다.

  • inetcolor.0 라우팅 테이블의 LDP LSP에 대한 라우팅 정보 기반(라우팅 테이블이라고도 함) 그룹 기반 폴백.

  • 컬러 SR-TE LSP.

  • 가상 플랫폼.

  • 64비트 Junos OS.

  • 논리적 시스템.

  • BGP 레이블이 지정된 유니캐스트.

다음 기능은 VPN 서비스의 색상 기반 매핑에서 지원되지 않습니다.

  • RSVP, LDP, BGP-LU, 정적과 같은 컬러 MPLS LSP.

  • 레이어 2 서킷

  • FEC-129 BGP 자동 검색 및 LDP 신호 레이어 2 VPN.

  • VPLS

  • 증권 시세 표시기

  • resolution-map을 사용하는 IPv4 및 IPv6.

PCE 시작 세그먼트 라우팅 LSP를 위한 터널 템플릿

PCE 시작 세그먼트 라우팅 LSP에 대한 터널 템플릿을 구성하여 이러한 LSP에 대한 두 가지 추가 매개 변수인 BFD(Bidirectional Forwarding Detection) 및 LDP 터널링을 전달할 수 있습니다.

PCE 시작 세그먼트 라우팅 LSP가 생성될 때 LSP는 정책 문(있는 경우)에 대해 확인되며, 일치하는 항목이 있는 경우 정책은 해당 LSP에 대해 구성된 템플릿을 적용합니다. 템플릿 구성은 LSP 소스(PCEP)에서 제공하지 않는 경우에만 상속됩니다. 예를 들어 메트릭입니다.

템플릿 구성 방법:

  1. 계층 수준에서 source-routing-path-template 문을 포함합니다.source-routing-path-template[edit protocols source-packet-routing] 여기에서 추가 BFD 및 LDP 터널링 매개 변수를 구성할 수 있습니다.

  2. PCE 시작 LSP를 확인해야 하는 정책 문을 나열하려면 계층 수준에 source-routing-path-template-map 문을 포함합니다.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/source-routing-path-template-map-edit-protocols-source-packet-routing.html[edit protocols source-packet-routing]

  3. 템플릿을 적용해야 하는 LSP를 나열하는 정책을 정의합니다.

    명령문은 및 일치 조건을 사용하는 LSP 이름 또는 LSP 정규 표현식을 포함할 수 있습니다.fromlsplsp-regex 이러한 옵션은 함께 사용할 수 없으므로 특정 시점에 하나의 옵션만 지정할 수 있습니다.

    문에는 수락 동작이 있는 옵션이 포함되어야 합니다.thensr-te-template 이렇게 하면 PCE 시작 LSP에 템플릿이 적용됩니다.

PCE 시작 LSP에 대한 템플릿을 구성할 때 다음 사항을 고려하십시오.

  • 템플릿 구성은 정적으로 구성된 세그먼트 라우팅 LSP 또는 다른 클라이언트의 세그먼트 라우팅 LSP에는 적용되지 않습니다.

  • PCEP 제공 구성이 템플릿 구성보다 우선합니다.

  • PCEP LSP는 템플릿 세그먼트 목록 구성을 상속하지 않습니다.

예: 정적 세그먼트 라우팅 레이블 스위칭 경로 구성

이 예는 MPLS 네트워크에서 정적 세그먼트 라우팅 레이블 전환 경로(LSP)를 구성하는 방법을 보여줍니다. 이 구성은 MPLS 네트워크에 더 높은 확장성을 제공하는 데 도움이 됩니다.

요구 사항

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

  • 7개의 MX 시리즈 5G 유니버설 라우팅 플랫폼

  • 모든 라우터에서 실행되는 Junos OS 릴리스 18.1 또는 이후 버전

시작하기 전에 디바이스 인터페이스를 구성해야 합니다.

개요

명시적 세그먼트 라우팅 경로 집합인 Junos OS는 계층 수준에서 명령문을 구성 하여 색상이 없는 정적 세그먼트 라우팅 터널의 수신 라우터에 구성됩니다.segment-list[edit protocols source-packet-routing] 계층 수준에서 문을 구성하여 세그먼트 라우팅 터널을 구성할 수 있습니다.source-routing-path[edit protocols source-packet-routing] 세그먼트 라우팅 터널에는 대상 주소와 하나 이상의 기본 경로 및 세그먼트 목록을 참조하는 선택적으로 보조 경로가 있습니다. 각 세그먼트 목록은 일련의 홉으로 구성됩니다. 색상이 지정되지 않은 정적 세그먼트 라우팅 터널의 경우 세그먼트 목록의 첫 번째 홉은 바로 다음 홉 IP 주소를 지정하고 두 번째에서 N번째 홉은 경로가 통과하는 링크 또는 노드에 해당하는 세그먼트 식별(SID) 레이블을 지정합니다. 세그먼트 라우팅 터널의 대상에 대한 경로는 inet.3 테이블에 설치됩니다.

토폴로지

이 예에서는 공급자 에지 라우터 PE1 및 PE5에서 계층 3 VPN을 구성합니다. 모든 라우터에서 MPLS 프로토콜을 구성합니다. 세그먼트 라우팅 터널은 라우터 PE1 및 라우터 PE5에 구성된 기본 경로를 사용하여 라우터 PE1에서 라우터 PE5로 구성됩니다. 라우터 PE1은 경로 보호를 위해 보조 경로로도 구성됩니다. 전송 라우터 PE2에서 PE4는 레이블 팝과 발신 인터페이스가 있는 인접 SID 레이블로 구성됩니다.

그림 10: 정적 세그먼트 라우팅 레이블 스위칭 경로정적 세그먼트 라우팅 레이블 스위칭 경로

구성

CLI 빠른 구성

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

디바이스 PE1 구성하기
단계별 절차

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

디바이스 PE1 구성:

  1. 인터페이스를 구성합니다.

  2. 패킷 전달 라우팅 옵션을 제어하기 위한 자율 시스템 번호 및 옵션을 구성합니다.

  3. MPLS 프로토콜로 인터페이스를 구성하고 MPLS 레이블 범위를 구성합니다.

  4. 업데이트에서 NLRI에 대한 피어 그룹 유형, 로컬 주소, 프로토콜 제품군 및 피어 그룹에 대한 인접 라우터의 IP 주소를 구성합니다.

  5. 프로토콜 영역 인터페이스를 구성합니다.

  6. 프로토콜 소스 패킷 라우팅(SPRING)의 소스 라우팅-트래픽 엔지니어링(TE) 정책을 위한 기본 및 보조 경로의 IPv4 주소와 레이블을 구성합니다.

  7. 프로토콜 SPRING에 대한 대상 IPv4 주소, 바인딩 SID 레이블, 기본 및 보조 소스 라우팅 경로를 구성합니다.

  8. 정책 옵션을 구성합니다.

  9. BGP 커뮤니티 정보를 구성합니다.

  10. 인스턴스 유형, 인터페이스, 라우터 구분자, VRF 가져오기, 내보내기 및 테이블 레이블을 사용하여 라우팅 인스턴스 VRF1을 구성합니다. 프로토콜 OSPF에 대한 영역의 내보내기 정책 및 인터페이스를 구성합니다.

결과

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

디바이스 PE2 구성하기
단계별 절차

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

  1. 인터페이스를 구성합니다.

  2. 프로토콜 MPLS를 위한 정적 LSP를 구성합니다.

  3. 프로토콜 MPLS에 대한 인터페이스 및 정적 레이블 범위를 구성합니다.

  4. 프로토콜 OSPF에 대한 인터페이스를 구성합니다.

결과

라우터 PE2의 구성 모드에서 및 명령을 입력하여 구성을 확인합니다.show interfacesshow protocols 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

검증

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

라우터 PE1의 라우팅 테이블 inet.3의 경로 항목 확인
목적

라우터 PE1의 라우팅 테이블 inet.3의 경로 항목을 확인합니다.

작업

운영 모드에서 show route table inet.3 명령을 입력합니다.

의미

출력에는 세그먼트 라우팅 터널의 수신 경로가 표시됩니다.

라우터 PE1의 라우팅 테이블 mpls.0의 경로 테이블 항목 확인
목적

라우팅 테이블 mpls.0의 경로 항목을 확인합니다.

작업

운영 모드에서 show route table mpls.0 명령을 입력합니다.

의미

출력에는 세그먼트 라우팅 터널의 SID 레이블이 표시됩니다.

라우터 PE1의 SPRING 트래픽 엔지니어링 LSP 확인
목적

수신 라우터에서 SPRING 트래픽 엔지니어링 LSP를 확인합니다.

작업

운영 모드에서 show spring-traffic-engineering overview 명령을 입력합니다.

의미

출력은 수신 라우터의 SPRING 트래픽 엔지니어링 LSP의 개요를 표시합니다.

라우터 PE1의 수신 라우터에서 SPRING 트래픽 엔지니어링 LSP 확인
목적

수신 라우터에서 SPRING 트래픽 엔지니어링 LSP를 확인합니다.

작업

운영 모드에서 show spring-traffic-engineering lsp detail 명령을 입력합니다.

의미

출력은 수신 라우터의 SPRING 트래픽 엔지니어링 LSP에 대한 세부 정보를 표시합니다

라우터 PE2의 라우팅 테이블 mpls.0의 라우팅 테이블 항목 확인
목적

라우터 PE2의 라우팅 테이블 mpls.0의 라우팅 테이블 항목을 확인합니다.

작업

운영 모드에서 show route table mpls.0 명령을 입력합니다.

라우터 PE2의 정적 MPLS LSP 세그먼트 상태 확인
목적

라우터 PE2의 MPLS LSP 세그먼트 상태를 확인합니다.

작업

운영 모드에서 show mpls static-lsp 명령을 입력합니다.

의미

출력은 라우터 PE2의 정적 MPLS LSP 세그먼트의 상태를 표시합니다.

세그먼트 라우팅 LSP를 위한 분산 CSPF 활성화

Junos OS 릴리스 19.2R1S1 이전에는 세그먼트 라우팅 경로의 트래픽 엔지니어링을 위해 정적 경로를 명시적으로 구성하거나 외부 컨트롤러에서 계산된 경로를 사용할 수 있었습니다. 세그먼트 라우팅 LSP를 위한 분산형 CSPF(Constrained Shortest Path First) 기능을 사용하면 구성한 제약 조건에 따라 수신 디바이스에서 로컬로 세그먼트 라우팅 LSP를 계산할 수 있습니다. 이 기능을 통해 LSP는 구성된 제약 조건 및 메트릭 유형(트래픽 엔지니어링 또는 IGP)을 기반으로 최적화됩니다. LSP는 세그먼트 라우팅 레이블 스택 압축이 활성화 또는 비활성화된 대상에 대해 사용 가능한 ECMP 경로를 활용하도록 계산됩니다.

분산 CSPF 계산 제약 조건

세그먼트 라우팅 LSP 경로는 구성된 모든 제약 조건이 충족될 때 계산됩니다.

분산형 CSPF 계산 기능은 인터넷 초안 draft-ietf-spring-segment-routing-policy-03.txt, 트래픽 엔지니어링을 위한 세그먼트 라우팅 정책에 지정된 다음과 같은 제약 조건 하위 집합을 지원합니다.

  • 관리 그룹의 포함 및 제외.

  • 느슨하거나 엄격한 홉 IP 주소 포함.

    주:

    느슨하거나 엄격한 홉 제약 조건에서 라우터 ID만 지정할 수 있습니다. 레이블 및 기타 IP 주소는 Junos OS 릴리스 19.2R1-S1에서 느슨하거나 엄격한 홉 제약 조건으로 지정할 수 없습니다.

  • 세그먼트 목록의 최대 세그먼트 ID(SID) 수입니다.

  • 후보 세그먼트 라우팅 경로당 최대 세그먼트 목록 수입니다.

세그먼트 라우팅 LSP를 위한 분산 CSPF 계산 기능은 다음과 같은 유형의 제약 및 구축 시나리오를 지원하지 않습니다.

  • IPV6 주소.

  • 도메인 간 세그먼트 라우팅 트래픽 엔지니어링(SR-TE) LSP.

  • 번호가 지정되지 않은 인터페이스.

  • OSPF, ISIS 및 BGP-LS와 같은 여러 프로토콜 라우팅 프로토콜이 동시에 활성화됩니다.

  • 접두사 또는 애니캐스트 주소를 대상으로 하는 계산.

  • 인터페이스 IP 주소를 제약 조건으로 포함하거나 제외합니다.

분산 CSPF 계산 알고리즘

세그먼트 라우팅 LSP를 위한 분산 CSPF 계산 기능은 CSPF와 함께 레이블 스택 압축 알고리즘을 사용합니다.

레이블 스택 압축 사용

압축된 레이블 스택은 소스에서 대상까지의 경로 세트를 나타냅니다. 일반적으로 노드 SID와 인접 SID로 구성됩니다. 레이블 스택 압축이 활성화된 경우, 계산 결과는 제약 조건을 준수하면서 스택의 최소 SID 수로 대상에 대한 ECMP를 최대화하는 경로 집합입니다.

레이블 스택 압축 비활성화됨

레이블 스택 압축이 비활성화된 다중 경로 CSPF 계산은 대상에 대한 세그먼트 목록까지 찾습니다.N

  • 모든 세그먼트 목록의 비용은 대상에 도달하기 위한 최단 트래픽 엔지니어링 메트릭과 같거나 동일합니다.

  • 각 세그먼트 목록은 인접 SID로 구성됩니다.

  • 의 값은 구성별 후보 경로에 허용되는 최대 세그먼트 목록 수입니다.N

  • 두 세그먼트 목록이 동일하지 않습니다.

  • 각 세그먼트 목록은 구성된 모든 제약 조건을 충족합니다.

분산 CSPF 계산 데이터베이스

SR-TE 계산에 사용되는 데이터베이스는 해당 보급 노드에서 트래픽 엔지니어링이 활성화되었는지 여부에 관계없이 모든 링크, 노드, 접두사 및 해당 특성을 보유합니다. 즉, 컴퓨팅 노드가 학습한 모든 도메인의 트래픽 엔지니어링 데이터베이스(TED)와 IGP 링크 상태 데이터베이스의 합집합입니다. 따라서 CSPF가 작동하려면 계층 수준에서 문을 포함해야 합니다.igp-topology[edit protocols isis traffic-engineering]

분산 CSPF 계산 제약 조건 구성

컴퓨팅 프로필을 사용하여 계산 제약 조건을 논리적으로 그룹화할 수 있습니다. 이러한 컴퓨팅 프로필은 기본 및 보조 세그먼트 라우팅 LSP를 계산하기 위한 세그먼트 라우팅 경로에서 참조됩니다.

컴퓨팅 프로필을 구성하려면 계층 수준에서 compute-profile 문을 포함합니다.compute-profile[edit protocols source-packet-routing]

지원되는 계산 제약 조건에 대한 구성은 다음과 같습니다.

  • Administrative groups

    계층 수준에서 admin-groups 를 구성할 수 있습니다.admin-groups[edit protocols mpls] Junos OS는 관리 그룹 구성을 세그먼트 라우팅 트래픽 엔지니어링(SR-TE) 인터페이스에 적용합니다.

    계산 제약 조건을 구성하기 위해 관리 그룹 집합에 대해 세 가지 범주를 지정할 수 있습니다. 계산 제약 조건 구성은 모든 후보 세그먼트 라우팅 경로에 공통적이거나 개별 후보 경로 아래에 있을 수 있습니다.

    • include-any- 목록에 구성된 관리 그룹 중 하나 이상이 있는 모든 링크가 통과 경로에 허용되도록 지정합니다.

    • include-all- 목록에 구성된 모든 관리 그룹이 있는 모든 링크가 통과 경로에 허용되도록 지정합니다.

    • exclude- 목록에 구성된 관리 그룹이 없는 모든 링크가 통과 경로에 허용되도록 지정합니다.

  • Explicit path

    SR-TE 후보 경로를 계산하기 위한 제약 조건으로 컴퓨팅 프로파일에서 일련의 라우터 ID를 지정할 수 있습니다. 각 홉은 IPv4 주소여야 하며 strict 또는 loose 유형일 수 있습니다. 홉 유형이 구성되지 않은 경우 strict가 사용됩니다. 명시적 경로 제약 조건을 지정할 때 segment-list 문 아래에 옵션을 포함해야 합니다.computesegment-list

  • Maximum number of segment lists (ECMP paths)

    후보 경로를 여러 동적 세그먼트 목록과 연결할 수 있습니다. 경로는 ECMP 경로이며, 여기서 각 세그먼트 목록은 활성 가중치가 있는 다음 홉 게이트웨이로 변환됩니다. 이러한 경로는 압축 여부에 관계없이 경로 계산의 결과입니다.

    compute-profile 구성 문에서 옵션을 사용하여 이 속성을 구성할 수 있습니다.maximum-computed-segment-lists maximum-computed-segment-listscompute-profile 이 구성은 지정된 기본 및 보조 LSP에 대해 계산된 세그먼트 목록의 최대 수를 결정합니다.

  • Maximum segment list depth

    최대 세그먼트 목록 깊이 계산 매개변수는 관리 그룹과 같은 다른 모든 제약 조건을 충족하는 ECMP 경로 중에서 최대 세그먼트 목록 깊이보다 작거나 같은 세그먼트 목록이 있는 경로만 사용되도록 합니다. compute-profile에서 이 매개 변수를 제약 조건으로 구성하면 계층 수준 아래의 구성(있는 경우)을 재정의합니다.maximum-segment-list-depth[edit protocols source-packet-routing]

    compute-profile 구성 문에서 옵션을 사용하여 이 속성을 구성할 수 있습니다.maximum-segment-list-depth maximum-segment-list-depthcompute-profile

  • Protected or unprotected adjacency SIDs

    compute-profile 아래에서 보호되거나 보호되지 않는 인접 SID를 제약 조건으로 구성하여 지정된 SID 유형과의 링크를 방지할 수 있습니다.compute-profile

  • Metric type

    계산에 사용할 링크의 메트릭 유형을 지정할 수 있습니다. 기본적으로 SR-TE LSP는 계산을 위해 링크의 트래픽 엔지니어링 메트릭을 사용합니다. 링크에 대한 트래픽 엔지니어링 메트릭은 IGP 프로토콜의 트래픽 엔지니어링 확장에 의해 광고됩니다. 그러나 컴퓨팅 프로필에서 메트릭 유형 구성을 사용하여 계산에 IGP 메트릭을 사용하도록 선택할 수도 있습니다.

    compute-profile 구성 문에서 옵션을 사용하여 이 속성을 구성할 수 있습니다.metric-type (igp | te)compute-profile

분산 CSPF 계산

SR-TE 후보 경로는 구성된 제약 조건을 충족하도록 로컬에서 계산됩니다. 레이블 스택 압축을 사용하지 않도록 설정하면 다중 경로 CSPF 계산 결과는 인접 SID 스택 집합입니다. 레이블 스택 압축이 활성화되면 압축된 레이블 스택 집합(인접 SID 및 노드 SID로 구성)이 생성됩니다.

보조 경로가 계산될 때 기본 경로에 의해 취해진 링크, 노드 및 SRLG는 계산을 위해 회피되지 않습니다. 기본 및 보조 경로에 대한 자세한 내용은 기본 및 보조 LSP 구성을 참조하십시오.기본 및 보조 LSP 구성

계산 결과가 실패한 LSP의 경우, 트래픽 엔지니어링 데이터베이스(TED) 변경으로 계산이 재시도됩니다.

분산 CSPF 계산과 SR-TE 기능 간의 상호 작용

SR-TE 정책 경로와 연관된 가중치

경로의 다음 홉에 기여하는 계산 및 정적 SR-TE 경로에 대해 가중치를 구성할 수 있습니다. 그러나 계산이 활성화된 단일 경로로 인해 여러 세그먼트 목록이 생성될 수 있습니다. 이러한 계산된 세그먼트 목록은 그 자체에서 ECMP로 처리됩니다. 구성된 각 기본에 할당된 가중치를 고려하여 이러한 세그먼트에 계층적 ECMP 가중치를 할당할 수 있습니다.

BFD Liveliness 감지

계산된 기본 또는 보조 경로에 대해 BFD 활성도 감지를 구성할 수 있습니다. 계산된 모든 기본 또는 보조 경로는 여러 세그먼트 목록을 생성할 수 있으며, 그 결과, 세그먼트 목록에 대해 구성된 BFD 매개 변수가 계산된 모든 세그먼트 목록에 적용됩니다. 모든 활성 기본 경로가 다운되면 사전 프로그래밍된 2차 경로(제공된 경우)가 활성화됩니다.

상속 레이블 다음 홉

계산된 기본 또는 보조 경로에 대해 계층 아래의 구성은 기본 동작이므로 명시적으로 활성화할 필요는 없습니다.inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name]

자동 번역 기능

세그먼트 목록에서 자동 번역 기능을 구성할 수 있으며, 자동 번역 기능이 있는 기본 또는 보조 경로는 이러한 세그먼트 목록을 참조합니다. 반면, 컴퓨팅 기능이 활성화된 기본 또는 보조는 세그먼트 목록을 참조할 수 없습니다. 따라서 지정된 기본 또는 보조 경로에 대해 컴퓨팅 기능과 자동 변환 기능을 모두 사용하도록 설정할 수 없습니다. 그러나 컴퓨팅 유형의 기본 경로와 자동 변환 유형의 기본 경로로 구성된 LSP가 있을 수 있습니다.

분산 CSPF 계산 샘플 구성

예시 1

실시예 1에서,

  • 계산되지 않은 기본 경로는 구성된 세그먼트 목록을 참조합니다. 이 예에서는 구성된 세그먼트 목록이 참조되며 이 기본 경로의 이름으로도 사용됩니다.static_sl1

  • 계산된 기본에는 구성된 이름이 있어야 하며, 이 이름은 구성된 세그먼트 목록을 참조해서는 안 됩니다. 이 예에서 은(는) 구성된 세그먼트 목록이 아닙니다.compute_segment1

  • compute-profile은 라는 이름으로 기본 경로에 적용됩니다.compute_profile_redcompute_segment1

  • 계산 프로필에는 계산에 대한 명시적 경로 제약 조건을 지정하는 데 사용되는 유형의 세그먼트 목록이 포함되어 있습니다.compute_profile_redcompute

계산된 경로 다음 홉과 정적 다음 홉의 가중치는 각각 2와 3입니다. 계산된 경로의 다음 홉이 , , 이며 정적 경로에 대한 다음 홉이 라고 가정하면, 가중치는 다음과 같이 적용됩니다.comp_nh1comp_nh2comp_nh3static_nh

다음 홉

중량

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

예시 2

예제 2에서는 기본 경로와 보조 경로 모두 컴퓨팅 유형일 수 있으며 자체 컴퓨팅 프로필을 가질 수 있습니다.

예시 3

예제 3에서 컴퓨팅이 기본 또는 보조 경로 아래에 언급되면 계산에 대한 제약 조건이나 다른 매개 변수 없이 대상에 대한 경로의 로컬 계산이 발생합니다.

예: SR-TE LSP를 위한 CoS 기반 포워딩 및 정책 기반 라우팅 구성

SUMMARY CBF(CoS 기반 포워딩) 및 PBR(Policy-Based Routing)은 SR-TE(Non-Color Segment Routing-Traffic Engineered) LSP에 대해 활성화되어 명시적 SR-TE 경로를 통해 선택적 트래픽을 조정하여 서비스 등급 또는 정책에 따라 트래픽을 서비스하는 이점을 제공할 수 있습니다.

SR-TE LSP를 위한 CoS 기반 포워딩 및 정책 기반 라우팅 개요

SR-TE LSP를 위한 CoS 기반 포워딩(CBF) 및 정책 기반 라우팅(PBR)의 이점

CBF 및 PBR을 통해 다음을 수행할 수 있습니다.

  • 코어에서 서비스 트래픽을 조정하기 위해 세그먼트 라우팅-트래픽 엔지니어링(SR-TE) 경로의 조합을 사용합니다.

  • 선택한 SR-TE 경로를 통해 해결할 지원 서비스를 선택합니다.

CBF 및 PBR을 지원하는 세그먼트 라우팅 경로 소스

다음 세그먼트 라우팅 경로 소스는 CoS 기반 포워딩 및 정책 기반 라우팅을 지원합니다.

  • Static SR–TE paths- 전체 레이블 스택이 정적으로 구성된 정적으로 구성된 소스 라우팅 경로.

  • PCEP- 컨트롤러에서 생성되고 PCEP 세그먼트 라우팅 확장을 통해 또는 BGP 세그먼트 라우팅 확장을 통해 BGP 세그먼트 라우팅 정책에서 ERO의 수신 라우터로 다운로드되는 소스 라우팅 경로를 동적으로 프로비저닝합니다.

  • Dynamic LSPs- 마지막 홉 ERO 해상도가 있는 동적 터널 모듈을 통해 트리거되는 동적으로 생성된 터널입니다.

  • Auto-translated paths- 자동으로 변환되는 정적으로 구성된 소스 라우팅 경로.

SR-TE LSP에 대한 CBF 및 PBR 구성 고려 사항

기억:

  • CBF 및 PBR은 정적 또는 동적으로 구성된 색상이 지정되지 않은 SR-TE LSP에서만 활성화됩니다.

  • SR-TE LSP에 대한 CBF 및 PBR 구성은 모두 디바이스에 공존할 수 있습니다. 구성 순서에 따라 경로가 전달되는 유형이 결정됩니다.

  • PBR의 경우 SR-TE LSP의 첫 번째 홉이 레이블이면 계층 수준에서 문을 포함해야 합니다.resolution preserve-nexthop-hiearchy[edit routing-options]

  • CBF에 대한 클래스 기반 경로 포워딩은 포워딩 테이블에서만 볼 수 있으며 경로에는 표시되지 않습니다.

  • PBR에 대한 경로의 정책 기반 전달은 경로에서 수행되며 명령 출력에 표시됩니다.show route

SR-TE LSP를 위한 CoS 기반 포워딩 및 정책 기반 라우팅 구성

SUMMARY CBF(CoS 기반 포워딩) 및 PBR(Policy-Based Routing, 필터 기반 포워딩 FBF라고도 함)은 SR-TE(Explicit Segment Routing-Traffic Engineer) LSP(label-swtiched path)를 사용하여 선택적 트래픽을 조정할 수 있습니다. 다음 홉이 첫 번째 홉 레이블 또는 IP 주소로 구성된 색상이 없는 세그먼트 라우팅 LSP만 CBF 및 PBR을 지원합니다.

시작하기 전에

  • 무색 SR-TE LSP에 대해 CBF 및 PBR을 활성화하려면 Junos OS 릴리스 20.1 이상 릴리스를 실행해야 합니다.

  • 디바이스 인터페이스를 구성하고 디바이스가 네트워크에 연결되어 있는지 확인합니다.

  • 세그먼트 목록을 정의하고 SR-TE LSP 및 관련 매개 변수를 구성합니다.

SR-TE LSP를 구성하려면 다음을 수행합니다.

  1. 레이블 매개 변수를 사용하여 세그먼트 목록을 정의합니다.

    예:

  2. SR-TE LSP에 대한 소스 라우팅 경로를 구성하고 경로에 대한 기본 설정 값과 기본 세그먼트를 지정합니다.

    예:

이제 구성된 SR-TE LSP에 대해 CBF 및 PBR을 구성할 수 있습니다.

CBF를 구성하려면 다음을 수행합니다

  1. DSCP(Differentiated Services Code Point) 분류자를 정의하여 수신 IPv4 패킷, 포워딩 클래스 및 옵션 값을 처리합니다.

    예:

  2. 전송할 패킷을 그룹화하기 위한 포워딩 클래스(FC)를 정의하고 출력 대기열에 패킷을 할당합니다.

    예:

  3. 구성된 분류자를 디바이스 인터페이스에 할당합니다.

    예:

  4. LSP 다음 홉을 SR-TE LSP로 사용하여 CoS 기반 포워딩 정책 옵션을 정의합니다.

    예:

  5. 다음 홉 맵에서 포워딩 클래스를 충족하지 않는 트래픽은 삭제합니다.

    예:

  6. 경로 필터와 일치하는 경로가 map-name으로 지정된 CoS 다음 홉 매핑의 적용을 받도록 지정하는 정책 문을 구성합니다.

    예:

  7. 라우팅 테이블에서 포워딩 테이블로 내보내는 경로에 정책을 적용합니다. 이를 통해 SR-TE LSP에 대한 CBF를 사용할 수 있습니다.

    예:

  8. 구성을 커밋합니다.

Verify CBF Configuration

명령을 사용하여 CBF 구성을 확인할 수 있습니다 .show route forwarding-table destination ip-address vpn vpn-name extensive

CBF의 경우, 필터링된 경로가 명령 출력에 표시되는 PBR과 달리 클래스 기반 경로 전달은 포워딩 테이블에서만 볼 수 있습니다 .show route

PBR을 구성하려면 다음을 수행합니다

  1. 프로토콜 및 경로 필터와 일치하는 경로가 LSP 다음 홉의 적용을 받거나 포워딩 테이블에서 ECMP(Equal-Cost Multipath)로 로드 밸런싱되도록 지정하는 정책 문을 구성합니다.

    예:

  2. 경로의 프로토콜 다음 홉에서 사용자 지정 경로 확인을 수행하도록 디바이스를 구성합니다.

    주:

    SR-TE LSP의 첫 번째 홉이 레이블일 때 PBR이 작동하려면 명령문이 필수입니다.resolution preserve-nexthop-hierarchy

  3. 라우팅 테이블에서 포워딩 테이블로 내보내는 경로에 정책을 적용합니다. 이를 통해 SR-TE LSP에 대한 PBR이 활성화됩니다.

    예:

  4. 구성을 커밋합니다.

Verify PBR Configuration

명령을 사용하여 PBR 구성을 확인할 수 있습니다 .show route destination-prefix

출력은 대상 접두사 4.0.0.1에 대한 모든 다음 홉을 표시합니다. 옵션은 출력 필드 아래에 필터링된 다음 홉을 표시합니다.expanded-nh extensiveKrt_inh

PBR의 경우 명령 출력은 경로의 정책 기반 필터링을 수행합니다.show route

PCEP에서 SR-TE LSP를 위한 다중 경로 활성화

draft-ietf-pce-multipath-06에 정의된 대로 PCEP SR-TE LSP(정적으로 구성, 위임 및 PCE 시작)에 대해 여러 경로(기본 또는 보조)를 구성할 수 있습니다. 단 하나의 보조 경로 구성만 지원되며 정적으로 구성된 SR-TE LSP에 대해서만 지원됩니다. draft-ietf-pce-multipath-06에 정의된 PCEP 확장을 통해 PCEP는 PCEP 엔드포인트 간에 LSP에 대한 다중 경로(다중 경로)를 전파할 수 있습니다.

PCEP SR-TE LSP를 위한 다중 경로의 이점

  • LSP는 대상에 여러 세트의 ERO를 가질 수 있습니다

  • 개별 ERO에 대한 가중치를 구성하여 로드 밸런싱 기능 제공

  • 후보 경로를 정의하기 위해 SR-TE 아키텍처 초안과 일치

다음과 같은 PCEP 다중 경로 기능이 지원됩니다.

  • 여러 경로에 대한 PCEP가 활성화되면(기본값) PCC가 구성 및 제어되는 후보 경로에서 여러 기본(또는 하나의 보조) 경로를 구성할 수 있습니다.

  • 다중 경로에 대한 PCEP가 비활성화되면 후보 경로에 하나의 기본 경로만 구성할 수 있습니다. 보조 경로 구성은 허용되지 않습니다.

PCEP 다중 경로를 활성화하면 이제 1보다 큰 최대 세그먼트 목록 수()로 구성할 수 있습니다.compute-profilemaximum-computed-segment-lists

주:

다중 경로에 대한 PCEP가 활성화되면 PCCD는 PCC 제어 후보 경로에 대한 제약 조건을 보내지 않습니다.

PCEP multipath 기능이 활성화되면 위임되지 않은 PCC 후보 경로에 대해 보조 경로 구성이 허용되며, 보조 경로에 특정한 ERO(EXPLICIT-ROUTE Object)가 ERO에 대한 백업 플래그 세트와 함께 PCE로 전송됩니다. 기본 경로에는 PCRpt 메시지의 MULTIPATH-BACKUP-TLV가 포함되지 않습니다. 보조 경로에는 백업 플래그가 설정된 MULTIPATH-BACKUP-TLV가 포함됩니다.

지원되는 PCEP 다중 경로 기능은 다음과 같습니다.

  • 경로 속성(PATH-ATTRIB) 개체의 다중 경로 가중치 TLV(MULTIPATH-WEIGHT-TLV)

  • PCC 제어 SR-TE LSP 전용 경로 속성(PATH-ATTRIB) 개체의 MULTIPATH-BACKUP TLV

  • PCEP LSP 개체의 MULTIPATH-CAP TLV

  • PCEP multipath가 비활성화된 경우 SR 후보 경로에서 여러 기본 및 보조 경로를 제한합니다.

  • PCC 제어 LSP에 대해 PCEP multipath가 활성화된 경우 SR 후보 경로의 여러 기본 경로 및 보조 경로

  • 위임 및 PCE 시작 LSP에 대한 SR-TE 컴퓨팅 프로파일에서 최대 계산 세그먼트 목록()이 1개 이상max-computed-segment-lists

  • SR-TE 및 PCCD의 PCE 시작 후보 경로에 대한 여러 ERO

  • SRv6 LSP

  • SR MPLS(IPv4)

  • SR MPLS(IPv4) 동적 터널

  • 다중 컨트롤러 지원

  • PCE 시작, PCC 구성 및 제어, 위임 컬러 및 비컬러 후보 경로에 대한 다중 ERO 경로

  • 이전 버전의 Paragon Pathfinder와 역호환됩니다. 이전 버전과의 호환성을 위해 [] 계층 수준에서 구성 문을 구성해야 합니다.disable-multipath-capabilityedit protocols pcep

  • PCE 시작 후보 경로 검증 실패에 대한 오류 코드 지원

    • 후보 경로당 총 하위 후보 경로는 127개로 제한됩니다. PCE 시작 LSP의 경우 ERO 경로 수가 127을 교차하면 SR-TE는 PCCD에 ERROR를 발생시키고(PCCD는 PCEP 오류 메시지를 PCE에 전송) 해당 ERO 경로가 거부됩니다.

다음과 같은 PCEP 오류 메시지가 지원됩니다.

표 5: PCEP 오류 메시지
오류 유형 오류 값 의미 사용 현황
19 20 백업 경로가 지원되지 않음 이는 PCC에서 MULTIPATH-BACKUP TLV를 수신할 때 발생합니다.
24개 1 허용되지 않는 인스턴스화 매개 변수 이는 PCE가 후보 경로당 127개 이상의 하위 후보 경로를 추가하려고 할 때 발생합니다.

제한

다음과 같은 PCEP 제한 사항이 적용됩니다.

  • draft-ietf-pce-multipath-06에 언급된 다음 TLV는 지원되지 않습니다.

    • 다중 경로 백업 TLV

    • 다중 경로 반대 방향 경로 TLV

    • 복합 후보 경로

  • PCEP에서 다중 경로 기능이 비활성화된 경우, 여러 하위 후보 경로를 구성할 수 없습니다. 그러나 다중 경로 기능이 없는 Junos 디바이스(22.4R1 이전의 Junos OS 버전)에서는 여러 하위 후보 경로 구성이 허용됩니다. PCEP 다중 세그먼트가 활성화되면(기본적으로), 보고를 위해 PCC 제어 LSP에 대해 여러 기본 경로가 허용됩니다. 그러나 PCEP 다중 세그먼트가 활성화된 경우 위임된 후보 경로에 대해 하나의 기본 경로만 지원됩니다.

  • 관리 그룹 및 기타 제약 조건은 PCC 구성 및 제어된 SR-MPLS 및 SRv6 후보 경로(단일 또는 다중 기본 구성 포함)에 대해 PCE에 통지되지 않습니다. 위임 및 PCE 시작 후보 경로에는 영향이 없습니다.

  • PCEP multipath 기능이 활성화되면 위임되지 않은 후보 경로에 대해 보조 경로 구성이 허용됩니다. PCEP multipath 기능이 비활성화되면 보조 경로 구성이 허용되지 않습니다.

  • 후보 경로에는 PCE 시작 및 위임 LSP가 혼합되어 있을 수 없습니다.

  • PCE 시작 컬러 후보 경로에 대한 다중 하위 후보 경로는 지원되지 않습니다.

  • 후보 경로에 여러 하위 후보 경로가 있는 위임 기능은 지원되지 않습니다.

구성

PCCD가 LSP 객체에서 다중 경로 기능 TLV를 전송하여 특정 후보 경로에 대한 최대 계산 세그먼트 목록을 알리도록 하려면 [] 계층 수준에 구성 문을 포함합니다.propagate-max-segmentlistedit protocols pcep 기본적으로 TLV는 LSP 개체로 전송되지 않습니다.

모든 PCE에 대해 PCEP 다중 기능 세션을 비활성화하려면 [] 계층 수준에서 구성 문을 포함합니다.disable-multipath-capabilityedit protocols pcep

진단을 위해 다음 프로토콜 추적 옵션을 활성화할 수 있습니다.

  • user@host# set protocols pcep traceoptions ...

  • user@host# set protocols pcep pce pce1 traceoptions ...

  • user@host# set protocols source-packet-routing traceoptions

다음 show 명령을 사용하여 PCC에서 LSP의 상태를 표시할 수 있습니다.

  • user@host> show path-computation-client lsp- PCC(Path Computation Client)에 알려진 LSP(Label-Switched Path)의 상태를 표시합니다.

  • user@host> show path-computation-client lsp extensive- 알려진 각 LSP(point-to-point 및 point-to-multipoint LSP)에 대한 광범위한 출력 수준을 표시합니다.

  • user@host> show path-computation active-pce- 세션에서 multipath의 상태를 표시합니다.

  • user@host> show spring-traffic-engineering lsp detail- SPRING 트래픽 엔지니어링의 수신 세부 정보를 표시합니다.

PCEP 세션에 대한 전송 레이어 보안 활성화

TLS(전송 계층 보안)는 피어 인증, 메시지 암호화 및 무결성을 지원합니다. PCC(Path Computation Client)에서 TLS를 사용하여 RFC 8253에 정의된 대로 PCE(Path Computation Element)와의 TCP 연결을 설정할 수 있습니다. 이렇게 하면 PCEP 메시지를 전송하기 위한 보안 PCEP 세션(PCEPS)이 생성됩니다.

이 문서에서는 TLS 절차의 시작, TLS 핸드셰이크 메커니즘, 피어 인증을 위한 TLS 방법을 포함하여 PCE와의 상호 작용을 보호하기 위해 PCEP 세션에 TLS를 활성화하는 방법에 대해 설명합니다. TLS를 통한 PCEP의 보안 전송은 PCEPS라고도 합니다.

PCEP 세션에 대한 TLS 활성화의 이점

  • 스푸핑(PCC 또는 PCE 가장), 스누핑(메시지 가로채기), 위조 및 서비스 거부와 같은 공격으로부터 PCEP 세션을 보호합니다.

  • TLS 보안 이점을 활용합니다.

PCC(Path Computation Client)에서 TLS 활성화

PCC에서 TLS를 활성화하고 PCEPS 세션을 설정하려면 [] 계층 수준에서 CLI 문을 설정합니다.tls-strictedit protocols pcep

tls-strict 구성 문을 활성화하면 다음 이벤트가 발생합니다.

  1. PCEP 세션이 플랩됩니다. 기존 TCP 연결이 종료되고 TLS를 사용하여 다시 연결됩니다.

  2. PCC는 PCE와 TCP 연결을 설정합니다.

  3. TLS 프로시저는 PCE에서 PCC로, PCC에서 PCE로의 메시지에 의해 시작됩니다.StartTLS PCC에서 메시지를 보내고 타이머가 시작됩니다.StartTLSStartTLSWait [] 계층 수준에서 CLI 문을 구성 하여 타이머를 구성할 수 있습니다.StartTLSWaitstart-tls-wait-timer secondsedit protocols pcep pce pce-id

    주:

    타이머의 권장 값은 60초이며 타이머보다 작아서는 안 됩니다.StartTLSWaitOpenWait 기본 타이머 값은 60초로 설정됩니다.OpenWait

    • PCC에서 메시지 대신 Open 메시지를 수신하는 경우 Error-Type이 1(PCEP 세션 설정 실패)로 설정되고 Error-value가 1(유효하지 않은 Open 메시지 또는 non-Open 메시지 수신)로 설정된 메시지가 수신되면 TCP 세션이 닫힙니다.StartTLSPCErr

    • PCE에서 메시지가 수신되지 않으면 타이머가 만료된 후 PCC는 오류 유형이 25(PCEP 실패)로 설정되고 오류 값이 5(타이머 만료 전에 메시지 없음)로 설정된 메시지를 보내고 TCP 세션이 닫힙니다.StartTLSStartTLSWaitPCErrStartTLSStartTLS PCErr/OpenStartTLSWait

  4. TLS 연결의 협상 및 설정이 발생합니다.

  5. PCEP 메시지 교환은 RFC5440에 따라 시작됩니다.

주:

[] 계층 수준에서 CLI 문을 활성화 하지 않은 경우, PCEP 세션을 설정하는 동안 PCC가 메시지 대신 메시지를 수신하면 오류 유형이 1(PCEP 세션 설정 실패)로 설정된 메시지와 오류 값이 1로 설정된 메시지(잘못된 열기 메시지 또는 비개방 메시지 수신)가 TCP 세션이 닫힙니다.tls-strictedit protocols pcepStartTLSOpenPCErr

주:

성공적인 PCEPS 세션을 설정하려면 PCC와 PCE 모두에서 TLS를 활성화해야 합니다.

PKI(공개 키 인프라)를 사용하여 인증서 업데이트

PKI는 인증서 만료에 대해 PCC에 알리지 않습니다. 다음 CLI 명령을 사용하여 인증서를 수동으로 업데이트해야 합니다. 이 방법에서는 인증서 만료 날짜를 추적해야 합니다.

TLS 연결 설정

다음 단계에서는 TLS 연결(TLS v1.2 사용)을 설정하는 방법을 설명합니다.

  1. 노드(Junos OS 디바이스/pce-server)에 대한 인증서를 생성합니다. 다음 방법 중 하나를 사용하여 인증서를 생성할 수 있습니다.

    • Method 1- 디바이스에서 키 쌍 및 CSR을 생성하고 이 CSR을 CA로 전송하여 인증서를 가져옵니다. 인증서가 발급되면 상자에 복사되어 설치됩니다.

    • Method 2- 기본적으로 키 쌍 및 인증서를 생성합니다. 인증서와 개인 키가 모두 디바이스에 복사되어 함께 설치됩니다.

  2. 로드된 CA에 대해 PCE 서버 인증서의 유효성을 검증할 수 있도록 PCC에 인증 기관(CA)을 로드합니다.

    주:

    CA는 플랫 계층 구조에서 독립 CA로 로드할 수 있습니다. CA가 다른 CA의 하위 CA인 경우 체인은 PKI에 의해 내부적으로 구성됩니다.

    주:

    서버 인증서는 CA에서 서명해야 합니다. 자체 서명된 인증서는 허용되지 않습니다.

  3. PCC에서 TLS를 사용하도록 설정합니다.

  4. PCEP 세션은 TLS 핸드셰이크 메커니즘을 사용하여 TLS를 통해 설정됩니다.

  5. PCE 서버는 TLS를 통해 들어오는 PCC 연결 요청에 대해 포트 4189를 수신 대기합니다.

  6. PCC는 대상 포트 4189에 대한 연결 요청을 시작합니다.

  7. 3방향 핸드셰이크가 완료되면 인증서를 사용하여 TLS 핸드셰이크가 시작되고 단방향 인증이 수행됩니다(PCC가 서버 인증서를 인증함). 서버와 클라이언트 모두 메시지를 수신 할 때까지 기다립니다.StartTLSWaitStartTLS [] 계층 수준에서 CLI 문을 구성하여 타이머를 구성할 수 있습니다.StartTLSWait start-tls-wait-timer secondsedit protocols pcep pce pce-id

    주:

    타이머의 권장 값은 60초이며 타이머보다 작아서는 안 됩니다.StartTLSWaitOpenWait 기본 타이머 값은 60초로 설정됩니다.OpenWait

  8. TLS 핸드셰이크 세션이 성공한 후 PCC 및 PCE는 TLS를 통해 PCEP 세션 설정을 시작하며, 이 기간 동안 세션 매개변수가 협상됩니다.

    • 인증서 유효성 검사에 실패하면 PCC는 TCP 연결을 종료합니다.

  9. PCEP 메시지는 TLS 연결을 통해 애플리케이션 데이터로 전송됩니다.

  10. 암호화 및 복호화는 성공적인 TLS 핸드셰이크 후 PCC와 PCE 모두에서 발생합니다.

  11. PCEP 세션이 닫히면 TLS 세션이 제거됩니다.

주:

진행 중인 TLS를 통한 PCEP 세션 중에 인증서가 만료, 해지 또는 다시 로드되는 경우 진행 중인 세션은 영향을 받지 않습니다.

기본 TLS 핸드셰이크 메커니즘 이해

핸드셰이크는 서버와 클라이언트 간에 교환되는 일련의 메시지입니다. 핸드셰이크의 정확한 단계는 키 교환 알고리즘, 암호 그룹 등에 따라 다릅니다. 다음은 기본 TLS 핸드셰이크 메커니즘 단계입니다.

  1. Client Hello- 클라이언트는 이 메시지를 전송하여 핸드셰이크를 시작합니다. 이 메시지에는 TLS 버전, 지원되는 암호화 알고리즘 목록 또는 암호 그룹 및 기타 클라이언트 세부 정보가 포함되어 있습니다.

  2. Server Hello- 서버는 서버 Hello 메시지를 전송하여 클라이언트 Hello에 응답합니다. 이 메시지에는 서버 인증서, 선택한 암호화 알고리즘, 세션 ID 및 서버의 공개 키가 포함되어 있습니다.

  3. Authentication- 백그라운드에서 클라이언트는 인증서를 발급한 구성된 인증 기관을 통해 서버의 인증서를 확인합니다. 성공적으로 확인되면 클라이언트는 서버가 정품임을 확인하고 상호 작용을 계속합니다.

  4. Optional Client Certificate- 서버가 Server Hello 메시지에서 클라이언트로부터 인증서를 요청한 경우 클라이언트는 클라이언트 인증서를 보냅니다(상호 TLS의 경우에만).

  5. Client Key Exchange- 클라이언트는 서버의 공개 키로 암호화된 비밀 키(서버 Hello 메시지에서 획득)를 보냅니다.

  6. Decrypt secret key- 서버는 개인 키를 사용하여 비밀 키를 복호화합니다.

  7. Client Finished- 클라이언트가 공유 비밀 키로 암호화된 종료 메시지를 보내고 핸드셰이크 완료를 알립니다.

  8. Server Finished- 서버는 공유 비밀 키로 암호화된 완료 메시지로 응답하고 핸드셰이크 완료를 알립니다.

  9. Exchange Messages- 핸드셰이크 완료 후의 메시지는 대칭적으로 암호화됩니다.

PCEP 세션에 대한 TLS 진단 및 검증

진단을 위해 다음 traceoptions CLI 문을 사용합니다.

다음 구성을 사용하여 PKI 로그를 활성화하고 다음에서 동일한 파일을 캡처합니다. /var/log/<filename>

다음 명령을 사용하여 로드된 CA 인증서를 확인합니다.

샘플 출력

다음은 명령의 샘플 출력입니다.show path-computation-client statistics

이 샘플 출력은 다음 정보를 제공합니다.

  • TLS는 PCC에서 활성화됩니다.

  • PCE는 TLS를 지원합니다.

  • TLS 세션이 설정되었습니다. 이는 또한 PCE 서버 인증서가 유효함을 나타냅니다.

  • PCEPS 세션 상태가 실행 중입니다.

PCEP에서 경로 최적화 및 계산된 지표 보고

PCEP의 메트릭 개체는 여러 용도로 사용됩니다. 메트릭 개체는 경로 최적화에 사용되는 메트릭 유형을 나타냅니다. 또한 메트릭 개체는 경로가 허용 가능한 것으로 간주되기 위해 초과해서는 안 되는 경로 비용에 대한 경계를 나타냅니다. 메트릭 개체는 계산된 메트릭도 나타냅니다.

주니퍼는 경로 최적화(내부 게이트웨이 프로토콜, 트래픽 엔지니어링 및 경로 지연)와 RSVP 및 SR-TE LSP에 대한 계산된 메트릭 보고를 위한 메트릭 개체를 지원합니다.

주:

계산된 메트릭의 경로 최적화 및 보고를 위한 메트릭 개체는 SRv6-TE LSP에 적용되지 않습니다.

PCEP에서 경로 최적화 및 계산된 지표 보고의 이점

  • PCC에 구성된 경로 최적화 메트릭을 보고하면 PCE가 경로 계산에 사용되는 제약 조건을 인식하는 데 도움이 됩니다.

  • 계산된 지표를 PCE에 보고합니다. 이는 PCE가 LSP에 추가 최적화가 필요한지 분석하는 데 도움이 됩니다.

최적화 메트릭 이해

다음 섹션에서는 PCEP의 RSVP 및 SR-TE(SR MPLS) LSP에 대한 의도된 실제 최적화 메트릭에 대해 설명합니다.

로컬에서 생성된 RSVP LSP

로컬로 생성된 RSVP LSP를 메트릭으로 최적화하려면 구성된 메트릭이 PCEP를 통해 보고되도록 최적화 메트릭(IGP, TE 및 경로 지연)을 구성합니다. 계산된 메트릭은 PCRpt 메시지를 통해 PCEP에 실제 메트릭으로 전송됩니다.

위임된 RSVP LSP

위임된 RSVP LSP에 대한 최적화 메트릭을 보고하려면 최적화 메트릭(IGP, TE 및 경로 지연)을 구성합니다.

Intended Metric:

  • LSP의 위임 시점에 최적화 메트릭이 구성되면, 정보는 PCRpt 메시지를 통해 PCE로 전송된다.

  • LSP 위임 후 최적화 메트릭이 구성되면 LSP 제어 상태가 로컬로 제어될 때 LSP에 변경 사항이 적용되거나 PCE에 전달됩니다.

  • PCUpd 메시지가 수신될 때 메시지에 최적화 메트릭이 있는 경우 LSP 제어 상태가 외부 제어될 때까지 후속 PCRpt 메시지에서 메트릭이 의도한 메트릭으로 사용됩니다.

  • PCUpd 메시지가 수신될 때 최적화 메트릭이 메시지에 없으면 후속 PCRpt 메시지에 의도된 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬 제어로 변경되면 Junos CLI에서 구성된 최적화 메트릭이 PCRpt 메시지의 의도된 메트릭이 됩니다.

Actual Metric:

  • LSP를 위임하는 동안 PCRpt 메시지에는 실제 메트릭이 포함되지 않습니다.

  • PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 있는 경우 LSP 제어 상태가 외부 제어될 때까지 메트릭은 후속 PCRpt 메시지에서 실제 메트릭으로 사용됩니다.

  • PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 없는 경우 후속 PCRpt 메시지에는 실제 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬 제어로 변경되면 PCC에서 계산한 메트릭이 PCRpt 메시지에서 실제 메트릭으로 전송됩니다.

PCE 시작 RSVP LSP

PCE 시작 RSVP LSP에 대한 최적화 메트릭을 보고하려면 템플릿에서 최적화 메트릭(IGP, TE 및 경로 지연)을 구성합니다. 그런 다음 LSP 제어 상태가 로컬 제어가 되면 템플릿이 PCE 시작 LSP에 적용됩니다.

Intended Metric:

  • PCE 시작 LSP가 최적화 메트릭이 있는 템플릿에 매핑되면 LSP 제어 상태가 로컬 제어로 변경되면 구성이 LSP에 적용되고 PCE로 전송됩니다.

  • PCInit/PCUpd 메시지가 수신될 때 메시지에 최적화 메트릭이 있는 경우 LSP 제어 상태가 외부 제어될 때까지 후속 PCRpt 메시지에서 메트릭이 의도된 메트릭으로 사용됩니다.

  • PCInit/PCUpd 메시지가 수신될 때 최적화 메트릭이 메시지에 없으면 후속 PCRpt 메시지에 의도된 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 국부적으로 제어될 때, 템플릿에 있는 최적화 메트릭은 PCRpt 메시지에서 의도된 메트릭으로 사용된다.

Actual Metric:

  • PCInit/PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 있는 경우 LSP 제어 상태가 외부 제어될 때까지 메트릭이 후속 PCRpt 메시지에서 실제 메트릭으로 사용됩니다.

  • PCInit/PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 없는 경우 후속 PCRpt 메시지에는 실제 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬 제어로 변경되면 PCC에서 계산한 메트릭이 PCRpt 메시지에서 실제 메트릭으로 전송됩니다.

위임된 SR-TE LSP

위임된 SR-TE(SR MPLS) LSP에 대한 최적화 메트릭을 보고하려면 최적화 메트릭(IGP, TE 및 경로 지연)을 구성합니다.

Intended Metric:

  • LSP의 위임 시에 최적화 메트릭이 구성되면, 정보는 PCRpt 메시지를 통해 PCE로 전송된다.

  • LSP 위임 후 최적화 메트릭이 구성되면 LSP 제어 상태가 로컬로 제어될 때 LSP에 변경 사항이 적용되거나 PCE에 전달됩니다.

  • PCUpd 메시지가 수신될 때 메시지에 최적화 메트릭이 있는 경우 LSP 제어 상태가 외부 제어될 때까지 후속 PCRpt 메시지에서 메트릭이 의도한 메트릭으로 사용됩니다.

  • PCUpd 메시지가 수신될 때 최적화 메트릭이 메시지에 없으면 후속 PCRpt 메시지에 의도된 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬 제어로 변경되면 Junos CLI에서 구성된 최적화 메트릭이 PCRpt 메시지의 의도된 메트릭이 됩니다.

Actual Metric:

  • 생성 후 LSP가 위임될 때, LSP 위임 시 LSP에 1개의 ERO가 있는 경우 IGP, TE 및 지연 메트릭의 계산된 값이 PCRpt 메시지의 실제 메트릭으로 전송됩니다.

  • 생성 후 LSP가 위임될 때, LSP에 여러 ERO가 있는 경우 LSP 위임 시 실제 메트릭은 PCEP의 LSP(ERO당이 아님)별로 전송되어야 하므로 계산된 메트릭/실제 메트릭은 PCRpt 메시지로 전송되지 않습니다.

  • PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 있는 경우 LSP 제어 상태가 외부 제어될 때까지 메트릭은 후속 PCRpt 메시지에서 실제 메트릭으로 사용됩니다.

  • PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 없는 경우 후속 PCRpt 메시지에는 실제 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬 제어로 변경되면 PCC에서 계산된 IGP, TE 및 지연 메트릭이 PCRpt 메시지의 실제 메트릭으로 전송됩니다.

PCE 시작 SR-TE LSP

PCInit/PCUpd 메시지에서 PCE가 보낸 의도된 메트릭 또는 실제 메트릭은 LSP가 외부에서 제어될 때까지 PCRpt 메시지를 통해 PCE에 다시 보고됩니다.

Intended Metric:

  • PCInit/PCUpd 메시지가 수신될 때 메시지에 최적화 메트릭이 있는 경우 LSP 제어 상태가 외부 제어될 때까지 후속 PCRpt 메시지에서 메트릭이 의도된 메트릭으로 사용됩니다.

  • PCInit/PCUpd 메시지가 수신될 때 최적화 메트릭이 메시지에 없으면 후속 PCRpt 메시지에 의도된 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬로 제어되면 의도한 메트릭이 전송되지 않습니다.

Actual Metric:

  • PCInit/PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 있는 경우 LSP 제어 상태가 외부 제어될 때까지 메트릭이 후속 PCRpt 메시지에서 실제 메트릭으로 사용됩니다.

  • PCInit/PCUpd 메시지가 수신될 때 계산된 메트릭이 메시지에 없는 경우 후속 PCRpt 메시지에는 실제 메트릭이 포함되지 않습니다.

  • LSP 제어 상태가 로컬 제어로 변경되면 후속 PCRpt 메시지에는 실제 메트릭이 포함되지 않습니다.

PCRpt 메시지에서 최적화 메트릭 전송

최적화 메트릭은 PCRpt 메시지의 을(를) 통해 PCE로 전송됩니다.intended-attributes-list 메트릭 값은 0으로 설정되고 B, C 플래그는 0으로 설정됩니다. 메트릭 유형은 최적화할 메트릭을 나타냅니다.

PCRpt 메시지에서 계산된 메트릭 보내기

계산된 메트릭은 PCRpt 메시지의 을(를) 통해 PCE로 전송됩니다.actual-attributes-list 메트릭 값은 계산된 메트릭 값이고 메트릭 유형은 계산된 메트릭 유형을 나타냅니다. B 플래그는 0으로 설정되고, C 플래그는 1로 설정됩니다.

경로 메트릭에 대한 이전 버전과의 호환성

경로 메트릭은 벤더 TLV를 사용하여 지원되므로 PCC는 Northstar 및 Paragon Pathfinder의 이전 릴리스를 지원하는 주니퍼 PCE에서 메트릭 개체로 전송된 경로 메트릭을 처리하지 않습니다.

LSP에 대한 최적화 메트릭 구성

RSVP LSP 및 SR-TE LSP에 대한 최적화 메트릭(IGP, TE 및 경로 지연)을 구성할 수 있습니다.

RSVP LSP에 대한 IGP, TE 및 경로 지연 최적화 메트릭을 구성하려면 [] 계층 수준에서 CLI 문을 포함합니다.metric-type <igp|te|delay|delay minimum>edit protocols mpls label-switched-path <lsp-name>

SR-TE LSP에 대한 IGP, TE 및 경로 지연 최적화 메트릭을 구성하려면 [] 계층 수준에서 CLI 문을 포함합니다.metric-type <igp|te|delay|delay minimum>edit protocols source-packet-routing compute-profile <compute-profile-name>

샘플 출력

및 CLI 명령을 사용하여 PCC(Path Computation Client)에 알려진 LSP(Label-Switched Path)의 상태를 표시할 수 있습니다.show path-computation-client lspshow path-computation-client lsp extensive

다음은 의 샘플 출력입니다.show path-computation-client lsp extensive

출력은 LSP가 메트릭 유형 IGP로 최적화되었음을 보여줍니다. IGP 메트릭의 계산 값은 50입니다. 라우팅 테이블에 설치된 라우팅 메트릭은 50입니다.

변경 내역 표

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

릴리스
설명
21.R1
Junos OS 릴리스 21.1R1부터 Junos OS는 PCE 시작 RSVP 기반 포인트-투-포인트 및 포인트-투-멀티포인트 LSP를 위한 NSR(Nonstop Active Routing)을 지원합니다.
21.R1
Junos OS 릴리스 21.1R1부터 Junos OS는 PCE 시작 RSVP 기반 Point-to-Multipoint LSP를 위한 NSR(Nonstop Active Routing)을 지원합니다.
20.2R1
Junos OS 릴리스 20.2R1부터 BGP 레이블 유니캐스트(BGP-LU)는 IPv4 및 IPv6 주소 패밀리 모두에 대해 SR-TE(세그먼트 라우팅-트래픽 엔지니어링)를 통해 IPv4 또는 IPv6 경로를 확인할 수 있습니다.
19.4R1
단일 또는 다양한 MVPN 멀티캐스트 플로우(S,G)를 동적으로 생성된 PCE 시작 LSP(Point-to-Multipoint Label-Switched Path)에 연결할 수 있습니다.
19.4R1
PCE 시작 세그먼트 라우팅 LSP에 대한 터널 템플릿을 구성하여 이러한 LSP에 대한 두 가지 추가 매개 변수인 BFD(Bidirectional Forwarding Detection) 및 LDP 터널링을 전달할 수 있습니다.
19.1R1
Junos OS 릴리스 19.1R1부터 커밋 확인 기능이 도입되어 컬러 경로에 기여하는 모든 세그먼트 목록이 모든 홉에 대해 존재하는 최소 레이블을 갖도록 합니다.
19.1R1
Junos OS 릴리스 19.1R1부터는 무색 정적 LSP의 첫 번째 홉이 이제 IP 주소 외에도 SID 레이블에 대한 지원을 제공하므로 이 요구 사항이 적용되지 않습니다. 첫 번째 홉 레이블 지원으로, 색상이 지정된 정적 LSP와 유사하게 정적 비색상 세그먼트 라우팅 LSP를 해결하기 위해 MPLS FRR(Fast Reroute) 및 가중 동일 비용 다중 경로가 활성화됩니다.
18.2R1
Junos OS 릴리스 18.2R1부터 수신 디바이스에서 정적으로 구성된 무색 세그먼트 라우팅 LSP는 PCEP(Path Computation Element Protocol) 세션을 통해 PCE(Path Computation Element)에 보고됩니다.
17.2R1
Junos OS 릴리스 17.2 부터 PCE 제어 LSP에 대해 두 가지 새로운 경로 계산 유형이 도입되었습니다.external cspf local cspfno cspf.
16.1
Junos OS 릴리스 16.1부터 RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호할 수 있습니다.
16.1
Junos OS 릴리스 16.1에는 RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호하는 기능이 도입되었습니다.
14.2R4
Junos OS 릴리스 14.2R4부터 PCE 제어 LSP에 대한 자동 대역폭 지원이 제공됩니다.