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에서 모든 관련 인터페이스를 활성화합니다. Directed LDP의 경우, family MPLS를 통해 루프백 인터페이스를 활성화해야 합니다.

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

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

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

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

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

LDP 활성화 및 비활성화

LDP는 라우팅 인스턴스 인식(routing-instance-aware)입니다. 특정 인터페이스에서 LDP를 활성화하려면 다음과 같은 명령문을 포함합니다.

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

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

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

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

Hello 메시지를 위한 LDP 타이머 구성

LDP hello 메시지는 LDP 노드가 서로를 발견하고 이웃 또는 이웃에 대한 링크의 장애를 감지할 수 있도록 지원합니다. Hello 메시지는 LDP가 활성화된 모든 인터페이스에서 주기적으로 전송됩니다.

LDP Hello 메시지의 유형은 다음과 같습니다.

  • Hello 메시지 링크—LDP 검색 포트로 주소가 지정된 UDP 패킷으로 LDP 인터페이스를 통해 전송됩니다. 인터페이스에서 LDP 링크 hello 메시지를 수신하여 LDP 피어 라우터와의 인접성을 식별합니다.

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

기본적으로 LDP는 링크 안녕하세요 메시지를 위해 5초마다, 대상별 Hello 메시지에는 15초마다 안녕하세요 메시지를 보냅니다. LDP 타이머를 구성하여 두 유형의 Hello 메시지가 전송되는 빈도를 변경할 수 있습니다. 그러나 LDP 대기 시간보다 더 큰 LDP 타이머에 대한 시간을 구성할 수는 없습니다. 자세한 내용은 LDP Neighbor가 다운되기 전에 지연 구성을 참조하십시오.

링크 Hello 메시지를 위한 LDP 타이머 구성

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

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

대상화된 Hello 메시지를 위한 LDP 타이머 구성

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

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

LDP 이웃을 하향 고려하기 전에 지연 구성

보류 시간은 LDP 노드가 이웃 노드의 다운을 선언하기 전에 인사이더 메시지를 기다려야 하는 기간을 결정합니다. 이 값은 hello 메시지의 일부로 전송되므로 각 LDP 노드가 이웃에게 기다릴 시간을 알려줍니다. 각 이웃이 전송하는 값이 일치할 필요가 없습니다.

보류 시간은 일반적으로 적어도 세 번 안녕하세요 간격이어야한다. 기본값은 링크 Hello 메시지의 경우 15초, 대상은 Hello 메시지에 45초입니다. 그러나 Hello 간격에 대한 값에 가까운 LDP 보류 시간을 구성할 수 있습니다.

주:

LDP 대기 시간을 Hello 간격(hello 간격의 3배 미만)에 가깝게 구성함으로써 LDP 인접 장애를 보다 빠르게 감지할 수 있습니다. 그러나 이는 라우터가 여전히 정상적으로 작동하고 있는 LDP neighbor를 다운 선언할 가능성도 높아질 수 있습니다. 자세한 내용은 Hello 메시지를 위한 LDP 타이머 구성을 참조하십시오.

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

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

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

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

LDP 링크 Hello 메시지 대기 시간 구성

LDP 노드가 이웃을 아래로 선언하기 전에 링크 hello 메시지를 기다려야 하는 기간을 수정하려면 다음과 같은 명령문을 사용하여 hold-time 몇 초 만에 새로운 시간을 지정하십시오.

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

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

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

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

LDP를 위한 엄격한 타겟 헬로 메시지 활성화

엄격한 타겟 헬로 메시지를 사용하여 특별히 구성되지 않은 원격 이웃과 LDP 세션이 설정되지 않도록 합니다. 명령문을 strict-targeted-hellos 구성하면 LDP 피어는 구성된 원격 이웃 중 하나가 아닌 소스에서 수신되는 대상 Hello 메시지에 응답하지 않습니다. 구성된 원격 이웃에는 다음이 포함될 수 있습니다.

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

  • Layer 2 회선 이웃

구성된 이웃이 hello 메시지를 보내는 경우, LDP 피어는 메시지를 무시하고 소스를 나타내는 오류( error trace flag 포함)를 기록합니다. 예를 들어, LDP 피어가 인터넷 주소 10.0.0.1로부터 targeted hello를 수신했으며 이 주소가 있는 neighbor가 특별히 구성되지 않은 경우, 다음 메시지가 LDP 로그 파일로 인쇄됩니다.

엄격한 대상을 지정한 Hello 메시지를 활성화하려면 다음과 같은 명령문을 strict-targeted-hellos 포함합니다.

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

LDP Keepalive Messages의 간격 구성

keepalive 간격은 세션 동안 메시지가 전송되는 빈도를 결정하여 유지 타임아웃이 초과되지 않도록 보장합니다. 이렇게 많은 시간 동안 세션을 통해 다른 LDP 트래픽이 전송되지 않으면 keepalive 메시지가 전송됩니다. 기본값은 10초입니다. 최소 값은 1초입니다.

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

유지 간격을 수정하려면 다음과 같은 명령문을 keepalive-interval 포함합니다.

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

LDP Keepalive Timeout 구성

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

유지 간격을 수정하려면 다음과 같은 명령문을 keepalive-timeout 포함합니다.

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

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

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 수준에서 집계되거나 요약된 경로를 학습할 수 있습니다. 가장 긴 일치 정책은 Prefix 세분화당 제공합니다.

요구 사항

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

  • 연결된 인터페이스에서 OSPF 프로토콜과 LDP를 지원하는 6개의 MX 시리즈 라우터.

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

시작하기 전:

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

  • OSPF를 구성합니다.

개요

LDP는 종종 OSPF 또는 IS-IS와 같은 IGP를 사용하여 전체 네트워크 도메인 전반에 걸쳐 MPLS LSP(Label-Switched Path)를 설정하는 데 사용됩니다. 이러한 네트워크에서 도메인의 모든 링크에는 IGP 인접과 LDP 인접성이 있습니다. LDP는 IP 포워딩에 따라 목적지로 향하는 최단 경로에 LSP를 설정합니다. Junos OS에서 LDP 구현은 레이블 매핑을 위해 RIB 또는 IGP 경로에서 FEC의 IP 주소에 대한 정확한 일치 룩업을 수행합니다. 이와 같은 정확한 매핑을 위해서는 모든 LE에서 MPLS 엔드투엔드 LDP IP 주소를 구성해야 합니다. 액세스 장치의 IP 계층적 설계 또는 기본 라우팅의 목적과는 상반됩니다. Configuring longest-match 은 정확한 일치 동작을 억제하고 접두사별로 가장 긴 매칭 경로를 기반으로 LSP를 설정하여 이러한 문제를 극복하는 데 도움이 됩니다.

토폴로지

토폴로지 그림 1에서 LDP에 대한 가장 긴 일치가 Device R0에 구성됨을 보여줍니다.

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

구성

CLI 빠른 구성

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

R0

R1

R2

R3

R4

R5

장비 R0 구성

단계별 절차

다음 예제에서는 구성 계층에서 다양한 레벨을 탐색해야 합니다. CLI 탐색에 대한 자세한 내용은 CLI 사용자 가이드의 Configuration Mode에서 CLI Editor를 사용하는 것을 참조하십시오.

디바이스 R0을 구성하려면:

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

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

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

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

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

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

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

결과

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

디바이스 구성을 완료한 경우 구성 모드에서 입력 commit 합니다.

확인

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

경로 검증

목적

예상 경로 학습 여부를 확인합니다.

실행

Device R0에서 운영 모드에서 명령을 실행 show route 하여 라우팅 테이블에 경로를 표시합니다.

의미

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

LDP 개요 정보 검증

목적

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

실행

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

의미

출력은 장비 R0의 LDP 개요 정보를 표시합니다.

내부 토폴로지 테이블에서 LDP 엔트리 검증

목적

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

실행

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

의미

출력은 Device R0의 LDP 내부 토폴로지 테이블에 루트 엔트리를 표시합니다.

LDP 경로의 FEC 정보만 확인

목적

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

실행

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

의미

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

LDP의 FEC 및 쉐도우 경로 검증

목적

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

실행

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

의미

이 출력은 Device R0의 FEC 및 쉐도우 경로를 표시합니다.

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가 정상적으로 재시작되기를 기다리는 시간입니다. 복구 기간은 초기화 메시지가 전송되거나 수신되는 시점부터 시작됩니다. 또한 이 기간은 일반적으로 이웃 라우터가 재시작 라우터에 대한 정보를 유지하여 트래픽을 계속 포워딩할 수 있도록 하는 시간입니다.

LDP 프로토콜의 마스터 인스턴스와 특정 라우팅 인스턴스 모두에서 LDP graceful restart를 구성할 수 있습니다. 모든 프로토콜에 대해 전역 수준에서, LDP의 프로토콜 수준에서만, 특정 라우팅 인스턴스에서 graceful restart를 비활성화할 수 있습니다. LDP graceful restart는 기본적으로 비활성화됩니다. 글로벌 수준에서는 기본적으로 Graceful Restart가 비활성화되어 있기 때문입니다. 그러나 헬퍼 모드(graceful restart를 시도하는 이웃 라우터를 지원하는 기능)는 기본적으로 활성화됩니다.

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

  • 재시작 환경에서는 발신 레이블이 유지되지 않습니다. 새로운 발신 레이블이 할당됩니다.

  • 라우터가 재시작되면 재시작 라우터가 안정화될 때까지 graceful restart를 지원하는 이웃에게 레이블 맵 메시지가 전송되지 않습니다(label-map 메시지는 graceful restart를 지원하지 않는 이웃에게 즉시 전송됨). 그러나 다른 모든 메시지(keepalive, address-message, 알림 및 릴리스)는 평소와 같이 전송됩니다. 이러한 다른 메시지를 배포하면 라우터가 불완전한 정보를 배포하지 못하게 됩니다.

  • 헬퍼 모드와 Graceful Restart는 독립적입니다. 구성에서 graceful restart를 비활성화할 수 있지만, 라우터가 정상적으로 재시작하려고 시도하는 이웃과 협력할 수 있습니다.

LDP Graceful Restart 구성

또는 [edit protocols ldp graceful-restart] 계층 수준에서 graceful restart 구성을 [edit routing-options graceful-restart] 변경하면 실행 중인 LDP 세션이 자동으로 재시작되어 graceful restart 구성을 적용합니다. 이 동작은 BGP의 graceful Restart 구성을 변경할 때의 동작을 반영합니다.

기본적으로 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 프로토콜 수준에서만 헬퍼 모드를 비활성화할 수 있습니다. 특정 라우팅 인스턴스에 대해 헬퍼 모드를 비활성화할 수 없습니다. LDP 헬퍼 모드를 비활성화하려면 다음과 같은 명령문을 helper-disable 포함합니다.

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

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

  • LDP Graceful Restart와 Helper 모드 모두 활성화됩니다.

  • LDP graceful restart는 비활성화되어 있지만 Helper 모드는 활성화됩니다. 이 방법으로 구성된 라우터는 정상적으로 재시작할 수는 없지만 이웃을 다시 시작하는 데 도움이 될 수 있습니다.

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

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

재컨넥트 시간 구성

이웃 간의 LDP 연결에 장애가 발생하면 이웃들은 정상적으로 다시 시작하는 라우터가 LDP 메시지 전송을 재개할 때까지 일정 시간 동안 기다려야 합니다. 대기 기간 이후에 LDP 세션을 재구축할 수 있습니다. 몇 초만에 대기 기간을 구성할 수 있습니다. 이 값은 LDP graceful restart가 활성화될 때 LDP 초기화 메시지에서 전송되는 장애 허용 세션 TLV에 포함됩니다.

라우터 A와 라우터 B가 LDP neighbor라고 가정해 보십시오. 라우터 A는 재시작 라우터입니다. 재연결 시간은 라우터 A가 라우터 B에게 라우터 B가 라우터 A가 재시작되는 것을 탐지한 후에 기다려야 합니다.

재연결 시간을 구성하려면 다음과 같은 명령문을 reconnect-time 포함합니다.

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

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

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

복구 시간은 라우터가 LDP가 정상적으로 재시작되기를 기다리는 시간입니다. 복구 기간은 초기화 메시지가 전송되거나 수신되는 시점부터 시작됩니다. 이 기간은 일반적으로 이웃 라우터가 재시작 라우터에 대한 정보를 유지하여 트래픽을 계속 포워딩하는 시간입니다.

재시작 라우터로부터 복구 시간에 대한 잘못된 값을 수신하는 경우 이웃 라우터가 악영향을 받지 않도록 하기 위해 이웃 라우터에서 최대 복구 시간을 구성할 수 있습니다. 인접 라우터는 2배 더 짧게 상태를 유지합니다. 예를 들어 라우터 A는 LDP Graceful Restart를 수행합니다. 인접한 라우터 B에 900초의 복구 시간을 보냈습니다. 그러나 라우터 B는 400초에 구성된 최대 복구 시간을 가지고 있습니다. 라우터 B는 라우터 A에서 LDP 정보를 삭제하기 전까지 400초 동안만 기다려야 합니다.

복구 시간을 구성하려면 다음과 같은 recovery-time 명령문과 명령문을 maximum-neighbor-recovery-time 포함하십시오.

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

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

수신된 LDP 레이블 바인딩을 필터링하여 이웃 라우터가 광고하는 바인딩을 수락하거나 거부하는 정책을 적용할 수 있습니다. 수신 레이블 필터링을 구성하려면 다음과 같은 명령문을 import 포함합니다.

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

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

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

from 연산자

설명

interface

지정된 인터페이스를 통해 인접한 이웃으로부터 수신된 바인딩에 대한 일치

neighbor

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

next-hop

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

route-filter

지정된 접두사에서 바인딩에 대한 일치

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

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

LDP 세션은 인터페이스 또는 인터페이스 주소에 얽매이지 않습니다. LDP는 라우터당(인터페이스가 아님) 레이블만 광고하고, 따라서 두 라우터 사이에 여러 병렬 링크가 존재하면 하나의 LDP 세션만 설정되며 단일 인터페이스에 얽매이지 않습니다. 라우터가 동일한 이웃에 여러 인접한 경우 필터가 예상되는 작업을 수행하도록 주의해야 합니다. (일반적으로 이 경우 사용 next-hop 중이며 interface 적합하지 않습니다.)

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

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

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

모든 neighbor의 접두사/32개만 허용:

라우터 ID 10.10.255.2 를 허용 131.108/16 하거나 더 오래 허용하며 다른 모든 이웃의 모든 접두사 허용:

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

LDP 아웃바운드 레이블을 필터링하기 위해 내보내기 정책을 구성할 수 있습니다. 라우팅 정책을 적용하여 아웃바운드 레이블 바인딩을 필터링하여 바인딩이 인접 라우터에 광고되는 것을 차단할 수 있습니다. 아웃바운드 레이블 필터링을 구성하려면 다음과 같은 명령문을 export 포함합니다.

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

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

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

운영자에게

설명

interface

지정된 인터페이스를 통해 인접한 이웃에게 전송되는 바인딩에 대한 일치

neighbor

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

next-hop

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

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

LDP 세션은 인터페이스 또는 인터페이스 주소에 얽매이지 않습니다. LDP는 라우터당(인터페이스가 아님) 레이블만 광고합니다. 2개의 라우터 사이에 다중 병렬 링크가 존재하면 하나의 LDP 세션만 설정되며 단일 인터페이스에 얽매이지 않습니다.

라우터에 동일한 이웃에 next-hop 여러 인접한 경우 해당 라우터와 interface 운영자를 사용하지 마십시오.

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

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

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

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

라우터 ID10.10.255.2로만 131.108/16 또는 더 오래 보내고 모든 접두사들을 다른 모든 라우터로 보냅니다.

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

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

LDP 전송 주소를 구성하려면 전송 주소 명세서를 포함합니다.

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

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

주:

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

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

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

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

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

대상 LDP 세션 설정에 대한 전송 주소 구성은 다음과 같은 이점을 제공합니다.

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

  • Ease of operation—인터페이스 수준에서 구성된 전송 주소를 사용하면 LDP용 IGP 백본에서 두 개 이상의 프로토콜을 사용할 수 있습니다. 이를 통해 원활하고 손쉬운 운영을 수행할 수 있습니다.

대상 LDP 전송 주소 개요

Junos OS Release 19.1R1에 앞서 LDP는 모든 LDP 인터페이스에서 전송 주소로 라우터 ID 또는 인터페이스 주소에 대해서만 지원을 제공했습니다. 인터페이스상에서 형성된 인접은 인터페이스 또는 라우터 ID에 할당된 IP 주소 중 하나를 사용했습니다. 대상에 인접한 경우 인터페이스는 루프백 인터페이스입니다. 장비에서 다중 루프백 주소를 구성한 경우, 인터페이스에 대해 전송 주소를 도출할 수 없으며, 그 결과 LDP 세션을 설정할 수 없습니다.

Junos OS Release 19.1R1에서 시작하여 대상 LDP 세션의 전송 주소에 사용되는 기본 IP 주소와 더불어, 다른 IP 주소를 , 및 interface 구성 명령문의 sessionsession-group전송 주소로 구성할 수 있습니다. 전송 주소 구성은 Layer 2 회로, MPLS 및 VPLS 인접을 포함하여 구성된 이웃에만 적용됩니다. 이 구성은 검색된 인접(대상 또는 아님)에는 적용되지 않습니다.

전송 주소 기본 설정

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

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

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

전송 주소 구성 문제 해결

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

  • show ldp session

  • show ldp neighbor

    detail 명령의 show ldp neighbor 출력 수준은 대상 이웃에 대한 hello 메시지에서 전송되는 전송 주소를 표시합니다. 이 주소를 이웃에서 연결할 수 없는 경우 LDP 세션이 나오지 않습니다.

  • show configuration protocols ldp

추가적인 문제 해결을 위해 LDP 추적(traceoption)을 사용할 수도 있습니다.

  • 구성이 잘못된 전송 주소(도달 불가능)를 사용하는 것에서 유효한 전송 주소로 변경된 경우, 다음 추적을 관찰할 수 있습니다.

  • 올바르지 않은(도달 불가능한) 전송 주소에 유효한 전송 주소를 사용하여 구성을 변경한 경우 다음 추적을 관찰할 수 있습니다.

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

  • address family참조하십시오. 명령문에 session 구성된 전송 주소는 neighbor 또는 세션과 동일한 주소 제품군에 속해야 합니다.

  • 아래의 전송 주소 neighbor 또는 session 명령문으로 구성된 주소는 대상에 지정된 hello 메시지가 시작되도록 라우터에 로컬이어야 합니다. 주소가 구성되었는지 확인할 수 있습니다. 어떤 인터페이스 하에서 주소가 구성되지 않으면 구성이 거부됩니다.

라우팅 테이블로부터 LDP로 공지된 접두사 구성

LDP에 보급된 접두사 집합을 제어하고 라우터를 해당 접두사에 대한 송신 라우터로 만들 수 있습니다. 기본적으로 루프백 주소만 LDP에 표시됩니다. LDP에 광고할 라우팅 테이블의 접두사 집합을 구성하려면 다음과 같은 egress-policy 명령문을 포함합니다.

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

주:

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

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

주:

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

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

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

FEC 세분화 구성

LDP 송신 라우터가 여러 Prefix를 알리는 경우, 접두사들은 단일 Label에 연결되고 단일 FEC(Forwarding Equivalence Class)로 집계됩니다. 기본적으로 LDP는 광고가 네트워크를 통과할 때 이 어그리게이션을 유지합니다.

일반적으로 LSP는 여러 다음 홉으로 분할되지 않고 접두사들이 단일 LSP로 연결되기 때문에 동일한 비용의 경로에서 로드 밸런싱이 수행되지 않습니다. 그러나 로드 밸런싱 정책을 구성하고 FEC를 세분화하면 동일한 비용의 경로에서 로드 밸런싱을 수행할 수 있습니다.

FEC의 세분화로 인해 각 접두사가 별도의 레이블에 바인딩되고 별도의 LSP가 됩니다.

세분화된 FEC를 구성하려면 다음과 같은 명령문을 deaggregate 포함합니다.

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

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

FEC를 세분화하면 생성된 여러 LSP를 동일한 비용의 여러 경로에 분산시키고 송신 세그먼트의 여러 다음 홉에 LSP를 분산하지만 LSP당 하나의 다음 홉만 설치할 수 있습니다.

FEC를 집계하려면 다음과 같은 명령문을 포함하십시오 no-deaggregate .

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

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

LDP FEC에 대한 폴리서 구성

Junos OS를 구성하여 LDP FEC의 트래픽을 추적하고 정책 처리할 수 있습니다. LDP FEC 폴리서는 다음 중 어느 것을 수행하는 데 사용할 수 있습니다.

  • LDP FEC의 수신 트래픽을 추적하거나 정책 적용합니다.

  • LDP FEC의 전송 트래픽을 추적하거나 정책 적용합니다.

  • 특정 포워딩 클래스에서 발생한 LDP FEC 트래픽을 추적하거나 폴리싱합니다.

  • 특정 가상 라우팅 및 포워딩(VRF) 사이트에서 발생한 LDP FEC 트래픽을 추적하거나 폴리싱합니다.

  • 특정 LDP FEC에 바인딩된 잘못된 트래픽을 폐기합니다.

LDP FEC의 트래픽을 폴리에 적용하려면 먼저 필터를 구성해야 합니다. 특히 계층 수준에서 명령문 또는 interface-set 명령문을 [edit firewall family protocol-family filter filter-name term term-name from] 구성 interface 해야 합니다. 이 interface 명령문을 사용하면 필터를 단일 인터페이스에 맞출 수 있습니다. 이 interface-set 명령문을 사용하면 필터를 여러 인터페이스에 맞출 수 있습니다.

LDP FEC에 대한 명령문, 명령문 및 폴리서를 구성하는 interface 방법에 대한 자세한 내용은 라우팅 정책, 방화벽 필터 및 Traffic Policers 사용자 가이드를 참조하십시오.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)와 Layer 2 회선 FEC를 교환합니다. LDP 세션을 간접적으로 연결된 이웃에게 하려면 세션이 Layer 2 회로 또는 VPLS를 지원하도록 특별히 구성된 경우에만 Layer 2 서킷 FEC를 이웃으로 내보낼 수 있습니다.

BGP가 아닌 모든 접두사가 LDP에 광고되는 혼합 벤더 네트워크에서는 LDP 데이터베이스가 커질 수 있습니다. 이러한 유형의 환경에서는 Layer 2 회로 또는 LDP VPLS 구성으로 인해 형성된 LDP 세션에서 IPv4 FEC의 광고를 방지하는 데 유용할 수 있습니다. 마찬가지로 이러한 환경에서 수신되는 모든 IPv4 FEC를 필터링하는 데 유용할 수 있습니다.

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

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

LDP가 Layer 2 neighbor를 통해서만 LDP 세션을 통해 IPv4 FEC를 내보낼 수 없도록 하고 이러한 세션을 통해 수신된 IPv4 FEC를 필터링하려면 다음과 같은 명령문을 l2-smart-policy 포함합니다.

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

LDP LSP를 위한 BFD 구성

LDP LSP에 대해 BFD(Bidirectional Forwarding Detection)를 구성할 수 있습니다. 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를 사용하려면 다음과 bfd-liveness-detection 같은 내용이 oam 포함되어 있습니다.

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

동등한 FEC 주소가 명시적으로 구성되거나 OAM 수신 정책을 사용하여 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 Explorer를 참조하십시오.

성명서에는 bfd-liveness-detection 다음과 같은 옵션이 포함되어 있습니다.

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

  • 홀드다운 간격—경로 또는 다음 홉을 추가하기 전에 BFD 세션이 유지해야 하는 지속 기간을 지정합니다. 0초의 시간을 지정하면 BFD 세션이 돌아오자마자 경로 또는 다음 홉이 추가됩니다.

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

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

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

  • multiplier—탐지 시간 곱을 지정합니다. 범위는 1에서 255까지입니다.

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

LDP LSP를 위한 ECMP-Aware BFD 구성

FEC에 BFD를 구성하면 라우터에 대해 하나의 활성 로컬 넥트 홉에 대해서만 BFD 세션이 설정됩니다. 그러나 특정 ECMP(Equal-Cost Multipath) 경로와 연관된 각 FEC에 대해 여러 BFD 세션을 구성할 수 있습니다. 제대로 작동하려면 LDP LSP 주기적 경로 추적(traceroute)을 구성해야 합니다. ( LDP LSP 추적 경로 구성을 참조하십시오.) LDP LSP traceroute는 ECMP 경로를 검색하는 데 사용됩니다. 발견된 각 ECMP 경로에 대해 BFD 세션이 시작됩니다. ECMP 경로 중 하나에 대한 BFD 세션이 실패할 때마다 오류가 기록됩니다.

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

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

  • LDP LSP traceroute가 오류(예: 타임아웃)를 반환하면 해당 FEC와 관련된 모든 BFD 세션이 철거됩니다.

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

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

성명서와 함께 ecmp 글로벌 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]([edit protocols ldp oam]계층 수준)에 대한 구성에 명령문을 포함 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 세션 장애가 발생할 경우 장애 조치를 구성하려면 다음과 같은 옵션 또는 remove-route 옵션을 failure-action 포함합니다remove-nexthop.

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

BFD 세션에 대한 홀드다운 간격 구성

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

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

멀티캐스트 전용 Fast Reroute의 이해

MoFRR(Multicast-only 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 개요

유니캐스트 스트림에서의 FrR(Fast Reroute)을 통해 업스트림 라우팅 장비는 MPLS LSP(Label-Switched Paths)를 프리스테이블(preestablishes)하거나 다운스트림 경로에서 세그먼트의 장애를 처리하기 위해 IP 루프 없는 대체(LFA) 고속 재라우팅 백업 경로를 미리 구성합니다.

멀티캐스트 라우팅에서 수신 측은 일반적으로 트래픽 배포 그래프를 시작합니다. 이는 일반적으로 소스에서 수신기로 경로를 설정하는 유니캐스트 라우팅과는 다릅니다. PIM(IP용), 멀티포인트 LDP(MPLS용) 및 RSVP-TE(MPLS)는 멀티캐스트 분산 그래프를 설정할 수 있는 프로토콜입니다. 이 중 PIM 및 멀티포인트 LDP 수신기는 분산 그래프 설정을 시작하므로 MoFRR은 지원되는 이 두 멀티캐스트 프로토콜과 함께 작동할 수 있습니다.

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

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

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

그림 12 멀티캐스트 수신기 라우팅 디바이스(PE(egress Provider Edge) 디바이스에서 멀티캐스트 소스 라우팅 디바이스(수신 PE 장비라고도 함)에 이르는 두 가지 경로를 보여줍니다.

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

MoFRR을 사용하면 송신(수신기 측) 라우팅 디바이스가 각각(S,G)에 대한 멀티캐스트 소스로 2개의 멀티캐스트 트리, 기본 경로 및 백업 경로를 설정합니다. 즉, 송신 라우팅 장비는 동일한(S,G) 조인 메시지를 두 개의 업스트림 이웃에 전파하여 두 개의 멀티캐스트 트리를 만듭니다.

멀티캐스트 트리 중 하나는 평면 1을 통과하고 다른 하나는 평면 2 그림 12를 통과합니다. 각 (S,G)에 대해 송신 라우팅 장비는 기본 경로에서 수신된 트래픽을 포워딩하고 백업 경로에서 수신된 트래픽을 드롭합니다.

MOFRR은 ECMP(Equal-Cost Multipath) 경로와 비 ECMP 경로 모두에서 지원됩니다. 이 장치는 비 ECMP 경로에서 MoFRR을 지원하기 위해 유니캐스트 루프 없는 대체(LFA) 경로를 활성화해야 합니다. IGP(Interior Gateway Protocol) 구성의 명령문을 사용하여 link-protection LFA 경로를 활성화합니다. OSPF 또는 IS-IS 인터페이스에서 링크 보호를 사용하면 보호된 인터페이스를 통과하는 모든 대상 경로에 대해 기본 다음 홉으로 백업 LFA 경로를 생성합니다.

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

멀티포인트 LDP MoFRR은 패킷이 IP 네트워크로 전달되는 MPLS 네트워크의 송신 디바이스에서 사용됩니다. 이 장치는 멀티포인트 LDP MoFRR을 통해 LER에서 2개의 MPLS 패킷 스트림을 수신할 수 있도록 업스트림 PE 라우팅 장비로 향하는 두 가지 경로를 설정합니다. 디바이스는 스트림 중 하나(기본)를 허용하고 다른 스트림(백업)은 LER에서 삭제됩니다. 기본 경로에 장애가 발생하면 디바이스가 백업 스트림을 대신 수락합니다. Inband 시그널링 지원은 멀티포인트 LDP를 갖춘 MoFRR의 사전 필수 조건입니다(점 대다점 LSP의 경우 멀티포인트 LDP 인밴드 시그널링 이해 참조).

PIM 기능

Junos OS는 PIM SSM(Source-Specific Multicast) 및 ASM(Any-Source Multicast)에서 최단 경로 트리(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(reverse-path forwarding) 인터페이스에서 조인 메시지를 전파하여 동일한 조인 요청에 대해 두 링크에서 멀티캐스트 트래픽을 수신합니다. MoFRR은 동일한 업스트림 라우팅 장비로 통합되지 않는 두 가지 경로를 기본 설정합니다. PIM은 2개의 인터페이스(기본 및 백업 경로용)로 업스트림 RPF 다음 홉과 함께 적절한 멀티캐스트 경로를 설치합니다.

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

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

계층에서 구성 명령문을 사용하여 stream-protection MoFRR을 [edit routing-options multicast] 활성화합니다. MoFRR은 일련의 필터 정책으로 관리됩니다.

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

  • MoFRR 구성이 없는 경우 PIM은 하나의 업스트림 이웃(예: 평면 2 in 그림 12)으로 조인 메시지 업스트림을 보냅니다.

  • MoFRR 구성이 있는 경우 장치는 정책 구성을 검사합니다.

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

    • 기본 및 백업 경로를 사용할 수 없는 경우 PIM은 하나의 업스트림 이웃(예: 평면 2 in 그림 12)으로 조인 메시지 업스트림을 보냅니다.

    • 기본 및 백업 경로를 사용할 수 있는 경우 PIM은 사용 가능한 업스트림 이웃 두 쪽으로 조인 메시지 업스트림을 보냅니다. Junos OS는 멀티캐스트 트래픽을 수신하기 위해 기본 및 보조 멀티캐스트 경로를 설정합니다(예: 평면 1 in 그림 12).

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

    • 이 정책 검사에 실패하면 PIM은 한 업스트림 이웃(예: 평면 2 in 그림 12)으로 조인 메시지 업스트림을 보냅니다.

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

      • 기본 및 백업 경로를 사용할 수 없는 경우 PIM은 하나의 업스트림 이웃(예: 플레인 2 in 그림 12)으로 조인 메시지 업스트림을 보냅니다.

      • 기본 및 백업 경로를 사용할 수 있는 경우 PIM은 사용 가능한 업스트림 이웃 두 쪽으로 조인 메시지 업스트림을 보냅니다. 디바이스는 기본 및 보조 멀티캐스트 경로를 설정하여 멀티캐스트 트래픽(예: 평면 1 in 그림 12)을 수신합니다.

멀티포인트 LDP 기능

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

MoFRR을 이용한 멀티포인트 LDP의 경우, 멀티포인트 LDP 장치는 2개의 개별 업스트림 피어를 선택하고 2개의 별도 레이블(각각에 하나씩)을 보냅니다. 이 장치는 RFC 6388에서 설명한 것과 동일한 알고리즘을 사용하여 기본 업스트림 경로를 선택합니다. 이 장치는 동일한 알고리즘을 사용하여 백업 업스트림 경로를 선택하지만 예비 후보로 기본 업스트림 LSR은 제외합니다. 2개의 다른 업스트림 피어가 2개의 MPLS 트래픽 스트림을 송신 라우팅 장비로 보냅니다. 이 장치는 MPLS 트래픽을 수용할 기본 경로로 업스트림 이웃 경로 중 하나만 선택합니다. 다른 경로는 백업 경로가 되고 디바이스는 해당 트래픽을 드롭합니다. 기본 업스트림 경로에 장애가 발생하면 장비가 백업 경로에서 트래픽을 수락하기 시작합니다. 멀티포인트 LDP 장치는 다음 홉에서 IGP(Interior Gateway Protocol) 루트 디바이스를 기반으로 2개의 업스트림 경로를 선택합니다.

포워딩 FEC(Equivalency Class)는 동일한 방식으로 동일한 경로상에서 동일한 포워딩 처리를 하는 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 P2000 FEC를 활성화한 경우 장치는 업스트림 경로를 선택할 때 다음과 같은 고려 사항을 고려합니다.

  • LDP 세션이 타겟팅되지 않은 경우 대상 LDP 세션을 건너뛰습니다. 단일 대상 LDP 세션이 있는 경우, 대상 LDP 세션이 선택되지만, 대상 LDP 세션과 연관된 인터페이스가 없기 때문에 해당 P2S(Point-to-Multipoint) FEC는 MoFRR 기능을 잃게 됩니다.

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

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

패킷 포워딩

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

  • 패브릭 전체에 중복 스트림을 전송하지 않도록 방지

  • 여러 루트 조회(패킷 드롭)를 방지합니다.

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

그림 13 PIM을 사용한 라우터를 위한 샘플 기본 및 백업 인터페이스를 통해 이 프로세스를 보여줍니다. 그림 14 PIM을 갖춘 스위치의 경우 이와 유사하게 표시됩니다.

그림 13: 라우터의 패킷 포워딩 엔진에서 MoFRR IP Route 룩업라우터의 패킷 포워딩 엔진에서 MoFRR IP Route 룩업
그림 14: 스위치상의 패킷 포워딩 엔진에서 MoFRR IP Route Handling스위치상의 패킷 포워딩 엔진에서 MoFRR IP Route Handling

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

그림 15 멀티포인트 LDP를 갖춘 라우터에 대해 이 프로세스를 보여줍니다.

그림 15: 패킷 포워딩 엔진의 MoFRR MPLS 루트 룩업패킷 포워딩 엔진의 MoFRR MPLS 루트 룩업

제한 사항 및 경고

스위칭 및 라우팅 디바이스에 대한 MoFRR 제한 사항 및 경고

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

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

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

  • 최대 종단 간의 일관성 없는 업스트림 경로 탐지는 지원되지 않습니다. 수신기측(송신) 라우팅 장비는 서로 협소한 업스트림 디바이스(이전 홉)만 보장합니다. PIM 및 멀티포인트 LDP는 ERO(Explicit Route Objects)와 동등한 수준을 지원하지 않습니다. 따라서, 해체된 업스트림 경로 탐지는 이전 홉 디바이스에 대한 제어로 제한됩니다. 이러한 제한으로 인해 기본 및 백업으로 선택된 이전 홉의 업스트림 디바이스로 향하는 경로가 공유될 수 있습니다.

  • 다음 시나리오에서 트래픽 손실이 발생할 수 있습니다.

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

    • 송신 디바이스에 활성 트래픽 스트림이 흐르는 동안 MoFRR을 활성화하거나 비활성화합니다.

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

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

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

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

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

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

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

PIM을 통한 스위칭 디바이스에 대한 MoFRR 제한 사항

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

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

  • 멀티캐스트 트래픽을 포워딩하는 동안 패킷 복제 및 멀티캐스트 조회는 패킷이 PFE를 통해 여러 번 재순환할 수 있습니다. 따라서 명령의 멀티캐스트 패킷 카운트 show pfe statistics traffic 에 대한 표시된 값은 등과 Output packets같은 Input packets 출력 필드에서 예상보다 높은 숫자를 표시할 수 있습니다. 기본 스트림과 백업 스트림이 복제되어 트래픽 흐름이 전반적으로 증가하기 때문에 MoFRR 시나리오에서 이러한 동작을 보다 자주 확인할 수 있습니다.

멀티포인트 LDP를 통한 라우팅 장치에 대한 MoFRR 제한 사항 및 경고

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

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

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

  • 내부 레이블로 다중점 LDP 레이블은 지원되지 않습니다.

  • 소스가 여러 수신(소스측) PE(Provider Edge) 라우팅 장비를 통해 도달 가능한 경우, 멀티포인트 LDP MoFRR은 지원되지 않습니다.

  • 대상 LDP 업스트림 세션은 MoFRR용 업스트림 장치로 선택되지 않습니다.

  • MoFRR 내부 레이블에 대한 지원이 없기 때문에 백업 경로의 멀티포인트 LDP 링크 보호는 지원되지 않습니다.

멀티캐스트 전용 Fast Reroute 구성

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

빠른 재라우트가 유니캐스트 스트림에 적용되면, 업스트림 라우터는 MPLS LSP(Label-Switched Path)를 프리스테이션하거나, 다운스트림 경로에서 세그먼트의 장애를 처리하기 위해 IP 루프 없는 대체(LFA) Frrte 백업 경로를 미리 구성합니다.

멀티캐스트 라우팅에서 트래픽 배포 그래프는 일반적으로 수신기에 의해 시작됩니다. 이는 일반적으로 소스에서 수신기로 경로를 설정하는 유니캐스트 라우팅과는 다릅니다. 멀티캐스트 분산 그래프를 설정할 수 있는 프로토콜은 PIM(IP), MPLS용 멀티포인트 LDP 및 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 도메인에서는 ASM(Any-Source Multicast)(*,G) 조인에 MoFRR을 적용할 수 있습니다.

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

  6. (선택사항) MoFRR이 있는 PIM 도메인에서는 서로 다른 RPF(별도의 평면의 RPF)만 백업 RPF 경로로 선택할 수 있습니다.

    이는 멀티포인트 LDP MoFRR에서는 지원되지 않습니다. 멀티포인트 LDP MoFRR 도메인에서 동일한 업스트림 이웃에 대한 병렬 링크 간에 동일한 레이블이 공유됩니다. 각 링크가 이웃을 형성하는 PIM 도메인에서는 이러한 경우가 아닙니다. 이 명령문은 mofrr-disjoint-upstream-only 경로가 기본 RPF 경로와 동일한 업스트림 이웃으로 가는 경우 백업 RPF 경로를 선택하는 것을 허용하지 않습니다. 이를 통해 다중 RPF 업스트림 이웃이 있는 토폴로지에서만 MoFRR이 트리거됩니다.

  7. (선택사항) MoFRR이 있는 PIM 도메인에서는 백업 경로에서 조인 메시지를 보내는 것을 방지하지만 다른 모든 MoFRR 기능은 그대로 유지합니다.

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

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

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

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

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

이 예에서는 링크 장애가 발생한 경우 네트워크에서 패킷 손실을 최소화하기 위해 모FRR(Multicast-only Fast Reroute)을 구성하는 방법을 보여줍니다.

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

요구 사항

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

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

MoFRR은 MPC 라인 카드가 있는 MX 시리즈 플랫폼에서 지원됩니다. 사전 필수 사항인 라우터는 모드로 설정 network-services enhanced-ip 해야 하며 플랫폼의 모든 라인 카드는 MPC여야 합니다.

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

개요

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

OSPF는 연결에 사용되지만 모든 IGP(Interior Gateway Protocol) 또는 정적 경로를 사용할 수 있습니다.

테스트 목적으로 라우터는 소스와 수신기를 시뮬레이션하는 데 사용됩니다. 디바이스 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 탐색에 대한 자세한 내용은 Junos OS CLI 사용자 가이드의 Configuration 모드에서 CLI Editor를 사용하는 것을 참조하십시오.

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

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

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

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

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

  5. PIM을 구성합니다.

  6. LDP를 구성합니다.

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

  8. 내부 BGP를 구성합니다.

  9. MPLS 및 선택적으로 RSVP를 구성합니다.

  10. MoFRR을 활성화합니다.

결과

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

디바이스 구성을 완료한 경우 구성 모드에서 입력 commit 합니다.

확인

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

LDP Point-to-Multipoint Forwarding Equivalency Classes 확인

목적

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

실행
의미

이 출력은 MoFRR이 활성화됨을 보여주며, 301568 레이블과 301600이 2개의 멀티포인트 LDP P2P에서 멀티포인트 LSP에 사용되고 있음을 보여줍니다.

라벨 정보 검사

목적

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

실행
의미

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

멀티캐스트 경로 확인

목적

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

실행
의미

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

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

목적

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

실행
의미

출력은 Label을 통한 기본 및 백업 경로를 모두 보여줍니다.

예를 들면 다음과 같습니다. 온 디맨드 LDP 다운스트림 구성

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

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

요구 사항

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

  • M 시리즈 라우터

  • Junos OS 12.2

개요

계층 수준에서 다운스트림 온디맨드 명령문을 포함함으로써 LDP 세션에 대한 LDP 다운스트림 온 디맨드 레이블 광고를 활성화할 [edit protocols ldp session] 수 있습니다. 온 디맨드 방식의 다운스트림을 구성한 경우 주니퍼 네트웍스 라우터는 해당 피어 라우터에 온디맨드 방식의 다운스트림 요청을 알려 드립니다. 두 라우터 간에 다운스트림 온 디맨드 세션을 설정하려면 LDP 세션 설정 중에 모두 온 디맨드 모드로 다운스트림을 광고해야 합니다. 한 라우터가 다운스트림 원치 않는 모드를 광고하고 다른 라우터가 온 디맨드 방식에서 다운스트림을 광고하는 경우 다운스트림 비청정 모드가 사용됩니다.

구성

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

단계별 절차

온 디맨드 방식으로 LDP 다운스트림을 구성한 다음 해당 정책을 구성하고 LDP 세션에서 온 디맨드 방식으로 LDP 다운스트림을 활성화하려면 다음을 수행합니다.

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

    이 정책으로 인해 라우터는 DOD-Request-Loopbacks 정책에 따라 일치하는 FEC에만 Label Request 메시지를 전달합니다.

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

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

  3. downstream-on-demand 온 디스트리미드 디스트리모드를 다운스트림할 수 있도록 LDP 세션 구성에 명령문을 포함합니다.

LDP 다운스트림 온 디맨드 경로의 레이블 BGP로 분산

단계별 절차

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

  1. LDP 경로 정책(redistribute_ldp 이 예)을 구성합니다.

  2. LDP 경로 정책을 redistribute_ldp BGP 구성에 포함합니다(이 예에서는 BGP 그룹 구성 ebgp-to-abr 의 일부로서).

    BGP는 정책에 따라 redistribute_ldp LDP 경로를 원격 PE 라우터로 전달합니다.

단계별 절차

다운스트림 원치 않는 모드로 구성된 다른 라우터로 레이블 전파를 제한하려면(온 디맨드 방식의 다운스트림 대신), 다음 정책을 구성합니다.

  1. LDP에서 라우트의 dod-routes 허용을 위해 정책을 구성합니다.

  2. do-not-propagate-du-sessions 정책을 구성하여 루트를 이웃으로 1.1.1.1전달하지 않음 . 2.2.2.23.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 protocols ldp 명령을 입력하여 구성을 show policy-options 확인합니다. 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

확인

Label Advertisement 모드 검증

목적

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

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

실행

show ldp session 문제 및 show ldp session detail 명령어:

  • 명령에 대한 show ldp session 다음 명령 출력은 (Label advertisement 모드)가 (온 디맨드 세션의 LDP 다운스트림이 작동 중임을 의미함)DOD을 나타낸다 Adv. Mode .

  • 명령어에 show ldp session detail 대한 다음 명령 출력은 기본값(Downstream unsolicitedLocal Label Advertisement mode온 디맨드 시 다운스트림이 로컬 세션에서 구성되지 않음)을 나타냅니다. 반대로, Remote Label Advertisement mode 이 두 Negotiated Label Advertisement mode 가지 모두 원격 세션에 구성된 것을 Downstream on demand 나타냅니다.

LDP 네이티브 IPv6 지원 구성

LDP는 RFC 7552에서 설명한 대로 IPv6 전용 네트워크 및 IPv6 또는 IPv4 듀얼 스택 네트워크에서 지원됩니다. IPv4 또는 IPv6 또는 inet6 둘 다에 대해 inet 주소 제품군을 구성하고 전송 기본 설정 중 하나 IPv4 또는 IPv6. 이 명령문은 dual-transport Junos OS LDP가 IPv4 neighbor를 통해 IPv4를 통해, IPv6 neighbor를 단일 스택 LSR로 IPv6를 통해 TCP 연결을 설정할 수 있도록 지원합니다. inet-lsr-id 및 ID는 IPv4 및 inet6-lsr-id IPv6 TCP 전송을 통해 LDP 세션을 설정하도록 구성해야 하는 2개의 LSR ID입니다. 이들 2개의 IPD는 비 제로이며 서로 다른 값으로 구성되어야 합니다.

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

LDP 네이티브 IPv6 지원을 구성하려면 다음을 수행해야 합니다.

  1. 여러 주소 제품군에 서로 다른 레이블을 사용하기 위해 포워딩 FEC(Equivalence Class) 분할을 지원합니다.
  2. LDP 주소 제품군을 구성합니다.
  3. transport-preference IPv4와 IPv6를 모두 활성화할 때 TCP 연결에 대한 기본 전송을 선택하도록 명령문을 구성합니다. 기본적으로 IPv6는 LDP 연결 구축을 위한 TCP 전송으로 사용됩니다.
  4. (선택사항) LDP가 IPv4 neighbor와 함께 별도의 IPv4 세션과 IPv6 neighbor가 있는 IPv6 세션을 설정할 수 있도록 이중 전송을 구성합니다. IPv4용 LSR ID와 inet6-lsr-id IPv6용 LSR ID로 구성 inet-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 neighbor를 이용한 IPv4상에서 TCP 연결을 설정하고 IPv6 neighbor를 단일 스택 LSR로 설정하는 방법을 보여줍니다. 이를 통해 IPv4 신호가 전송되는 MPLS LSP(Label-Switched Path)를 사용하여 IPv4 MPLS 코어에서 IPv6의 터널링을 방지할 수 있습니다.

요구 사항

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

  • 2개의 MX 시리즈 라우터

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

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

개요

LDP는 RFC 7552에서 설명한 대로 IPv6 전용 네트워크 및 IPv6 또는 IPv4 듀얼 스택 네트워크에서 지원됩니다. IPv4 또는 inet6 IPv6용으로 inet 주소 제품군을 구성합니다. 기본적으로 IPv6는 IPv4와 IPv6를 모두 활성화할 때 피어와 함께 LDP 세션을 위한 TCP 전송으로 사용됩니다. 듀얼 전송 명령문은 Junos LDP가 IPv4 neighbor를 통해 IPv4를 통해, IPv6 neighbor를 단일 스택 LSR로 IPv6를 통해 TCP 연결을 설정할 수 있도록 지원합니다. 그리고 IPv4 inet-lsr-idinet6-lsr-id IPv6 TCP 전송을 통해 LDP 세션을 설정하도록 구성해야 하는 2개의 LSR ID입니다. 이들 2개의 IPD는 비 제로이며 서로 다른 값으로 구성되어야 합니다.

토폴로지

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

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

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣고, 줄 바꿈을 제거하고, 네트워크 구성에 필요한 세부 정보를 변경하고, 명령을 계층 수준에서 CLI [edit] 에 복사 및 붙여넣은 다음 구성 모드에서 입력 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(Equivalence Class) 분할을 지원합니다.

  6. LDP 주소 제품군을 구성합니다.

결과

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

기본 전송 선택으로 전송 기본 설정 구성

CLI 빠른 구성
단계별 절차

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

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

단계별 절차
결과

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

이중 전송을 구성하여 IPv4 Neighbor와 IPv6 Neighbor를 통한 IPv4용 별도 세션 설정

단계별 절차

LDP가 dual-transport IPv4 neighbor와 함께 별도의 IPv4 세션과 IPv6 neighbor가 있는 IPv6 세션을 설정할 수 있도록 명령문을 구성할 수 있습니다. 이를 위해서는 IPv4용 LSR ID와 inet6-lsr-id IPv6용 LSR ID로 구성 inet-lsr-id 해야 합니다.

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

결과

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

확인

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

mpls.0 테이블의 Route Entries 검증
목적

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

실행

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

의미

출력은 mpls.0 라우팅 테이블 정보를 보여줍니다.

inet.3 테이블의 Route Entries 검증
목적

inet.3 라우팅 테이블 정보를 표시합니다.

실행

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

의미

출력은 inet.3 라우팅 테이블 정보를 보여줍니다.

inet6.3 테이블의 Route Entries 검증
목적

inet6.3 라우팅 테이블 정보를 표시합니다.

실행

디바이스 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에서 작동 모드에서 및 show ldp neighbor extensive 명령을 실행 show ldp neighbor 하여 LDP neighbor 정보를 표시합니다.

의미

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

LDP 세션 정보 검증
목적

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

실행

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

의미

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

확인

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

LDP Neighbor 정보 검증
목적

LDP neighbor 정보를 표시합니다.

실행

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

의미

출력은 IPv4 및 IPv6 주소 모두에 대한 LDP 인접 정보를 보여줍니다.

LDP 세션 정보 검증
목적

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

실행

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

의미

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

확인

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

LDP Neighbor 정보 검증
목적

LDP neighbor 정보를 표시합니다.

실행

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

의미

출력은 IPv4 및 IPv6 주소 모두에 대한 LDP 인접 정보를 보여줍니다.

LDP 세션 정보 검증
목적

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

실행

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

예를 들면 다음과 같습니다. 점대다점 LSP를 위한 멀티포인트 LDP 인밴드 시그널링 구성

점대다점 LSP를 위한 멀티포인트 LDP 인밴드 시그널링 이해

인밴드 시그널링이 있는 P2M(Point-to-Multipoint) LSP(Label-Switched Path)를 위한 M-LDP(Multipoint Label Distribution Protocol)는 예를 들어 IPTV를 위해 멀티캐스트 트래픽을 전송해야 하는 기존 IP/MPLS 백본이 있는 구축 환경에서 유용합니다.

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

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

이를 위해 서비스 프로바이더는 멀티캐스트 트래픽이 통과할 수 있도록 기존 구축의 확장을 활용하는 데 관심이 있습니다. IP/MPLS를 위한 기존 멀티캐스트 확장은 RSVP-TE를 위한 P2M(Point-to-Multipoint) 확장, LDP를 위한 P2M(Point-to-Multipoint) 확장 및 멀티포인트 간 확장입니다. 이러한 구축 시나리오는 RFC 6826, 점대다점(Point-to-Multipoint)을 위한 멀티포인트 LDP 인밴드 시그널링, 멀티포인트에서 멀티포인트로의 레이블 스위칭 경로에 대해 설명합니다. 이 기능 개요는 LDP에 대한 점대다점 확장으로 제한됩니다.

M-LDP의 작동 방식

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

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

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

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

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

LER(Label-Edge Router)의 구성 명령문을 mldp-inband-signalling 통해 PIM은 LER가 PIM 업스트림 이웃을 감지하지 못할 때 업스트림 이웃에 대해 M-LDP 인밴드 시그널링을 사용할 수 있습니다. 정책을 사용하여 MPLS LSP 루트의 정적 구성이 PIM 구성에 포함됩니다. 이는 코어 사이트에서 IBGP를 사용할 수 없거나 IBGP 기반 LSP 루트 감지를 무시하기 위해 필요합니다.

예를 들어,

PIM 지원 MPLS 코어의 M-LDP

Junos OS Release 14.1부터 시작해 기존 IPTV 서비스를 네이티브 IP 멀티캐스트에서 MPLS 멀티캐스트로 마이그레이션하려면 최소한의 가동 중단 없이 PIM에서 M-LDP P2P로 원활하게 전환해야 합니다. 그림 20 유사한 M-LDP 토폴로지와 같은 그림 19것을 보여 주지만, 다른 시나리오에서는 다릅니다. 코어는 PIM을 통해 지원되며 단일 소스가 모든 IPTV 채널을 스트리밍합니다. TV 채널은 그룹 주소로 식별된 각 채널을 가진 ASM 스트림으로 전송됩니다. 이전에는 이러한 채널이 코어에서 IP 스트림으로 스트리밍되고 PIM을 사용하여 신호를 받았습니다.

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

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

구성

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

주:

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

예를 들어,

주:

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

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

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

용어

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

P2P LSP

수신 LSR(Ingress Label-Switched Router)과 1개의 송신 LSR이 있는 LSP입니다.

멀티포인트 LSP

P2P(Point-to-Multipoint) 또는 멀티포인트-멀티포인트 LSP 중 하나

P2P(Point-to-Multipoint) LSP

수신 LSR 1개와 송신 LSR이 하나 이상 있는 LSP입니다.

멀티포인트 투 포인트 LSP

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

멀티포인트-멀티포인트 LSP

LSP의 모든 노드에서 전송되는 트래픽이 다른 모든 노드에 전달되도록 일련의 노드를 연결하는 LSP입니다.

수신 LSR

특정 LSP의 수신 LSR은 LSP를 따라 데이터 패킷을 보낼 수 있는 LSR입니다. 멀티포인트-멀티포인트 LSP는 여러 수신 LSR을 가질 수 있습니다. P2P LSP는 단 하나뿐이며 이 노드를 루트 노드라고도 합니다.

송신 LSR

특정 LSP를 위한 송신 LSR은 추가 처리를 위해 해당 LSP에서 데이터 패킷을 제거할 수 있는 LSR입니다. P2P(Point-to-Point) 및 멀티포인트 투 포인트 LSP는 단일 송신 노드만을 갖는다. P2P(Point-to-Multipoint) 및 멀티포인트-멀티포인트 LSP는 여러 송신 노드를 가질 수 있습니다.

전송 LSR

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

Bud LSR

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

리프 노드

P2P(Point-to-Multipoint) LSP의 맥락에서 송신 또는 bud LSR 멀티포인트-멀티포인트 LSP의 맥락에서 LSR은 동일한 멀티포인트-멀티포인트 LSP에 대한 수신 및 송신이며 새싹 LSR이 될 수도 있습니다.

Ingress Join Translation 및 의사 인터페이스 처리

ingress LER에서 LDP는 PIM에게 인밴드 시그널링을 통해 수신되는 (S,G) 메시지에 대해 통보합니다. PIM은 각(S,G) 메시지를 의사 인터페이스와 연결합니다. 그 후, 최단 경로 트리(SPT) 조인 메시지가 소스로 시작됩니다. PIM은 이를 새로운 유형의 로컬 수신기로 취급합니다. LSP가 철거되면 PIM은 LDP의 통보를 기반으로 이 로컬 수신기를 제거합니다.

수신 스플라이싱

LDP는 PIM에 각(S,G) 엔트리와 연결될 다음 홉을 제공합니다. PIM은 LDP Next Hop 및 기타 PIM 수신기와 함께 PIM(S,G) 멀티캐스트 경로를 설치합니다. 다음 홉은 로컬 수신기의 복합 다음 홉 + PIM 다운스트림 neighbor 목록 + LDP 터널을 위한 하위 레벨 다음 홉입니다.

역방향 경로 포워딩

PIM의 RPF(reverse-path-forwarding) 계산은 egress 노드에서 수행됩니다.

PIM은 다음과 같은 모든 조건이 사실일 때 M-LDP 대역 내 시그널링을 수행합니다.

  • 소스에 대한 PIM 이웃이 없습니다.

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

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

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

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

LSP 루트 감지

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

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

  1. 기존 정적 구성이 소스 주소를 지정하는 경우 루트는 구성에서 지정된 대로 가져옵니다.

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

    Junos OS Release 16.1에 앞서 M-LDP P2M LSP는 수신 LSR의 루트 주소를 사용하여 송신에서 수신으로 신호를 전달합니다. 이 루트 주소는 IGP만을 통해 도달 가능하기 때문에 M-LDP P2M(Point-to-Multipoint) LSP를 단일 자율 시스템으로 제한할 수 있습니다. 루트 주소가 IGP를 통해 도달 가능하지 않고 BGP를 통해 도달 가능하지 않고 BGP 경로가 MPLS LSP를 통해 재발행되는 경우, 해당 지점에서 수신 LSR 루트 주소로 더 이상 신호가 전달되지 않습니다.

    다음과 같은 애플리케이션에 사용할 수 있는 여러 자율 시스템 전반에서 이러한 비세그먼테이션 P2P LSP 신호를 전송해야 합니다.

    • 비세그먼테이션된 P2M(Point-to-Multipoint) LSP를 갖춘 AS 간 MVPN.

    • INTER-AS M-LDP는 MPLS 코어 네트워크로 연결된 클라이언트 네트워크 간의 인밴드 시그널링을 제공합니다.

    • 비 세그먼트화된 P2M(Point-to-Multipoint) LSP(원활한 MPLS 멀티캐스트)를 통한 영역 간 MVPN 또는 M-LDP 대역 신호 전송

    Junos OS Release 16.1부터 시작하여, M-LDP는 루트 주소가 BGP 경로인 경우 ASBR에서 점대다점 LSP에 신호를 전달하거나 MPLS LSP를 통해 추가적으로 해결되는 BGP 경로인 경우 전송 또는 송신을 할 수 있습니다.

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

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

송신 스플라이싱

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

지원되는 기능

M-LDP 대역 내 시그널링의 경우, Junos OS는 다음과 같은 기능을 지원합니다.

  • LDP 경로로 PIM 다음 홉의 송신 스플라이싱

  • LDP 다음 홉을 사용한 PIM 경로의 수신 스플라이싱

  • PIM 조인 메시지를 LDP P2M(Point-to-Multipoint) LSP 설정 매개변수로 변환

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

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

  • PIM(S,G) 상태는 PIM SSM(Source-Specific Multicast) 및 ASM(anysource multicsast) 범위 내

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

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

송신 LER 기능

egress LER에서 PIM은 다음 정보를 가진 LDP를 트리거하여 P2M(Point-to-Multipoint) LSP를 생성합니다.

  • 루트 노드

  • (S,G)

  • 다음 홉

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

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

멀티캐스트 트리의 소스에 대한 루트 주소가 변경되면 PIM은 점대다점 LSP를 삭제하고 LDP를 트리거하여 새로운 P2M LSP를 생성합니다. 이 경우 송신 인터페이스 목록이 NULL이 되고, PIM이 LDP를 트리거하여 점대다점 LSP를 삭제하고, LDP는 업스트림 노드로 레이블 철회 메시지를 보냅니다.

전송 LSR 기능

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

수신 LER 기능

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

  • (S,G)

  • 플러드 다음 홉

그런 다음 PIM은 포워딩 상태를 설치합니다. 새 브랜치를 추가하거나 삭제하면 플러드 다음 홉이 그에 따라 업데이트됩니다. 라벨 철회로 인해 모든 브랜치가 삭제되면 LDP는 업데이트된 정보를 PIM에 보냅니다. 업스트림과 다운스트림 이웃 간에 여러 링크가 있는 경우, P2P LSP는 로드 밸런서스가 되지 않습니다.

예를 들면 다음과 같습니다. 점대다점 LSP를 위한 멀티포인트 LDP 인밴드 시그널링 구성

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

요구 사항

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

  • Junos OS 릴리스 13.2 이상

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

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

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

주:

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

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

개요

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

그림 21: P2M-Multipoint LSP를 위한 M-LDP 인밴드 시그널링(In-LDP In-Band Signaling) 예시 토폴로지P2M-Multipoint LSP를 위한 M-LDP 인밴드 시그널링(In-LDP In-Band Signaling) 예시 토폴로지

구성

절차
CLI 빠른 구성

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

디바이스 src1

디바이스 IngressPE

디바이스 송신PE

디바이스 p6

디바이스 pr3

디바이스 pr4

디바이스 pr5

단계별 절차

다음 예제에서는 구성 계층에서 다양한 레벨을 탐색해야 합니다. CLI 탐색에 대한 자세한 내용은 CLI 사용자 가이드의 Configuration Mode에서 CLI Editor를 사용하는 것을 참조하십시오.

Device EgressPE를 구성하려면 다음을 수행합니다.

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

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

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

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

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

  4. BGP를 구성합니다.

    BGP는 정책 기반 프로토콜이므로 필요한 라우팅 정책도 구성하고 적용합니다.

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

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

  6. OSPF를 구성합니다.

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

  8. 점대다점 MPLS LSP를 활성화합니다.

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

  10. 이 디바이스가 PIM RP(rendezvous point) 역할을 하므로 RP 설정을 구성합니다.

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

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

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

결과

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

디바이스 송신PE

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

디바이스 구성을 완료한 경우 구성 모드에서 입력 commit 합니다.

확인

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

PIM 조인 상태 확인
목적

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

실행

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

PIM 소스 확인
목적

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

실행

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

LDP 데이터베이스 검사
목적

명령이 show ldp database 예상 루트 투(S,G) 바인딩을 표시해야 합니다.

실행
MPLS Label의 경로 정보 조회
목적

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

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

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

실행

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

세그먼트 라우팅을 점진적으로 구축하는 LDP 네트워크에서는 LDP만 지원하거나 세그먼트 라우팅만 지원하는 디바이스가 존재할 수 있습니다. 디바이스가 상호 연동되기 위해서는 세그먼트 라우팅 네트워크의 모든 디바이스에서 LDP 매핑 서버 기능을 구성해야 합니다.

LDP 매핑 서버 기능은 OSPF 또는 ISIS 중 하나를 사용하여 구현됩니다.

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

OSPF를 사용하여 세그먼트 라우팅의 상호 운용성을 구현하기 위해 모든 LDP 접두사에 대한 범위, 길이 및 값(TLV)을 사용하는 확장된 접두사 링크 상태 광고(LSA)가 생성되고, inet.3 및 mpls.0 라우팅 테이블에 prefix에 해당하는 매핑 경로가 설치됩니다.

그림 22 OSPF를 사용하는 LDP 장치와 세그먼트 라우팅 디바이스의 상호 운용성을 설명하기 위해 사용되는 단순한 LDP 네트워크 토폴로지입니다. 토폴로지의 디바이스에는 LDP-세그먼트 라우팅 마이그레이션과 함께 6개의 디바이스(디바이스 R1, R2, R3, R4, R5, R6)가 있습니다.

그림 22: OSPF를 사용한 LDP와 세그먼트 라우팅의 상호운용성을 갖춘 LDP 토폴로지 샘플OSPF를 사용한 LDP와 세그먼트 라우팅의 상호운용성을 갖춘 LDP 토폴로지 샘플

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

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

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

주:

LDP 네트워크에서 장비의 루프백 주소로 start-prefix 사용되는 IP 주소(이 예에서는 Device R5).

LDP 매핑 서버 구성이 Device R2에서 커밋되면 확장된 접두사 범위 TLV가 OSPF 영역 전반으로 플러드됩니다. 세그먼트 라우팅(디바이스 R1, R2 및 R3)을 수행할 수 있는 디바이스는 SID(Segment ID) 인덱스와 함께 지정된 루프백 주소에 대해 OSPF 세그먼트 라우팅 경로를 설치합니다. SID 인덱스는 세그먼트 라우팅 장치에 의해 mpls.0 라우팅 테이블에서도 업데이트됩니다.

Junos OS 릴리스 19.1R1부터 세그먼트 라우팅-LDP 경계 라우터는 세그먼트 라우팅 트래픽을 LDP Next-Hop에 연결하고 그 반대의 경우도 마찬가지입니다.

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

  • Prefix 충돌은 소스 구성에서만 감지됩니다. 접두사 범위 충돌이 발생하면 하위 라우터 ID의 Prefix SID가 우선합니다. 이 경우 시스템 로그 오류 메시지가RPD_OSPF_PFX_SID_RANGE_CONFLICT 생성됩니다.

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

  • 자율 시스템(AS)을 위한 세그먼트 라우팅 매핑 서버에서 생성된 OSPF Extended 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) 디바이스(Devices P5, P6, P7, P8)가 있습니다.

그림 23: ISIS를 사용한 LDP와 세그먼트 라우팅의 상호 운용성을 갖춘 LDP 토폴로지 샘플ISIS를 사용한 LDP와 세그먼트 라우팅의 상호 운용성을 갖춘 LDP 토폴로지 샘플

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

지속적인 MPLS 터널을 사용하여 Device PE3 및 Device PE1로 터널링되는 서비스 플로우를 위해서는 세그먼트 라우팅 및 LDP를 지원하는 디바이스의 섬이 상호 운영되어야 합니다.

LDP Mapping Client Functionality (LDP to Segment Routing)

LDP 클라이언트 기능은 LDP-세그먼트 라우팅 매핑이며, 이는 에서 우측에서 좌측으로 트래픽 흐름 그림 23입니다. Device P6에서 LDP egress 정책은 왼쪽의 세그먼트 라우팅 네트워크에서 모든 노드 SID 및 Prefix SID를 광고하도록 구성됩니다. 그 결과, 장비 P6에서 LDP는 Devices PE1, PE2 및 P5를 Device P7에 대한 egress FEC Label 바인딩으로 광고합니다.

Device PE3는 다음 홉 프로토콜로 Device PE1을 통해 서비스 경로를 학습했습니다. 장비 PE3에는 PE1 FEC에 대한 P8 다음 홉에서 LDP 레이블이 바인딩됩니다. 그 결과, Device PE3는 기존 LDP 동작에 따라 서비스 패킷을 Device P8로 보냅니다. Device P8에는 PE1 FEC에 대한 P7 다음 홉에서 LDP 레이블이 바인딩되므로 Device P8은 기존 LDP 동작에 따라 Device P7로 전달됩니다.

장비 P7에는 P6 다음 홉인 PE1 FEC로부터 LDP 레이블이 바인딩되기 때문에, Device P7은 클래식 LDP 동작에 따라 Device P6로 전달됩니다.

Device P6that은 PE1 FEC에 대한 LDP 송신의 역할을 하며, PE1 FEC를 위한 수신 송신 LDP 레이블을 동급 세그먼트 라우팅 노드 SID(이 예의 101)로 바꿔 트래픽을 Device P5로 전달합니다.

Device P5는 Device PE1이 Penultimate-pop 플래그 집합으로 노드 세그먼트 101을 광고한 다음 트래픽을 Device PE1로 전달한다고 가정하여 101 SID를 파핑합니다. 장비 PE1은 터널링된 패킷을 반복하고 서비스 레이블을 처리합니다.

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

LDP Mapping Server Functionality (Segment Routing to LDP)

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

여기에서 Device P6는 세그먼트 라우팅 매핑 서버(SRMS)의 역할을 하며 다음과 같은 매핑(P7, 107), (P8, 108), (PE3, 103), (PE4, 104) 및 (P7, 107)을 광고합니다. Device PE3에서 세그먼트 라우팅이 지원되었다면 노드 SID 103은 Device PE3에서 구성되었을 것입니다. Device PE3는 세그먼트 라우팅을 지원하지 않기 때문에, 정책은 Device P6의 SRMS에서 구성되며, Device P6는 매핑 광고를 담당합니다.

이러한 매핑 서버 광고는 세그먼트 라우팅 디바이스에서만 이해할 수 있습니다. 세그먼트 라우팅 장비는 노드 자체에서 노드 세그먼트가 광고된 방식과 정확히 어떻게 MPLS 데이터 플레인에 관련 노드 SID를 설치합니다. 예를 들어, Device PE1은 Device PE3가 SID 103을 광고한 것처럼 노드 SID 103을 P5 다음 홉에 설치합니다.

Device PE1은 PE3를 프로토콜 넥넥스 홉(next hop)으로 사용한 서비스 루트를 가지고 있습니다. 장비 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을 1037로 바꿔 디바이스 P7로 전달합니다.

Device P7은 이 레이블을 Device P8에서 수신한 LDP 레이블로 바꿉니다. 그런 다음 Device P8로 전달합니다. LDP 레이블은 Device P8에 의해 튀어나와 Device PE3로 포워딩됩니다.

디바이스 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 Label로 교체하는 MPLS 전송 경로를 프로그래밍하여 세그먼트 라우팅 도메인에서 LDP 도메인으로 트래픽을 전환함으로써 세그먼트 라우팅 LSP를 LDP LSP에 연결합니다.

그림 24 세그먼트 라우팅과 LDP LSP의 연계를 보여 줍니다.

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

토폴로지에서 Device PE3는 LDP를 지원하며 세그먼트 라우팅을 지원하지 않습니다. 세그먼트 라우팅 도메인의 매핑 서버는 P7, P8 및 PE4 디바이스에 대한 TLV 바인딩 레이블을 알 수 있습니다. 이러한 시나리오에서 Device PE1은 Prefix SID와 원격 레이블이 TLV 및 SID를 결합하여 Device PE4에 도달할 수 있습니다. 그러나 Device PE1은 TLV를 결합하는 원격 레이블보다 Prefix SID를 선호하는 동시에 Device PE4를 위한 수신 세그먼트 라우팅 경로를 프로그래밍합니다. 그 결과, Device PE1은 세그먼트 라우팅 LSP를 엔드 투 엔드로 사용하여 디바이스 PE4로 트래픽을 전송하고, Device PE3로 트래픽을 전송하는 동안 세그먼트 라우팅-LDP 스티칭을 사용합니다.

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

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

  • TLV를 바인딩하는 레이블의 범위의 접두사 광고는 지원되지 않습니다.

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

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

  • NSR(Nonstop Active Routing) 및 GRES(Graceful Routing Engine Switchover)는 지원되지 않습니다.

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

  • RFC 7794, 확장 IPv4를 위한 IS-IS Prefix 속성 은 지원되지 않습니다.

  • 스티칭 노드에서 LDP 경로를 접두사 시드로 재분배하는 것은 지원되지 않습니다.

기타 LDP 속성 구성

다음 섹션에서는 여러 가지 기타 LDP 속성을 구성하는 방법을 설명합니다.

IGP Route Metric을 사용하도록 LDP 구성

track-igp-metric 기본 LDP 경로 메트릭(기본 LDP 경로 메트릭은 1)이 아니라 IGP(Interior Gateway Protocol) 루트 메트릭을 LDP 경로에 사용하기를 원하는 경우 명령문을 사용합니다.

IGP 라우트 메트릭을 사용하려면 다음과 같은 명령문을 track-igp-metric 포함합니다.

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

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

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

주:

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

inet.0 라우팅 테이블에서 ingress 경로를 생략하려면 다음과 같은 명령문을 no-forwarding 포함합니다.

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

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

여러 LDP 라우팅 인스턴스를 구성함으로써 LDP를 사용하여 서비스 프로바이더 PE(Carrier-of-Carrier) 라우터에서 고객 CE(Customer Edge) 라우터로 캐리어급 VPN의 레이블을 알릴 수 있습니다. 이는 서비스 프로바이더 고객이 기본적인 ISP(Internet Service Provider)이며 전체 인터넷 경로를 PE 라우터로 제한하려는 경우에 특히 유용합니다. BGP 대신 LDP를 사용함으로써 통신 사업자 고객은 다른 내부 라우터를 인터넷으로부터 보호합니다. 다중 인스턴스 LDP는 통신 사업자 고객이 고객에게 Layer 2 또는 Layer 3 VPN 서비스를 제공하려고 할 때도 유용합니다.

통신 사업자 VPN을 위해 여러 LDP 라우팅 인스턴스를 구성하는 방법의 예는 Label Distribution Protocol User Guide를 위한 다중 인스턴스를 참조하십시오.

궁극의 홉 라우터에서 LABEL을 팝업하도록 MPLS 및 LDP 구성

기본 광고 레이블은 Label 3(암시적 Null Label)입니다. Label 3이 광고되면 Penultimate-hop 라우터는 Label을 제거하고 패킷을 송신 라우터로 보냅니다. 궁극의 홉 터핑이 활성화되면 Label 0(IPv4 Explicit Null Label)이 광고됩니다. 궁극적인 홉 터핑(Ultimate-hop popping)은 MPLS 네트워크를 통과하는 모든 패킷에 Label을 포함하도록 보장합니다.

궁극의 홉 터핑을 구성하려면 다음과 같은 문장을 포함하십시오 explicit-null .

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

주:

주니퍼 네트웍스 라우터는 수신 레이블을 기반으로 패킷을 큐에 줍니다. 다른 벤더의 라우터는 패킷을 다르게 큐에 큐할 수 있습니다. 여러 벤더의 라우터가 포함된 네트워크를 사용할 때는 이러한 점을 유념해야 합니다.

레이블에 대한 자세한 내용은 MPLS Label 개요MPLS Label 할당을 참조하십시오.

RSVP 설정 LSP를 통한 LDP 지원

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

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

이기종 네트워크에서 RSVP 기반 LSP를 통한 LDP 지원

일부 다른 벤더는 루프백 주소에 대해 OSPF 메트릭 1을 사용합니다. 주니퍼 네트웍스 라우터는 루프백 주소에 대해 OSPF 메트릭 0을 사용합니다. 이기종 네트워크에서 RSVP LSP에 LDP 터널링을 구축할 때 RSVP 메트릭을 수동으로 구성해야 할 수도 있습니다.

RSVP 터널을 통해 주니퍼 네트웍스 라우터를 다른 벤더의 라우터에 연결하고 LDP 터널링이 활성화되면 기본적으로 주니퍼 네트웍스 라우터는 RSVP 터널을 사용해 다른 벤더의 송신 라우터의 LDP 대상 다운스트림으로 트래픽을 라우팅하지 못할 수 있습니다.

이기종 네트워크에서 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 시그니처를 구성하여 LDP 세션 연결 스트림에 스푸핑된 TCP 세그먼트가 유입되는 것을 차단할 수 있습니다.

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

서로 다른 보안 시그니처로 피어링 인터페이스를 구성한 경우에도 여전히 LDP hello adjacencies를 생성할 수 있습니다. 그러나 TCP 세션은 인증할 수 없으며 설정되지도 않습니다.

Junos OS Release 16.1R1부터 LDP 세션을 위한 HMAC(Hashed Message Authentication Code) 및 MD5 인증에 대한 지원이 세션당 구성에서 서브넷 매치(즉, 가장 긴 접두사 일치) 구성으로 확장됩니다.

서브넷 매치 인증에 대한 지원은 자동 대상 LDP(TLDP) 세션을 위해 인증을 구성하는 유연성을 제공하므로 원격 루프 없는 대체(LFA) 및 FEC 129 의사 회선의 구축이 용이합니다.

LDP TCP 연결을 session-groupauthentication-key 위한 MD5 시그니처를 구성하려면

명령문을 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 authentication-key-chains] 연결합니다. 또한 계층 수준 명령문을 포함 authentication-algorithm algorithm 함으로써 인증 알고리즘을 [edit protocols ldp] 구성해야 합니다.

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

LDP 세션 보호 구성

LDP 세션은 일반적으로 하나 이상의 링크에 의해 연결된 라우터 쌍 사이에 생성됩니다. 라우터는 모든 링크를 연결하고 모든 인접성을 해당 LDP 세션과 연결하는 모든 링크에 대해 Hello Adjacency를 형성합니다. LDP 세션의 마지막 Hello Adjacency가 사라지면 LDP 세션이 종료됩니다. LDP 세션이 불필요하게 종료되고 재구축되지 않도록 이 동작을 수정할 수 있습니다.

명령문을 구성하여 두 라우터를 연결하는 링크에 안녕하세요 인접한 부분이 없더라도 두 라우터 사이에 LDP 세션을 남겨 두도록 Junos OS를 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 링크상의 IGP와 LDP 동기화 구성

LDP는 트래픽이 엔지니어링되지 않는 애플리케이션에서 레이블을 배포하는 프로토콜입니다. 레이블은 IGP에 의해 결정되는 최상의 경로를 따라 배포됩니다. LDP와 IGP 간의 동기화가 유지되지 않으면 LSP가 다운됩니다. LDP가 지정된 링크에서 완벽하게 운영되지 않고(세션이 설정되지 않고 레이블이 교환되지 않는 경우) IGP는 최대 비용 측정 지표로 링크를 광고합니다. 링크는 기본 설정되지 않았지만 네트워크 토폴로지로 유지됩니다.

LDP 동기화는 IGP에서 점대점(point-to-point)으로 구성된 활성 P2P(Point-to-Point) 인터페이스 및 LAN 인터페이스에서만 지원됩니다. LDP 동기화는 Graceful Restart 동안 지원되지 않습니다.

LDP가 동기화를 위해 운영될 때까지 최대 비용 지표를 광고하려면 다음과 같은 명령문을 ldp-synchronization 포함합니다.

동기화를 비활성화하려면 명령문을 포함하십시오 disable . 완벽하게 운영되지 않는 링크에 대한 최대 비용 지표를 광고하기 위해 기간을 구성하려면 성명서를 hold-time 포함합니다.

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

라우터의 IGP와 LDP 동기화 구성

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

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

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

Label Withdrawal Timer 구성

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

타이머가 실행되기 전에 라우터가 새 Label을 수신하면 Label Withdrawal Timer가 취소됩니다. 그러나 타이머가 다 떨어지면 모든 업스트림 라우터에서 FEC의 레이블이 철회됩니다.

기본적으로 LDP는 레이블을 철회하기 전에 60초 동안 기다렸다가 IGP가 리컨버전싱하는 동안 LSP가 여러 번 사임하지 않도록 합니다. 몇 초 만에 레이블 철수 지연 시간을 구성하려면 다음과 같은 진술을 포함하십시오 label-withdrawal-delay .

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

LDP 서브넷 검사 무시

Junos OS Release 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(Multi-Protocol Label Switched) 데이터 플레인 장애 감지를 기반으로 합니다. 이 기능을 사용하면 FEC의 모든 경로를 주기적으로 추적할 수 있습니다. FEC 토폴로지 정보는 CLI에서 액세스할 수 있는 데이터베이스에 저장됩니다.

토폴로지 변경으로 인해 자동으로 LDP LSP의 추적이 트리거되지 않습니다. 하지만 트레이스라우트를 수동으로 시작할 수 있습니다. traceroute 요청이 현재 데이터베이스에 있는 FEC인 경우 데이터베이스 내용이 결과로 업데이트됩니다.

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

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

자체 또는 다음과 같은 옵션으로 명령문을 구성할 periodic-traceroute 수 있습니다.

  • exp—프로브를 보낼 때 사용할 서비스 클래스를 지정합니다.

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

  • frequency—경로 추적 시도 사이의 간격을 지정합니다.

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

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

  • source—프로브를 보낼 때 사용할 IPv4 소스 주소를 지정합니다.

  • ttl—최대 라이브 시간 값을 지정합니다. 이 값을 넘어서는 노드는 추적되지 않습니다.

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

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에서 통과한 데이터 바이트 수입니다.

  • Shared—값은 Yes 여러 접두사들이 동일한 Label(예: 여러 접두사에 송신 정책을 통해 광고되는 경우)에 바인딩됨을 나타냅니다. 이 케이스의 LDP 트래픽 통계는 모든 접두사에 적용되며 이와 같이 처리되어야 합니다.

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

Penultimate-Hop Router에서 LDP 통계 비활성화

Penultimate-hop 라우터에서 LDP 트래픽 통계를 수집하면 특히 넥트 홉 경로에서 과도한 시스템 리소스를 소비할 수 있습니다. 명령문 이외에 이 명령문을 구성 deaggregate 한 경우 이 문제는 더욱 심각합니다 traffic-statistics . 넥티드 홉(next-hop) 경로 사용 한계에 도달한 라우터의 경우 다음과 같은 명령문에 no-penultimate-hoptraffic-statistics 대한 옵션을 구성하는 것이 좋습니다.

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

주:

옵션을 구성할 no-penultimate-hop 때 이 라우터의 Penultimate Hop인 FEC에 대한 통계는 제공되지 않습니다.

이 옵션을 구성에서 포함하거나 제거할 때마다 LDP 세션이 다운되고 다시 시작됩니다.

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

LDP 통계 제한

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

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

  • 지정된 간격을 단축하는 경우, 새로운 LDP 통계 요청은 통계 타이머가 새 간격보다 늦게 만료되는 경우에만 발행됩니다.

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

LSP가 다운되면 LDP 통계가 재설정됩니다.

LDP 프로토콜 트래픽 추적

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

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

LDP 프로토콜 트래픽을 추적하기 위해 계층 수준에서 글로벌 traceoptions 명령문 [edit routing-options] 의 옵션을 지정하고 다음과 같은 명령문을 포함하여 traceoptions LDP별 옵션을 지정할 수 있습니다.

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

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

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

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

  • binding—레이블 바인딩 작업을 추적합니다.

  • error—추적 오류 조건.

  • event—추적 프로토콜 이벤트.

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

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

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

  • packets—주소, 주소 철회, 초기화, 레이블 요청, 레이블 맵, 레이블 철수, 레이블 릴리스, 알림 및 주기적인 메시지의 작동을 추적합니다. 이 수정자는 , initialization, labelnotificationperiodic 수정자를 설정하는 address것과 같습니다.

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

  • path—레이블 스위칭 경로 작업을 추적합니다.

  • path—레이블 스위칭 경로 작업을 추적합니다.

  • periodic—인사말 및 유지 메시지의 작동을 추적합니다.

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

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

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

LDP는 생성한 각 LSP와 FEC(Forwarding Equivalence Class)를 연결합니다. LSP와 연관된 FEC는 해당 LSP에 매핑되는 패킷을 지정합니다. 각 라우터가 FEC에 대해 다음 홉에 의해 광고되는 레이블을 선택하고 다른 모든 라우터에 광고하는 레이블에 LSP를 접합함에 따라 LSP가 네트워크를 통해 확장됩니다.

특정 FEC 내에서 LDP 프로토콜 트래픽을 추적하고 FEC를 기반으로 LDP 추적 문을 필터링할 수 있습니다. 이 방법은 FEC와 연관된 LDP 프로토콜 트래픽을 추적하거나 문제를 해결하려는 경우에 유용합니다. 다음 추적 플래그는 이 목적을 위해 사용할 수 있습니다. route, path, .binding

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

이 기능은 다음과 같은 제한 사항을 가지고 있습니다.

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

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

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

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

  • 유일한 match-on 옵션은 fec. 따라서, 반드시 포함해야 하는 정책 유형은 루트 필터 정책뿐입니다.

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

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

모든 LDP 발신 메시지 추적:

모든 LDP 오류 조건 추적:

모든 LDP 수신 메시지 및 모든 레이블 바인딩 작업을 추적:

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

출시 내역 표
릴리스
설명
19.1
Junos OS 릴리스 19.1R1부터 세그먼트 라우팅-LDP 경계 라우터는 세그먼트 라우팅 트래픽을 LDP Next-Hop에 연결하고 그 반대의 경우도 마찬가지입니다.
16.1R1
Junos OS Release 16.1R1부터 LDP 세션을 위한 HMAC(Hashed Message Authentication Code) 및 MD5 인증에 대한 지원이 세션당 구성에서 서브넷 매치(즉, 가장 긴 접두사 일치) 구성으로 확장됩니다.
16.1
Junos OS Release 16.1부터 시작하여, M-LDP는 루트 주소가 BGP 경로인 경우 ASBR에서 점대다점 LSP에 신호를 전달하거나 MPLS LSP를 통해 추가적으로 해결되는 BGP 경로인 경우 전송 또는 송신을 할 수 있습니다.
14.1
Junos OS Release 14.1부터 시작해 기존 IPTV 서비스를 네이티브 IP 멀티캐스트에서 MPLS 멀티캐스트로 마이그레이션하려면 최소한의 가동 중단 없이 PIM에서 M-LDP P2P로 원활하게 전환해야 합니다.