Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지에서
 

LDP 구성

최소 LDP 구성

최소 구성으로 LDP 활성화:

  1. family MPLS 아래의 모든 관련 인터페이스를 활성화합니다. 지정 LDP의 경우, 루프백 인터페이스가 family MPLS와 함께 활성화되어야 합니다.

  2. (선택) [edit protocol mpls] 계층 수준 아래의 관련 인터페이스를 구성합니다.

  3. 단일 인터페이스에 LDP를 활성화하고, ldp 문을 포함하며 interface 문을 사용하는 인터페이스를 지정합니다.

이것은 최소 LDP 구성입니다. 다른 모든 LDP 구성 문은 선택 사항입니다.

모든 인터페이스에서 LDP를 활성화하려면, interface-nameall을(를) 지정합니다.

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

LDP 활성화 및 비활성화

LDP는 routing-instance-aware입니다. 특정 인터페이스에서 LDP를 활성화하려면, 다음 문을 포함합니다.

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

모든 인터페이스에서 LDP를 활성화하려면, interface-nameall을(를) 지정합니다.

인터페이스 그룹에서 인터페이스 속성을 구성하고 인터페이스 중 하나에서 LDP를 비활성화하고 싶다면 disable 옵션을 포함한 interface 문을 포함합니다.

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

Hello 메시지에 대한 LDP 타이머 구성

LDP Hello 메시지는 LDP 노드가 서로를 발견하고 이웃의 장애나 이웃으로 연결되는 링크를 탐지할 수 있게 해줍니다. LDP가 활성화되어 있는 모든 인터페이스에서는 주기적으로 Hello 메시지가 전송됩니다.

LDP Hello 메시지에는 다음의 두 가지 유형이 있습니다.

  • 링크 Hello 메시지 - LDP 디스커버리 포트로 주소 지정된 UDP 패킷으로서 LDP 인터페이스를 통해 전송됩니다. 인터페이스에서 LDP 링크 Hello 메시지를 수신하면 LDP 피어 라우터와 인접성을 식별합니다.

  • 대상 지정 Hello 메시지 - 특정 주소의 LDP 디스커버리 포트로 주소 지정된 UDP 패킷으로서 전송됩니다. 대상 지정 Hello 메시지는 직접 연결되지 않은 라우터 간에 LDP 세션을 지원하는 데 사용됩니다. 대상 라우터는 대상 지정 Hello 메시지에 대응할지 또는 무시할지 결정합니다. 대응하기로 선택한 대상 라우터는 시작하는 라우터에 주기적으로 대상 지정 Hello 메시지를 다시 보내는 방식으로 대응합니다.

기본적으로 LDP는 링크 Hello 메시지의 경우 5초마다, 대상 지정 Hello 메시지의 경우 15초마다 Hello 메시지를 보냅니다. 두 가지 유형의 Hello 메시지 전송 주기는 LDP 타이머를 구성하여 변경하실 수 있습니다. 그러나 LDP 타이머의 시간을 LDP 보류 시간보다 큰 값으로 구성하실 수는 없습니다. 보다 자세한 내용은 LDP 이웃이 꺼짐으로 간주되기 전에 지연 구성에서 확인하실 수 있습니다.

링크 Hello 메시지에 대한 LDP 타이머 구성

LDP가 링크 Hello 메시지를 보내는 주기를 수정하려면 hello-interval 명령문을 사용하여 LDP 타이머에 대해 새로운 링크 Hello 메시지 간격을 지정하셔야 합니다.

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

대상 지정 Hello 메시지에 대해 LDP 타이머 구성

LDP가 대상 지정 Hello 메시지를 보내는 주기를 수정하려면 targeted-hello 명령문에 대해 hello-interval 명령문을 옵션으로 구성하여 LDP 타이머에 대해 새로운 대상 지정 Hello 메시지 간격을 지정하셔야 합니다.

이러한 명령문을 포함할 수 있는 계층 수준의 목록은 해당 명령문에 대한 요약 섹션에 나와 있습니다.

LDP 이웃이 다운된 것으로 간주되기 전에 지연 구성

보류 시간은 이웃이 다운되었음을 선언하기 전에 LDP 노드가 hello 메시지를 기다려야 하는 시간을 결정합니다. 이 값은 hello 메시지의 일부로 전송되므로 각 LCP 노드는 해당 이웃에 대기 시간을 알립니다. 각 이웃이 보낸 값은 일치할 필요가 없습니다.

보류 시간은 일반적으로 hello 간격의 최소 3배 이상이어야 합니다. 기본값은 링크 hello 메시지에 대해 15초, 대상 hello 메시지에 대해 45초입니다. 그러나 hello 간격의 값에 근접한 LDP 보류 시간을 구성할 수 있습니다.

주:

LDP 보류 시간을 hello 간격에 더 근접하게 구성함으로써(hello 간격의 3배 미만) LDP 이웃 오류는 더 빨리 감지될 수 있습니다. 그러나 이것은 라우터가 여전히 정상적으로 작동 중인 LDP 이웃을 다운된 것으로 선언할 가능성도 높입니다. 자세한 정보는 Hello 메시지에 대한 LDP Timer 구성을 참조하십시오.

또한 LDP 보류 시간은 LDP 피어 간에 자동으로 협상됩니다. 두 개의 LDP 피어가 다른 LDP 보류 시간을 서로 광고하면 더 작은 값이 사용됩니다. LDP 피어 라우터가 구성한 값보다 짧은 보류 시간을 광고하면, 피어 라우터의 광고된 보류 시간이 사용됩니다. 이 협상은 LDP keepalive 간격에도 영향을 미칠 수 있습니다.

LDP 피어 협상 시 로컬 LDP 보류 시간이 단축되지 않으면 사용자 구성된 keepalive 간격은 변경되지 않습니다. 그러나 피어 협상 중에 로컬 보류 시간이 축소되면 keepalive 간격이 다시 계산됩니다. 피어 협상 중에 LDP 보류 시간이 축소되면 keepalive 간격이 새 보류 시간 값의 1/3으로 축소됩니다. 예를 들어, 새로운 보류 시간 값이 45초라면, keepalive 간격은 15초로 설정됩니다.

이 자동화된 keepalive 간격 계산으로 각 피어 라우터에 다른 keepalive 간격이 구성될 수 있습니다. 이를 통해 LDP 피어 협상이 LDP 보류 시간보다 더 자주 전송되도록 하기 때문에 라우터가 keepalive 메시지를 보내는 빈도에 대해 유연할 수 있습니다.

hold-time 간격을 구성할 때 세션이 재설정될 때까지 변경 사항이 적용되지 않습니다. 보류 시간은 LDP 피어링 세션이 시작될 때 협상되며 세션이 가동하는 한 재협상할 수 없습니다(RFC 5036, LDP 사양에서 필요). LDP 세션을 수동으로 재설정하려면 clear ldp session 명령을 실행합니다.

링크 Hello 메시지에 대한 LDP 보류 시간 구성

LDP 노드가 이웃이 다운되었음을 선언하기 전에 링크 hello 메시지를 기다려야 하는 시간을 수정하려면 hold-time 문을 사용하여 새로운 시간을 초 단위로 지정합니다.

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

대상 Hello 메시지에 대한 LDP 보류 시간 구성

LDP 노드가 이웃이 다운되었음을 선언하기 전에 대상 hello 메시지를 기다려야 하는 시간을 수정하려면 hold-time 문을 targeted-hello 문에 대한 옵션으로 사용하여 새로운 시간을 초 단위로 지정합니다.

이러한 명령문을 포함할 수 있는 계층 수준의 목록은 해당 명령문에 대한 요약 섹션에 나와 있습니다.

LDP에 대한 정확한 대상 Hello 메시지 활성화

정확한 대상 Hello 메시지를 사용하면 LDP 세션이 구체적으로 구성되지 않은 원격 이웃과 함께 설정되지 않습니다. strict-targeted-hellos문을 구성하면, LDP 피어는 구성된 원격 이웃 중 하나가 아닌 소스에서 오는 대상 Hello 메시지에 응답하지 않습니다. 구성된 원격 이웃은 다음을 포함할 수 있습니다.

  • LDP 터널링이 구성되는 RSVP 터널의 엔드 포인트

  • 레이어 2 서킷 이웃

구성된 이웃이 Hello 메시지를 보내면, LDP 피어는 메시지를 무시하고 소스를 나타내는 오류( error추적 플래그와 함께)를 기록합니다. 예를 들어, LDP 피어가 인터넷 주소 10.0.0.1에서 대상 Hello를 수신하고 이 주소를 가진 이웃이 구체적으로 구성되지 않은 경우, 다음 메시지가 LDP 로그 파일에 인쇄됩니다.

정확한 대상 Hello 메시지를 사용하려면 strict-targeted-hellos문을 포함합니다.

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

LDP Keepalive 메시지 간격 구성

Keepalive 간격은 연결이 유지되는 시간의 초과가 발생하지 않도록 세션을 통하여 메시지가 얼마나 자주 전송되는지 결정합니다. 이 시간 내에 세션을 통하여 다른 LDP 트래픽의 전송이 없다면 Keepalive 메시지가 전송됩니다. 기본값은 10초입니다. 최소값은 1초입니다.

피어 라우터 내에서 LDP 유지 시간에 대하여 구성된 값이 로컬 설정된 값보다 낮으면 LDP 세션 협상 중에 Keepalive 간격에 대한 값을 변경할 수 있습니다. 보다 자세한 내용은 LDP 이웃이 꺼짐으로 간주되기 전에 지연 구성에서 확인하실 수 있습니다.

Keepalive 간격을 수정하려면 keepalive-interval 문을 포함합니다:

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

LDP Keeplive 시간 초과 구성

LDP 세션이 설정된 후, 세션이 계속 작동하는지 확인하기 위해서는 메시지가 주기적으로 교환되어야 합니다. Keeplive 시간 초과는 세션 실패를 결정하기 전에 이웃 LDP 노드가 대기하는 시간을 정의합니다. 이 값은 보통 적어도 Keepalive 간격의 세 배로 설정됩니다. 기본 값은 30초입니다.

Keepalive 간격을 수정하려면 keepalive-timeout 문을 포함합니다:

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

keepalive-timeout 문에 구성된 값은 show ldp session detail 명령을 발급할 때 보류 시간으로 표시됩니다.

LDP에 대한 가장 긴 일치 구성

LDP가 OSPF 영역 또는 ISIS 수준 전반에 걸쳐 도메인 간에 어그리게이션된 경로를 학습할 수 있으려면 Junos OS가 RFC5283에 따라 LDP에 대한 가장 긴 매치를 구성하도록 허용해야 합니다.

LDP에 대해 가장 긴 매치를 구성하기 전에 다음 작업을 해야 합니다.

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

  2. MPLS 프로토콜을 구성합니다.

  3. 최단 경로 우선(OSPF) 프로토콜을 구성합니다.

LDP에 대해 가장 긴 매치를 구성하려면, 다음 작업을 수행해야 합니다.

  1. LDP 프로토콜에 대해 가장 긴 일치를 구성합니다.
  2. 인터페이스에서 LDP 프로토콜을 구성합니다.

    예를 들어, 인터페이스를 구성합니다.

예: LDP에 대한 가장 긴 일치 구성

이 예에서는 RFC5283을 기준으로 LDP에 대해 가장 긴 일치를 구성하는 방법을 보여 줍니다. 이를 통해 LDP는 도메인 간 OSPF 영역 또는 ISIS 수준에서 집계 또는 요약된 경로를 학습할 수 있습니다. 가장 긴 일치 정책은 접두사별 세분성을 제공합니다.

요구 사항

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

  • 연결된 인터페이스에서 OSPF 프로토콜과 LDP가 활성화된 MX 시리즈 라우터 6개

  • 모든 디바이스에서 실행되는 Junos OS 릴리스 16.1 이상

시작하기 전에:

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

  • OSPF를 구성합니다.

개요

LDP는 OSPF 또는 IS-IS와 같은 IGP를 사용하여 완전한 네트워크 도메인 전체에 걸쳐 MPLS 레이블 교환 경로(LSP)를 설정하는 데 종종 사용됩니다. 이러한 네트워크에서, 도메인의 모든 링크는 LDP 인접성뿐만 아니라 IGP 인접성을 갖습니다. LDP는 IP 포워딩에 의해 결정되는 대상에 대한 최단 경로에 LSP를 설정합니다. Junos OS에서 LDP 구현체는 레이블 매핑을 위해 RIB 또는 IGP 경로에서 FEC의 IP 주소에 대해 정확한 일치 검색을 수행합니다. 이 정확한 매핑을 수행하려면 모든 LER에서 MPLS 종단 간 LDP 끝점 IP 주소를 구성해야 합니다. 이는 액세스 디바이스에서 IP 계층 설계 또는 기본 라우팅의 목적을 무효화합니다. longest-match을(를) 구성하면 정확한 일치 동작을 억제하고 접두사별로 가장 긴 일치 경로를 기반으로 LSP를 설정함으로써 이를 극복하는 데 도움이 됩니다.

토폴로지

토폴로지에서 그림 1은(는) LDP에 대한 가장 긴 일치가 디바이스 R0에서 구성되어 있음을 보여줍니다.

그림 1: LDP에 대한 가장 긴 일치 예제LDP에 대한 가장 긴 일치 예제

구성

CLI 빠른 구성

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

R0

R1

R2

R3

R4

R5

디바이스 R0 구성

단계별 절차

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

디바이스 R0 구성:

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

  2. 디바이스에 루프백 주소를 할당합니다.

  3. 라우터 ID를 구성합니다.

  4. 인터페이스에서 MPLS 프로토콜을 구성합니다.

  5. 인터페이스에서 MPLS 프로토콜을 구성합니다.

  6. LDP 프로토콜에 대해 가장 긴 일치를 구성합니다.

  7. 인터페이스에서 LDP 프로토콜을 구성합니다.

결과

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

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

검증

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

경로 확인

목적

예상되는 경로가 학습되는지 확인합니다.

작업

디바이스 R0에서 작동 모드에서 show route 명령을 실행하여 라우팅 테이블에 경로를 표시합니다.

의미

출력에는 디바이스 R0의 라우팅 테이블에 있는 모든 경로가 표시됩니다.

LDP 개요 정보 확인

목적

LDP 개요 정보를 표시합니다.

작업

디바이스 R0에서 작동 모드에서 show ldp overview 명령을 실행하여 LDP의 개요를 표시합니다.

의미

출력에 디바이스 R0의 LDP 개요 정보가 표시됩니다.

내부 토폴로지 테이블의 LDP 항목 확인

목적

LDP(Label Distribution Protocol) 내부 토폴로지 테이블에 경로 항목을 표시합니다.

작업

디바이스 R0에서 작동 모드에서 show ldp route 명령을 실행하여 LDP의 내부 토폴로지 테이블을 표시합니다.

의미

출력에는 디바이스 R0의 LDP(Label Distribution Protocol) 내부 토폴로지 테이블에 경로 항목이 표시됩니다.

LDP 경로의 FEC 정보만 확인

목적

LDP 경로의 FEC 정보만 표시합니다.

작업

디바이스 R0에서 작동 모드에서 show ldp route fec-only 명령을 실행하여 라우팅 테이블에 경로를 표시합니다.

의미

출력에는 디바이스 R0에 사용할 수 있는 LDP 프로토콜의 FEC 경로만 표시됩니다.

LDP의 FEC 및 섀도 경로 확인

목적

라우팅 테이블에 FEC 및 섀도 경로를 표시합니다.

작업

디바이스 R0에서 작동 모드에서 show ldp route fec-and-route 명령을 실행하여 라우팅 테이블에 FEC 및 섀도 경로를 표시합니다.

의미

출력에 디바이스 R0의 FEC 및 섀도 경로가 표시됩니다.

LDP 경로 선호도 구성

여러 프로토콜이 동일한 대상에 대한 경로를 계산하는 경우 포워딩 테이블에 어떤 경로가 설치되는지를 선택하는 데 경로 선호도가 사용됩니다. 가장 낮은 우선 순위 값을 가진 경로가 선택됩니다. 선호도 값은 범위 0~255의 숫자가 될 수 있습니다. 기본적으로 LDP 경로는 9의 우선 순위 값을 갖습니다.

경로 선호도를 수정하려면 preference 문을 포함합니다.

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

LDP Graceful Restart

LDP Graceful Restart는 LDP 컨트롤 플레인이 재시작 중인 라우터가 이웃 라우터에서 상태를 회복하는 동안 트래픽을 계속 전달하게 해줍니다. 또한 Helper 모드가 활성화된 라우터가 LDP의 재시작을 시도하는 이웃 라우터를 지원하도록 허용합니다.

세션 초기화 중 라우터는 LDP Graceful Restart 수행 능력을 광고하거나 Graceful Restart TLV를 전송하여 LDP Graceful Restart를 수행하는 이웃을 활용합니다. 이 TLV에는 LDP Graceful Restart와 관련된 두 가지 필드가 포함되어 있습니다: 재연결 시간 및 복구 시간. 재연결 및 복구 시간의 값은 라우터에서 지원하는 Graceful Restart 기능을 나타냅니다.

라우터가 이웃 라우터의 재시작을 발견하면, 재연결을 시도하기 전에 복구 시간이 종료될 때까지 기다립니다. 복구 시간은 라우터가 LDP의 Graceful Restart을 위해 대기하는 시간입니다. 복구 시간은 초기화 메시지가 전송되거나 수신되면 시작됩니다. 또한 이 시간은 일반적으로 이웃 라우터가 재시작하는 라우터에 대한 정보를 유지하여 트래픽 전송을 계속하게 해주는 시간입니다.

LDP 프로토콜과 특정 라우팅 인스턴스 모두의 마스터 인스턴스에서 LDP Graceful Restart를 구성할 수 있습니다. 모든 프로토콜의 전역 수준, LDP의 프로토콜 수준, 특정 라우팅 인스턴스에서 Graceful Restart를 비활성화할 수 있습니다. 전역 수준에서 Graceful Restart가 기본적으로 비활성화되므로, LDP Graceful Restart는 기본값으로 비활성화됩니다. 그러나 Helper 모드(Graceful Restart를 시도하는 이웃 라우터를 지원하는 능력)가 기본적으로 활성화됩니다.

다음은 LDP Graceful Restart와 관련된 일부 동작입니다:

  • 발신 레이블은 재시작이 유지되지 않습니다. 새로운 발신 레이블이 할당됩니다.

  • 라우터가 재시작되면, 재시작 라우터가 안정화될 때까지 Graceful Restart를 지원하는 이웃에게 레이블 맵 메시지가 전송되지 않습니다(Graceful Restart를 지원하지 않는 이웃에게는 레이블 맵 메시지가 즉시 전송됩니다). 그러나 다른 모든 메시지(Keepalive, 주소 메시지, 알림 및 릴리스)는 평소대로 전송됩니다. 이러한 다른 메시지를 배포하면 라우터가 불완전한 정보를 배포하는 것을 방지합니다.

  • Helper 모드와 Graceful Restart는 독립적입니다. 구성에서 Graceful Restart를 비활성화할 수 있지만, 라우터는 여전히 Graceful Restart를 시도하는 이웃과 협력할 수 있습니다.

LDP GR(Graceful Restart) 구성

[edit routing-options graceful-restart] 또는 [edit protocols ldp graceful-restart] 계층 수준에서 GR(Graceful Restart) 구성을 변경하면 실행 중인 모든 LDP 세션이 자동으로 다시 시작되어 GR(Graceful Restart) 구성을 적용할 수 있습니다. 이 동작은 GR(Graceful Restart) 구성을 변경할 때 BGP의 동작을 미러링합니다.

기본적으로 GR(Graceful Restart) Helper 모드는 활성화되어 있지만 GR(Graceful Restart)은 비활성화됩니다. 따라서 라우터의 기본 동작은 GR(Graceful Restart)을 시도하는 이웃 라우터를 지원하지만 자체적으로 GR(Graceful Restart)을 시도하지는 않습니다.

LDP GR(Graceful Restart)을 구성하려면 다음 섹션을 참조하십시오.

GR(Graceful Restart) 활성화

LDP GR(Graceful Restart)을 활성화하려면 라우터에서 GR(Graceful Restart)을 사용하도록 설정해야 합니다. GR(Graceful Restart)을 활성화하려면 graceful-restart 문을 포함합니다.

다음 계층 수준에서 이 문을 포함시킬 수 있습니다:

  • [edit routing-options]

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

주:

ACX 시리즈 라우터는 [edit logical-systems logical-system-name routing-options] 계층 수준을 지원하지 않습니다.

graceful-restart 문은 라우터에서 이 기능을 지원하는 모든 프로토콜에 대해 GR(Graceful Restart)을 활성화합니다. Graceful Restart에 대한 자세한 내용은 라우팅 장치를 위한 Junos OS 라우팅 프로토콜 라이브러리를 참조하십시오.

기본적으로, LDP 프로토콜 수준과 모든 라우팅 인스턴스에서 GR(Graceful Restart)을 활성화하면 LDP GR(Graceful Restart)이 활성화됩니다. 그러나 LDP GR(Graceful Restart) 및 LDP GR(Graceful Restart) Helper 모드를 모두 비활성화할 수 있습니다.

LDP GR(Graceful Restart) 또는 Helper 모드 비활성화

LDP GR(Graceful Restart) 및 복구를 비활성화하려면 disable 문을 포함합니다.

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

LDP 프로토콜 수준에서만 Helper 모드를 비활성화할 수 있습니다. 특정 라우팅 인스턴스에서 Helper 모드를 비활성화할 수 있습니다. LDP Helper 모드를 비활성화하려면 helper-disable 문을 포함합니다.

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

다음과 같은 LDP GR(Graceful Restart) 구성이 가능합니다.

  • LDP GR(Graceful Restart) 및 Helper 모드가 모두 활성화됩니다.

  • LDP GR(Graceful Restart)은 비활성화되지만, Helper 모드는 활성화됩니다. 이 방식으로 구성된 라우터는 GR(Graceful Restart)이 가능하지 않지만, 이웃의 재시작을 지원할 수 있습니다.

  • LDP GR(Graceful Restart) 및 Helper 모드가 모두 비활성화됩니다. 라우터는 초기화 메시지에서 전송된 LDP GR(Graceful Restart) 또는 GR(Graceful Restart) TLV(유형, 길이, 값)를 사용하지 않습니다. 라우터는 LDP GR(Graceful Restart)을 지원할 수 없는 라우터로 작동합니다.

GR(Graceful Restart)을 활성화하고 Helper 모드를 비활성화하려고 시도하면 구성 오류가 발생합니다.

재연결 시간 구성

이웃 간의 LDP 연결이 실패한 후, 이웃은 GR(Graceful Restart) 라우터가 LDP 메시지 전송을 재개할 때까지 일정 시간 동안 대기합니다. 그 이후 LDP 세션을 재설정할 수 있습니다. 대기 시간을 초 단위로 구성할 수 있습니다. 이 값은 LDP GR(Graceful Restart)이 활성화되어 있을 때 LDP 초기화 메시지에서 전송되는 내결함성 세션 TLV에 포함됩니다.

Router A와 Router B가 LDP 이웃이라고 가정해봅시다. Router A는 재시작 라우터입니다. 재연결 시간은 Router B가 Router A의 재시작을 감지한 후 Router A가 Router B에 대기하도록 지정한 시간입니다.

재연결 시간을 구성하려면 reconnect-time 문을 포함합니다.

재연결 시간을 30~300초 범주의 값으로 설정할 수 있습니다. 기본적으로 60초입니다.

이러한 문을 구성할 수 있는 계층 수준 목록은 해당 문에 대한 문 요약 섹션을 참조하십시오.

복구 시간 및 최대 복구 시간 구성

복구 시간은 라우터가 LDP의 GR(Graceful Restart)을 위해 대기하는 시간입니다. 복구 시간은 초기화 메시지가 전송되거나 수신되면 시작됩니다. 또한 이 기간은 일반적으로 이웃 라우터가 재시작하는 라우터에 대한 정보를 유지하여 트래픽 포워딩을 지속하게 해주는 시간입니다.

재시작 라우터에서 복구 시간에 대한 잘못된 값을 수신하는 경우 이웃 라우터가 부정적인 영향을 받지 않도록 하려면, 이웃 라우터에서 최대 복구 시간을 구성할 수 있습니다. 이웃 라우터는 두 번 중 짧은 시간에 대해 상태를 유지합니다. 예를 들어, Router A는 LDP GR(Graceful Restart)을 수행하고 있습니다. 900초의 복구 시간을 이웃 Router B에 보냈지만 Router B의 최대 복구 시간은 400초로 구성됩니다. Router B는 Router A에서 해당 LDP 정보를 제거하기 전에 400초 동안만 대기합니다.

복구 시간을 구성하려면 recovery-time 문과 maximum-neighbor-recovery-time 문을 포함합니다.

이러한 문을 구성할 수 있는 계층 수준 목록은 해당 문에 대한 문 요약 섹션을 참조하십시오.

인바운드 LDP 레이블 바인딩 필터링

수신된 LDP 레이블 바인딩을 필터링하며, 이웃 라우터에서 광고된 바인딩을 수락 또는 거부하는 정책을 적용할 수 있습니다. 수신 레이블 필터링을 구성하려면 import 문을 포함합니다:

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

명명된 정책([edit policy-options] 계층 수준에서 구성)은 모든 LDP 이웃에서 수신한 모든 레이블 바인딩에 적용됩니다. 모든 필터링은 from 문으로 수행됩니다. 표 1은(는) LDP 수신 레이블 필터링에 적용되는 from 연산자만 나열합니다.

표 1: LDP 수신 레이블 필터링에 적용되는 연산자로부터

from 연산자

설명

interface

지정된 인터페이스에 인접한 이웃에서 수신한 바인딩 일치

neighbor

지정된 LDP 라우터 ID로부터 수신한 바인딩 일치

next-hop

지정된 인터페이스 주소를 광고하는 이웃에서 수신한 바인딩 일치

route-filter

지정된 접두사의 바인딩 일치

바인딩이 필터링되면, LDP 데이터베이스에는 여전히 나타나지만, 레이블 스위치 경로(LSP)의 일환인 설치 대상으로는 간주되지 않습니다.

일반적으로 LDP에서 정책을 적용하는 것은 라우팅을 제어하기 위해서가 아니라 LSP의 설정을 차단하기 위한 목적입니다. 이것은 LSP가 따르는 경로가 LDP가 아닌 유니캐스트 라우팅에 의해 결정되기 때문입니다. 그러나 다른 이웃을 통해 대상으로 연결되는 여러 개의 동일 비용 경로가 있으면, LDP 필터링을 사용하여 가능한 다음 홉 중 일부를 고려 대상에서 제거할 수 있습니다. (아니면 LDP는 다음 홉 중 하나를 무작위로 선택합니다.)

LDP 세션은 인터페이스 또는 인터페이스 주소에 바인딩되지 않습니다. LDP는 라우터당(인터페이스당 아님) 레이블만 광고합니다. 따라서 두 라우터 간 여러 병렬 링크가 존재하면, 단 하나의 LDP 세션만 설정되며, 단일 인터페이스에 바인딩되지 않습니다. 라우터가 동일한 이웃에 여러 인접성을 갖는 경우, 필터가 예상대로 수행하는지 확인하십시오. (일반적으로 next-hopinterface의 사용은 이 경우에 적합하지 않습니다.)

레이블을 필터링한 경우(정책에 의해 거부되고, LSP 구축에 사용되지 않음을 의미), 데이터베이스에 필터링된 것으로 표시됩니다:

LDP에 대한 정책을 구성하는 방법에 대한 자세한 내용은 라우팅 정책, 방화벽 필터 및 트래픽 폴리서 사용자 가이드를 참조하십시오.

예: 인바운드 LDP 레이블 바인딩 필터링

모든 이웃에서 /32 접두사만 수락:

라우터 ID 10.10.255.2에서 131.108/16 이상만 수락하고 다른 모든 이웃에서 모든 접두사를 수락:

아웃바운드 LDP 레이블 바인딩 필터링

내보내기 정책을 구성하여 LDP 아웃바운드 레이블을 필터링할 수 있습니다. 라우팅 정책을 적용하여 바인딩이 이웃 라우터에 광고되지 못하도록 차단함으로써 아웃바운드 레이블 바인딩을 필터링할 수 있습니다. 아웃바운드 레이블 필터링을 구성하려면 export 명령문을 포함하십시오.

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

지명된 내보내기 정책([edit policy-options] 계층 수준에서 구성됨)이 모든 LDP 이웃에 전송되는 모든 레이블 바인딩에 적용됩니다. LDP 아웃바운드 레이블 필터링에 적용되는 유일한 from 연산자는 route-filter로서, 바인딩과 지정된 접두사를 연결시킵니다. 아웃바운드 레이블 필터링에 적용되는 유일한 to 연산자는 표 2에 나와 있는 연산자입니다.

표 2: LDP 아웃바운드 레이블 필터링을 위한 to 연산자

to 연산자

설명

interface

지정된 인터페이스를 통해 인접한 이웃으로 전송되는 바인딩의 일치 항목

neighbor

지정된 LDP 라우터 ID로 전송되는 바인딩의 일치 항목

next-hop

지정된 인터페이스 주소를 광고하는 이웃으로 전송되는 바인딩의 일치 항목

바인딩이 필터링되면 이 바인딩은 이웃 라우터에 광고되지 않지만 로컬 라우터에서 LSP의 일부로 설치될 수 있습니다. LDP에서 정책을 적용하여 LSP의 설정을 차단할 수 있지만 라우팅을 제어할 수는 없습니다. LSP가 따르는 경로는 LDP가 아니라 유니캐스트 라우팅에 의해 결정됩니다.

LDP 세션은 인터페이스 또는 인터페이스 주소에 바인딩되지 않습니다. LDP는 라우터당(인터페이스당이 아님) 레이블만 광고합니다. 두 라우터 간에 여러 병렬 링크가 존재하는 경우, 한 개의 LDP 세션만 설정되며 이는 단일 인터페이스에 바인딩되지 않습니다.

라우터에서 동일한 이웃에 여러 인접 항목이 있는 경우 next-hopinterface 연산자를 사용하면 안 됩니다.

필터링된 레이블은 데이터베이스에 표시됩니다.

LDP에 대한 정책을 구성하는 방법에 대한 자세한 내용은 라우팅 정책, 방화벽 필터 및 트래픽 폴리서 사용자 가이드를 참조하십시오.

예: 아웃바운드 LDP 레이블 바인딩 필터링

10.10.255.6/32에 대한 경로가 어떤 이웃으로도 전송되지 않도록 차단합니다.

131.108/16 이상만 라우터 ID 10.10.255.2로 전송하고 다른 모든 라우터에 모든 접두사를 전송합니다.

LDP가 사용하는 전송 주소 지정

라우터는 LDP 세션을 구성할 수 있기 전에 서로 간에 TCP 세션을 먼저 구성해야 합니다. TCP 세션은 라우터를 활성화하여 LDP 세션에 필요한 레이블 광고를 변경할 수 있습니다. TCP 세션을 구성하려면, 각 라우터가 다른 라우터의 전송 주소를 학습해야 합니다. 전송 주소는 LDP 세션이 실행되는 TCP 세션을 식별하는 데 사용되는 IP 주소입니다.

LDP 전송 주소를 구성하려면, transport-address 문을 포함합니다:

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

router-id 옵션을 지정하는 경우, 라우터 식별자의 주소는 전송 주소(다른 구성이 없는 한, 라우터 식별자는 일반적으로 루프백 주소와 동일)로 사용됩니다. interface 옵션을 지정하는 경우, 인터페이스 주소는 해당 인터페이스에 도달할 수 있는 이웃에게 모든 LDP 세션의 전송 주소로 사용됩니다. 라우터 식별자는 기본적으로 전송 주소로 사용됩니다.

주:

적절한 작업을 위해서는 LDP 전송 주소가 도달할 수 있어야 합니다. 라우터 ID는 라우팅 가능한 IP 주소가 아니라 식별자입니다. 이러한 이유로 라우터 ID는 루프백 주소와 일치하도록 설정하고 루프백 주소가 IGP로 보급되는 것이 좋습니다.

같은 LDP 이웃에게 여러 병렬 링크가 있을 때 interface 옵션을 지정할 수 없습니다. LDP 사양이 동일한 전송 주소가 같은 이웃으로의 모든 인터페이스에 보급되는 것을 요구하기 때문입니다. LDP가 동일한 이웃으로의 여러 병렬 링크를 감지하면, 인터페이스의 이웃 연결을 해제하거나 router-id 옵션을 지정하여 조건이 해결될 때까지 해당 이웃으로의 인터페이스를 하나씩 비활성화합니다.

대상 LDP 세션에 사용되는 전송 주소 제어

두 디바이스 간에 TCP 세션을 구축하려면, 각 디바이스가 다른 디바이스의 전송 주소를 학습해야 합니다. 전송 주소는 LDP 세션이 작동하는 TCP 세션을 식별하는 데 사용되는 IP 주소입니다. 앞서 이 전송 주소는 라우터 ID 또는 인터페이스 주소만 될 수 있었습니다. LDP 전송 주소 기능으로, 레이어 2 서킷, MPLS 및 VPLS 인접성에 대한 대상 LDP 이웃의 전송 주소로 어떤 IP 주소든 명시적으로 구성할 수 있습니다. 이를 통해 전송 주소 구성을 사용하는 대상 LDP 세션을 제어할 수 있습니다.

대상 LDP 세션에 사용되는 전송 주소 제어의 이점

대상 LDP 세션 구축을 위한 전송 주소를 구성하면 다음과 같은 이점이 있습니다:

  • Flexible interface configurations- 대상 LDP 이웃 간에 LDP 세션 생성을 방해하지 않으면서 하나의 루프백 인터페이스에 여러 IP 주소를 구성할 수 있는 유연성을 제공합니다.

  • Ease of operation- 인터페이스 수준에서 구성된 전송 주소로, LDP에 대한 IGP 백본에서 두 개 이상의 프로토콜을 사용할 수 있습니다. 이를 통해 원활하고 쉽게 작업할 수 있습니다.

대상 LDP 전송 주소 개요

Junos OS 릴리스 19.1R1 이전에는 LDP는 모든 LDP 인터페이스의 전송 주소로 라우터 ID나 인터페이스 주소만 지원했습니다. 이 인터페이스에서 형성된 인접성은 인터페이스 또는 라우터 ID에 할당된 IP 주소 중 하나를 사용했습니다. 대상 인접성의 경우, 인터페이스는 루프백 인터페이스입니다. 디바이스에서 여러 루프백 주소가 구성되면 전송 주소는 인터페이스를 위해 파생될 수 없으며, 그 결과 LDP 세션을 구축할 수 없습니다.

Junos OS 릴리스 19.1R1부터 대상 LDP 세션의 전송 주소에 사용되는 기본 IP 주소뿐만 아니라 session, session-groupinterface 구성 문 아래의 전송 주소로 다른 어떤 IP 주소도 구성할 수 있습니다. 전송 주소 구성은 레이어 2 서킷, MPLS 및 VPLS 인접성만 포함한 구성된 이웃에 적용됩니다. 이 구성은 발견된 인접성(대상 또는 비대상)에 적용되지 않습니다.

전송 주소 기본 설정

세션, 세션 그룹 및 인터페이스 수준에서 대상 LDP 세션의 전송 주소를 구성할 수 있습니다.

전송 주소가 구성되면, LDP의 전송 주소 기본 설정을 기반으로 대상 LDP 세션이 구축됩니다.

대상 이웃(레이어 2 서킷, MPLS, VPLS 및 LDP 구성)에 대한 전송 주소의 기본 설정 순서는 다음과 같습니다:

  1. [edit protocols ldp session] 계층 아래.

  2. [edit protocols ldp session-group] 계층 아래.

  3. [edit protocols ldp interfcae lo0] 계층 아래.

  4. [edit protocols ldp] 계층 아래.

  5. 기본 주소.

발견한 이웃에 대한 전송 주소의 기본 설정 순서는 다음과 같습니다:

  1. [edit protocols ldp interfcae] 계층 아래.

  2. [edit protocols ldp] 계층 아래.

  3. 기본 주소.

LDP가 Hello 패킷을 수락하도록 구성된 자동 대상 이웃에 대한 전송 주소의 기본 설정 순서는 다음과 같습니다:

  1. [edit protocols ldp interfcae lo0] 계층 아래.

  2. [edit protocols ldp] 계층 아래.

  3. 기본 주소.

전송 주소 구성의 문제 해결

다음 표시 명령 출력을 사용해 대상 LDP 세션을 해결할 수 있습니다:

  • show ldp session

  • show ldp neighbor

    show ldp neighbor 명령 출력의 detail 수준은 대상 이웃에 Hello 메시지를 보낸 전송 주소를 표시합니다. 이 주소가 이웃에서 도달할 수 없으면, LDP 세션은 발생하지 않습니다.

  • show configuration protocols ldp

또한 추가 문제 해결을 위해 LDP traceoption을 활성화할 수 있습니다.

  • 구성이 유효하지 않은(도달 불가) 전송 주소에서 유효한 전송 주소의 사용으로 변경되면, 다음 흔적을 확인할 수 있습니다:

  • 구성이 유효한 전송 주소에서 유효하지 않은(도달 불가) 전송 주소의 사용으로 변경되면, 다음 흔적을 확인할 수 있습니다:

구성이 잘못된 경우, 다음의 문제 해결 작업을 수행합니다:

  • address family을(를) 확인합니다. session 문 아래에 구성된 전송 주소는 이웃 또는 세션과 동일한 주소 패밀리에 속해야 합니다.

  • neighbor 또는 session 문 아래에서 전송 주소로 구성된 주소는 대상 Hello 메시지를 시작하기 위해 라우터에 로케일되어야 합니다. 주소가 구성되었는지 확인할 수 있습니다. 인터페이스 아래에서 주소가 구성되지 않으면, 구성이 거부됩니다.

라우팅 테이블에서 LDP로 표시된 접두사 구성

LDP로 표시된 접두사 세트를 제어하고 라우터가 해당 접두사의 송신 라우터 역할을 하게 할 수 있습니다. 기본적으로 루프백 주소만 LDP로 표시됩니다. LDP로 표시될 라우팅 테이블 접두사 세트를 구성하기 위해 egress-policy문을 포함합니다.

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

주:

루프백 주소를 포함하지 않는 LDP의 송신 정책을 구성하는 경우 LDP에서 더 이상 표시되지 않습니다. 루프백 주소를 계속 표시하려면 LDP 송신 정책 일부로 루프백 주소를 명시적으로 구성해야 합니다.

명명된 정책( [edit policy-options]또는 [edit logical-systems logical-system-name policy-options]계층 수준에서 구성된)은 라우팅 테이블의 모든 경로에 적용됩니다. 정책과 일치하는 경로는 LDP로 표시됩니다. export문을 사용하여 접두사가 표시된 이웃 세트를 제어할 수 있습니다. from운영자만 고려됩니다. 유효한 from운영자를 사용할 수 있습니다. 자세한 내용은 라우팅 장치를 위한 Junos OS 라우팅 프로토콜 라이브러리 를 참조하십시오.

주:

ACX 시리즈 라우터는 [edit logical-systems] 계층 수준을 지원하지 않습니다.

예: LDP로 표시된 접두사 구성

LDP로 연결된 모든 경로를 표시합니다.

FEC 분해 구성

LDP 송신 라우터가 여러 개의 접두사를 표시하는 경우, 접두사는 단일 레이블과 결합되며 단일한 FEC(포워딩 동등성 클래스)로 어그리게이션됩니다. 기본적으로 LDP는 표시가 네트워크를 횡단할 때 어그리게이션을 유지합니다.

일반적으로 LSP는 여러 개의 다음 홉을 가로질러 분할 되지 않기 때문에 접두사는 단일 LSP로 결합되므로 동일한 비용 경로에서는 부하 밸런싱이 발생하지 않습니다. 그러나 부하 밸런싱 정책을 구성하고 FEC를 분해하는 경우 동일한 비용 경로에서 부하 밸런싱을 수행할 수 있습니다.

FEC를 분해하면 각 접두사가 별도의 레이블로 결합되고 별도의 LSP가 됩니다.

세분화된 FEC를 구성하기 위해 deaggregate문을 포함합니다.

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

모든 LDP 세션의 경우, 전역에 걸쳐 분해된 FEC만 구성할 수 있습니다.

FEC를 분해하면 결과되는 여러 LSP가 여러 동일 비용 경로에 걸쳐 분산되고 송신 세그먼트의 여러 다음 홉에 걸쳐 분산되지만 LSP당 하나의 다음 홉만 설치할 수 있습니다.

FEC를 어그리게이션하려면 no-deaggregate문을 포함합니다.

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

모든 LDP 세션의 경우, 전역에 걸쳐 어그리게이션된 FEC만 구성할 수 있습니다.

LDP FEC의 폴리서 구성

LDP FEC의 트래픽을 추적하고 감시하도록 Junos OS를 구성할 수 있습니다. LDP FEC 폴리서를 사용하여 다음 작업을 수행할 수 있습니다.

  • LDP FEC의 수신 트래픽 추적 또는 감시.

  • LDP FEC의 전송 트래픽 추적 또는 감시.

  • 특정 포워딩 클래스에서 발생하는 LDP FEC 트래픽 추적 또는 감시.

  • 특정 가상 라우팅 및 포워딩(VRF) 사이트에서 발생하는 LDP FEC 트래픽 추적 또는 감시.

  • 특정 LDP FEC에 대해 바인딩된 잘못된 트래픽 삭제

LDP FEC의 트래픽을 구성하려면 먼저 필터를 구성해야 합니다. 구체적으로 [edit firewall family protocol-family filter filter-name term term-name from] 계층 수준에서 interface 문 또는 interface-set 문을 구성해야 합니다. interface 문을 사용하여 필터를 단일 인터페이스에 일치시킬 수 있습니다. interface-set문을 사용하여 필터를 다중 인터페이스에 일치시킬 수 있습니다.

LDP FEC의 interface 문, interface-set 문 및 폴리서 구성 방법에 대한 자세한 내용은 라우팅 정책, 방화벽 필터 및 트래픽 폴리서 사용 설명서를 참조하십시오.

필터를 구성한 후에는 LDP의 policing 문 구성에 필터를 포함시켜야 합니다. LDP FEC의 폴리서를 구성하려면 다음과 같이 policing 문을 포합시킵니다.

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

policing 문에는 다음과 같은 옵션이 포함됩니다.

  • fec - 감시할 LDP FEC의 FEC 주소를 지정합니다.

  • ingress-filter - 수신 트래픽 필터의 이름을 지정합니다.

  • transit-traffic - 전송 트래픽 필터의 이름을 지정합니다.

LDP IPv4 FEC 필터링 구성

기본적으로 대상 LDP 세션이 설정된 경우, Junos OS는 대상 LDP 세션에 대해 IPv4 FEC(Forwarding Equivalence Class) 및 계층 2 서킷 FEC를 항상 교환합니다. 간접적으로 연결된 이웃에 대한 LDP 세션의 경우, 세션이 계층 2 서킷 또는 VPLS를 지원하도록 특별히 구성된 경우에만 이웃에 계층 2 서킷 FEC를 내보내고 싶을 수 있습니다.

모든 비 BGP 접두사가 LDP에 보급되는 혼합 벤더 네트워크에서는 LDP 데이터베이스가 커질 수 있습니다. 이러한 유형의 환경에서는 계층 2 서킷 또는 LDP VPLS 구성 때문에 형성된 LDP 세션에 대한 IPv4 FEC의 보급을 방지하는 것이 유용할 수 있습니다. 마찬가지로, 이러한 종류의 환경에서 수신된 IPv4 FEC를 필터링하는 것이 유용할 수 있습니다.

LDP 세션과 관련된 모든 LDP 이웃이 계층 2만 있는 경우, l2-smart-policy 문을 구성하여 Junos OS가 계층 2 서킷 FEC만 보급하도록 구성할 수 있습니다. 이 기능은 또한 이 세션에서 수신된 IPv4 FEC를 자동으로 필터링합니다. l2-smart-policy에 대해 활성화된 명시적인 내보내기 또는 가져오기 정책 구성은 해당 방향에서 이 기능을 비활성화합니다.

LDP 세션의 이웃 중 하나가 발견된 인접성으로 인해 형성된 경우 또는 하나 이상의 RSVP LSP에 대한 LDP 터널링 구성 때문에 인접성이 형성된 경우 IPv4 FEC는 기본 행동을 사용하여 보급 및 수신됩니다.

LDP가 계층 2 이웃만 가진 LDP 세션에 대해 IPv4 FEC를 내보내지 못하도록 하고 이러한 세션에서 수신된 IPv4 FEC를 필터링하기 위해 l2-smart-policy 문을 포함합니다.

이 문을 구성할 수 있는 계층 수준 목록은 문 요약을 참조하십시오.

LDP LSP의 BFD 구성하기

LDP LSP의 양방향 포워딩 검출(BFD)을 구성할 수 있습니다. BFD 프로토콜은 네트워크의 실패를 감지하는 간단한 Hello 메커니즘입니다. Hello 패킷은 정규적이며 지정된 간격으로 전송됩니다. 지정된 간격 후 라우터가 답변 수신을 중단하면 이웃 실패가 감지됩니다. BFD는 다양한 네트워크 환경과 토폴로지에서 작동합니다. BFD의 실패 검출 타이머는 정적 경로의 실패 검출 메커니즘보다 짧은 시간 제한을 가지고 있어 빠른 탐지를 제공합니다.

경로에 대한 BFD 세션이 실패할 때마다 오류가 기록됩니다. 다음은 LDP LSP 로그 메시지에 대한 BFD가 어떻게 나타나는지 보여줍니다.

RSVP LSP의 BFD도 구성할 수 있으며, RSVP 신호된 LSP의 BFD 구성하기에 설명되어 있습니다.

BFD 실패 검출 타이머는 적응 가능하며 더 많거나 적은 공격용으로 조정할 수 있습니다. 예를 들어, 타이머는 인접성이 실패하면 더 높은 값에 적응하거나 또는 이웃이 구성된 값보다 타이머의 높은 값을 협상할 수 있습니다. BFD 세션 플랩이 15초 동안 3배 이상 발생하면 타이머는 더 높은 값에 적응합니다. 로컬 BFD 인스턴스가 세션 플랩의 이유인 경우 물러서기 알고리즘은 수신 (Rx) 간격을 2배로 증가시킵니다. 원격 BFD 인스턴스가 세션 플랩의 이유인 경우 전송 (Tx) 간격은 2배 증가합니다. clear bfd adaptation 명령을 사용하여 BFD 간격 타이머를 구성된 값으로 돌려줄 수 있습니다. clear bfd adaptation 명령은 중단이 없으며, 이는 명령이 라우팅 디바이스의 트래픽 플로우에 영향을 미치지 않는다는 것을 의미합니다.

LDP LSP의 BFD를 활성화하려면 oambfd-liveness-detection 명령문을 포함합니다.

[edit protocols ldp] 계층 수준에서 fec 옵션을 사용하여 FEC 주소를 구성하여 특정 포워딩 동등 클래스(FEC)와 관련된 LDP LSP의 BFD를 활성화할 수 있습니다. 또는 OAM(Operation Administration and Management)의 수신 정책을 구성해 다양한 FEC 주소에서 BFD를 활성화시킬 수 있습니다. 자세한 내용은 LDP의 OAM 수신 정책 구성하기를 참조하세요.

OAM 수신 정책을 사용하는 FEC에서 동일한 FEC 주소가 명시적으로 구성되거나 OAM이 활성화되지 않는다면 BFD LDP LSP를 활성화시킬 수 없습니다. FEC 주소에 대해 BFD가 활성화되지 않은 경우 BFD 세션은 나타나지 않습니다.

oam 명령문은 다음의 계층 수준에서 구성할 수 있습니다.

  • [edit protocols ldp]

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

주:

ACX 시리즈 라우터는 [edit logical-systems] 계층 수준을 지원하지 않습니다.

oam 문에는 다음과 같은 옵션이 포함됩니다.

  • fec - FEC 주소를 지정합니다. BFD 세션이 올라오는지 확인하기 위해 FEC 주소를 지정하거나 또는 OAM 수신 정책을 구성해 주어야 합니다.

  • lsp-ping-interval - 초 단위 LSP 핑 간격 기간을 지정합니다. LDP 신호된 LSP에서 핑을 하기 위해 ping mpls ldp 명령을 사용하세요. 자세한 내용은 CLI 탐색기를 참조하세요.

bfd-liveness-detection 문에는 다음과 같은 옵션이 포함됩니다.

  • ecmp - LDP는 지정된 FEC에 대해 구성된 모든 ECMP 경로에 대해 BFD 세션을 구축해 줄 수 있습니다. ecmp 옵션을 구성한다면 지정된 FEC에 대한 periodic-traceroute 명령문도 반드시 구성해야 합니다. 구성하지 않으면 커밋 작업이 실패합니다. 특정 FEC([edit protocols ldp oam fec address bfd-liveness-detection])에 대한 ecmp 옵션만을 구성하면서도 글로벌 계층 수준([edit protocols ldp oam])에서 periodic-traceroute 명령문을 구성할 수 있습니다.

  • holddown-interval - 경로 또는 다음 홉을 추가하기 전에 BFD 세션이 유지되어야 하는 기간을 지정합니다. 시간을 0초로 지정하면 BFD 세션이 다시 돌아오자마자 경로 또는 다음 홉이 추가됩니다.

  • minimum-interval - 최소 전송 및 수신 간격을 지정합니다. minimum-interval 옵션을 구성한다면 minimum-receive-interval 옵션 또는 minimum-transmit-interval 옵션을 구성할 필요가 없습니다.

  • minimum-receive-interval - 최소 수신 간격을 지정합니다. 범위는 1~255,000 밀리초입니다.

  • minimum-transmit-interval - 최소 전송 간격을 지정합니다. 범위는 1~255,000 밀리초입니다.

  • multiplier - 검출 시간 승수를 지정합니다. 범위는 1~255입니다.

  • version - BFD 버전을 지정합니다. 옵션은 BFD 버전 0 또는 BFD 버전 1입니다. 기본값으로 Junos OS 소프트웨어는 BFD 버전을 자동으로 결정합니다.

LDP LSP에 대한 ECMP 인식 BFD 구성

FEC를 위해 BFD를 구성할 때, 라우터에 대해 오직 한 개의 활성 로컬 넥스트 홉만 BFD 세션이 설정됩니다. 그러나 특정 ECMP(Equal-cost multipath) 경로와 관련된 각 FEC에 대해 하나씩 여러 BFD 세션을 구성할 수 있습니다. 이를 위해서는 LDP LSP 정기 traceroute도 구성해야 합니다. (LDP LSP Traceroute 구성을 참조하십시오.) LDP LSP traceroute는 ECMP 경로를 발견하는 데 사용됩니다. 발견된 각 ECMP 경로에 대해 BFD 세션이 시작됩니다. ECMP 경로 중 하나에 대한 BFD 세션이 실패할 때마다 오류가 로그됩니다.

LDP LSP traceroute는 ECMP 경로의 무결성을 확인하기 위해 주기적으로 실행됩니다. 문제가 발견되면 다음이 발생할 수 있습니다.

  • FEC에 대한 최신 LDP LSP traceroute가 이전 traceroute와 다른 경우, 해당 FEC와 연결된 BFD 세션(이전 실행에서 변경된 주소 범위에 대한 BFD 세션)이 중지되고 새로운 BFD 세션이 변경된 범위의 대상 주소에 대해 시작됩니다.

  • LDP LSP traceroute가 오류(예: 시간 초과)를 반환하면 해당 FEC와 관련된 모든 BFD 세션이 모두 종료됩니다.

특정 FEC를 위해 구성된 모든 ECMP 경로에 대해 BFD 세션을 설정하도록 LDP를 구성하려면 ecmp 문을 포함합니다.

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

ecmp 문과 함께 글로벌 LDP OAM 구성([edit protocols ldp oam] 또는 [edit logical-systems logical-system-name protocols ldp oam] 계층 수준에서) 또는 지정된 FEC에 대한 구성([edit protocols ldp oam fec address] 또는 [edit logical-systems logical-system-name protocols ldp oam fec address] 계층 수준에서) 중 하나에서 periodic-traceroute 문도 포함해야 합니다. 그렇지 않으면, 커밋 작업은 실패합니다.

주:

ACX 시리즈 라우터는 [edit logical-systems] 계층 수준을 지원하지 않습니다.

LDP LSP에서 BFD 세션에 대한 실패 동작 구성

LDP LSP에서 BFD 세션 실패 이벤트가 발생한 경우 경로 및 다음 홉 속성을 구성할 수 있습니다. 실패 이벤트는 중단된 기존 BFD 세션,또는 발생하지 않은 BFD 세션일 수 있습니다. LDP는 관련 BFD 세션이 다시 돌아올 때 경로 또는 다음 홉을 추가합니다.

LDP LSP에서 BFD 세션 실패 이벤트가 발생한 경우 failure-action문에 대해 다음 실패 동작 옵션 중 하나를 구성할 수 있습니다.

  • remove-nexthop- BFD 세션 실패 이벤트가 감지되면 수신 노드에서 LSP의 경로 다음 홉에 해당하는 경로를 제거합니다.

  • remove-route- BFD 세션 실패 이벤트가 감지되면 적절한 라우팅 테이블에서 LSP에 해당하는 경로를 제거합니다. LSP가 ECMP로 구성되어 있고 모든 경로에 해당하는 BFD 세션이 내려가는 경우 경로가 제거됩니다.

LDP LSP에서 BFD 세션 실패 이벤트의 경우 실패 동작을 구성하려면 failure-action문에 remove-nexthop옵션이나 remove-route옵션을 포함합니다.

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

BFD 세션의 홀드다운 간격 구성

[edit protocols ldp oam bfd-livenesss-detection] 계층 수준 또는 [edit protocols ldp oam fec address bfd-livenesss-detection] 계층 수준에서 holddown-interval 문을 구성하여 경로나 다음 홉을 추가하기 전에 BFD 세션의 기간을 최대로 지정할 수 있습니다. 시간을 0초로 지정하면 BFD 세션이 다시 돌아오자마자 경로 또는 다음 홉이 추가됩니다.

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

MoFRR(Multicast-Only Fast Reroute) 이해하기

MoFRR(Multicast-only fast reroute)은 링크 장애 발생 시 멀티캐스트 배포 트리의 트래픽 패킷 손실을 최소화하여 이러한 기능을 지원하는 디바이스의 PIM(Protocol Independent Multicast) 및 멀티포인트 LDP(Label Distribution Protocol) 등 멀티캐스트 라우팅 프로토콜을 향상합니다.

주:

스위치에서 MPLS 레이블 스위치 경로와 멀티포인트 LDP를 포함하는 MoFRR은 지원되지 않습니다.

MX 시리즈 라우터의 경우 MoFRR는 MPC 라인 카드가 탑재된 MX 시리즈 라우터에서만 지원됩니다. 전제 조건으로, 라우터는 network-services enhanced-ip(으)로 구성하고 라우터의 모든 라인 카드는 MPC여야 합니다.

MoFRR이 활성화되어 있으면 디바이스는 멀티캐스트 소스로의 기본 및 백업 업스트림 경로에 참가 메시지를 보냅니다. 디바이스는 기본 및 백업 경로 모두에서 데이터 패킷을 수신하고 우선순위(기본 및 백업 경로에 할당된 가중치)에 따라 중복 패킷을 폐기합니다. 디바이스가 기본 경로에서 장애를 감지하면, 즉시 이차 인터페이스(백업 경로)에서 패킷을 수신하기 시작합니다. 빠른 스위치 전환은 기본 경로 링크 장애 시 컨버전스 시간을 크게 향상합니다.

MoFRR용 단일 애플리케이션은 스트리밍 IPTV입니다. IPTV 스트리밍은 UDP 스트리밍 멀티캐스트이므로 손실 패킷은 재전송되지 않으며, 만족스럽지 않은 사용자 경험을 선사할 수 있습니다. MoFRR은 상황을 개선할 수 있습니다.

MoFRR 개요

유니캐스트 스트리밍에서 FR(fast reroute)을 사용하면 업스트림 라우팅 디바이스가 미리 MPLS 레이블 스위치 경로(LSP)를 설정하거나 미리 IP LFA(loop-free alternate) FR(fast reroute) 백업 경로를 계산하여 다운스트림 경로에서 세그먼트 장애를 해결합니다.

멀티캐스트 라우팅에서 수신 측은 보통 트래픽 배포 그래프를 생성합니다. 유니캐스트 라우팅과 다릅니다. 유니캐스트 라우팅은 보통 소스에서 수신자로의 경로를 설정합니다. PIM(IP용), 멀티포인트 LDP (MPLS용) 및 RSVP-TE(MPLS용)는 멀티캐스트 배포 그래프를 설정할 수 있는 프로토콜입니다. 이중 PIM 및 멀티포인트 LDP 수신자는 배포 그래프 설정을 시작하므로 MoFRR은 지원되는 경우 이러한 멀티캐스트 프로토콜 2개와 함께 작동할 수 있습니다.

멀티캐스트 트리에서 디바이스가 네트워크 구성 요소 장애를 감지하면 반응형 복구를 수행하는 데 일정 시간이 소요되므로, 대체 경로 설정 동안 상당한 트래픽을 손실할 수 있습니다. MoFRR은 네트워크 구성 요소 장애 시 멀티캐스트 배포 트리에서 트래픽 손실을 줄여줍니다. MoFRR을 사용하면 다운스트림 라우팅 디바이스 중 하나가 소스로의 대체 경로를 설정하여 동일한 멀티캐스트 트래픽의 백업 라이브 스트림을 수신합니다. 기본 스트림에서 장애가 발생하면 MoFRR 라우팅 디바이스는 빠르게 백업 스트림으로 전환합니다.

MoFRR이 활성화되면 각 (S, G) 엔트리의 경우, 디바이스는 사용 가능한 업스트림 인터페이스 중 2개를 사용해 참가 메시지를 보내고 멀티캐스트 트래픽을 수신합니다. 프로토콜은 2개의 결합 안 된 경로가 사용 가능한 경우 해당 경로 선택을 시도합니다. 결합 안 된 경로를 사용할 수 없는 경우 프로토콜은 2개의 결합 경로를 선택합니다. 2개의 결합 경로를 사용할 수 없는 경우 백업 없이 기본 경로만 선택됩니다. MoFRR은 사용 가능한 경로의 로드 밸런싱을 통해 결합 안 된 백업의 우선순위를 결정합니다.

MoFRR은 IPv4 및 IPv6 프로토콜 패밀리를 지원합니다.

그림 12은(는) 멀티캐스트 수신기 라우팅 디바이스(전송 프로바이더 에지(PE) 디바이스라고도 명명)에서 멀티캐스트 소스 라우팅 디바이스(수신 PE 디바이스로도 명명)에 이르는 소스로부터 2개의 경로를 표시합니다.

그림 12: MoFRR 샘플 토폴로지MoFRR 샘플 토폴로지

MoFRR을 활성화하면 전송(수신자 측) 라우팅 디바이스가 2개의 멀티캐스트 트리로 각 (S, G)에 대한 멀티캐스트 소스 방향의 기본 경로와 백업 경로를 설정합니다. 즉, 전송 라우팅 디바이스가 동일한 (S, G) 참가 메시지를 2개의 각기 다른 업스트림 이웃으로 전송하므로 2개의 멀티캐스트 트리가 생성됩니다.

그림 12에 표시된 대로 멀티캐스트 트리 중 하나는 플레인 1로 이동하고 다른 하나는 플레인 2로 이동합니다. 각 (S, G)에 대해 전송 라우팅 디바이스는 기본 경로에서 수신한 트래픽을 전달하고 백업 경로에 수신한 트래픽을 드롭합니다.

MoFRR은 동일한 비용의 multipath (ECMP) 경로 및 비-ECMP 경로에서 지원됩니다. 디바이스는 유니캐스트 LFA(loop-free alternate) 경로를 활성화하여 비-ECMP 경로에서 MoFRR을 지원해야 합니다. link-protection문을 사용해 내부 게이트웨이 프로토콜(IGP) 구성에서 LFA 경로를 활성화할 수 있습니다. OSPF 또는 IS-IS 인터페이스에서 링크 보호를 활성화하면 디바이스는 보고 인터페이스를 통과하는 모든 목적지 경로의 기본 다음 홉에 백업 LFA 경로를 생성합니다.

Junos OS 는 IP MoFRR을 위해 IP 네트워크에서, 멀티포인트 LDP MoFRR을 위해 MPLS 레이블 에지 라우팅 디바이스(LER)에서 MoFRR을 구현합니다.

멀티포인트 LDP MoFRR은 MPLS 네트워크의 전송 디바이스에서 사용됩니다. 이때 패킷은 IP 네트워크로 전달됩니다. 멀티포인트 LDP MoFRR을 사용하면 디바이스는 업스트림 PE 라우팅 디바이스 방향으로 2개의 경로를 설정하여 LER에서 MPLS 패킷의 2개 스트림을 수신합니다. 디바이스는 스트림(기본) 중 하나를 수신하고 다른 스트림(백업)은 LER에서 삭제됩니다. 기본 경로가 실패하면 디바이스가 대신 백업 스트림을 수락합니다. 대역 내 신호 지원은 멀티포인트 LDP를 사용하는 MoFRR의 전제 조건입니다(포인트 투 멀티포인트 LSP에 대한 멀티포인트 LDP 대역 내 신호 이해하기 참조).

PIM 기능

Junos OS는 PIM 소스 고유 멀티캐스트(SSM)와 임의 소스 멀티캐스트(ASM)의 최단 경로 트리(SPT) 참가를 위한 MoFRR을 지원합니다. MoFRR은 SSM 및 ASM 범위에서 모두 지원됩니다. (*,G) 참가에 대해 MoFRR을 활성화하려면 [edit routing-options multicast stream-protection] 계층에 mofrr-asm-starg 구성 문을 포함합니다. 각 그룹 G에 대해 MoFRR은 (S,G) 또는 (*,G) 중 하나에 대해 작동하지만 둘 다 작동하지는 않습니다. (S,G)는 항상 (*,G)보다 우선합니다.

MoFRR이 활성화된 경우, PIM 라우팅 디바이스는 두 개의 업스트림 역경로 포워딩(RPF) 인터페이스에서 참가 메시지를 전파하여 동일한 참가 요청에 대해 두 링크 모두에서 멀티캐스트 트래픽을 수신합니다. MoFRR은 동일한 즉시 업스트림 라우팅 디바이스로 수렴되지 않는 두 경로를 우선합니다. PIM은 두 개의 인터페이스(기본 및 백업 경로용)를 가진 업스트림 RPF 다음 홉으로 적절한 멀티캐스트 경로를 설치합니다.

기본 경로에 장애가 발생하면 백업 경로가 기본 상태로 업그레이드되고 디바이스가 그에 따라 트래픽을 전달합니다. 사용 가능한 대체 경로가 있는 경우, MoFRR은 새로운 백업 경로를 계산하고 적절한 멀티캐스트 경로를 업데이트하거나 설치합니다.

PIM 참가 로드 밸런싱으로 MoFRR을 활성화할 수 있습니다(join-load-balance automatic 문 참조). 그러나 이 경우 링크 간 참가 메시지의 분포가 고르지 않을 수 있습니다. 새 ECMP 링크가 추가되면 기본 경로에 있는 참가 메시지가 재배포되고 로드 밸런싱됩니다. 백업 경로의 참가 메시지는 여전히 동일한 경로를 따를 수 있으며 균등하게 재배포되지 않을 수 있습니다.

[edit routing-options multicast] 계층에서 1···2··1 stream-protection 구성 문을 사용하여 MoFRR을 활성화합니다. MoFRR은 필터 정책 집합에 의해 관리됩니다.

출력 PIM 라우팅 디바이스가 참가 메시지 또는 IGMP 보고서를 수신하면 MoFRR 구성을 확인하고 다음과 같이 진행합니다.

  • MoFRR 구성이 없는 경우, PIM은 하나의 업스트림 인접 라우터(예: 그림 12의 플레인 2)를 향해 업스트림 참가 메시지를 보냅니다.

  • MoFRR 구성이 있는 경우 디바이스는 정책 구성을 확인합니다.

  • 정책이 없으면 디바이스는 기본 및 백업 경로(업스트림 인터페이스)를 확인하고 다음과 같이 진행합니다.

    • 기본 및 백업 경로를 사용할 수 없는 경우, PIM은 하나의 업스트림 인접 라우터(예: 그림 12의 플레인 2)를 향해 업스트림 참가 메시지를 보냅니다.

    • 기본 및 백업 경로를 사용할 수 있는 경우, PIM은 사용 가능한 업스트림 인접 라우터 중 두 개를 향해 가입 메시지를 업스트림으로 보냅니다. Junos OS는 멀티캐스트 트래픽을 수신하기 위해 기본 및 보조 멀티캐스트 경로를 설정합니다(예: 그림 12의 플레인 1).

  • 정책이 있는 경우 디바이스는 정책이 이 (S,G)에 대해 MoFRR을 허용하는지 확인하고 다음과 같이 진행합니다.

    • 이 정책 확인이 실패할 경우, PIM은 하나의 업스트림 인접 라우터(예: 그림 12의 플레인 2)를 향해 업스트림 참가 메시지를 보냅니다.

    • 이 정책 검사가 통과되면, 디바이스는 기본 및 백업 경로(업스트림 인터페이스)를 확인합니다.

      • 기본 및 백업 경로를 사용할 수 없는 경우 PIM은 업스트림 인접 라우터(예: 그림 12의 플레인 2)를 향해 업스트림 참가 메시지를 보냅니다.

      • 기본 및 백업 경로를 사용할 수 있는 경우 PIM은 사용 가능한 업스트림 인접 라우터 중 두 개를 향해 참가 메시지를 업스트림으로 보냅니다. 디바이스는 멀티캐스트 트래픽을 수신하기 위해 1차 및 2차 멀티캐스트 경로를 설정합니다(예: 그림 12의 플레인 1).

멀티포인트 LDP 기능

MPLS 트래픽 중복을 방지하기 위해 멀티포인트 LDP는 일반적으로 업스트림 경로를 하나만 선택합니다. (섹션 2.4.1.1 RFC 6388, 점간 라벨 스위치드 경로 1에 대한 라벨 분배 프로토콜 확장에서 '업스트림 LSR' 결정 참조)

MoFRR을 사용하는 멀티포인트 LDP의 경우, 멀티포인트 LDP 디바이스는 두 개의 개별 업스트림 피어를 선택하고 각 업스트림 피어에 하나씩 두 개의 개별 레이블을 보냅니다. 디바이스는 RFC 6388에 설명된 것과 동일한 알고리즘을 사용하여 기본 업스트림 경로를 선택합니다. 디바이스는 동일한 알고리즘을 사용하여 백업 업스트림 경로를 선택하지만 기본 업스트림 LSR은 후보로 제외합니다. 두 개의 서로 다른 업스트림 피어는 두 개의 MPLS 트래픽 스트림을 출력 라우팅 디바이스로 보냅니다. 디바이스는 MPLS 트래픽을 허용할 기본 경로로 업스트림 인접 경로 중 하나만 선택합니다. 다른 경로가 백업 경로가 되고 디바이스는 해당 트래픽을 삭제합니다. 주 업스트림 경로가 실패하면 디바이스는 백업 경로에서 트래픽을 수락하기 시작합니다. 멀티포인트 LDP 디바이스는 내부 게이트웨이 프로토콜(IGP) 루트 디바이스 다음 홉을 기반으로 두 개의 업스트림 경로를 선택합니다.

포워딩 동등성 클래스(FEC)은 동일한 방식으로, 동일한 경로를 통해, 동일한 포워딩 처리로 포워딩되는 IP 패킷의 그룹입니다. 일반적으로 특정 패킷에 붙여진 레이블은 해당 패킷이 할당된 FEC를 나타냅니다. MoFRR에서는 각 FEC에 대해 두 개의 경로가 mpls.0 테이블에 배치됩니다. 하나는 기본 레이블에 대한 경로이고 다른 하나는 백업 레이블에 대한 경로입니다.

동일한 즉시 업스트림 디바이스에 대한 병렬 링크가 있는 경우 디바이스는 두 병렬 링크를 모두 기본 링크로 간주합니다. 언제든지 업스트림 디바이스는 다중 병렬 링크 중 하나만 트래픽을 전송합니다.

버드 노드는 출력 LSR이지만 하나 이상의 다운스트림 LSR이 직접 연결된 LSR입니다. 버드 노드의 경우 기본 업스트림 경로로부터의 트래픽이 다운스트림 LSR로 전달됩니다. 기본 업스트림 경로가 실패하면 백업 업스트림 경로에서 MPLS 트래픽이 다운스트림 LSR로 전달됩니다. 즉, 다운스트림 LSR 다음 홉이 출력 다음 홉과 함께 두 MPLS 경로에 모두 추가됩니다.

PIM과 마찬가지로 [edit routing-options multicast] 계층에서 stream-protection 구성 문을 사용하여 멀티포인트 LDP로 MoFRR을 활성화하고 필터 정책 집합에 의해 관리됩니다.

MoFRR에 대해 멀티포인트 LDP 포인트 투 멀티포인트 FEC를 활성화한 경우 디바이스는 업스트림 경로를 선택할 때 다음 사항을 고려합니다.

  • 대상 LDP 세션이 없는 경우 대상 LDP 세션을 건너뜁니다. 단일 대상 LDP 세션이 있는 경우 대상 LDP 세션이 선택되지만 해당 포인트 투 멀티 포인트 FEC는 대상 LDP 세션과 연관된 인터페이스가 없기 때문에 MoFRR 기능을 상실합니다.

  • 동일한 업스트림 LSR에 속하는 모든 인터페이스가 기본 경로로 간주됩니다.

  • 루트 노드 경로 업데이트의 경우 업스트림 경로는 IGP의 최신 다음 홉에 따라 변경됩니다. 더 나은 경로를 사용할 수 있는 경우 멀티포인트 LDP는 더 나은 경로로 전환을 시도합니다.

패킷 전달

PIM 또는 멀티포인트 LDP의 경우 디바이스는 입력 인터페이스에서 멀티캐스트 소스 스트림 선택을 수행합니다. 이렇게 하면 패브릭 대역폭을 보존하고 다음과 같은 이유로 포워딩 성능을 극대화할 수 있습니다.

  • 패브릭 전체에서 중복 스트림 전송 방지

  • 여러 경로 검색을 방지하여 패킷이 손실됩니다.

PIM의 경우, 각 IP 멀티캐스트 스트림은 동일한 대상 주소를 포함한다. 패킷이 도착하는 인터페이스에 관계없이 패킷은 동일한 경로를 가집니다. 디바이스는 각 패킷이 도착하는 인터페이스를 확인하고 기본 인터페이스에서 전송된 패킷만 전달합니다. 인터페이스가 백업 스트림 인터페이스와 일치하는 경우 디바이스는 패킷을 삭제합니다. 인터페이스가 기본 또는 백업 스트림 인터페이스와 일치하지 않으면 디바이스는 제어 영역에서 패킷을 예외로 처리합니다.

그림 13에는 PIM을 사용하는 라우터의 기본 및 백업 인터페이스 샘플이 나와 있습니다. 그림 14은(는) PIM을 사용하는 스위치에서도 이와 유사한 프로세스를 보여줍니다.

그림 13: 라우터의 패킷 포워딩 엔진에서 MoFRR IP 경로 조회라우터의 패킷 포워딩 엔진에서 MoFRR IP 경로 조회
그림 14: 스위치의 패킷 포워딩 엔진에서의 MoFRR IP 경로 처리스위치의 패킷 포워딩 엔진에서의 MoFRR IP 경로 처리

라우터에 멀티포인트 LDP가 있는 MoFRR의 경우, 디바이스는 여러 MPLS 레이블을 사용하여 MoFR 스트림 선택을 제어합니다. 각 레이블은 별도의 경로를 나타내지만, 각 레이블은 동일한 인터페이스 목록 검사를 참조합니다. 디바이스는 기본 레이블만 전달하고 다른 레이블은 모두 삭제합니다. 여러 인터페이스가 동일한 레이블을 사용하여 패킷을 수신할 수 있습니다.

그림 15에 멀티포인트 LDP가 있는 라우터의 이 프로세스를 나타냅니다.

그림 15: 패킷 포워딩 엔진의 MoFRR MPLS 경로 조회패킷 포워딩 엔진의 MoFRR MPLS 경로 조회

제한사항 및 주의사항

스위칭 및 라우팅 디바이스의 MoFRR 제한 사항 및 주의 사항

MoFRR에는 라우팅 및 스위칭 디바이스에 대한 다음과 같은 제한 사항 및 주의 사항이 있습니다.

  • MoFRR 장애 감지는 멀티캐스트 트래픽 경로의 모든 링크(엔드 투 엔드)가 아닌 MoFRR이 활성화된 라우팅 디바이스의 즉각적인 링크 보호를 위해 지원됩니다.

  • MoFRR은 소스로 향하는 선택된 두 개의 분리된 경로에서 빠른 FR(fast reroute)을 지원합니다. 선택한 업스트림 네이버 중 두 개는 동일한 인터페이스에 있을 수 없습니다. 즉, LAN 세그먼트에 있는 두 개의 업스트림 이웃입니다. 업스트림 인터페이스가 멀티캐스트 터널 인터페이스인 경우에도 마찬가지입니다.

  • 최대 단대단 분리 업스트림 경로 탐지는 지원되지 않습니다. 수신기 측(출력) 라우팅 디바이스는 분리된 업스트림 디바이스(직전의 홉)가 있는지만 확인합니다. PIM 및 멀티포인트 LDP는 명시적 경로 객체(ERO)와 동등한 것을 지원하지 않습니다. 따라서, 분리된 업스트림 경로 검출은 직전 홉 디바이스에 대한 제어로 제한됩니다. 이 제한으로 인해 기본 및 백업으로 선택한 이전 홉의 업스트림 디바이스에 대한 경로가 공유될 수 있습니다.

  • 다음과 같은 시나리오에서 일부 트래픽이 손실될 수 있습니다.

    • 출력 디바이스에서 더 나은 업스트림 경로를 사용할 수 있게 됩니다.

    • 활성 트래픽 스트림이 흐르는 동안 출력 디바이스에서 MoFRR을 사용하거나 사용하지 않도록 설정합니다.

  • 백업 경로의 참가 메시지에 대한 PIM 참가 로드 밸런싱은 지원되지 않습니다.

  • 멀티캐스트 그룹 G의 경우, MoFRR은 (S,G) 및 (*,G) 참가 메시지 모두에 대해 허용되지 않습니다. (S,G) 참가 메시지가 (*,G)보다 우선합니다.

  • 두 개의 서로 다른 멀티캐스트 그룹을 사용하는 멀티캐스트 트래픽 스트림에는 MoFRR이 지원되지 않습니다. 각각의 (S,G) 조합은 고유한 멀티캐스트 트래픽 스트림으로 처리됩니다.

  • 양방향 PIM 범위는 MoFRR에서 지원되지 않습니다.

  • PIM 집적도-모드는 MoFRR에서 지원되지 않습니다.

  • 백업 트래픽 스트림에 대한 멀티캐스트 통계는 PIM에 의해 유지 관리되지 않으므로 show 명령의 작동 출력에는 사용할 수 없습니다.

  • 속도 모니터링은 지원되지 않습니다.

PIM을 사용한 스위칭 디바이스의 MoFRR 제한

PIM을 사용하는 MoFRR에는 스위칭 디바이스에 다음과 같은 제한이 있습니다.

  • 업스트림 인터페이스가 IRB(Internet Group Management Protocol version 3) 스누핑과 같은 다른 멀티캐스트 기능에 영향을 미치는 통합 라우팅 및 브리징(IRB) 인터페이스인 경우 MoFRR이 지원되지 않습니다.

  • 멀티캐스트 트래픽을 전달하는 동안 패킷 복제 및 멀티캐스트 조회는 패킷이 여러 번 PFE를 통해 재순환되도록 할 수 있습니다. 결과적으로, show pfe statistics traffic 명령에서 멀티캐스트 패킷 수에 대해 표시된 값은 Input packetsOutput packets와(과) 같은 출력 필드에서 예상보다 높은 수치를 나타낼 수 있습니다. 기본 및 백업 스트림을 복제하면 일반적으로 트래픽 흐름이 증가하므로 MoFRR 시나리오에서 이 동작을 더 자주 볼 수 있습니다.

멀티포인트 LDP를 사용하는 라우팅 디바이스의 MoFRR 제한 사항 및 주의 사항

MoFRR은 멀티포인트 LDP와 함께 사용될 때 라우터에 다음과 같은 제한 사항 및 주의 사항이 있습니다.

  • RSVP 터널이 인터페이스와 연결되어 있지 않기 때문에 RSVP 터널에서 수신되는 멀티포인트 LDP 트래픽에는 MoFRR이 적용되지 않습니다.

  • 혼합 업스트림 MoFRR은 지원되지 않습니다. 이는 PIM 멀티포인트 LDP 인밴드 시그널링을 의미하며, 한 업스트림 경로는 멀티포인트 LDP를 통과하고 두 번째 업스트림 경로는 PIM을 통과합니다.

  • 내부 레이블로서의 멀티포인트 LDP 레이블은 지원되지 않습니다.

  • 소스가 여러 입력(소스 측) 공급자 에지(PE) 라우팅 디바이스를 통해 연결할 수 있는 경우 멀티포인트 LDP MoFRR은 지원되지 않습니다.

  • 대상 LDP 업스트림 세션이 MoFRR의 업스트림 디바이스로 선택되지 않습니다.

  • MoFRR 내부 레이블을 지원하지 않으므로 백업 경로의 멀티포인트 LDP 링크 보호가 지원되지 않습니다.

Multicast-Only Fast Reroute 구성

링크 장애가 있을 때 네트워크에서 패킷 손실을 최소화하기 위해 MoFRR(Multicast-only Fast Reroute)를 구성할 수 있습니다.

Fast Reroute가 유니캐스트 스트림에 적용될 때, 업스트림 라우터는 다운스트림 경로에서 세그먼트의 장애를 처리하기 위해 MPLS LSPs(label-switched paths)를 미리 설정하거나 IP LFA(loop-free alternate) fast reroute 백업 경로를 미리 계산합니다.

멀티캐스트 라우팅에서 트래픽 분포 그래프는 일반적으로 수신기에 의해 생성됩니다. 이는 일반적으로 소스에서 수신기로의 경로를 설정하는 유니캐스트 라우팅과는 다릅니다. 멀티캐스트 분포 그래프를 확립할 수 있는 프로토콜은 PIM(IP 용), 멀티포인트 LDP(MPLS 용) 및 RSVP-TE(MPLS 용)입니다. 이들 중, PIM 및 멀티포인트 LDP 수신기는 분포 그래프 설정을 시작하므로:

  • QFX 시리즈에서 MoFRR은 PIM 도메인에서 지원됩니다.

  • MX 시리즈 및 SRX 시리즈에서 MoFRR은 PIM 및 멀티포인트 LDP 도메인에서 지원됩니다.

별도의 다른 설명이 없는 한 이 기능을 지원하는 모든 디바이스에서 PIM에 대한 MoFRR을 활성화하기 위한 구성 단계는 동일합니다. 멀티포인트 LDP MoFRR에 적용되지 않는 구성 단계도 표시됩니다.

(MX 시리즈 라우터 전용) MoFRR은 MPC 라인 카드가 있는 MX 시리즈 라우터에서 지원됩니다. 전제 조건으로, 라우터의 모든 라인 카드는 MPC 여야 합니다.

라우터 또는 스위치에서 MoFRR을 구성하려면:

  1. (MX 시리즈 및 SRX 시리즈 라우터의 경우에만 해당) 라우터를 확장 IP 모드로 설정합니다.
  2. MoFRR을 활성화합니다.
  3. (선택사항) MoFRR 구성의 영향을 받을 제한된 멀티캐스트 스트림 집합을 필터링하는 라우팅 정책을 구성합니다.

    소스 또는 그룹 주소를 기반으로 하는 필터를 적용할 있습니다.

    예:

  4. (선택사항) MoFRR 구성의 영향을 받을 멀티캐스트 그룹 집합을 필터링하도록 라우팅 정책을 구성한 경우 MoFRR 스트림 보호를 위한 정책을 적용합니다.

    예:

  5. (선택사항) MoFRR이 있는 PIM 도메인에서 MoFRR이 ASM(any-source multicast)(*, G) 조인에 적용될 수 있도록 합니다.

    이는 멀티포인트 LDP MoFRR에는 지원되지 않습니다.

  6. (선택사항) MoFRR이 있는 PIM 도메인에서 백업 RPF 경로로 분리된 RPF(별도의 평면에 있는 RPF)만 선택되도록 허용합니다.

    이는 멀티포인트 LDP MoFRR에는 지원되지 않습니다. 멀티포인트 LDP MoFRR 도메인에서, 동일한 레이블은 동일한 업스트림 neighbor에 대한 병렬 링크 간에 공유됩니다. 이는 각 링크가 neighbor를 형성하는 PIM 도메인에서의 케이스는 아닙니다. 경로가 기본 RPF 경로와 동일한 업스트림 neighbor로 이동하는 경우, mofrr-disjoint-upstream-only 명령문에서는 백업 RPF 경로를 선택할 수 없습니다. 이를 통해 여러 RPF 업스트림 neighbor가 있는 topology에서만 MoFRR이 작동됩니다.

  7. (선택사항) MoFRR이 있는 PIM 도메인에서 백업 경로에서 조인 메시지 전송을 막지만 다른 모든 MoFRR 기능을 유지합니다.

    이는 멀티포인트 LDP MoFRR에는 지원되지 않습니다.

  8. (선택사항) MoFRR이 있는 PIM 도메인에서 백업 경로가 기본 경로를 승격하는 대신, 소스에 대한 유니캐스트 게이트웨이 선택을 기반으로 새로운 기본 경로 선택을 허용하고, 유니캐스트 선택의 변경이 있을 때 변경할 수 있습니다. 이를 통해 기본 RPF hop이 항상 최선의 경로를 유지할 수 있습니다.

    mofrr-primary-selection-by-routing 명령문을 포함하면 기본 경로가 다운될 때 백업 경로가 새로운 기본 경로로 승격되지 않습니다.

    이는 멀티포인트 LDP MoFRR에는 지원되지 않습니다.

예: 멀티포인트 LDP 도메인에 멀티캐스트 전용 Fast Reroute 구성

다음 예시는 링크 장애가 있을 때 네트워크에서 패킷 손실을 최소화하기 위한 멀티캐스트 전용 Fast Reroute(MoFRR) 구성 방법을 보여줍니다.

멀티포인트 LDP MoFRR은 MPLS 네트워크의 송신 노드에서 사용됩니다. 이때 패킷은 IP 네트워크로 전달됩니다. 멀티포인트 LDP MoFRR의 경우, 업스트림 프로바이더 에지(PE) 라우터를 위한 두 경로가 연결되어 레이블 에지 라우터(LER)에서 두 개의 MPLS 패킷을 수신합니다. 스트림(기본) 중 하나가 수락되고 다른 하나(백업)는 LER에서 떨어집니다. 기본 경로가 실패하면 백업 스트림이 허용됩니다.

요구 사항

이 예를 구성하기 전에 디바이스 초기화를 제외한 특별한 구성은 필요하지 않습니다.

멀티포인트 LDP 도메인에서 MoFRR이 작동하려면 송신 PE 라우터만 MoFRR을 활성화합니다. 다른 라우터는 MoFRR을 지원할 필요가 없습니다.

MoFRR은 MPC 라인 카드가 있는 MX 시리즈 플랫폼에서 지원됩니다. 전제 조건으로 라우터 역시 network-services enhanced-ip 모드로 설정되어야 하며 플랫폼의 모든 라인 카드는 MPC이어야 합니다.

다음 예시는 송신 PE 라우터에서 Junos OS 릴리스 14.1 이상을 필요로 합니다.

개요

다음 예시에서 디바이스 R3은 송신 에지 라우터입니다. MoFRR은 디바이스에서만 활성화됩니다.

OSPF는 연결을 위해 사용되지만 모든 내부 게이트웨이 프로토콜(IGP) 또는 정적 경로도 사용될 수 있습니다.

테스트 목적으로 라우터는 소스 및 수신기를 시뮬레이션하는 데 사용됩니다. 디바이스 R4와 디바이스 R8은 set protocols igmp interface interface-name static group group 명령을 사용해 원하는 그룹에 정적으로 합류하도록 구성됩니다. 리얼 멀티캐스트 수신기 호스트를 사용할 수 없는 경우, 본 예시와 같이 정적 IGMP 구성이 유용합니다. 수신자에서 멀티캐스트 그룹 주소를 듣게 하기 위해 본 예시는 set protocols sap listen group을(를) 사용합니다.

MoFRR 구성은 정책 옵션을 포함합니다. 다음 예시에서 보여주고 있지 않지만 별도로 설명되어 있습니다. 옵션은 다음과 같이 구성됩니다.

토폴로지

그림 16은 샘플 네트워크를 표시합니다.

그림 16: 멀티포인트 LDP 도메인의 MoFRR멀티포인트 LDP 도메인의 MoFRR

CLI 빠른 구성그림 16 내 모든 디바이스의 구성을 보여줍니다.

섹션 구성은 디바이스 R3의 단계를 설명합니다.

CLI 빠른 구성

CLI 빠른 구성

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

디바이스 src1

디바이스 src2

디바이스 R1

디바이스 R2

디바이스 R3

디바이스 R4

디바이스 R5

디바이스 R6

디바이스 R7

디바이스 R8

구성

절차

단계별 절차

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

디바이스 R3 구성:

  1. 향상된 IP 모드를 활성화합니다.

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

  3. AS(Autonomous System) 번호를 구성합니다.

  4. 라우팅 정책을 구성합니다.

  5. PIM을 구성합니다.

  6. LDP를 구성합니다.

  7. IGP 또는 정적 경로를 구성합니다.

  8. 내부 BGP(Border Gateway Protocol)를 구성합니다.

  9. MPLS 및 선택한 경우 RSVP를 구성합니다.

  10. MoFRR을 활성화합니다.

결과

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

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

검증

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

LDP 포인트 간 다중 전달 동등 클래스 확인하기

목적

MoFRR이 활성화되어 있는지 확인하고 어떤 레이블을 사용할지 결정합니다.

작업
의미

출력으로 MoFRR이 활성화되어 있으며 2개의 멀티포인트 LDP 포인트 간 LSP 모두에 대해 301568 및 301600이 사용되고 있음을 보여줍니다.

레이블 정보 검사하기

목적

송신 디바이스 장치에 멀티캐스트 그룹 조인에 대한 두 개의 업스트림 인터페이스를 가지고 있는지 확인합니다.

작업
의미

출력은 기본 업스트림 경로 및 백업 업스트림 경로를 보여줍니다. 또한 RPF의 다음 홉을 보여줍니다.

멀티캐스트 경로 확인하기

목적

IP 멀티캐스트 포워딩 테이블을 검토하여 기본 및 백업 인터페이스를 통해 업스트림 RPF 인터페이스 목록이 있는지 확인합니다.

작업
의미

출력은 기본 및 백업 세션을 보여주며 RPF의 다음 홉을 보여줍니다.

LDP 포인트 간 멀티포인트 트래픽 통계 확인하기

목적

기본 및 백업 통계가 모두 나열되어 있는지 확인합니다.

작업
의미

출력은 레이블을 포함하는 기본 및 백업 경로를 모두 보여줍니다.

예: 온디맨드 LDP 다운스트림 구성하기

다음 예는 온디맨드 LDP 다운스트림을 구성하는 방법을 보여줍니다. LDP는 일반적으로 다운스트림을 원치 않는 광고 모드를 사용하여 구성되며, 이는 모든 경로에 대한 레이블 광고는 모든 LDP 피어에서 수신되는 것을 의미합니다. 서비스 프로바이더가 액세스 및 어그리게이션 네트워크를 단일 MPLS 도메인에 통합함에 따라 온디맨드 LDP 다운스트림은 액세스 및 어그리게이션 네트워크 간에 바인딩이 분산되고 컨트롤 플레인 처리 요건은 감소되어야 합니다.

다운스트림 노드는 업스트림 어그리게이션 노드에서 수만 개의 레이블 바인딩을 잠재적으로 수신할 수 있습니다. MPLS 네트워크 내에서 가능한 모든 루프백 주소에 대한 모든 레이블 바인딩을 학습하고 저장하는 대신 다운스트림 어그리게이션 노드는 온디맨드 LDP 다운스트림을 사용하여 서비스가 구성된 송신 노드의 루프백 주소에 해당하는 FEC에 대한 레이블 바인딩만을 요청하도록 구성될 수 있습니다.

요구 사항

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

  • M Series 라우터

  • Junos OS 12.2

개요

[edit protocols ldp session] 계층 수준에서 downstream-on-demand 명령문을 포함하여 LDP 세션에 대한 온디맨드 LDP 다운스트림 레이블 광고를 활성화할 수 있습니다. 온디맨드 다운스트림 구성을 완료했다면 주니퍼 네트웍스 라우터는 온디맨드 다운스트림을 광고해 피어 라우터에 요청합니다. 두 라우터 간에 온디맨드 다운스트림 세션이 설정되어야 하는 경우, LDP 세션 설정 시 온디맨드 다운스트림 모드를 두 라우터 모두에서 광고해야 합니다. 하나의 라우터가 다운스트림을 원치 않는 모드를 광고하고 다른 라우터가 온디맨드 다운스트림을 광고하면 다운스트림을 원치 않는 모드가 사용됩니다.

구성

온디맨드 LDP 다운스트림 구성하기

단계별 절차

온디맨드 LDP 다운스트림을 정책을 구성한 후, 해당 정책과 LDP 세션에서 온디맨드 LDP 다운스트림을 구성하고 활성화하려면 다음을 따르세요.

  1. 온디맨드 다운스트림 정책을 구성합니다(DOD-Request-Loopbacks 예시와 같음).

    이 정책은 라우터가 DOD-Request-Loopbacks 정책과 일치하는 FEC에만 레이블 요청 메시지를 전달하도록 합니다.

  2. [edit protocols ldp] 계층 수준에서 dod-request-policy 명령문을 사용하여 DOD-request-Loopbacks 정책 설정을 지정합니다.

    dod-request-policy 명령문으로 지정된 정책은 레이블 요청 메시지를 보내기 위한 접두사를 식별하는 데 사용됩니다. 이 정책은 송신 정책 또는 가져오기 정책과 유사합니다. inet.0 라우팅 테이블 경로를 처리하는 경우, Junos OS 소프트웨어는 DOD-Request-Loopbacks 정책과 일치하는 경로를 확인합니다. (본 예시 참조) 경로가 정책과 일치하고 LDP 세션이 DOD 광고 모드와 협상되는 경우, 레이블 요청 메시지가 해당 다운스트림 LDP 세션에 전송됩니다.

  3. LDP 세션 구성에 downstream-on-demand 명령문을 포함시켜 온디맨드 다운스트림 배포 모드를 활성화합니다.

온디맨드 LDP 다운스트림을 경로를 레이블 BGP(Border Gateway Protocol)로 배포합니다.

단계별 절차

온디맨드 LDP 다운스트림 경로를 레이블 BGP로 배포하려면 BGP 내보내기 정책을 사용합니다.

  1. LDP 경로 정책 설정하기. (redistribute_ldp 예시 참조)

  2. LDP 경로 정책을 포함해 BGP 구성의 redistribute_ldp (BGP 그룹 구성의 일부인 ebgp-to-abr 예시 참조).

    BGP는 redistribute_ldp 정책을 기반으로 LDP 경로를 원격 PE 라우터로 전달합니다.

단계별 절차

레이블 전파를 다운스트림 원치 않는 모드(온디맨드 다운스트림이 아닌)로 구성된 다른 라우터로 제한하기 위해 다음 정책을 구성하세요.

  1. LDP에서 경로를 수락하는 dod-routes 정책 설정을 구성합니다.

  2. do-not-propagate-du-sessions 정책 설정을 구성하여 10.1.1.1 이웃, 10.2.2.210.3.3.3 같은 경로를 전달하지 않습니다.

  3. filter-dod-on-du-sessions 정책 설정을 구성하여 dod-routes 정책이 검토한 경로가 do-not-propagate-du-sessions 정책에 정의된 인접 라우터로 전달되는 것을 방지하십시오.

  4. filter-dod-routes-on-du-sesssion 정책을 BGP 그룹의 내보내기 정책으로 ebgp-to-abr을(를) 지정하세요.

결과

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

검증

레이블 광고 모드 확인하기

목적

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

show ldp session 명령을 사용하여 LDP 세션에 대한 레이블 광고 모드 상태를 확인합니다.

작업

show ldp sessionshow ldp session detail 명령을 실행합니다.

  • show ldp session 명령에 대한 다음의 명령 출력은 Adv. Mode (레이블 광고 모드)이/가 DOD(온디맨드 LDP 다운스트림 세션이 작동 가능하다는 의미)을/를 나타냅니다.

  • show ldp session detail 명령에 대한 다음의 명령 출력은 Local Label Advertisement mode 이/가 기본값인 Downstream unsolicited(온디맨드 다운스트림이 로컬 세션에서 설정되지 않는다는 것을 의미)을/를 나타냅니다. 반대로 Remote Label Advertisement modeNegotiated Label Advertisement mode 모두는 Downstream on demand이/가 원격 세션에서 구성된 것을 나타냅니다.

LDP 네이티브 IPv6 지원 구성

LDP는 IPv6 전용 네트워크 및 RFC 7552에 설명된 바와 같이 IPv6 또는 IPv4 이중 스택 네트워크에서 지원됩니다. 주소 패밀리를 IPv4인 경우 inet로 구성하거나 IPv6 또는 둘 다인 경우 inet6로 구성하거나 transport preference을 IPv4또는 IPv6로 구성합니다. dual-transport 문을 통해 Junos OS LDP는 IPv4 및 IPv6 인접 라우터를 통한 TCP 연결을 단일 스택 LSR로 설정할 수 있습니다. inet-lsr-idinet6-lsr-id ID는 IPv4 및 IPv6 TCP 전송을 통한 LDP 세션을 설정하기 위해 구성해야 하는 두 개의 LSR ID입니다. 이 두 ID는 0이 아니어야 하며 다른 값으로 구성해야 합니다.

IPv6을 이중 스택으로 구성하기 전에 라우팅 및 신호 프로토콜을 구성해야 합니다.

LDP 네이티브 IPv6 지원을 구성하기 위해 다음을 수행해야 합니다:

  1. 서로 다른 주소 패밀리에 대해 서로 다른 레이블을 사용하려면 FEC(Forwarding Equivalence Class) 격리를 사용합니다.
  2. LDP 주소 패밀리를 구성합니다.
  3. IPv4와 IPv6이 모두 활성화된 경우, TCP 연결에 대한 기본 전송을 선택하도록 transport-preference명령문을 구성합니다. 기본적으로 IPv6은 LDP 연결을 설정하기 위한 TCP 전송으로 사용됩니다.
  4. (선택사항) LDP가 IPv4 인접 라우터와의 별도의 IPv4 세션 및 IPv6 인접 라우터와의 IPv6 세션을 설정할 수 있도록 dual transport를 구성합니다. inet-lsr-id을 IPv4의 레이블 스위칭 라우터(LSR) ID로, inet6-lsr-id을 IPv6의 레이블 스위칭 라우터(LSR) ID로 구성합니다.

    예를 들어, inet-lsr-id는 10.255.0.1로, inet6-lsr-id는 10.1.1.1로 구성합니다.

예: LDP 네이티브 IPv6 지원 구성

이 예에서는 Junos OS LDP(Label Distribution Protocol)가 IPv4 인접 라우터와 IPv6 인접 라우터를 통한 TCP 연결을 단일 스택 LSR로 설정하는 방법을 보여 줍니다. 이렇게 하면 IPv4 신호 MPLS LSP(Label-Switched Path)를 사용하여 IPv6 over IPv4 MPLS 코어의 터널링을 방지할 수 있습니다.

요구 사항

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

  • MX 시리즈 라우터 2개

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

IPv6을 이중 스택으로 구성하기 전에 라우팅 및 신호 프로토콜을 구성해야 합니다.

개요

LDP는 IPv6 전용 네트워크 및 RFC 7552에 설명된 바와 같이 IPv6 또는 IPv4 이중 스택 네트워크에서 지원됩니다. IPv4의 경우 주소 패밀리를 inet(으)로 구성하거나 IPv6의 경우 inet6(으)로 구성합니다. IPv4와 IPv6이 모두 사용되도록 설정된 경우 기본적으로 IPv6은 피어와의 LDP 세션에 대한 TCP 전송으로 사용됩니다. 이중 전송 문을 통해 Junos LDP는 IPv4 및 IPv6 인접 라우터를 통한 TCP 연결을 단일 스택 LSR로 설정할 수 있습니다. inet-lsr-id과(와) inet6-lsr-id은(는) IPv4 및 IPv6 TCP 전송을 통한 LDP 세션을 설정하기 위해 구성해야 하는 두 개의 LSR ID입니다. 이 두 ID는 0이 아니어야 하며 다른 값으로 구성해야 합니다.

토폴로지

그림 17에서는 디바이스 R1 및 디바이스 R2에서 이중 스택으로 구성된 LDP IPv6을 보여줍니다.

그림 17: LDP 네이티브 IPv6 지원 예LDP 네이티브 IPv6 지원 예

구성

CLI 빠른 구성

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

R1

R2

R1 구성

단계별 절차

다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색에 대한 내용은 Junos OS CLI 사용자 가이드의 " Using the CLI Editor in Configuration Mode "을(를) 참조하십시오.

디바이스 R1 구성

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

  2. 디바이스에 루프백 주소를 할당합니다.

  3. IS-IS 인터페이스를 구성합니다.

  4. 디바이스에서 LDP 인터페이스를 사용하도록 MPLS를 구성합니다.

  5. 서로 다른 주소 패밀리에 대해 서로 다른 레이블을 사용하려면 FEC(Forwarding Equivalence Class) 격리를 사용합니다.

  6. LDP 주소 패밀리를 구성합니다.

결과

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

선호 전송을 선택하도록 전송 기본 설정 구성

CLI 빠른 구성
단계별 절차

IPv4와 IPv6이 모두 활성화된 경우 TCP 연결에 대한 기본 전송을 선택하도록 transport-preference문을 구성할 수 있습니다. 기본적으로 IPv6은 LDP 연결을 설정하기 위한 TCP 전송으로 사용됩니다.

  • (선택 사항) LDP 연결에 대한 전송 기본 설정을 구성합니다.

단계별 절차
결과

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

IPv4 인접 라우터와 IPv4 및 IPv6 인접 라우터에 대한 별도의 세션을 설정하도록 이중 전송 구성

단계별 절차

LDP가 IPv4 인접 라우터와의 별도의 IPv4 세션 및 IPv6 인접 라우터와의 IPv6 세션을 설정할 수 있도록 dual-transport문을 구성할 수 있습니다. 이를 위해서는 IPv4의 LSR ID로서 inet-lsr-id을(를) IPv6의 LSR ID로서 inet6-lsr-id 을(를) 구성해야 한다.

  • (선택 사항) LDP가 IPv4 인접 라우터와 IPv6 인접 라우터를 통해 단일 스택 LSR로 IPv6 인접 라우터를 통해 TCP 연결을 설정할 수 있도록 이중 전송을 구성합니다.

결과

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

검증

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

mpls.0 테이블의 경로 항목 확인
목적

mpls.0 경로 테이블 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show route table mpls.0명령을 실행하여 mpls.0 경로 테이블 정보를 표시합니다.

의미

출력에는 mpls.0 경로 테이블 정보가 표시됩니다.

inet.3의 경로 항목 확인 테이블
목적

inet.3 경로 테이블 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show route table inet.3명령을 실행하여 inet.3 경로 테이블 정보를 표시합니다.

의미

출력에는 inet.3 경로 테이블 정보가 표시됩니다.

inet 6.3 표의 경로 항목 확인
목적

inet6.3 경로 테이블 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show route table inet6.3명령을 실행하여 inet6.3 경로 테이블 정보를 표시합니다.

의미

출력에는 inet6.3 경로 테이블 정보가 표시됩니다.

LDP 데이터베이스 확인
목적

LDP 데이터베이스 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp database명령을 실행하여 LDP 데이터베이스 정보를 표시합니다.

의미

출력에는 LDP 데이터베이스의 항목이 표시됩니다.

LDP 인접 정보 확인
목적

LDP 인접 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp neighborshow ldp neighbor extensive 명령 을 실행하여 LDP 인접 정보를 표시합니다.

의미

출력에는 IPv4 및 IPv6 주소의 LDP 인접 정보가 모두 표시됩니다.

LDP 세션 정보 확인
목적

LDP 세션 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp sessionshow ldp session extensive 명령을 실행하여 LDP 세션 정보를 표시합니다.

의미

출력에는 IPv6을 TCP 전송으로 사용하는 LDP 세션에 대한 정보가 표시됩니다.

검증

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

LDP 인접 정보 확인
목적

LDP 인접 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp neighbor extensive 명령을 실행하여 LDP 인접 정보를 표시합니다.

의미

출력에는 IPv4 및 IPv6 주소 모두에 대한 LDP 인접 정보가 표시됩니다.

LDP 세션 정보 확인
목적

LDP 세션 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp session extensive 명령을 실행하여 LDP 세션 정보를 표시합니다.

의미

출력에는 IPv6을 TCP 전송으로 사용하는 LDP 세션에 대한 정보가 표시됩니다.

검증

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

LDP 인접 정보 확인
목적

LDP 인접 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp neighbor extensive명령을 실행하여 LDP 인접 정보를 표시합니다.

의미

출력에는 IPv4 및 IPv6 주소 모두에 대한 LDP 인접 정보가 표시됩니다.

LDP 세션 정보 확인
목적

LDP 세션 정보를 표시합니다.

작업

디바이스 R1에서 작동 모드에서 show ldp session extensive명령을 실행하여 LDP 인접 정보를 표시합니다.

예: P2MP(Point-to-multipoint) LSP를 위한 멀티포인트 LDP 인밴드 시그널링 구성

Point-to-Multipoint LSP에 대한 멀티포인트 LDP 대역 내 신호 이해하기

대역 내 시그널링이 있는 LSP(Point-to-Multipoint Label-Switched Path)용 M-LDP(Multipoint Label Distribution Protocol)는 IPTV와 같이 멀티캐스트 트래픽을 전송해야 하는 기존 IP/MPLS 백본을 사용한 구축에 유용합니다.

수년 동안 멀티캐스트 트래픽 전송에 가장 널리 사용된 솔루션은 멀티포인트 IP 터널링과 함께 서비스 프로바이더 코어에서 네이티브 IP 멀티캐스트를 사용하여 고객 트래픽을 격리하는 것이었습니다. 멀티캐스트 라우팅 프로토콜(일반적으로 PIM(Protocol Independent Multicast))이 구축되어 전달 경로를 설정합니다. IP 멀티캐스트 라우팅은 코어에서 PIM 시그널링을 사용하여 포워딩에 사용됩니다. 이 모델이 작동하려면 코어 네트워크가 멀티캐스트를 사용하도록 설정되어야 합니다. 이를 통해 AS(Inter-Autonomous System) 시나리오에서도 효과적이고 안정적인 구축이 가능합니다.

그러나 기존 IP/MPLS 네트워크에서는 PIM 구축이 첫 번째 선택이 아닐 수 있습니다. 일부 서비스 프로바이더는 IP 터널링을 MPLS 레이블 캡슐화로 대체하는 데 관심이 있습니다. MPLS 레이블 스위칭으로 전환하는 이유는 MPLS 트래픽 엔지니어링 및 보호 기능을 활용하고 프로바이더 코어에서 제어 트래픽 오버헤드의 양을 줄이기 위함입니다.

이를 위해 서비스 프로바이더는 기존 구축의 확장을 활용하여 멀티캐스트 트래픽이 통과할 수 있도록 하는 데 관심이 있습니다. IP/MPLS에 대한 기존의 멀티캐스트 확장은 RSVP-TE에 대한 포인트-투-멀티포인트 확장과 LDP에 대한 포인트-투-멀티포인트 및 멀티포인트-투-멀티포인트 확장입니다. 이러한 구축 시나리오는 RFC 6826, Point-to-Multipoint 및 Multipoint-to-Multipoint 레이블 전환 경로에 대한 멀티포인트 LDP 대역 내 신호에 설명되어 있습니다. 이 기능 개요는 LDP에 대한 point-to-multipoint 확장으로 제한됩니다.

M-LDP 작동 방식

M-LDP 신호의 레이블 바인딩

LDP에 대한 멀티포인트 확장은 기능 광고, 레이블 매핑 및 신호 절차와 함께 포인트-투-멀티포인트 및 멀티포인트-투-멀티포인트 포워딩 동등 클래스(FEC) 요소(RFC 5036, LDP 사양에 정의됨)를 사용합니다. FEC 요소에는 IP 주소인 LSP 루트와 동일한 불투명 값을 공유하는 리프 노드를 함께 그룹화하는 선택기인 "불투명" 값의 개념이 포함됩니다. 불투명 값은 중간 노드에 투명하지만 LSP 루트에 대한 의미를 갖습니다. 모든 LDP 노드는 FEC에서 발견된 루트 IP 주소에 대한 최단 경로에 있는 업스트림 LDP 노드에 로컬 수신 레이블 바인딩을 광고합니다. 레이블 바인딩을 수신하는 업스트림 노드는 자체 로컬 레이블 및 발신 인터페이스를 생성합니다. 나가는 분기가 여러 개 있는 경우 이 레이블 할당 프로세스로 인해 패킷 복제가 발생할 수 있습니다. 에서 그림 18볼 수 있듯이 LDP 노드는 동일한 업스트림 노드를 공유하는 다운스트림 노드를 찾으면 동일한 불투명 값에 대한 레이블 바인딩을 병합합니다. 이를 통해 point-to-multipoint LSP를 효과적으로 구축하고 라벨을 보존할 수 있습니다.

그림 18: M-LDP 신호의 레이블 바인딩M-LDP 신호의 레이블 바인딩
PIM-Free MPLS 코어의 M-LDP

그림 19 에서는 축소된 배포 시나리오를 보여 줍니다. 두 개의 개별 PIM 도메인은 PIM이 없는 코어 사이트에 의해 상호 연결됩니다. 이 코어 사이트의 경계 라우터는 경계 인터페이스에서 PIM을 지원합니다. 또한 이러한 경계 라우터는 인접 사이트에서 코어 네트워크로 라우팅 정보를 수집하여 배포합니다. 사이트 C의 에지 라우터는 루트 노드 검색을 위해 BGP를 실행합니다. 대부분의 경우 IGP에서 제공하는 포워딩 다음 홉은 소스에 대한 수신 디바이스에 대한 정보를 제공하지 않기 때문에 IGP(Interior Gateway Protocol) 경로는 수신 발견에 사용할 수 없습니다. M-LDP 대역 내 시그널링은 point-to-multipoint LSP와 (S,G) flow 간에 일대일 매핑을 갖습니다. 대역 내 시그널링을 통해 PIM 메시지는 M-LDP FEC 바인딩으로 직접 변환됩니다. 반면, 대역 외 신호는 수동 구성을 기반으로 합니다. M-LDP 대역 내 시그널링을 위한 한 가지 애플리케이션은 MPLS 백본에서 IPTV 멀티캐스트 트래픽을 전달하는 것입니다.

그림 19: PIM-Free MPLS 코어의 M-LDP 토폴로지 샘플PIM-Free MPLS 코어의 M-LDP 토폴로지 샘플
구성

레이블 에지 라우터(LER)의 구성 문 mldp-inband-signalling 은 LER이 PIM 업스트림 이웃을 감지하지 못할 때 PIM이 업스트림 이웃에 M-LDP 인밴드 시그널링을 사용할 수 있도록 합니다. MPLS LSP 루트의 정적 구성은 정책을 사용하여 PIM 구성에 포함됩니다. 이는 핵심 사이트에서 IBGP를 사용할 수 없거나 IBGP 기반 LSP 루트 감지를 무시할 때 필요합니다.

예:

PIM 지원 MPLS 코어의 M-LDP

Junos OS 릴리스 14.1부터 기존 IPTV 서비스를 네이티브 IP 멀티캐스트에서 MPLS 멀티캐스트로 마이그레이션하려면 중단을 최소화하면서 PIM에서 M-LDP 포인트 투 멀티포인트 LSP로 원활하게 전환해야 합니다. 그림 20 은(는) M-LDP 토폴로지를 그림 19와 유사하지만 시나리오가 다릅니다. 코어는 PIM으로 활성화되며, 하나의 소스가 모든 IPTV 채널을 스트리밍합니다. TV 채널은 ASM 스트림으로 전송되며 각 채널은 그룹 주소로 식별됩니다. 이전에는 이러한 채널이 코어에서 IP 스트림으로 스트리밍되고 PIM을 사용하여 시그널링되었습니다.

그림 20: PIM 지원 MPLS 코어의 샘플 M-LDP 토폴로지PIM 지원 MPLS 코어의 샘플 M-LDP 토폴로지

이 시나리오에서 을 mldp-inband-signaling (를) 구성하면 소스에 대한 PIM neighbor가 없는 경우에만 M-LDP 시그널링이 시작됩니다. 그러나 송신 PE의 업스트림 인터페이스에서 PIM이 비활성화되지 않는 한 소스로 향하는 PIM 이웃이 항상 존재하기 때문에 PIM이 M-LDP보다 우선하며 M-LDP는 적용되지 않습니다.

구성

M-LDP 업스트림을 사용하는 스트림이 거의 없고 기존 PIM 업스트림을 사용하는 다른 스트림이 있는 M-LDP MPLS 코어로 채널별로 점진적으로 마이그레이션하려면 M-LDP 대역 내 신호 전달을 위한 정책 필터에 그룹 기반 필터와 함께 구성 문을 포함합니다 selected-mldp-egress .

주:

M-LDP 대역 내 시그널링 정책 필터는 명령문이나 route-filter 명령문 또는 이 둘의 조합을 포함할 source-address-filter 수 있습니다.

예:

주:

위 구성의 제한 사항 중 일부는 다음과 같습니다.

  • 문은 selected-mldp-egress LER에서만 구성해야 합니다. selected-mldp-egress 송신이 아닌 PIM 라우터에서 문을 구성하면 경로 설정에 실패할 수 있습니다.

  • PIM 업스트림에서 M-LDP 업스트림으로 또는 그 반대로 트래픽을 스위칭하기 위해 정책이 변경되면 컨트롤 플레인에서 브레이크 앤 메이크 메커니즘이 수행되므로 패킷 손실이 예상될 수 있습니다.

용어

다음 용어는 멀티캐스트 트래픽에 대한 M-LDP 인밴드 시그널링을 이해하는 데 중요합니다.

Point-to-point LSP

수신 레이블 스위치 라우터(LSR) 1개와 송신 LSR 1개가 있는 LSP입니다.

Multipoint LSP

point-to-multipoint 또는 multipoint-to-multipoint LSP입니다.

Point-to-multipoint LSP

하나의 수신 LSR과 하나 이상의 송신 LSR이 있는 LSP입니다.

Multipoint-to-point LSP

하나 이상의 수신 LSR과 하나의 고유한 송신 LSR이 있는 LSP입니다.

Multipoint-to-multipoint LSP

LSP의 모든 노드에서 보낸 트래픽이 다른 모든 노드로 전달되도록 노드 집합을 연결하는 LSP입니다.

Ingress LSR

특정 LSP에 대한 수신 LSR은 LSP를 따라 데이터 패킷을 전송할 수 있는 LSR입니다. 멀티포인트 투 멀티포인트 LSP는 여러 수신 LSR을 가질 수 있습니다. 포인트 투 멀티포인트 LSP는 단 하나만 있으며, 이 노드를 종종 루트 노드라고 합니다.

Egress LSR

특정 LSP에 대한 송신 LSR은 추가 처리를 위해 해당 LSP에서 데이터 패킷을 제거할 수 있는 LSR입니다. 포인트-투-포인트 및 멀티포인트-투-포인트 LSP는 단 하나의 송신 노드를 가집니다. 포인트-투-멀티포인트 및 멀티포인트-투-멀티포인트 LSP는 여러 송신 노드를 가질 수 있습니다.

Transit LSR

직접 연결된 업스트림 LSR과 하나 이상의 직접 연결된 다운스트림 LSR을 통해 멀티포인트 LSP의 루트에 도달할 수 있는 LSR입니다.

Bud LSR

송신이지만 하나 이상의 다운스트림 LSR이 직접 연결된 LSR입니다.

Leaf node

point-to-multipoint LSP의 컨텍스트에서 송신 또는 버드 LSR입니다. 멀티포인트 투 멀티포인트 LSP의 맥락에서 LSR은 동일한 멀티포인트 간 LSP에 대한 수신 및 송신이며 버드 LSR이 될 수도 있습니다.

수신 조인 변환 및 의사 인터페이스 처리

수신 LER에서 LDP는 대역 내 시그널링을 통해 수신되는 (S,G) 메시지에 대해 PIM에 알립니다. PIM은 각 (S,G) 메시지를 의사 인터페이스와 연결합니다. 그 후, 소스로 SPT(Shortest-Path-Tree) 참가 메시지가 시작됩니다. PIM은 이를 새로운 유형의 로컬 수신기로 취급합니다. LSP가 삭제되면 PIM은 LDP의 알림에 따라 이 로컬 수신기를 제거합니다.

수신 접합

LDP는 PIM에 각 (S, G) 항목과 연결할 다음 홉을 제공합니다. PIM은 LDP 다음 홉 및 기타 PIM 수신기와 함께 PIM(S,G) 멀티캐스트 경로를 설치합니다. 다음 홉은 로컬 수신기의 복합 다음 홉 + PIM 다운스트림 이웃 목록 + LDP 터널에 대한 하위 수준 다음 홉입니다.

역방향 경로 포워딩

PIM의 RPF(Reverse-Path-Forwarding) 계산은 송신 노드에서 수행됩니다.

PIM은 다음 조건이 모두 참일 때 M-LDP 인밴드 시그널링을 수행합니다.

  • 소스에 대한 PIM 인접 항목이 없습니다.

  • M-LDP 인밴드 시그널링 문이 구성됩니다.

  • 다음 홉은 BGP를 통해 학습되거나 정적 매핑(M-LDP 인밴드 시그널링 정책에 지정)에 존재합니다.

그렇지 않고 LSP 루트 탐지에 실패하면 PIM은 RPF 상태가 미해결인 (S,G) 엔트리를 보유합니다.

PIM RPF는 유니캐스트 라우팅 정보가 변경될 때마다 이 소스 주소를 등록합니다. 따라서 소스에 대한 경로가 변경되면 RPF 재계산이 반복됩니다. 소스로 향하는 BGP 프로토콜 다음 홉도 LSP 루트의 변경 사항에 대해 모니터링됩니다. 이러한 변경으로 인해 짧은 기간 동안 트래픽이 중단될 수 있습니다.

LSP 루트 탐지

RPF 작업이 M-LDP 인밴드 시그널링 업스트림의 필요성을 감지하면 LSP 루트(수신)가 감지됩니다. 이 루트는 LDP LSP 시그널링을 위한 매개 변수입니다.

루트 노드는 다음과 같이 감지됩니다.

  1. 기존 정적 구성이 소스 주소를 지정하는 경우, 루트는 구성에 지정된 대로 사용됩니다.

  2. 조회는 유니캐스트 라우팅 테이블에서 수행됩니다. 소스 주소가 발견되면 소스로 향하는 프로토콜 다음 홉이 LSP 루트로 사용됩니다.

    Junos OS 릴리스 16.1 이전에는 M-LDP point-to-multipoint LSP가 수신 LSR의 루트 주소를 사용하여 송신에서 수신으로 신호를 보냅니다. 이 루트 주소는 IGP를 통해서만 도달할 수 있으므로 M-LDP point-to-multipoint LSP를 단일 자율 시스템으로 제한합니다. 루트 주소가 IGP를 통해 도달할 수 없지만 BGP를 통해 도달할 수 있고 해당 BGP 경로가 MPLS LSP를 통해 재귀적으로 확인되는 경우, 포인트 투 멀티포인트 LSP는 해당 지점에서 수신 LSR 루트 주소로 더 이상 신호를 보내지 않습니다.

    이러한 세그먼트화되지 않은 Point-to-Multipoint LSP는 여러 자율 시스템에 걸쳐 신호를 보내야 하며, 이는 다음 애플리케이션에 사용할 수 있습니다.

    • 세그먼트화되지 않은 Point-to-Multipoint LSP를 사용하는 AS 간 MVPN

    • MPLS 코어 네트워크로 연결된 클라이언트 네트워크 간 AS M-LDP 대역 간 시그널링.

    • 세그먼트화되지 않은 Point-to-Multipoint LSP(원활한 MPLS 멀티캐스트)를 사용하는 영역 간 MVPN 또는 M-LDP 대역 내 신호.

    Junos OS 릴리스 16.1부터 M-LDP는 루트 주소가 MPLS LSP를 통해 재귀적으로 추가로 확인되는 BGP 경로인 경우 ASBR 또는 전송 또는 송신에서 point-to-multipoint LSP에 신호를 보낼 수 있습니다.

송신 조인 변환 및 의사 인터페이스 처리

송신 LER에서 PIM은 LSP 루트와 함께 시그널링될 (S,G) 메시지를 LDP에 알립니다. PIM은 이 (S,G) 메시지에 대한 업스트림 인터페이스로 의사 인터페이스를 생성합니다. (S,G) 정리 메시지가 수신되면 이 연결이 제거됩니다.

송신 접합

다운스트림 사이트로부터의 (S,G) 참가 메시지가 수신되는 코어 네트워크의 송신 노드에서, 이 참가 메시지는 M-LDP 대역 내 시그널링 파라미터로 변환되고 LDP가 통보됩니다. 또한 LSP 분해는 (S,G) 항목이 손실되거나, LSP 루트가 변경되거나, PIM 이웃을 통해 (S,G) 항목에 도달할 수 있을 때 발생합니다.

지원되는 기능

M-LDP 인밴드 시그널링을 위해 Junos OS는 다음과 같은 기능을 지원합니다.

  • LDP 경로를 사용한 PIM 다음 홉의 송신 접합

  • LDP 다음 홉과 PIM 경로의 수신 접합

  • PIM join 메시지를 LDP point-to-multipoint LSP 설정 매개 변수로 변환

  • PIM 조인 메시지를 설정하기 위한 M-LDP 인밴드 LSP 매개 변수 변환

  • 정적으로 구성된 BGP 프로토콜 다음 홉 기반 LSP 루트 탐지

  • PIM 소스별 멀티캐스트(SSM) 및 애니소스 멀티캐스트(ASM) 범위의 PIM(S,G) 상태

  • 수신 및 송신 LER이 에지 라우터로 작동할 수 있도록 하는 구성 문

  • LER의 IGMP 참가 메시지

  • IPv6 소스 및 그룹 주소를 IPv4 루트 노드에 대한 불투명 정보로 전달

  • IPv6(S,G)를 IPv4 루트 주소에 매핑하기 위한 정적 구성

지원되지 않는 기능

M-LDP 인밴드 시그널링의 경우, Junos OS는 다음 기능을 지원하지 않습니다 .

  • PIM ASM에 대한 완벽한 지원

  • mpls lsp point-to-multipoint ping(S,G) 옵션이 있는 명령

  • NSR(Nonstop Active Routing )

  • PIM에 대한 MBB(Make-before-break)

  • IPv6 LSP 루트 주소(LDP는 IPv6 LSP를 지원하지 않습니다.)

  • 직접 연결되지 않은 PIM 스피커 간의 인접 관계

  • 그레이스풀 리스타트(Graceful Restart)

  • PIM 고집적 모드

  • PIM 양방향 모드

LDP 기능

PIM(S,G) 정보는 M-LDP 불투명 TLV(type-length-value) 인코딩으로 전달됩니다. point-to-multipoint FEC 요소는 루트 노드 주소로 구성됩니다. 차세대 멀티캐스트 VPN(NGEN MVPN)의 경우 포인트 투 멀티포인트 LSP는 루트 노드 주소와 LSP ID로 식별됩니다.

송신 LER 기능

송신 LER에서 PIM은 다음 정보를 사용하여 LDP를 트리거하여 point-to-multipoint LSP를 생성합니다.

  • 루트 노드

  • (에스,지)

  • 다음 홉

PIM은 멀티캐스트 트리의 소스를 기반으로 루트 노드를 찾습니다. 루트 주소가 이 (S,G) 엔트리에 구성된 경우, 구성된 주소는 point-to-multipoint LSP 루트로 사용됩니다. 그렇지 않으면 라우팅 테이블을 사용하여 소스에 대한 경로를 조회합니다. 멀티캐스트 트리 소스에 대한 경로가 BGP 학습 경로인 경우 PIM은 BGP 다음 홉 주소를 검색하여 point-to-multipoint LSP의 루트 노드로 사용합니다.

LDP는 루트 노드를 기반으로 업스트림 노드를 찾고, 레이블을 할당하고, 레이블 매핑을 업스트림 노드로 보냅니다. LDP는 대역 내 M-LDP 시그널링에 PHP(Penultimate Hop Popping)를 사용하지 않습니다.

멀티캐스트 트리 소스의 루트 주소가 변경되면 PIM은 포인트-투-멀티포인트 LSP를 삭제하고 LDP가 새로운 포인트-투-멀티포인트 LSP를 생성하도록 트리거합니다. 이 경우 나가는 인터페이스 목록은 NULL이 되고, PIM은 LDP를 트리거하여 Point-to-Multipoint LSP를 삭제하며, LDP는 레이블 철회 메시지를 업스트림 노드로 보냅니다.

전송 LSR 기능

전송 LSR은 point-to-multipoint FEC의 소스를 향해 업스트림 LSR에 레이블을 광고하고 패킷을 전달하는 데 필요한 전달 상태를 설치합니다. 전송 LSR은 모든 M-LDP 지원 라우터가 될 수 있습니다.

수신 LER 기능

수신 LER에서 LDP는 레이블 매핑을 수신하면 PIM에 다음 정보를 제공합니다.

  • (에스,지)

  • 플러드 다음 홉

그런 다음 PIM은 전달 상태를 설치합니다. 새 브랜치가 추가되거나 삭제되면 플러드 다음 홉이 그에 따라 업데이트됩니다. 철회되는 레이블로 인해 모든 브랜치가 삭제되면 LDP는 업데이트된 정보를 PIM으로 보냅니다. 업스트림과 다운스트림 neighbor 사이에 여러 링크가 있는 경우 포인트 투 멀티포인트 LSP는 로드 밸런싱되지 않습니다.

예: P2MP(Point-to-multipoint) LSP를 위한 멀티포인트 LDP 인밴드 시그널링 구성

이 예는 멀티캐스트 트래픽에 대해 PIM(Protocol Independent Multicast) 프로토콜의 확장 또는 PIM의 대체품으로 멀티포인트 LDP(M-LDP) 인밴드 시그널링을 구성하는 방법을 보여줍니다.

요구 사항

이 예는 다음 하드웨어 및 소프트웨어 구성 요소를 사용하여 구성할 수 있습니다.

  • Junos OS 릴리스 13.2 이상

  • 프로바이더 에지(PE) 라우터를 위한 MX 시리즈 5G 유니버설 라우팅 플랫폼 또는 M 시리즈 멀티서비스 에지 라우터

  • 전송 레이블 스위칭 라우터 역할을 하는 PTX 시리즈 패킷 전송 라우터

  • 코어 라우터용 T 시리즈 코어 라우터

주:

PE 라우터는 T 시리즈 코어 라우터일 수도 있지만 일반적이지 않습니다. 확장 요구 사항에 따라 코어 라우터는 MX 시리즈 5G 유니버설 라우팅 플랫폼 또는 M 시리즈 멀티서비스 에지 라우터가 될 수도 있습니다. 고객 에지(CE) 디바이스는 주니퍼 네트웍스 또는 다른 벤더의 다른 라우터 또는 스위치일 수 있습니다.

이 예를 구성하기 전에 디바이스 초기화를 제외한 특별한 구성은 필요하지 않습니다.

개요

CLI 빠른 구성은(는) 그림 21 내 모든 디바이스의 구성을 보여줍니다. 이 섹션에서는 #d358e63__d358e831 디바이스 송신PE의 단계를 설명합니다.

그림 21: Point-to-Multipoint LSP를 위한 M-LDP 대역 내 시그널링 토폴로지 예시Point-to-Multipoint LSP를 위한 M-LDP 대역 내 시그널링 토폴로지 예시

구성

절차
CLI 빠른 구성

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

디바이스 src1

디바이스 IngressPE

디바이스 송신PE

장치 p6

장치 pr3

장치 pr4

장치 pr5

단계별 절차

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

디바이스 송신PE를 구성하려면 다음을 수행합니다.

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

    코어 대면 인터페이스에서 MPLS를 활성화합니다. 송신 다음 홉에서는 MPLS를 활성화할 필요가 없습니다.

  2. 송신 인터페이스에서 IGMP를 구성합니다.

    테스트를 위해 이 예에는 정적 그룹 주소와 소스 주소가 포함되어 있습니다.

  3. 코어 대면 인터페이스에서 MPLS를 구성합니다.

  4. BGP를 구성합니다.

    BGP는 정책 중심 프로토콜이므로 필요한 라우팅 정책을 구성하고 적용할 수도 있습니다.

    예를 들어 정적 경로를 BGP로 내보낼 수 있습니다.

  5. (선택 사항) 디바이스 pr5와의 MSDP 피어 연결을 구성하여 서로 다른 PIM 도메인을 상호 연결하여 중복 RP를 활성화합니다.

  6. OSPF를 구성합니다.

  7. 코어 대면 인터페이스와 루프백 인터페이스에서 LDP를 구성합니다.

  8. point-to-multipoint MPLS LSP를 활성화합니다.

  9. 다운스트림 인터페이스에서 PIM을 구성합니다.

  10. 이 디바이스가 PIM 랑데부 포인트(RP) 역할을 하므로 RP 설정을 구성합니다.

  11. M-LDP 대역 내 시그널링을 활성화하고 관련 정책을 설정합니다.

  12. point-to-multipoint LSP 및 관련 소스 주소에 대한 루트 주소를 지정하는 라우팅 정책을 구성합니다.

  13. AS(Autonomous System) ID를 구성합니다.

결과

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

디바이스 송신PE

마찬가지로 다른 송신 디바이스도 구성합니다.

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

검증

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

PIM 조인 상태 확인
목적

PIM 조인 상태에 대한 정보를 표시하여 M-LDP 인밴드 업스트림 및 다운스트림 세부 정보를 확인합니다. 수신 디바이스에서 show pim join extensive 다운스트림 인터페이스에 대한 명령이 표시됩니다 Pseudo-MLDP . 송신 show pim join extensive 시 업스트림 인터페이스에 대한 명령이 표시됩니다 Pseudo-MLDP .

작업

운영 모드에서 show pim join extensive 명령을 입력합니다.

PIM 소스 확인
목적

PIM 소스에 예상되는 M-LDP 인밴드 업스트림 및 다운스트림 세부 정보가 있는지 확인합니다.

작업

운영 모드에서 show pim source 명령을 입력합니다.

LDP 데이터베이스 확인
목적

명령이 예상되는 루트-(S,G) 바인딩을 표시하는지 show ldp database 확인합니다.

작업
MPLS 레이블에 대한 경로 정보 조회
목적

포인트 투 멀티포인트 FEC 정보를 표시합니다.

작업
LDP 트래픽 통계 확인
목적

포인트 투 멀티포인트 LSP에 대한 데이터 트래픽 통계를 모니터링합니다.

작업

LDP 상호 운용성에 대한 세그먼트 라우팅을 위한 클라이언트 및 서버 매핑

세그먼트 라우팅 매핑 서버 및 클라이언트 지원은 LDP를 실행하는 네트워크 아일랜드와 세그먼트 라우팅(SR 또는 SPRING) 간의 상호 운용성을 지원합니다. 이러한 상호 운용성은 LDP에서 SR로의 마이그레이션할 때 유용합니다. 전환 중에는 LDP만 지원하거나 세그먼트 라우팅만 지원하는 디바이스가 있는 아일랜드(또는 도메인)가 있을 수 있습니다. 이러한 디바이스가 상호 작용하려면 LDP 세그먼트 라우팅 매핑 서버(SRMS) 및 세그먼트 라우팅 매핑 클라이언트(SRMC) 기능이 필요합니다. 세그먼트 라우팅 네트워크 디바이스에서 이러한 서버 및 클라이언트 기능을 활성화합니다.

SR 매핑 서버 및 클라이언트 기능은 OSPF 또는 ISIS로 지원됩니다.

LDP 상호 운용성을 위한 세그먼트 라우팅 개요

그림 22간단한 LDP 네트워크 토폴로지를 통해 세그먼트 라우팅 디바이스와 LDP 디바이스의 상호 운용성이 어떻게 작동하는지 보여줍니다. 최단 경로 우선(OSPF) 및 ISIS가 모두 지원되므로, 지금은 IGP 관련해 애그노스틱을 유지합니다. 샘플 토폴로지에는 LDP에서 세그먼트 라우팅으로 마이그레이션 중인 네트워크에 6개의 디바이스(R1~R6)가 있습니다.

토폴로지에서는 디바이스 R1, R2 및 R3이 세그먼트 라우팅 전용으로만 구성됩니다. 디바이스 R5 및 R6은 레거시 LDP 도메인의 일부이며 현재는 SR을 지원하지 않습니다. 디바이스 R4는 LDP와 세그먼트 라우팅 모두를 지원합니다. 모든 디바이스의 루프백 주소가 표시됩니다. 이러한 루프백은 LDP 도메인의 송신 FEC로, SR 도메인의 SR 노드 침입 탐지 서비스(IDS)로 보급됩니다. 상호 운용성은 LDP FEC을 SR 노드 ID로 매핑하는 것에 기반하며, 그 반대도 마찬가지입니다.

그림 22: LDP 운용 토폴로지로에 대한 샘플 세그먼트 라우팅LDP 운용 토폴로지로에 대한 샘플 세그먼트 라우팅

R1이 R6과 상호 작용하려면 LDP 세그먼트 라우팅 매핑 서버(SRMS) 및 세그먼트 라우팅 클라이언트(SRMC)가 모두 필요합니다. 트래픽 플로우를 단반향으로 보면 SRMS 및 SRMC의 역할을 쉽게 이해할 수 있습니다. 그림 22에 기초하여, 왼쪽에서 오른쪽으로 흐르는 트래픽이 SR 도메인에서 시작되며 LDP 도메인에서 종료된다고 합니다. 마찬가지로 오른쪽에서 왼쪽으로 흐르는 트래픽은 LDP 도메인 시작해 SR 도메인에서 종료됩니다.

SRMS는 트래픽을 왼쪽에서 오른쪽으로 연결하는 데 필요한 정보를 제공합니다. SRMC은 오른쪽에서 왼쪽으로 흐르는 트래픽에 대한 매핑을 제공합니다.

  • 왼쪽에서 오른쪽의 트래픽 플로우: 세그먼트 라우팅 매핑 서버

    SRMS는 SR 및 LDP 도메인 간의 LSP 연결을 용이하게 합니다. 서버는 LDP FECs을 SR 노드 침입 탐지 서비스(IDS)로 매핑합니다. [edit routing-options source-packet-routing]계층 수준 아래에 매핑되도록 LDP FECs를 구성합니다. 일반적으로 전체 연결을 위해 모든 LDP 노드 루프백 주소를 매핑해야 합니다. 아래 나와 있는 대로 단일 범위 문에서 연속한 접두사를 매핑할 수 있습니다. LDP 노드 루프백이 연속되지 않으면 여러 매핑 문을 정의해야 합니다.

    SRMS 매핑 구성을 [edit protocols ospf] 또는 [edit protocols isis] 계층 수준 아래에 적용합니다. 이 선택은 사용 중인 IGP에 따라 달라집니다. SR 및 LDP 노드 모두 공통, 단일 영역/수준, IGP 라우팅 도메인을 공유합니다.

    SRMS는 확장된 접두사 리스트 LSA(또는 ISIS의 경우 LSP)를 생성합니다. 이 LSA의 정보를 통해 SR 노드는 LDP 접두사(FEC)를 SR 노트 침입 탐지 서비스(IDS)에 매핑할 수 있습니다. LDP 접두사에 대한 매핑된 경로는 SR 노드의 inet.3mpls.0 라우팅 테이블에 설치되어 왼쪽에서 오른쪽으로의 트래픽에 대한 LSP 수신 및 연결 작업을 용이하게 합니다.

    확장된 LSA(또는 LSP)는 IGP(단일) 영역 전체에 걸쳐 플러딩됩니다. 즉, SRMS 구성을 SR 도메인의 모든 라우터에 자유롭게 배치가 가능합니다. SRMS 노드는 LDP를 실행할 필요가 없습니다.

  • 오른쪽에서 왼쪽으로의 트래픽 플로우: 세그먼트 라우팅 매핑 클라이언트

    오른쪽에서 왼쪽으로, 즉 LDP 아일랜드에서 SR 아일랜드로 상호 운용하려면 SR과 LDP를 모두 사용하는 노드에서 세그먼트 라우팅 클라이언트 기능을 활성화하기만 하면 됩니다. 예제에서는 R4입니다. [edit protocols ldp] 계층에서 mapping-client명령문을 사용하여 SRMC 기능을 활성화합니다.

    SRMC 구성은 자동으로 LDP 송신 정책을 활성화 해 SR 도메인의 노드 및 접두사 SIDs를 LDP 송신 FEC로 보급합니다. 이는 LDP 노드에 SR 도메인의 노드에 LSP 도달성을 제공합니다.

  • SRMC 기능은 SR 및 LSP 도메인에 모두 연결된 라우터에 구성되어야 합니다. 원한다면 동일한 노드가 SRMS로 작동할 수 있습니다.

LDP 상호 운용성에 대한 세그먼트 라우팅 최단 경로 우선(OSPF)을 사용

그림 22를 참조하여 디바이스 R2(세그먼트 라우팅 네트워크에서)가 SRMS라고 가정합니다.

  1. SRMS 기능 정의:

    이 구성을 통해 샘플 토폴로지에서의 두 LDP 디바이스 루프백 주소에 대한 매핑 블록을 생성합니다. R5의 루프백에 매핑된 초기 세그먼트 ID(SID) 인덱스는 1000입니다. 2 크기를 지정하면 SID 인덱스 10001이 R6의 루프백 주소에 매핑됩니다.

    주:

    start-prefix로 사용되는 IP 주소는, LDP 네트워크(이 예에서는 R5)에서 디바이스 루프백 주소입니다. 전체 연결을 위해서는 LDP 라우터의 모든 루프백 주소를 SR 도메인에 매핑해야 합니다. 루프백 주소가 연속된 경우, 단일 prefix-segment-range 문으로 이를 수행할 수 있습니다. 연속되지 않은 루프백에는 여러 접두사 매핑 문을 정의해야 합니다.

    예제에서는 연속적인 루프백을 사용하므로 단일 prefix-segment-range이(가) 위에 표시됩니다. 다음은 연속되지 않은 루브백 주소 지정을 사용하는 두 LDP 노드의 경우를 지원하기 위한 다중 매핑의 예입니다:

  2. 그런 다음, 매핑된 접두사를 플러딩하는 데 사용되는 확장된 LSA에 대한 OSPF 지원을 구성합니다.

    매핑 서버 구성이 디바이스 R2에서 커밋되면, 확장된 접두사 범위 TLV 가 최단 경로 우선(OSPF) 영역 전체에 플러딩됩니다. 세그먼트 라우팅이 가능한 디바이스(R1, R2, R3)는 지정된 루프백 주소(R5, R6)에 대해 세그먼트 ID(SID) 인덱스를 사용해 최단 경로 우선(OSPF) 세그먼트 라우팅 경로를 설치합니다. SID 인덱스는 또한 세그먼트 라우팅 장치에 의해 mpls.0라우팅 테이블에서 업데이트됩니다.

  3. SRMC 기능을 활성화합니다. 샘플 토폴로지의 경우, R4에서 SRMC 기능을 활성화해야 합니다.

    매핑 클라이언트 구성이 디바이스 R4에서 커밋 되면, SR 노드 IDs 및 레이블 블록이 송신 FEC로 라우터 R5에 보급되고 라우터 R5는 이를 R6에 다시 보급합니다.

Junos OS 19.1R1에서 최단 경로 우선(OSPF)를 통한 세그먼트 라우팅 연결 및 LDP 넥스트 홉에 대한 지원이 시작됩니다.

Unsupported Features and Functionality for Segment Routing interoperability with LDP using OSPF

  • 접두사 충돌은 SRMS에서만 감지됩니다. 접두사 범위 충돌이 있는 경우, 라우터 ID의 접두사 SID가 우선합니다. 이러한 경우, 시스템 로그 오류 메시지—RPD_OSPF_PFX_SID_RANGE_CONFLICT—가 생성됩니다.

  • IPv6 접두사는 지원되지 않습니다.

  • AS 경계(inter-AS)를 걸친 최단 경로 우선(OSPF) Extended Prefix Opaque LSA 플러딩은 지원되지 않습니다.

  • 영역 간 LDP 매핑 서버 기능은 지원되지 않습니다.

  • Extended Prefix Opaque LSA의 ABR 기능은 지원되지 않습니다.

  • Extended Prefix Opaque LSA의 ASBR 기능은 지원되지 않습니다.

  • 세그먼트 라우팅 매핑 서버 선호 TLV은 지원되지 않습니다.

ISIS를 사용한 세그먼트 라우팅과 LDP의 상호 운용성

그림 22를 참조하여 디바이스 R2(세그먼트 라우팅 네트워크에서)가 SRMS라고 가정합니다. 매핑 기능에 대해 다음과 같은 구성이 추가되었습니다:

  1. SRMS 기능 정의:

    이 구성을 통해 샘플 토폴로지에서의 두 LDP 디바이스 루프백 주소에 대한 매핑 블록을 생성합니다. R5의 루프백에 매핑된 초기 세그먼트 ID(SID) 인덱스는 1000입니다. 2 크기를 지정하면 SID 인덱스 10001이 R6의 루프백 주소에 매핑됩니다.

    주:

    start-prefix로 사용되는 IP 주소는, LDP 네트워크(이 예에서는 R5)에서 디바이스 루프백 주소입니다. 전체 연결을 위해서는 SR 도메인에 있는 LDP 라우터의 모든 루프백 주소를 매핑해야 합니다. 루프백 주소가 연속된 경우, prefix-segment-range문으로 이를 수행할 수 있습니다. 연속되지 않은 루프백에는 여러 매핑 문의 정의가 필요합니다.

    예제에서는 연속적인 루프백을 사용하므로 단일 prefix-segment-range이(가) 위에 표시됩니다. 다음은 연속되지 않은 루프백 주소 지정을 사용하는 두 LDP 라우터의 케이스를 처리하기 위한 접두사 매핑의 예입니다:

  2. 그런 다음, 매핑된 접두사를 플러딩하는 데 사용되는 확장된 LSP에 대한 ISIS 지원을 구성합니다.

    매핑 서버 구성이 디바이스 R2에서 커밋되면, 확장된 접두사 범위 TLV 가 최단 경로 우선(OSPF) 영역 전체에 플러딩됩니다. 세그먼트 라우팅이 가능한 디바이스(R1, R2, R3)는 지정된 루프백 주소(R5, R6)에 대해 세그먼트 ID(SID) 인덱스를 사용하여 ISIS 세그먼트 라우팅 경로를 설치합니다. SID 인덱스는 또한 세그먼트 라우팅 장치에 의해 mpls.0라우팅 테이블에서 업데이트됩니다.

  3. SRMC 기능을 활성화합니다. 샘플 토폴로지의 경우, R4에서 SRMC 기능을 활성화해야 합니다.

    매핑 클라이언트 구성이 디바이스 R4에 커밋되면 SR 노드 IDs 및 레이블 블록은 라우터 R5에 송신 FECs로, 그리고 거기서 라우터 R6로 보급됩니다.

ISIS를 통한 연결 세그먼트 라우팅 및 LDP 넥스트 홉을 위한 지원은 Junos OS 17.4R1에서 시작되었습니다.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

  • 레이블 바인딩 TLV에 대한 Penultiate-hop Popping 동작은 지원되지 않습니다.

  • 레이블 바인딩 TLV에서 접두사 범위의 보급은 지원되지 않습니다.

  • 세그먼트 라우팅 충돌 해결은 지원되지 않습니다.

  • LDP 트래픽 통계는 작동하지 않습니다.

  • NSR(Nonstop active routing) 및 GRES(Graceful 라우팅 엔진 switchover)은 지원되지 않습니다.

  • ISIS 레벨 간은 지원되지 않습니다.

  • RFC 7794, 확장 IPv4에 대한 IS-IS(Intermediate System to Intermediate System) 접두사 속성은 지원되지 않습니다.

  • 연결 노드에서 접두사 sid로 LDP 경로를 재배포하는 것은 지원되지 않습니다.

기타 LDP 속성

아래 섹션에서는 여러 기타 LDP 속성을 구성하는 방법에 대해 설명합니다.

IGP 라우팅 메트릭을 사용하도록 LDP 구성

기본 LDP 라우팅 메트릭(기본 LDP 라우팅 메트릭은 1) 대신 LDP 라우팅에 IGP(Interior Gateway Protocol) 라우팅 메트릭을 사용하려면 track-igp-metric 문을 사용합니다.

IGP 라우팅 메트릭을 사용하려면 track-igp-metric 문을 포함합니다.

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

inet.0 라우팅 테이블에 수신 경로가 추가되지 않도록 방지

no-forwarding 문을 구성하면 [edit protocols mpls] 또는 [edit logical-systems logical-system-name protocols mpls] 계층 수준에서 traffic-engineering bgp-igp 문을 활성화한 경우에도 inet.3 라우팅 테이블 대신 inet.0 라우팅 테이블에 수신 라우팅이 추가되는 것을 방지할 수 있습니다. 기본적으로 no-forwarding 문은 비활성화됩니다.

주:

ACX 시리즈 라우터는 [edit logical-systems] 계층 수준을 지원하지 않습니다.

inet.0 라우팅 테이블에서 수신 라우팅을 생략하려면 no-forwarding 문을 포함합니다.

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

다중 인스턴스 및 Carrier-of-Carriers VPN

여러 LDP 라우팅 인스턴스를 구성하면 LDP를 사용하여 서비스 프로바이더 PE 라우터에서 고객 통신사 CE 라우터로 carrier-of-carriers VPN의 레이블을 광고할 수 있습니다. 이는 통신사 고객이 기본 ISP(인터넷 서비스 프로바이더)이고 전체 인터넷 라우팅을 해당 PE 라우터로 제한하려는 경우에 특히 유용합니다. 통신사 고객은 BGP 대신 LDP를 사용하여 다른 내부 라우터를 인터넷으로부터 보호합니다. 또한 다중 인스턴스 LDP는 통신사 고객이 해당 고객에게 레이어 2 또는 레이어 3 VPN 서비스를 제공하려는 경우에도 유용합니다.

carrier-of-carriers VPN에 대해 다중 LDP 라우팅 인스턴스를 구성하는 방법에 대한 예는 LDP(Label Distribution Protocol)에 대한 다중 인스턴스 사용자 가이드를 참조하십시오.

Ultimate-Hop 라우터에서 레이블이 표시되도록 MPLS 및 LDP 구성

기본으로 광고되는 레이블은 레이블 3(Implicit Null 레이블)입니다. 레이블 3이 광고되면 Penultimate-Hop 라우터가 레이블을 제거하고 패킷을 송신 라우터로 보냅니다. UHP(Ultimate-Hop Popping)가 활성화되면 레이블 0(IPv4 Explicit Null 레이블)이 광고됩니다. UHP(Ultimate-Hop Popping)는 MPLS 네트워크를 트래버스하는 모든 패킷이 레이블을 포함하도록 합니다.

UHP(Ultimate-Hop Popping)를 구성하려면 explicit-null 문을 포함합니다.

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

주:

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

레이블에 대한 자세한 정보는 MPLS 레이블 개요MPLS 레이블 할당을 참조하십시오.

RSVP가 설정한 LSP에 대해 LDP 활성화

RSVP에 의해 설정된 LSP를 통해 LDP가 설정된 LSP를 효과적으로 터널링하여, RSVP로 설정한 LSP를 통해 LDP를 실행할 수 있습니다. 이를 위해서는 lo0.0 인터페이스에서 LDP를 활성화하십시오(LDP 활성화 및 비활성화 참조). 또한 [edit protocols mpls label-switched-path lsp-name] 계층 수준에서 ldp-tunneling 문을 포함하여 LDP가 작동할 LSP를 구성해야 합니다.

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

주:

LDP는 링크 보호가 활성화된 RSVP 세션을 통해 터널링될 수 있습니다. Junos OS 릴리스 21.1R1부터 LDP가 터널링한 경로에 대한 세부 정보를 표시할 때 기본 및 우회 LSP 다음 홉이 모두 나타납니다. 이전 릴리스의 Junos OS에서는 우회 LSP 다음 홉이 기본 LSP에 대한 다음 홉을 표시했습니다.

이기종 네트워크에서 RSVP가 설정한 LSP에 대해 LDP 활성화

일부 다른 벤더는 루프백 주소에 최단 경로 우선(OSPF) 메트릭 1을 사용합니다. 주니퍼 네트웍스 라우터는 루프백 주소에 대해 최단 경로 우선(OSPF) 메트릭 0을 사용합니다. 그러기 위해서는 이기종 네트워크에서 RSVP LSP를 통해 LDP 터널링을 배치할 때 RSVP 메트릭을 수동으로 구성해야 할 수 있습니다.

주니퍼 네트웍스 라우터가 RSVP 터널을 통해 다른 벤더의 라우터에 연결되고 있고 LDP 터널링 또한 활성화되어 있으면, 기본적으로 주니퍼 네트웍스 라우터는 RSVP 경로에 물리적 OSPF 경로보다 큰 메트릭 1이 있는 경우 RSVP 터널을 사용하여 다른 벤더 송신 라우터의 LDP 대상 다운스트림으로 트래픽을 라우팅하지 않을 수 있습니다.

이기종 네트워크에서 LDP 터널링 기능을 올바르게 사용하려면 ignore-lsp-metrics 문을 포함하여 RSVP LSP 메트릭을 무시하도록 최단 경로 우선(OSPF)을 구성할 수 있습니다.

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

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

주:

ACX 시리즈 라우터는 [edit logical-systems] 계층 수준을 지원하지 않습니다.

RSVP LSP를 통해 LDP를 활성화하려면 섹션 RSVP가 설정한 LSP에 대해 LDP 활성화의 절차를 완료해야 합니다.

LDP 세션에 대해 TCP MD5 서명 구성

스푸핑된 TCP 세그먼트가 LDP 세션 연결 스트림에 유입되는 것을 방지하기 위해 LDP TCP 연결에 MD5 시그니처를 구성할 수 있습니다. TCP 인증에 대한 보다 자세한 내용은 TCP를 참조해 주십시오. TCP MD5 대신 TCP 인증 옵션(TCP-AO)을 사용하는 방법은 No link title에서 확인할 수 있습니다.

MD5 시그니처 옵션을 사용하는 라우터는 인증이 필요한 각 피어에 대해 비밀번호를 사용하여 구성됩니다. 비밀번호는 암호화되어 저장됩니다.

LDP hello 인접 항목은 피어링 인터페이스가 다른 보안 서명으로 구성된 경우에도 생성할 수 있습니다. 그러나 TCP 세션을 인증할 수 없고 설정되지 않습니다.

LDP 세션에 대해 HMAC(Hashed Message Authentication Code) 및 MD5 인증을 구성할 때는 세션별 구성 또는 서브넷 일치(즉, 가장 긴 접두사 일치) 중에서 선택할 수 있습니다. 서브넷 일치 인증이 지원되면서 자동 대상 LDP(TLDP) 세션에 대한 인증을 보다 유연하게 구성할 수 있게 되었습니다. 이로 인해 LFA(Remote Loop-Free Alternate) 및 FEC 129 유사 회선을 구축하기가 훨씬 쉬워졌습니다.

LDP TCP 연결을 위해 MD5 서명을 구성하려면 다음과 같이 authentication-key 명령문을 세션 그룹의 일부에 포함하십시오.

session-group 문을 사용하여 LDP 세션의 원격 쪽으로 주소를 구성할 수 있습니다.

구성에서 md5-authentication-key 또는 비밀번호의 길이는 최대 69자까지 가능합니다. 문자는 모든 ASCII 문자열을 포함할 수 있습니다. 공백이 포함되어 있는 경우, 따옴표 안에 모든 문자를 입력합니다.

또한 LDP 라우팅 프로토콜에 대한 인증 키 업데이트 메커니즘을 구성할 수 있습니다. 이 메커니즘으로 OSPF(Open Shortest Path First), RSVP(Resource Reservation Setup Protocol)와 같은 관련 라우팅 및 신호 전송 프로토콜을 중단하지 않아도 인증 키를 업데이트할 수 있습니다.

인증 키 업데이트 메커니즘을 구성하려면 [edit security authentication-key-chains] 계층 수준에서 key-chain 문을 포함하고 key 옵션을 지정하여 여러 인증 키로 구성된 키 체인을 생성합니다.

LDP 라우팅 프로토콜에 대한 인증 키 업데이트 메커니즘을 구성하려면 [edit protocols ldp] 계층 수준에서 authentication-key-chain 문을 포함하여 프로토콜과 [edit security suthentication-key-chains] 인증 키를 연결합니다. 또한 [edit protocols ldp] 계층 수준에서 authentication-algorithm algorithm 문을 포함하여 인증 알고리즘을 구성할 수 있습니다.

인증 키 업데이트 기능에 대한 자세한 정보는 BGP 및 LDP 라우팅 프로토콜에 대한 인증 키 업데이트 메커니즘 구성을 참조하십시오.

LDP 세션 보호 구성

LDP 세션은 일반적으로 하나 이상의 링크에서 연결된 라우터 쌍 간에 생성됩니다. 라우터는 라우터를 연결하는 모든 링크에 대해 하나의 hello 인접 항목을 형성하고 모든 인접 항목을 해당 LDP 세션과 연결합니다. LDP 세션에 대한 마지막 hello 인접 항목이 사라지면 LDP 세션이 중단됩니다. 이 동작을 수정하여 LDP 세션이 불필요하게 종료되고 다시 설정되지 않도록 할 수 있습니다.

session-protection 문을 구성하여 두 라우터를 연결하는 링크에 hello 인접 항목이 없더라도 두 라우터 사이에 LDP 세션을 유지하도록 Junos OS를 구성할 수 있습니다. timeout 옵션을 사용하여 시간을 초 단위로 지정할 수 있습니다(선택 사항). 라우터가 IP 네트워크 연결을 유지하는 한 이 세션은 지정된 기간 동안 유지됩니다.

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

LDP에 대한 SNMP 트랩 비활성화

LDP LSP가 상단에서 하단으로, 또는 하단에서 상단으로 전환할 때마다 라우터는 SNMP 트랩을 보냅니다. 그러나 라우터, 논리적 시스템 또는 라우팅 인스턴스에서 LDP SNMP 트랩을 비활성화할 수 있습니다.

LDP SNMP 트랩과 독점 LDP MIB에 대한 정보는 SNMP MIB Explorer를 참조하십시오.

LSP에 대해 SNMP 트랩을 비활성화하려면 log-updown 문에 trap disable 옵션을 지정하십시오.

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

LDP 링크에서 IGP로 LDP 동기화 구성

LDP는 non-traffic-engineered 애플리케이션에서 레이블을 배포하기 위한 프로토콜입니다. 레이블은 IGP에서 확인한 최상의 경로를 따라 배포됩니다. LDP와 IGP 사이의 동기화가 유지되지 않으면 LSP가 중단됩니다. LDP가 주어진 링크에서 완전히 작동하지 않으면(세션이 설정되지 않고 레이블이 교환되지 않음) IGP는 최대 비용 메트릭으로 링크를 광고합니다. 링크는 선호되지 않지만 네트워크 토폴로지에 유지됩니다.

LDP 동기화는 활성 점대점 인터페이스와 IGP에서 점대점으로 구성된 LAN 인터페이스에서만 지원됩니다. LDP 동기화는 GR(Graceful Restart) 중에 지원되지 않습니다.

LDP가 동기화를 위해 작동할 때까지 최대 비용 메트릭을 광고하려면 ldp-synchronization 문을 포함합니다.

문을 비활성화하려면 disable 문을 포함합니다. 완전히 작동하지 않는 링크에 대해 최대 비용 메트릭을 광고하는 기간을 구성하려면 hold-time 문을 포함합니다.

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

라우터에서 IGP로 LDP 동기화 구성

LDP 이웃과 인터페이스에 대한 세션이 작동하는지 IGP에 알리기 전에 LDP가 대기하는 시간을 구성할 수 있습니다. FEC가 많은 대규모 네트워크의 경우, LDP 레이블 데이터베이스가 교환되도록 충분한 시간을 허용하기 위해 더 긴 값을 구성해야 할 수 있습니다.

LDP 이웃과 세션이 작동하는지 IGP에 알리기 전에 LDP가 대기하는 시간을 구성하려면 igp-synchronization 문을 포함하고 holddown-interval 옵션에 초 단위로 시간을 지정합니다.

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

레이블 철회 타이머 구성

레이블 철회 타이머는 FEC에 대한 레이블 철회 메시지를 이웃으로 보내는 것을 지연시킵니다. 이웃에 대한 IGP 링크가 실패하면 이웃이 FEC의 다음 홉인 경우 모든 업스트림 라우터에서 FEC와 관련된 레이블을 철회해야 합니다. IGP가 통합되고 새 다음 홉에서 레이블이 수신된 후에 레이블은 모든 업스트림 라우터에 다시 광고됩니다. 이것이 일반적인 네트워크 동작입니다. 레이블 철회를 약간의 시간만 지연하여(예: IGP가 통합되고 라우터가 다운스트림 다음 홉에서 FEC에 대한 새 레이블을 수신할 때까지) 레이블 철회와 레이블 매핑 전송을 피할 수 있습니다. label-withdrawal-delay 문으로 이 지연 시간을 구성할 수 있습니다. 기본적으로 지연은 60초입니다.

타이머가 만료되기 전에 라우터가 새 레이블을 수신하면 레이블 철회 타이머가 취소됩니다. 그러나 타이머가 만료되면 FEC에 대한 레이블이 모든 업스트림 라우터에서 철회됩니다.

기본적으로 LDP는 IGP가 재통합되는 동안 LSP를 여러 번 신호로 보내는 것을 방지하기 위해 레이블이 철회되기 전에 60초 간 대기합니다. 레이블 철회 지연 시간을 초 단위로 구성하려면 label-withdrawal-delay 문을 포함합니다.

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

LDP 서브넷 체크 무시

Junos OS 릴리스 8.4 이후부터 이웃 설정 프로시저 중에 LDP 소스 주소 서브넷 체크가 수행됩니다. LDP 링크 hello 패킷의 소스 주소는 인터페이스 주소와 일치합니다. 이로 인해 일부 다른 벤더의 장비와 상호 운용성 문제가 발생합니다.

서브넷 체크를 비활성화하려면 allow-subnet-mismatch 문을 포함합니다.

이 문은 다음 계층 수준에서 포함될 수 있습니다.

  • [edit protocols ldp interface interface-name]

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

주:

ACX 시리즈 라우터는 [edit logical-systems] 계층 수준을 지원하지 않습니다.

LDP LSP 트레이스라우트 구성

경로를 추적한 다음 LDP 신호 LSP를 추적할 수 있습니다. LDP LSP 트레이스라우트는 RFC 4379, MPLS(Multi-Protocol Label Switched) 데이터 플레인 오류 감지를 기반으로 합니다. 이 기능을 통해 FEC의 모든 경로를 주기적으로 추적할 수 있습니다. FEC 토폴로지 정보는 CLI에서 접근할 수 있는 데이터베이스에 저장됩니다.

토폴로지 변경을 통해 LDP LSP의 추적을 자동으로 트리거 할 수 없습니다. 하지만 트레이서라우트를 수동으로 시작할 있습니다. 데이터베이스에 현재 존재하는 FEC에 대한 트레이스라우트 요청이 있는 경우, 데이터베이스의 내용은 결과로 업데이트됩니다.

모든 FEC에 적용되는 주기적 트레이스라우트 기능은 [edit protocols ldp]계층형 레벨로 구성된 oam명령문에 따라 지정됩니다. 주기적인 LDP LSP 트레이스라우트 구성을 위해, periodic-traceroute명령문을 포함합니다:

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

periodic-traceroute명령문을 단독 구성하거나 다음 옵션 중 하나에 따라 구성할 수 있습니다:

  • exp: 프로브 발송 시 서비스 등급을 지정합니다.

  • fanout: 노드당 검색할 최대 다음 홉의 수를 지정합니다.

  • frequency: 트레이스라우트 시도 간의 interval을 지정합니다.

  • paths: 검색할 최대 경로 수를 지정합니다.

  • retries: 종료 전, 프로브에서 특정 노드로 발송하려는 시도 수를 지정합니다.

  • source: 프로브 발송 시 IPv4 소스 주소를 지정합니다.

  • ttl: 최대 유지 시간 값을 지정합니다. 이 값을 넘는 노드들은 추적되지 않습니다.

  • wait: 프로브 패킷을 다시 발송 하기 전에 대기 interval을 지정합니다.

LDP 통계 수집

LDP 트래픽 통계는 라우터의 특정 FEC를 통과하는 트래픽 양을 보여줍니다.

[edit protocols ldp] 계층 수준에서 traffic-statistics문을 구성하면 LDP 트래픽 통계가 정기적으로 수집되어 파일에 작성됩니다. interval 옵션을 사용하여 통계 수집 빈도(초당)를 구성할 수 있습니다. 기본 수집 간격은 5분입니다. LDP 통계 파일을 구성해야 합니다. 그렇지 않으면 LDP 트래픽 통계가 수집되지 않습니다. LSP가 감소하면 LDP 통계가 재설정됩니다.

LDP 트래픽 통계를 수집하려면 traffic-statistics문을 포함합니다.

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

이 섹션은 다음 주제를 포함합니다.

LDP 통계 출력

다음 샘플 출력은 LDP 통계 파일에서 나옵니다.

LDP 통계 파일에는 다음 데이터 열이 포함됩니다.

  • FEC—LDP 트래픽 통계가 수집되는 FEC입니다.

  • Type—라우터로부터의 트래픽 유형으로, Ingress(이 라우터에서 전송됨) 또는 Transit(이 라우터를 통해 전달됨) 중 하나에 해당합니다.

  • Packets—LSP가 등장한 이후 FEC에서 통과한 패킷 수입니다.

  • Bytes—LSP가 등장한 이후 FEC에서 통과한 데이터 바이트수입니다.

  • SharedYes 값으로, 여러 접두사에 동일한 레이블(예를 들어 전송 정책으로 보급된 여러 접두사가 있을 때)이 지정되었음을 나타냅니다. 이 케이스에 대한 LDP 트래픽 통계는 모든 접두사에 적용되며 그렇게 처리되어야 합니다.

  • read—이 숫자(날짜 및 시간 옆에 표시됨)는 표시된 통계의 실제 숫자와 다를 수 있습니다. 통계 중 일부는 표시되기 전 요약됩니다.

PH(Penultimate-Hop) 라우터에서 LDP 통계 비활성화하기

PH(Penultimate-Hop) 라우터에서 LDP 트래픽 통계를 수집하면 특정 다음 홉 경로에서 과도한 시스템 리소스를 소비할 수 있습니다. 이 문제는 deaggregate문과 traffic-statistics 문을 함께 구성한 경우 더욱 심각해집니다. 다음 홉 경로 사용 한계에 도달한 라우터의 경우 traffic-statistics문에 대해 no-penultimate-hop 옵션을 구성하는 것이 좋습니다.

traffic-statistics 문을 구성할 수 있는 계층 수준 목록의 경우 이 문에 대한 문 요약 섹션을 참조하십시오.

주:

no-penultimate-hop 옵션을 구성하면 이 라우터의 PH(Penultimate-Hop)인 FEC에 대해 통계를 사용할 수 없습니다.

구성에서 이 옵션을 포함하거나 제거하면 LDP 세션이 중단된 다음 다시 시작됩니다.

다음 샘플 출력은 no-penultimate-hop 옵션이 구성된 라우터를 표시하는 LDP 통계 파일에서 가져온 것입니다.

LDP 통계 한계

다음은 traffic-statistics문을 구성하여 LDP 통계를 수집하는 것과 관련된 문제입니다.

  • LDP 통계를 지울 수 없습니다.

  • 지정된 간격을 줄이려면 새로운 LDP 통계 요청을 해야 합니다. 단 이때 통계 타이머는 새 간격보다 더 늦게 만료되어야 합니다.

  • 새로운 LDP 통계 수집 작업은 이전 작업이 완료될 때까지 시작할 수 없습니다. 간격이 짧거나 LDP 통계 수가 크면 두 통계 수집 간 시간 격차가 간격보다 더 클 수 있습니다.

LSP가 감소하면 LDP 통계가 재설정됩니다.

LDP 프로토콜 트래픽 추적

다음 섹션은 LDP 프로토콜 트래픽을 검사하기 위해 trace 옵션을 구성하는 방법에 대해 설명합니다.

프로토콜 및 라우팅 인스턴스 수준에서 LDP 프로토콜 트래픽 추적

LDP 프로토콜 트래픽을 추적하려면 [edit routing-options] 계층 수준에서 전역 traceoptions 문에 옵션을 지정하고 traceoptions 문을 포함하여 LDP 특정 옵션을 지정할 수 있습니다.

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

file 문을 사용하여 tracing 연산의 출력을 수신하는 파일 이름을 지정할 수 있습니다. 모든 파일은 /var/log 디렉터리에 배치됩니다. LDP-tracing 출력을 ldp-log 파일에 배치하는 것을 권장합니다.

다음 추적 플래그는 다양한 LDP 메시지 송수신과 관련된 작업을 표시합니다. 각각은 다음 한정자 중 하나 이상을 전달할 수 있습니다.

  • address—주소 및 주소 회수 메시지 작업을 추적합니다.

  • binding—label-binding 작업을 추적합니다.

  • error—오류 조건을 추적합니다.

  • event—프로토콜 이벤트를 추적합니다.

  • initialization—초기화 메시지 작업을 추적합니다.

  • label—레이블 요청, 레이블 매핑, 레이블 회수, 레이블 릴리스 메시지 작업을 추적합니다.

  • notification—알림 메시지 작업을 추적합니다.

  • packets—주소, 주소 철회, 초기화, 레이블 요청, 레이블 맵, 레이블 회수, 레이블 릴리스, 알림, 주기적 메시지 작업을 추적합니다. 이 수정자는 address, initialization, label, notification, periodic 수정자를 설정하는 것과 같습니다.

    또한 packets 플래그에 대한 match-on address 하위 옵션을 사용하여 filter 플래그 수정자를 구성할 수도 있습니다. 이를 통해 패킷의 소스 및 대상 주소를 기반으로 추적할 수 있습니다.

  • path—레이블 스위칭 경로(LSP) 작업을 추적합니다.

  • path—레이블 스위칭 경로(LSP) 작업을 추적합니다.

  • periodic—hello 및 keepalive 메시지 작업을 추적합니다.

  • route—경로 메시지 작업을 추적합니다.

  • state—프로토콜 상태 전환을 추적합니다.

FEC 내에서 LDP 프로토콜 트래픽 추적

LDP는 FEC(포워딩 동급 클래스)를 생성하는 각 LSP와 연결합니다. LSP와 연관된 FEC는 어떤 패킷이 해당 LSP에 매핑되는지 지정합니다. LSP는 각 라우터가 FEC의 다음 홉으로 광고된 레이블을 선택하고 다른 모든 라우터에 광고하는 레이블에 연결할 때 네트워크를 통해 확장됩니다.

특정 FEC 내에서 LDP 프로토콜 트래픽을 추적하고 FEC에 기반한 LCD 추적 문을 필터링할 수 있습니다. 이는 FEC와 연결된 LDP 프로토콜 트래픽을 추적하거나 해결하려는 경우 유용합니다. 다음 추적 플래그는 route, path, binding 목적으로 사용할 수 있습니다.

다음 예는 FEC를 기반으로 LCD 추적 문을 필터링하도록 LDP traceoptions 문을 구성하는 방법을 보여줍니다.

이 기능은 다음과 같은 한계가 있습니다.

  • 필터링 기능은 IP 버전 4(IPv4) 접두사로 구성된 FEC에서만 사용할 수 있습니다.

  • 레이어 2 서킷 FEC는 필터링할 수 없습니다.

  • 경로 추적 및 필터링 모두를 구성하면 MPLS 경로가 표시되지 않습니다(필터에 의해 차단됨).

  • 필터링은 정책과 match-on 옵션에 대해 구성된 값에 따라 결정됩니다. 정책을 구성할 때 기본 동작이 항상 reject인지 확인하십시오.

  • 유일한 match-on 옵션은 fec입니다. 결과적으로, 포함해야 할 유일한 정책 유형은 route-filter 정책입니다.

예: LDP 프로토콜 트래픽 추적

LDP 경로 메시지를 상세하게 추적:

나가는 모든 LDP 메시지를 추적:

모든 LDP 오류 조건을 추적:

유입되는 모든 LDP 메시지와 모든 label-binding 작업을 추적:

LSP와 관련된 FEC에 대한 LDP 프로토콜 트래픽 추적:

변경 내역 표

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

릴리스
설명
22.4R1
Junos OS Evolved 릴리스 22.4R1부터 IP 서브넷으로 TCP-AO 또는 TCP MD5 인증을 구성하여 해당 서브넷에 속한 전체 주소 범위를 포함할 수 있습니다.
22.4R1
Junos OS Evolved 릴리스 22.4R1부터 TCP 인증이 VRF를 인식합니다.
19.1
Junos OS 릴리스 19.1R1부터 세그먼트 라우팅 LDP 경계 라우터는 세그먼트 라우팅 트래픽을 LDP 넥스트 홉으로 연결하거나 그 반대로 연결할 수 있습니다.
16.1
Junos OS 릴리스 16.1부터 M-LDP는 루트 주소가 MPLS LSP를 통해 재귀적으로 추가로 확인되는 BGP 경로인 경우 ASBR 또는 전송 또는 송신에서 point-to-multipoint LSP에 신호를 보낼 수 있습니다.
14.1
Junos OS 릴리스 14.1부터 기존 IPTV 서비스를 네이티브 IP 멀티캐스트에서 MPLS 멀티캐스트로 마이그레이션하려면 중단을 최소화하면서 PIM에서 M-LDP 포인트 투 멀티포인트 LSP로 원활하게 전환해야 합니다.