Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP 구성

최소 RSVP 구성

단일 인터페이스에서 RSVP를 활성화하려면 명령문을 포함하고 명령문을 사용하여 rsvp 인터페이스를 interface 지정합니다. 최소 RSVP 구성입니다. 기타 모든 RSVP 구성 명령문은 선택 사항입니다.

다음과 같은 계층 수준에 이러한 진술을 포함할 수 있습니다.

  • [edit protocols]

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

모든 인터페이스에서 RSVP를 활성화하려면 all 변수를 interface-name 대신합니다.

인터페이스 그룹에 인터페이스 속성을 구성하고 인터페이스 중 하나에서 RSVP를 비활성화하려는 경우 다음과 같은 명령문을 disable 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp interface interface-name ]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name ]

RSVP 및 MPLS

Junos RSVP 소프트웨어의 주된 목적은 LSP(Label-Switched Path) 내에서 동적 시그널링을 지원하는 것입니다. 라우터에서 MPLS RSVP를 모두 활성화하면 MPLS RSVP 클라이언트가 됩니다. RSVP 및 RSVP를 연계하는 데 추가 구성이 MPLS 필요하지 않습니다.

계층 수준에서 명령문을 MPLS 신호 전송 경로를 설정하도록 label-switched-path 구성할 [edit protocols mpls] 수 있습니다. 각 LSP는 RSVP가 RSVP 세션을 시작하기 위한 요청으로 변환됩니다. 이 요청은 Label 스위칭과 RSVP 간의 내부 인터페이스를 통과합니다. 요청 정보를 검토하고 RSVP 상태 확인 및 로컬 라우팅 테이블을 확인한 후 RSVP는 각 LSP에 대해 하나의 세션을 시작됩니다. 세션은 로컬 라우터에서 도출되어 LSP 대상을 대상으로 지정됩니다.

RSVP 세션이 성공적으로 생성되면 RSVP 세션에서 생성한 경로를 따라 LSP가 설정됩니다. RSVP 세션에 실패한 경우 RSVP는 해당 MPLS 통보합니다. 백업 경로를 MPLS 계속 재시도하는 것은 최대치입니다.

레이블 스위칭 시그널링 정보를 전달하기 위해 RSVP는 Label Request object, Label object, Explicit Route 객체 및 Record Route 객체. LSP를 성공적으로 설정하려면 경로에 있는 모든 라우터는 MPLS, RSVP 및 4개 객체를 지원해야 합니다. 4개 객체 중, Record Route 객체는 필수가 아닙니다.

RSVP MPLS 구성하고 이를 RSVP 클라이언트로 구성하기 위해 다음을 실행하십시오.

  • 레이블 MPLS 참여하는 모든 라우터에서 보안 기능을 활성화합니다(이는 레이블 스위칭 경로의 일부일 수 있는 모든 라우터에 해당).

  • LSP를 형성하는 모든 라우터 인터페이스와 모든 라우터 인터페이스에서 RSVP를 활성화합니다.

  • LSP 시작에 라우터를 구성합니다.

예를 들면 다음과 같습니다. RSVP 및 MPLS

다음은 LSP 시작 시 라우터에 대한 샘플 구성을 보여줍니다.

다음은 LSP를 형성하는 다른 모든 라우터에 대한 샘플 구성을 보여줍니다.

RSVP 인터페이스 구성

다음 섹션에서는 RSVP 인터페이스를 구성하는 방법을 설명합니다.

RSVP 리프레시 감소 구성

인터페이스 구성에 다음과 같은 명령문을 포함해 각 인터페이스에서 RSVP 리프레시 감소를 구성할 수 있습니다.

  • aggregatereliable —모든 RSVP 리프레시 감소 기능 사용: RSVP 메시지 번들링, RSVP 메시지 ID, 안정적인 메시지 전송 및 요약 새로 고침.

    리프레시 절감 및 안정적인 제공을 위해서는, 명령문과 진술을 aggregatereliable 포함해야 합니다.

  • no-aggregate—RSVP 메시지 번들링 및 요약 새로 고침을 비활성화하십시오.

  • no-reliable—RSVP 메시지 ID, 안정적인 메시지 전송 및 요약 새로 고침을 비활성화하십시오.

RSVP 리프레시 감소에 대한 자세한 내용은 RSVP Refresh Reduction 을 참조하십시오.

라우터에서 명령문이 구성되면(안정적인 메시지 전송이 비활성화된 경우), 라우터는 Message ID 객체가 포함된 RSVP 메시지를 허용하지만 Message ID 객체를 무시하고 표준 메시지 처리를 계속 no-reliable 실행합니다. 이 경우 오류가 생성되지 않습니다. RSVP는 정상적으로 작동합니다.

그러나 서로 다른 리프레시 리프레시 기능을 갖추고 있는 두 이웃 간의 모든 조합이 올바르게 작동하지는 않습니다. 예를 들어, 명령문과 명령문 또는 명령문을 사용하여 aggregateno-reliablereliableno-aggregate 라우터를 구성합니다. RSVP neighbor가 Summary Refresh 객체를 이 라우터에 전송하면 오류가 생성되지 않지만 Summary Refresh 객체는 처리될 수 없습니다. 결과적으로, 이웃이 Summary Refresh에만 해당 RSVP 상태의 갱신을 위해 필요한 경우, RSVP 상태는 이 라우터에 타임아웃될 수 있습니다.

구체적인 요구 사항이 없는 한, 각 RSVP neighbor에서 유사한 방식으로 RSVP 리프레시 감소를 구성하는 것이 좋습니다.

인터페이스에서 모든 RSVP 리프레시 감소 기능을 활성화하려면 다음 진술을 aggregate 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

RSVP 메시지 번들링 및 요약 새로 고침을 비활성화하기 위해 다음 진술을 no-aggregate 포함하십시오.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

인터페이스에서 RSVP 메시지 ID 및 안정적인 메시지 전송을 활성화하려면 다음 reliable 진술을 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

RSVP 메시지 ID, 신뢰할 수 있는 메시지 전송 및 요약 리프레시를 비활성화하기 위해 다음 진술을 no-reliable 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

RSVP Neighbor의 리프레시 감소 기능 파악

RSVP neighbor의 RSVP 리프레시 감소 기능을 확인하려면 다음 정보가 필요합니다.

  • 이웃에 의해 광고된 RR 비트

  • RSVP 리프레시 감소의 로컬 구성

  • 이웃에서 수신된 실제 RSVP 메시지

이 정보를 얻기 위해 명령어를 발행할 수 show rsvp neighbor detail 있습니다. 샘플 출력은 다음과 같습니다.

명령에 대한 자세한 정보를 show rsvp neighbor detail 원합니다.

RSVP Hello 간격 구성

RSVP는 내부 게이트웨이 프로토콜(IGP)(IS-IS(Intermediate System to Intermediate System) 또는 최단 경로 우선(OSPF)) 이웃의 상태를 모니터링하고 IGP 프로토콜을 사용하여 노드에 장애가 발생하면 이를 탐지합니다. 한 IGP 프로토콜이 이웃(hello 패킷이 더 이상 수신되지 못하기 때문에)을 선언하면 RSVP는 인접한 아래로 내려가게 됩니다. 그러나 인접 IGP 프로토콜과 RSVP는 여전히 독립적으로 운영됩니다.

라우터의 주니퍼 네트웍스 경우, RSVP hello 간격을 짧게 구성하는 것은 RSVP 세션이 다운되는지 여부에 영향을 끼치지 않습니다. RSVP hello 패킷이 더 이상 수신되지 경우에도 RSVP 세션이 유지됩니다. 라우터가 hello 패킷의 수신을 중단하거나 IGP RSVP 경로 및 Resv 메시지가 타임아웃될 때까지 RSVP 세션이 유지 관리됩니다. 그러나, Junos OS Release 16.1에서 시작하여 RSVP hello 메시지가 타임아웃되는 경우 RSVP 세션이 다운됩니다.

RSVP hello 간격은 다른 벤더의 장비가 RSVP 세션을 다운할 때에도 영향을 미칠 수 있습니다. 예를 들어, 인접한 비-주니퍼 네트웍스 라우터를 RSVP hello 패킷을 모니터링하도록 구성할 수 있습니다.

RSVP가 hello 패킷을 얼마나 자주 전송하는지 수정하려면 다음 문을 hello-interval 포함해야 합니다.

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

RSVP 인증 구성

모든 RSVP 프로토콜 교환은 신뢰할 수 있는 이웃들만이 예약 설정에 참여할 수 있습니다. 기본적으로 RSVP 인증은 비활성화됩니다.

RSVP 인증은 HMAC(Hashed Message Authentication Code)-MD5 메시지 기반 다이제스트를 활용합니다. 이 체계는 암호 인증 키와 메시지 내용을 기반으로 메시지 다이제스트를 생성합니다. (메시지 내용에는 시퀀스 번호도 포함됩니다.) 계산된 다이제스트는 RSVP 메시지와 함께 전송됩니다. 인증을 구성하면 모든 이웃을 통해 수신 및 전송된 RSVP 메시지가 이 인터페이스에서 인증됩니다.

MD5 인증은 대대적인 변경 및 메시지 변경을 방지합니다. 또한 리플레이 공격을 차단할 수 있습니다. 그러나 모든 메시지는 투명한 텍스트로 전송되며 기밀을 제공하지 않습니다.

기본적으로 인증은 비활성화됩니다. 인증을 활성화하려면 각 인터페이스의 키를 다음 명령문을 포함해 authentication-key 구성합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

클래스 유형에 대한 대역폭 구독 구성

기본적으로 RSVP는 클래스 유형에 대해 대역폭의 100%를 RSVP 예약에 사용할 수 있습니다. 다중 클래스 LSP에 대해 클래스 유형을 초과 수용하면 모든 RSVP 세션의 총 수요는 클래스 유형의 실제 용량을 초과할 수 있습니다.

클래스 유형에 대한 대역폭 구독을 구성하는 방법에 대한 자세한 지침은 LSP에대한 대역폭 구독 비율 구성을 참조하십시오.

인터페이스에서 RSVP 업데이트 임계값 구성

IGP(Interior Gateway Protocols)는 트래픽 엔지니어링 데이터베이스를 유지하지만, 트래픽 엔지니어링 데이터베이스 링크의 현재 가용 대역폭은 RSVP에서 비로소 제공합니다. 링크의 대역폭이 변경되는 경우 RSVP는 IGP에 알려 트래픽 엔지니어링 데이터베이스를 업데이트하고 새로운 대역폭 정보를 모든 네트워크 노드로 전달할 수 있습니다. 그러면 네트워크 노드가 트래픽 엔지니어링 데이터베이스 링크(로컬 또는 원격)에서 사용할 수 있는 대역폭을 알 수 있으며 CSPF가 경로를 올바르게 계산할 수 있습니다.

그러나 이러한 IGP 과도한 시스템 리소스를 소모할 수 있습니다. 네트워크 노드 수에 따라 대역폭의 작은 변경을 위해 IGP 업데이트를 수행하는 것이 바람직하지 않을 수 있습니다. 계층 수준에서 명령문을 구성하면 예약 대역폭의 변경으로 최대 업데이트가 트리거되는 임계값을 IGP update-threshold[edit protocols rsvp] 수 있습니다.

업데이트 시작 시 0.001%~20%(기본값은 10%)의 IGP 수 있습니다. 예약 대역폭의 변경이 해당 인터페이스에서 구성된 정적 대역폭의 구성된 임계치 비율과 같거나 크면 IGP 업데이트가 발생합니다. 예를 들어, 명령문을 15%로 구성하고 라우터가 링크의 예약 대역폭이 링크 대역폭의 10%까지 변경된 것으로 확인되면 RSVP는 명령어 업데이트를 트리거하지 IGP update-threshold 있습니다. 그러나 링크의 예약 대역폭이 링크 대역폭의 20%까지 변경되면 RSVP는 새로운 IGP 트리거합니다.

명령문에 있는 옵션을 사용하여 임계값을 절대 값으로 threshold-value 구성할 수도 update-threshold 있습니다.

임계값 값이 해당 링크의 대역폭의 20% 이상으로 구성되면 임계값 값은 대역폭의 20%로 제한됩니다.

예를 들어 인터페이스의 대역폭이 1Gbps인 threshold-value 경우, 200Mbps 이상으로 구성되면 threshold-value 200Mbps에 제한됩니다. 임계값%는 20.000%, threshold-value 200Mbps로 표시됩니다.

주:

임계값%(threshold-percent) 및 상호 배타적(threshold-percent) 두 threshold-value 가지 옵션 특정 시점에 단 하나의 옵션만 구성하여 낮은 대역폭 예약을 위한 IGP 업데이트를 생성할 수 있습니다. 그 결과, 하나의 옵션이 구성되면 다른 옵션이 계산되어 네트워크 상에 CLI.

예를 들어, 1Gbps 링크에서 임계값 백분율이 5%로 구성되면 threshold-value 50Mbps로 계산되고 표시됩니다. 마찬가지로, 50m로 구성되면 임계값%가 계산되어 threshold-value 5%로 표시됩니다.

예약 대역폭의 변경이 네트워크 업데이트를 트리거하는 임계값을 IGP 임계값을 조정하기 위해 업데이트 임계값 명령문을 포함합니다. 업데이트 임계값 때문에 CSPF(Constrained Shortest Path First)는 링크에 있는 시간 부족한 트래픽 엔지니어링 데이터베이스 대역폭 정보를 사용하여 경로를 계산할 수 있습니다. RSVP가 해당 경로에 대한 LSP 구축을 시도하면 해당 링크에 대역폭이 부족하다는 것을 발견할 수 있습니다. 이 경우 RSVP는 트래픽 엔지니어링 데이터베이스 IGP 업데이트된 대역폭 정보를 플러드하여 트리거합니다. 그런 다음 CSPF는 업데이트된 대역폭 정보를 사용하여 경로를 재조정하고 다른 경로를 검색하려고 시도하여 정체된 링크를 피할 수 있습니다. 이 기능은 기본 기능으로 추가 구성이 필요하지 않습니다.

PathErr 메시지에서 제공하는 정보를 사용하여 계층 수준 또는 계층 수준에서 명령문을 구성하여 트래픽 엔지니어링 rsvp-error-hold-time 데이터베이스(LSP에 대한 대역폭 추정의 정확성 포함)의 정확성을 향상시킬 [edit protocols mpls][edit logical-systems logical-system-name protocols mpls] 수 있습니다. RSVP Patherr 메시지를 통해 트래픽엔지니어링 데이터베이스 정확성 향상을 확인하십시오.

선택되지 않은 인터페이스에 대한 RSVP 구성

이 Junos OS 인터페이스에서 RSVP 트래픽 엔지니어링을 지원 지정되지 않은 링크에 대한 트래픽 엔지니어링 정보는 RFC 420 최단 경로 우선(OSPF)3에 설명된 바와 같이 IGP 최단 경로 우선(OSPF) 및 IS-IS(Intermediate System to Intermediate System)에 대한 트래픽 엔지니어링 확장, GMPLS(Generalized Multi-Protocol Label Switching) 및 GMPLS(Generalized Multi-Protocol Label Switching)를지원하여 RFC 4205 Intermediate System to Intermediate System IS-IS(Intermediate System to Intermediate System)(IS-IS(Intermediate System to Intermediate System))확장을 지원하는 rfC 4205, IS-IS(Intermediate System to Intermediate System) 확장에 대한 트래픽 엔지니어링 확장에서 수행됩니다. 또한, 지정되지 않은 링크는 RFC 3477, RSVP-트래픽 엔지니어링(TE)(Traffic Engineering)의 RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol에서설명한 바와 같이 신호 전송에 지정할 수도 있습니다. MPLS 트래픽 엔지니어링 이 기능을 사용하면 RSVP 시그널드 네트워크에 참여하는 각 인터페이스에 대해 IP 주소를 구성할 필요를 방지할 수 있습니다.

지정되지 않은 인터페이스에 대해 RSVP를 구성하려면 계층 수준에서 지정된 진술을 사용하여 라우터 ID를 router-id[edit routing-options] 구성해야 합니다. 라우터 ID는 라우팅에 사용할 수 있어야 합니다(일반적으로 루프백 주소를 사용할 수 있습니다). 등록되지 않은 링크에 대한 RSVP 제어 메시지는 라우터 ID 주소(임의 선택된 주소가 아닌)를 사용하여 전송됩니다.

표시되지 않은 인터페이스가 활성화된 라우터에서 링크 보호를 구성하고 빠른 재라우트(fast reroute)를 구성하려면, 최소 2개의 주소를 구성해야 합니다. 라우터 ID 구성과 함께 루프백에서 보조 인터페이스를 구성하는 것이 좋습니다.

RSVP Node-ID Hellos 구성

노드 ID 기반 RSVP hello를 구성하여 주니퍼 네트웍스 라우터가 다른 벤더의 장비와 상호 운영될 수 있도록 보장할 수 있습니다. 기본적으로 Junos OS 인터페이스 기반 RSVP hello를 사용합니다. Node-ID 기반 RSVP hellos는 RFC 4558, Node-ID Based Resource Reservation Protocol(RSVP) Hello에 지정됩니다. A Clarification Statement RSVP node-ID hellos는 RSVP 인터페이스에서 문제를 탐지하기 위해 BFD를 구성한 경우 유용합니다. 이 인터페이스에 대해 인터페이스 Hello를 비활성화할 수 있습니다. Node-ID hello를 사용하여 graceful restart 절차를 할 수도 있습니다.

Node-ID hello는 모든 RSVP neighbor에 대해 전역적으로 활성화할 수 있습니다. 기본적으로 node-ID hello 지원은 비활성화됩니다. 라우터에서 RSVP 노드 ID를 활성화하지 않은 경우 Junos OS hello 패킷은 허용하지 않습니다.

라우터에서 전 세계적으로 RSVP node-ID를 활성화하려면 다음 계층 수준에서 node-hello 명령문을 포함합니다.

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

또한, 전역적으로 RSVP 인터페이스 Hello를 명시적으로 비활성화할 수도 있습니다. 이러한 유형의 구성은 주니퍼 네트웍스 벤더의 장비와 수많은 RSVP 연결이 필요한 네트워크에서 필요합니다. 그러나 전역적으로 RSVP 인터페이스를 비활성화하면 hello 간격 명령문을 사용하여 RSVP 인터페이스에서 hello 간격을 구성할 수도 있습니다. 이 구성은 전역적으로 RSVP 인터페이스를 비활성화하지만, 지정된 인터페이스에서 RSVP 인터페이스 Hello를 활성화합니다(명령문을 구성하는 RSVP hello-interval 인터페이스). 이 구성은 일부 디바이스가 RSVP 노드 ID Hello를 지원하고 다른 디바이스가 RSVP 인터페이스 Hello를 지원하는 이기종 네트워크에서 필요할 수 있습니다.

라우터에서 전역적으로 RSVP 인터페이스를 비활성화하기 위해 다음 계층 수준에서 no-interface-hello 명령문을 포함합니다.

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

예를 들면 다음과 같습니다. RSVP 신호 전송 LSP 구성

이 예에서는 신호 전송 프로토콜로 RSVP를 사용하여 IP 네트워크에서 라우터 간에 LSP를 생성하는 방법을 보여줍니다.

요구 사항

시작 전에 디바이스에서 보안 서비스를 삭제합니다. 예제를 참조합니다. 보안 서비스 삭제.

개요 및 토폴로지

RSVP를 신호 전송 프로토콜로 사용하면 IP 네트워크에서 라우터 간에 LSP를 생성할 수 있습니다. 다음 예제에서와 같이 샘플 네트워크를 그림 1 구성합니다.

토폴로지

그림 1: 일반 RSVP 신호 전송 LSP일반 RSVP 신호 전송 LSP

라우터 간에 LSP를 구축하려면 MPLS 네트워크의 각 전송 인터페이스에서 MPLS RSVP를 MPLS 구성해야 합니다. 다음 예제는 ge-0/MPLS 인터페이스에서 RSVP를 설정하고 구성하는 방법을 보여줍니다. 또한 네트워크의 모든 MPLS 인터페이스에서 MPLS 프로세스가 활성화되어야 합니다.

이 예에서는 R7의 루프백 주소(10.0.9.7)를 사용하여 ingress 라우터(R1)에서 R1에서 R7로 LSP를 정의하는 방법을 보여줍니다. 이 구성은 10Mbps의 대역폭을 예약합니다. 또한, 구성은 CSPF 알고리즘을 비활성화하여 호스트 C1 및 C2가 네트워크 및 최단 경로에 해당하는 RSVP 신호 LSP를 IGP 있도록 보장합니다.

구성

절차

CLI 빠른 구성

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

단계별 절차

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

RSVP 구성:

  1. 네트워크 MPLS 모든 전송 인터페이스에서 MPLS 패밀리를 활성화합니다.

  2. 네트워크 내 각 전송 인터페이스에서 RSVP를 MPLS 활성화합니다.

  3. 네트워크 MPLS 인터페이스에서 MPLS 프로세스를 활성화합니다.

  4. ingress 라우터에서 LSP를 정의합니다.

  5. LSP에서 10Mbps의 대역폭을 예약합니다.

결과

구성 모드에서 명령을 show 입력하여 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제에서 구성 지침을 반복하여 수정합니다.

이 명령 출력에는 이 예제와 관련이 있는 구성만 show 포함됩니다. 시스템의 다른 구성은 타원(...)로 대체되었습니다.

디바이스 구성이 완료되면 commit 구성 모드에서 입력합니다.

확인

구성이 올바르게 작동하고 있는지 확인하려면 다음 작업을 수행합니다.

RSVP Neighbor 검증

목적

각 디바이스가 적절한 RSVP neighbor를 표시하는지 확인합니다. 예를 들어 라우터 그림 1 R1이 라우터 R3과 라우터 R2를 모두 RSVP neighbor로 나열합니다.

실행

이 CLI 명령어를 show rsvp neighbor 입력합니다.

출력은 이웃 라우터의 IP 주소를 보여줍니다. 인접한 각 RSVP 라우터 루프백 주소가 나열되어 있는지 확인합니다.

RSVP 세션 검증

목적

모든 RSVP neighbor 간에 RSVP 세션이 설정된지 확인 또한 대역폭 예약 값이 활성 상태인지 검증합니다.

실행

이 CLI 명령어를 show rsvp session detail 입력합니다.

출력에는 설정된 각 RSVP 세션에 대한 세션 IP, 대역폭 예약 및 넥스 홉 주소 등의 상세 정보가 표시된다. 다음 정보를 검증합니다.

  • 각 RSVP neighbor 주소에는 루프백 주소별로 나열된 각 이웃에 대한 엔트리가 있습니다.

  • 각 LSP 세션의 상태는 Up 입니다.

  • 적절한 대역폭 값이 에 Tspec10Mbps 대해 표시됩니다.

RSVP 신호 전송 LSP의 존재 확인

목적

진입(ingress) 라우터의 라우팅 테이블이 다른 라우터의 루프백 주소에 구성된 LSP가 있는지 검증합니다. 예를 들어, R1 엔트리 라우터의 라우팅 테이블이 Router R7의 루프백 주소에 inet.3 구성된 LSP를 가지는지 그림 1 확인합니다.

실행

이 CLI 명령어를 show route table inet.3 입력합니다.

출력은 라우팅 테이블에 존재하는 RSVP inet.3 경로를 보여줍니다. RSVP 신호 LSP가 네트워크 내 출구(egress) 라우터 R7의 루프백 주소와 MPLS 있는지 검증합니다.

예를 들면 다음과 같습니다. RSVP 자동 메시 구성

서비스 프로바이더들은 종종 BGP(Border Gateway Protocol) 및 MPLS VPN을 사용하여 네트워크를 효율적으로 확장하는 동시에 수익 창출 서비스를 제공합니다. 이러한 환경에서는 BGP(Border Gateway Protocol) VPN 라우팅 정보를 서비스 제공업체의 네트워크 전반에 배포하는 데 사용 반면, MPLS VPN 트래픽을 다른 VPN 사이트로 전달하는 데 사용됩니다.

BGP(Border Gateway Protocol) 및 MPLS VPN에 참여할 새로운 PE 라우터를 추가할 때 기존 PE 라우터는 모두 기존 PE 라우터와 BGP(Border Gateway Protocol) 모두에 대해 새로운 PE 라우터와 피어링하도록 MPLS. 새로운 PE 라우터가 서비스 제공업체의 네트워크에 추가될 때마다 구성 부담이 너무 커지기까지 합니다.

라우팅 리포지터를 BGP(Border Gateway Protocol) 피어링에 대한 구성 요구 사항을 줄일 수 있습니다. RSVP 시그널드 MPLS 네트워크에서 RSVP 자동 메시는 네트워크의 일부분에 대한 구성 MPLS 최소화할 수 있습니다. 모든 PE 라우터에서 구성하면 새 PE 라우터가 추가될 rsvp-te 때 RSVP가 필요한 LSP를 자동으로 생성할 수 있습니다.

요구 사항

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

  • 릴리스 10.1 Junos OS 실행되는 라우터

  • RSVP MPLS를 LSP(MPLS Label-Switched Path) 시그널링 프로토콜로 사용하는 BGP(Border Gateway Protocol) 및 MPLS VPN

개요

이 예에서는 구성 명령문을 사용하여 PE 라우터에서 RSVP 자동 메시를 rsvp-te 구성하는 방법을 보여줍니다. RSVP 자동 메시가 제대로 작동하려면, 풀 메시 구성 모든 PE 라우터가 rsvp-te 명령문을 구성해야 합니다. 명령문으로 구성한 경우, 나중에 추가된 새로운 PE 라우터도 자동 메시 기능의 이점을 받을 수 rsvp-te 있습니다.

이 요구 사항의 경우, 이 예에서는 새로 추가된 PE 라우터의 구성만 보여줍니다. RSVP 자동 메시가 이미 기존 PE 라우터에서 구성된 것으로 가정됩니다.

토폴로지

그림 2토폴로지에는 기존 PE 라우터 3개( PE1, PE2 및 PE3)가 있습니다. PE4가 추가되고 RSVP 자동 메시가 구성됩니다. 클라우드는 서비스 제공업체 네트워크를 나타내며 네트워크 주소(192.0.2.0/24)는 그림 가운데에 표시된다.

그림 2: 서비스 프로바이더 라우터가 있는 네트워크서비스 프로바이더 라우터가 있는 네트워크

구성

RSVP 자동 메시 구성에는 다음 작업을 수행할 수 있습니다.

  • 계층 수준에서 rsvp-te 구성 [edit routing-options dynamic-tunnels dynamic-tunnel-name] 명령문을 활성화합니다.

  • 필수 요소 destination-networks 구성.

    이 구성 요소는 대상 네트워크에 대한 IPv4 Prefix 범위를 지정합니다. 지정된 Prefix 범위 내의 터널만 생성될 수 있습니다.

  • 필수 요소 label-switched-path-template 구성.

    이 구성 요소는 사전 구성된 LSP 템플릿의 이름을 인수로 default-template 만듭니다. 는 사용자 구성이 필요 없는 시스템 default-template 정의 템플릿입니다.

CLI 빠른 구성

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

PE4 라우터

RSVP 자동 메시 구성

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 이를 위한 지침은 에서 Configuration Mode의 CLI 편집자 사용 CLI 참조하십시오.

RSVP 자동 메시 활성화:

  1. 계층 rsvp-te 수준에서 [edit routing-options dynamic-tunnels] 구성합니다.

  2. 계층 destination-networks 수준에서 [edit routing-options dynamic-tunnels] 구성합니다.

결과

계층 수준에서 명령을 실행하여 구성 결과를 show[edit routing-options dynamic-tunnels] 확인:

확인

라우터 PE4에 RSVP 자동 메시 터널이 있는지 검증

목적

새로 구성된 PE4 라우터의 작동을 확인하다가 작동 모드에서 명령을 show dynamic-tunnels database 실행합니다. 이 명령은 동적 터널을 만들 수 있는 대상 네트워크를 보여줄 것입니다.

실행

라우터 PE4에 MPLS LSP가 있는지 검증

목적

PE4 라우터에 MPLS LSP가 있는지 확인하다가 작동 모드에서 명령을 show mpls lsp 발행합니다. 이 명령은 LSP의 MPLS 표시하게 됩니다.

실행

Nonsession RSVP Neighbor에 대한 Hello Acknowledgments 구성

명령문은 동일한 세션에 있는지 여부에 관계없이 hello-acknowledgements RSVP neighbor 간의 hello Acknowledgment 동작을 제어합니다.

일반적인 RSVP 세션의 일부가 아닌 RSVP neighbor에서 수신된 Hello 메시지를 폐기합니다. 계층 수준에서 명령문을 구성하는 hello-acknowledgements[edit protocols rsvp] 경우, 비ssion neighbor의 hello 메시지는 hello acknowledgment 메시지를 통해 수신됩니다. Hello는 비sion neighbor에서 수신될 때 RSVP neighbor 관계를 생성하고 이제 비SSION Neighbor로부터 주기적인 Hello 메시지를 수신할 수 있습니다. hello-acknowledgements명령문은 기본적으로 비활성화됩니다. 이 명령문을 구성하면 hello 패킷을 사용하여 RSVP 지원 라우터를 검색하고 LSP 설정 메시지를 전송하기 전에 인터페이스가 RSVP 패킷을 수신할 MPLS 있습니다.

일단 비SSN(Nonssesion) RSVP neighbor에 대한 hello Acknowledgment를 활성화한 후, 인터페이스 자체가 다운되거나 구성을 변경하지 않는 한 라우터는 계속해서 비SSSion RSVP neighbor의 hello 메시지를 인정합니다. 인터페이스 기반 이웃은 자동으로 노인되지 않습니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

네트워크 노드에서 멀리 떨어져 있는 LSP 스위칭

인터페이스를 위해 우회 LSP를 활성화한 후 네트워크 노드에서 액티브 LSP를 스위칭하도록 라우터를 구성할 수 있습니다. 이 기능은 네트워크를 전송하는 트래픽을 방해하지 않으면서 장치를 교체해야 하는 경우 활성 네트워크를 유지하는 데 사용될 수 있습니다. LSP는 정적 또는 동적일 수 있습니다.

  1. 먼저 비활성화하려는 네트워크 장치를 통과해야 하는 트래픽에 대한 링크 또는 노드 보호를 구성해야 합니다. 제대로 작동하려면 우회 LSP는 보호된 LSP와 다른 논리적 인터페이스를 사용해야 합니다.
  2. 라우터가 네트워크 노드에서 멀리 떨어져 있는 스위칭 트래픽을 시작할 수 있도록 준비하기 위해 다음 always-mark-connection-protection-tlv 명령문을 구성하십시오.

    그런 다음, 라우터는 OAM 기능을 기반으로 트래픽을 대체 경로로 스위칭할 준비를 위해 이 인터페이스를 통과하는 모든 OAM 트래픽에 마킹합니다.

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

    • [edit protocols mpls interface interface-name]

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

  3. 그런 다음 보호된 LSP에서 우회 LSP로 트래픽을 전환하도록 명령문을 구성하여 기본 다운스트림 네트워크 디바이스를 효과적으로 switch-away-lsps 우회해야 합니다. 실제 링크 자체는 이 구성으로 다운되지 않습니다.

    라우터가 네트워크 노드에서 멀리 떨어져 있는 트래픽을 전환하도록 구성하기 위해 다음 진술을 switch-away-lsps 구성합니다.

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

    • [edit protocols mpls interface interface-name]

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

액티브 LSP를 네트워크 노드에서 멀리 스위칭하는 데는 다음과 같은 제한이 있습니다.

  • 스위치-멀리 기능은 MX 시리즈 라우터에서만 지원됩니다.

  • 스위치-멀리 기능은 기본 Point-to-Multipoint LSP에서 점대다점 LSP를 우회하기 위해 트래픽을 스위칭하는 데 지원되지 않습니다. Point-to-Multipoint LSP에 대한 명령문을 구성하는 경우, 트래픽은 switch-away-lsps Bypass Point-to-Multipoint LSP로 스위칭되지 않습니다.

  • 동적 LSP 경로를 따라 인터페이스에서 스위치 멀리 기능을 구성하는 경우 해당 경로에 새로운 동적 LSP를 설정하지 못합니다. 스위치 어시멀(switch-away) 기능은 RSVP 신호 LSP의 기능이 중단되기 전의 동작을 방지합니다. 깨지기 전에 동작은 일반적으로 라우터가 원래의 구성을 끊기 전에 동적 LSP에 다시 신호를 재시작하려고 시도합니다.

RSVP 설정 보호 구성

시설 백업 Fast Reroute 메커니즘을 구성하여 신호 전송 중 LSP에 대한 설정 보호 기능을 제공할 수 있습니다. 점대점(point-to-point) LSP와 Point-to-Multipoint LSP가 모두 지원됩니다. 이 기능은 다음 시나리오에서 적용할 수 있습니다.

  1. LSP 신호가 전달되기 전에 실패한 링크 또는 노드가 LSP의 엄격한 명시적 경로에 존재합니다.

  2. 링크 또는 노드를 보호하는 우회 LSP도 있습니다.

  3. RSVP는 우회 LSP를 통해 LSP에 신호를 전송합니다. LSP는 원래 기본 경로를 따라 설정한 것으로 나타나 링크 또는 노드 장애로 인한 우회 LSP에 장애가 발생했습니다.

  4. 링크 또는 노드가 복구된 경우 LSP는 자동으로 기본 경로로 되찾을 수 있습니다.

LSP 설정 보호를 사용하려는 LSP 경로를 따라 각 라우터의 명령문을 setup-protection[edit protocols rsvp] 구성해야 합니다. 또한 LSP 경로의 IGP 트래픽 엔지니어링을 구성해야 합니다. 명령어를 발행하여 show rsvp session LSP가 PLR(Point of Local Repair) 또는 병합 지점의 역할을 하는 라우터에서 설정 보호 기능을 활성화하고 있는지 여부를 판단할 수 있습니다.

RSVP 설정 보호를 활성화하려면 setup-protection 명령문을 포함

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

RSVP LSP 전반의 로드 밸런싱 구성

기본적으로 여러 RSVP LSP를 동일한 Egress 라우터에 구성한 경우 최저 메트릭을 사용하는 LSP가 선택되어 모든 트래픽을 실행합니다. 모든 LSP가 동일한 메트릭을 가지는 경우, LSP 중 하나가 임의로 선택되어 모든 트래픽이 그 위에 포워드됩니다.

또는 패킷당 로드 밸런싱을 통해 모든 LSP 전반의 트래픽에 대한 로드 밸런싱을 할 수 있습니다.

수신 LSP에서 패킷당 로드 밸런싱을 활성화하려면 다음과 policy-statement 같이 명령문을 구성합니다.

그런 다음 이 명령문을 내보내기 정책으로 포링 테이블에 적용해야 합니다.

패킷당 로드 밸런싱이 적용되고 나면 트래픽은 LSP 간에 동일하게 분산됩니다(기본적으로).

PFE FAST Reroute를 활성화하려면 패킷당 로드 밸런싱을 구성해야 합니다. PFE Fast Reroute를 활성화하려면, 재라우트가 있을 수 있는 각 라우터의 구성에 이 섹션에 나와 있는 패킷당 로드 밸런싱에 대한 policy-statement 명령문을 포함합니다. Fast Reroute 구성도 에서 볼 수 있습니다.

또한 각 LSP에 대해 구성된 대역폭의 양에 비례하여 LSP 간의 트래픽을 로드 릴리즈할 수 있습니다. LSP의 구성된 대역폭은 일반적으로 LSP의 트래픽 용량을 반영하기 때문에 이 기능은 외부 링크 전반에 걸쳐 비대칭 대역폭 기능을 통해 네트워크에서 트래픽을 보다 잘 분배할 수 있습니다.

RSVP LSP 로드 밸런싱을 구성하기 위해 다음과 load-balance 같은 옵션을 포함한 명령문을 bandwidth 포함합니다.

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

  • [edit protocols rsvp]

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

진술을 사용할 때 다음 정보를 load-balance 유의하십시오.

  • 명령문을 load-balance 구성하면 현재 LSP 실행 동작을 변경하지 않습니다. 현재 실행 중인 LSP가 새 동작을 사용하기 위해 명령어를 발행할 수 clear mpls lsp 있습니다.

  • 이 명령문은 패킷당 로드 밸런싱을 활성화한 load-balance 수신 LSP에만 적용됩니다.

  • 차별화된 서비스 인식 트래픽 엔지니어링 LSP의 경우, LSP의 대역폭은 모든 클래스 유형의 대역폭을 합산하여 계산됩니다.

RSVP 자동 메시 구성

풀 메시 LSP에 추가된 새로운 PE 라우터에 대해 자동으로 점대점 LSP(Point-to-Point Label-Switched Path)를 설정하도록 RSVP를 구성할 수 있습니다. 이 기능을 활성화하려면 풀 메시의 모든 PE 라우터에 대한 명령문을 rsvp-te 구성해야 합니다.

주:

CCC와 함께 RSVP 자동 메시를 구성할 수 없습니다. CCC는 동적으로 생성된 LSP를 사용할 수 없습니다.

RSVP 자동 메시를 구성하기 위해 다음 rsvp-te 문을 포함합니다.

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

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

또한 RSVP 자동 메시를 활성화하려면 다음 명령문을 구성해야 합니다.

  • destination-networks—대상 네트워크에 대한 IP 버전 4(IPv4) Prefix 범위를 지정합니다. 지정된 IPv4 Prefix 범위 내 동적 터널을 시작할 수 있습니다.

  • label-switched-path-template (Multicast)—이 옵션을 사용하여 명시적으로 기본 템플릿을 구성하거나 이 옵션을 사용하여 default-template 자체적으로 LSP 템플릿을 구성할 수 template-name 있습니다. LSP 템플릿은 동적으로 생성된 LSP에 대한 모델 구성의 역할을 합니다.

RSVP 새로 고침 메시지를 위한 시간 구성

RSVP는

  • refresh-time—갱신 시간은 연속적인 갱신 메시지 생성 사이의 간격을 제어합니다. 갱신 시간의 기본값은 45초입니다. 이 숫자는 명령문의 기본값인 30에서 파생된 것으로 고정 값을 refresh-time 1.5로 곱합니다. 이러한 계산은 RFC 2205와 차이가 있습니다. 이는 갱신 시간이 0.5 ~ 1.5 범위의 임의 값에 의해 배가해야 한다고 기술합니다.

    새로 고침 메시지에는 경로 및 Resv 메시지가 포함됩니다. 업데이트 메시지는 주기적으로 전송됩니다. 따라서 인접 노드의 예약 상태는 타임 아웃되지 않습니다. 각 경로와 Resv 메시지는 리프레시 시간(refresh timer) 값을 전달하며, 수신 노드는 메시지에서 이 값을 추출합니다.

  • keep-multiplier—유지 배수는 1에서 255까지 로컬로 구성된 작은 정수입니다. 기본값은 3입니다. 특정 상태가 부실로 선언되고 삭제되어야 하는 경우, 손실될 수 있는 메시지의 수를 나타냅니다. 계속 배수는 RSVP 상태의 수명에 직접적인 영향을 미치게 됩니다.

예약 상태의 수명을 결정하기 위해 다음 공식을 사용하십시오.

최악의 경우, ( – 1) 연속적인 갱신 메시지는 예약 상태가 삭제되기 keep-multiplier 전에 손실되어야 합니다.

짧은 RSVP hello timer를 구성하는 것은 권장하지 않습니다. 실패한 이웃을 신속하게 발견해야 하는 경우 짧은 IGP(최단 경로 우선(OSPF) 또는 IS-IS(Intermediate System to Intermediate System)) hello timers를 구성합니다.

기본적으로, 갱신 시간(refresh timer) 값은 30초입니다. 이 값을 수정하려면 다음 refresh-time 문을 포함해야 합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

Keep Multiplier의 기본값은 3입니다. 이 값을 수정하려면 다음 keep-multiplier 문을 포함해야 합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

RSVP 세션 사전 준비

대역폭이 모든 RSVP 세션을 처리할 수 없는 경우, RSVP 세션의 사전 할당을 제어할 수 있습니다. 기본적으로 RSVP 세션은 우선 순위가 높은 새로운 세션만이 우선 순위가 지정됩니다.

대역폭이 부족할 때 항상 세션을 선점하기 위해 다음 옵션을 사용하여 preemption 명령문을 aggressive 포함하십시오.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

RSVP 세션 예비 옵션을 사용하지 않도록 preemptiondisabled 설정하십시오.

기본값으로 돌아오면(즉, 우선 순위가 높은 새로운 세션에서만 세션을 예고), 옵션과 함께 preemption 명령문을 normal 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

RSVP에서 최대 전송 단위(MTU) 신호 전송 구성

RSVP에서 최대 전송 단위(최대 전송 단위(MTU)) 시그널링을 구성하려면 ip 패킷이 MPLS 캡슐화되기 전에 패킷을 단편화할 수 있도록 MPLS. 또한 RSVP에서 최대 전송 단위(MTU) 시그널링을 구성해야 합니다. 문제 해결을 위해 패킷 단편화 없이 최대 전송 단위(MTU) 시그널링 단독으로 구성할 수 있습니다.

RSVP에서 최대 전송 단위(MTU) 시그널링을 구성하기 위해 다음 path-mtu 진술을 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

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

다음 섹션에서는 RSVP에서 패킷 단편화 및 최대 전송 단위(MTU) 시그널링을 활성화하는 방법을 설명합니다.

RSVP에서 최대 전송 단위(MTU) 신호 전송 지원

RSVP에서 최대 전송 단위(MTU) 시그널링을 활성화하려면 다음 rsvp mtu-signaling 진술을 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls path-mtu]

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

구성을 커밋하면 다음에 RSVP를 위한 최대 전송 단위(MTU) 동작의 변경이 적용됩니다.

계층 수준에서 mtu-signaling 자체적으로 명령문을 [edit protocols mpls path-mtu rsvp] 구성할 수 있습니다. 이는 문제 해결에 유용할 수 있습니다. 명령문만 구성하면 이 명령을 사용하여 mtu-signaling LSP에 있는 가장 작은 최대 전송 단위(MTU) show rsvp session detail 수 있습니다. show rsvp session detail명령어는 Adspec 객체에서 최대 전송 단위(MTU) 전송된 값을 나타냅니다.

패킷 단편화 활성화

IP 패킷이 캡슐화되기 전에 단편화될 수 있도록 MPLS 진술을 allow-fragmentation 포함해야 합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls path-mtu]

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

    주:

    명령문을 allow-fragmentation 단독으로 구성하지 말 것. 명령문과 함께 항상 mtu-signaling 구성합니다.

LSP를 위한 궁극의 홉 핑 구성

기본적으로 RSVP 신호 LSP는 PHP(Penultimate-hop popping)를사용됩니다.그림 3 라우터 PE1과 라우터 PE2 간의 Penultimate-hop Popping LSP를 보여줌 Router CE1은 패킷을 다음 홉(Router PE1)으로 전달합니다. 이는 LSP 수신입니다. Router PE1은 패킷에서 Label 1을 푸시하고 레이블이 지정한 패킷을 라우터 P1로 전달합니다. Router P1은 표준 MPLS Label 스왑 교체 작업을 완료하고 Label 2에 대한 Label 1을 교체하고 패킷을 Router P2로 전달합니다. Router P2는 LSP에서 Router PE2로의 Penultimate-hop 라우터이기 때문에 먼저 레이블을 파핑한 다음 패킷을 Router PE2로 전달합니다. Router PE2가 이를 수신하면 패킷은 서비스 레이블, 명시적-null 레이블을 갖거나 일반 IP 또는 VPLS 패킷일 수 있습니다. Router PE2는 불명확한 패킷을 Router CE2로 전달합니다.

그림 3: LSP를 위한 Penultimate-Hop PoppingLSP를 위한 Penultimate-Hop Popping

또한 RSVP 신호LSP에대해 궁극의 홉 핑(UHP)(에 표시된 그림 4 것)을 구성할 수 있습니다. 일부 네트워크 애플리케이션은 패킷이 null 외장 레이블이 없는 egress 라우터(Router PE2)에 도착해야 할 수 있습니다. 궁극의 홉(hop) LSP를 위해 Penultimate 라우터(Router P2 in)는 패킷을 egress Router PE2로 전달하기 전에 표준 MPLS Label 스왑 교체 작업(이 예에서는 그림 4 Label 3용 Label 2)을 수행합니다. Router PE2는 아우터 레이블을 팝업하고 패킷 주소의 두 번째 룩업을 수행하여 최종 대상을 확인합니다. 그런 다음 패킷을 해당 목적지(Router CE2 또는 Router CE4)로 전달합니다.

그림 4: LSP를 위한 궁극의 홉 핑(Hop Popping)LSP를 위한 궁극의 홉 핑(Hop Popping)

다음 네트워크 애플리케이션은 UHP LSP를 구성해야 합니다.

  • MPLS 및 인밴드 OAM을 위한 MPLS-TP

  • 에지 보호 가상 회로

UHP 동작을 지원하지 않는 기능은 다음과 같습니다.

  • LDP 신호 전송 LSP

  • 정적 LSP

  • 점대다점 LSP

  • CCC

  • traceroute 명령

UHP 동작에 대한 자세한 내용은 RSVP-트래픽 엔지니어링(TE) LSP를위한 인터넷 draft-draft-ietf-mpls-rsvp-te-no-php-oob 매핑-01.txt, 비 PHP 동작 및 대역 외 매핑 을 참조하십시오.

점대점(point-to-point) RSVP 신호 LSP의 경우, UHP 동작은 LSP 수신에서 시그널링됩니다. 수신 라우터 구성에 따라 RSVP는 비 PHP 플래그 집합을 사용하여 UHP LSP를 시그널링할 수 있습니다. RSVP PATH 메시지는 LSP-ATTRIBUTES 객체에서 두 플래그를 전달합니다. egress 라우터가 PATH 메시지를 수신하면, LSP에 non-null Label을 할당합니다. 또한 RSVP는 mpls.0 라우팅 테이블에서 2개의 라우트를 생성하고 설치합니다. S는 label 스택의 MPLS 여부를 나타내는 MPLS 비트를 나타냅니다.

  • Route S=0—스택에 레이블이 더 많이 있는 것을 나타 내포합니다. 다음 홉은 mpls.0 라우팅 테이블을 표시하고, 스택에서 나머지 MPLS 레이블 룩업을 트리거하여 나머지 MPLS 레이블을 검색합니다.

  • Route S=1—더 이상 레이블이 없음을 나타냅니다. 다음 홉은 플랫폼이 체인 및 다중 패밀리 룩업을 지원할 경우 inet.0 라우팅 테이블을 밝힙니 다. 또는 Label Route는 VT 인터페이스를 지정하여 IP 포우링을 시작할 수 있습니다.

UHP LSP를 사용하는 경우, Layer 3 VPN MPLS VPLS, Layer 2 VPN 및 Layer 2 회로와 같은 애플리케이션은 UHP LSP를 사용할 수 있습니다. UHP LSP가 다양한 유형의 애플리케이션에 미치는 영향을 MPLS 설명하고 있습니다.

  • Layer 2 VPN 및 Layer 2 회로—패킷은 2개의 레이블이 있는 PE 라우터(UHP LSP의 Egress)에 도착합니다. 외부 레이블(S=0)은 UHP Label, Inner Label(S=1)은 VC Label입니다. 전송 레이블에 기반한 룩업은 mpls.0 라우팅 테이블에 대한 테이블 취급을 결과로 이루어 습니다. 내부 레이블에 해당하는 mpls.0 라우팅 테이블에 추가 경로가 있습니다. 내부 레이블에 기반한 룩업은 고객 에지(CE) 넥스 홉(next hop)으로 연결됩니다.

  • Layer 3 VPN—패킷은 2개의 레이블이 있는 PE 라우터(UHP LSP의 Egress)에 도착합니다. 외부 레이블(S=0)은 UHP Label, 내부 레이블은 VPN Label(S=1)입니다. 전송 레이블에 기반한 룩업은 mpls.0 라우팅 테이블에 대한 테이블 처리의 결과입니다. 이 시나리오에는 두 가지 사례가 있습니다. 기본적으로 레이어 3 VPN은 다음 홉 레이블을 광고합니다. 내부 레이블에 기반한 룩업은 네트워크 라우터로 향하는 다음 고객 에지(CE) 결과입니다. 그러나 Layer 3 VPN 라우팅 인스턴스에 대한 명령문을 구성한 경우, 내부 vrf-table-labelLSI Label은 VRF 라우팅 테이블을 지정합니다. VRF 라우팅 테이블에 대한 IP 룩업도 완료됩니다.

    주:

    명령문으로 구성된 Layer 3 VPN용 UHP는 MX 시리즈 5G 네트워크에서만 지원 유니버설 라우팅 플랫폼 vrf-table-label 있습니다.

  • VPLS—패킷은 2개의 레이블이 있는 PE 라우터(UHP LSP의 Egress)에 도착합니다. 외부 레이블은 전송 레이블(S=0)으로, 내부 레이블은 VPLS Label(S=1)입니다. 전송 레이블에 기반한 룩업은 mpls.0 라우팅 테이블에 대한 테이블 처리의 결과입니다. mpls.0 라우팅 테이블의 내부 레이블에 기반한 룩업은 터널 서비스가 구성되지 않은 경우(또는 VT 인터페이스를 사용할 수 없는 경우) VPLS 라우팅 인스턴스의 LSI 터널 인터페이스에 표시됩니다. MX 3D 시리즈 라우터는 연쇄 룩업 및 멀티 패밀리 룩업을 제공합니다.

    주:

    명령문으로 구성된 VPLS용 UHP는 no-tunnel-service MX 3D 시리즈 라우터에서만 지원됩니다.

  • IPv4는 MPLS—패킷은 하나의 Label(S=1)을 통해 PE 라우터(UHP LSP의 Egress)에 도착합니다. 이 레이블에 기반한 룩업은 VT 터널 인터페이스를 반환합니다. 패킷을 전달할 위치를 결정하기 위해 VT 인터페이스에서 또 다른 IP 룩업이 완료됩니다. 라우팅 플랫폼이 멀티 패밀리 및 체인 룩업(예: MX 3D 라우터 및 PTX 시리즈 패킷 전송 라우터), inet.0 라우팅 테이블에 대한 레이블 경로(S=1) 지점에 기반한 룩업을 지원하는 경우

  • IPv6 over MPLS—2의 레이블 MPLS 통해 IPv6 터널링이 서로에게 IPv6 경로를 표시하는 경우. IPv6에 대한 명시적 null 레이블입니다. 그 결과 원격 PE 라우터에서 학습된 IPv6 라우트의 포워링 다음 홉은 일반적으로 2개의 레이블을 푸시합니다. 내부 레이블은 2입니다(광고 PE 라우터가 다른 벤더의 경우 다를 수 있으며), 라우터 레이블은 LSP 레이블입니다. 패킷은 2개의 레이블이 있는 PE 라우터(UHP LSP의 egress)에 도착합니다. 외부 레이블은 전송 레이블(S=0)으로, 내부 레이블은 IPv6 explicit-null Label(Label 2)입니다. mpls.0 라우팅 테이블의 내부 레이블에 기반한 룩업은 mpls.0 라우팅 테이블로 다시 리디렉션됩니다. MX 3D 시리즈 라우터에서, 내부 레이블(Label 2)이 제거되어 IPv6 룩업은 inet6.0 라우팅 테이블을 사용하여 수행됩니다.

  • PHP 및 UHP LSP를 모두 활성화하면 동일한 네트워크 경로에서 PHP 및 UHP LSP를 모두 구성할 수 있습니다. 명령문이 있는 정규 표현식을 사용하여 LSP 다음 홉 포우링을 선택하여 PHP 및 UHP 트래픽을 분리할 수 install-nexthop 있습니다. 또한 단순히 LSP의 이름을 적절하게 이름화하여 트래픽을 구분할 수도 있습니다.

다음 명령문은 LSP를 위한 궁극적인 홉(hop) popping을 가능하게 합니다. 특정 LSP 또는 라우터에서 구성된 모든 ingress LSP에 대해 이 기능을 사용할 수 있습니다. LSP ingress에서 라우터에서 이러한 명령문을 구성합니다.

  1. 궁극적인 홉(hop) popping을 활성화하려면 다음 ultimate-hop-popping 문을 포함해야 합니다.

    계층 수준에서 이 [edit protocols mpls label-switched-path label-switched-path-name] 명령문을 포함하여 특정 LSP에서 궁극적인 홉(ultimate-hop) popping을 활성화합니다. 계층 수준에서 이 명령문을 포함하면 라우터에서 구성된 모든 [edit protocols mpls] ingress LSP에 대한 궁극적인 홉(hop) popping을 지원할 수 있습니다. 동일한 계층 수준 하에서 ultimate-hop-popping[edit logical-routers] 명령문을 구성할 수 있습니다.

    주:

    궁극의 홉(hop) popping을 활성화하면 RSVP가 중단되기 전에 궁극적인 홉 Popping LSP로 기존 LSP를 재지정하려고 시도합니다. egress 라우터가 궁극의 홉(hop) popping을 지원하지 않는 경우, 기존 LSP가 해체됩니다(RSVP는 LSP 경로를 따라 PathTear 메시지를 전송하여 경로 상태 및 종속 예약 상태를 제거하고 관련 네트워킹 리소스를 분리합니다).

    궁극의 홉(ultimate-hop) popping을 비활성화하면 RSVP는 중단되기 전에 기존 LSP를 Penultimate-hop popping LSP로 재지정합니다.

  2. MX 3D 시리즈 라우터에서만 궁극의 홉 포핑(hop-popping)과 연쇄형 넥스트 홉(chained next hop)을 활성화하려면 다음 명령문에 대한 옵션을 구성해야 enhanced-ipnetwork-services 합니다.

    계층 수준에서 이 [edit chassis] 명령문을 구성합니다. 명령문을 구성한 후 UHP 동작을 활성화하려면 라우터를 network-services 재부팅해야 합니다.

궁극적인 홉 라우터에서 Label을 팝업으로 RSVP 구성

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

주:

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

RSVP에 대한 궁극적인 홉 Popping을 구성하기 위해 다음 explicit-null 문을 포함:

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

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

Point-to-Multipoint LSP에서 궁극의 홉 핑(hop popping) 활성화

기본적으로 점대점(point-to-point) LSP와 Point-to-Multipoint LSP 모두에서 페울티트 홉(penultimate-hop) popping이 트래픽에 MPLS 사용됩니다. MPLS LSP의 egress 라우터 직전에 라우터의 패킷에서 MPLS 제거됩니다. 그런 다음 일반 IP 패킷이 egress 라우터로 전달됩니다. 궁극적인 홉(hop) popping을 위해 egress 라우터는 MPLS 레이블을 제거하고 일반 IP 패킷을 처리합니다.

특히 전송 트래픽이 동일한 Egress 디바이스를 통과하는 경우, 점대다점 LSP에서 궁극의 홉(hop) popping을 활성화하는 데 도움이 될 수 있습니다. 궁극의 홉(hop) popping을 활성화하면 수신 링크를 통해 트래픽의 단일 복사본을 전송하여 상당한 대역폭을 절약할 수 있습니다. 기본적으로 궁극적인 홉(ultimate-hop) popping은 비활성화됩니다.

명령문을 구성하여 Point-to-Multipoint LSP에 대한 궁극적인 홉 포핑(hop popping)을 tunnel-services 활성화할 수 있습니다. 궁극의 홉(hop) popping을 활성화하면 Junos OS 사용할 수 있는 가상 루프백 터널(VT) 인터페이스 중 하나를 선택하여 IP 포우링을 위해 패킷을 PFE로 루프백합니다. 기본적으로 VT 인터페이스 선택 프로세스가 자동으로 수행됩니다. 대역폭 지원 제어는 하나의 VT 인터페이스에서 사용할 수 있는 LSP의 수를 제한하는 데 사용됩니다. 일단 모든 대역폭이 하나의 인터페이스에서 소비되고 나면 Junos OS 제어를 위한 충분한 대역폭이 있는 다른 VT 인터페이스를 선택합니다.

LSP가 모든 VT 인터페이스에서 사용할 수 있는 것보다 더 많은 대역폭을 필요로 하는 경우, 궁극적인 홉 Popping을 활성화할 수 없습니다. 대신 Penultimate-hop popping을 활성화합니다.

Point-to-Multipoint LSP에서 궁극의 홉 포핑(hop popping)이 제대로 작동하려면, egress 라우터는 터널 서비스 PIC 또는 적응형 서비스 PIC와 같은 터널 서비스를 제공하는 PIC를 있어야 합니다. 최종 MPLS 레이블을 터프하고 IP 주소 룩업을 위한 패킷을 반환하기 위해 터널 서비스가 필요합니다.

명령문에 대한 옵션을 포함하여 RSVP 트래픽을 처리하는 VT 인터페이스를 명시적으로 devices 구성할 수 tunnel-services 있습니다. 이 devices 옵션을 사용하면 RSVP에서 사용할 VT 인터페이스를 지정할 수 있습니다. 이 옵션을 구성하지 않는 경우 라우터에서 사용할 수 있는 모든 VT 인터페이스를 사용할 수 있습니다.

라우터에서 egress point-to-multipoint LSP에 대한 궁극적인 홉 Popping을 활성화하려면 다음 명령문을 tunnel-services 구성하십시오.

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

  • [edit protocols rsvp]

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

egress Point-to-Multipoint LSP에 대해 궁극적인 홉 Popping을 활성화하려면 다음 옵션을 사용하여 interface 명령문을 구성해야 all 합니다.

계층 수준에서 이 [edit protocols rsvp] 명령문을 구성해야 합니다.

RSVP 프로토콜 트래픽 추적

RSVP 프로토콜 트래픽을 추적하기 위해 다음 traceoptions 명령문을 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols rsvp]

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

RSVP 명령문에서 RSVP별 플래그를 지정할 수 traceoptions 있습니다.

명령문을 사용하여 추적 작업의 출력을 수신하는 파일의 이름을 file 지정합니다. 모든 파일이 디렉토리에 /var/log 배치됩니다. RSVP 추적 출력을 파일에 두는 것이 rsvp-log 좋습니다.

  • all—모든 추적 운영.

  • error—탐지된 모든 오류 조건

  • event—RSVP 관련 이벤트(RSVP graceful restart와 관련된 이벤트를 추적하는 데 도움이 됩니다.

  • lmp—LMP(RSVP-Link Management Protocol) 상호 작용

  • packets—모든 RSVP 패킷

  • path—모든 경로 메시지

  • pathtear—PathTear 메시지

  • resv—Resv 메시지

  • resvtear—ResvTear 메시지

  • route—라우팅 정보

  • state—RSVP 신호 LSP가 설정 및 다운되는 경우를 비롯한 세션 상태 전환

주:

CPU가 매우 바쁘게 들 수 있기 때문에 trace 플래그 및 플래그 alldetail 수정자를 주의하십시오.

RSVP 추적 옵션을 사용할 때 생성된 로그 파일을 확인하려면 명령문을 사용하여 지정한 파일이 있는 명령을 show log file-namefile-nametraceoptions 발행합니다.

추적 및 글로벌 추적 옵션에 대한 일반 정보는 라우팅 디바이스를 위한 Junos OS 라우팅 프로토콜 라이브러리 를 참조하십시오.

예제: RSVP 프로토콜 트래픽 추적

RSVP 경로 메시지 추적 세부 사항:

모든 RSVP 메시지 추적:

모든 RSVP 오류 조건을 추적합니다.

추적 RSVP 상태 전환:

RSVP 로그 파일 출력

다음은 플래그 구성을 통해 RSVP 추적 옵션을 활성화한 라우터에서 명령을 발행하여 생성된 샘플 show log file-namestate 출력입니다. RSVP 신호 LSP E-D는 3월 11일 14:04:36.707092에서 해소된 것으로 나타났습니다. 3월 11일 14:05:30.101492가 다시 시작된 것으로 나타났습니다.

RSVP Graceful Restart

RSVP graceful restart를 통해 재시작을 진행하는 라우터가 인접 이웃에 해당 조건을 알릴 수 있습니다. 재시작 라우터는 이웃 또는 피어로부터 유예 기간을 요청하고 재시작 라우터와 연동할 수 있습니다. 재시작 라우터는 재시작 기간 MPLS 트래픽을 포우링할 수 있습니다. 네트워크의 컨버전스가 중단되지 않습니다. 재시작은 네트워크의 나머지는 볼 수 없습니다. 그리고 재시작 라우터는 네트워크 토폴로지에서 제거되지 않습니다. 전송 라우터와 ingress 라우터 모두에서 RSVP graceful restart를 사용할 수 있습니다. 점대점(point-to-point) LSP와 Point-to-Multipoint LSP 모두에서 사용 가능합니다.

RSVP graceful restart는 다음 섹션에서 설명합니다.

RSVP Graceful Restart 용어

재시작 시간(밀리초)

기본값은 60,000밀리초(1분)입니다. 재시작 시간이 hello 메시지에 표시됩니다. 시간 은 라우터가 중단되었다고 선언하고 제거하기 전에 이웃이 재시작 라우터에서 hello 메시지를 수신할 때까지 얼마나 기다려야 하는지를 나타냅니다.

네트워크 Junos OS 시간이 로컬 재시작 시간의 1/3을 넘을 경우 이웃의 공시된 재시작 시간을 까다로워할 수 있습니다. 예를 들어, 기본 재시작 시간이 60초인 경우 라우터는 재시작 이웃에서 hello 메시지를 수신하는 데 20초 이하를 기다립니다. 재시작 시간이 0인 경우, 재시작 이웃을 즉시 종료(declared)할 수 있습니다.

복구 시간(밀리초)

재시작 시간 전에 제어 채널이 설정(hello exchange가 완료된 경우)에만 적용됩니다. 정수(nodal) 장애에만 적용됩니다.

Graceful Restart가 진행 중이면 복구를 완료하는 데 남은 시간이 광고됩니다. 또 다른 경우, 이 값은 0입니다. 최대 공시된 복구 시간은 2분(120,000밀리초)입니다.

복구 시간 동안 재시작 노드는 이웃의 도움을 통해 손실된 상태의 복구를 시도합니다. 재시작 노드의 이웃은 복구 시간의 절반 내에 복구 레이블이 있는 경로 메시지를 재시작 노드로 전송해야 합니다. 재시작 노드는 알려지기 전 복구 시간 이후에 Graceful Restart가 완료된 것으로 고려합니다.

RSVP Graceful Restart 작동

RSVP graceful restart가 작동하려면 해당 기능을 글로벌 라우팅 인스턴스에서 활성화해야 합니다. RSVP graceful restart는 프로토콜 수준에서(RSVP 단독의 경우) 또는 모든 프로토콜의 글로벌 수준에서 비활성화될 수 있습니다.

RSVP graceful restart를 위해서는 재시작 라우터와 라우터의 이웃이 필요합니다.

  • 재시작 라우터의 경우, RSVP graceful restart를 시도하여 RSVP와 할당된 레이블이 설치한 경로를 유지하여 트래픽을 중단 없이 계속 포우링합니다. RSVP graceful restart는 인접 노드에 대한 영향을 줄이거나 제거할 수 있을 정도로 빠르게 수행됩니다.

  • 인접한 라우터는 RSVP graceful restart 도우미 모드를 활성화해야 하므로 RSVP를 재시작하려는 라우터를 지원할 수 있어야 합니다.

RSVP hello 메시지로 전송되는 Restart Cap라는 객체는 노드의 재시작 기능을 광고합니다. 인접 노드는 Label 복구 객체를 다시 시작 노드로 전송하여 포우링 상태를 복구합니다. 이 객체는 기본적으로 노드가 다운되기 전에 재시작 노드가 광고하는 오래된 레이블입니다.

다음 목록은 구성 및 활성화된 기능에 따라 달라지는 RSVP graceful restart 동작입니다.

  • 도우미 모드를 비활성화하면 Junos OS RSVP를 다시 시작하는 데 도움이 되지 않습니다. 이웃의 Restart Cap 객체와 함께 도착하는 모든 정보는 무시됩니다.

  • 라우팅 인스턴스 구성에서 graceful restart를 활성화하면 라우터가 이웃의 도움으로 graceful restart될 수 있습니다. RSVP는 재시작 및 복구 시간을 지정하는 hello 메시지에 RSVP RESTART(Restart Cap Object)를 광고합니다(두 값 모두 0은 아닙니다).

  • 계층 수준에서 RSVP graceful restart를 명시적으로 비활성화하면 Restart Cap 객체는 0으로 지정된 재시작 및 복구 시간으로 [protocols rsvp] 표시됩니다. 이웃 라우터의 재시작은 지원되지만(helper 모드가 비활성화되지 않는 한), 라우터 자체가 RSVP 포우링 상태를 보존하지 못하며 제어 상태를 복구할 수 없습니다.

  • 재시작 후 RSVP가 포우링 상태를 보존하지 못했다는 것을 깨달은 경우, Restart Cap 객체는 0으로 지정된 재시작 및 복구 시간으로 알려지게 됩니다.

  • Graceful Restart 및 Helper 모드가 비활성화된 경우 RSVP graceful restart를 완전히 비활성화합니다. 라우터는 RSVP graceful restart 객체를 인식하거나 알지 못합니다.

재시작 및 복구 시간을 위해 값을 명시적으로 구성할 수 없습니다.

다른 프로토콜과 달리 RSVP는 고정 타임아웃 이외에 재시작 프로시저를 완료한지 판단할 방법이 없습니다. 모든 RSVP graceful restart 절차는 타임러 기반입니다. 명령어에 따르면 모든 RSVP 세션이 백업되고 루트가 복구된 경우에도 재시작이 여전히 진행 show rsvp version 중일 수 있습니다.

재시작 캡 객체 처리

다음 가정은 Restart Cap 객체에 기반한 이웃(노드 재시작과 컨트롤 채널 장애를 무분별하게 구별할 수 있는 경우)

  • Hello 메시지에 Restart Cap 객체를 광고하지 않는 이웃은 상태 또는 레이블 복구를 라우터를 지원할 수 없으며 RSVP graceful restart를 수행할 수도 없습니다.

  • 재시작 후, 이웃 광고는 재시작 시간이 모든 값과 같고 복구 시간이 0과 동일한 재시작된 재시작 객체는 해당 포우링 상태를 보존하지 못합니다. 복구 시간이 0과 같을 때 이웃은 종료된 것으로 간주하고, 재시작 시간의 값에 관계없이 이 neighbor와 관련된 모든 상태는 제거됩니다.

  • 재시작 후, 이웃은 0이 넘는 값을 사용하여 복구 시간을 광고하고 포우링 상태를 유지하거나 유지할 수 있습니다. 로컬 라우터가 이웃의 재시작 또는 복구 절차를 지원할 경우, 이 이웃에 Label 복구 객체를 전송합니다.

RSVP Graceful Restart 구성

RSVP graceful restart 구성은 다음과 같습니다.

  • Graceful Restart와 Helper 모드가 모두 활성화됩니다(기본).

  • Graceful Restart가 활성화되지만 Helper 모드는 비활성화됩니다. 이러한 방식으로 구성된 라우터는 graceful 방식으로 재시작할 수 있지만 이웃의 재시작 및 복구 절차를 지원할 수는 없습니다.

  • Graceful Restart는 비활성화되지만 도우미 모드가 활성화됩니다. 이러한 방식으로 구성된 라우터는 Graceful Restart가 지원되지 않지만 이웃을 재시작하는 데 도움이 될 수 있습니다.

  • Graceful Restart 및 Helper 모드 모두 비활성화됩니다. 이 구성은 RSVP graceful restart(재시작 및 복구 절차 및 도우미 모드 포함)를 완전히 비활성화합니다. 라우터는 RSVP Graceful Restart를 지원하지 않는 라우터처럼 작동됩니다.

주:

RSVP graceful restart를 켜기 위해서는 글로벌 graceful restart 타임을 최소 180초로 설정해야 합니다.

다음 섹션에서는 RSVP graceful restart를 구성하는 방법을 설명합니다.

모든 라우팅 프로토콜에 대해 Graceful Restart 지원

RSVP에 graceful restart를 활성화하려면 라우터에서 graceful restart를 지원하는 모든 프로토콜에 대해 graceful restart를 활성화해야 합니다. graceful restart에 대한 자세한 내용은 라우팅 디바이스를 위한 Junos OS 라우팅 프로토콜 라이브러리 를 참조하십시오.

라우터에서 graceful restart를 활성화하려면 다음 graceful-restart 문을 포함하십시오.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

RSVP용 Graceful Restart 장애

기본적으로 Graceful Restart를 활성화하면 RSVP graceful restart 및 RSVP 도우미 모드가 활성화됩니다. 그러나 이러한 기능 중 하나 또는 두 가지 모두를 비활성화할 수 있습니다.

RSVP graceful restart 및 복구를 비활성화하려면, 계층 수준에서 disable[edit protocols rsvp graceful-restart] 명령문을 포함하십시오.

RSVP 도우미 모드 비가시

RSVP 도우미 모드를 비활성화하기 위해 계층 수준에서 helper-disable[edit protocols rsvp graceful-restart] 명령문을 포함하십시오.

최대 도우미 복구 시간 구성

라우터가 graceful restart를 진행하는 동안 라우터가 RSVP neighbor의 상태를 유지하는 시간을 구성하려면 계층 수준에서 명령문을 maximum-helper-recovery-time[edit protocols rsvp graceful-restart] 포함합니다. 이 값은 모든 인접 라우터에 적용되어 가장 느린 RSVP neighbor에서 복구하는 데 필요한 시간을 기반으로 합니다.

최대 Helper Restart 시간 구성

라우터가 인접 라우터가 다운되고 이웃을 선언할 때 계층 수준에서 명령문을 포함하도록 maximum-helper-restart-time[edit protocols rsvp graceful-restart] 지연을 구성합니다. 이 값은 모든 인접 라우터에 적용되어 가장 느린 RSVP neighbor에서 재시작하는 데 필요한 시간을 기반으로 합니다.

RSVP LSP 터널 개요

RSVP(Resource Reservation Protocol) LSP(Label-Switched Path) 터널을 사용하면 다른 RSVP LSP 내부로 RSVP LSP를 전송할 수 있습니다. 이를 통해 네트워크 관리자는 네트워크의 한 단말에서 다른 엔드로의 트래픽 엔지니어링을 제공할 수 있습니다. 이 기능을 위한 유용한 애플리케이션은 RSVP LSP를 사용하여 고객 에지(고객 에지(CE)) 라우터와 PE(Provider Edge) 라우터를 연결한 다음, 네트워크 코어를 통해 이동하는 두 번째 RSVP LSP 내부에서 이 에지 LSP를 터널링하는 것입니다.

주니어 및 레이블 스위칭 개념을 MPLS 이해해야 합니다. 에 대한 자세한 MPLS Junos MPLS Applications Configuration Guide 를 참조하십시오.

RSVP LSP 터널은 GMPLS(Generalized MPLS 노드)에 사용되는 터널과 유사한 포링 인접성의 개념을 추가합니다. (GMPLS에 대한 자세한 내용은 Junos GMPLS 사용자 가이드 를 참조하십시오.

포워더 인접성은 RSVP LSP 네트워크에서 피어 디바이스 간에 데이터를 전송하기 위한 터널링 경로를 생성합니다. 포워더 인접 LSP(FA-LSP)가 설정되면 CSPF(Constrained Shortest Path First), LMP(Link Management Protocol), 최단 경로 우선(최단 경로 우선(OSPF)) 및 RSVP를 사용하여 FA-LSP를 통해 다른 LSP를 전송할 수 있습니다.

RSVP LSP 터널을 활성화하려면 Junos OS 메커니즘을 사용할 수 있습니다.

  • LMP—원래 GMPLS용으로 설계된 LMP는 RSVP LSP 터널 피어 간에 포우링 인접를 구축하고 트래픽 엔지니어링 링크에 리소스를 유지 관리 및 할당합니다.

  • 최단 경로 우선(OSPF) 확장—최단 경로 우선(OSPF) PIC(Physical Interface Card)과 관련된 물리적 및 논리적 인터페이스로 패킷을 라우팅하도록 설계되었습니다. 이 프로토콜은 LMP 구성에 정의된 가상 피어 인터페이스로 패킷을 라우팅할 수 있도록 확장되었습니다.

  • RSVP-트래픽 엔지니어링(TE) 확장—RSVP-트래픽 엔지니어링(TE) 물리적 인터페이스에 대한 패킷 LSP 설정 시그널을 표시하도록 설계되었습니다. 이 프로토콜은 LMP 구성에 정의된 가상 피어 인터페이스로 전송되는 패킷 LSP에 대한 경로 설정 요청으로 확장되었습니다.

    주:

    RSVP-Junos OS 15.1부터 RSVP-MPLS 다중 인스턴스 지원이 트래픽 엔지니어링(TE). 이 지원은 가상 라우터 인스턴스 유형에만 제공됩니다. 라우터는 여러 개의 독립적인 토폴로지 파티션을 트래픽 엔지니어링(TE) 참여할 수 있으며, 각 분할된 트래픽 엔지니어링(TE) 도메인을 독립적으로 확장할 수 있습니다. 다중 인스턴스 RSVP-트래픽 엔지니어링(TE) 인스턴스 인식이 필요한 컨트롤 플레인 엔티티를 선택할 수 있는 유연성을 제공합니다. 예를 들어 라우터는 단일 인스턴스를 실행하는 동안 여러 트래픽 엔지니어링(TE) 인스턴스에 참여할 수 BGP(Border Gateway Protocol) 있습니다.

    RSVP-Junos OS 구현은 MPLS Release 16.1의 LSP의 사용성, 가시성, 구성트래픽 엔지니어링(TE) 문제 해결을 향상할 수 있도록 Junos OS 확장됩니다.

    이러한 기능 향상을 통해 RSVP-트래픽 엔지니어링(TE) 쉽게 대규모로 구성할 수 있습니다.

    • 트래픽이 RSVP-트래픽 엔지니어링(TE) LSP를 통해 LSP를 선회하기 전에 LSP가 재지정되는 동안 LSP 데이터 플레인 준비를 보장합니다.

      LSP가 데이터 플레인에서 프로그래밍된 것으로 알려져 있지 않다면 트래픽을 전달하기 시작하면 안 됩니다. LSP 핑 요청과 같은 LSP 데이터 플레인에서 데이터 교환은 트래픽을 LSP로 스위칭하기 전에 ingress 라우터에서 발생하거나 MBB 인스턴스로 전송됩니다. egress LSP가 LSP 핑 요청에 응답해야 하기 때문에 대규모 네트워크에서는 이러한 트래픽이 LSP egress 라우터에 부담을 가할 수 있습니다. LSP 셀프 핑 메커니즘을 통해 수신 LER은 LSP 핑 응답 메시지를 생성하고 LSP 데이터 플레인을 통해 전송할 수 있습니다. 이러한 메시지를 수신할 때, egress LER는 LSP 데이터 플레인의 활동을 나타내는 수신으로 전달합니다. 따라서 LSP가 데이터 플레인이 프로그래밍되기 전에 트래픽을 전달하지 않도록 보장합니다.

    • 수신 라우터에서 64K LSP의 현재 하드 제한을 제거하고 신호 전송 LSP로 RSVP-트래픽 엔지니어링(TE) 총 LSP 수를 확장합니다. 각 걸기 기준으로 최대 64K LSP를 구성할 수 있습니다. 앞서 이 제한은 ingress LER에서 구성할 수 있는 총 LSP 수입니다.

    • 전송 라우터에서 LSP 신호 전송 지연으로 인해 수신 라우터에 의해 LSP의 혹사적인 중단 방지

    • LSP 데이터 세트에 대한 유연한 뷰를 지원하여 LSP 특성의 데이터 시각화를 용이하게 합니다.

    주:

    릴리스 17.Junos OS 부터는 셀프 핑(self-ping)을 위한 1800초의 기본 시간이 사용됩니다.

LSP 계층에는 다음과 같은 제한이 있습니다.

  • CCC(Circuit Cross-Connect) 기반 LSP는 지원되지 않습니다.

  • Graceful Restart는 지원되지 않습니다.

  • 링크 보호는 FA-LSP 또는 포우링 인접의 egress 지점에서 지원되지 않습니다.

  • POINT-to-Multipoint LSP는 FA-LSP에서 지원되지 않습니다.

예를 들면 다음과 같습니다. RSVP LSP 터널 구성

그림 5: RSVP LSP 터널 토폴로지 다이어그램RSVP LSP 터널 토폴로지 다이어그램

그림 5 라우터 0에서 시작하여 Router 5에서 종료되는 엔드-to-end RSVP LSP를 e2e_lsp_r0r5 보여줍니다. 전송 중 이 LSP는 FA-LSP를 fa_lsp_r1r4 통과합니다. 반환 경로는 FA-LSP를 통해 이동하는 엔드-to-end RSVP e2e_lsp_r5r0 LSP로 fa_lsp_r4r1 표현됩니다.

Router 0에서 Router 5로 이동하는 엔드-to-end RSVP LSP를 구성합니다. 라우터 1과 라우터 1에서 라우터 4로 이동하는 LMP 트래픽 엔지니어링 링크를 통해 엄격한 경로를 사용하십시오.

라우터 0

라우터 1에서 FA-LSP를 구성하여 라우터 4에 도달합니다. LMP 트래픽 엔지니어링 링크와 라우터 4와 LMP 피어 관계를 구축합니다. 트래픽 엔지니어링 링크에서 FA-LSP를 참조하고 피어 인터페이스를 최단 경로 우선(OSPF) RSVP에 추가합니다.

리턴 경로의 엔드-엔드 LSP가 Router 1에 도착하면 라우팅 플랫폼은 라우팅 룩업을 수행하고 트래픽을 Router 0으로 포워드할 수 있습니다. 라우터 0과 최단 경로 우선(OSPF) 올바르게 구성하는지 확인합니다.

라우터 1

Router 2에서 코어 네트워크에서 FA-LSP를 최단 경로 우선(OSPF), MPLS, RSVP를 구성합니다.

라우터 2

Router 3에서 코어 최단 경로 우선(OSPF) FA-LSP를 MPLS 인터페이스에서 최단 경로 우선(OSPF), RSVP 및 RSVP를 구성합니다.

라우터 3

라우터 4에서 라우터 1에 도달하기 위해 경로 FA-LSP를 구성합니다. LMP 트래픽 엔지니어링 링크와 라우터 1과 LMP 피어 관계를 구축합니다. 트래픽 엔지니어링 링크에서 FA-LSP를 참조하고 피어 인터페이스를 최단 경로 우선(OSPF) RSVP에 추가합니다.

초기 엔드-엔드 LSP가 Router 4에 도착하면 라우팅 플랫폼은 라우팅 룩업을 수행하고 트래픽을 Router 5로 포워드할 수 있습니다. 라우터 4와 라우터 5 최단 경로 우선(OSPF) 올바르게 구성하는지 확인합니다.

라우터 4

Router 5에서 Router 0으로 이동하는 반환 경로의 엔드-to-엔드 RSVP LSP를 구성합니다. 라우터 4 및 라우터 4에서 라우터 1로 이동하는 LMP 트래픽 엔지니어링 링크를 통해 엄격한 경로를 사용하십시오.

라우터 5

업무 검증

RSVP LSP 터널이 올바르게 작동하고 있는지 확인하려면 다음 명령을 실행하십시오.

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

구성 예제와 함께 사용되는 이러한 명령을 확인하려면 다음 섹션을 참조하십시오.

라우터 0

Router 0에서 FA-LSP가 트래픽 엔지니어링 데이터베이스에서 유효한 경로로 나타나는지 확인할 수 있습니다. 이 경우, 및 의 LMP 트래픽 엔지니어링 링크 주소를 참조하는 Router 1 ( ) 및 Router 4 ()의 경로를 10.255.41.21610.255.41.217 살펴 172.16.30.1 보게 172.16.30.2 됩니다. 또한, FA-LSP를 통해 Router 5로 이동하는 경우, 엔드-to-end LSP 경로를 찾아내기 위한 show rsvp session extensive 명령을 내릴 수도 있습니다.

라우터 1

라우터 1에서 LMP 트래픽 엔지니어링 링크 구성이 작동하고 엔드-to-엔드 LSP가 명령 집합을 발행하여 트래픽 엔지니어링 링크를 통해 전달하는지 show link-management 확인합니다. 또한 명령을 실행하여 show rsvp session extensive FA-LSP가 작동하고 있는지 확인할 수 있습니다.

RSVP 및 최단 경로 우선(OSPF) 피어 인터페이스 구성

LMP 피어를 설정한 후 웹 인터페이스 및 RSVP에 최단 경로 우선(OSPF) 합니다. 피어 인터페이스는 두 피어 간의 제어 인접을 지원하는 데 사용되는 가상 인터페이스입니다.

피어 인터페이스 이름은 계층 수준에서 peer peer-name LMP에서 구성된 명령문과 [edit protocols link-management] 일치해야 합니다. 실제 프로토콜 패킷은 피어 인터페이스를 통해 전송 및 수신하기 때문에 피어 인터페이스는 표준 및 RSVP로 구성된 다른 물리적 인터페이스와 마찬가지로 피어에게 신호를 보내고 최단 경로 우선(OSPF) 수 있습니다. LMP 피어에 최단 경로 우선(OSPF) 라우팅을 구성하기 위해 계층 수준에서 peer-interface[edit protocols ospf area area-number] 명령문을 포함합니다. LMP 피어에 대한 RSVP 시그널링을 구성하기 위해 계층 수준에서 peer-interface [edit protocols rsvp] 명령문을 포함합니다.

FA-LSP에 대한 레이블 스위칭 경로 정의

그런 다음, 계층 수준에서 명령문을 포함해 FA-LSP를 label-switched-path[edit protocols mpls] 정의합니다. 계층 수준에서 명령문에 피어의 to 라우터 [edit protocols mpls label-switched-path] ID를 포함합니다. 패킷 LSP는 단방향이기 때문에 피어에 도달하기 위해 하나의 FA-LSP를 생성하고 두 번째 FA-LSP를 피어에서 반환해야 합니다.

FA-LSP 경로 정보 설정

FA-LSP에 대한 명시적 LSP 경로를 구성할 경우, 트래픽 엔지니어링 링크 원격 주소를 넥스홉 주소로 사용해야 합니다. CSPF가 지원될 때 원하는 경로 옵션을 사용할 수 있습니다. 그러나 계층 수준에서 명령문으로 CSPF가 비활성화된 경우 엄격한 경로를 no-cspf[edit protocols mpls label-switched-path lsp-name] 사용해야 합니다.

주:

엔드-엔드 LSP가 FA-LSP와 동일한 라우팅 플랫폼에서 시작된 경우 CSPF를 비활성화하고 엄격한 경로를 사용해야 합니다.

옵션: RSVP LSP의 Graceful 종료

LSP에서 사용하는 RSVP 세션을 단계적으로 철회하는 2단계 프로세스에서 RSVP LSP를 해소할 수 있습니다. graceful teardown을 지원하는 모든 이웃의 경우, LSP 및 경로의 모든 RSVP 이웃에 대한 라우팅 플랫폼에 의해 종료 요청이 대상 단말로 전송됩니다. 요청은 RSVP 패킷 필드에 ADMIN_STATUS 포함됩니다. 이웃이 요청을 수신하면 RSVP 세션이 철회될 준비를 합니다. 두 번째 메시지는 RSVP 세션의 해산을 완료하기 위해 라우팅 플랫폼에 의해 전송됩니다. 이웃이 graceful teardown을 지원하지 않는 경우 요청은 graceful 네트워크가 아닌 표준 세션 종료로 처리됩니다.

RSVP 세션의 graceful teardown을 수행하기 위해 명령을 clear rsvp session gracefully 실행합니다. 선택적으로 RSVP 세션의 소스 및 대상 주소, RSVP 발신자에 대한 LSP 식별자 및 RSVP 세션의 터널 식별자를 지정할 수 있습니다. 이러한qualifiers를 사용하게 에는 명령어를 발행할 때 connection-sourceconnection-destination , 및 lsp-idtunnel-id 옵션이 clear rsvp session gracefully 포함됩니다.

또한, 계층 수준에서 명령문을 포함해 실제 연결 종료를 시작하기 전에 라우팅 플랫폼이 graceful teardown 요청을 수신할 때까지 기다리는 시간을 구성할 graceful-deletion-timeout[edit protocols rsvp] 수 있습니다. 기본 Graceful Deleout 타임아웃 값은 30초로, 최소값은 1초, 최대값은 300초입니다. graceful deletion 타임아웃을 위해 구성된 현재 값을 보시고, 작업 모드 명령을 show rsvp version 실행합니다.

출시 내역 표
릴리스
설명
19.4R1
16.1
그러나, Junos OS Release 16.1에서 시작하여 RSVP hello 메시지가 타임아웃되는 경우 RSVP 세션이 다운됩니다.