이 페이지에서
RSVP 구성
최소 RSVP 구성
단일 인터페이스에서 RSVP를 활성화하고, rsvp 문을 포함하며 interface 문을 사용하는 인터페이스를 지정합니다. 이것은 최소 RSVP 구성입니다. 다른 모든 RSVP 구성 문은 선택 사항입니다.
rsvp { interface interface-name; }
다음 계층 수준에서 이러한 문을 포함할 수 있습니다.
[edit protocols][edit logical-systems logical-system-name protocols]
모든 인터페이스에서 RSVP를 활성화하려면, interface-name 변수를 all(으)로 대체합니다.
인터페이스 그룹에서 인터페이스 속성을 구성하고 인터페이스 중 하나에서 RSVP를 비활성화하고 싶다면 disable 문을 포함합니다.
interface interface-name { disable; }
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
RSVP 및 MPLS 구성
Junos RSVP 소프트웨어의 주요 목적은 LSP(Label Switched Path) 내에서 동적 신호를 지원하는 것입니다. 라우터에서 MPLS 및 RSVP를 모두 활성화하면 MPLS는 RSVP 클라이언트가 됩니다. MPLS 및 RSVP를 바인딩 하는 데 추가 구성은 필요하지 않습니다.
[edit protocols mpls]계층 수준에서 label-switched-path명령문을 사용하여 신호 경로를 설정하도록 MPLS를 구성할 수 있습니다. 각 LSP는 RSVP가 RSVP 세션을 시작하도록 요청하는 것으로 변환됩니다. 이 요청은 레이블 스위칭 및 RSVP 사이의 내부 인터페이스를 통해 전달됩니다. 요청 정보를 검사하고, RSVP 상태를 확인하고, 로컬 라우팅 테이블을 확인하는 후, RSVP는 각 LSP에 대한 하나의 세션을 시작합니다. 이 세션은 라우터에서 공급되며 LSP의 대상으로 지정됩니다.
RSVP 세션이 성공적으로 생성되면, LSP는 RSVP 세션에 의해 생성된 경로를 따라 설정됩니다. RSVP 세션이 실패하면, RSVP는 MPLS에 상태를 알립니다. 백업 경로를 시작하거나 초기 경로를 계속 재시도하는 것은 MPLS에 달려 있습니다.
레이블 스위칭 신호 정보를 전달하기 위해 RSVP는 4개의 추가 객체를 지원합니다: 레이블 요청 객체, 레이블 객체, 명시적 경로 객체 및 기록 경로 객체. LSP가 성공적으로 설정되려면 경로를 따라 있는 모든 라우터가 MPLS, RSVP 및 4개의 객체를 지원해야 합니다. 4개 객체 중 기록 경로 개체는 필수가 아닙니다.
MPLS를 구성하고 이를 RSVP의 클라이언트로 만들기 위해 다음을 수행합니다:
레이블 스위칭 들어가는 모든 라우터(레이블 스위칭 경로에 포함될 수 있는 모든 라우터)에서 MPLS를 활성화합니다.
LSP를 형성하는 모든 라우터 및 모든 라우터 인터페이스에서 RSVP를 활성화합니다.
LSP의 시작 부분에 라우터를 구성합니다.
경로 계산에 대한 지연 메트릭을 사용하도록 RSVP LSP(Label Switched Path)를 구성할 수 있습니다. 구성을 위해, [edit protocols mpls label-switched-path name]계층에서 소개한 CLI 옵션을 사용합니다.
예: RSVP 및 MPLS 구성
다음은 LSP의 시작 부분에 라우터 구성 예시를 보여줍니다:
[edit]
protocols {
mpls {
label-switched-path sf-to-london {
to 192.168.1.4;
}
}
rsvp {
interface so-0/0/0;
}
}
다음은 LSP를 형성하는 다른 모든 라우터에 대한 구성 예시를 보여줍니다:
[edit]
protocols {
mpls {
interface so-0/0/0;
}
rsvp {
interface so-0/0/0;
}
}
RSVP 인터페이스 구성
다음 섹션에서는 RSVP 인터페이스 구성 방법을 설명합니다.
- RSVP 리프레시 감소 구성
- RSVP Hello 간격 구성
- RSVP 인증 구성
- 클래스 유형에 따른 대역폭 구독 구성
- 인터페이스에서 RSVP 업데이트 임계값 구성
- 번호가 없는 인터페이스용 RSVP 구성
RSVP 리프레시 감소 구성
인터페이스 구성에 다음 문을 포함하여 각 인터페이스에 RSVP 리프레시 감소를 구성할 수 있습니다.
aggregate및reliable-RSVP 리프레시 감소 기능을 활성화합니다: RSVP 메시지 묶음, RSVP 메시지 ID, 안정적인 메시지 전달 및 요약 리프레시.리프레시 감소와 안정적인 전달을 위해
aggregate및reliable문을 포함해야 합니다.no-aggregate- RSVP 메시지 묶음과 요약 리프레시 비활성화.no-reliable- RSVP 메시지 ID, 안정적인 메시지 전달 및 요약 리프레시 비활성화.
RSVP 리프레시 감소에 관한 자세한 정보는 RSVP 리프레시 감소를 참조하십시오.
no-reliable 문이 라우터에 구성되면(안정적인 메시지 전달이 비활성화되면), 라우터는 메시지 ID 개체를 포함한 RSVP 메시지를 수락하지만 메시지 ID 개체를 무시하고 표준 메시지 처리를 계속 수행합니다. 이 경우에는 오류가 발생하지 않으며, RSVP가 정상적으로 작동합니다.
그러나 다른 리프레시 감소 기능을 가진 두 이웃 간 모든 조합이 항상 올바르게 작동하는 것은 아닙니다. 예를 들어 라우터가 aggregate 문 및 no-reliable 문 또는 reliable 문 및 no-aggregate 문으로 구성됩니다. RSVP 이웃이 이 라우터에 요약 리프레시 개체를 전송하면, 오류가 발생하지는 않지만 요약 리프레시 개체는 처리할 수 없습니다. 그 결과, 이웃이 이 RSVP 상태를 리프레시하는 데 요약 리프레시에만 의존하는 경우, RSVP 상태는 이 라우터에서 시간 초과될 수 있습니다.
특정 요구 사항이 없는 한, RSVP 이웃마다 유사한 방식으로 RSVP 리프레시 감소를 구성하기는 게 좋습니다.
인터페이스에서 모든 RSVP 리프레시 감소 기능을 활성화하려면 aggregate 문을 포함합니다.
aggregate;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp interface interface-name][edit logical-systems logical-system-name protocols rsvp interface interface-name]
RSVP 메시지 묶음과 요약 리프레시를 비활성화하려면, no-aggregate 문을 포함합니다.
no-aggregate;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp interface interface-name][edit logical-systems logical-system-name protocols rsvp interface interface-name]
인터페이스에서 RSVP 메시지 ID와 안정적인 메시지 전달을 활성화하려면, reliable 문을 포함합니다.
reliable;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp interface interface-name][edit logical-systems logical-system-name protocols rsvp interface interface-name]
RSVP 메시지 ID, 안정적인 메시지 전달 그리고 요약 리프레시를 비활성화하려면, no-reliable 문을 포함합니다.
no-reliable;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp interface interface-name][edit logical-systems logical-system-name protocols rsvp interface interface-name]
RSVP 이웃의 리프레시 감소 기능 결정
RSVP 이웃의 RSVP 리프레시 감소 기능을 결정하려면 다음 정보가 필요합니다.
이웃이 광고하는 RR 비트
RSVP 리프레시 감소의 로컬 구성
이웃에서 수신된 실제 RSVP 메시지
이 정보를 얻기 위해 show rsvp neighbor detail 명령을 실행할 수 있습니다. 샘플 출력은 다음과 같습니다.
user@host> show rsvp neighbor detail
RSVP neighbor: 6 learned
Address: 192.168.224.178 via: fxp1.0 status: Up
Last changed time: 10:06, Idle: 5 sec, Up cnt: 1, Down cnt: 0
Message received: 36
Hello: sent 69, received: 69, interval: 9 sec
Remote instance: 0x60b8feba, Local instance: 0x74bc7a8d
Refresh reduction: not operational
Address: 192.168.224.186 via: fxp2.0 status: Down
Last changed time: 10:17, Idle: 40 sec, Up cnt: 0, Down cnt: 0
Message received: 6
Hello: sent 20, received: 0, interval: 9 sec
Remote instance: 0x0, Local instance: 0x2ae1b339
Refresh reduction: incomplete
Remote end: disabled, Ack-extension: enabled
Address: 192.168.224.188 via: fxp2.0 status: Up
Last changed time: 4:15, Idle: 0 sec, Up cnt: 1, Down cnt: 0
Message received: 55
Hello: sent 47, received: 31, interval: 9 sec
Remote instance: 0x6436a35b, Local instance: 0x663849f0
Refresh reduction: operational
Remote end: enabled, Ack-extension: enabled
show rsvp neighbor detail 명령에 대한 자세한 정보.
RSVP Hello 간격 구성
RSVP는 내부 게이트웨이 프로토콜(IGP) (IS-IS 또는 OSPF) 이웃의 상태를 모니터링하고, IGP 프로토콜에 의존하여 노드 실패를 감지합니다. IGP 프로토콜이 이웃의 중단을 선언하면(Hello 패킷이 더 이상 수신되지 않기 때문에), RSVP 또한 해당 이웃을 중단합니다. 그러나 이웃이 중단되어도 IGP 프로토콜과 RSVP는 여전히 독립적으로 작동합니다.
주니퍼 네트웍스 라우터의 경우, 더 짧거나 긴 RSVP Hello 간격은 RSVP 세션의 중단 여부에 영향을 주지 않습니다. RSVP 세션은 RSVP Hello 패킷이 더 이상 수신되지 않아도 지속됩니다. RSVP 세션은 라우터가 IGP Hello 패킷 수신을 중단하거나 RSVP 경로 및 RSVP 메시지가 시간 초과될 때까지 유지됩니다. 그러나 Junos OS 릴리스 16.1부터 RSVP Hello 메시지가 시간 초과되면, RSVP 세션이 중단됩니다.
또한 RSVP Hello 간격은 다른 공급업체의 장비가 RSVP 세션을 중단할 때도 영향을 받을 수 있습니다. 예를 들어 이웃의 비주니퍼 네트워크 라우터는 RSVP Hello 패킷을 모니터링하도록 구성할 수 있습니다.
RSVP가 Hello 패킷을 보내는 빈도를 수정하려면 hello-interval 문을 포함합니다.
hello-interval seconds;
릴리스 16.1부터 Junos가 가능한 경우 우회 LSP에서 RSVP Hello 메시지를 보냅니다. IGP 다음 홉을 통해 Hello를 전송하는 기존 동작으로 돌아가는 방법은 no-node-hello-on-bypass에서 확인하십시오.
이러한 명령문을 포함할 수 있는 계층 수준의 목록은 명령문 요약 섹션을 참조하십시오.
RSVP 인증 구성
모든 RSVP 프로토콜 교환은 신뢰할 수 있는 이웃만 예약 설정에 참여하는 것을 보증하도록 인증될 수 있습니다. 기본적으로 RSVP 인증은 비활성화됩니다.
RSVP 인증은 HMAC(Hashed Message Authentication Code)-MD5 메시지 기반 다이제스트를 사용합니다. 이 체계는 비밀 인증 키 및 메시지 내용을 기반으로 메시지 다이제스트를 생성합니다. (또한 메시지 내용에는 시퀀스 번호가 포함되어 있습니다.) 계산된 다이제스트는 RSVP 메시지와 함께 전송됩니다. 인증을 구성하면, 모든 이웃과 함께 수신되고 전송되는 RSVP 메시지가 모두 이 인터페이스에서 인증됩니다.
MD5 인증은 위조와 메시지 수정 관련 보호를 제공합니다. 또한 반복 공격을 방지할 수 있습니다. 그러나 모든 메시지가 일반 텍스트로 전송되었기 때문에 기밀성을 제공하지 않습니다.
기본적으로 인증이 비활성화됩니다. 인증을 활성화하려면 authentication-key 문을 포함하여 각 인터페이스에 키를 구성합니다.
authentication-key key;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
클래스 유형에 따른 대역폭 구독 구성
기본적으로 RSVP는 RSVP 예약에 사용되는 클래스 유형에 100%의 대역폭을 허용합니다. 다중 클래스 LSP의 클래스 유형을 초과하여 구독하면, 모든 RSVP 세션의 총수요는 클래스 유형의 실제 용량을 초과할 수 있습니다.
클래스 유형의 대역폭 구독 구성 방법에 관한 자세한 내용은 LSP의 대역폭 구독 비율 구성을 참조하십시오.
인터페이스에서 RSVP 업데이트 임계값 구성
내부 게이트웨이 프로토콜(IGP)은 트래픽 엔지니어링 데이터베이스를 유지하지만, 트래픽 엔지니어링 데이터베이스 링크에서 현재 사용 가능한 대역폭은 RSVP에서 유래합니다. 링크의 대역폭이 변경되면 RSVP가 IGP에 알려주며, IGP는 트래픽 엔지니어링 데이터베이스를 업데이트하고 모든 네트워크 노드로 새로운 대역폭 정보를 전달할 수 있습니다. 그런 다음 네트워크 노드는 트래픽 엔지니어링 데이터베이스 링크(로컬 또는 원격)에서 가능한 대역폭이 얼마나 있는지 파악하고, CSPF는 경로를 올바르게 계산할 수 있습니다.
그러나 IGP 업데이트는 시스템 리소스를 과도하게 사용할 있습니다. 네트워크의 노드 수에 따라 대역폭의 작은 변경 사항을 위한 IGP 업데이트는 바람직하지 않을 수도 있습니다. [edit protocols rsvp] 계층 수준에서 update-threshold 문을 구성하여, 예약된 대역폭 변경이 IGP 업데이트를 트리거하는 임계값을 조정할 수 있습니다.
IGP 업데이트를 트리거할 때를 위해 0.001%에서 20%(기본값은 10%)까지로 값을 구성할 수 있습니다. 예약된 대역폭의 변경이 해당 인터페이스에서 고정 대역폭의 구성 임계값 비율 이상이면, IGP 업데이트가 발생합니다. 예를 들어 update-threshold 문을 15%로 구성했는데 라우터가 링크의 예약된 대역폭이 링크 대역폭의 10%만큼 변경된 것을 발견하면, RSVP는 IGP 업데이트를 트리거하지 않습니다. 그러나 링크의 예약된 대역폭이 링크 대역폭의 20%만큼 변경되면, RSVP는 IGP 업데이트를 트리거합니다.
또한 threshold-value 문 아래에서 update-threshold 옵션을 사용하여 임계값을 절대 값으로 구성할 수 있습니다.
임계값이 해당 링크에서 대역폭의 20%를 초과하도록 구성하면, 임계값은 대역폭의 20%로 제한됩니다.
예를 들어 인터페이스의 대역폭이 1Gbps이고 threshold-value이(가) 200Mbps 초과로 구성된 경우, threshold-value은(는) 200Mbps로 제한됩니다. threshold-percent은(는) 20.000%로 그리고 threshold-value은(는) 200Mbps로 표시됩니다.
두 가지 옵션인 threshold-percent 및 threshold-value은(는) 상호 배타적입니다. 낮은 대역폭 예약을 위해 IGP 업데이트를 생성하도록 주어진 시점에서 단 한 개의 옵션을 구성할 수 있습니다. 그 결과, 한 개의 옵션이 구성되면 다른 옵션이 계산되어 CLI에 표시됩니다.
예를 들어 1Gbps의 링크에서 threshold-percent이(가) 5%로 구성된 경우, threshold-value은(는) 50Mbps로 계산되어 표시됩니다. 마찬가지로 threshold-value이(가) 50m로 구성된 경우, threshold-percent은(는) 5%로 계산되어 표시됩니다.
예약된 대역폭의 변경이 IGP 업데이트를 트리거하는 임계값을 조정하려면, update-threshold 문을 포함합니다. 업데이트 임계값 때문에 CSPF(Constrained Shortest Path First)는 링크의 오래된 트래픽 엔지니어링 데이터베이스 대역폭 정보를 사용하여 경로를 계산합니다. RSVP가 해당 경로에 LSP를 구축하려는 경우, 해당 링크에서 대역폭이 부족하다는 것을 찾을 수 있습니다. 이런 경우에는 RSVP가 IGP 트래픽 엔지니어링 데이터베이스 업데이트를 트리거하여, 네트워크에서 업데이트된 대역폭 정보를 초과합니다. 그러면 CSPF는 업데이트된 대역폭 정보를 사용하여 경로를 재계산하고, 혼잡한 링크를 피해 다른 경로를 찾도록 시도할 수 있습니다. 이 기능은 기본 사항으로, 추가 구성이 필요하지 않습니다.
[edit protocols mpls] 계층 수준 또는 [edit logical-systems logical-system-name protocols mpls] 계층 수준에서 rsvp-error-hold-time 문을 구성하여 PathErr 메시지가 제공하는 정보를 사용하는 트래픽 엔지니어링 데이터베이스의 정확성(LSP의 대역폭 추정 정확성 포함)을 향상시킬 수 있습니다. RSVP PathErr 메시지로 트래픽 엔지니어링 데이터베이스 정확성 개선을 참조하십시오.
번호가 없는 인터페이스용 RSVP 구성
Junos OS는 번호가 없는 인터페이스에 RSVP 트래픽 엔지니어링을 지원합니다. 번호가 없는 링크에 대한 트래픽 엔지니어링 정보는 RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 및 RFC 4205, Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)에 설명된 대로 OSPF 및 IS-IS의 IGP 트래픽 엔지니어링 확장에서 수행됩니다. 또한 번호가 없는 링크는 RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)에서 설명된 것과 같이 MPLS 트래픽 엔지니어링 신호에서 지정할 수 있습니다. 이 기능으로 RSVP 신호 네트워크에 참여하는 각 인터페이스에 IP 주소를 구성하지 않아도 됩니다.
번호가 없는 인터페이스에 RSVP를 구성하려면, [edit routing-options] 계층 수준에서 지정된 router-id 문을 사용하는 라우터 ID로 라우터를 구성해야 합니다. 라우터 ID는 라우팅 시 사용할 수 있어야 합니다(일반적으로 루프백 주소를 사용할 수 있습니다). 번호가 없는 링크의 RSVP 제어 메시지는 (무작위로 선택된 주소 보다는) 라우터 ID 주소를 사용하여 전송됩니다.
활성화된 번호가 없는 인터페이스의 라우터에서 링크 보호와 Fast Reroute를 구성하려면, 최소 2개의 주소를 구성해야 합니다. 또한 라우터 ID를 구성하려면 루프백에서 보조 인터페이스 구성하는 것을 권장합니다.
RSVP Node-ID Hello 구성
주니퍼 네트웍스 라우터가 다른 공급 업체의 장비와 상호 운용되도록 Node-ID 기반 RSVP Hello를 구성할 수 있습니다. 기본적으로 Junos OS는 인터페이스 기반 RSVP Hello를 사용합니다. Node-ID 기반 RSVP Hello는 RFC 4558, Node-ID 기반 RSVP(Resource Reservation Protocol) Hello: 명확화 문에 명시되어 있습니다. RSVP 인터페이스를 통해 문제를 감지하도록 BFD를 구성하면 이러한 인터페이스에 대한 인터페이스 Hello를 비활성화할 수 있으므로, RSVP Node-ID Hello가 유용합니다. 또한 Graceful Restart 절차를 위해 Node-ID Hello를 사용할 수 있습니다.
Node-ID Hello는 모든 RSVP 이웃에 대해 전역으로 활성화할 수 있습니다. 기본적으로 Node-ID Hello 지원은 비활성화됩니다. 라우터에서 RSVP Node ID를 활성화하지 않으면, Junos OS는 어떤 Node-ID Hello 패킷도 수락하지 않습니다.
릴리스 16.1부터 Junos가 가능한 경우 우회 LSP에서 RSVP Hello 메시지를 보냅니다. IGP 다음 홉을 통해 Hello를 전송하는 기존 동작으로 돌아가는 방법은 no-node-hello-on-bypass에서 확인하십시오.
라우터에서 전역으로 Node-ID Hello를 활성화하려면, 다음 계층 수준에서 Node-Hello 문을 포함합니다:
-
[edit protocols rsvp] -
[edit logical-systems logical-systems-name protocols rsvp]
또한 전역으로 RSVP 인터페이스를 명시적으로 비활성화할 수 있습니다. 이러한 유형의 구성은 주니퍼 네트웍스 라우터가 다른 공급 업체의 장비와 수많은 RSVP 연결을 가진 네트워크에서 필수일 수도 있습니다. 그러나 전역으로 RSVP 인터페이스 Hello를 비활성화하면, hello-interval 문을 사용하는 RSVP 인터페이스의 Hello 간격을 구성할 수도 있습니다. 이 구성은 RSVP 인터페이스 Hello를 전역으로 비활성화하지만, 지정된 인터페이스(hello-interval 문을 구성하는 RSVP 인터페이스)에서 RSVP 인터페이스 Hello를 활성화합니다. 이러한 구성은 일부 디바이스가 RSVP Node-ID Hello를 지원하고 다른 디바이스가 RSVP 인터페이스 Hello를 지원하는 이기종 네트워크에서 필요할 수 있습니다.
라우터에서 RSVP 인터페이스 Hello를 전역으로 비활성화하려면, 다음 계층 수준에서 no-interface-hello 문을 포함합니다:
-
[edit protocols rsvp] -
[edit logical-systems logical-systems-name protocols rsvp]
예: RSVP 신호 LSP 구성
이 예는 신호 프로토콜로 RSVP를 사용하는 IP 네트워크의 라우터 간에 LSP를 생성하는 방법을 보여줍니다.
요구 사항
시작하기 전에 디바이스에서 보안 서비스를 삭제합니다. 예: 보안 서비스 삭제.
개요 및 토폴로지
신호 프로토콜로 RSVP를 사용하면 IP 네트워크의 라우터 간에 LSP를 생성할 수 있습니다. 이 예에서는 그림 1에 보이는 것처럼 샘플 네트워크를 구성합니다.
토폴로지
라우터 간에 LSP를 구축하려면, MPLS 네트워크의 각 전송 인터페이스에서 개별적으로 MPLS 패밀리를 활성화하고 RSVP를 구성해야 합니다. 이 예는 ge-0/0/0 전송 인터페이스에서 MPLS를 활성화하고 RSVP를 구성하는 방법을 보여줍니다. 또한 네트워크의 모든 MPLS 인터페이스에서 MPLS 프로세스를 활성화해야 합니다.
이 예는 R7의 루프백 주소(10.0.9.7)를 사용하는 수신 라우터(R1)에서 R1부터 R7까지 LSP를 정의하는 방법을 보여줍니다. 구성은 10Mbps 대역폭을 갖습니다. 또한 구성은 CSPF 알고리즘을 비활성화하여, 호스트 C1과 C2가 네트워크 IGP의 최단 경로에 해당하는 RSVP 신호 LSP를 사용하게 합니다.
구성
절차
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣습니다.
set interfaces ge-0/0/0 unit 0 family mpls set protocols rsvp interface ge-0/0/0.0 set protocols mpls label-switched-path r1-r7 to 10.0.9.7 set protocols mpls label-switched-path r1-r7 bandwidth 10m set protocols mpls interface all
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 관한 정보는 CLI 사용자 가이드에서 구성 모드에서 CLI 편집기 사용을 참조하십시오.
RSVP 구성:
MPLS 네트워크의 모든 전송 인터페이스에서 MPLS 패밀리를 활성화합니다.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family mpls
MPLS 네트워크의 각 전송 인터페이스에서 RSVP를 활성화합니다.
[edit] user @host# set protocols rsvp interface ge-0/0/0
MPLS 네트워크의 전송 인터페이스에서 MPLS 프로세스를 활성화합니다.
[edit] user@host# set protocols mpls interface ge-0/0/0
수신 라우터에서 LSP를 정의합니다.
[edit protocols mpls] user@host# set label-switched-path r1-r7 to 10.0.9.7
LSP에서 10Mbps 대역폭을 갖습니다.
[edit protocols mpls] user @host# set label-switched-path r1-r7 bandwidth 10m
결과
구성 모드에서 show 명령을 입력하여 구성을 확인합니다. 출력이 의도된 구성을 표시하지 않으면, 이 예의 구성 지침을 반복하여 수정합니다.
간결성을 위해 이 show 명령 출력은 이 예와 관련된 구성만 포함합니다. 시스템의 다른 구성은 생략 부호(...)로 대체되었습니다.
user@host# show
...
interfaces {
ge-0/0/0 {
family mpls;
}
}
}
...
protocols {
rsvp {
interface ge-0/0/0.0;
}
mpls {
label-switched-path r1-r7 {
to 10.0.9.7;
bandwidth 10m;
}
interface all;
}
}
...
디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.
검증
구성이 제대로 작동하는지 확인하려면 다음의 작업을 수행하십시오:
RSVP 이웃 확인
목적
각 디바이스가 적절한 RSVP 이웃을 보여주는지 확인합니다. 예를 들어, 그림 1의 라우터 R1은 RSVP 이웃으로 라우터 R3과 라우터 R2를 모두 나열합니다.
작업
CLI에서 show rsvp neighbor 명령을 입력합니다.
user@r1> show rsvp neighbor RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx 10.0.6.2 0 3/2 13:01 3 366/349 10.0.3.3 0 1/0 22:49 3 448/448
출력은 이웃 라우터의 IP 주소를 나타냅니다. 각 이웃 RSVP 라우터 루프백 주소가 목록에 있는지 확인합니다.
RSVP 세션 확인
목적
모든 RSVP 이웃 간에 RSVP 세션이 설정되었는지 확인합니다. 또한 대역폭 예약 값이 활성화되는지 확인합니다.
작업
CLI에서 show rsvp session detail 명령을 입력합니다.
user@r1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.9.7 From: 10.0.6.1, LSPstate: Up, ActiveRoute: 0 LSPname: r1–r7, LSPpath: Primary Bidirectional, Upstream label in: –, Upstream label out: - Suggested label received: -, Suggested label sent: – Recovery label received: -, Recovery label sent: 100000 Resv style: 1 FF, Label in: -, Label out: 100000 Time left: -, Since: Thu Jan 26 17:57:45 2002 Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 Port number: sender 3 receiver 17 protocol 0 PATH rcvfrom: localclient PATH sentto: 10.0.4.13 (ge-0/0/1.0) 1467 pkts RESV rcvfrom: 10.0.4.13 (ge-0/0/1.0) 1467 pkts Record route: <self> 10.0.4.13 10.0.2.1 10.0.8.10
출력은 각각 설정된 RSVP 세션에 대해 세션 ID, 대역폭 예약 및 다음 홉 주소를 포함한 자세한 정보를 보여줍니다. 다음 정보를 확인합니다:
각 RSVP 이웃 주소는 루프백 주소로 나열된 각 이웃에 대한 항목을 보유합니다.
각 LSP 세션의 상태는 Up입니다.
Tspec에는 적절한 대역폭 값 10Mbps이(가) 나타납니다.
RSVP 신호 LSP의 존재 확인
목적
entry(수신) 라우터의 라우팅 테이블이 다른 라우터의 루프백 주소에 구성된 LSP를 가졌는지 확인합니다. 예를 들어, 그림 1에서 R1 entry 라우터의 inet.3 라우팅 테이블이 라우터 R7의 루프백 주소에 구성된 LSP를 가졌는지 확인합니다.
작업
CLI에서 show route table inet.3 명령을 입력합니다.
user@r1> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.9.7/32 *[RSVP/7] 00:05:29, metric 10
> to 10.0.4.17 via ge-0/0/0.0, label-switched-path r1–r7
출력은 inet.3 라우팅 테이블에 존재하는 RSVP 경로를 보여줍니다. RSVP 신호 LSP가 MPLS 네트워크에서 exit(송신) 라우터 R7의 루프백 주소와 연결되었는지 확인합니다.
예: RSVP 자동 메시 구성
서비스 프로바이더는 종종 BGP 및 MPLS VPN을 사용하여 수익 생성 서비스를 제공하는 동시에 네트워크를 효율적으로 확장합니다. 이러한 환경에서 BGP는 서비스 프로바이더의 네트워크 전반에 VPN 라우팅 정보를 배포하는 데 사용되는 반면, MPLS는 하나의 VPN 사이트에서 다른 사이트로 VPN 트래픽을 전달하는 데 사용됩니다.
BGP 및 MPLS VPN에 참여할 새로운 PE 라우터를 추가할 때, 기존의 모든 PE 라우터는 BGP와 MPLS 모두의 새로운 PE 라우터와 피어링하도록 구성되어야 합니다. 각 새로운 PE 라우터가 서비스 프로바이더의 네트워크에 추가되면서, 구성 부담은 곧 처리하기에 너무 많아집니다.
BGP 피어링 구성 요구 사항은 경로 리플렉터를 사용하여 줄일 수 있습니다. RSVP 신호 MPLS 네트워크에서, RSVP 자동 메시는 네트워크의 MPLS 부분의 구성 부담을 최소화할 수 있습니다. 모든 PE 라우터에서 rsvp-te을(를) 구성하면 RSVP가 새로운 PE 라우터가 추가될 때 필요한 LSP를 자동으로 생성합니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
Junos OS 릴리스 10.1 이상에서 실행되는 라우터.
MPLS 레이블 스위칭 경로(LSP) 신호 프로토콜로 RSVP를 사용하는 BGP 및 MPLS VPN.
개요
이 예는 rsvp-te 구성 문을 사용하는 PE 라우터에서 RSVP 자동 메시를 구성하는 방법을 보여줍니다. RSVP 자동 메시가 제대로 작동하려면, 풀 메시 구성의 모든 PE 라우터에 rsvp-te 문 구성을 해야 합니다. 그러면 나중에 추가된 모든 새로운 PE 라우터 또한 rsvp-te 문으로 구성된 경우라면 자동 메시 기능의 혜택을 누릴 수 있습니다.
이 요구 사항을 감안할 때, 이 예는 새로 추가된 PE 라우터의 구성만 보여줍니다. RSVP 자동 메시가 이미 기존 PE 라우터에 구성되었다고 가정합니다.
토폴로지
그림 2에는 토폴로지에 세 개의 기존 PE 라우터인 PE1, PE2 및 PE3가 있습니다. PE4가 추가되었으며, RSVP 자동 메시가 구성됩니다. 클라우드는 서비스 프로바이더 네트워크를 나타내며, 네트워크 주소 192.0.2.0/24는 그림의 중심에 표시됩니다.
구성
RSVP 자동 메시 구성은 다음 작업을 수행하는 것을 포함합니다:
[edit routing-options dynamic-tunnels dynamic-tunnel-name]계층 수준에서rsvp-te구성 문 활성화.필요한
destination-networks요소 구성.이 구성 요소는 대상 네트워크의 IPv4 접두사 범위를 지정합니다. 지정된 접두사 범위 내의 터널만 생성할 수 있습니다.
필요한
label-switched-path-template요소 구성.이 구성 요소는 인자로
default-template또는 사전 구성된 LSP 템플릿의 이름을 사용합니다.default-template은(는) 사용자 구성이 필요하지 않은 시스템 정의 템플릿입니다.
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣습니다.
PE4 라우터
set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
RSVP 자동 메시 구성
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 이를 수행하는 방법에 대한 지침은 CLI 사용자 가이드의 구성 모드에서 CLI 편집기 사용을 참조하십시오.
RSVP 자동 메시 활성화:
[edit routing-options dynamic-tunnels]계층 수준에서rsvp-te을(를) 구성합니다.[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template
[edit routing-options dynamic-tunnels]계층 수준에서destination-networks을(를) 구성합니다.[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
결과
[edit routing-options dynamic-tunnels] 계층 수준에서 show 명령을 발행하여 구성 결과를 확인합니다:
[edit routing-options dynamic-tunnels]
user@PE4#show
dt-1 {
rsvp-te rsvp-te-1 {
label-switched-path-template {
default-template;
}
destination-networks {
192.0.2.0/24;
}
}
}
검증
라우터 PE4에서 RSVP 자동 메시 터널의 존재 확인
목적
새로 구성된 PE4 라우터의 작동을 확인하기 위해 운영 모드에서 show dynamic-tunnels database 명령을 발행합니다. 이 명령은 동적 터널을 생성할 수 있는 대상 네트워크를 보여줍니다.
작업
user@PE4> show dynamic-tunnels database Table: inet.3 Destination-network: 192.0.2.0/24
라우터 PE4에서 MPLS LSP의 존재 확인
목적
PE4 라우터에서 MPLS LSP의 존재를 확인하기 위해 운영 모드에서 show mpls lsp 명령을 발행합니다. 이 명령은 MPLS LSP의 상태를 보여줍니다.
작업
user@PE4> show mpls lsp
Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.0.2.104 192.0.2.103 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.102 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.101 Up 0 1 FF 3 - PE1-PE4 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
비세션 RSVP 이웃에 대한 Hello 승인 구성하기
hello-acknowledgements 명령문은 동일한 세션 여부와 관계 없이 RSVP 이웃 간 Hello 승인 행동을 통제합니다.
일반적인 RSVP 세션의 일부가 아닌 RSVP 이웃에서 받은 Hello 메시지는 폐기됩니다. [edit protocols rsvp] 계층에서 hello-acknowledgements 명령문을 구성하는 경우, 비세션 이웃의 Hello 메시지는 Hello 승인 메시지와 함께 승인됩니다. 비세션 이웃에서 Hello를 받으면 RSVP 이웃 관계가 생성되며 비세션 이웃으로부터 주기적인 Hello 메시지를 이제 수신하게 됩니다. hello-acknowledgements 명령문은 기본적으로 비활성화됩니다. 이 명령문을 구성하면 Hello 패킷을 사용하여 RSVP 가능한 라우터가 발견되며 MPLS LSP 설정 메시지를 보내기기 전에 인터페이스가 RSVP 패킷을 수신할 수 있음을 확인합니다.
비세션 RSVP 이웃에 대한 Hello 승인이 가능해지면 인터페이스 자체가 다운되거나 구성을 변경하지 않는 한 라우터는 모든 비세션 RSVP 이웃으로부터의 Hello 메시지를 계속 인정합니다. 인터페이스 기반 이웃은 자동으로 나이가 지나지 않습니다.
hello-acknowledgements;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
LSP를 네트워크 노드에서 분리하여 스위칭
인터페이스에 대해 활성화된 우회 LSP를 사용하여 활성 LSP를 네트워크 노드에서 분리하여 스위칭하도록 라우터를 구성하실 수 있습니다. 네트워크를 통과하는 트래픽을 방해하지 않으면서 디바이스를 교체해야 할 때 활성 네트워크를 유지하는 데 이 기능을 사용할 수 있습니다. LSP는 정적이거나 동적일 수 있습니다.
활성 LSP를 네트워크 노드에서 분리하여 스위칭하는 것과 관련하여 다음과 같은 제한 사항을 참고해 주십시오.
이렇게 분리하여 스위칭하는 기능은 MX 시리즈 라우터에서만 지원됩니다.
이 분리 스위칭 기능은 기본 포인트-투-멀티포인트 LSP의 트래픽을 우회 포인트-투-멀티포인트 LSP로 스위칭하는 데는 지원되지 않습니다. 포인트-투-멀티포인트 LSP에 대해
switch-away-lsps명령문을 구성할 경우, 트래픽이 우회 포인트-투-멀티포인트 LSP로 스위칭되지 않습니다.동적 LSP의 경로를 따라 인터페이스에서 분리 스위칭 기능을 구성할 경우, 해당 경로에는 새로운 동적 LSP가 설정될 수 없습니다. 분리 스위칭 기능은 RSVP 신호 전송 LSP의 단절 전 접속 작동을 방지해 줍니다. 단절 전 접속 방식은 보통 라우터가 원본을 삭제하기 전에 우선 동적 LSP에 다시 신호 전송을 시도하게 합니다.
RSVP 설정 보호 구성
신호 받기 중인 LSP에 대한 설정 보호를 제공하기 위해 시설 백업 Fast Reroute 메커니즘을 구성할 수 있습니다. 포인트-투 포인트 LSP와 포인트-투 -멀티포인트 LSP는 지원됩니다. 이 기능은 다음 시나리오에서 적용됩니다.
실패한 링크 또는 노드는 LSP가 신호를 받기 전에 LSP의 명시적 경로 상에 존재합니다.
링크 또는 노드를 보호하는 우회 LSP도 있습니다.
RSVP는 우회 LSP를 통해 LSP를 신호합니다. LSP는 마치 원래 주요 경로를 따라 설정되었다가 링크 또는 노드 실패로 인해 우회 LSP로 장애 조치된 것처럼 보입니다.
링크 또는 노드가 회복되면 LSP는 자동으로 기본 경로로 되돌려질 수 있습니다.
LSP 설정 보호를 활성화하려는 LSP 경로를 따라 각 라우터의 [edit protocols rsvp]에서 setup-protection문을 구성해야 합니다. 또한 LSP 경로의 모든 라우터에서 IGP 트래픽 엔지니어링 구성을 해야합니다. show rsvp session명령을 실행하여 LSP가 로컬 수리 포인트(PLR) 또는 병합 포인트 역할을 하는 라우터에서 설정 보호가 활성화되었는지 여부를 확인할 수 있습니다.
RSVP 설정 보호를 활성화하려면 setup-protection문을 포함합니다.
setup-protection;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
RSVP LSP에 대한 로드 밸런싱 구성
기본적으로 동일한 송신 라우터에 여러 RSVP LSP를 구성한 경우에는 가장 낮은 메트릭의 LSP가 선택되어 모든 트래픽을 전송합니다. 모든 LSP가 동일한 메트릭을 갖고 있으면 무작위로 LSP 중 하나가 선택되어 모든 트래픽을 전송합니다.
또는 패킷당 로드 밸런싱을 활성화하여 전체 LSP에 대해 트래픽 로드를 분산할 수도 있습니다.
수신 LSP에서 패킷당 로드 밸런싱을 활성화하려면 다음과 같이 policy-statement 명령문을 구성하십시오.
[edit policy-options] policy-statement policy-name { then { load-balance per-packet; } accept; }
그런 다음 이 명령문을 포워딩 테이블에 내보내기 정책으로 적용해야 합니다.
패킷당 로드 밸런싱이 적용되면 LSP 간에 트래픽이 균등하게 분산됩니다(기본값).
PFE 고속 재라우팅(FRR)을 활성화하기 위해서는 패킷당 로드 밸런싱을 구성해야 합니다. PFE 고속 재라우팅(FRR)을 활성화하려면 재라우팅이 발생할 수 있는 각 라우터의 구성에서 이 섹션에 나와 있는 패킷당 로드 밸런싱을 위한 policy-statement 명령문을 포함하십시오. 또한 고속 재라우팅(FRR) 구성도 참조해 주십시오
각 LSP에 대해 구성된 대역폭 양에 비례하여 LSP 간에 트래픽 로드를 분산하는 것도 가능합니다. LSP의 구성된 대역폭은 보통 해당 LSP의 트래픽 용량을 반영하기 때문에 이 기능은 외부 링크에 대한 비대칭 대역폭 기능으로 네트워크에서 트래픽을 더욱 효율적으로 분산할 수 있습니다.
RSVP LSP 로드 밸런싱을 구성하려면 bandwidth 옵션의 load-balance 명령문을 포함하십시오.
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) 를 자동으로 설정할 수 있도록 RSVP를 구성할 수 있습니다. 이 기능을 사용하려면 전체 메쉬의 모든 PE 라우터에 대한 rsvp-te문을 구성해야 합니다.
CCC와 함께 RSVP 자동 메쉬를 구성할 수 없습니다. CCC는 동적으로 생성된 LSP를 사용할 수 없습니다.
RSVP 자동 메쉬를 구성하기 위해 rsvp-te문을 포함시킵니다.
rsvp-te { destination-networks network-prefix; label-switched-path-template (Multicast) { default-template; template-name; } }
이 명령문은 다음과 같은 계층 수준에서 구성할 수 있습니다.
[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) 접두사 범위를 지정합니다. 지정된 IPv4 접두사 범위 내의 동적 터널이 시작될 수 있습니다.label-switched-path-template (Multicast)--default-template옵션을 사용하여 명시적으로 기본 템플릿을 구성할 수 있거나template-name옵션을 사용하여 해당 사용자만의 LSP 템플릿을 구성할 수 있습니다. LSP 템플릿은 동적으로 생성된 LSP의 모델 구성 역할을 합니다.
RSVP 새로 고침 메시지에 대한 타이머 구성
RSVP는 두 가지 관련 타이밍 매개 변수를 사용합니다.
refresh-time- 새로 고침 시간은 연속되는 새로 고침 메시지 생성 간의 간격을 제어합니다. 새로 고침 시간에 대한 기본 값은 45초입니다. 이 수치는refresh-time문의 기본 값에서 30에 고정 값 1.5를 곱하여 나온 값입니다. 이 계산은 새로 고침 시간에 0.5에서 1.5까지의 범위의 임의의 값을 곱해야 한다고 명시한 RFC 2205와 다릅니다.새로 고침 메시지에는 경로 및 Resv 메시지가 포함됩니다. 새로 고침 메시지를 주기적으로 전송되어 이웃 노드의 예약 상태가 시간 초과되지 않도록 해줍니다. 각 경로 및 Resv 메시지에는 새로 고침 타이머 값이 전달되며, 수신 노드는 메시지로부터 이 값을 추출합니다.
keep-multiplier- 유지 배수는 1에서 255까지의 작은 수이며, 로컬에서 구성된 정수입니다. 기본 값은 3입니다. 특정 상태가 교착 상태로 선언되어 삭제되기까지 손실되는 메시지의 수를 나타냅니다. 유지 배수는 RSVP 상태의 수명에 직접 영향을 미칩니다.
예약 상태의 수명을 결정하기 위해 다음 공식을 사용합니다.
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
최악의 경우에 예약 상태가 삭제되기 전에 (keep-multiplier – 1)개의 연속 새로 고침 메시지가 손실되어야 합니다.
짧은 RSVP Hello 타이머를 구성하는 것을 권장하지 않습니다. 실패한 이웃을 빨리 발견해야 할 경우, 짧은 IGP (OSPF 또는 IS-IS) 헬로 타이머를 구성하십시오.
기본적으로 새로 고침 타이머 값은 30초입니다. 이 값을 수정하려면 refresh-time 문을 포함시킵니다:
refresh-time seconds;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
유지 배수의 기본 값은 3입니다. 이 값을 수정하려면 keep-multiplier 문을 포함합니다.
keep-multiplier number;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
RSVP 세션 선점
모든 RSVP 세션을 처리하기에 대역폭이 부족할 때면, RSVP 세션의 선점을 제어할 수 있습니다. 기본적으로 RSVP 세션은 새로운 높은 우선 순위 세션에서만 선점됩니다.
대역폭이 부족할 때 항상 세션을 선점하려면, aggressive 옵션의 preemption 문을 포함합니다:
preemption aggressive;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
RSVP 세션 선점을 비활성화하려면, disabled 옵션의 preemption 문을 포함합니다:
preemption disabled;
기본값(즉, 새로운 높은 우선 순위 세션에서만 세션 선점)으로 돌아가려면, normal 옵션의 preemption 문을 포함합니다:
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문을 포함시킵니다:
path-mtu { allow-fragmentation; rsvp { mtu-signaling; } }
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
다음 섹션에서는 RSVP에서 패킷 단편화 및 최대 전송 단위(MTU) 신호를 활성화시키는 방법을 설명합니다:
RSVP에서의 최대 전송 단위(MTU) 신호 활성화
RSVP에서 최대 전송 단위(MTU) 신호를 활성화하기 위해 rsvp mtu-signaling문을 포함시킵니다:
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문만 구성하는 경우, show rsvp session detail명령어를 사용하여 LSP에서 가장 작은 최대 전송 단위(MTU)가 무엇인지 확인할 수 있습니다. show rsvp session detail명령어는 Adspec 객체에서 수신 및 전송된 최대 전송 단위(MTU) 값을 표시합니다.
패킷 단편화 활성화
IP 패킷이 MPLS에서 캡슐화되기 전에 단편화될 수 있도록 하려면 allow-fragmentation문을 포함시킵니다:
allow-fragmentation;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls path-mtu][edit logical-systems logical-system-name protocols mpls path-mtu]주:allow-fragmentation문을 단독으로 구성하지 마십시오. 항상mtu-signaling문을 함께 구성합니다.
LSP에 대한 UHP 구성
기본적으로 RSVP 신호 전송 LSP는 PHP(Penultimate-Hop Popping)를 사용합니다. 그림 3에는 라우터 PE1과 라우터 PE2 간의 PHP LSP가 나와 있습니다. 라우터 CE1은 LSP 수신 라우터이기도 한 다음 홉(라우터 PE1)으로 패킷을 전달합니다. 라우터 PE1은 이 패킷의 레이블 1을 푸시하고 레이블 지정된 이 패킷을 라우터 P1로 전달합니다. 라우터 P1은 표준 MPLS 레이블 스와핑 작업을 완료하여 레이블 1과 레이블 2를 교체하고 패킷을 라우터 P2로 전달합니다. 라우터 P2는 LSP에서 라우터 PE2에 대해 끝에서 두 번째 홉 라우터이므로 먼저 해당 레이블을 내보낸 다음 라우터 PE2에 이 패킷을 전달합니다. 라우터 PE2가 수신하면 이 패킷은 서비스 레이블이나 명시적 NULL 레이블을 가질 수 있고 단순히 일반 IP 또는 VPLS 패킷이 될 수도 있습니다. 라우터 PE2는 레이블이 지정되지 않은 패킷을 라우터 CE2로 전달합니다.
RSVP 신호 전송 LSP에 대해서도 그림 4에 나온 것과 같이 UHP(Ultimate-Hop Popping)를 구성하실 수 있습니다. 일부 네트워크 애플리케이션에서는 송신 라우터(라우터 PE2)에 도착하는 패킷이 NULL이 아닌 외부 레이블을 포함해야 할 수 있습니다. UHP(Ultimate-Hop Popping) LSP를 위해 끝에서 두 번째 라우터(그림 4의 라우터 P2)는 패킷을 송신 라우터 PE2에 전달하기 전에 표준 MPLS 레이블 스와핑(이 예에서는 레이블 2와 레이블 3 교체) 작업을 수행합니다. 라우터 PE2는 외부 레이블을 내보내고 패킷 주소의 두 번째 조회를 수행하여 최종 대상을 결정합니다. 그런 다음 패킷을 해당 대상(라우터 CE2 또는 라우터 CE4)으로 전달합니다.
다음과 같은 네트워크 애플리케이션에서는 UHP LSP를 구성하셔야 합니다.
성능 모니터링 및 인밴드 OAM을 위한 MPLS-TP
에지 보호 가상 서킷
다음과 같은 기능은 UHP 동작을 지원하지 않습니다.
LDP 신호 전송 LSP
정적 LSP
포인트 투 멀티포인트 LSP
ccc
traceroute명령
UHP 동작에 대한 보다 자세한 내용은 인터넷 초안 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, RSVP-TE LSP를 위한 아웃오브밴드 매핑 및 PHP가 아닌 동작을 참조하십시오.
포인트 투 포인트 RSVP 신호 전송 LSP의 경우, UHP 동작은 LSP 수신 신호를 받습니다. 수신 라우터 구성을 기반으로 RSVP는 PHP가 아닌 플래그 세트를 포함하는 UHP LSP의 신호를 전송할 수 있습니다. RSVP PATH 메시지는 LSP-ATTRIBUTES 개체의 이 두 개 플래그를 전달합니다. 송신 라우터는 이 PATH 메시지를 수신하면 LSP에 NULL이 아닌 레이블을 할당합니다. RSVP 또한 mpls.0 라우팅 테이블에 두 개의 경로를 생성하여 설치합니다. S는 MPLS 레이블의 S 부분을 의미하며, 레이블 스택의 최하단에 도달했는지 여부를 나타냅니다.
Route S=0 - 스택에 레이블이 더 있음을 나타냅니다. 이 경로의 다음 홉은 mpls.0 라우팅 테이블을 가리켜 연동된 MPLS 레이블 조회를 트리거함으로써 스택에 남아 있는 MPLS 레이블을 찾습니다.
Route S=1 - 레이블이 더 이상 없음을 나타냅니다. 플랫폼에서 연동된 멀티 패밀리 조회가 지원되는 경우, 다음 홉은 inet.0 라우팅 테이블을 가리킵니다. 또는 레이블 경로가 VT 인터페이스를 가리켜 IP 전달을 시작할 수도 있습니다.
UHP LSP를 활성화하면 레이어 3 VPN, VPLS, 레이어 2 VPN, 레이어 2 서킷 등과 같은 MPLS 애플리케이션이 UHP LSP를 사용할 수 있습니다. 아래에는 UHP LSP가 여러 유형의 MPLS 애플리케이션에 어떻게 영향을 미치는지에 대한 설명이 나와 있습니다.
레이어 2 VPN 및 레이어 2 서킷 - PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블(S=0)은 UHP 레이블이고, 내부 레이블(S=1)은 VC 레이블입니다. 전송 레이블을 기반으로 하는 조회에 따라 mpls.0 라우팅 테이블에 대한 테이블 처리가 발생합니다. mpls.0 라우팅 테이블에 내부 레이블에 해당하는 추가 경로가 있습니다. 내부 레이블을 기반으로 하는 조회에 따라 고객 에지(CE) 라우터 다음 홉이 발생합니다.
레이어 3 VPN - PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블(S=0)은 UHP 레이블이고, 내부 레이블은 VPN 레이블(S=1)입니다. 전송 레이블을 기반으로 하는 조회에 따라 mpls.0 라우팅 테이블에 대한 테이블 처리가 발생합니다. 이 시나리오에서는 두 가지 경우가 있습니다. 기본적으로 레이어 3 VPN은 다음 홉별 레이블을 광고합니다. 내부 레이블을 기반으로 하는 조회에 따라 고객 에지(CE) 라우터로 향하는 다음 홉이 발생합니다. 그러나 레이어 3 VPN 라우팅 인스턴스에 대해
vrf-table-label명령문을 구성하신 경우, 내부 LSI 레이블은 VRF 라우팅 테이블을 가리킵니다. VRF 라우팅 테이블에 대해 IP 조회도 완료됩니다.주:vrf-table-label명령문으로 구성한 레이어 3 VPN에 대한 UHP는 MX 시리즈 5G 유니버설 라우팅 플랫폼에서만 지원됩니다.VPLS - PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블은 전송 레이블(S=0)이고, 내부 레이블은 VPLS 레이블(S=1)입니다. 전송 레이블을 기반으로 하는 조회에 따라 mpls.0 라우팅 테이블에 대한 테이블 처리가 발생합니다. 터널 서비스가 구성되지 않았거나 VT 인터페이스를 사용할 수 없는 경우 mpls.0 라우팅 테이블의 내부 레이블을 기반으로 하는 조회에 따라 VPLS 라우팅 인스턴스의 LSI 터널 인터페이스가 발생합니다. MX 3D 시리즈 라우터는 연동 조회 및 멀티 패밀리 조회를 지원합니다.
주:no-tunnel-service명령문으로 구성한 VPLS에 대한 UHP는 MX 3D 시리즈 라우터에서만 지원됩니다.MPLS를 통한 IPv4 - PE 라우터(UHP LSP의 송신 라우터)에 한 개 레이블(S=1)을 포함하는 패킷이 도착합니다. 이 레이블을 기반으로 하는 조회가 VT 터널 인터페이스를 반환합니다. 패킷을 어디로 전달할지 결정하기 위해 VT 인터페이스에서 또 다른 IP 조회가 완료됩니다. 라우팅 플랫폼이 멀티 패밀리 조회와 연동 조회를 지원하는 경우(예: MX 3D 라우터 및 PTX 시리즈 패킷 전송 라우터), 레이블 경로(S=1)를 기반으로 하는 조회가 inet.0 라우팅 테이블을 가리킵니다.
MPLS를 통한 IPv6 - MPLS를 통한 IPv6 터널링의 경우, PE 라우터는 레이블 값 2를 이용해 서로에게 IPv6 경로를 광고합니다. 이것이 IPv6에 대한 명시적 NULLL 레이블입니다. 그 결과 원격 PE 라우터에서 학습된 IPv6 경로에 대한 포워딩 다음 홉은 보통 두 개의 레이블을 푸시합니다. 내부 레이블은 2(광고하는 PE 라우터가 다른 벤더 제품인 경우 다를 수 있음)이고, 라우터 레이블은 LSP 레이블입니다. PE 라우터(UHP LSP의 송신 라우터)에 두 개의 레이블을 포함하는 패킷이 도착합니다. 외부 레이블은 전송 레이블(S=0)이고, 내부 레이블은 IPv6 명시적 NULL 레이블(레이블 2)입니다. mpls.0 라우팅 테이블의 내부 레이블을 기반으로 하는 조회가 mpls.0 라우팅 테이블로 다시 리디렉션됩니다. MX 3D 시리즈 라우터에서는 내부 레이블(레이블 2)이 제거되고 inet6.0 라우팅 테이블을 사용하여 IPv6 조회가 수행됩니다.
PHP 및 UHP LSP 모두 활성화 - 동일한 네트워크 경로에서 PHP 및 UHP LSP를 모두 구성하실 수 있습니다.
install-nexthop명령문을 포함하는 정규식을 사용하여 포워딩 LSP 다음 홉을 선택하면 PHP 트래픽과 UHP 트래픽을 분리하실 수 있습니다. 또한 단순히 LSP 이름을 적절히 지정하는 방법으로도 트래픽 분리가 가능합니다.
다음의 명령문은 LSP에 대한 UHP(Ultimate-Hop Popping)를 활성화해줍니다. 이 기능은 특정 LSP에 대해 또는 라우터에서 구성된 모든 수신 LSP에 대해 활성화하실 수 있습니다. LSP 수신 라우터에서 다음의 명령문을 구성하십시오.
Ultimate-Hop 라우터에서 레이블이 팝하도록 RSVP 구성
LSP의 송신 라우터에서 광고되는 레이블 값을 제어할 수 있습니다. 기본으로 광고되는 레이블은 레이블 3(Implicit Null 레이블)입니다. 레이블 3이 광고되면 Penultimate-Hop 라우터가 레이블을 제거하고 패킷을 송신 라우터로 보냅니다. Ultimate-Hop Popping이 활성화되면, 레이블 0(IP 버전 4 [IPv4] 명시적 Null 레이블)이 광고됩니다. UHP(Ultimate-Hop Popping)는 MPLS 네트워크를 트래버스하는 모든 패킷이 레이블을 포함하도록 합니다.
주니퍼 네트웍스 라우터는 수신 레이블을 기반으로 패킷을 대기열에 넣습니다. 다른 벤더의 라우터는 패킷을 다르게 대기열에 넣을 수 있습니다. 여러 벤더의 라우터가 포함된 네트워크에서 작업할 때는 이 사실을 염두에 두십시오.
RSVP에 대한 Ultimate-Hop Popping을 구성하려면, explicit-null 문을 포함합니다:
explicit-null;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
Point-to-Multipoint LSP에서 UHP(Ultimate-Hop Popping) 활성화
Point-to-Point 및 Point-to-Multipoint LSP 모두 기본적으로 Penultimate-Hop Popping이 MPLS 트래픽에 사용됩니다. MPLS 레이블은 LSP의 송신 라우터 직전에 라우터의 패킷에서 제거됩니다. 그런 다음 일반 IP 패킷이 송신 라우터로 전달됩니다. Ultimate-Hop Popping의 경우, 송신 라우터가 MPLS 레이블 제거와 일반 IP 패킷 처리를 모두 담당합니다.
특히 전송 트래픽이 동일한 송신 디바이스를 트래버스할 때 Point-to-Multipoint LSP에서 Ultimate-Hop Popping을 활성화하는 것이 유익할 수 있습니다. Ultimate-Hop Popping을 활성화하면, 수신 링크로 단일 트래픽 사본이 전송되어 큰 대역폭을 절약할 수 있습니다. 기본적으로 Ultimate-Hop Popping이 비활성화됩니다.
tunnel-services 문을 구성하여 Point-to-Multipoint LSP에 대한 Ultimate-Hop Popping을 구성할 수 있습니다. Ultimate-Hop Popping을 활성화할 때, Junos OS는 IP 포워딩을 위해 PFE로 패킷을 루프 백하기 위해 사용 가능한 가상 루프백 터널(VT) 인터페이스 중 하나를 선택합니다. 기본적으로 VT 인터페이스 선택 프로세스가 자동으로 수행됩니다. 대역폭 승인 제어는 하나의 VT 인터페이스에 사용할 수 있는 LSP의 수를 제한하는 데 사용됩니다. 모든 대역폭이 하나의 인터페이스에 사용되면, Junos OS는 승인 제어를 위한 충분한 대역폭을 갖춘 다른 VT 인터페이스를 선택합니다.
LSP가 VT 인터페이스에서 가능한 것 이상의 대역폭을 필요로 하는 경우, Ultimate-Hop Popping을 활성화할 수 없으며 대신 Penultimate-Hop Popping이 활성화됩니다.
Point-to-Multipoint LSP에서 Ultimate-Hop Popping이 제대로 작동하려면, 송신 라우터가 터널 서비스 PIC 또는 적응형 서비스 PIC와 같은 터널 서비스를 제공하는 PIC를 가져야 합니다. 터널 서비스는 최종 MPLS 레이블을 팝하고 IP 주소 조회를 위해 패킷을 반환하는 데 필요합니다.
tunnel-services 문에 대한 devices 옵션을 포함하여 어떤 VT 인터페이스가 RSVP 트래픽을 처리할지 명시적으로 구성할 수 있습니다. devices 옵션으로 RSVP에서 사용할 VT 인터페이스를 지정할 수 있습니다. 이 옵션을 구성하지 않으면, 라우터에 가능한 모든 VT 인터페이스를 사용할 수 있습니다.
라우터에서 송신 Point-to-Multipoint LSP에 대한 Ultimate-Hop Popping을 활성화하려면, tunnel-services 문을 구성합니다:
tunnel-services { devices device-names; }
이 명령문은 다음의 계층 수준에서 구성하실 수 있습니다.
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
송신 Point-to-Multipoint LSP에 대한 Ultimate-Hop Popping을 활성화하려면, all 옵션으로 interface 문을 구성해야 합니다:
interface all;
이 명령문은 [edit protocols rsvp] 계층 수준에서 구성해야 합니다.
RSVP 프로토콜 트래픽 추적
RSVP 프로토콜 트래픽은 추적하려면 다음과 같이 traceoptions 문을 포함시킵니다.
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
RSVP traceoptions 문에서 다음과 같은 RSVP 관련 플래그를 지정할 수있습니다.
file 문을 사용하여 tracing 연산의 출력을 수신하는 파일 이름을 지정할 수 있습니다. 모든 파일은 /var/log 디렉터리에 배치됩니다. RSVP 추적 출력을 rsvp-log 파일에 배치하는 것을 권장합니다.
all- 모든 추적 작업.error- 감지된 모든 오류 조건event- RSVP 관련 이벤트(RSVP graceful 재시작 관련 이벤트 추적에 도움이 됨)lmp- RSVP-링크 관리 프로토콜(LMP) 상호 작용packets- 모든 RSVP 패킷path- 모든 경로 메시지pathtear- PathTear 메시지resv- Resv 메시지resvtear- ResvTear 메시지route- 라우팅 정보state- RSVP 신호 LSP가 작동하고 중단되는 경우를 포함한 세션 상태 전환.
all 추적 플래그와 detail 플래그 한정자를 사용할 때는 CPU 사용량이 매우 많을 수 있으므로 주의하십시오.
RSVP traceoptions를 활성화할 때 생성되는 로그 파일을 보려면 show log file-name 명령을 실행합니다. 여기서 file-name은 traceoptions 문을 사용하여 지정한 파일입니다.
추적 및 전역 추적 옵션에 관한 일반 정보는 라우팅 장치용 Junos OS 라우팅 프로토콜 리이브러리를 참조하십시오.
예: RSVP 프로토콜 트래픽 추적
RSVP 경로 메시지 상세 추적:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag path;
}
}
}
모든 RSVP 메시지 추적:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag packets;
}
}
}
모든 RSVP 오류 조건 추적:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag error;
}
}
}
RSVP 상태 전환 추적:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp-data;
flag state;
}
}
}
RSVP 로그 파일 출력
다음은 state 플래그가 구성된 상태에서 RSVP traceoptions가 활성화된 라우터에서 show log file-name 명령을 실행하여 생성된 샘플 출력입니다. RSVP 신호 LSP E-D가 3월 11일 14:04:36.707092에 중단되는 것을 보여줍니다. 3월 11일 14:05:30.101492에 다시 작동하는 것을 보여줍니다.
user@host> show log rsvp-data
Mar 11 13:58:51 trace_on: Tracing to "/var/log/E/rsvp-data" started
Mar 11 13:58:51.286413 rsvp_iflchange for vt ifl vt-1/2/0.69206016
Mar 11 13:58:51.286718 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 1, is_appl_vt 0, already known
Mar 11 13:58:51.286818 RSVP Peer vt-1/2/0.69206016 TE-link __rpd:vt-1/2/0.69206016 Up
Mar 11 13:58:51.286978 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.287962 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.288629 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr 10.0.0.2, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.288996 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.289593 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.289949 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr 10.0.0.17, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.290049 RSVP Peer lt-1/2/0.17 TE-link __rpd:lt-1/2/0.17 Up
Mar 11 13:59:05.042034 RSVP new bypass Bypass->10.0.0.18 on interface lt-1/2/0.17 to 10.0.0.18 avoid 0.0.0.0
Mar 11 14:04:36.707092 LSP "E-D" is Down (Reason: Reservation state deleted)
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 1)
Mar 11 14:04:36.707661 RSVP delete resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781185 RSVP delete path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781440 RSVP delete session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.101492 RSVP new Session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0, session ID 3
Mar 11 14:05:30.101722 RSVP new path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179124 RSVP new resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179395 RSVP PSB E-D, allocating psb resources for label 4294967295
Mar 11 14:05:30.180353 LSP "E-D" is Up
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 2)RSVP Graceful Restart
RSVP Graceful Restart로 재시작 라우터가 인접 이웃에게 조건을 알려줄 수 있습니다. 재시작 라우터는 이웃 또는 피어로부터 유예 기간을 요청한 다음, 재시작 라우터와 협력할 수 있습니다. 재시작 라우터는 재시작 기간 중에도 MPLS 트래픽을 전달할 수 있으며, 네트워크의 컨버전스가 중단되지 않습니다. 재시작은 네트워크의 나머지에는 표시되지 않으며, 재시작 라우터는 네트워크 토폴로지에서 제거되지 않습니다. RSVP Graceful Restart는 전송 라우터와 수신 라우터 모두에서 사용할 수 있습니다. point-to-point LSP와 point-to-multipoint LSP에 모두 사용할 수 있습니다.
RSVP Graceful Restart는 다음 섹션에 설명되어 있습니다:
RSVP Graceful Restart 전문 용어
Restart 시간(밀리초 단위로)
기본값은 60,000밀리초(1분)입니다. 재시작 시간은 Hello 메시지에 표시됩니다. 시간은 인접 라우터가 재시작 중인 라우터로부터 Hello 메시지를 받기 위해 얼마나 기다려야 하는지 나타냅니다.
Junos OS는 시간이 로컬 재시작 시간의 1/3보다 큰 경우, 인접 라우터가 광고하는 재시작 시간을 재정의할 수 있습니다. 예를 들어, 기본 재시작 시간이 60초인 경우, 라우터는 재시작 하는 인접 라우터로부터 Hello 메시지를 받기 위해 20초 이하를 기다릴 것입니다. 재시작 시간이 0인 경우, 재시작 중인 인접 라우터가 즉시 비활성 상태로 선언될 수 있습니다.
복구 시간(밀리초 단위)
재시작 시간 전에 제어 채널이 가동(hello 교환 완료) 된 경우에만 적용됩니다. 결함 노드에만 적용됩니다.
Graceful Restart가 진행 중인 경우, 복구를 완료하는 데 남은 시간이 광고됩니다. 이 값은 0인 경우도 있습니다. 광고된 최대 복구 시간은 2분(120,000밀리초)입니다.
복구 시간 동안, 재시작 노드는 인접 라우터의 도움을 받아 손실된 상태를 복구하려고 시도합니다. 재시작 노드의 인접 라우터는 복구 시간의 1/2 기간 내에 복구 레이블이 있는 경로 메시지를 재시작 노드로 보내야 합니다. 재시작 노드는 광고된 복구 시간 이후에 Graceful Restart이 완료된 것으로 간주합니다.
RSVP 그레이스풀 재시작(Graceful Restart) 작업
RSVP 그레이스풀 재시작이 작동하려면 글로벌 라우팅 인스턴스에서 기능이 반드시 활성화되어야 합니다. RSVP 그레이스풀 재시작은 프로토콜 수준(RSVP 단독)이나 또는 모든 프로토콜의 글로벌 수준에서 비활성화될 수 있습니다.
RSVP 그레이스풀 재시작은 재시작 라우터 및 라우터 이웃의 다음 사항을 요구합니다.
재시작 라우터의 경우 RSVP 그레이스풀 재시작은 RSVP와 할당된 레이블에 의해 설치된 경로를 유지하므로 트래픽은 중단없이 계속 전달됩니다. RSVP 그레이스풀 재시작은 이웃 노드에 대한 영향을 줄이거나 없애기에 충분한 빠른 속도로 수행됩니다.
이웃 라우터는 RSVP 그레이스풀 재시작 도움 모드를 활성화해야 하므로 RSVP를 재시작하려는 라우터의 시도를 도울 수 있습니다.
RSVP hello 메시지에 보내지는 재시작 캡이라 불리는 개체는 노드의 재시작 기능을 광고합니다. 이웃 노드는 복원 레이블 객체를 재시작 노드에 전송하여 포워딩 상태를 확인합니다. 이 개체는 노드가 다운 전에 광고된 재시작 노드가 있는 오래된 레이블입니다.
다음은 구성에 따라 다양하고 기능이 활성화되어 있는 RSVP 그레이스풀 재시작 동작을 나열합니다.
도움 모드 비활성화 경우, Junos OS는 이웃 재시작 RSVP를 도우려는 시도를 하지 않습니다. 이웃의 재시작 캡 객체에 도달하는 모든 정보는 무시됩니다.
라우팅 인스턴스 구성에 따라 그레이스풀 재시작이 활성화되면 라우터는 이웃의 도움으로 그레이스풀 재시작을 할 수 있습니다. RSVP는 재시작 및 복구 시간이 지정(값이 0이 아님)되지 않은 hello 메시지에 재시작 캡 객 객체(RSVP RESTART)를 광고합니다.
계층
[protocols rsvp]수준에서 RSVP 그레이스풀 재시작을 명시적으로 비활성화하면 재시작 캡 객체는 0으로 지정된 재시작과 복구 시 광고됩니다. 이웃 라우터의 재시작은 지원되지만(도움 모드가 비활성화되어있지 않다면), 라우터 자체는 RSVP 포워딩 상태를 보존하고 제어 상태를 복구할 수 없습니다.재시작 RSVP 후 포워딩 상태가 보존되지 않았다는 것을 깨닫는 경우, 재시작 캡 객체는 0으로 지정된 재시작과 복구 시간으로 광고됩니다.
그레이스풀 재시작과 도움 모드가 비활성화되면, RSVP 그레이스풀 재시작은 완전히 비활성화됩니다. 라우터 또한 RSVP 그레이스풀 재시작 객체를 인식하지 않고 광고하지 않습니다.
재시작 및 복구 시간에 대한 값을 명시적으로 구성할 수 없습니다.
다른 프로토콜과는 달리, RSVP가 고정 타임아웃 이외의 재시작 절차를 완료했는지 결정하는 방법은 없습니다. 모든 RSVP 그레이스풀 재시작 절차는 타이머 기반입니다. show rsvp version 명령은 모든 RSVP 세션이 백업되고 경로가 복원되더라도 재시작 과정이 여전히 진행 중임을 나타낼 수 있습니다.
재시작된 캡 객체 처리
재시작된 캡 객체에 기초하여 이웃에 대한 다음과 같은 가정(제어 채널 실패가 노드 재시작과 모호하지 않게 구별될 수 있다고 가정)이 됩니다.
Hello 메시지에서 재시작된 캡 객체를 알리지 않는 이웃은 상태 또는 레이블 복구로 라우터를 도울 수 없으며 RSVP 적절한 재시작을 수행할 수도 없습니다.
재시작된 후, 재시작 시간이 임의의 값과 같고 복구 시간이 0인 재시작 캡 객체를 통보하는 이웃은 전송 상태를 보존하지 않았습니다. 복구 시간이 0이면 다시 시작 시간 값에 관계없이 이웃이 작동하지 않는 것으로 간주되고 이 이웃과 관련된 모든 상태가 제거됩니다.
재시작된 후, 0 이외의 값으로 복구 시간을 통보하는 이웃은 전송 상태를 유지하였거나 유지할 수 있습니다. 로칼 라우터 가 재시작 또는 복구 절차로 이웃을 지원하면 이 이웃에게 복구 레이블 객체를 보냅니다.
RSVP Graceful Restart 구성
다음 RSVP Graceful Restart 구성이 가능합니다:
Graceful Restart 및 Helper 모드가 모두 활성화됩니다(기본).
Graceful Restart는 활성화되지만, Helper 모드는 비활성화됩니다. 이 방식으로 구성된 라우터는 Graceful Restart가 가능하지만, 이웃의 재시작 및 복구 절차를 지원할 수는 없습니다.
Graceful Restart는 비활성화되지만, Helper 모드는 활성화됩니다. 이 방식으로 구성된 라우터는 Graceful Restart가 가능하지 않지만, 이웃의 재시작을 지원할 수 있습니다.
Graceful Restart 및 Helper 모드가 모두 비활성화됩니다. 이 구성은 RSVP Graceful Restart를 완전히 비활성화합니다(재시작 및 복구 절차 그리고 Helper 모드 포함). 라우터는 RSVP Graceful Restart를 지원하지 않는 라우터처럼 작동합니다.
RSVP Graceful Restart를 켜려면, 전역 Graceful Restart 타이머를 180초 이상으로 설정해야 합니다.
다음 섹션은 RSVP Graceful Restart를 구성하는 방법을 설명합니다:
- 모든 라우팅 프로토콜에서 Graceful Restart 활성화
- RSVP에서 Graceful Restart 비활성화
- RSVP Helper 모드 비활성화
- 최대 Helper 복구 시간 구성
- 최대 Helper 재시작 시간 구성
모든 라우팅 프로토콜에서 Graceful Restart 활성화
RSVP에 Graceful Restart를 활성화하려면, 라우터에서 Graceful Restart를 지원하는 모든 프로토콜에 대해 Graceful Restart를 활성화해야 합니다. Graceful Restart에 대한 자세한 내용은 라우팅 장치를 위한 Junos OS 라우팅 프로토콜 라이브러리를 참조하십시오.
라우터에서 Graceful Restart를 활성화하려면, graceful-restart 문을 포함합니다:
graceful-restart;
다음 계층 수준에서 이 문을 포함시킬 수 있습니다:
[edit routing-options][edit logical-systems logical-system-name routing-options]
RSVP에서 Graceful Restart 비활성화
기본적으로 Graceful Restart를 활성화할 때 RSVP Graceful Restart 및 RSVP Helper 모드가 활성화됩니다. 하지만 이 기능 중 하나 또는 둘 다 비활성화할 수 있습니다.
RSVP Graceful Restart 및 복구를 비활성화하려면 [edit protocols rsvp graceful-restart] 계층 수준에서 disable 문을 포함합니다:
disable;
RSVP Helper 모드 비활성화
RSVP Helper 모드를 비활성화하려면, [edit protocols rsvp graceful-restart] 계층 수준에서 helper-disable 문을 포함합니다:
helper-disable;
최대 Helper 복구 시간 구성
라우터의 RSVP 이웃이 Graceful Restart를 진행 중일 때 라우터가 RSVP 이웃의 상태를 유지하는 시간을 구성하려면, [edit protocols rsvp graceful-restart] 계층 수준에서 maximum-helper-recovery-time 문을 포함합니다. 이 값은 모든 이웃 라우터에 적용되므로, 복구하는 데 가장 느린 RSVP 이웃이 필요한 시간을 기준으로 해야 합니다.
maximum-helper-recovery-time seconds;
최대 Helper 재시작 시간 구성
라우터가 이웃 라우터가 중단된 것을 발견하고 이웃의 중단을 선언할 때 둘 사이의 지연을 구성하려면, [edit protocols rsvp graceful-restart] 계층 수준에서 maximum-helper-restart-time 문을 포함합니다. 이 값은 모든 이웃 라우터에 적용되므로, 재시작하는 데 가장 느린 RSVP 이웃이 필요한 시간을 기준으로 해야 합니다.
maximum-helper-restart-time seconds;
RSVP LSP 터널 개요
리소스 예약 프로토콜(RSVP) 레이블 스위치 경로(LSP) 터널은 다른 RSVP LSP 내에서 RSVP LSP를 보낼 수 있도록 해줍니다. 이것은 네트워크 관리자가 네트워크의 한쪽 끝에서 다른 쪽 끝에 트래픽 엔지니어링을 제공하는 것을 가능케 합니다. 이 기능에 유용한 애플리케이션은 RSVP LSP를 사용해 고객 에지(CE) 라우터와 공급자 에지(PE) 라우터와 연결한 다음 네트워크 코어를 가로질러 이동하는 두 번째 RSVP LSP 내부의 이 에지 LSP를 터널하는 것입니다.
MPLS 레이블 스위칭 개념에 대한 일반적인 이해를 해야 합니다. MPLS에 대한 자세한 내용은 Junos MPLS 애플리케이션 구성 가이드를 참조하십시오.
RSVP LSP 터널은 일반적인 MPLS 노드(GMPLS)에 사용되는 것과 유사한 포워딩 인접성의 개념을 추가합니다. (GMPLS에 대한 자세한 내용은 Junos GMPLS 사용자 가이드를 참조하세요.
포워딩 인접성은 RSVP LSP 네트워크의 피어 디바이스 간에 데이터를 전송하기 위한 터널링 경로를 생성합니다. 포워딩 인접성 LSP(FA-LSP)가 설정되면, 다른 LSP는 제한된 짧은 경로 우선(CSPF), 링크 관리 프로토콜(LMP), 개방형 최단 경로 우선(OSPF) 및 RSVP를 사용하여 FA-LSP를 통해 다른 LSP를 전송할 수 있습니다.
RSVP LSP 터널 기능을 지원하기 위해 Junos OS는 다음과 같은 메커니즘을 사용합니다.
LMP - 원래 GMPLS 용으로 설계된 LMP는 RSVP LSP 터널 피어 간 포워딩 인접성을 설정하고 트래픽 엔지니어링 링크를 위한 리소스를 유지하고 할당합니다.
최단 경로 우선(OSPF) 확장 - 물리적 인터페이스 카드(PIC)와 관련된 물리적 및 논리적 인터페이스로 패킷을 라우팅하도록 설계되었습니다. 이 프로토콜은 LMP 구성에 정의된 피어 인터페이스로 패킷을 라우팅하는 방향으로 확장되었습니다.
RSVP-TE 확장 - RSVP-TE는 패킷 LSP 설치를 물리적 인터페이스에 시그널링하도록 설계되었습니다. 프로토콜은 LMP 구성에 정의된 가상 피어 인터페이스로 이동하는 패킷 LSP에 대한 경로 설정을 요청하기 위해 확장되었습니다.
주:Junos OS 릴리스 15.1을 시작으로 MPLS RSVP-TE로 멀티인스턴스 지원이 확장됩니다. 이 지원은 가상 라우터 인스턴스 유형에서만 사용할 수 있습니다. 라우터 각각은 각 트래픽 엔지니어링(TE) 도메인을 독립적으로 확장할 수 있는 여러 독립적 TE 토폴로지 파티션에 라우터를 생성하고 참여할 수 있습니다. 멀티인스턴스 RSVP-TE는 인스턴스를 인식해야 하 컨트롤 플레인 개체를 직접 고를 수 있는 유연성을 제공합니다. 예를 들어, 라우터는 단일 BGP(Border Gateway Protocol) 인스턴스를 여전히 실행하는 동시에 다수의 트래픽 엔지니어링(TE) 인스턴스에 참여할 수 있습니다.
MPLS RSVP-TE의 Junos OS 구현은 Junos OS 릴리스 16.1에서 LSP의 사용성, 가시성, 구성 및 문제 해결을 향상시키기 위해 확장되었습니다.
이러한 개선은 RSVP-TE 구성을 다음과 같이 단계적으로 쉽게 만듭니다.
RSVP-TE LSP 셀프 핑 메커니즘을 통해 LSP를 트래픽 통과하기 전에 LSP 재 시그널링 과정에서 LSP 데이터 플레인 준비를 보장하는 것입니다.
LSP는 데이터 플레인 내에 프로그래밍된 것으로 알려져 있지 않는 한 트래픽 전송을 시작하지 말아야 합니다. LSP 핑 요청과 같은 LSP 데이터 플레인 데이터 교환은 LSP 또는 MBB 인스턴스에 트래픽을 스위칭하기 전에 수신 라우터에서 발생합니다. 대형 네트워크에서 LSP 핑 요청에 송신 LSP가 대응해야 하므로 이러한 트래픽은 LSP 송신 라우터 기능을 압도할 수 있습니다. LSP 셀프 핑 메커니즘은 수신 LER이 LSP 핑 응답 메시지를 생성하여 LSP 데이터 플레인 위로 전송할 수 있도록 해줍니다. 이러한 메시지를 수신하면, 송신 LER는 수신으로 전달하여 LSP 데이터 플레인 활력을 나타내게 됩니다. 이를 통해 데이터 플레인이 프로그래밍되기 전에 LSP가 트래픽 전송을 시작하지 않도록 합니다.
수신 라우터 상의 현재 하드 제한 64K LSP를 제거하고 RSVP-TE 신호 LSP와 LSP를 총 수를 확장합니다. 송신 당 기준 최대 64K LSP가 있을 수 있습니다. 앞서 이 제한은 수신 LER에서 구성할 수 있는 LSP의 총 집계 수 였습니다.
전송 라우터에서 LSP를 시그널링하는 지연으로 인해 수신 라우터가 LSP를 갑자기 삭제하는 것을 방지합니다.
LSP 특성 데이터 시각화 기능을 용이하게 하는 LSP 데이터 세트에 대한 유연한 보기를 활성화합니다.
주:Junos OS 릴리스 17.4를 시작으로 자체 핑을 위한 1800초 기본 타이머가 도입됩니다.
LSP 계층 구조에 다음과 같은 제한이 있습니다.
CCC(Circuit cross-connect) 기반 LSP는 지원되지 않습니다.
Graceful restart은 지원되지 않습니다.
링크 보호는 포워딩 인접성의 송신 포인트 또는 FA-LSP에서 볼 수 없습니다.
포인트 투 멀티포인트 LSP는 FA-LSP에서 지원되지 않습니다.
예: RSVP LSP 터널 구성
그림 5은(는) Router 0에서 시작하여 Router 5에서 종료되는 e2e_lsp_r0r5라는 엔드투엔드 RSVP LSP를 보여줍니다. 전송 시, 이 LSP는 FA-LSP fa_lsp_r1r4을(를) 트래버스합니다. 반환 경로는 FA-LSP fa_lsp_r4r1을(를) 통해 이동하는 엔드투엔드 RSVP LSP e2e_lsp_r5r0에 의해 표시됩니다.
Router 0에서 Router 5로 이동하는 엔드투엔드 RSVP LSP를 구성합니다. Router 1과 Router 1에서 Router 4로 이동하는 LMP 트래픽 엔지니어링 링크를 트래버스하는 엄격한 경로를 사용합니다.
Router 0
[edit]
interfaces {
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.222/32;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r0r5 { # An end-to-end LSP traveling to Router 5.
to 10.255.41.221;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.1.2.2 strict;
172.16.30.2 strict; # This traverses the TE link heading to Router 4.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-3/2/1.0 {
admin-group other;
}
interface so-0/0/3.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
Router 1에서 Router 4에 도달하려면 FA-LSP을 구성합니다. Router 4와 LMP 트래픽 엔지니어링 링크 및 LMP 피어 관계를 설정합니다. 트래픽 엔지니어링 링크에서 FA-LSP를 참조하고 OSF와 RSVP에 피어 인터페이스를 추가합니다.
반환 경로 엔드투엔드 LSP가 Router 1에 도달하면 라우팅 플랫폼은 라우팅 조회를 수행하고 트래픽을 Router 0으로 포워딩할 수 있습니다. Routers 0과 1 사이에서 OSPF를 올바르게 구성해야 합니다.
Router 1
[edit]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.1/30;
}
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.5/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r4; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r1r4 { # Configure your FA-LSP to Router 4 here.
to 10.255.41.217;
bandwidth 400k;
primary path_r1r4; # Apply the FA-LSP path here.
}
path path_r1r4 { # Configure the FA-LSP path here.
10.2.4.2;
10.4.5.2;
10.3.5.1;
}
interface so-0/0/3.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r4; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r1r4 { # Assign a name to the TE link here.
local-address 172.16.30.1; # Configure a local address for the TE link.
remote-address 172.16.30.2; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r1r4; # Reference the FA-LSP here.
}
peer r4 { # Configure LMP peers here.
address 10.255.41.217; # Configure the loopback address of your peer here.
te-link link_r1r4; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r1r4;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r1r4;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
Router 2에서 코어 네트워크를 통해 FA-LSP를 전송하는 모든 인터페이스에 OSPF, MPLS, RSVP를 구성합니다.
Router 2
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.4.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r1 {
10.2.4.1;
}
path path_r3r4 {
10.4.5.2;
10.3.5.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/1.0 {
admin-group other;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
Router 3에서 코어 네트워크를 통해 FA-LSP를 전송하는 모든 인터페이스에 OSPF, MPLS, RSVP를 구성합니다.
Router 3
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.2/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.5.6.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r4 {
10.3.5.1;
}
path path_r2r1 {
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/1.0 {
admin-group other;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
Router 4에서 Router 1에 도달하려면 반환 경로 FA-LSP를 구성합니다. Router 1과 LMP 트래픽 엔지니어링 링크 및 LMP 피어 관계를 설정합니다. 트래픽 엔지니어링 링크에서 FA-LSP를 참조하고 OSF와 RSVP에 피어 인터페이스를 추가합니다.
초기 엔드투엔드 LSP가 Router 4에 도달하면 라우팅 플랫폼은 라우팅 조회를 수행하고 트래픽을 Router 5로 포워딩할 수 있습니다. Routers 4와 5 사이에서 OSPF를 올바르게 구성해야 합니다.
Router 4
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.3.6.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.1/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.6/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r1; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r4r1 { # Configure your FA-LSP here.
to 10.255.41.216;
bandwidth 400k;
primary path_r4r1; # Apply the FA-LSP path here.
}
path path_r4r1 { # Configure the FA-LSP path here.
10.3.5.2;
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/0.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r1; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r4r1 { # Assign a name to the TE link here.
local-address 172.16.30.2; # Configure a local address for the TE link.
remote-address 172.16.30.1; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r4r1; # Reference the FA-LSP here.
}
peer r1 { # Configure LMP peers here.
address 10.255.41.216; # Configure the loopback address of your peer here.
te-link link_r4r1; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r4r1;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r4r1;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
Router 5에서 Router 0으로 이동하는 반환 경로 엔드투엔드 RSVP LSP를 구성합니다. Router 4와 Router 4에서 Router 1로 이동하는 LMP 트래픽 엔지니어링 링크를 트래버스하는 엄격한 경로를 사용합니다.
Router 5
[edit]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.3.6.2/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.221/32;
}
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r5r0 { # An end-to-end LSP returning to Router 0.
to 10.255.41.222;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.3.6.1 strict;
172.16.30.1 strict; # This traverses the TE link heading to Router 1.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
상태 확인
RSVP LSP 터널이 올바르게 작동하고 있는지 확인하려면 다음 명령을 실행합니다.
show ted database (extensive)show rsvp session name (extensive)show link-managementshow link-management te-link name (detail)
구성 예제에서 사용된 이러한 명령을 확인하려면 다음 섹션을 참조하십시오.
Router 0
Router 0에서 FA-LSP가 트래픽 엔지니어링 데이터베이스에서 유효한 경로로 표시되는지 확인할 수 있습니다. 이 경우, Router 1(10.255.41.216) 및 Router 4(10.255.41.217)에서 172.16.30.1와 172.16.30.2의 LMP 트래픽 엔지니어링 링크 주소를 참조하는 경로를 찾으십시오. 또한 FA-LSP를 통해 Router 5로 이동할 때 엔드투엔드 LSP 경로를 찾기 위해 show rsvp session extensive 명령을 실행할 수 있습니다.
user@router0> show ted database
TED database: 0 ISIS nodes 8 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.214 Rtr 486 4 4 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.4.2, Remote: 10.1.4.1
To: 10.255.41.216, Local: 10.2.4.2, Remote: 10.2.4.1
To: 10.255.41.215, Local: 10.4.5.1, Remote: 10.4.5.2
To: 10.3.4.1-1, Local: 10.3.4.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.215 Rtr 187 4 4 OSPF(0.0.0.0)
To: 10.255.41.214, Local: 10.4.5.2, Remote: 10.4.5.1
To: 10.255.41.217, Local: 10.3.5.2, Remote: 10.3.5.1
To: 10.255.41.221, Local: 10.5.6.1, Remote: 10.5.6.2
To: 10.2.5.1-1, Local: 10.2.5.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.216 Rtr 396 6 6 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.217 Rtr 404 6 6 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.221 Rtr 481 2 2 OSPF(0.0.0.0)
To: 10.255.41.215, Local: 10.5.6.2, Remote: 10.5.6.1
To: 10.255.41.217, Local: 10.3.6.2, Remote: 10.3.6.1
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.222 Rtr 2883 2 2 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.1.2.1, Remote: 10.1.2.2
To: 10.255.41.214, Local: 10.1.4.1, Remote: 10.1.4.2
user@router0> show ted database 10.255.41.216 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.216
Type: Rtr, Age: 421 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show ted database 10.255.41.217 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.217
Type: Rtr, Age: 473 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show rsvp session name e2e_lsp_r0r5 extensive
Ingress RSVP: 1 sessions
10.255.41.221
From: 10.255.41.222, LSPstate: Up, ActiveRoute: 2
LSPname: e2e_lsp_r0r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101584
Resv style: 1 FF, Label in: -, Label out: 101584
Time left: -, Since: Wed Sep 7 19:02:56 2005
Tspec: rate 30kbps size 30kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 29458 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.1.2.2 (so-0/0/3.0) 15 pkts
RESV rcvfrom: 10.1.2.2 (so-0/0/3.0) 16 pkts
Explct route: 10.1.2.2 172.16.30.2 10.3.6.2
Record route: <self> 10.1.2.2 172.16.30.2 10.3.6.2
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Router 1
Router 1에서 일련의 show link-management 명령을 실행하여 LMP 트래픽 엔지니어링 링크 구성이 작동하고 엔드투엔드 LSP가 트래픽 엔지니어링 링크를 트래버스하는지 확인합니다. 또한 show rsvp session extensive 명령을 실행하여 FA-LSP가 작동하는지 확인할 수 있습니다.
user@router1> show link-management
Peer name: r4 , System identifier: 10758
State: Up, Control address: 10.255.41.217
TE links:
link_r1r4
TE link name: link_r1r4, State: Up
Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2,
Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps,
Total bandwidth: 400kbps, Available bandwidth: 370kbps
Name State Local ID Remote ID Bandwidth Used LSP-name
fa_lsp_r1r4 Up 22642 0 400kbps Yes e2e_lsp_r0r5
user@router1> show link-management te-link name link_r1r4 detail
TE link name: link_r1r4, State: Up
Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2,
Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps,
Total bandwidth: 400kbps, Available bandwidth: 370kbps
Resource: fa_lsp_r1r4, Type: LSP, System identifier: 2147483683, State: Up, Local identifier: 22642,
Remote identifier: 0
Total bandwidth: 400kbps, Unallocated bandwidth: 370kbps
Traffic parameters: Encoding: Packet, Switching: Packet, Granularity: Unknown
Number of allocations: 1, In use: Yes
LSP name: e2e_lsp_r0r5, Allocated bandwidth: 30kbps
user@router1> show rsvp session name fa_lsp_r1r4 extensive
Ingress RSVP: 1 sessions
10.255.41.217
From: 10.255.41.216, LSPstate: Up, ActiveRoute: 0
LSPname: fa_lsp_r1r4, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100816
Resv style: 1 FF, Label in: -, Label out: 100816
Time left: -, Since: Wed Sep 7 19:02:33 2005
Tspec: rate 400kbps size 400kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 5933 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.2.4.2 (so-0/0/2.0) 28 pkts
RESV rcvfrom: 10.2.4.2 (so-0/0/2.0) 26 pkts
Explct route: 10.2.4.2 10.4.5.2 10.3.5.1
Record route: <self> 10.2.4.2 10.4.5.2 10.3.5.1
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 2 sessions
Total 0 displayed, Up 0, Down 0
링크 관리 프로토콜 피어 구성
트래픽 엔지니어링 링크를 설정한 후, [edit protocols link-management] 계층 수준에서 peer peer-name 문과 함께 LMP 네트워크 피어를 구성합니다. 피어는 라우팅 플랫폼이 통신하고 FA-LSP를 설정하는 네트워크 디바이스입니다. 피어 이름을 지정하고, 주소(종종 루프백 주소)로 피어 라우터 ID를 구성하고, 이 피어와 관련되도록 트래픽 엔지니어링 링크를 적용합니다. 피어링 관계의 양면을 구성하여 양방향 통신을 활성화합니다.
GMLS와는 달리, 피어에 대한 제어 채널을 구성해서는 안 됩니다. 제어 채널을 포함하면 커밋 작업이 실패합니다.
[edit]
protocols {
link-management {
peer peer-name { # Configure the name of your network peer.
address ip-address; # Include the router ID of the peer.
te-link te-link-name; # Assign a TE link to this peer.
}
}
}
링크 관리 프로토콜 트래픽 엔지니어링 링크 구성
RSVP LSP 터널 구성을 시작하려면, 수신 및 송신 라우팅 플랫폼 모두에서 LMP 트래픽 엔지니어링 링크를 구성합니다. 트래픽 엔지니어링 링크가 피어 디바이스 간 단방향 연결을 정의하므로, 패킷의 양방향 전송을 활성화하려면 피어 간 모든 방향에서 트래픽 엔지니어링 링크를 구성해야 합니다.
LMP에서 트래픽 엔지니어링 링크를 구성하려면, [edit protocols link-management] 계층 수준에서 te-link te-link-name 문을 포함합니다. 아래에 표시된 트래픽 엔지니어링 링크 옵션을 정의하고, 특히 피어에 연결하기 위해 FA-LSP로 사용될 레이블 전환 경로를 정의합니다. 선택 사항으로 트래픽 엔지니어링 링크(TE 링크)에 대한 트래픽 엔지니어링 메트릭을 지정할 수 있습니다. 기본적으로 트래픽 엔지니어링 메트릭은 CSPF 연산에서 파생됩니다.
[edit]
protocols {
link-management {
te-link te-link-name { # Name of the TE link.
label-switched-path lsp-name; # LSP used for the forwarding adjacency.
local-address ip-address; # Local IP address associated with the TE link.
remote-address ip-address; # Remote IP address mapped to the TE link.
te-metric value; # Traffic engineering metric used for the TE link.
}
}
}
OSPF 및 RSVP에서의 피어 인터페이스 구성
LMP 피어를 설정한 후, OSPF 및 RSVP에 피어 인터페이스를 추가해야 합니다. 피어 인터페이스는 두 피어 간 제어 인접성을 지원하는 데 사용되는 가상 인터페이스입니다.
피어 인터페이스 이름은 [edit protocols link-management] 계층 수준의 LMP에서 구성된 peer peer-name 문과 일치해야 합니다. 실제로 사용하는 프로토콜 패킷이 피어 인터페이스에 의해 전송 및 수신되기 때문에, 피어 인터페이스는 OSPF 및 RSVP를 위해 구성된 다른 물리적 인터페이스와 같은 피어에게 신호 및 보급될 수 있습니다. LMP 피어에 대한 OSPF 라우팅을 구성하려면 [edit protocols ospf area area-number] 계층 수준에서 peer-interface 문을 포함합니다. LMP 피어에 대한 RSVP 시그널링을 구성하려면, [edit protocols rsvp] 계층 수준에서 peer-interface 문을 포함합니다.
[edit]
protocols {
rsvp {
peer-interface peer-name { # Configure the name of your LMP peer.
}
ospf {
area area-number {
peer-interface peer-name { # Configure the name of your LMP peer.
}
}
}
}
}
FA-LSP에 대한 LSP(Label Switched Path) 정의
여러분의 FA-LSP를 [edit protocols mpls] 계층 레벨에서 label-switched-path문을 포함하여 정의하세요. 피어의 라우터 ID를 [edit protocols mpls label-switched-path] 계층 레벨의 to문에 포함시킵니다. 패킷 LSP는 단방향이기 때문에 피어에 연결하려면 하나의 FA-LSP를 생성하고 피어에서 반환하려면 두 번째 FA-LSP를 생성해야 합니다.
[edit]
protocols {
mpls {
label-switched-path lsp-name {
from ip-address;
to ip-address;
primary path-name;
secondary path-name;
no-cspf; # This statement to disable CSPF is optional.
}
}
}
FA-LSP 경로 정보 수립
FA-LSP에 대한 명시적인 LSP 경로를 구성할 때, 다음 홉 주소로 트래픽 엔지니어링 링크 원격 주소를 사용해야 합니다. CSPF가 지원되면, 원하는 경로 옵션을 사용할 수 있습니다. 그러나 CSPF가 [edit protocols mpls label-switched-path lsp-name] 계층 수준에서 no-cspf 문으로 비활성화되면, 엄격한 경로를 사용해야 합니다.
[edit]
protocols {
mpls {
path path-name {
next-hop-address (strict | loose);
}
}
}
end-to-end LSP가 FA-LSP와 같은 라우팅 플랫폼에서 시작되면, CSPF를 비활성화하고 엄격한 경로를 사용해야 합니다.
옵션: RSVP LSP의 graceful 삭제
LSP에서 사용하는 RSVP 세션의 graceful 중단 2단계 프로세스로 RSVP LSP를 삭제할 수 있습니다. graceful 삭제를 지원하는 모든 neighbor의 경우, 라우팅 플랫폼에서 경로에 있는 모든 RSVP neighbor 및 LSP의 대상 엔드포인트로 삭제 요청을 전송합니다. 이 요청은 RSVP 패킷의 ADMIN_STATUS 필드에 포함되어 있습니다. neighbor에서 요청을 수신하면 RSVP 세션을 중단할 준비를 합니다. 라우팅 플랫폼에서 RSVP 세션 삭제를 완료하기 위해 두 번째 메시지를 전송합니다. neighbor에서 graceful 삭제를 지원하지 않는 경우, 요청은 graceful이 아닌 표준 세션 삭제로 처리됩니다.
RSVP 세션의 graceful 삭제를 수행하려면 clear rsvp session gracefully 명령을 실행합니다. 선택적으로, RSVP 세션의 소스 및 대상 주소, RSVP 발신자의 LSP 식별자, RSVP 세션의 터널 식별자를 지정할 수 있습니다. 이러한 한정자를 사용하려면 clear rsvp session gracefully 명령을 실행할 때 connection-source, connection-destination, lsp-id 및 tunnel-id 옵션을 포합시킵니다.
또한 [edit protocols rsvp] 계층 수준에서 graceful-deletion-timeout 문을 포함시킴으로써 실제 삭제를 시작하기 전에 neighbor에서 graceful 삭제 요청을 수신할 때까지 라우팅 플랫폼이 대기하는 시간을 구성할 수 있습니다. graceful 삭제 시간 제한 기본값은 30초이며 최솟값은 1초이고 최댓값은 300초입니다. graceful 삭제 시간 제한의 현재 구성값을 보려면 show rsvp version 운영 모드 명령을 실행합니다.
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.