LSP 경로
MPLS 및 라우팅 테이블
IGP 및 BGP는 기본 IP 라우팅 테이블인 inet.0 라우팅 테이블에 라우팅 정보를 저장합니다. traffic-engineering bgp BGP만 트래픽 포워딩에 MPLS 경로를 사용할 수 있도록 명령이 구성된 경우, MPLS 경로 정보는 별도의 라우팅 테이블인 inet.3에 저장됩니다. BGP만 inet.3 라우팅 테이블에 액세스합니다. BGP는 inet.0과 inet.3을 모두 사용하여 다음 홉 주소를 확인합니다. traffic-engineering bgp-igp IGP가 트래픽 포워딩에 MPLS 경로를 사용할 수 있도록 명령이 구성된 경우, MPLS 경로 정보는 inet.0 라우팅 테이블에 저장됩니다. 그림 1( 그리고 그림 2 두 트래픽 엔지니어링 구성의 라우팅 테이블을 보여줍니다.)
inet.3 라우팅 테이블에는 각 LSP의 송신 라우터의 호스트 주소가 포함되어 있습니다. 이 라우팅 테이블은 수신 라우터에서 패킷을 대상 송신 라우터로 라우팅하는 데 사용됩니다. BGP는 수신 라우터의 inet.3 라우팅 테이블을 사용하여 다음 홉 주소를 해결합니다.
또한 MPLS는 각 LSP의 다음 레이블 스위치 라우터 목록을 포함하는 MPLS 경로 라우팅 테이블(mpls.0)을 유지 관리합니다. 이 라우팅 테이블은 LSP를 따라 다음 라우터로 패킷을 라우팅하기 위해 전송 라우터에서 사용됩니다.
일반적으로 LSP의 송신 라우터는 mpls.0 라우팅 테이블을 참조하지 않습니다. (LSP의 끝에서 두 번째 라우터가 패킷의 레이블을 0 값으로 변경하거나 레이블을 팝하기 때문에 이 라우터는 mpls.0을 참조할 필요가 없습니다.) 두 경우 모두 송신 라우터는 IP 라우팅 테이블 inet.0을 참조하여 패킷을 전달하는 방법을 결정하면서 IPv4 패킷으로 전달합니다.
전송 또는 송신 라우터가 MPLS 패킷을 수신하면 MPLS 포워딩 테이블의 정보를 사용하여 LSP의 다음 전송 라우터를 결정하거나 이 라우터가 송신 라우터인지 확인합니다.
BGP는 다음 홉 접두사를 확인할 때 inet.0 및 inet.3 라우팅 테이블을 모두 검사하여 가장 낮은 선호도의 다음 홉을 찾습니다. 두 라우팅 테이블에서 동일한 선호도를 가진 다음 홉 항목을 찾으면 BGP는 inet.3 라우팅 테이블의 항목을 선호합니다.
일반적으로 BGP는 inet.3 라우팅 테이블에서 다음 홉 항목을 선택하는데, 그 이유는 해당 항목의 기본 설정이 OSPF 및 IS-IS 다음 홉 기본 설정보다 항상 낮기 때문입니다. LSP를 구성할 때 MPLS LSP에 대한 기본 기본 설정을 재정의할 수 있으며, 이는 다음 홉 선택 프로세스를 변경할 수 있습니다.
BGP가 inet.3 라우팅 테이블에서 다음 홉 항목을 선택하면 해당 LSP를 패킷 전달 엔진의 포워딩 테이블에 설치하여 다음 홉으로 향하는 패킷이 LSP에 들어와 LSP를 따라 이동하게 합니다. LSP가 제거되거나 실패하면 inet.3 라우팅 테이블 및 포워딩 테이블에서 경로가 제거되고 BGP는 inet.0 라우팅 테이블에서 다음 홉을 사용하도록 되돌아갑니다.
Fast Reroute 개요
Fast reroute는 LSP 경로에 대한 중복성을 제공합니다. Fast Reroute를 활성화하면 LSP를 따라 우회가 미리 계산되고 미리 설정됩니다. 현재 LSP 경로에 네트워크 장애가 발생할 경우, 트래픽은 우회 경로 중 하나로 신속하게 라우팅됩니다. 그림 3 은 라우터 A에서 라우터 F로의 LSP를 보여주며, 설정된 우회 경로를 보여줍니다. 각 우회는 업스트림 노드에 의해 설정되어 바로 다운스트림 노드 및 바로 다운스트림 노드 자체에 대한 링크를 회피합니다. 각 우회로는 그림에 나와 있지 않은 하나 이상의 레이블 스위칭 라우터(또는 스위치)를 통과할 수 있습니다.
Fast Reroute는 수신 및 송신 라우터(또는 스위치) 간의 단일 장애 지점으로부터 트래픽을 보호합니다. 확장된 Fast Reroute 시나리오에서 장애가 발생할 경우, 디바이스는 장애가 발생한 링크를 통해 연결된 모든 피어에 대한 도달 가능성을 잃게 됩니다. 이로 인해 디바이스 간의 BGP 세션이 중단됨에 따라 트래픽이 중단됩니다. LSP를 따라 여러 번의 실패가 발생하면 Fast Reroute 자체가 실패할 수 있습니다. 또한 Fast Reroute는 수신 또는 송신 라우터의 장애로부터 보호하지 않습니다.
노드가 다운스트림 링크가 실패했거나(링크 레이어별 Liveness Detection 메커니즘 사용) 다운스트림 노드가 실패했거나(예: RSVP neighbor Hello 프로토콜 사용) 이를 감지하면, 노드는 트래픽을 우회로 신속하게 전환함과 동시에 링크 또는 노드 실패에 대해 수신 라우터에 신호를 보냅니다. 그림 4 은(는) 라우터 B와 라우터 C 간의 링크가 실패할 때 수행되는 우회를 보여줍니다.
네트워크 토폴로지가 충분히 풍부하지 않은 경우(다른 라우터에 대한 충분한 링크가 있는 라우터가 충분하지 않은 경우) 일부 우회가 성공하지 못할 수 있습니다. 예를 들어, 라우터 A에서 라우터 C 그림 3 로의 우회는 링크 A-B와 라우터 B를 트래버스할 수 없습니다. 이러한 경로가 가능하지 않으면 우회가 발생하지 않습니다.
노드가 트래픽을 우회로 전환한 후 곧 새로 계산된 우회로 트래픽을 다시 전환할 수 있습니다. 이는 초기 우회 경로가 최적 경로가 아닐 수 있기 때문입니다. 가능한 한 빨리 경로를 재라우팅하기 위해 노드는 우회가 유효한지 먼저 확인하지 않고 트래픽을 초기 우회로 전환합니다. 전환이 이루어지면 노드는 우회를 다시 계산합니다. 노드가 초기 우회가 여전히 유효하다고 판단하면 트래픽은 이 우회를 통해 계속 흐릅니다. 노드가 초기 우회가 더 이상 유효하지 않다고 판단하면 트래픽을 새로 계산된 우회로 다시 전환합니다.
노드가 트래픽을 초기 우회로 전환한 후 명령을 실행하면 show 노드는 트래픽이 여전히 원래 LSP를 통해 흐르고 있음을 나타낼 수 있습니다. 이 상황은 일시적이며 신속하게 수정되어야 합니다.
빠른 경로 재지정 우회가 적용되는 데 필요한 시간은 두 개의 독립적인 시간 간격에 따라 달라집니다.
링크 또는 노드 장애가 있음을 감지하는 시간 - 이 간격은 사용 중인 링크 레이어 및 장애의 특성에 따라 크게 달라집니다. 예를 들어, SONET/SDH 링크의 장애 탐지는 일반적으로 기가비트 이더넷 링크보다 훨씬 빠르며, 둘 다 라우터 장애 탐지보다 훨씬 빠릅니다.
트래픽을 우회로 연결하는 데 필요한 시간 - 이 작업은 패킷 전달 엔진에 의해 수행되며, 트래픽을 우회로 연결하는 데 시간이 거의 필요하지 않습니다. 필요한 시간은 우회로 전환되는 LSP의 수에 따라 달라질 수 있습니다.
Fast Reroute는 패킷 손실을 줄이기 위한 단기 패치입니다. 우회 계산이 적절한 대역폭을 예약하지 않을 수 있기 때문에 우회로 인해 대체 링크에 혼잡이 발생할 수 있습니다. 수신 라우터는 LSP 정책 제약을 완전히 인식하는 유일한 라우터이며, 따라서 적절한 장기 대체 경로를 제시할 수 있는 유일한 라우터입니다.
우회는 RSVP를 사용하여 생성되며 모든 RSVP 세션과 마찬가지로 네트워크에서 추가 상태 및 오버헤드가 필요합니다. 이러한 이유로 각 노드는 Fast Reroute가 활성화된 각 LSP에 대해 최대 한 번의 우회를 설정합니다. 각 LSP에 대해 두 개 이상의 우회 경로를 만들면 오버헤드가 증가하지만 실용적인 용도는 없습니다.
네트워크 오버헤드를 더 줄이기 위해 각 우회는 노드 또는 링크에 장애가 발생한 후 가능한 한 빨리 LSP로 다시 병합을 시도합니다. 라우터 노드를 통해 n 이동하는 LSP를 고려할 수 있는 경우 우회를 생성할 n – 1 수 있습니다. 예를 들어, 그림 5에서 우회는 라우터 E 또는 라우터 F가 아닌 라우터 D의 LSP로 다시 병합을 시도합니다. LSP로 다시 병합하면 우회 확장성 문제를 보다 쉽게 관리할 수 있습니다. 토폴로지 제한으로 인해 우회가 LSP로 빠르게 다시 병합되지 못하는 경우 우회는 다른 우회와 자동으로 병합됩니다.
Fast Reroute 구성
Fast reroute는 LSP의 노드 또는 링크에 장애가 발생할 경우 LSP에서 트래픽을 자동으로 재라우팅하는 메커니즘을 제공하여 LSP를 통해 이동하는 패킷의 손실을 줄입니다.
LSP에서 Fast Reroute를 구성하려면 수신 라우터(또는 스위치)에 명령문을 포함합니다 fast-reroute .
fast-reroute { (bandwidth bps | bandwidth-percent percentage); (exclude [ group-names ] | no-exclude ); hop-limit number; (include-all [ group-names ] | no-include-all); (include-any [ group-names ] | no-include-any); }
다음 계층 수준에서 이 명령문을 포함시킬 수 있습니다:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
LSP의 전송 및 송신 라우터(또는 스위치)에서 Fast Reroute를 구성할 필요가 없습니다. Fast Reroute가 활성화되면 수신 라우터(또는 스위치)는 LSP에서 Fast Reroute가 활성화되었음을 모든 다운스트림 라우터(또는 스위치)에 알리고 각 다운스트림 라우터는 LSP에 대한 우회 설정을 위해 최선을 다합니다. 다운스트림 라우터가 Fast Reroute를 지원하지 않는 경우, 우회 설정 요청을 무시하고 LSP를 계속 지원합니다. 빠른 재라우팅을 지원하지 않는 라우터는 일부 우회 경로를 실패하게 만들지만, 그 외에는 LSP에 영향을 미치지 않습니다.
PFE 고속 재라우팅을 활성화하려면 트래픽이 재라우팅될 수 있는 각 라우터의 계층 수준에서 명령문 [edit policy-options policy-statement policy-name then] 으로 라우팅 정책 명령 load-balance per-packet 문을 구성합니다. RSVP LSP에서 로드 밸런싱 구성도 참조하십시오.
기본적으로 다시 라우팅된 경로에는 대역폭이 예약되어 있지 않습니다. 다시 라우팅된 경로에 대역폭을 할당하려면 문 또는 bandwidth-percent 문을 포함합니다bandwidth. 이러한 문은 한 번에 하나만 포함할 수 있습니다. 명령문이나 bandwidth-percent 명령문을 포함하지 bandwidth 않는 경우, 기본 설정은 우회 경로에 대한 대역폭을 예약하지 않는 것입니다.
명령문을 포함할 bandwidth 때 우회 경로에 대해 예약할 특정 대역폭 양(초당 비트 수[bps])을 지정할 수 있습니다. 대역폭이 LSP에 할당된 대역폭과 동일할 필요는 없습니다.
명령문을 사용하여 대역폭 퍼센트를 bandwidth-percent 지정할 때, 우회 경로 대역폭은 대역폭 백분율에 메인 트래픽 엔지니어링 LSP를 위해 구성된 대역폭을 곱하여 계산됩니다. 트래픽 엔지니어링 LSP의 대역폭을 구성하는 방법에 대한 자세한 내용은 트래픽 엔지니어링 LSP 구성을 참조하십시오.
홉 제한 제약 조건은 LSP 자체와 비교하여 우회가 통과할 수 있는 라우터 수를 정의합니다. 기본적으로 홉 제한은 6으로 설정됩니다. 예를 들어, LSP가 4개의 라우터를 통과하는 경우 LSP의 우회는 수신 및 송신 라우터를 포함하여 최대 10개(즉, 4 + 6)개의 라우터 홉이 될 수 있습니다.
기본적으로 우회는 CSPF가 대체 경로를 결정할 때 부모 LSP와 동일한 관리(컬러링) 그룹 제약 조건을 상속합니다. 링크 색상 또는 리소스 클래스라고도 하는 관리 그룹은 링크의 '색상'을 설명하는 수동으로 할당 된 속성으로, 같은 색상의 링크는 개념적으로 동일한 클래스에 속합니다. 상위 LSP를 include-any 구성할 때 명령문을 지정하는 경우, 대체 세션이 통과하는 모든 링크는 그룹 목록에 하나 이상의 색상이 있어야 합니다. 상위 LSP를 include-all 구성할 때 명령문을 지정하는 경우, 대체 세션이 통과하는 모든 링크는 그룹 목록에 있는 모든 색상을 가져야 합니다. 상위 LSP를 exclude 구성할 때 명령문을 지정하는 경우, 링크 중 어느 것도 그룹 목록에서 색상을 찾을 수 없어야 합니다. 관리 그룹 제약 조건에 대한 자세한 내용은 LSP에 대한 관리 그룹 구성을 참조하십시오.
우회 병합 프로세스
이 섹션에서는 라우터가 동일한 세션 및 발신자 템플릿 개체를 가진 다른 인터페이스로부터 경로 메시지를 수신할 때 어떤 LSP를 선택할지 결정하기 위해 라우터가 사용하는 프로세스에 대해 설명합니다. 이 경우 라우터는 경로 상태를 병합해야 합니다.
라우터는 경로 상태를 병합할 시기와 방법을 결정하기 위해 다음 프로세스를 사용합니다.
모든 경로 메시지에 Fast Reroute 또는 우회 객체가 포함되어 있지 않거나 라우터가 LSP의 송신인 경우 병합이 필요하지 않습니다. 메시지는 RSVP 트래픽 엔지니어링에 따라 처리됩니다.
그렇지 않으면 라우터는 수신 인터페이스와 함께 경로 상태를 기록 해야 합니다 . 경로 메시지가 동일한 발신 인터페이스와 다음 홉 라우터를 공유하지 않는 경우, 라우터는 이를 독립적인 LSP로 간주하고 병합하지 않습니다.
동일한 발신 인터페이스와 다음 홉 라우터를 공유하는 모든 경로 메시지에 대해 라우터는 다음 프로세스를 사용하여 최종 LSP를 선택합니다.
이 노드에서 단 하나의 LSP가 발생하는 경우 최종 LSP로 선택합니다.
단 하나의 LSP에만 Fast Reroute 객체가 포함되어 있는 경우 이를 최종 LSP로 선택합니다.
여러 LSP가 있고 그 중 일부에 우회 객체가 있는 경우 최종 LSP 선택 프로세스에서 우회 객체를 포함하는 LSP를 제거하십시오.
여러 최종 LSP 후보가 남아 있는 경우(즉, 우회 및 보호된 LSP가 모두 있는 경우) Fast Reroute 객체가 있는 LSP를 선택합니다.
Fast Reroute 객체가 있는 LSP가 없는 LSP를 선택합니다. 모든 LSP에 우회 객체가 있는 경우 모두 선택합니다.
나머지 LSP 후보 중 다른 LSP가 피하는 노드를 통과하는 후보는 고려 대상에서 제외합니다.
여러 후보 LSP가 여전히 남아 있는 경우 ERO(Explicit Route Object) 경로 길이가 가장 짧은 LSP를 선택합니다. 둘 이상의 LSP의 경로 길이가 동일한 경우 무작위로 하나를 선택합니다.
최종 LSP가 식별되면 라우터는 이 LSP에 해당하는 경로 메시지만 전송해야 합니다. 다른 모든 LSP는 이 노드에서 병합된 것으로 간주됩니다.
우회 계산
우회 계산 및 설정은 각 노드에서 독립적으로 수행됩니다. 노드에서 LSP에 Fast Reroute가 활성화되어 있고 다운스트림 링크 또는 노드를 식별할 수 있는 경우 라우터는 로컬 트래픽 엔지니어링 데이터베이스의 정보를 사용하여 CSPF(Constrained Shortest Path First) 계산을 수행합니다. 이러한 이유로 우회는 트래픽 엔지니어링 확장을 지원하는 IGP에 의존합니다. 트래픽 엔지니어링 데이터베이스가 없으면 우회를 설정할 수 없습니다.
CSPF는 처음에 다음 다운스트림 노드를 건너뛰는 경로를 찾으려고 시도합니다. 이 경로를 찾으려고 하면 노드 또는 링크에서 다운스트림 장애를 방지할 수 있습니다. 노드 건너뛰기 경로를 사용할 수 없는 경우 CSPF는 다음 다운스트림 노드에 대한 대체 링크에서 경로를 찾으려고 시도합니다. 대체 링크를 찾으려는 시도는 링크의 다운스트림 장애에 대한 보호만 제공합니다. 우회 계산은 처음에는 성공하지 못할 수 있습니다. 계산이 실패하면 라우터는 계산이 성공할 때까지 새로 고침 간격마다 약 한 번씩 우회를 다시 계산합니다. 각 우회에 대한 RSVP 메트릭은 10,000에서 19,999 사이의 값으로 설정됩니다.
Fast Reroute 경로 최적화
빠른 경로 재지정 보호 경로는 비결정적입니다. 특정 노드의 실제 보호 경로는 Fast Reroute 경로가 계산된 LSP 및 네트워크 토폴로지의 기록에 따라 달라집니다. 결정론적 동작이 부족하면 네트워크에서 여러 링크 플랩이 발생한 후 운영상의 어려움과 제대로 최적화되지 않은 경로로 이어질 수 있습니다. 소규모 네트워크에서도 몇 번의 링크 플랩 후에 빠른 경로 재지정 경로는 임의로 많은 수의 노드를 통과할 수 있으며 해당 상태를 무기한으로 유지할 수 있습니다. 이는 비효율적이며 네트워크의 예측 가능성을 낮춥니다.
빠른 경로 재지정 최적화는 이러한 결함을 해결합니다. 글로벌 경로 최적화 타이머를 제공하므로, Fast Reroute가 활성화되고 우회 경로가 가동되어 실행되는 모든 LSP를 최적화할 수 있습니다. 타이머 값은 예상되는 RE 처리 부하에 따라 달라질 수 있습니다.
Fast Reroute 최적화 알고리즘은 IGP 메트릭만을 기반으로 합니다. 새 경로의 IGP 메트릭이 이전 경로보다 낮으면 새 경로가 더 혼잡하거나(더 높은 대역폭 사용률) 더 많은 홉을 통과하더라도 CSPF 결과가 허용됩니다.
RFC 4090, LSP 터널에 대한 RSVP-TE로의 Fast Reroute 확장에 따라, Fast Reroute 최적화를 위해 새 경로가 계산되고 수락되면 기존 우회가 먼저 소멸된 다음 새 우회가 설정됩니다. 트래픽 손실을 방지하기 위해 트래픽을 능동적으로 보호하는 우회는 최적화되지 않습니다.
Fast Reroute 경로에 대한 최적화 간격 구성
빠른 경로 재설정 최적화 타이머를 구성하여 빠른 경로 재설정을 위한 경로 최적화를 활성화할 수 있습니다. 최적화 타이머는 네트워크 리소스를 보다 효율적으로 사용하기 위해 빠른 경로 우회 LSP를 다시 계산하는 주기적인 최적화 프로세스를 트리거합니다.
Fast Reroute 경로 최적화를 활성화하려면 문에 optimize-timer 옵션을 사용하여 시간(초)을 지정합니다.fast-reroute
fast-reroute seconds;
다음 계층 수준에서 이 명령문을 포함시킬 수 있습니다:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
inet.3 또는 inet6.3 라우팅 테이블에 LSP 관련 경로 추가
기본적으로 송신 라우터로 향하는 호스트 경로는 inet.3 또는 inet6.3 라우팅 테이블에 설치됩니다. (호스트 경로 주소는 명령문에서 to 구성하는 주소입니다.) 호스트 경로를 설치하면 BGP가 다음 홉 확인을 수행할 수 있습니다. 또한 호스트 경로가 동적 라우팅 프로토콜에서 학습되어 inet.0 또는 inet6.0 라우팅 테이블에 저장된 접두사를 방해하지 않도록 합니다.
inet.0 또는 inet6.0 테이블의 경로와 달리 inet.3 또는 inet6.3 테이블의 경로는 패킷 전달 엔진에 복사되지 않으므로 시스템 전달 테이블에 직접 변경이 발생하지 않습니다. 이러한 경로에서는 ping 또는 traceroute 명령을 사용할 수 없습니다. inet.3 또는 inet6.3의 유일한 용도는 BGP가 다음 홉 확인을 수행하도록 허용하는 것입니다. inet.3 또는 inet6.3 테이블을 검사하려면 또는 show route table inet6.3 명령을 show route table inet.3 사용하십시오.
inet.3 또는 inet6.3 라우팅 테이블에 추가 경로를 삽입하려면 문을 포함합니다.install
install { destination-prefix <active>; }
다음 계층 수준에서 이 명령문을 포함시킬 수 있습니다:
[edit protocols mpls label-switched-path lsp-name][edit protocols mpls static-label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls static-label-switched-path lsp-name]
지정된 경로는 LSP가 설정될 때 라우팅 테이블에 별칭으로 설치됩니다. 추가 경로를 설치하면 BGP가 지정된 접두사 내에서 다음 홉을 해결하고 이러한 다음 홉에 대한 추가 트래픽을 특정 LSP로 보낼 수 있습니다.
명령문에 install 옵션을 포함하면 active 지정된 접두사가 기본 포워딩 테이블인 inet.0 또는 inet6.0 라우팅 테이블에 설치됩니다. 그 결과 LSP가 설정될 때마다 포워딩 테이블에 경로가 설치되므로 경로를 ping하거나 추적할 수 있습니다. 이 유형의 접두사는 정적 경로와 매우 유사하므로 이 옵션을 사용할 때는 주의해야 합니다.
BGP 다음 홉으로 사용되는 주소가 여러 개 있는 라우터 또는 MPLS를 지원하지 않는 라우터에 별칭 경로를 사용합니다. 두 경우 모두 LSP는 로컬 도메인 내의 다른 MPLS 지원 시스템으로 구성될 수 있으며, 이는 "경계" 라우터 역할을 합니다. 그런 다음 LSP는 경계 라우터에서 종료되고 해당 라우터에서 레이어 3 포워딩이 패킷을 진정한 다음 홉 라우터로 가져갑니다.
상호 연결의 경우 도메인의 경계 라우터가 프록시 라우터 역할을 할 수 있으며 경계 라우터가 BGP 다음 홉을 자신에게 설정하지 않는 경우 상호 연결에 대한 접두사를 보급할 수 있습니다.
MPLS를 지원하지 않는 라우터가 있는 POP(Point of Presence)의 경우 MPLS를 지원하는 하나의 라우터(예: 코어 라우터)가 전체 POP에 대한 프록시 역할을 할 수 있으며 POP를 포함하는 접두사 집합을 삽입할 수 있습니다. 따라서 POP 내의 모든 라우터는 자신을 내부 BGP(IBGP) 다음 홉으로 광고할 수 있으며 트래픽은 LSP를 따라 코어 라우터에 도달할 수 있습니다. 즉, POP에서는 일반 IGP 라우팅이 우선합니다.
inet.3 또는 inet6.3 라우팅 테이블의 경로에는 또는 traceroute 명령을 사용할 ping 수 없습니다.
BGP 다음 홉 확인의 경우, 경로가 inet.0/inet6.0 또는 inet.3/inet6.3에 있는지 여부는 차이가 없습니다. 가장 일치하는 경로(가장 긴 마스크)가 선택됩니다. 여러 개의 최적 일치 경로 중에서 가장 높은 우선 순위 값을 가진 경로가 선택됩니다.
문은 install destination-prefix active 정적 LSP에서 지원되지 않습니다. 정적 LSP에 install destination-prefix active 대해 명령문이 구성되면 MPLS 경로가 inet.0 라우팅 테이블에 설치되지 않습니다.