Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지에서
 

LDP 구성

최소 LDP 구성

최소 구성으로 LDP를 활성화하려면:

  1. 패밀리 네트워크에서 모든 관련 MPLS. LDP로 연결되는 경우, 루프백 인터페이스는 family MPLS.

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

  3. 단일 인터페이스에서 LDP를 활성화하고, 명령문을 포함하며, 명령문을 사용하여 인터페이스를 ldpinterface 지정합니다.

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

모든 인터페이스에서 LDP를 활성화하려면 allinterface-name 를 지정합니다.

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

LDP 활성화 및 비가시

LDP는 라우팅 인스턴스 인식입니다. 특정 인터페이스에서 LDP를 활성화하려면 다음 명령문을 포함합니다.

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

모든 인터페이스에서 LDP를 활성화하려면 allinterface-name 를 지정합니다.

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

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

Hello 메시지를 위한 LDP Timer 구성

LDP hello 메시지를 통해 LDP 노드가 다른 노드를 검색하고 이웃 또는 이웃 링크의 장애를 탐지할 수 있습니다. 안녕하세요 메시지는 LDP가 활성화되는 모든 인터페이스에서 주기적으로 전송됩니다.

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

  • 링크 hello 메시지—LDP 검색 포트로 주소가 UDP 패킷으로 LDP 인터페이스를 통해 전송됩니다. 인터페이스에서 LDP 링크 안녕하세요 메시지를 수신하면 LDP 피어 라우터와 인접한 것이 식별됩니다.

  • 대상 안녕하세요 메시지—특정 주소에서 LDP 검색 포트로 주소가 지정되는 UDP 패킷으로 전송. 대상 안녕하세요 메시지는 직접 연결되지 않은 라우터 간에 LDP 세션을 지원하는 데 사용됩니다. 대상 라우터는 대상에 대한 Hello 메시지를 무시할지 여부를 확인합니다. 응답을 선택한 대상 라우터는 대상 hello 메시지를 주기적으로 시작 라우터로 다시 전송합니다.

기본적으로 LDP는 링크 Hello 메시지에 대해 5초마다 안녕하세요 메시지를, 대상에 지정된 Hello 메시지에는 15초마다 안녕하세요 메시지를 전송합니다. LDP 타임러를 구성하여 두 유형의 hello 메시지 전송 시간을 변경할 수 있습니다. 그러나 LDP 보유 시간보다 큰 LDP 타임을 구성할 수는 없습니다. 자세한 내용은 LDP Neighbor를고려하기 전에 지연 구성을 참조하십시오.

링크 Hello 메시지를 위한 LDP Timer 구성

LDP가 링크 hello 메시지를 얼마나 자주 전송하는지 수정하려면, 명령문을 사용하여 LDP 타임러에 대한 새로운 링크 hello 메시지 간격을 hello-interval 지정합니다.

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

Targeted Hello 메시지를 위한 LDP Timer 구성

LDP가 대상 hello 메시지를 얼마나 자주 전송하는지 수정하려면, 명령문을 명령문에 대한 옵션으로 구성하여 LDP timer에 대한 새로운 대상 hello 메시지 간격을 hello-intervaltargeted-hello 지정합니다.

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

LDP Neighbor가 다운되기 전에 지연 구성

대기 시간은 LDP 노드가 이웃(neighbor)을 다운(down)한다고 선언하기 전에 Hello 메시지를 기다릴 시간을 결정합니다. 이 값은 hello 메시지의 일부로 전송될 수 있으므로 각 LDP 노드가 이웃에 얼마나 오래 기다려야 하는지 알 수 있습니다. 각 이웃에 의해 전송된 값과 일치할 수 없습니다.

보류 시간은 일반적으로 hello 간격의 최소 3배입니다. 기본 설정은 링크 안녕하세요 메시지의 경우 15초, 대상을 정하는 hello 메시지에는 45초입니다. 그러나 hello 간격에 대한 값에 근접한 LDP 보유 시간을 구성할 수 있습니다.

주:

LDP가 hello 간격에 가까우며(hello 간격의 3배 미만)를 보유한 시간을 구성하여 LDP neighbor 장애를 보다 신속하게 탐지할 수 있습니다. 그러나 라우터가 여전히 정상 작동 중인 LDP neighbor를 다운(lDP neighbor)으로 선언할 수도 있는 가능성도 증가합니다. 자세한 내용은 Hello Messages를 위한 LDP Timer 구성을 참조하십시오.

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

로컬 LDP 보유 시간이 LDP 피어 협상 중에 단축되지 않는 경우 사용자 구성의 Keepalive 간격은 변경되지 않습니다. 그러나 피어 협상 중에 로컬 홀드 시간이 줄어들면 keepalive 간격이 다시 계산됩니다. 만약 LDP 보유 시간이 피어 협상 중에 감소된 경우, 유지 간격은 새로운 홀드 시간 값의 13분의 1로 감소됩니다. 예를 들어, 새로운 홀드타임 값이 45초인 경우 Keepalive 간격은 15초로 설정됩니다.

이렇게 자동화된 유지 간격 계산은 각 피어 라우터에서 서로 다른 Keepalive 간격을 구성할 수 있습니다. 따라서 LDP 피어 협상에서 LDP 보유 시간보다 더 자주 전송되도록 보장하기 때문에 이 라우터는 KEEPALIVE 메시지를 얼마나 자주 전송하는지 유연하게 유지할 수 있습니다.

홀드 타임 간격을 재구성하는 경우 세션이 재설정될 때까지 변경 사항이 영향을 미치지 않습니다. 보류 시간은 LDP 피어링 세션이 시작될 때 협상되고 세션이 설정되는 한 재협상할 수 없습니다(RFC 5036, LDP 사양에서요구). LDP 세션을 수동으로 재설정하려면 명령을 clear ldp session 실행하십시오.

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

LDP 노드가 neighbor를 선언하기 전에 링크 Hello 메시지를 기다릴 수 있는 시간을 수정하려면 다음 명령문을 사용하여 몇 초 만에 새 시간을 hold-time 지정합니다.

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

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

LDP 노드가 이웃을 선언하기 전에 대상 hello 메시지를 기다려야 하는 시간을 수정하려면 명령문을 명령문에 대한 옵션으로 사용하여 몇 초 만에 새 시간을 hold-timetargeted-hello 지정합니다.

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

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

엄격한 대상 지정 hello 메시지를 사용하여 LDP 세션이 특별히 구성되지 않은 원격 이웃에 설정되지 못하도록 방지합니다. 명령문을 구성하는 경우, LDP 피어는 구성된 원격 이웃 중 하나인 소스에서 오는 대상 hello 메시지에 응답하지 strict-targeted-hellos 않습니다. 구성된 원격 이웃은 다음을 포함할 수 있습니다.

  • LDP 터널이 구성된 RSVP 터널의 엔드포인트

  • 레이어 2 서킷 이웃

구성되지 않은 이웃이 hello 메시지를 보내는 경우, LDP 피어는 메시지를 무시하고 소스를 나타내는 error 오류(trace 플래그와 함께)를 기록합니다. 예를 들어, LDP 피어가 인터넷 주소 10.0.0.1에서 targeted hello를 받았고 이 주소가 특별히 구성된 이웃이 없는 경우, 다음 메시지가 LDP 로그 파일에 인쇄됩니다.

엄격한 대상 안녕하세요 메시지를 활성화하려면 다음 strict-targeted-hellos 진술을 포함합니다.

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

LDP Keepalive 메시지의 간격 구성

Keepalive 간격은 세션을 통해 메시지가 얼마나 자주 전송되는지 결정하여 Keepalive 타임아웃이 초과되지 않도록 보장합니다. 많은 시간 동안 다른 LDP 트래픽이 세션을 통해 전송되지 않는다면, Keepalive 메시지가 전송됩니다. 기본 설정은 10초입니다. 최소 값은 1초입니다.

피어 라우터의 LDP 보유 시간을 위해 구성된 값이 로컬로 구성된 값보다 낮은 경우, 유지 간격에 대해 구성된 값은 LDP 세션 협상 중에 변경할 수 있습니다. 자세한 내용은 LDP Neighbor를고려하기 전에 지연 구성을 참조하십시오.

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

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

LDP Keepalive Timeout 구성

LDP 세션이 설정되면 세션이 계속 작동하도록 메시지를 주기적으로 교환해야 합니다. keepalive 타임아웃은 인접 LDP 노드가 세션에 실패했다고 결정하기 전에 기다리는 시간을 정의합니다. 이 값은 일반적으로 keepalive 간격의 최소 3배로 설정됩니다. 기본 설정은 30초입니다.

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

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

명령문에 대해 구성된 값은 명령어를 발행할 때 보유 keepalive-timeout 시간으로 show ldp session detail 표시됩니다.

LDP에 가장 긴 일치 구성

LDP가 도메인 간 영역 또는 ISIS 최단 경로 우선(OSPF) 통합되거나 요약된 경로를 학습할 수 있도록 Junos OS RFC5283에기반하여 LDP에 대한 가장 긴 일치 경로를 구성할 수 있습니다.

LDP에 대해 가장 긴 일치를 구성하려면 다음을 해야 합니다.

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

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

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

LDP에 가장 긴 일치를 구성하려면 다음을 해야 합니다.

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

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

예를 들면 다음과 같습니다. LDP에 가장 긴 일치 구성

이 예에서는 RFC5283에기반하여 LDP에 대한 가장 긴 일치를 구성하는 방법을 보여줍니다. 이를 통해 LDP는 도메인 간 최단 경로 우선(OSPF) 전체에서 통합되거나 요약된 경로를 학습할 수 있습니다. 가장 긴 일치 정책은 Prefix 세분화에 따라 제공합니다.

요구 사항

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

  • 프로토콜이 최단 경로 우선(OSPF) 6대의 MX 시리즈 라우터와 연결된 인터페이스 상에서 LDP가 지원됩니다.

  • Junos OS Release 16.1 이상이 모든 장치에서 실행됩니다.

시작하기 전에 다음을 할 수 있습니다.

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

  • 구성 최단 경로 우선(OSPF).

개요

LDP는 종종 MPLS 또는 LSP와 같은 네트워크를 사용하는 전체 네트워크 도메인에서 LSP(label-switched path)를 IGP 사용하는 최단 경로 우선(OSPF) IS-IS(Intermediate System to Intermediate System). 이러한 네트워크에서 도메인의 모든 링크는 LDP IGP 인접해 있습니다. LDP는 IP 포링에 따라 목적지로 가는 최단 경로에 LSP를 구축합니다. 이러한 Junos OS 경우, LDP 구현은 RIB의 FEC IP 주소에 대한 정확한 일치 룩업을 실행하거나 레이블 매핑을 위한 IGP 경로에 대해 정확한 일치 룩업을 실행합니다. 이러한 매핑을 위해서는 MPLS 전체 LDP 엔드포인트 IP 주소를 모든 LE에서 구성해야 합니다. 이는 액세스 디바이스의 IP 계층 설계 또는 기본 라우팅의 목적을 갖지 못합니다. Configuring은 가장 긴 연결 경로(pre-prefix 기준)를 기준으로 정확한 일치 동작을 억제하고 LSP를 설정하여 이러한 문제를 longest-match 극복하는 데 도움이 됩니다.

토폴로지

토폴로지에서 LDP에 대한 가장 긴 일치가 Device R0에 구성되어 있는 그림 1 것으로 나타났습니다.

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

구성

CLI 빠른 구성

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

R0

R1

R2

R3

R4

R5

디바이스 R0 구성

단계별 절차

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

Device R0을 구성하려면:

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

  2. 루프백 주소를 장비에 할당합니다.

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

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

  5. 인터페이스에서 최단 경로 우선(OSPF) 프로토콜을 구성합니다.

  6. LDP 프로토콜에 대한 가장 긴 일치 구성

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

결과

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

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

확인

구성이 제대로 작동하고 있는지 확인합니다.

경로 검증

목적

예상되는 경로가 학습된지 확인

실행

Device R0에서 작동 모드에서 라우팅 테이블에 경로를 표시하기 위해 명령을 show route 실행합니다.

의미

출력은 Device R0의 라우팅 테이블에 있는 모든 경로를 보여줍니다.

LDP 검증 개요 정보

목적

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

실행

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

의미

출력은 Device R0의 LDP 개요 정보를 표시

내부 토폴로지 테이블에서 LDP 엔트리 확인

목적

LDP(Label Distribution Protocol) 내부 토폴로지 테이블에 경로 엔트리를 표시합니다.

실행

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

의미

출력은 Device R0의 LDP(Label Distribution Protocol) 내부 토폴로지 테이블에서 라우트 엔트리를 표시합니다.

LDP 경로의 FEC 정보만 검증

목적

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

실행

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

의미

출력은 Device R0에서 사용할 수 있는 LDP 프로토콜의 FEC 경로만 표시합니다.

LDP의 FEC 및 쉐도우 경로 검증

목적

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

실행

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

의미

출력은 FEC와 Device R0의 쉐도우 경로를 표시하며

LDP 경로 기본 설정 구성

여러 프로토콜이 동일한 대상에 대한 경로를 계산할 때 라우팅 기본 설정이 포우링 테이블에 설치된 경로를 선택하는 데 사용됩니다. 최저 기본 설정값이 있는 경로가 선택됩니다. 기본 설정값은 범위 0에서 255까지의 수입니다. 기본적으로 LDP 경로의 기본 설정값은 9입니다.

경로 기본 설정을 수정하려면 다음 preference 문을 포함하십시오.

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

LDP Graceful Restart

LDP graceful restart를 통해 LDP 컨트롤 플레인이 재시작되는 라우터가 트래픽을 계속 포우링하는 동시에 이웃 라우터에서 상태를 복구할 수 있습니다. 또한 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를 비활성화할 수 있습니다. 글로벌 수준에서는 기본적으로 LDP graceful restart가 비활성화됩니다. 그 이유는 글로벌 수준에서는 기본적으로 graceful restart가 비활성화됩니다. 그러나, 도우미 모드(graceful restart를 시도하는 이웃 라우터를 지원할 수 있는 능력)는 기본적으로 활성화됩니다.

다음은 LDP graceful restart와 관련된 몇 가지 동작입니다.

  • Outgoing Label은 재시작 시 유지되지 않습니다. 새로운 Outgoing Label이 할당됩니다.

  • 라우터가 재시작되면, label-map 메시지가 다시 시작될 때까지 graceful restart를 지원하는 이웃으로 전송되지 않습니다(Label-map 메시지는 Graceful Restart를 지원하지 않는 이웃으로 즉시 전송됩니다). 그러나 다른 모든 메시지(keepalive, 주소 메시지, 통보 및 릴리스)는 평상시와 같이 전송됩니다. 이러한 다른 메시지를 배포하면 라우터가 불완전한 정보를 배포하지 못합니다.

  • 도우미 모드 및 graceful restart는 독립적입니다. 구성에서 graceful restart를 비활성화할 수 있지만, 라우터가 graceful 다시 시작을 시도하는 이웃과 협력할 수 있도록 허용합니다.

LDP Graceful Restart 구성

또는 계층 수준에서 graceful restart 구성을 변경하면 실행 중인 LDP 세션이 자동으로 재시작되어 Graceful Restart 구성을 [edit routing-options graceful-restart][edit protocols ldp graceful-restart] 적용합니다. 이 동작은 graceful restart 구성을 변경하면 BGP(Border Gateway Protocol) 네트워크의 동작을 미러링합니다.

기본적으로 graceful restart 도우미 모드가 활성화되지만 Graceful Restart가 비활성화됩니다. 따라서 라우터의 기본 동작은 graceful restart를 시도하지만 Graceful Restart 자체를 시도하지 않는 이웃 라우터를 보조하는 것입니다.

LDP graceful restart를 구성하려면 다음 섹션을 참조하십시오.

Graceful Restart 활성화

LDP graceful restart를 활성화하려면 라우터에서 graceful restart를 활성화해야 합니다. 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 graceful restart가 실행됩니다. graceful restart에 대한 자세한 내용은 라우팅 디바이스를 위한 Junos OS 라우팅 프로토콜 라이브러리 를 참조하십시오.

기본적으로 LDP 프로토콜 수준과 모든 라우팅 인스턴스에서 Graceful Restart를 활성화하면 LDP graceful restart가 활성화됩니다. 그러나 LDP graceful restart와 LDP graceful restart 도우미 모드를 모두 비활성화할 수 있습니다.

LDP Graceful Restart 또는 Helper 모드 비가동

LDP graceful restart 및 복구를 비활성화하려면 다음을 disable 포함합니다.

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

LDP 프로토콜 수준에서만 도우미 모드를 비활성화할 수 있습니다. 특정 라우팅 인스턴스에 대해 helper 모드를 비활성화할 수 없습니다. LDP 도우미 모드를 비활성화하기 위해 다음 문을 helper-disable 포함하십시오.

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

다음과 같은 LDP graceful restart 구성이 가능합니다.

  • LDP graceful restart와 도우미 모드가 모두 활성화됩니다.

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

  • LDP graceful restart 및 도우미 모드는 모두 비활성화됩니다. 라우터는 LDP graceful restart 또는 초기화 메시지에 전송된 TLV(graceful restart) 유형, 길이 및 값(TLV)을 사용하지 않습니다. 라우터는 LDP graceful restart를 지원할 수 없는 라우터로 실행됩니다.

graceful restart를 활성화하고 helper 모드를 비활성화하려고 시도하면 구성 오류가 발행됩니다.

재연결 시간 구성

이웃 간의 LDP 연결에 장애가 발생하면 이웃은 Graceful Restart 라우터가 LDP 메시지 전송을 재개할 때까지 일정한 시간을 기다려야 합니다. 대기 기간이 지난 후 LDP 세션을 재구성할 수 있습니다. 몇 초 만에 대기 기간을 구성할 수 있습니다. 이 값은 LDP graceful restart를 활성화할 때 LDP 초기화 메시지로 전송되는 폴트 에지(fault tolerant) 세션 TLV에 포함됩니다.

라우터 A 및 라우터 B가 LDP 이웃인 것으로 가정해보죠. Router A는 재시작 라우터입니다. 재연결 시간은 라우터 A가 Router B에 라우터 A가 재시작된 지 탐지한 후 기다릴 때입니다.

재연결 시간을 구성하기 위해 다음 reconnect-time 진술을 포함합니다.

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

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

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

복구 시간은 라우터가 LDP가 Graceful Restart될 때까지 기다리는 시간입니다. 복구 기간은 초기화 메시지가 전송 또는 수신될 때 시작됩니다. 이 기간은 일반적으로 이웃 라우터가 재시작 라우터에 대한 정보를 유지하여 트래픽을 지속적으로 전달하는 데 필요한 시간입니다.

재시작 라우터에서 복구 시간 동안 잘못된 값을 수신할 경우 이웃 라우터가 악영향을 받지 않도록, 인접 라우터에서 최대 복구 시간을 구성할 수 있습니다. 이웃 라우터는 두 번의 짧은 시간으로 상태를 유지 관리합니다. 예를 들어, 라우터 A는 LDP Graceful Restart를 실행합니다. 인접한 라우터 B로 900초의 복구 시간을 보냈다. 라우터 B의 최대 복구 시간은 400초입니다. 라우터 B는 라우터 A에서 LDP 정보를 제거하기 전에 400초 동안만 기다려야 합니다.

복구 시간을 구성하기 위해 명령문과 recovery-time 명령문을 maximum-neighbor-recovery-time 포함합니다.

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

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

수신 LDP 레이블 바인딩을 필터링하여 이웃 라우터에서 광고하는 바인딩을 허용하거나 거부할 수 있습니다. 수신 레이블 필터링을 구성하기 위해 다음 import 진술을 포함합니다.

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

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

표 1: LDP 수신 레이블 필터링에 적용하는 운영자로부터

from Operator

설명

interface

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

neighbor

지정된 LDP 라우터 ID에서 수신된 바인딩과 일치

next-hop

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

route-filter

지정된 Prefix와 바인딩 일치

바인딩이 필터링된 경우 여전히 LDP 데이터베이스에 나타나지만 LSP(Label-Switched Path)의 일부로 설치하는 것으로 간주되지 않습니다.

일반적으로, LDP에 정책을 적용하는 것은 라우팅을 제어하지 않는 LSP의 구축을 차단하는 데만 사용할 수 있습니다. 이는 LSP가 따르는 경로가 LDP가 아닌 유니캐스트 라우팅에 따라 결정됩니다. 그러나 서로 다른 이웃을 통해 대상에 대한 다중 동등한 비용 경로가 있는 경우 LDP 필터링을 사용하여 가능한 다음 홉 중 일부를 고려할 때 제외할 수 있습니다. (그렇지 않은 경우, LDP는 가능한 다음 홉 중 하나를 임의로 선택합니다.)

LDP 세션은 인터페이스 또는 인터페이스 주소에 연계되지 않습니다. LDP는 라우터당(인터페이스당이 아 아) 레이블만 광고합니다. 따라서 두 라우터 간에 다중 병렬 링크가 있는 경우 하나의 LDP 세션만 설정되어 단일 인터페이스에 연결되지 않습니다. 라우터가 동일한 이웃에 여러 인접한 경우 필터가 예상대로 작동할 수 있도록 주의를 다합니다. (일반적으로 사용하며 이 next-hopinterface 경우에는 적합하지 않습니다.)

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

LDP에 대한 정책 구성 방법에 대한 자세한 내용은 라우팅 정책, 방화벽 필터 및 Traffic Policers 사용자 가이드를 참조하십시오.

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

모든 이웃에서 /32개 프리픽스만 허용:

라우터 ID를 허용하거나 더 이상 허용하고 다른 모든 이웃의 모든 131.108/1610.10.255.2 프리픽스를 허용합니다.

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

내보내기 정책을 구성하여 LDP 아웃바운드 레이블을 필터링할 수 있습니다. 라우팅 정책을 적용하여 이웃 라우터에 광고되는 바인딩을 차단하여 아웃바운드 레이블 바인딩을 필터링할 수 있습니다. 아웃바운드 레이블 필터링을 구성하기 위해 다음 export 문을 포함하십시오.

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

명명된 내보내기 정책(계층 수준에서 구성)이 모든 LDP neighbor로 전송되는 모든 레이블 바인딩에 [edit policy-options] 적용됩니다. LDP 아웃바운드 레이블 필터링에 적용되는 유일한 운영자는 지정된 fromroute-filter Prefix와 바인딩을 일치합니다. 아웃바운드 레이블 필터링에 적용되는 유일한 운영자는 to표 2 의 운영자입니다.

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

통신 사업자

설명

interface

지정된 인터페이스를 통해 인접한 이웃으로 전송된 바인딩에 일치

neighbor

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

next-hop

지정된 인터페이스 주소를 광고하는 이웃에게 전송된 바인딩에 일치

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

LDP 세션은 인터페이스 또는 인터페이스 주소에 연계되지 않습니다. LDP는 인터페이스당 레이블이 아니라 라우터당 레이블만 광고합니다. 두 라우터 간에 다중 병렬 링크가 있는 경우 하나의 LDP 세션만 설정되어 단일 인터페이스에 연결되지 않습니다.

라우터가 동일한 이웃에 여러 인접한 경우 운영자 및 운영자는 next-hopinterface 사용하지 않습니다.

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

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

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

모든 이웃에 대한 경로 10.10.255.6/32 전송 차단:

라우터 ID로만 전송하고 다른 모든 라우터로 모든 131.108/1610.10.255.2 프리픽스를 전송합니다.

LDP에서 사용하는 전송 주소 지정

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

LDP 전송 주소를 구성하기 위해 전송 주소문을 포함합니다.

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

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

LDP 규격은 동일한 이웃에 대한 모든 인터페이스에 동일한 전송 주소가 광고될 것을 요구하기 때문에 동일한 LDP neighbor에 대한 다중 병렬 링크가 있는 경우 옵션을 지정할 수 interface 없습니다. LDP가 동일한 이웃에 대한 여러 병렬 링크를 탐지하면 조건이 지워질 때까지 인터페이스의 이웃 연결을 끊거나 옵션을 지정하여 해당 이웃에 대한 인터페이스를 하나씩 router-id 비활성화합니다.

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

두 장비 간에 TCP 세션을 설정하려면 각 디바이스가 다른 장치의 전송 주소를 학습해야 합니다. 전송 주소는 LDP 세션이 작동하는 TCP 세션을 식별하는 데 사용되는 IP 주소입니다. 이전의 이 전송 주소는 라우터 ID 또는 인터페이스 주소일 뿐입니다. LDP 전송 주소 기능을 사용하면 레이어 2 회로, MPLS 및 VPLS 인접에 대한 대상 LDP neighbor에 대한 전송 주소로 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 Release 19.1R1 및 targeted-LDP 세션의 전송 주소에 사용되는 기본 IP 주소 외에도 , 및 구성 명령문의 전송 주소로 다른 IP 주소를 구성할 수 sessionsession-groupinterface 있습니다. 전송 주소 구성은 Layer 2 회로, MPLS 및 VPLS 인접을 포함하여 구성된 이웃에만 적용 가능합니다. 이 구성은 발견된 인접(대상 또는 아니요)에는 적용되지 않습니다.

전송 주소 기본 설정

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

전송 주소가 구성된 후, LDP의 전송 주소 기본 설정에 따라 대상-LDP 세션이 설정됩니다.

대상 이웃(Layer 2 circuit, 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. 기본 주소.

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

  1. [edit protocols ldp interfcae lo0]계층에서.

  2. [edit protocols ldp]계층에서.

  3. 기본 주소.

전송 주소 구성 문제 해결

다음 show 명령 출력을 사용하여 targeted-LDP 세션의 문제를 해결할 수 있습니다.

  • show ldp session

  • show ldp neighbor

    명령의 출력 수준은 hello 메시지에서 대상 이웃에 전송된 전송 주소를 detailshow ldp neighbor 표시합니다. 이 주소가 이웃에서 도달할 수 없는 경우 LDP 세션이 설정되지 않습니다.

  • show configuration protocols ldp

또한 추가 문제 해결을 위해 LDP 추적 옵션을 사용할 수도 있습니다.

  • 유효한 전송 주소로 올인(도달할 수 없는) 전송 주소로 구성이 변경된 경우 다음과 같은 추적을 관찰할 수 있습니다.

  • 잘못된 전송 주소(도달할 수 없는) 전송 주소가 유효한 전송 주소로 변경된 경우 다음과 같은 추적을 관찰할 수 있습니다.

구성에 문제가 있는 경우 다음과 같은 문제 해결 작업을 수행합니다.

  • address family을 체크합니다. 명령문에 따라 구성된 전송 주소는 neighbor 또는 세션과 동일한 주소 session 패밀리에 속해야 합니다.

  • a 또는 명령문에 있는 전송 주소로 구성된 주소는 대상 hello 메시지를 시작하려면 라우터에 neighborsession 로컬로 구성되어야 합니다. 주소가 구성된지 확인할 수 있습니다. 인터페이스 하에서 주소가 구성되지 않은 경우 구성은 거부됩니다.

라우팅 테이블에서 LDP에 광고된 Prefix 구성

LDP에 광고되는 Prefix 집합을 제어하고 라우터를 해당 prefix에 대한 egress 라우터로 만들 수 있습니다. 기본적으로 루프백 주소만 LDP에 광고됩니다. LDP에 광고를 위해 라우팅 테이블의 Prefix 세트를 구성하려는 경우, 다음을 egress-policy 포함합니다.

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

주:

루프백 주소가 없는 LDP에 대한 egress 정책을 구성하는 경우 더 이상 LDP에 광고되지 않습니다. 루프백 주소를 계속 광고하려면, LDP egress 정책의 일부로 명시적으로 구성해야 합니다.

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

주:

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

예를 들면 다음과 같습니다. LDP에 광고된 Prefix 구성

연결된 모든 경로를 LDP로 광고:

FEC Deaggregation 구성

LDP egress 라우터가 여러 프리픽스(prefix)를 광고하는 경우 Prefix는 단일 레이블에 연계되어 FEC(Single Forwarding Equivalence Class)로 집계됩니다. 기본적으로 LDP는 광고가 네트워크를 선회할 때 이러한 집계를 유지 관리합니다.

일반적으로, LSP는 여러 다음 홉으로 분할되지 않습니다. Prefix는 단일 LSP에 연결하기 때문에 동일한 비용 경로에서 로드 밸런싱이 발생하지 않습니다. 그러나 로드 밸런싱 정책을 구성하고 FEC를 세분하면 동일한 비용 경로 전반에서 로드 밸런싱이 가능합니다.

FEC의 세분화는 각 Prefix를 별도의 레이블에 연결하고 별도의 LSP가 됩니다.

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

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

모든 LDP 세션의 경우, 세분화된 FEC를 전역적으로만 구성할 수 있습니다.

FEC의 세분화는 생성된 여러 LSP를 동일한 비용의 여러 경로에 분산하고 egress 세그먼트의 여러 넥스트 홉에 LSP를 분산하지만 LSP당 하나의 다음 홉만 설치할 수 있도록 합니다.

FEC를 집계하기 위해 다음 no-deaggregate 문을 포함합니다.

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

모든 LDP 세션의 경우 집계된 FEC를 전역적으로만 구성할 수 있습니다.

LDP FEC를 위한 Policers 구성

LDP FEC에 대한 트래픽을 Junos OS 트래픽을 추적하고 추적하도록 구성할 수 있습니다. LDP FEC policers는 다음과 같은 작업을 하는 데 사용할 수 있습니다.

  • LDP FEC에 대한 ingress 트래픽을 추적하거나 경찰에 신고합니다.

  • LDP FEC에 대한 전송 트래픽을 추적하거나 경찰에 신고합니다.

  • 특정 포우링 클래스에서 시작된 LDP FEC 트래픽을 추적하거나 추적합니다.

  • 특정 VRF(Virtual Routing and Forwarding) 사이트에서 시작된 LDP FEC 트래픽을 추적하거나 추적합니다.

  • 특정 LDP FEC에 대한 잘못된 트래픽을 폐기합니다.

LDP FEC에 대한 트래픽에 대한 트래픽을 관리하려면 먼저 필터를 구성해야 합니다. 특히, 계층 수준에서 명령문 또는 interfaceinterface-set 명령문을 [edit firewall family protocol-family filter filter-name term term-name from] 구성해야 합니다. 이 명령문을 통해 필터를 단일 인터페이스에 interface 일치할 수 있습니다. 명령문을 통해 필터를 여러 interface-set 인터페이스에 일치할 수 있습니다.

interfaceLDP FEC에 대한 명령문, 정책 구성 방법에 대한 자세한 내용은 라우팅 정책, 방화벽 필터 및 트래픽 정책 사용자 가이드 를 interface-set참조하십시오.

필터를 구성한 policing 후, LDP에 대한 명령문 구성에 필터를 포함해야 합니다. LDP FEC에 대한 정책 처리를 구성하기 위해 다음 진술을 policing 포함합니다.

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

policing명령문에는 다음 옵션이 포함되어 있습니다.

  • fec—경찰서로 지정하려는 LDP FEC에 대한 FEC 주소를 지정합니다.

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

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

LDP IPv4 FEC 필터링 구성

기본적으로 대상 LDP 세션이 설정되면 Junos OS 대상 LDP 세션에서 IPv4 포워팅 등가 클래스(FEC)와 Layer 2 서킷 FEC를 항상 교환합니다. LDP 세션을 간접적으로 연결된 이웃으로 연결하려면 세션이 Layer 2 회로 또는 VPLS를 지원하도록 특별히 구성된 경우 레이어 2 회로 FEC를 이웃으로 내보내기만 할 수 있습니다.

LDP에 모든 비-BGP(Border Gateway Protocol) 프리픽스가 광고되는 혼합 벤더 네트워크에서 LDP 데이터베이스는 대규모로 구축될 수 있습니다. 이러한 유형의 환경에서는 레이어 2 서킷 또는 LDP VPLS 구성으로 인해 형성된 LDP 세션에서 IPv4 FEC의 광고를 방지하는 것이 유용할 수 있습니다. 마찬가지로, 이와 같은 환경에서 수신되는 모든 IPv4 FEC를 필터링하는 것이 유용할 수 있습니다.

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

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

LDP가 Layer 2 neighbors를 통해 LDP 세션에서 IPv4 FEC를 내보내는 것을 방지하고 해당 세션에서 수신된 IPv4 FEC를 필터링하기 위해 다음을 l2-smart-policy 포함합니다.

이 명령문을 구성할 수 있는 계층 수준 목록은 이 명령문에 대한 명령문 요약을 참조합니다.

LDP LSP용 BFD 구성

LDP LSP에 대해 BFD(Bidirectional Forwarding Detection)를 구성할 수 있습니다. BFD 프로토콜은 네트워크에서 장애를 탐지하는 간단한 Hello 메커니즘입니다. Hello 패킷은 지정된 간격으로 전송됩니다. 라우터가 지정된 간격 후에 회신 수신을 중단하면 이웃 장애가 탐지됩니다. BFD는 다양한 네트워크 환경 및 토폴로지와 연동됩니다. BFD를 위한 장애 감지 시간(failure detection timers)은 정적 경로의 장애 탐지 메커니즘보다 짧은 시간 제한을 제공함으로써 보다 빠른 탐지를 제공합니다.

경로에 대한 BFD 세션에 장애가 발생할 때마다 오류가 로깅됩니다. 다음은 LDP LSP 로그 메시지를 위한 BFD가 어떻게 나타나는지 보여줍니다.

또한 RSVP 신호 방식 LSP용 BFD 구성에 설명된 바와 같이 RSVP LSP를 위한 BFD를구성할 수 있습니다.

BFD 장애 감지 시간(failure detection timers)은 적응형으로 보다 적게 조정될 수 있습니다. 예를 들어, 인접한 곳에 장애가 발생하면 더 높은 값에 적응하거나, 이웃이 구성된 값보다 더 높은 타임러에 대해 더 높은 값을 협상할 수 있습니다. BFD 세션 플랩이 15초 동안 3배 이상 발생하면 더 높은 가치에 적응합니다. 로컬 BFD 인스턴스가 세션 플랩을 위한 이유인 경우 백오프 알고리즘은 Receive(Rx) 간격을 2배 증가합니다. 원격 BFD 인스턴스가 세션 플랩을 위한 이유인 경우 전송(Tx) 간격은 2배 증가합니다. 이 명령을 사용하여 clear bfd adaptation BFD 간격 시간(interval timers)을 구성된 값으로 반환할 수 있습니다. 명령어는 무중단(hitless)을 의미하기도 합니다. 이는 명령이 라우팅 장비의 트래픽 흐름에 clear bfd adaptation 영향을 미치지 않는다는 의미입니다.

LDP LSP에 대한 BFD를 활성화하려면 다음과 oambfd-liveness-detection 같은 명령문을 포함합니다.

계층 수준에서 옵션을 사용하여 FEC 주소를 구성하여 특정 FEC(Forwarding Equivalence Class)와 연관된 LDP LSP에 대한 BFD를 활성화할 fec[edit protocols ldp] 수 있습니다. 또는 OAM(Operation Administration and Management) ingress 정책을 구성하여 다양한 FEC 주소에서 BFD를 활성화할 수 있습니다. 자세한 내용은 LDP에 대한 OAM Ingress 정책 구성을 참조하십시오.

동급 FEC 주소가 명시적으로 구성되거나 OAM이 OAM ingress 정책을 사용하여 FEC에 활성화되지 않는 한 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 ingress 정책을 구성해야 합니다.

  • lsp-ping-interval—몇 초만에 LSP 핑 간격(ping interval)의 기간을 지정합니다. LDP 신호 LSP에서 핑을 발행하기 위해 명령을 ping mpls ldp 사용하여 자세한 내용은 CLI.

bfd-liveness-detection명령문에는 다음 옵션이 포함됩니다.

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

  • 홀드다운 간격—경로 또는 다음 홉을 추가하기 전에 BFD 세션이 계속 유지되는 기간을 지정합니다. 0초의 시간을 지정하면 BFD 세션이 백업되는 즉시 경로 또는 다음 홉이 추가됩니다.

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

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

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

  • multiplier—탐지 시간 배수(multiplier)를 지정합니다. 범위는 1에서 255까지입니다.

  • 버전—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 경로는 ECMP 경로를 검색하는 데 사용됩니다. BFD 세션은 검색된 각 ECMP 경로에 대해 시작됩니다. 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 구성(계층 수준 또는 계층 수준) 또는 지정된 FEC 구성(또는 계층 수준에서)에 명령문을 포함해야 periodic-traceroute[edit protocols ldp oam][edit logical-systems logical-system-name protocols ldp oam][edit protocols ldp oam fec address][edit logical-systems logical-system-name protocols ldp oam fec address] 합니다. 그렇지 않으면 커밋 작업이 실패합니다.

주:

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

LDP LSP에서 BFD 세션의 장애 조치 구성

LDP LSP에서 BFD 세션 장애 이벤트가 발생하면 경로 및 넥스홉 속성을 구성할 수 있습니다. 장애 이벤트는 기존 BFD 세션이 다운되거나 전혀 발생하지 않는 BFD 세션일 수 있습니다. LDP는 관련 BFD 세션이 백업될 때 루트 또는 다음 홉을 다시 추가합니다.

LDP LSP에서 BFD 세션에 장애가 발생하면 명령문에 대한 다음 장애 조치 옵션 중 하나를 failure-action 구성할 수 있습니다.

  • remove-nexthop—BFD 세션 장애 이벤트가 탐지되면 ingress 노드에서 LSP 경로의 다음 홉에 해당하는 경로를 제거합니다.

  • remove-route—BFD 세션 장애 이벤트가 탐지되면 해당 라우팅 테이블에서 LSP에 해당하는 경로를 제거합니다. ECMP로 LSP가 구성되고 모든 경로에 해당하는 BFD 세션이 다운되면 루트가 제거됩니다.

LDP LSP에서 BFD 세션 장애가 발생하면 장애 조치를 구성하기 위해 명령문에 대한 옵션 또는 옵션을 remove-nexthopremove-routefailure-action 포함합니다.

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

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

계층 수준 또는 계층 수준에서 명령문을 구성하여 루트 또는 다음 홉을 추가하기 전에 BFD 세션이 위급한 기간을 지정할 holddown-interval[edit protocols ldp oam bfd-livenesss-detection][edit protocols ldp oam fec address bfd-livenesss-detection] 있습니다. 0초의 시간을 지정하면 BFD 세션이 백업되는 즉시 경로 또는 다음 홉이 추가됩니다.

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

멀티캐스트 전용 Fast Reroute 이해

멀티캐스트 전용 MoFRR(Fast Reroute)는 링크 장애가 발생하면 멀티캐스트 분산 트리에서 트래픽의 패킷 손실을 최소화하여 이러한 기능을 지원하는 디바이스에서 PIM(Protocol Independent Multicast) 및 멀티포인트 LDP(Multipoint Label Distribution Protocol)와 같은 멀티캐스트 라우팅 프로토콜을 향상합니다.

주:

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

MX 시리즈 라우터의 경우 MoFRR은 MPC 라인 카드가 있는 MX 시리즈 라우터에서만 지원됩니다. 사전 필요한 경우 라우터를 모드로 구성해야 합니다. 라우터의 모든 라인 network-services enhanced-ip 카드는MPC가 되어야 합니다.

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

MoFRR의 한 애플리케이션은 스트리밍 IPTV입니다. IPTV 스트림은 UDP 스트림으로 멀티캐스트하기 때문에 손실된 패킷이 재전전되지 않아 만족스러운 사용자 경험을 제공합니다. MoFRR은 상황을 개선할 수 있습니다.

MoFRR 개요

유니캐스트 스트림에서 Fast Rero MPLS ute를 사용하는 업스트림 라우팅 디바이스는 LSP(Label-Switched Path)를 미리 설정하거나, 다운스트림 경로에서 세그먼트의 장애를 처리하기 위해 IP 루프가 없는 대체 경로(LFA)를 사전컴컴합니다.

멀티캐스트 라우팅에서 수신측은 일반적으로 트래픽 분배 그래프에서 비 시작됩니다. 이는 일반적으로 소스에서 수신기로 경로를 설정하는 유니캐스트 라우팅과는 달리, PIM(IP용), 멀티포인트 LDP(MPLS) 및 RSVP-트래픽 엔지니어링(TE)(MPLS)는 멀티캐스트 배포 그래프를 설정할 수 있는 프로토콜입니다. 이러한 중 PIM 및 멀티포인트 LDP 리시버가 분산 그래프 설정을 시작할 수 있으므로, MoFRR는 지원되는 이 2개의 멀티캐스트 프로토콜과 연동할 수 있습니다.

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

각(S,G) 엔트리에 대해 MoFRR을 활성화하면 디바이스는 사용 가능한 2개의 업스트림 인터페이스를 사용하여 가입 메시지를 전송하고 멀티캐스트 트래픽을 수신합니다. 이 프로토콜은 이러한 두 경로를 사용할 수 있는 경우 2개의 서로 다른 경로를 선택하려고 시도합니다. 서로 다른 경로를 사용할 수 없는 경우 프로토콜에서 2개의 비일관성 경로를 선택합니다. 2개의 비일관성 경로가 지원되지 않을 경우 백업이 없는 기본 경로만 선택됩니다. MoFRR는 가용 경로의 로드 밸런싱을 위해 불일치 백업을 우선 순위화합니다.

MoFRR은 IPv4 및 IPv6 프로토콜군에서 모두 지원됩니다.

그림 12 은 멀티캐스트 수신기 라우팅 장비(PE(egress Provider Edge) 디바이스)에서 멀티캐스트 소스 라우팅 장비(수신 PE 디바이스라고도도)에 대한 2개의 경로를 보여줍니다.

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

MoFRR를 활성화하면 송신(수신자측) 라우팅 디바이스가 각각(S,G)의 멀티캐스트 소스로 2개의 멀티캐스트 트리, 기본 경로 및 백업 경로로 설정됩니다. 다시 말해, egress 라우팅 장치는 동일한(S,G) 서로 다른 업스트림 이웃(upstream neighbor)을 향해 동일한 메시지를 전파하여 2개의 멀티캐스트 트리를 생성합니다.

멀티캐스트 트리 중 하나는 에 표시된와 같이 플레인 1을 통과하고 다른 하나는 플레인 2를 그림 12 통과합니다. 각(S,G)에 대해, egress 라우팅 장치는 기본 경로에서 수신된 트래픽을 전달하고 백업 경로에서 수신된 트래픽을 삭제합니다.

MoFRR은 ECMP(Equal-Cost Multipath) 경로와 비 ECMP 경로에서 모두 지원됩니다. 이 장치는 비 ECMP 경로에서 MoFRR을 지원하기 위해 유니캐스트 LFA(Loop-Free Alternate) 경로를 활성화해야 합니다. 내부 게이트웨이 프로토콜(IGP) 구성에서 명령문을 사용하여 LFA link-protection 경로를 활성화합니다. 인터페이스 또는 최단 경로 우선(OSPF) IS-IS(Intermediate System to Intermediate System) 보호를 활성화하면 장치는 보호된 인터페이스를 통해 전달되는 모든 대상 경로에 대해 기본 넥스트 홉에 대한 백업 LFA 경로를 생성합니다.

Junos OS 멀티포인트 LDP MoFRR를 위한 IP MoFRR 및 MPLS LER(Label-Edge Routing Device)에서 IP 네트워크에서 MoFRR을 구현합니다.

멀티포인트 LDP MoFRR는 패킷이 IP 네트워크로 전송되는 MPLS 네트워크의 egress 장치에서 사용됩니다. 이 장치는 멀티포인트 LDP MoFRR를 통해 업스트림 PE 라우팅 장비로 향하는 2개의 경로를 설정하여 LER에서 2개의 MPLS 패킷을 수신합니다. 디바이스는 스트림(기본)을 허용하고 다른 스트림(백업)은 LER에 드롭됩니다. 기본 경로에 장애가 발생하면 디바이스가 대신 백업 스트림을 수락합니다. 인밴드 시그널링 지원은 멀티포인트 LDP를 지원하는 MoFRR의 사전 전제입니다(Point-to-Multipoint LSP의 경우 멀티포인트 LDP 인밴드 시그널링이해 참조).

PIM 기능

Junos OS PIM 소스별 멀티캐스트(SSM) 및 ASM(Any-Source Multicast)에서 SPT(Shortest-Path Tree) 조인에 대해 MoFRR을 지원 MoFRR은 SSM 및 ASM 범위 모두에서 지원됩니다. MoFRR for (*,G) Joins를 활성화하려면 계층에 mofrr-asm-starg 구성 명령문을 [edit routing-options multicast stream-protection] 포함해야 합니다. 각 그룹 G의 경우, MoFRR은 (S, G) 또는 (*,G) 모두에서 작동하지만 둘 다 작동하지는 않습니다. (S,G)는 항상 (*,G)에 우선합니다.

MOFRR를 활성화하면 PIM 라우팅 디바이스가 두 개의 업스트림 RPF(Reverse Path Forwarding) 인터페이스에서 메시지를 연결하여 동일한 조인 요청에 대한 두 링크에서 멀티캐스트 트래픽을 수신합니다. MoFRR는 동일한 즉각적인 업스트림 라우팅 장비로 수렴하지 않는 두 경로를 기본 설정합니다. PIM은 2개의 인터페이스(기본 및 백업 경로)를 통해 업스트림 RPF 다음 홉을 통해 적절한 멀티캐스트 경로를 설치합니다.

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

PIM 조인트 로드 밸런싱을 통해 MoFRR을 활성화할 join-load-balance automatic 수 있습니다(명령문 참조). 그러나 이 경우 링크 간 조인(join) 메시지가 배포되지 않을 수 있습니다. 새로운 ECMP 링크가 추가될 경우 기본 경로에 있는 메시지를 재분배하고 로드 균형을 맞출 수 있습니다. 백업 경로의 조인 메시지는 여전히 동일한 경로를 따라가며 재배포되지 않을 수도 있습니다.

계층에서 구성 명령문을 사용하여 MoFRR을 stream-protection[edit routing-options multicast] 활성화합니다. MoFRR은 필터 정책 세트를 통해 관리됩니다.

egress PIM 라우팅 장비가 참여 메시지 또는 IGMP 보고서를 수신하면 MoFRR 구성을 검사하고 다음과 같이 진행합니다.

  • MoFRR 구성이 없는 경우 PIM은 업스트림 neighbor(예: Plane 2 in)로 가입 메시지 업스트림을 그림 12 전송합니다.

  • MoFRR 구성이 있는 경우 디바이스가 정책 구성을 검사합니다.

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

    • 기본 및 백업 경로를 사용할 수 없는 경우- PIM은 업스트림 이웃(예: Plane 2 in)으로 가입 메시지 업스트림을 그림 12 전송합니다.

    • 기본 및 백업 경로가 사용 가능한 경우, PIM은 가용 업스트림 이웃 중 2개로 참여 메시지 업스트림을 전송합니다. Junos OS 기본 및 보조 멀티캐스트 경로를 설정하여 멀티캐스트 트래픽을 수신합니다(예: Plane 1 그림 12 in).

  • 정책이 있는 경우 디바이스는 해당 정책이 이러한(S,G)에 대해 MoFRR을 허용하는지 여부를 검사하고 다음과 같이 진행합니다.

    • 이 정책 검사에 장애가 발생하면 PIM이 업스트림 neighbor(예: plane 2 in)로 가입 메시지 업스트림을 그림 12 전송합니다.

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

      • 기본 및 백업 경로를 사용할 수 없는 경우 PIM은 업스트림 이웃(예: Plane 2 in)으로 조인 메시지 업스트림을 그림 12 전송합니다.

      • 기본 및 백업 경로를 사용할 수 있는 경우 PIM은 가용 업스트림 이웃 중 2개로 참여 메시지 업스트림을 전송합니다. 디바이스는 멀티캐스트 트래픽을 수신하기 위한 기본 및 보조 멀티캐스트 경로를 설정합니다(예: Plane 1 그림 12 in).

멀티포인트 LDP 기능

트래픽 중복을 MPLS 방지하기 위해 멀티포인트 LDP는 일반적으로 하나의 업스트림 경로만 선택합니다. (섹션 2.4.1.1을 참조하십시오. RFC 6388에서 '업스트림 레이블 스위칭 라우터(LSR)', Point-to-Multipoint 및 Multipoint-to-Multipoint Label Switched Path를 위한 Label Distribution Protocol Extensions를결정한다.)

멀티포인트 LDP와 MoFRR의 경우, 멀티포인트 LDP 디바이스는 2개의 개별 업스트림 피어를 선택하고 각각 다른 2개의 레이블(각 업스트림 피어로 1개)을 전송합니다. 디바이스는 RFC 6388에 설명된 동일한 알고리즘을 사용하여 기본 업스트림 경로를 선택합니다. 이 장치는 동일한 알고리즘을 사용하여 백업 업스트림 경로를 선택하지만 기본 업스트림 레이블 스위칭 라우터(LSR) 제외합니다. 2개의 서로 다른 업스트림 피어는 2개의 MPLS 트래픽 스트림을 egress 라우팅 장비로 전송합니다. 디바이스는 업스트림 이웃 경로 중 하나를 기본 경로로 선택하여 트래픽을 MPLS 있습니다. 다른 경로는 백업 경로가 됐고 장치는 그 트래픽을 삭제합니다. 기본 업스트림 경로에 장애가 발생하면 디바이스가 백업 경로에서 트래픽 허용을 시작합니다. 멀티포인트 LDP 디바이스는 내부 게이트웨이 프로토콜(IGP) 루트 디바이스 다음 홉을 기반으로 IGP 업스트림 경로를 선택합니다.

FEC(Forwarding Equivalency Class)는 동일한 방식으로 동일한 경로상에서 동일한 전달 처리를 통해 전달되는 IP 패킷 그룹입니다. 일반적으로, 특정 패킷에 붙어 있는 레이블은 해당 패킷이 할당되는 FEC를 나타 내포합니다. MoFRR에서 두 라우트는 각 FEC에 대한 mpls.0 테이블에 배치됩니다. 즉, 기본 레이블에 대한 한 경로와 백업 레이블에 대한 다른 루트가 있습니다.

동일한 즉각적인 업스트림 디바이스로 향하는 병렬 링크가 있는 경우 디바이스는 두 병렬 링크가 모두 기본 링크로 고려됩니다. 업스트림 디바이스는 어느 시점이든 여러 병렬 링크 중 하나에서만 트래픽을 전송합니다.

버드 노드는 레이블 스위칭 라우터(LSR) egress 레이블 스위칭 라우터(LSR) LSRS가 하나 이상의 다운스트림 LSRS를 직접 연결합니다. 버드 노드의 경우 기본 업스트림 경로의 트래픽이 다운스트림 레이블 스위칭 라우터(LSR). 기본 업스트림 경로에 장애가 발생하면 백업 업스트림 경로의 MPLS 트래픽이 다운스트림 경로로 레이블 스위칭 라우터(LSR). 즉, 다음 홉의 다운스트림 레이블 스위칭 라우터(LSR) egress next hop과 MPLS 두 경로에 추가됩니다.

PIM과 함께 계층에서 구성 명령문을 사용하여 멀티포인트 LDP를 사용하여 MoFRR을 활성화하고 필터 정책 세트를 stream-protection[edit routing-options multicast] 통해 관리할 수 있습니다.

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

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

  • 동일한 업스트림 인터페이스에 속하는 모든 레이블 스위칭 라우터(LSR) 경로로 간주됩니다.

  • 루트 노드 경로 업데이트의 경우 업스트림 경로는 에지의 최신 넥스트 홉을 IGP. 더 나은 경로를 사용할 수 있는 경우 멀티포인트 LDP가 더 나은 경로로 전환하려고 시도합니다.

패킷 포워딩

PIM 또는 멀티포인트 LDP의 경우, 장치는 ingress 인터페이스에서 멀티캐스트 소스 스트림 선택을 수행한다. 이를 통해 패브릭 대역폭을 보존하고 포우킹 성능을 극대화할 수 있습니다.

  • 패브릭 전체에서 복제 스트림을 전송하지 않습니다.

  • 여러 루트 룩업을 방지(패킷 드롭으로 이어지음).

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

그림 13 PIM이 있는 라우터의 샘플 기본 및 백업 인터페이스를 통해 이 프로세스를 보여줍니다. 그림 14 PIM이 있는 스위치의 경우 이와 유사한 것으로 나타날 수 있습니다.

그림 13: 라우터에서 네트워크에서 패킷 전달 엔진 MoFRR IP Route Lookup라우터에서 네트워크에서 패킷 전달 엔진 MoFRR IP Route Lookup
그림 14: 스위치에서 네트워크에서 패킷 전달 엔진 MOFRR IP 경로 처리스위치에서 네트워크에서 패킷 전달 엔진 MOFRR IP 경로 처리

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

그림 15 멀티포인트 LDP를 사용하여 라우터에 이 프로세스를 보여줍니다.

그림 15: MoFRR MPLS 경로 룩업을 패킷 전달 엔진MoFRR MPLS 경로 룩업을 패킷 전달 엔진

제한 사항 및 경고문

스위칭 및 라우팅 장치에 대한 MoFRR 제한 및 경고문

MoFRR는 라우팅 및 스위칭 디바이스에 대한 다음과 같은 제한 사항과 경고문을 가지고 있습니다.

  • MoFRR 장애 감지는 멀티캐스트 트래픽 경로의 모든 링크(전체 링크)가 아니라 MoFRR이 활성화된 라우팅 장치에 대한 즉각적인 링크 보호를 지원할 수 있습니다.

  • MoFRR는 소스를 향해 선택된 2개의 서로 다른 경로에서 고속 재라우트를 지원 선택한 업스트림 이웃 중 2개가 동일한 인터페이스에 있을 수 없습니다. 즉, LAN 세그먼트에 있는 업스트림 이웃 2개입니다. 업스트림 인터페이스가 멀티캐스트 터널 인터페이스인 경우도 마찬가지입니다.

  • 최대 엔드-엔드 비일관성 업스트림 경로 탐지는 지원되지 않습니다. 수신기 측(송신) 라우팅 장비는 오직 상이한 업스트림 장비(즉각적인 이전 홉)가 있는지만 확인합니다. PIM 및 멀티포인트 LDP는 동일하게 명시적 경로 객체(EROS)를 지원하지 않습니다. 따라서, 업스트림 경로 탐지가 즉시 이전 홉 디바이스에 대한 제어로 제한됩니다. 이러한 제한으로 인하여 기본 홉 및 백업으로 선택된 이전 홉의 업스트림 디바이스로의 경로를 공유할 수 있습니다.

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

    • 더 나은 업스트림 경로는 egress 장치에서 사용할 수 있습니다.

    • egress 디바이스에서 MoFRR을 활성화 또는 비활성화하고 활성 트래픽 스트림이 흐르는 중입니다.

  • 백업 경로에 대한 조인 메시지를 위한 PIM 조인트 로드 밸런싱은 지원되지 않습니다.

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

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

  • 양방향 PIM 범위는 MoFRR과 함께 지원되지 않습니다.

  • PIM 고밀도 모드는 MoFRR과 함께 지원되지 않습니다.

  • 백업 트래픽 스트림에 대한 멀티캐스트 통계는 PIM에 의해 유지 관리되지 않는 것이기 때문에 명령의 작동 출력에서는 show 지원되지 않습니다.

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

PIM을 사용하여 스위칭 디바이스에 대한 MoFRR 제한

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

  • 업스트림 인터페이스가 IRB(Integrated Routing and Bridging) 인터페이스인 경우, MoFRR는 지원되지 않습니다. 이 인터페이스는 IGMPv3(Internet Group Management Protocol version 3) 스누킹과 같은 다른 멀티캐스트 기능에 영향을 줍니다.

  • 멀티캐스트 트래픽을 포워팅하는 동안 패킷 복제 및 멀티캐스트 룩업을 통해 패킷이 PF를 통해 여러 번 재인증될 수 있습니다. 그 결과, 명령어에서 멀티캐스트 패킷 카운트에 대한 표시되는 값이 show pfe statistics trafficInput packetsOutput packets 복제 기본 및 백업 스트림이 일반적인 트래픽 흐름을 증가시 주기 때문에 이러한 동작이 MoFRR 시나리오에서 더 자주 발생할 수 있습니다.

멀티포인트 LDP를 통해 라우팅 디바이스에 대한 MoFRR 제한 및 경고문

MoFRR는 멀티포인트 LDP와 함께 사용할 때 라우터에 다음과 같은 제한 사항과 경고문을 가지고 있습니다.

  • RSVP 터널이 인터페이스와 연관되지 않은 경우, RSVP 터널에서 수신된 멀티포인트 LDP 트래픽에는 MoFRR이 적용되지 않습니다.

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

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

  • 여러 ingress(소스측) PE(Provider Edge) 라우팅 디바이스를 통해 소스에 도달하는 경우 멀티포인트 LDP MoFRR이 지원되지 않습니다.

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

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

멀티캐스트 전용 Fast Reroute 구성

링크 장애 시 네트워크에서 패킷 손실을 최소화하도록 멀티캐스트 전용 MoFRR(Fast Reroute)를 구성할 수 있습니다.

고속 재라우팅을 유니캐스트 스트림에 적용하면 MPLS 업스트림 라우터가 LSP(Label-Switched Path)를 사전 설정하거나 LFA(IP Loop-Free Alternate) Fast Reroute 백업 경로를 사전컴컴하여 다운스트림 경로에서 세그먼트 장애를 처리합니다.

멀티캐스트 라우팅에서 트래픽 분배 그래프는 일반적으로 리시버(receiver)에서 시작됩니다. 이는 일반적으로 소스에서 수신기로 경로를 설정하는 유니캐스트 라우팅과는 달리, 멀티캐스트 배포 그래프를 설정할 수 있는 프로토콜은 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 도메인에서 동일한 레이블이 동일한 업스트림 이웃에 대한 병렬 링크 간에 공유됩니다. 이는 각 링크가 이웃을 형성하는 PIM 도메인은 아닙니다. 이 명령문은 경로가 기본 RPF 경로와 동일한 업스트림 이웃으로 가는 경우 백업 mofrr-disjoint-upstream-only RPF 경로를 선택하지 못합니다. 따라서 여러 RPF 업스트림 이웃이 있는 토폴로지에서만 MoFRR이 트리거됩니다.

  7. (선택 사항) MoFRR가 있는 PIM 도메인에서는 백업 경로에서 참여 메시지를 전송하지 못하도록 차단하지만 다른 모든 MoFRR 기능을 그대로 유지할 수 있습니다.

    이 버전은 멀티포인트 LDP MoFRR에서 지원되지 않습니다.

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

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

    이 버전은 멀티포인트 LDP MoFRR에서 지원되지 않습니다.

예를 들면 다음과 같습니다. 멀티캐스트 전용 Fast Reroute 구성 멀티포인트 LDP 도메인에서

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

멀티포인트 LDP MoFRR은 패킷이 IP 네트워크로 MPLS 네트워크의 egress 노드에서 사용됩니다. 멀티포인트 LDP MoFRR의 경우, 업스트림 PE(Provider Edge) 라우터로 향하는 두 경로는 레이블 에지 라우터(LER)에서 2개의 MPLS 패킷 스트림을 수신하기 위해 설정됩니다. 스트림 중 하나(기본)가 허용되면 다른 스트림(백업)은 LER에 드롭됩니다. 기본 경로에 장애가 발생하면 백업 스트림이 수용됩니다.

요구 사항

이 예제를 구성하기 전에 장치 초기화 이외에는 특별한 구성이 필요하지 않습니다.

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

MoFRR은 MPC 라인 카드를 통해 MX 시리즈 플랫폼에서 지원됩니다. 사전 준비된 라우터는 모드로 설정되어야 합니다. 플랫폼의 모든 라인 카드는 network-services enhanced-ip MPC가 되어야 합니다.

이 예에서는 Junos OS egress PE 라우터에서 Release 14.1 이상을 필요로 합니다.

개요

이 예에서 Device R3은 egress 에지 라우터입니다. 이 디바이스에서만 MoFRR이 활성화됩니다.

최단 경로 우선(OSPF)(IGP) 또는 정적 경로를 사용할 수 있는 경우 연결에 사용됩니다.

테스트 목적으로 라우터는 소스와 수신기를 시뮬레이션하는 데 사용됩니다. Device R4 및 Device 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 보여줍니다.

구성 섹션에서는 Device R3의 단계를 설명합니다.

CLI 빠른 구성

CLI 빠른 구성

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

디바이스 src1

디바이스 src2

디바이스 R1

디바이스 R2

디바이스 R3

디바이스 R4

디바이스 R5

디바이스 R6

디바이스 R7

디바이스 R8

구성

절차

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 정보는 CLI 사용자 가이드의 CLI Editor 사용 Junos OS CLI 참조하십시오.

Device R3을 구성하려면:

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

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

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

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

  5. PIM을 구성합니다.

  6. LDP를 구성합니다.

  7. 정적 IGP 구성합니다.

  8. 내부 구성 BGP(Border Gateway Protocol).

  9. RSVP MPLS 구성합니다.

  10. MoFRR을 활성화합니다.

결과

구성 모드에서 , , 및 명령어를 입력하여 show chassisshow interfacesshow protocolsshow policy-optionsshow routing-options 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

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

확인

구성이 제대로 작동하고 있는지 확인합니다.

LDP Point-to-Multipoint 포우징 등가(Point-to-Multipoint Forwarding) 등급 검사

목적

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

실행
의미

출력은 MoFRR이 활성화되어 있는 것을 보여 주며, 레이블 301568 및 301600이 2개의 멀티포인트 LDP 점대다점 LSP에 사용 중인 것을 보여줍니다.

Label 정보 검토

목적

egress 디바이스에 멀티캐스트 그룹 참여를 위한 2개의 업스트림 인터페이스가 있는지 확인합니다.

실행
의미

출력은 기본 업스트림 경로와 백업 업스트림 경로를 보여줍니다. RPF 다음 홉도 보여줍니다.

멀티캐스트 경로 확인

목적

IP 멀티캐스트 포워팅 테이블을 검사하여 기본 및 백업 인터페이스가 있는 업스트림 RPF 인터페이스 목록이 있는지 확인하십시오.

실행
의미

출력에는 기본 세션 및 백업 세션과 RPF 넥스 홉이 표시된다.

LDP Point-to-Multipoint 트래픽 통계 확인

목적

기본 통계와 백업 통계가 모두 나열되어 있는지 확인

실행
의미

출력에는 레이블이 있는 기본 경로와 백업 경로가 모두 표시됩니다.

예를 들면 다음과 같습니다. 수요에 따라 LDP 다운스트림 구성

이 예에서는 요구에 따라 LDP 다운스트림을 구성하는 방법을 보여줍니다. LDP는 일반적으로 다운스트림 원치 않는 광고 모드를 사용하여 구성됩니다. 즉, 모든 LDP 피어로부터 모든 라우트에 대한 레이블 광고가 수신됩니다. 서비스 프로바이더가 액세스 및 어그리게이트 네트워크를 단일 MPLS 도메인으로 통합할 경우, 액세스와 어그리게이트 네트워크 간의 바인딩을 분산하고 컨트롤 플레인에 대한 프로세싱 요구 사항을 줄이기 위해 수요에 따라 LDP 다운스트림이 필요합니다.

다운스트림 노드는 업스트림 집계 노드에서 수만 개의 레이블 바인딩을 수신할 수 있습니다. 전체 MPLS 네트워크 내에서 가능한 모든 루프백 주소에 대한 모든 레이블 바인딩을 학습하고 저장하는 대신, 다운스트림 어그리게이트 노드는 온디맨드 방식의 LDP 다운스트림을 사용하여 서비스를 구성한 해당 Egress 노드의 루프백 주소에 해당하는 FEC에 대한 레이블 바인딩만 요청하도록 구성할 수 있습니다.

요구 사항

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

  • M Series 라우터

  • Junos OS 12.2

개요

계층 수준에서 다운스트림 On-Demand 명령문을 포함해 LDP 세션에 대한 LDP 다운스트림 레이블 광고를 활성화할 [edit protocols ldp session] 수 있습니다. 요청 시 다운스트림을 구성한 경우 주니퍼 네트웍스 라우터가 해당 피어 라우터에 다운스트림 요청을 알려 줍니다. 두 라우터 간에 다운스트림(downstream) 세션이 설정될 경우, 두 라우터 모두 LDP 세션 설정 중에 요구에 따라 다운스트림 모드에 대해 알려야 합니다. 하나의 라우터가 다운스트림 비가정 모드에 광고를 올리고 다른 라우터가 수요에 따라 다운스트림을 광고하는 경우, 다운스트림 원치 않는 모드가 사용됩니다.

구성

수요에 따라 LDP 다운스트림 구성

단계별 절차

요구 시 LDP 다운스트림을 구성한 다음, 해당 정책을 구성하고 LDP 세션에서 LDP 다운스트림을 활성화하려면 다음을 제공합니다.

  1. 이 예에서는 다운스트림 On Demand 정책(DOD-Request-Loopbacks)을 구성합니다.

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

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

    명령문과 함께 지정된 정책은 레이블 요청 메시지를 전송하는 dod-request-policy prefix를 식별하는 데 사용됩니다. 이 정책은 egress 정책 또는 가져오기 정책과 유사합니다. inet.0 라우팅 테이블의 경로를 처리하는 경우 Junos OS 소프트웨어에서 정책과 일치하는 경로를 DOD-Request-Loopbacks 검사합니다(예). 루트가 정책과 일치하면 LDP 세션이 DOD 광고 모드와 협상되는 경우, Label 요청 메시지가 해당 다운스트림 LDP 세션으로 전송됩니다.

  3. LDP 세션을 구성에 포함하여 다운스트림을 지원하고, 요구에 따라 분산 downstream-on-demand 모드로 다운스트림할 수 있도록 합니다.

LDP 다운스트림을 라벨링된 경로로 BGP(Border Gateway Protocol)

단계별 절차

라벨링된 경로로 수요에 따라 LDP 다운스트림을 BGP(Border Gateway Protocol) 수출 정책을 BGP(Border Gateway Protocol) 수 있습니다.

  1. LDP 라우트 정책을 구성합니다(이 redistribute_ldp 예에서는).

  2. LDP 라우팅 정책을 BGP(Border Gateway Protocol) 구성에 포함합니다(이 예제에서는 BGP(Border Gateway Protocol) 그룹 구성의 redistribute_ldpebgp-to-abr 일부로).

    BGP(Border Gateway Protocol) 정책에 따라 LDP 경로를 원격 redistribute_ldp PE 라우터로 전달합니다.

단계별 절차

다운스트림 비 원치 않는 모드(다운스트림 대신)로 구성된 다른 라우터로 레이블 전파를 제한하기 위해 다음 정책을 구성합니다.

  1. dod-routesLDP의 경로를 허용하도록 정책을 구성합니다.

  2. 이웃 , 및 에 대한 경로를 포부하지 do-not-propagate-du-sessions1.1.1.12.2.2.2 말고 정책을 3.3.3.3 구성합니다.

  3. 정책에서 검사하는 라우트가 정책에 정의된 이웃 라우터로 전달되지 못하도록 정책을 filter-dod-on-du-sessionsdod-routesdo-not-propagate-du-sessions 구성합니다.

  4. 정책은 filter-dod-routes-on-du-sesssion 브로프 브로프에 대한 내보내기 BGP(Border Gateway Protocol) ebgp-to-abr 를 지정합니다.

결과

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

확인

Label Advertisement 모드 검증

목적

구성이 제대로 작동하고 있는지 확인합니다.

명령어를 사용하여 LDP 세션에 대한 show ldp session Label 광고 모드의 상태를 검증합니다.

실행

문제 show ldp sessionshow ldp session detail 명령:

  • 명령에 대한 다음 명령 출력은 (레이블 광고 모드)가 (즉, 요구에 따라 show ldp sessionAdv. Mode LDP 다운스트림이 작동하고 있는 경우)를 DOD 나타냅니다.

  • 명령에 대한 다음 명령 출력은 show ldp session detailLocal Label Advertisement mode 의 기본값을 나타냅니다(로컬 세션에서 다운스트림을 Downstream unsolicited 의미). 거스를 수 있는 것은 모두 원격 세션에서 Remote Label Advertisement modeNegotiated Label Advertisement modeDownstream on demand 구성됩니다.

LDP 네이티브 IPv6 지원 구성

LDP는 IPv6 전용 네트워크 및 RFC 7552에설명된 바와 같이 IPv6 또는 IPv4 듀얼 스택 네트워크에서 지원됩니다. inetIPv4 또는 IPv6 또는 두 가지 모두에 대해 주소 패밀리를 구성하고 전송 기본 설정이 하도록 inet6IPv4IPv6 구성합니다. 이 Junos OS 명령문을 통해 LDP는 IPv4 이웃을 사용하여 IPv4를 통해 TCP 연결을 구축하고 IPv6 이웃을 단일 스택 장치로 dual-transport IPv6로 구축할 수 레이블 스위칭 라우터(LSR). inet-lsr-idinet6-lsr-id IPv4 및 IPv6 TCP 전송을 통해 LDP 세션을 설정하도록 구성해야 하는 2개의 레이블 스위칭 라우터(LSR) 아이디입니다. 이들 2개 아이디는 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 neighbor를 사용하여 IPv6 세션을 구축할 수 있도록 듀얼 전송을 구성합니다. inet-lsr-idIPv4의 레이블 스위칭 라우터(LSR) ID로, inet6-lsr-id IPv6를 위한 레이블 스위칭 라우터(LSR) ID로 구성합니다.

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

예를 들면 다음과 같습니다. LDP 네이티브 IPv6 지원 구성

이 예제에서는 LDP(Junos OS Label Distribution Protocol)를 통해 IPv4 이웃을 사용하여 IPv4를 통해 TCP 연결을 설정하고 IPv6 이웃을 단일 스택 네트워크로 IPv6를 통해 구축하는 레이블 스위칭 라우터(LSR). 이를 통해 IPv4 신호 전송 MPLS LSP(Label-Switched Path)를 통해 IPv6 MPLS 터널링을 피할 수 있습니다.

요구 사항

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

  • 2개의 MX 시리즈 라우터

  • Junos OS Release 16.1 이상이 모든 장치에서 실행됩니다.

IPv6를 듀얼 스택으로 구성하기 전에 라우팅 및 시그널링 프로토콜을 구성해야 합니다.

개요

LDP는 RFC 7552에설명된 바와 같이 IPv6 또는 IPv4 듀얼 스택 네트워크에서 IPv6 전용 네트워크에서 지원됩니다. inetIPv4 또는 inet6 IPv6용 주소 패밀리를 구성합니다. 기본적으로 IPv6는 IPv4 및 IPv6를 활성화할 때 피어를 사용하는 LDP 세션의 TCP 전송으로 사용됩니다. 듀얼-전송 명령문을 통해 Junos LDP는 IPv4 이웃을 사용하여 IPv4를 통해 TCP 연결을 구축하고 IPv6 이웃을 단일 스택 네트워크로 IPv6로 구축할 수 레이블 스위칭 라우터(LSR). 그리고 두 가지 레이블 스위칭 라우터(LSR) inet-lsr-id IPv4 및 IPv6 TCP 전송을 통해 LDP 세션을 설정하도록 구성해야 하는 두 가지 inet6-lsr-id 아이디입니다. 이들 2개 아이디는 0이 아닌 서로 다른 값으로 구성되어야 합니다.

토폴로지

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

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

구성

CLI 빠른 구성

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

R1

R2

R1 구성

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 데이터 유저 가이드의 CLI Using the CLI Editor in Configuration Mode"를참조하십시오. Junos OS CLI.

장비 R1을 구성하려면:

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

  2. 루프백 주소를 장비에 할당합니다.

  3. 인터페이스 IS-IS(Intermediate System to Intermediate System) 구성합니다.

  4. 디바이스 MPLS LDP 인터페이스를 사용할 수 있도록 구성합니다.

  5. 서로 다른 주소 패밀리에 대해 서로 다른 레이블을 사용하기 위해 FEC(Forwarding Equivalence Class) 디어그리게이징을 활성화합니다.

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

결과

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

선호하는 전송을 선택하기 위해 전송 기본 설정 구성

CLI 빠른 구성
단계별 절차

IPv4 및 IPv6가 모두 활성화될 때 TCP 연결을 위한 기본 전송을 선택하도록 명령문을 transport-preference 구성할 수 있습니다. 기본적으로 IPv6는 LDP 연결을 구축하기 위한 TCP 전송으로 사용됩니다.

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

단계별 절차
결과

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

IPv4 Neighbor와 IPv6 Neighbor를 통해 IPv4를 위한 개별 세션을 설정하기 위한 듀얼 전송 구성

단계별 절차

이 명령문을 통해 LDP가 IPv4 neighbor와 IPv6 인접한 IPv6 세션을 통해 별도의 IPv4 세션을 구축할 수 있도록 명령문을 dual-transport 구성할 수 있습니다. 이를 위해서는 inet-lsr-id IPv4용 레이블 스위칭 라우터(LSR) ID로, inet6-lsr-id IPv6를 위한 레이블 스위칭 라우터(LSR) ID로 구성해야 합니다.

  • (선택 사항) LDP가 IPv4 이웃을 사용하여 IPv4에서 TCP 연결을 구축하고 IPv6 이웃을 단일 스택 서버로 IPv6로 구축할 수 있도록 이중 전송을 레이블 스위칭 라우터(LSR).

결과

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

확인

구성이 제대로 작동하고 있는지 확인합니다.

mpls.0 테이블에서 경로 엔트리 검증
목적

mpls.0 라우팅 테이블 정보를 표시합니다.

실행

Device R1에서 작동 모드에서 명령을 실행하여 show route table mpls.0 mpls.0 라우팅 테이블 정보를 표시합니다.

의미

출력에는 mpls.0 라우팅 테이블 정보가 표시됩니다.

inet.3 표의 경로 엔트리 검증
목적

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

실행

Device R1에서 작동 모드에서 명령을 실행하여 show route table inet.3 inet.3 라우팅 테이블 정보를 표시합니다.

의미

출력에는 inet.3 라우팅 테이블 정보가 표시됩니다.

inet6.3 표의 경로 엔트리 검증
목적

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

실행

Device R1에서 작동 모드에서 명령을 실행하여 show route table inet6.3 inet6.3 라우팅 테이블 정보를 표시합니다.

의미

출력에는 inet6.3 라우팅 테이블 정보가 표시됩니다.

LDP 데이터베이스 검증
목적

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

실행

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

의미

출력은 LDP 데이터베이스의 엔트리를 보여줍니다.

LDP Neighbor 정보 검증
목적

LDP neighbor 정보를 표시합니다.

실행

Device R1에서 작동 모드에서 LDP neighbor 정보를 표시하기 위해 명령어와 명령을 show ldp neighborshow ldp neighbor extensive 실행합니다.

의미

출력은 IPv4 및 IPv6 주소 모두의 LDP neighbor 정보를 보여줍니다.

LDP 세션 정보 검증
목적

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

실행

Device R1에서 작동 모드에서 LDP 세션 정보를 표시하기 위해 명령어와 명령을 show ldp sessionshow ldp session extensive 실행합니다.

의미

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

확인

구성이 제대로 작동하고 있는지 확인합니다.

LDP Neighbor 정보 검증
목적

LDP neighbor 정보를 표시합니다.

실행

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

의미

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

LDP 세션 정보 검증
목적

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

실행

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

의미

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

확인

구성이 제대로 작동하고 있는지 확인합니다.

LDP Neighbor 정보 검증
목적

LDP neighbor 정보를 표시합니다.

실행

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

의미

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

LDP 세션 정보 검증
목적

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

실행

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

예를 들면 다음과 같습니다. 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 터널링을 레이블 캡슐화(label encapsulation)로 MPLS 있습니다. 레이블 스위칭을 MPLS 동기는 MPLS 트래픽 엔지니어링 및 보호 기능을 활용하고 제공업체 코어에서 제어 트래픽 오버헤드의 양을 줄이는 것입니다.

이를 위해 서비스 프로바이더는 멀티캐스트 트래픽이 통과할 수 있도록 기존 구축의 확장을 활용하는 데 관심이 있습니다. IP/MPLS 기존 멀티캐스트 확장은 RSVP-트래픽 엔지니어링(TE) 및 LDP를 위한 Point-to-Multipoint 확장을 위한 Point-to-Multipoint 확장입니다. 이들 구축 시나리오는 RFC 6826, Point-to-Multipoint 및 Multipoint-to-Multipoint Label Switched Path를위한 멀티포인트 LDP 대역 내 신호 전송에서 논의됩니다. 이 기능 개요는 LDP에 대한 점대다점 확장으로 제한됩니다.

M-LDP의 작동 방식

M-LDP 시그널링의 레이블 바인딩

LDP에 대한 멀티포인트 확장은 기능 광고, 레이블 매핑 및 시그널링 절차와 함께 FEC(Point-to-Multipoint Forwarding Equivalence Class) 요소(RFC 5036, LDP 사양에서정의)를 사용합니다. FEC 요소에는 IP 주소인 LSP 루트의 아이디어와 리프 노드를 함께 그룹화하는 선택자인 "불투명" 값이 포함됩니다. 불투명 값은 중간 노드에 투명하지만 LSP 루트에 대한 의미가 있습니다. 모든 LDP 노드는 FEC에서 발견되는 루트 IP 주소로 가장 짧은 경로에 있는 업스트림 LDP 노드에 로컬 수신 레이블 바인딩을 광고합니다. 레이블 바인딩을 수신하는 업스트림 노드는 자체 로컬 Label 및 outgoing 인터페이스를 생성합니다. 이 레이블 할당 프로세스는 여러 개의 전송 브랜치가 있는 경우 패킷 복제가 될 수 있습니다. 그림과 같이, LDP 노드는 동일한 업스트림 노드를 공유하는 다운스트림 노드가 발견될 경우 동일 불투명 값을 위한 레이블 그림 18 바인딩을 병합합니다. 이를 통해 점대다점 LSP 및 레이블 보존을 효과적으로 구축할 수 있습니다.

그림 18: M-LDP 시그널링의 레이블 바인딩M-LDP 시그널링의 레이블 바인딩
M-LDP in PIM-Free MPLS Core

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

그림 19: PIM-Free 코어에서 M-LDP MPLS 샘플PIM-Free 코어에서 M-LDP MPLS 샘플
구성

LER(Label-Edge Router)의 구성 명령문을 통해 PIM은 LER이 PIM 업스트림 이웃을 감지하지 못하면 업스트림 이웃에 대한 M-LDP 대역 내 시그널링을 사용할 수 있습니다. mldp-inband-signalling LSP MPLS 정적 구성은 정책을 사용하여 PIM 구성에 포함됩니다. 이는 IBGP가 코어 사이트에서 제공되지 못하거나 IBGP 기반 LSP 루트 감지를 까다로워하는 경우 필요합니다.

몇 가지 예를 들면 다음과 같습니다.

PIM 기반 코어 내 M-MPLS LDP

기존 IPTV 서비스를 네이티브 IP 멀티캐스트에서 MPLS 릴리스 14.1에서부터 시작하여 중단을 최소화하면서 PIM에서 M-LDP Point-to-Multipoint LSP로 원활하게 전환해야 합니다. Junos OS 유사한 M-LDP 토폴로지와는 다른 그림 20그림 19 시나리오를 보여줍니다. 코어는 PIM으로 활성화되어 하나의 소스 스트리밍으로 모든 IPTV 채널을 지원합니다. TV 채널은 그룹 주소로 식별되는 각 채널을 통해 ASM 스트림으로 전송됩니다. 이전에는 이러한 채널을 IP 스트림으로 코어에서 스트리밍하고 PIM을 사용하여 시그널로 전송되었습니다.

그림 20: PIM 지원 코어에서 M-LDP MPLS 샘플PIM 지원 코어에서 M-LDP MPLS 샘플

이 시나리오에서 구성하면 M-LDP 시그널링은 소스 쪽으로 PIM이 인접한 경우만 mldp-inband-signaling 시작됩니다. 그러나, PIM이 egress PE의 업스트림 인터페이스에서 비활성화되지 않는 경우 항상 소스 쪽으로 PIM 이웃이 존재하기 때문에 PIM은 M-LDP보다 우선 순위를 취하며 M-LDP는 효과가 없습니다.

구성

M-LDP 업스트림을 사용하는 스트림과 기존 PIM 업스트림을 사용하는 기타 스트림을 사용하는 스트림이 소수의 채널을 M-LDP MPLS 채널을 M-LDP로 점진적으로 마이그레이션하기 위해 M-LDP 인밴드 시그널링을 위한 정책 필터의 그룹 기반 필터와 함께 구성 명령문을 selected-mldp-egress 포함합니다.

주:

M-LDP 인밴드 시그널링 정책 필터는 명령문 또는 명령문 또는 이들 둘의 조합을 포함할 source-address-filterroute-filter 수 있습니다.

몇 가지 예를 들면 다음과 같습니다.

주:

위 구성의 몇 가지 제한은 다음과 같습니다.

  • selected-mldp-egress명령문은 LER에서만 구성해야 합니다. 비-egress PIM 라우터에서 명령문을 구성하면 경로 설정 selected-mldp-egress 실패가 발생할 수 있습니다.

  • PIM 업스트림에서 M-LDP 업스트림으로 트래픽을 전환하고 그 반대로 정책 변경이 수행되는 경우, 컨트롤 플레인에서 브레이크-화(break-and-make) 메커니즘이 수행될 때 패킷 손실이 예상될 수 있습니다.

용어

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

점대점 LSP

ingress Label-Switched 라우터(레이블 스위칭 라우터(LSR)) 1개와 레이블 스위칭 라우터(LSR).

멀티포인트 LSP

점대다점(point-to-multipoint) 또는 멀티포인트 LSP 중 하나에 있습니다.

점대다점 LSP

하나 이상의 ingress 레이블 스위칭 라우터(LSR) LSRS를 가지는 LSP

다지점 대 점 LSP

하나 이상의 ingress LSRS와 하나의 고유한 Egress 레이블 스위칭 라우터(LSR).

멀티포인트에서 멀티포인트 LSP

LSP의 모든 노드에서 전송되는 트래픽이 다른 노드로 전달될 수 있는 노드 집합을 연결하는 LSP입니다.

Ingress 레이블 스위칭 라우터(LSR)

특정 LSP에 대한 레이블 스위칭 라우터(LSR) 수신은 LSP를 따라 레이블 스위칭 라우터(LSR) 패킷을 보낼 수 있는 패킷입니다. 멀티포인트에서 멀티포인트 LSP로의 LSP에는 여러 개의 ingress LSRS가 있을 수 있습니다. 점대다점 LSP에는 오직 하나의 노드가 있으며 해당 노드를 종종 루트 노드라고 합니다.

발신 레이블 스위칭 라우터(LSR)

특정 LSP의 레이블 스위칭 라우터(LSR) 전송은 추가 처리를 레이블 스위칭 라우터(LSR) 데이터 패킷을 제거할 수 있는 패킷입니다. 점대점(point-to-point) 및 다지점(multipoint-to-point) LSP는 단일 Egress 노드만 있습니다. Point-to-Multipoint 및 Multipoint-to-Multipoint LSP는 여러 개의 Egress 노드를 지을 수 있습니다.

전송 레이블 스위칭 라우터(LSR)

레이블 스위칭 라우터(LSR) 업스트림 네트워크와 하나 이상의 직접 연결된 다운스트림 LSRS를 통해 멀티포인트 LSP의 루트에 도달할 수 있는 레이블 스위칭 라우터(LSR) 있는 네트워크입니다.

Bud 레이블 스위칭 라우터(LSR)

레이블 스위칭 라우터(LSR) egress이지만 하나 이상의 다운스트림 LSRS를 직접 연결한 네트워크입니다.

리프 노드

point-to-multipoint LSP의 레이블 스위칭 라우터(LSR) 또는 버드 시드(egress)나 버드미티(bud) 중 하나를 제공합니다. 멀티포인트-멀티포인트 LSP의 맥락에서, 레이블 스위칭 라우터(LSR) 동일한 멀티포인트-레이블 스위칭 라우터(LSR) 위한 ingress 및 egress 를 의미하며, 버드유니(bud) 레이블 스위칭 라우터(LSR).

Ingress Join Translation 및 Pseudo Interface Handling

수신 LER에서 LDP는 PIM에 대역 내 시그널링을 통해 수신된 (S,G) 메시지에 대해 이 메시지를 제공합니다. PIM은 의사 인터페이스와 연계된 각(S,G) 메시지를 연결합니다. 그 다음, 최단 경로 트리(SPT) 조인 메시지가 소스로 시작됩니다. PIM은 이를 새로운 유형의 로컬 수신기로 취급합니다. LSP가 해체될 때 PIM은 LDP의 통보에 따라 이 로컬 수신기를 제거합니다.

Ingress Splicing

LDP는 각(S,G) 엔트리와 연관될 다음 홉을 PIM에 않습니다. PIM은 LDP Next Hop 및 기타 PIM 수신기를 통해 PIM(S,G) 멀티캐스트 경로를 설치합니다. 다음 홉은 로컬 리시버의 복합 넥스트 홉 + PIM 다운스트림 이웃 목록 + LDP 터널을 위해 하위 수준 다음 홉입니다.

역방향 경로 포우링

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

PIM은 다음과 같은 조건이 모두 TRUE인 경우 M-LDP 대역 내 시그널링을 수행합니다.

  • 소스 쪽으로 PIM 이웃이 없습니다.

  • M-LDP 대역 내 시그널링 명령문이 구성됩니다.

  • 다음 홉은 BGP(Border Gateway Protocol) 통해 학습되거나 정적 매핑(M-LDP 대역 내 시그널링 정책에 지정)에 표시됩니다.

그렇지 않은 경우, LSP 루트 감지에 실패하면 PIM은 RPF 상태가 해결되지 않은 상태로 (S,G) 엔트리를 유지하게 됩니다.

PIM RPF는 유니캐스트 라우팅 정보 변경 시 이 소스 주소를 등록합니다. 따라서 소스로 향하는 경로가 변경된 경우 RPF 재계산이 재발합니다. BGP(Border Gateway Protocol) 프로토콜 다음 홉도 모니터링하여 LSP 루트의 변경을 모니터링합니다. 이러한 변경은 짧은 기간 동안 트래픽 중단을 일으킬 수 있습니다.

LSP 루트 감지

RPF 작동이 M-LDP 대역 내 시그널링 업스트림에 대한 필요성을 감지하면 LSP 루트(ingress)가 탐지됩니다. 이 루트는 LDP LSP 시그널링에 대한 매개 변수입니다.

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

  1. 기존 정적 구성이 소스 주소를 지정하면 구성에서 루트가 취해지습니다.

  2. 유니캐스트 라우팅 테이블에서 룩업이 수행됩니다. 소스 주소가 발견될 경우 소스를 향한 프로토콜 다음 홉이 LSP 루트로 사용됩니다.

    Junos OS Release 16.1에 앞서, M-LDP Point-to-Multipoint LSP는 ingress 레이블 스위칭 라우터(LSR). 이 루트 주소는 단일 IGP 통해 도달할 수 있어 M-LDP 점대다점 LSP를 단일 자율 시스템으로 국한합니다. 루트 주소가 IGP 통해 도달하지 못하고 BGP(Border Gateway Protocol) 통해 도달할 수 없는 경우, BGP(Border Gateway Protocol) LSP를 통해 BGP(Border Gateway Protocol) MPLS 경로가 재확인되는 경우, ingress 레이블 스위칭 라우터(LSR) 루트 주소로 향하는 신호가 해당 지점에서 다시 전송되지 레이블 스위칭 라우터(LSR).

    다음과 같은 애플리케이션에 사용할 수 있는 여러 자율 시스템 전반에서 이러한 비 세그먼트 분할(point-to-multipoint) LSP가 시그널로 전송될 필요가 있습니다.

    • 세그먼트가 아닌 점대다점 LSP가 있는 AS 간 MVPN입니다.

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

    • 비 세그먼트 분할(point-to-multipoint) LSP를 통해 영역 간 MVPN 또는 M-LDP 인밴드 시그널링(원활한 MPLS 멀티캐스트).

    Junos OS Release 16.1에서부터 M-LDP는 루트 주소가 BGP(Border Gateway Protocol) 경로인 경우 ASBR 또는 전송 또는 egress에서 point-to-multipoint LSP를 시그널링할 수 MPLS 있습니다.

Egress Join Translation 및 Pseudo Interface Handling

egress LER에서 PIM은 LSP 루트와 함께 신호 전송을 위해 (S,G) 메시지의 LDP에 이를 전송합니다. PIM은 이(S,G) 메시지를 위한 업스트림 인터페이스로 의사 인터페이스를 만듭니다. (S,G) prune 메시지가 수신되면 이 연결은 제거됩니다.

Egress Splicing

다운스트림 사이트의 (S,G) 참여 메시지가 수신되는 코어 네트워크의 egress 노드에서 이 조인 메시지는 M-LDP 대역 내 시그널링 매개 변수로 변환되고 LDP에게 통보됩니다. 또한, LSP 종료는 (S,G) 엔트리가 손실되거나, LSP 루트가 변경되거나, PIM neighbor를 통해 (S,G) 엔트리에 도달할 때 발생합니다.

지원되는 기능

M-LDP 대역 내 시그널링의 경우 Junos OS 기능을 지원할 수 있습니다.

  • LDP 경로를 통해 PIM 다음 홉의 Egress Splicing

  • LDP 다음 홉을 통해 PIM 경로의 Ingress Splicing

  • PIM 조인트 메시지를 LDP 점대다점 LSP 설정 매개 변수로 변환

  • PIM 참여 메시지를 설정하기 위해 M-LDP 대역 내 LSP 매개 변수 변환

  • 정적으로 구성되어 BGP(Border Gateway Protocol) 프로토콜 다음 홉 기반 LSP 루트 감지

  • PIM(S,G) PIM(Source-Specific Multicast) 및 ASM(Anysource Multicsast) 범위

  • ingress 및 egress LE의 구성 명령문을 통해 에지 라우터의 역할을 할 수 있도록 지원

  • IGMP LE에 대한 메시지 조인

  • 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(opaque type-length-value) 인코딩으로 수행됩니다. 점대다점 FEC 요소는 루트 노드 주소로 구성됩니다. 차세대 멀티캐스트 VPN(NGEN MVPNs)의 경우, Point-to-Multipoint LSP는 루트 노드 주소와 LSP ID로 식별됩니다.

발신 LER 기능

egress LER에서 PIM은 다음 정보를 사용하여 LDP를 트리거하여 점대다점 LSP를 생성합니다.

  • 루트 노드

  • (S,G)

  • 다음 홉

PIM은 멀티캐스트 트리의 소스를 기반으로 루트 노드를 검색합니다. 이(S,G) 엔트리에 대해 루트 주소가 구성되면 구성된 주소가 Point-to-Multipoint LSP 루트로 사용됩니다. 그렇지 않은 경우 라우팅 테이블은 소스로의 경로를 찾아보는 데 사용됩니다. 멀티캐스트 트리의 소스로 이동하는 경로가 BGP(Border Gateway Protocol) 학습 경로인 경우, PIM은 BGP(Border Gateway Protocol) 다음 홉 주소를 검색하고 이를 Point-to-Multipoint LSP의 루트 노드로 사용합니다.

LDP는 루트 노드를 기반으로 업스트림 노드를 찾고, 레이블을 할당하고, 업스트림 노드에 레이블 매핑을 전송합니다. LDP는 인밴드 M-LDP 시그널링을 위해 PHP(Penultimate Hop Popping)를 사용하지 않습니다.

멀티캐스트 트리 소스에 대한 루트 주소가 변경되면 PIM은 Point-to-Multipoint LSP를 삭제하고 LDP를 트리거하여 새로운 Point-to-Multipoint LSP를 생성합니다. 이 경우 송신 인터페이스 목록이 NULL이 되고 PIM은 LDP를 트리거하여 Point-to-Multipoint LSP를 삭제하고 LDP는 업스트림 노드로 Label Withdraw 메시지를 전송합니다.

전송 레이블 스위칭 라우터(LSR) 기능

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

Ingress LER 기능

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

  • (S,G)

  • 플러드 넥스 홉(Flood Next

그런 다음 PIM은 포우링 상태를 설치합니다. 새 브랜치가 추가되거나 삭제되면 플러드 넥스 홉(flood next hop)이 그에 따라 업데이트됩니다. 레이블이 제거되고 있는 경우 모든 브랜치가 삭제되면 LDP는 PIM으로 업데이트된 정보를 전송합니다. 업스트림과 다운스트림 이웃 사이에 여러 링크가 있는 경우 Point-to-Multipoint LSP는 로드 스트레인되지 않습니다.

예를 들면 다음과 같습니다. Point-to-Multipoint LSP를 위한 멀티포인트 LDP 대역 내 신호 구성

이 예에서는 멀티캐스트 트래픽을 위한 멀티포인트 LDP(M-LDP) 대역 내 시그널링을 구성하거나 PIM(Protocol Independent Multicast) 프로토콜을 확장하거나 PIM을 대체하는 방법을 보여줍니다.

요구 사항

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

  • Junos OS Release 13.2 이상

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

  • PTX 시리즈 패킷 전송 라우터 레이블 스위칭 라우터의 역할을 합니다.

  • T 시리즈 코어 라우터를 위한 코어 라우터

주:

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

이 예제를 구성하기 전에 장치 초기화 이외에는 특별한 구성이 필요하지 않습니다.

개요

CLI 빠른 구성 에 있는 모든 디바이스의 구성을 그림 21 보여줍니다. 이 #d517e60__d517e614 섹션에서는 Device EgressPE의 단계를 설명합니다.

그림 21: Point-to-Multipoint LSP를 위한 M-LDP 대역 내 신호 전송 토폴로지 예Point-to-Multipoint LSP를 위한 M-LDP 대역 내 신호 전송 토폴로지 예

구성

절차
CLI 빠른 구성

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

디바이스 src1

디바이스 IngressPE

디바이스 EgressPE

디바이스 p6

디바이스 pr3

디바이스 pr4

디바이스 pr5

단계별 절차

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

디바이스 EgressPE를 구성하려면:

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

    코어 MPLS 인터페이스에서 네트워크 구성을 활성화합니다. egress Next Hops에서 네트워크 기능을 활성화할 MPLS.

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

    테스트 목적으로 이 예에는 정적 그룹 및 소스 주소가 포함됩니다.

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

  4. 구성 BGP(Border Gateway Protocol).

    BGP(Border Gateway Protocol) 프로토콜이기 때문에 필요한 라우팅 정책을 구성하고 적용하기도 합니다.

    예를 들어 정적 경로를 다른 경로로 내보낼 수도 BGP(Border Gateway Protocol).

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

  6. 구성 최단 경로 우선(OSPF).

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

  8. LSP를 위한 점대다점 MPLS 지원.

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

  10. 이 디바이스가 RP(PIM Rendezvous Point)의 역할을 하도록 RP 설정을 구성합니다.

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

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

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

결과

구성 모드에서 , 및 명령어를 입력하여 show interfacesshow protocolsshow policy-optionsshow routing-options 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

디바이스 EgressPE

마찬가지로 다른 Egress 디바이스를 구성합니다.

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

확인

구성이 제대로 작동하고 있는지 확인합니다.

PIM Join 상태 확인
목적

PIM 참여(join) 상태 정보를 표시해 M-LDP 대역 내 업스트림 및 다운스트림 세부 정보를 검증합니다. ingress 디바이스에서 다운스트림 인터페이스에 대한 show pim join extensivePseudo-MLDP 명령어가 표시됩니다. egress에서 업스트림 인터페이스에 대한 show pim join extensivePseudo-MLDP 명령어가 표시됩니다.

실행

작동 모드에서 명령어를 show pim join extensive 입력합니다.

PIM 소스 확인
목적

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

실행

작동 모드에서 명령어를 show pim source 입력합니다.

LDP 데이터베이스 검사
목적

명령어가 예상 show ldp database 루트-to-S,G 바인딩을 표시하는지 확인

실행
MPLS 경로 정보 찾고
목적

점대다점 FEC 정보를 표시합니다.

실행
LDP 트래픽 통계 확인
목적

점대다점 LSP에 대한 데이터 트래픽 통계를 모니터링합니다.

실행

LDP와 세그먼트 라우팅의 상호 작동성을 위한 LDP 매핑 서버 개요

세그먼트 라우팅이 단계적으로 구축되는 LDP 네트워크에서는 LDP 또는 세그먼트 라우팅만 지원하는 디바이스 섬이 있을 수 있습니다. 디바이스가 상호 연동하려면 세그먼트 라우팅 네트워크의 모든 디바이스에서 LDP 매핑 서버 기능을 구성해야 합니다.

LDP 매핑 서버 기능은 LDP 또는 ISIS를 최단 경로 우선(OSPF) 구현됩니다.

LDP와 세그먼트 라우팅의 상호 최단 경로 우선(OSPF)

최단 경로 우선(OSPF) 사용하여 LDP와의 상호 연동성을 구현하기 위해 모든 LDP 프리픽스에 대한 범위 유형, 길이, 값(TLV)이 있는 확장된 LSA(Link-State Advertisement)가 생성되어 prefix에 해당하는 경로 매핑이 inet.3 및 mpls.0 라우팅 테이블에 설치됩니다.

그림 22 는 세그먼트 라우팅 디바이스와 LDP 디바이스의 상호 연동성을 설명하는 데 사용되는 단순한 LDP 최단 경로 우선(OSPF). 이 토폴로지에는 LDP-세그먼트 라우팅 마이그레이션을 위한 6개의 디바이스(Devices R1, R2, R3, R4, R5, R6)가 있습니다.

그림 22: LDP를 사용하는 LDP와 세그먼트 라우팅의 상호성이 있는 LDP 토폴로지 최단 경로 우선(OSPF)LDP를 사용하는 LDP와 세그먼트 라우팅의 상호성이 있는 LDP 토폴로지 최단 경로 우선(OSPF)

위 토폴로지에서 Devices R1, R2 및 R3은 세그먼트 라우팅만 지원하며, Devices R5 및 R6는 LDP만 지원하며, Device R4는 LDP 및 세그먼트 라우팅을 모두 지원합니다. 디바이스 R1은 상호 연동 문제로 인하여 Device R6와 상호 연동할 수 없습니다.

LDP 지원 장비와 세그먼트 라우팅 장치 간의 상호 연동을 지원하기 위해 세그먼트 라우팅 네트워크 세그먼트 내 장치 인터페이스가 LDP 매핑 서버로 구성됩니다. 현재, 매핑 서버는 계층 수준에서 Prefix를 [edit routing-options source-packet-routing] 구성합니다. 이 기능을 통해 LDP 매핑 서버 구성이 계층 수준에서 적용될 경우 모든 LDP 프리픽스에 대한 범위 TLV가 있는 새로운 확장 Prefix LSA가 에 의해 광고되는 [edit protocols ospf] 최단 경로 우선(OSPF). 세그먼트 라우팅이 가능한 디바이스가 확장된 Prefix 범위 TLV를 분석하고 prefix에 해당하는 매핑 경로가 inet.3 및 mpls.0 라우팅 테이블에 설치됩니다.

예를 들어, Device R2(세그먼트 라우팅 네트워크 내)가 LDP 매핑 서버인 경우 다음 구성이 그림 22 포함됩니다.

주:

IP 주소는 LDP 네트워크에서 장비의 루프백 주소입니다(이 start-prefix 예에서는 Device R5).

LDP 매핑 서버 구성이 Device R2에서 커밋될 때 확장된 prefix 범위 TLV는 전체 영역으로 플러드 최단 경로 우선(OSPF) 있습니다. 세그먼트 라우팅(Devices R1, R2 및 R3)이 가능한 디바이스는 SID(Segment ID) 인덱스를 최단 경로 우선(OSPF) 지정 루프백 주소에 대한 세그먼트 라우팅 경로를 설치할 수 있습니다. SID 인덱스는 세그먼트 라우팅 디바이스에 의해 mpls.0 라우팅 테이블에서도 업데이트됩니다.

Release Junos OS 릴리스부터 19.1R1 세그먼트 라우팅-LDP 경계 라우터는 세그먼트 라우팅 트래픽을 LDP 넥스홉으로 스티치하고 그 반대의 경우도 마찬가지입니다.

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

  • Prefix 충돌은 소스 구성에서만 탐지됩니다. Prefix 범위 충돌이 있는 경우 하위 라우터 ID의 Prefix SID가 우위를 니다. 이러한 경우 시스템 로그 오류 RPD_OSPF_PFX_SID_RANGE_CONFLICT 메시지—가 생성됩니다.

  • IPv6 Prefix는 지원되지 않습니다.

  • 자율 시스템(AS)을 위한 세그먼트 라우팅 매핑 서버가 생성한 최단 경로 우선(OSPF) 확장 Prefix Opaque LSA의 플러링은 지원되지 않습니다.

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

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

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

  • 세그먼트 라우팅 매핑 서버 기본 설정 TLV는 지원되지 않습니다.

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

ISIS를 사용하여 LDP와의 세그먼트 라우팅의 상호 연동성을 구현하려면 각각 프로토콜 ISIS 및 LDP에서 서버-클라이언트 구성이 필요하며, inet.3 또는 inet.0 라우팅 테이블의 경로는 LDP LSP를 사용하는 세그먼트 라우팅 LSP의 스티치에 사용되거나 반대로 사용됩니다.

그림 23 는 LDP 매핑 서버-클라이언트 기능을 사용해 세그먼트 라우팅 디바이스와 LDP 디바이스의 상호 연동성을 설명하는 데 사용되는 단순한 LDP 네트워크 토폴로지입니다. 이 토폴로지에는 4개의 PE(Provider Edge) 디바이스(Devices PE1, PE2, PE3, PE4)와 4개의 P(Provider) 디바이스(Devices P5, P6, P7, P8)가 있습니다.

그림 23: ISIS를 사용한 LDP와 세그먼트 라우팅의 상호 연동성이 있는 LDP 토폴로지 샘플ISIS를 사용한 LDP와 세그먼트 라우팅의 상호 연동성이 있는 LDP 토폴로지 샘플

디바이스 PE3, PE4, P6, P7 및 P8은 LDP 지원 장치입니다. 디바이스 PE1, PE2, P5 및 P6는 세그먼트 라우팅 글로벌 블록(SRGB) 값이 100 및 200인 세그먼트 라우팅과 각각 101, 102,105 및 106의 SD(Node Segment IDs) 값을 사용할 수 있습니다.

디바이스 PE3 및 Device PE1에서 지속적인 MPLS 터널링되는 서비스 플로우를 터널링하려면 세그먼트 라우팅 및 LDP를 지원하는 디바이스 제도가 상호 연동되어야 합니다.

LDP Mapping Client Functionality (LDP to Segment Routing)

LDP 클라이언트 기능은 LDP-세그먼트 라우팅 그림 23 매핑입니다. Device P6에서 LDP egress 정책은 왼쪽 세그먼트 라우팅 네트워크에서 모든 노드 SD와 Prefix SDSD를 광고하도록 구성됩니다. 그 결과, Device P6에서 LDP는 Device PE1, PE2 및 P5를 Device P7에 대한 egress FEC 레이블 바인딩으로 광고합니다.

Device PE3는 Protocol Next Hop으로 Device PE1을 통해 서비스 경로를 학습했습니다. Device PE3에는 PE1 FEC에 대한 P8 넥스트 홉에서 LDP 레이블 바인딩이 있습니다. 결과적으로 Device PE3는 전통적인 LDP 동작에 따라 서비스 패킷을 Device P8로 전송합니다. Device P8은 PE1 FEC를 위한 P7 Next Hop에서 LDP 레이블 바인딩을 가지기 때문에, Device P8은 전통적인 LDP 동작에 따라 Device P7으로 전달됩니다.

디바이스 P7에는 P6 Next Hop PE1 FEC에서 LDP 레이블 바인딩이 있습니다. 그 결과, Device P7은 전통적인 LDP 동작에 따라 Device P6으로 전달됩니다.

Device P6that은 PE1 FEC를 위한 LDP egress의 역할을 합니다. PE1 FEC에 대한 수신 Egress LDP 레이블을 동일한 세그먼트 라우팅 노드 SID(이 예에서는 101)로 교체하여 트래픽을 Device P5로 전달합니다.

Device P5는 101 SID를 파프하여 Device PE1이 노드 세그먼트 101에 Penultimate-pop 플래그 집합을 광고한 다음, Device PE1로 트래픽을 전달한 것으로 계산합니다. 디바이스 PE1은 터널링된 패킷을 생성하고 서비스 레이블을 처리합니다.

그 결과, 엔드-MPLS 터널은 Device PE3에서 Device P6로의 LDP LSP와 Device P6에서 Device PE1까지의 관련 노드 세그먼트에서 구축됩니다.

LDP Mapping Server Functionality (Segment Routing to LDP)

LDP 서버 기능은 의 좌측에서 우측으로 트래픽 흐름인 세그먼트 라우팅을 LDP에 매핑하는 그림 23 것입니다. Device P6에서 매핑 서버 Prefix 구성은 계층 [edit routing-options source-packet-routing] 수준에 포함됩니다. 특정 IGP 적용하면 LDP 네트워크의 모든 LDP FEC 레이블 바인딩에 대한 레이블 바인딩 유형, 길이 및 값(TLV)이 inet.3 LDP 경로로 표시됩니다.

디바이스 P6는 SRMS(Segment Routing Mapping Server)의 역할을 할 수 있으며( P7, 107), (P8, 108), (PE3, 103), (PE4, 104) 및 (P7, 107) 매핑을 표시합니다. 디바이스 PE3에서 세그먼트 라우팅이 지원되는 경우 노드 SID 103이 Device PE3에 구성된 것입니다. Device PE3은 세그먼트 라우팅을 지원하지기 때문에 정책은 Device P6의 SRMS에서 구성됩니다. Device P6는 매핑에 대한 광고를 담당합니다.

이러한 매핑 서버 광고는 세그먼트 라우팅 디바이스만 이해할 수 있습니다. 세그먼트 라우팅 디바이스는 노드 자체에 의해 노드 세그먼트가 MPLS 방법을 정확히 알 수 있는 데이터 플레인에 관련 노드 SID를 설치합니다. 예를 들어, Device PE1은 Device PE3가 SID 103을 광고한 경우와 정확히 똑같은 P5 Next Hop으로 노드 SID 103을 설치합니다.

Device PE1에는 프로토콜 넥스 홉(next hop)으로 PE3이 있는 서비스 경로가 있습니다. Device PE1에는 해당 경로에 대한 노드 IGP - 103과 P5 넥스 홉이 있습니다. 결과적으로 Device PE1은 서비스 패킷을 Device P5로 전송하며, 이는 서비스 레이블인 하단 레이블과 SID 103인 상단 레이블입니다. Device P5는 103을 103으로 교체하고 Device P6로 전달합니다. Device P6의 다음 홉은 IGP 라우팅할 수 없는 경로 PE3입니다. (디바이스 P7은 세그먼트 라우팅 기능을 광고하지 않습니다). 그러나, Device P6에는 동일한 FEC(예: LDP Label 1037)에 대한 다음 홉에서 LDP 레이블 바인딩이 있습니다. 그 결과, Device P6에서, IGP 103을 103으로 교체하고 Device P7으로 전달합니다.

Device P7은 이 라벨을 Device P8에서 수신된 LDP-Label으로 교체한 다음, Device P8로 전달합니다. LDP 레이블은 Device P8에 의해 터프되어 Device PE3로 전달됩니다.

Device PE3는 터널링된 패킷을 수신하고 서비스 레이블을 처리합니다. 엔드-엔드 MPLS 터널은 Devices PE1에서 P6까지의 세그먼트 라우팅 노드와 Devices P6에서 PE3까지의 LDP LSP에서 구축됩니다.

Segment Routing to LDP Stitching

IGP 세그먼트 라우팅 LSP의 IP Next Hop이 세그먼트 라우팅을 지원하지 않는 경우, IGP inet.3 라우팅 테이블을 보고 동일한 prefix에 LDP LSP가 있는지 볼 수 있습니다. LDP LSP가 있는 경우 IGP 세그먼트 라우팅 도메인에서 LDP 도메인으로 트래픽을 스위치하는 MPLS 전송 경로를 프로그래밍하여 세그먼트 라우팅 LSP를 LDP LSP로 전환합니다.

그림 24 상호 연동을 위한 세그먼트 라우팅과 LDP LSP의 스티치에 대해 설명하고 있습니다.

그림 24: 세그먼트 라우팅 및 LDP LSP 스티치세그먼트 라우팅 및 LDP LSP 스티치

토폴로지에서 Device PE3는 LDP 지원이 가능하고 세그먼트 라우팅을 지원하지 않습니다. 세그먼트 라우팅 도메인의 매핑 서버는 디바이스 P7, P8 및 PE4에 레이블 바인딩 TLV를 광고할 수 있습니다. 이러한 시나리오에서 Device PE1은 Device PE4에 도달하기 위해 Prefix SID와 원격 레이블 바인딩 TLV 및 SID를 모두 수용할 수 있습니다. 그러나 Device PE1은 장비 PE4에 대한 ingress 세그먼트 라우팅 경로를 프로그래밍하는 동시에 원격 레이블 바인딩 TLV에서 Prefix SID를 선호합니다. 결과적으로, Device PE1은 세그먼트 라우팅 LSP 엔드-엔드를 사용하여 디바이스 PE4로 트래픽을 전송하고, 디바이스 PE3로 트래픽을 전송하는 동시에 세그먼트 라우팅-LDP 스티치(stitching)를 사용합니다.

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

  • 레이블 바인딩 TLV를 위한 Penultimate-hop popping 행동은 지원되지 않습니다.

  • 레이블 바인딩 TLV의 범위 프리픽스 광고는 지원되지 않습니다.

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

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

  • NSR(Nonstop Active Routing) 및 GRES(graceful 라우팅 엔진 Switchover)는 지원되지 않습니다.

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

  • RFC 7794 확장 IPv4를 IS-IS(Intermediate System to Intermediate System) Prefix 속성은 지원되지 않습니다.

  • 스티치 노드에서 LDP 경로를 Prefix-sid로 재배포하는 것은 지원되지 않습니다.

기타 LDP 속성 구성

다음 섹션에서는 다양한 LDP 속성의 구성 방법을 설명합니다.

경로 메트릭을 사용할 LDP IGP 구성

기본 LDP 경로 메트릭(기본 LDP 경로 메트릭은 1)이 아니라 LDP 경로에 대해 내부 게이트웨이 프로토콜(IGP) 경로 메트릭을 사용하려는 경우 명령문을 track-igp-metric 사용합니다.

경로 메트릭을 IGP 명령문을 track-igp-metric 포함해야 합니다.

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

inet.0 라우팅 테이블에 Ingress 경로 추가 방지

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

주:

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

inet.0 라우팅 테이블에서 ingress 경로를 생략하기 위해 다음 명령문을 no-forwarding 포함합니다.

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

다중 인스턴스 LDP 및 Carrier-of-CarrierS VPN

여러 LDP 라우팅 인스턴스를 구성하여 LDP를 사용하여 서비스 제공업체 에지(PE) 라우터에서 고객 캐리어급 고객 에지(고객 에지(CE)) 라우터에 대한 캐리어급 VPN에서 레이블을 광고할 수 있습니다. 이는 통신 사업자 고객들이 PE 라우터로의 전체 인터넷 경로를 제한하기를 원하는 기본 ISP(Internet Service Provider)인 경우 특히 유용합니다. 통신 사업자 고객은 LDP 대신 BGP(Border Gateway Protocol) 인터넷에서 다른 내부 라우터를 보호합니다. 다중 인스턴스 LDP는 통신 사업자 고객이 Layer 2 또는 Layer 3 VPN 서비스를 고객에게 제공하고자 할 때에도 유용합니다.

캐리어급 VPN을 위해 여러 LDP 라우팅 인스턴스를 구성하는 방법에 대한 예는 Label Distribution Protocol User Guide의 다중인스턴스를 참조하십시오.

Ultimate-hop 라우터에서 MPLS LDP에 대한 구성

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

궁극적인 홉(hop) popping을 구성하기 위해 다음 explicit-null 문을 포함해야 합니다.

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

주:

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

라벨에 대한 자세한 내용은 MPLS Label Overview 및 MPLS 를 참조하십시오.

RSVP 설정 LSP에서 LDP 활성화

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

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

이기종 네트워크에서 RSVP 설정 LSP에서 LDP 지원

다른 벤더들은 루프백 주소에 대해 최단 경로 우선(OSPF) 1 지표를 사용하는 경우도 있습니다. 주니퍼 네트웍스 라우터는 루프백 주소에 최단 경로 우선(OSPF) 지표 0을 표시합니다. 이기종 네트워크에 RSVP LSP에 LDP 터널링을 구축할 때 RSVP 메트릭을 수동으로 구성해야 할 수 있습니다.

주니퍼 네트웍스 라우터가 RSVP 터널을 통해 다른 벤더의 라우터에 연결되는 경우, LDP 터널링이 활성화될 경우 기본적으로 주니퍼 네트웍스 라우터는 RSVP 터널을 사용하여 다른 벤더의 Egress 라우터의 LDP 대상 다운스트림으로 트래픽을 라우팅하지 않을 수 있습니다. RSVP 경로가 물리적 경로보다 1 큰 최단 경로 우선(OSPF).

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

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

  • [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 서명 구성

LDP TCP 연결을 위한 MD5 시그니처를 구성하여 스푸핑된 TCP 세그먼트를 LDP 세션 연결 스트림으로 도입하는 것을 방지할 수 있습니다.

MD5 서명 옵션을 사용하는 라우터는 인증이 필요한 각 피어에 대한 암호로 구성됩니다. 암호는 암호화되어 저장됩니다.

서로 다른 보안 시그니처로 피어링 인터페이스가 구성된 경우에도 LDP hello Adjacencies를 만들 수 있습니다. 그러나 TCP 세션은 인증할 수 없습니다.

릴리스 Junos OS 16.1R1 LDP 세션에 대한 해시드 메시지 인증 코드(HMAC) 및 MD5 인증에 대한 지원은 세션당 구성에서 서브넷 일치(즉, 가장 긴 Prefix-match) 구성으로 확장됩니다.

서브넷 매치(subnet-match) 인증을 지원하기 때문에 TLDP(Targeted LDP) 세션의 인증을 유연하게 구성할 수 있어 LFA(Remote Loop-Free Alternate) 및 FEC 129 의사회선의 구축이 용이합니다.

LDP TCP 연결을 위한 MD5 시그니처를 구성하기 위해 다음과 같은 session-groupauthentication-key 명령문을 포함합니다.

명령문을 사용하여 LDP 세션의 원격 종료에 대한 주소를 session-group 구성합니다.

암호는 md5-authentication-key 최대 69자까지 문자를 사용할 수 있습니다. 문자에는 ASCII 문자열이 포함되어 있습니다. 공백이 있는 경우 모든 문자를 견적 마크에 동봉합니다.

또한 LDP 라우팅 프로토콜에 대한 인증 키 업데이트 메커니즘을 구성할 수도 있습니다. 이 메커니즘을 사용하면 최단 경로 우선(최단 경로 우선) 및RSVP(ResourceReservation SetupProtocol)와같은 관련 라우팅 및 시그널링 프로토콜의 최단 경로 우선(OSPF) 없이 인증 키를 업데이트할 수 있습니다.

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

LDP 라우팅 프로토콜에 대한 인증 키 업데이트 메커니즘을 구성하기 위해 프로토콜을 인증 키와 연결하기 위한 계층 수준에서 authentication-key-chain[edit protocols ldp] 명령문을 [edit security authentication-key-chains] 포함합니다. 또한 계층 수준 명령문을 포함해 authentication-algorithm algorithm 인증 [edit protocols ldp] 알고리즘을 구성해야 합니다.

인증 키 업데이트 기능에 대한 자세한 내용은 인증 키 업데이트 메커니즘 구성(configuring authentication key update mechanism) BGP(Border Gateway Protocol) 및 LDP 라우팅 프로토콜 을 참조하십시오.

LDP 세션 보호 구성

LDP 세션은 일반적으로 하나 이상의 링크에 의해 연결되는 라우터 쌍 간에 생성됩니다. 라우터는 이들을 연결하고 모든 인접을 해당 LDP 세션과 연결하는 모든 링크에 대해 하나의 hello adjacency를 구성합니다. LDP 세션에 대한 마지막 Hello 인접이 모두 중단되면 LDP 세션이 종료됩니다. 이 동작을 수정하여 LDP 세션이 불필요하게 종료되고 재구성되는 것을 방지할 수 있습니다.

명령문을 Junos OS 두 라우터를 연결하는 링크에 hello 인접하지 않은 경우에도 LDP 세션을 두 라우터 간에 남겨 두도록 구성할 수 session-protection 있습니다. 옵션을 사용하여 몇 초 만에 시간을 지정할 수 timeout 있습니다. 라우터가 IP 네트워크 연결을 유지하는 한 세션은 지정된 기간 동안 유지됩니다.

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

LDP용 SNMP 트랩 수리

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

LDP SNMP 트랩 및 독점 LDP 관리 정보 베이스(MIB) 정보는 SNMP 관리 정보 베이스(MIB) Explorer를 참조하십시오.

LDP에 대한 SNMP 트랩을 비활성화하면 명령문에 trap disable 대한 옵션을 log-updown 지정합니다.

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

LDP 링크에서 LDP IGP 구성

LDP는 트래픽이 아닌 애플리케이션에서 레이블을 배포하기 위한 프로토콜입니다. 레이블은 각 라벨이 지정한 최상의 경로를 따라 IGP. LDP와 IGP 동기화가 유지되지 않는 경우 LSP가 다운됩니다. LDP가 해당 링크에서 완전히 작동되지 않는 경우(세션이 설정되어 레이블이 교환되지 IGP 최대 비용 메트릭이 있는 링크를 광고합니다. 링크는 선호되지 않지만 네트워크 토폴로지에서 그대로 남아 있습니다.

LDP 동기화는 네트워크 아래에서 점대점(point-to-point) 인터페이스로 구성된 활성 Point-to-Point 인터페이스와 LAN 인터페이스에서 IGP. LDP 동기화는 Graceful Restart 중에 지원되지 않습니다.

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

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

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

라우터에서 LDP IGP 구성

LDP가 대기하는 시간을 구성한 후 인터페이스에 대한 LDP neighbor IGP 세션이 작동하고 있는지 알릴 수 있습니다. 많은 FEC가 있는 대규모 네트워크의 경우 LDP 레이블 데이터베이스를 교환하는 데 충분한 시간을 할 수 있도록 더 많은 값을 구성해야 할 수 있습니다.

LDP가 LDP neighbor 및 세션이 작동 중이 IGP 알리기 전에 LDP가 대기하는 시간을 구성하기 위해 명령문을 포함하고 옵션을 위해 몇 초 만에 시간을 igp-synchronizationholddown-interval 지정합니다.

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

Label Withdrawal Timer 구성

Label Withdrawal timer는 FEC에 대한 레이블 인출 메시지를 이웃으로 전송하기를 지연합니다. 이웃 IGP 링크에 장애가 발생하면, 이웃이 FEC의 다음 홉인 경우 FEC와 연관된 레이블은 모든 업스트림 라우터에서 철회해야 합니다. 매니지드 IGP 새로운 넥스트 홉에서 레이블을 수신하면 모든 업스트림 라우터로 레이블이 다시 지정됩니다. 이것이 일반적인 네트워크 동작입니다. 레이블 인출을 소수의 시간(예: IGP 수렴할 때까지 라우터가 다운스트림 넥스트림 홉에서 FEC에 대한 새로운 Label을 수신할 때까지) Label Withdrawal을 지연하고 레이블 매핑을 전송하는 것을 곧 피할 수 있습니다. label-withdrawal-delay명령문을 통해 이 지연 시간을 구성할 수 있습니다. 기본적으로 지연은 60초입니다.

라우터가 타임러가 실행되기 전에 새 Label을 수신하면 Label Withdrawal Timer는 취소됩니다. 그러나, 타임러가 실행되는 경우 FEC에 대한 레이블은 모든 업스트림 라우터에서 철회됩니다.

기본적으로 LDP는 레이블을 인출하기 전에 60초를 기다려 LSP가 리컨버전스되는 동안 LSP를 여러 IGP 방지합니다. 몇 초 만에 Label Withdrawal Delay Time을 구성하기 위해 다음 진술을 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 트레이스라우트(traceroute)는 RFC 4379를 기반으로 다중 프로토콜 레이블 스위칭(MPLS) 데이터 플레인 장애 감지. 이 기능을 사용하면 FEC의 모든 경로를 주기적으로 추적할 수 있습니다. FEC 토폴로지 정보는 액세스 가능한 데이터베이스에 CLI.

토폴로지 변경이 LDP LSP 추적을 자동으로 트리거하지는 않습니다. 그러나 트레이스라우트(traceroute)를 수동으로 시작할 수 있습니다. 현재 데이터베이스에 있는 FEC에 대한 traceroute 요청인 경우, 데이터베이스 컨텐트는 그 결과로 업데이트됩니다.

주기적인 traceroute 기능은 계층 수준에서 구성된 명령문에 의해 지정된 모든 oam[edit protocols ldp] FEC에 적용됩니다. 주기적인 LDP LSP traceroute를 구성하기 위해 다음 periodic-traceroute 명령문을 포함합니다.

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

명령문 자체 또는 다음 옵션 중 원하는 것으로 periodic-traceroute 구성할 수 있습니다.

  • exp—프로브를 보낼 서비스 등급 사용할 옵션을 지정합니다.

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

  • frequency—추적(traceroute) 시도 사이의 간격을 지정합니다.

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

  • retries—이를 포기하기 전에 프로브를 특정 노드로 전송하려는 시도 횟수를 지정합니다.

  • source—프로브 전송 시 사용할 IPv4 소스 주소를 지정합니다.

  • ttl—최대 사용 시간(time-to-live)을 지정합니다. 이 값을 초과하는 노드는 추적되지 않습니다.

  • wait—프로브 패킷을 다시 전송하기 전에 대기 간격을 지정합니다.

LDP 통계 수집

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

계층 수준에서 명령문을 구성하면 LDP 트래픽 통계가 주기적으로 수집 및 파일에 traffic-statistics[edit protocols ldp] 기록됩니다. 이 옵션을 사용하여 수치가 수집되는 시간(초)을 구성할 수 interval 있습니다. 기본 수집 간격은 5분입니다. LDP 통계 파일을 구성해야 합니다. 그렇지 않으면 LDP 트래픽 통계가 수집되지 않습니다. LSP가 다운되면 LDP 통계가 리셋됩니다.

LDP 트래픽 통계를 수집하기 위해 다음 traffic-statistics 진술을 포함합니다.

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

이 섹션에는 다음 주제가 포함되어 있습니다.

LDP 통계 출력

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

LDP 통계 파일에는 다음과 같은 데이터 열이 포함되어 있습니다.

  • FEC—LDP 트래픽 통계가 수집되는 FEC

  • Type—라우터에서 시작되는 트래픽 유형(이 라우터에서 시작) 또는 (이 라우터를 IngressTransit 통해 전달)

  • Packets—LSP가 나왔기 때문에 FEC에 전달된 패킷 수입니다.

  • Bytes—LSP가 나타났기 때문에 FEC에서 통과하는 데이터의 수입니다.

  • Shared—값은 여러 Prefix가 동일한 레이블에 연계되어 있는 것을 Yes 나타냅니다(예: 여러 Prefix가 egress 정책으로 광고되는 경우). 이 케이스에 대한 LDP 트래픽 통계는 모든 Prefix에 적용될 수 있으며, 이와 같이 처리해야 합니다.

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

Penultimate-Hop 라우터에서 LDP 통계 비가시

Penultimate-hop 라우터에서 LDP 트래픽 통계를 수집하면 특히 넥스 홉 경로에서 과도한 시스템 리소스를 소비할 수 있습니다. 명령문과 함께 명령문을 구성한 경우 이 문제는 deaggregate 더 큰 문제가 traffic-statistics 됩니다. 다음 홉 경로 사용에 대한 제한에 도달하는 라우터의 경우 명령문에 대한 옵션을 no-penultimate-hop 구성하는 traffic-statistics 것이 좋습니다.

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

주:

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

구성에서 이 옵션을 포함하거나 제거할 때마다 LDP 세션이 제거된 다음 다시 시작합니다.

다음 샘플 출력은 옵션이 구성된 라우터를 보여주는 LDP 통계 no-penultimate-hop 파일에서 출력됩니다.

LDP 통계 제한

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

  • LDP 통계는 지워할 수 없습니다.

  • 지정된 간격을 단축하는 경우 새 LDP 통계 요청은 통계 타임러가 새 간격보다 짧아야만 발행됩니다.

  • 이전 LDP가 완료될 때까지 새로운 LDP 통계 수집 작업은 시작될 수 없습니다. 간격이 짧거나 LDP 통계 수가 큰 경우 두 통계 수집 간의 시간 간격이 간격보다 길어지기 합니다.

LSP가 다운되면 LDP 통계가 리셋됩니다.

LDP 프로토콜 트래픽 추적

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

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

LDP 프로토콜 트래픽을 추적하기 위해 계층 수준에서 Global statement에서 옵션을 지정할 수 있으며, 명령문을 포함해 traceoptions LDP별 옵션을 지정할 [edit routing-options]traceoptions 수 있습니다.

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

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

다음 trace 플래그는 다양한 LDP 메시지를 송수신하는 작업을 표시합니다. 각 수정자는 하나 이상의 다음 수정자를 전달할 수 있습니다.

  • address—주소 및 주소 인출 메시지의 작동을 추적합니다.

  • binding—레이블 바인딩 작업 추적.

  • error—오류 조건 추적.

  • event—프로토콜 이벤트를 추적합니다.

  • initialization—초기화 메시지의 작동을 추적합니다.

  • label—레이블 요청, 레이블 맵, Label Withdrawal 및 Label 릴리스 메시지의 작동을 추적합니다.

  • notification—알림 메시지의 작동을 추적합니다.

  • packets—주소, 주소 인출, 초기화, 레이블 요청, 레이블 맵, 레이블 철회, 레이블 릴리스, 통보 및 주기적인 메시지 추적 이 수정자는 , , 및 수정자를 addressinitializationlabelnotification 설정하는 periodic 데 동일합니다.

    플래그에 대한 하위 옵션과 함께 플래그 filtermatch-on address 수정자를 구성할 수도 packets 있습니다. 이를 통해 패킷의 소스 및 대상 주소를 기반으로 추적할 수 있습니다.

  • path—레이블 스위칭 경로 작업 추적

  • path—레이블 스위칭 경로 작업 추적

  • periodic—hello 및 keepalive 메시지의 작동을 추적합니다.

  • route—라우팅 메시지의 작동을 추적합니다.

  • state—프로토콜 상태 전환 추적.

FEC 내 LDP 프로토콜 트래픽 추적

LDP는 생성되는 각 LSP와 포링 동등 클래스(FEC)를 연결합니다. LSP와 연관된 FEC는 해당 LSP에 매핑되는 패킷을 지정합니다. 각 라우터가 FEC의 다음 홉에서 광고하는 라벨을 선택하고 다른 모든 라우터에 광고하는 레이블에 LSP를 추가하면 LSP가 네트워크를 통해 확장됩니다.

특정 FEC 내의 LDP 프로토콜 트래픽을 추적하고 FEC를 기반으로 LDP 추적 명령문을 필터링할 수 있습니다. 이는 FEC와 연관된 LDP 프로토콜 트래픽을 추적하거나 문제를 해결하려는 경우 유용합니다. 다음 trace 플래그는 이 목적으로 사용할 수 있습니다. routepath, 및 binding 를 통해

다음 예제에서는 FEC를 기반으로 LDP 추적 명령문을 필터링하기 위해 LDP 명령문을 구성하는 방법을 traceoptions 설명하고 있습니다.

이 기능에는 다음과 같은 제한이 있습니다.

  • 필터링 기능은 IPv4(IP version 4) prefix로 구성된 FEC에서만 사용할 수 있습니다.

  • Layer 2 회로 FEC는 필터링할 수 없습니다.

  • 경로 추적과 필터링을 모두 구성하면 MPLS 경로가 표시되지 않습니다(필터에 의해 차단).

  • 필터링은 정책과 옵션에 대한 구성된 값에 따라 match-on 결정됩니다. 정책을 구성할 때 기본 동작이 항상 에지와 같은지 확인해야 reject 합니다.

  • 유일한 match-on 옵션은 fec 입니다. 따라서 포함해야 하는 정책의 유형은 경로 필터 정책뿐입니다.

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

LDP 경로 메시지를 자세히 추적:

모든 LDP 발신 메시지 추적:

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

모든 LDP 수신 메시지와 모든 레이블 바인딩 연산 추적:

LSP와 연관된 FEC에 대한 추적 LDP 프로토콜 트래픽:

출시 내역 표
릴리스
설명
19.1
Release Junos OS 릴리스부터 19.1R1 세그먼트 라우팅-LDP 경계 라우터는 세그먼트 라우팅 트래픽을 LDP 넥스홉으로 스티치하고 그 반대의 경우도 마찬가지입니다.
16.1R1
릴리스 Junos OS 16.1R1 LDP 세션에 대한 해시드 메시지 인증 코드(HMAC) 및 MD5 인증에 대한 지원은 세션당 구성에서 서브넷 일치(즉, 가장 긴 Prefix-match) 구성으로 확장됩니다.
16.1
Junos OS Release 16.1에서부터 M-LDP는 루트 주소가 BGP(Border Gateway Protocol) 경로인 경우 ASBR 또는 전송 또는 egress에서 point-to-multipoint LSP를 시그널링할 수 MPLS 있습니다.
14.1
기존 IPTV 서비스를 네이티브 IP 멀티캐스트에서 MPLS 릴리스 14.1에서부터 시작하여 중단을 최소화하면서 PIM에서 M-LDP Point-to-Multipoint LSP로 원활하게 전환해야 합니다. Junos OS