Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

트래픽 엔지니어링을 위한 OSPF 지원 구성

트래픽 엔지니어링을 위한 OSPF 지원

트래픽 엔지니어링을 사용하면 라우팅 테이블을 사용하는 표준 라우팅 모델을 우회하여 데이터 패킷이 따르는 경로를 제어할 수 있습니다. 트래픽 엔지니어링은 혼잡한 링크에서 자동으로 계산된 목적지 기반 최단 경로에 의해 선택되지 않는 대체 링크로 플로우를 이동합니다.

트래픽 엔지니어링 및 MPLS 네트워크 토폴로지 및 로드에 대한 정보를 제공하기 위해 OSPF의 Junos OS 구현에 확장이 추가되었습니다. 라우팅 디바이스에서 트래픽 엔지니어링이 활성화되면 OSPF 트래픽 엔지니어링 지원을 활성화할 수 있습니다. 최단 경로 우선(SPF) 알고리즘은 최단 경로 우선(SPF) 알고리즘이 MPLS 따라 구성된 다양한 LSP(label-switched path)를 고려하고 트래픽 엔지니어링 매개 변수를 전달하는 불투명한 LSA(link-state advertisements)를 생성하도록 OSPF를 구성합니다. 매개 변수는 트래픽 엔지니어링 데이터베이스를 채우는 데 사용됩니다. TED(Traffic Engineering Database)는 물리적 토폴로지에서 LSP를 배치하기 위해 명시적 경로를 계산하는 용도로만 사용됩니다. CSPF(Constrained Shortest Path First) 알고리즘은 트래픽 엔지니어링 데이터베이스를 사용하여 LSP가 MPLS 경로를 계산합니다. RSVP는 이 경로 정보를 사용하여 LSP를 설정하고 이를 위해 대역폭을 예약합니다.

기본적으로 트래픽 엔지니어링 지원은 비활성화됩니다. 트래픽 엔지니어링을 활성화하려면 트래픽 엔지니어링 문을 포함합니다. 또한 다음 OSPF 트래픽 엔지니어링 확장을 구성할 수 있습니다.

  • advertise-unnumbered-interfaces—(OSPFv2만 해당) link-local 트래픽 엔지니어링 LSA 패킷에 link-local 식별자를 보급합니다. RSVP가 RFC 3477에 정의된 대로 번호가 지정되지 않은 인터페이스에 신호를 전송하여 리소스 예약 프로토콜 - 트래픽 엔지니어링(RSVP-TE)에서 번호가 지정되지 않은 링크를 신호할 수 있다면 이 문을 포함할 필요가 없습니다.

  • reliability-protocol-preference—(OSPFv2만 해당) 트래픽 엔지니어링 데이터베이스의 OSPF 경로에 신뢰성 값을 할당합니다. 기본적으로 Junos OS 다른 IGP의 경로가 더 낮은 값, 즉 선호되는 선호 값으로 구성되어 있더라도 다른 내부 게이트웨이 프로토콜(IGP) 경로보다 트래픽 엔지니어링 데이터베이스의 최단 경로 우선(OSPF) 경로를 선호합니다. TED(Traffic Engineering Database)는 각 IGP에 신뢰성 값을 할당하고 신뢰성 값이 가장 높은 IGP 경로를 선호합니다. Junos OS 릴리스 9.4 이상에서 프로토콜 기본 설정을 고려하여 TED(Traffic Engineering Database) 신뢰성 값을 결정하도록 OSPF를 구성할 수 있습니다. 프로토콜 선호를 사용하여 신뢰성 값을 결정할 때, OSPF 경로는 구성에 따라 TED(Traffic Engineering Database)에서 자동으로 선호되지 않습니다.

  • ignore-lsp-metrics - OSPF 트래픽 엔지니어링 바로 가기 계산에서 또는 RSVP LSP를 통해 LDP를 구성할 때 RSVP LSP 메트릭을 무시합니다. 이 옵션은 최단 경로 우선(OSPF)과 RSVP 간의 상호 의존성을 방지하여 트래픽 터널링에 사용되는 RSVP 메트릭이 최신 상태로 유지되지 않는 기간을 제거합니다. 또한 트래픽 엔지니어링에 RSVP를 사용하는 경우 LDP를 동시에 실행하여 코어의 외부 경로 배포를 제거할 수 있습니다. LDP에 의해 설정된 LSP는 RSVP에 의해 설정된 LSP를 통해 터널링됩니다. LDP는 트래픽 엔지니어링 LSP를 단일 홉으로 효과적으로 처리합니다.

  • multicast-rpf-routes—(OSPFv2만 해당) 멀티캐스트 RPF(Reverse Path Forwarding) 확인을 위해 멀티캐스트 라우팅 테이블(inet.2)에 유니캐스트 IPv4 경로(LSP가 아님)를 설치합니다. inet.2 라우팅 테이블 멀티캐스트 RPF 조회에 사용되는 유니캐스트 경로로 구성됩니다. RPF는 패킷 소스로 데이터를 다시 전송하는 인터페이스에서 패킷이 유입되는지 확인하는 데 사용되는 스푸핑 방지 메커니즘입니다.

  • no-topology—(OSPFv2만 해당) link-state 토폴로지 정보의 보급을 비활성화하려면. 비활성화된 경우 트래픽 엔지니어링 토폴로지 정보는 더 이상 최단 경로 우선(OSPF) 영역 내에 배포되지 않습니다.

  • 바로 가기 — OSPF가 수신 라우팅 디바이스에서 송신 라우팅 디바이스로의 논리적 인터페이스 인 것처럼 다음 홉으로 LSP를 사용할 수 있도록 IGP 바로 가기를 구성합니다. 수신 라우팅 디바이스의 [edit protocols mpls label-switched-path lsp-path-name] 계층 수준에서 to 문에 지정된 주소는 LSP가 송신 라우팅 디바이스에 대한 직접 링크로 작동하고 OSPF SPF 계산에 대한 입력으로 사용되기 위해서는 송신 라우팅 디바이스의 라우터 ID와 일치해야 합니다. 이러한 방식으로 사용될 때, LSP는 LSPS가 IPv4 트래픽만 전송한다는 것을 제외하고는 비동기 전송 모드(ATM) 및 프레임 릴레이 가상 서킷(VC)과 다르지 않습니다.

    OSPFv2는 inet.0 라우팅 테이블 IPv4 경로에 대한 접두사 를 설치하고 LSP는 inet.3 라우팅 테이블 기본적으로 설치됩니다.

    바로 가기에 사용되는 OSPFv3 LSP는 IPv4를 사용하여 신호가 계속 전송됩니다. 그러나 기본적으로 OSPFv3을 통해 계산된 바로 가기 IPv6 경로는 inet6.3 라우팅 테이블 추가됩니다. 기본 동작은 BGP가 계산에서 LSP만 사용하는 것입니다. BGP와 IGP 모두 트래픽 포워딩에 LSP를 사용하도록 MPLS 구성하는 경우 OSPFv3를 통해 계산된 IPv6 바로 가기 경로가 inet6.0 라우팅 테이블 추가됩니다.

    참고:

    가능할 때마다 트래픽 엔지니어링 단축키 대신 최단 경로 우선(OSPF) IGP 단축키를 사용합니다.

  • lsp-metric-info-summary - LSP를 링크로 취급하기 위해 요약 LSA에 LSP 메트릭을 보급합니다. 이 구성을 통해 네트워크의 다른 라우팅 디바이스가 이 LSP를 사용할 수 있습니다. 이를 위해서는 요약 LSA의 LSP 메트릭을 광고하도록 MPLS 및 최단 경로 우선(OSPF) 트래픽 엔지니어링을 구성해야 합니다.

라우팅 디바이스에서 트래픽 엔지니어링을 활성화하면 트래픽 엔지니어링 전용으로 사용되는 OSPF 메트릭을 구성할 수도 있습니다. 트래픽 엔지니어링 메트릭은 TED(Traffic Engineering Database)에 삽입된 정보에 사용됩니다. 해당 값은 일반 OSPF 포워딩에 영향을 미치지 않습니다.

예: OSPF 트래픽 엔지니어링 지원 활성화

이 예는 OSPF 트래픽 엔지니어링 지원을 활성화하여 요약 LSA(link-state advertisements)에서 레이블 스위칭 경로(LSP) 메트릭을 광고하는 방법을 보여줍니다.

요구 사항

시작하기 전에 다음을 수행합니다.

개요

LSP를 링크로 취급하고 네트워크의 다른 라우팅 디바이스가 이 LSP를 사용하도록 OSPF를 구성할 수 있습니다. 이를 위해 MPLS 및 최단 경로 우선(OSPF) 트래픽 엔지니어링을 구성하여 요약 LSA에서 LSP 메트릭을 보급합니다.

이 예에서는 영역 0.0.0.0에 4개의 라우팅 디바이스가 있으며, OSPF는 수신 디바이스 R1에서 송신 디바이스 R4로 가는 R1-to-R4라는 LSP를 링크로 취급하기를 원합니다.

OSPF의 경우 문을 포함하여 해당 영역의 네 개의 라우팅 디바이스에서 트래픽 엔지니어링을 활성화합니다 traffic-engineering . 이 구성은 최단 경로 우선(SPF) 알고리즘이 MPLS 따라 구성된 LSP를 고려하고 트래픽 엔지니어링 매개 변수를 전달하는 LSA를 생성하도록 OSPF를 구성합니다. 또한 OSPF가 MPLS LSP를 다음 홉으로 사용하고 수신 디바이스 R1에 선택적 shortcuts lsp-metric-into-summary 문을 포함하여 요약 LSA에서 LSP 메트릭을 보급하도록 보장합니다.

MPLS 경우, MPLS 문을 포함하여 traffic-engineering bgp-igp BGP 및 IGP 목적지 모두에서 트래픽 엔지니어링을 수행하도록 트래픽 엔지니어링을 활성화하고 수신 디바이스 R1에 문을 포함하여 label-switched-path lsp-path-name to address R1-to-R4라는 LSP를 포함합니다. 수신 디바이스 R1의 문에 지정된 to 주소는 LSP가 송신 라우팅 디바이스에 대한 직접 링크로 작동하고 OSPF SPF 계산에 대한 입력으로 사용하려면 송신 디바이스 R4의 라우터 ID와 일치해야 합니다. 이 예에서 송신 디바이스 R4의 라우터 ID는 10.0.0.4입니다.

구성

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

절차

CLI 빠른 구성

OSPF 트래픽 엔지니어링 지원을 빠르게 활성화하여 요약 LSA의 LSP 메트릭을 광고하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

R1 구성:

R2 구성:

R3 구성:

R4 구성:

단계별 절차

OSPF 트래픽 엔지니어링 지원을 활성화하여 요약 LSA의 LSP 메트릭을 광고하려면:

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

  2. OSPF 영역을 구성하고 인터페이스를 추가합니다.

    참고:

    OSPFv3를 지정하려면 계층 수준에서 문을 [edit protocols] 포함합니다ospf3.

  3. OSPF 트래픽 엔지니어링을 활성화합니다.

  4. 디바이스 R1에서 트래픽 엔지니어링 MPLS 구성합니다.

  5. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

, 및 show protocols ospfshow protocols mpls 명령을 입력하여 구성을 show routing-options확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

R1의 출력:

R2의 출력:

R3의 출력:

R4의 출력:

OSPFv3 구성을 확인하려면, show protocols ospf3show protocols mpls 명령을 입력show routing-options합니다.

확인

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

OSPF에 대한 트래픽 엔지니어링 기능 확인

목적

트래픽 엔지니어링이 OSPF에 대해 활성화되었는지 확인합니다. 기본적으로 트래픽 엔지니어링은 비활성화됩니다.

작업

운영 모드에서 OSPFv2에 대한 명령을 입력 show ospf overview 하고 OSPFv3에 대해 을 show ospf3 overview (를) 입력합니다.

TED(Traffic Engineering Database)에서 OSPF 항목 확인

목적

TED(Traffic Engineering Database)에서 OSPF 정보를 확인합니다. 프로토콜 필드는 OSPF 및 정보가 학습된 영역을 표시합니다.

작업

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

트래픽 엔지니어링 데이터베이스가 OSPF에서 노드 정보를 학습하고 있는지 확인

목적

OSPF가 노드 정보를 보고하고 있는지 확인합니다. 프로토콜 이름 필드에는 OSPF와 정보가 학습된 영역이 표시됩니다.

작업

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

예: 특정 OSPF 인터페이스에 대한 트래픽 엔지니어링 메트릭 구성

이 예는 트래픽 엔지니어링에 사용되는 OSPF 메트릭 값을 구성하는 방법을 보여줍니다.

요구 사항

시작하기 전에 다음을 수행합니다.

개요

트래픽 엔지니어링에만 사용되는 OSPF 메트릭을 구성할 수 있습니다. 트래픽 엔지니어링 메트릭의 기본 값을 수정하려면 문을 포함합니다 te-metric . OSPF 트래픽 엔지니어링 메트릭은 일반적인 OSPF 포워딩에 영향을 미치지 않습니다. 기본적으로 트래픽 엔지니어링 메트릭은 OSPF 메트릭과 동일한 값입니다. 범위는 1~65,535입니다.

이 예에서는 영역 0.0.0.0에서 OSPF 인터페이스 fe-0/1/1 에서 OSPF 트래픽 엔지니어링 메트릭을 구성합니다.

구성

CLI 빠른 구성

특정 인터페이스에 대한 OSPF 트래픽 엔지니어링 메트릭을 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브러브를 제거하고, 네트워크 구성과 일치하기 위해 필요한 세부 사항을 변경하고, 명령을 복사하여 [edit] 계층 수준에서 CLI로 붙여 넣은 다음, 구성 모드에서 을(를) 입력합니다 commit .

절차

단계별 절차

트래픽 엔지니어링에만 사용되는 특정 인터페이스에 대해 OSPF 트래픽 엔지니어링 메트릭을 구성하려면 다음을 수행합니다.

  1. OSPF 영역을 생성합니다.

    참고:

    OSPFv3를 지정하려면 계층 수준에서 문을 [edit protocols] 포함합니다ospf3.

  2. OSPF 네트워크 세그먼트의 트래픽 엔지니어링 메트릭을 구성합니다.

  3. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

명령을 입력하여 구성을 확인합니다 show protocols ospf . 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

OSPFv3 구성을 확인하려면 명령을 입력합니다 show protocols ospf3 .

확인

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

구성된 트래픽 엔지니어링 메트릭 확인

목적

트래픽 엔지니어링 메트릭 값을 확인합니다. 메트릭 필드에 구성된 트래픽 엔지니어링 메트릭이 표시되는지 확인합니다.

작업

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

OSPF 패시브 트래픽 엔지니어링 모드

일반적으로 OSPF와 같은 내부 라우팅 프로토콜은 자율 시스템 간의 링크에서 실행되지 않습니다. 그러나 AS 간 트래픽 엔지니어링이 제대로 작동하려면 AS 간 링크( 특히 원격 인터페이스의 주소)에 대한 정보를 AS(Autonomous System) 내에서 사용할 수 있어야 합니다. 이 정보는 일반적으로 외부 BGP(EBGP) 도달 가능성 메시지 또는 OSPF 라우팅 광고에 포함되지 않습니다.

AS 내에서 이 링크 주소 정보를 플러드하고 트래픽 엔지니어링 계산에 사용할 수 있도록 하려면 각 AS 간 인터페이스에서 트래픽 엔지니어링을 위한 OSPF 패시브 모드를 구성해야 합니다. 또한 OSPF가 배포하고 TED(Traffic Engineering Database)에 포함할 수 있도록 원격 주소를 제공해야 합니다. 최단 경로 우선(OSPF) 트래픽 엔지니어링 모드를 사용하면 MPLS 레이블 스위칭 경로(LSP)가 최단 경로 우선(OSPF) AS 경계 라우터를 동적으로 발견하고 라우터가 여러 자율 시스템 전반에 걸쳐 트래픽 엔지니어링 LSP를 설정할 수 있습니다.

예: OSPF 패시브 트래픽 엔지니어링 모드 구성

이 예는 AS 간 인터페이스에서 트래픽 엔지니어링을 위해 OSPF 패시브 모드를 구성하는 방법을 보여줍니다. EBGP 피어 간의 AS 경계 라우터 링크는 직접 연결된 링크여야 하며 패시브 트래픽 엔지니어링 링크로 구성되어야 합니다.

요구 사항

시작하기 전에 다음을 수행합니다.

개요

AS 간 인터페이스에서 트래픽 엔지니어링을 위한 OSPF 패시브 모드를 구성할 수 있습니다. 최단 경로 우선(OSPF) 패시브 트래픽 엔지니어링 링크의 원격 노드에 사용되는 주소는 EBGP 링크에 사용되는 주소와 동일해야 합니다. 이 예에서 AS 내에서 OSPF를 사용하여 트래픽 엔지니어링 정보를 배포하고 다음 설정을 포함하도록 AS 간 링크로 영역 0.0.0.1에서 인터페이스 so-1/1/ 0을 구성합니다.

  • passive - 해당 인터페이스에서 실제로 OSPF를 실행하지 않고 인터페이스에 직접 인터페이스 주소를 보급합니다. 패시브 인터페이스는 주소 정보가 OSPF에서 내부 경로로 보급되지만 프로토콜이 실행되지 않는 인터페이스입니다.

  • traffic-engineering — OSPF 패시브 트래픽 엔지니어링 모드에서 인터페이스를 구성하여 OSPF AS 경계 라우터의 동적 검색을 지원합니다. 기본적으로 OSPF 패시브 트래픽 엔지니어링 모드는 비활성화됩니다.

  • remote-node-id - AS 간 링크의 맨 끝에 있는 IP 주소를 지정합니다. 이 예에서 원격 IP 주소는 192.168.207.2입니다.

구성

트래픽 엔지니어링을 위한 OSPF 패시브 모드를 빠르게 구성하려면 다음 명령을 복사하여 모든 라인브래브를 제거하고 CLI에 붙여 넣습니다.

절차

단계별 절차

OSPF 패시브 트래픽 엔지니어링 모드 구성 방법:

  1. OSPF 영역을 생성합니다.

    참고:

    OSPFv3를 지정하려면 계층 수준에서 문을 [edit protocols] 포함합니다ospf3.

  2. 트래픽 엔지니어링을 위해 구성된 패시브 인터페이스로 인터페이스 so-1/1/0 을 구성하고 AS 간 링크의 맨 끝에 있는 IP 주소를 지정합니다.

  3. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

명령을 입력하여 구성을 확인합니다 show protocols ospf . 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

OSPFv3 구성을 확인하려면 명령을 입력합니다 show protocols ospf3 .

확인

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

OSPF 인터페이스의 상태 확인

목적

OSPF 인터페이스의 상태를 확인합니다. 인터페이스가 수동적인 경우, 인접 항목이 형성되지 않아 Adj 카운트 필드는 0입니다. 이 필드 옆에 패시브(Passive)라는 단어도 있습니다.

작업

운영 모드에서 OSPFv2에 대한 명령을 입력 show ospf interface detail 하고 OSPFv3에 대한 명령을 입력 show ospf3 interface detail 합니다.

OSPFv2에 레이블 스위칭 경로 보급

네트워크에서 레이블 스위칭 경로(LSP)를 구성하는 주된 이유 중 하나는 네트워크의 두 지점 사이의 최단 경로를 제어하기 위해서입니다. SPF 계산을 수행할 때 모든 참여 라우팅 디바이스가 LSP를 고려할 수 있도록 LSP를 포인트 투 포인트 링크로 OSPFv2에 보급할 수 있습니다. 광고에는 로컬 주소(LSP의 주소 에서 ), 원격 주소(LSP의 주소) 와 다음 우선 순위가 있는 메트릭이 포함됩니다.

  1. OSPFv2에 정의된 LSP 메트릭을 사용합니다.

  2. MPLS 아래에서 레이블 스위칭 경로에 구성된 LSP 메트릭을 사용합니다.

  3. 위의 메트릭을 구성하지 않으면 기본 OSPFv2 메트릭 1을 사용합니다.

참고:

OSPFv2에 공지된 LSP를 SPF 계산에 사용하려면 역방향 링크(즉, LSP의 테일 엔드에서 헤드 엔드까지 링크)가 있어야 합니다. 역방향으로 LSP를 구성하고 OSPFv2에서도 이를 공지하여 이 작업을 수행할 수 있습니다.

예: OSPFv2에 레이블 스위칭 경로 보급

이 예는 LSP를 OSPFv2에 보급하는 방법을 보여줍니다.

요구 사항

시작하기 전에 디바이스 인터페이스를 구성합니다. 라우팅 디바이스를 위한 Junos OS 네트워크 인터페이스 라이브러리를 참조하십시오.

개요

LSP를 OSPFv2로 보급하려면 LSP를 정의하고 LSP를 사용하여 트래픽을 라우팅하도록 OSPFv2를 구성합니다. 이를 통해 LSP를 사용하여 네트워크의 두 지점 사이의 최단 경로를 제어할 수 있습니다. 최단 경로 우선(OSPF)이 기본 Best-effort 라우팅을 사용하는 대신 LSP를 따라 최단 경로 우선(OSPF) 트래픽을 라우팅하려면 이 작업을 선택할 수 있습니다.

이 예에서는 OSPFv2에 LSP를 보급하도록 다음을 구성합니다.

  • Bgp

    모든 라우팅 디바이스의 경우, 로컬 AS 번호 65000을 구성하고 지정된 BGP 시스템을 피어로 인식하는 IBGP 그룹을 정의합니다. 모든 멤버는 로컬 AS 내부이므로 피어 전체 목록으로 내부 그룹을 구성합니다. 구성한 로컬 AS 번호와 동일한 피어 AS 그룹도 포함됩니다.

  • MPLS

    모든 라우팅 디바이스의 경우, 각 전송 논리적 인터페이스에서 프로토콜 체계를 구성하고 관리 인터페이스(fxp0.0)를 제외한 모든 인터페이스에서 MPLS 활성화합니다. mpls 프로토콜 체계 유형을 지정합니다.

  • Rsvp

    모든 라우팅 디바이스의 경우 관리 인터페이스(fxp0.0)를 제외한 모든 인터페이스에서 RSVP를 활성화합니다. 이 네트워크의 디바이스에서 RSVP를 활성화하여 인터페이스가 LSP에 신호를 전송할 수 있도록 합니다.

  • OSPFv2

    모든 라우팅 디바이스의 경우, 루프백 주소를 사용하여 라우터 ID를 할당하고, 모든 디바이스를 OSPF 영역 0.0.0.0으로 관리적으로 그룹화하고, OSPF에 참여하는 모든 인터페이스를 영역 0.0.0.0에 추가하고, 관리 인터페이스(fxp0.0.0)에서 최단 경로 우선(OSPF)을 비활성화합니다.

  • 레이블 스위칭 경로

    LSP의 시작(또는 헤드엔드)인 수신 라우팅 디바이스 R1에서 명시적 경로 LSP를 구성합니다. 명시적 경로 LSP가 다른 노드를 통과하지 않고 경로에 있는 다음 지정된 IP 주소로 이동해야 함을 나타냅니다. 이 예에서 R1-to-R6이라는 이름의 LSP를 생성하고 송신 라우팅 디바이스 R6의 IP 주소를 지정합니다.

  • OSPFv2에서 LSP 보급

    수신 라우팅 디바이스 R1에서 LSP를 OSPFv2에 포인트 투 포인트 링크로 보급합니다. 선택적으로 LSP가 목적지에 대한 다소 선호되는 경로가 도록 메트릭을 할당할 수 있습니다.

토폴로지

그림 1 에는 다음으로 구성된 샘플 네트워크 토폴로지가 표시됩니다.

  • BGP는 세 개의 라우팅 디바이스를 포함하는 하나의 로컬 AS(Autonomous System) 65000으로 모든 라우팅 디바이스에 구성됩니다.

    • R1 - 디바이스 R1은 라우터 ID가 10.0.0.1인 수신 디바이스입니다. - 인터페이스 so-0/0/2 는 디바이스 R3에 연결됩니다.

    • R3 - 디바이스 R3은 라우터 ID가 10.0.0.3인 전송 디바이스입니다. so-0/0/2 인터페이스는 디바이스 R1에 연결되고 인터페이스 so-0/0/3 은 디바이스 R6에 연결됩니다.

    • R6- 디바이스 R6은 라우터 ID가 10.0.0.6인 송신 디바이스입니다. - 인터페이스 so-0/0/3 은 디바이스 R3에 연결됩니다.

  • OSPFv2는 모든 라우팅 디바이스에서 구성됩니다.

  • MPLS 및 RSVP는 모든 라우팅 디바이스에서 활성화됩니다.

  • 디바이스 R1에서 하나의 RSVP 신호 LSP가 구성됩니다.

그림 1: LSP를 OSPFv2 Advertising an LSP into OSPFv2 에 보급

구성

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

LSP를 OSPFv2로 보급하는 디바이스를 구성하려면 다음 작업을 수행합니다.

BGP 구성

CLI 빠른 구성

각 라우팅 디바이스에서 BGP를 빠르게 구성하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

단계별 절차

BGP 구성 방법:

  1. 각 라우팅 디바이스에서 로컬 AS 번호를 구성합니다.

  2. 각 라우팅 디바이스에서 내부 BGP neighbor 연결을 구성합니다.

  3. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

show protocols bgp 명령을 입력하여 구성을 show routing-options 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

R1 구성:

R3 구성:

R6 구성:

MPLS 구성

CLI 빠른 구성

AS 65000의 모든 라우팅 디바이스에서 MPLS 빠르게 구성하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

단계별 절차

MPLS 구성:

  1. MPLS 위한 전송 인터페이스를 구성합니다.

  2. MPLS 활성화합니다.

  3. 관리 인터페이스(fxp0.0)에서 MPLS 비활성화합니다.

  4. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

show protocols mpls 명령을 입력하여 구성을 show interfaces 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

RSVP 구성

CLI 빠른 구성

AS 65000의 모든 라우팅 디바이스에서 RSVP를 빠르게 구성하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

단계별 절차

RSVP 구성:

  1. RSVP를 활성화합니다.

  2. 관리 인터페이스(fxp0.0)에서 RSVP를 비활성화합니다.

  3. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

명령을 입력하여 구성을 확인합니다 show protocols rsvp . 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

OSPF 구성

CLI 빠른 구성

OSPF를 빠르게 구성하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

단계별 절차

OSPF 구성:

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

  2. OSPF 영역과 인터페이스를 구성합니다.

  3. 관리 인터페이스(fxp0.0)에서 최단 경로 변환(OSPF)을 비활성화합니다.

  4. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

및 명령을 입력하여 구성을 show routing-options show protocols ospf 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

LSP 구성

CLI 빠른 구성

수신 라우팅 디바이스 라우터 R1에서 LSP를 빠르게 구성하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

단계별 절차

디바이스 R1에서 LSP를 구성하려면:

  1. MPLS 구성 모드를 입력합니다.

  2. LSP를 생성합니다.

  3. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

명령을 입력하여 구성을 확인합니다 show protocols mpls . 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

OSPFv2로 LSP 보급

CLI 빠른 구성

LSP를 OSPFv2에 신속하게 보급하고 디바이스 R1에서 LSP에 대한 메트릭을 선택적으로 포함하려면 다음 명령을 복사하여 CLI에 붙여 넣습니다.

단계별 절차

라우터 R1에서 OSPFv2로 LSP를 보급하려면,

  1. OSPF 구성 모드를 입력합니다.

  2. label-switched-path 문을 포함하고 생성한 LSP R1-to-R6을 지정합니다.

  3. (선택 사항) LSP에 대한 메트릭을 지정합니다.

  4. 디바이스 구성이 완료되면 구성을 커밋합니다.

결과

명령을 입력하여 구성을 확인합니다 show protocols ospf . 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

확인

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

OSPF 이웃 확인

목적

다른 이웃이 나열되어 있고 LSP를 통해 도달할 수 있는지 확인합니다. 인터페이스 필드는 LSP의 이름을 나타냅니다.

작업

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

OSPF를 위한 정적 인접 세그먼트 식별자

Adjacency Segment는 링크 비용에 관계없이 두 노드 사이의 특정 링크를 통해 패킷을 전달하는 엄격한 전달 단일 홉 터널입니다. 인터페이스에 대한 정적 인접 세그먼트 식별자(SID) 레이블을 구성할 수 있습니다.

인터페이스에 정적 인접 SID를 구성하면 기존 동적으로 할당된 인접 SID가 동일한 전송 경로와 함께 제거됩니다.

정적 인접 SID의 경우, 레이블은 정적 예약 레이블 풀 또는 OSPF 세그먼트 라우팅 글로벌 블록(SRGB)에서 선택됩니다.

다음 구성을 사용하여 레이블의 정적 할당에 사용할 레이블 범위를 예약할 수 있습니다.

user@host# set protocols mpls label-range static-label-range start-value end-value

정적 풀은 모든 프로토콜에서 이 범위에서 레이블을 할당하는 데 사용할 수 있습니다. 두 프로토콜이 동일한 정적 레이블을 사용하지 않도록 해야 합니다. OSPF 인접 SID는 키워드 label를 사용하여 구성을 통해 이 레이블 블록에서 할당될 수 있습니다. label 특정 인접 SID에 대한 값을 명시적으로 구성해야 합니다. 다음은 샘플 구성입니다.

참고:

명령을 사용할 ipv4-adjacency-segment 때 기본 인터페이스는 포인트 투 포인트여야 합니다.

SRGB는 구성에 따라 프로토콜에 할당되는 글로벌 레이블 공간입니다. 전체 SRGB의 레이블은 OSPF에서 사용할 수 있으며 다른 애플리케이션/프로토콜에 할당되지 않습니다. 접두사 SID(및 노드 SID)는 이 SRGB에서 인덱싱됩니다.

OSPF Adj-SIDs는 구성에서 키워드 '인덱스'를 사용하여 OSPF SRGB에서 할당할 수 있습니다. 이러한 경우 Adj-SID 인덱스가 도메인의 다른 접두사 SID와 충돌하지 않도록 해야 합니다. 접두사-SID와 마찬가지로, SRGB와 관련하여 인덱스를 언급함으로써 Adj-SIDs도 구성됩니다. 그러나 Adj-SID 하위 선반은 여전히 SID를 값으로 갖게 되며 L 및 V 플래그가 설정됩니다. 다음은 샘플 구성입니다.

정적 인접 SID는 영역별로 구성할 수 있으며 보호가 필요한지 여부에 따라 구성할 수도 있습니다. 인접 SID는 [edit protocols ospf area area interface interface-name] 계층 수준에서 인터페이스별로 구성되어야 합니다.

  • 보호 — 인접 SID가 백업 경로를 가질 자격이 있는지 확인하고 B-flag가 Adjacency SID 광고에서 설정되었는지 확인합니다.

  • 보호되지 않음 - 특정 인접 SID에 대한 백업 경로가 계산되지 않고 B-flag가 인접 SID 광고에서 설정되지 않았는지 확인합니다.

다음은 샘플 구성입니다.

LAN 서브네트워크에서 세그먼트 라우팅을 사용할 때 LAN의 각 라우터는 각 이웃의 인접 SID를 보급할 수 있습니다. 특정 이웃에 LAN 인터페이스에 대한 인접 SID를 구성하려면 [edit protocols ospf area 0.0.0.0 interface interface_name lan-neighbor neighbor-routerid] 계층 수준에서 lan-neighbor 구성 아래에서 인접 SID를 구성해야 합니다. 다음은 샘플 구성입니다.

인접 SID를 구성하기 위해 다음 CLI 계층을 사용합니다.

구성을 확인하기 위해 다음 운영 CLI 명령을 사용합니다.

show ospf neighbor 세부 정보

다음 샘플 출력은 구성된 동적 Adjacency SID의 세부 정보를 표시합니다.

SPRING(Source Packet Routing in Networking) 이해하기

소스 패킷 라우팅 또는 세그먼트 라우팅은 수신 라우터가 네트워크의 중간 노드에 의존하지 않고 네트워크의 특정 노드 및 링크 집합을 통해 패킷을 스티어링하여 실제 경로를 결정할 수 있도록 하는 컨트롤 플레인 아키텍처입니다. 이러한 맥락에서 '소스'라는 용어는 '명시적 경로가 부과되는 지점'을 의미합니다. Junos OS 릴리스 17.2R1부터는 QFX5100 및 QFX10000 스위치에서 IS-IS 및 OSPFv2에 대한 세그먼트 라우팅이 지원됩니다.

Junos OS 릴리스 20.3R1부터 OSPF 및 IS-IS 프로토콜에 대한 세그먼트 라우팅 지원은 SPRING(Source Packet Routing in Networking)에서 기본 기능을 제공합니다.

기본적으로 세그먼트 라우팅은 IS-IS 및 OSPF와 같은 IGP를 사용하여 두 가지 유형의 네트워크 세그먼트 또는 터널을 보급합니다.

  • 첫째, Adjacency Segment라고 하는 링크 비용에 관계없이 두 노드 사이의 특정 링크를 통해 패킷을 전달하는 엄격한 전달된 단일 홉 터널입니다.

  • 둘째, 노드 세그먼트라고 하는 두 개의 특정 노드 간의 최단 경로 링크를 사용하는 다중 홉 터널입니다.

수신 라우터는 적절한 터널 조합으로 패킷을 사전에 추가하여 원하는 노드 및 링크 집합을 통해 패킷을 스티어링할 수 있습니다.

세그먼트 라우팅은 소스 라우팅 패러다임을 활용합니다. 노드는 세그먼트라고 하는 주문된 지침 목록을 통해 패킷을 조정합니다. 세그먼트는 토폴로지 또는 서비스 기반의 모든 지침을 나타낼 수 있습니다. 세그먼트는 세그먼트 라우팅 노드 또는 세그먼트 라우팅 도메인 내의 글로벌 노드에 대한 로컬 의미 체계를 가질 수 있습니다. 세그먼트 라우팅은 모든 토폴로지 경로 및 서비스 체인을 통해 플로우를 적용하는 동시에 세그먼트 라우팅 도메인의 수신 노드에서만 플로우별 상태를 유지합니다. 세그먼트 라우팅은 포워딩 플레인에서 변경 없이 MPLS 아키텍처에 직접 적용할 수 있습니다. 세그먼트는 MPLS 레이블로 인코딩됩니다. 세그먼트의 정렬된 목록은 레이블 스택으로 인코딩됩니다. 처리할 세그먼트가 스택 맨 위에 있습니다. 세그먼트가 완료되면 스택에서 관련 레이블이 나타납니다. 새로운 유형의 라우팅 확장 헤더를 사용하여 세그먼트 라우팅을 IPv6 아키텍처에 적용할 수 있습니다. 세그먼트는 IPv6 주소로 인코딩됩니다. 세그먼트의 정렬된 목록은 라우팅 확장 헤더에서 IPv6 주소의 정렬된 목록으로 인코딩됩니다. 처리할 세그먼트는 라우팅 확장 헤더의 포인터로 표시됩니다. 세그먼트가 완료되면 포인터가 증가합니다.

다음 계층 수준에서 구성할 shortcuts 때 레이블이 지정된 IS-IS 세그먼트 경로에 대해 트래픽 엔지니어링 단축키가 활성화됩니다.

  • [edit protocols is-is traffic-engineering family inet] IPv4 트래픽에 대한 것입니다.

  • [edit protocols is-is traffic-engineering family inet6] IPv6 트래픽에 대한 것입니다.

네트워크, 데이터센터, 백본 및 피어링 디바이스에 소스 패킷 라우팅이 구축되면 트래픽 소스에 의해 생성된 레이블 스택으로 패킷을 MPLS 전환합니다. 예를 들어 데이터센터 서버를 예로 들어 보겠습니다. Junos OS 릴리스 17.4R1에서 소스 라우팅 트래픽은 RSVP 신호 경로를 가져오는 트래픽과 공존하며, 소스 라우팅은 레이블 작업을 사용하여 mpls.0 테이블을 통해 정규 레이블 스위칭으로 구현됩니다. 팝, 스왑(동일한 레이블 값으로) 및 스왑 푸시(인터페이스 보호를 위해). 모든 경우에서 트래픽은 여러 레이어 3 인터페이스 간에 또는 집계 인터페이스 내에서 로드 밸런서(load balance)가 될 수 있습니다. 릴리스 17.4R1 Junos OS 세그먼트 라우팅 네트워크의 트래픽 통계를 레이어 3 인터페이스에 대한 OpenConfig 호환 형식으로 기록할 수 있습니다. 통계는 RSVP 및 LDP 신호 트래픽을 제외한 SPRING(Source Packet Routing in Networking) 트래픽에 대해서만 기록되며 인터페이스당 제품군 MPLS 통계는 별도로 설명됩니다. SR 통계에는 링크 어그리게이션 그룹(LAG) 멤버 및 세그먼트 식별자(SID)당 SPRING 트래픽 통계도 포함됩니다. 세그먼트 라우팅 통계 기록을 활성화하려면 계층 수준에서 문을 [edit protocol isis source-packet-routing] 포함합니다sensor-based-stats.

릴리스 19.1R1 Junos OS 이전에는 MPLS 전송 트래픽에 대한 세그먼트 라우팅 통계를 수집할 수 있는 센서가 제공되었으며, 이는 본질적으로 MPLS MPLS. Junos OS 릴리스 19.1R1부터 MPC 및 MIC 인터페이스와 PTX 시리즈 라우터가 있는 MX 시리즈 라우터에서 추가 센서가 도입되어 본질적으로 IP-to-MPLS 인 MPLS 수신 트래픽에 대한 세그먼트 라우팅 통계를 수집합니다. 이 기능을 사용하면 레이블 IS-IS 세그먼트 라우팅 트래픽에 대한 센서만 활성화하고 통계를 gRPC 클라이언트로 스트리밍할 수 있습니다.

구성 문 아래에서 옵션을 사용하여 수신 트래픽 MPLS 세그먼트 라우팅 통계를 egress 활성화할 per-sid 수 있습니다. sid당 송신 기능의 리소스 이름은 다음과 입니다.

/junos/services/segment-routing/sid/egress/usage/

명령 출력을 사용하여 show isis spring sensor info 센서와의 레이블 IS-IS 경로 연결을 볼 수 있습니다. 이 명령은 실제 센서의 카운터 값을 표시하지 않습니다.

세그먼트 라우팅 통계 기록은 서버로 내보냅니다. 다음 OpenConfig 경로에서 세그먼트 라우팅 통계 데이터를 볼 수 있습니다.

  • /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-addr='L-ISIS-10.1.1.1']/state/counters[name='oc-xxx']/out-pkts

  • /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-addr='L-ISIS-10.1.1.1']/state/counters[name='oc-xxx']/out-pkts

참고:
  • GRES(Graceful 라우팅 엔진 Switchover)는 세그먼트 라우팅 통계에 지원되지 않습니다.

    NSR(Nonstop Active Routing)은 레이블 IS-IS에 대해 지원되지 않습니다. 라우팅 엔진 전환 중에 새로운 기본 라우팅 엔진 새로운 센서가 생성되어 이전 기본 라우팅 엔진 의해 생성된 센서를 대체합니다. 그 결과, 라우팅 엔진 전환 시 세그먼트 라우팅 통계 카운터가 0에서 시작합니다.

  • Graceful Restart는 레이블 IS-IS에 대해 지원되지 않습니다.

    Graceful Restart의 경우 IS-IS 초기화 중에 기존 센서가 삭제되고 새로운 센서가 생성됩니다. 세그먼트 라우팅 통계 카운터는 0에서 다시 시작됩니다.

  • ISSU(In-Service Software Upgrade) 및 NSSU(Nonstop Software Upgrade)는 지원되지 않습니다. 이러한 경우 세그먼트 라우팅 통계 카운터가 다시 시작됩니다.

  • 제로 통계 세그먼트 라우팅 데이터는 억제되며 gRPC 클라이언트에 스트리밍되지 않습니다.

릴리스 기록 테이블
릴리스
설명
20.3R1
Junos OS 릴리스 20.3R1부터 OSPF 및 IS-IS 프로토콜에 대한 세그먼트 라우팅 지원은 SPRING(Source Packet Routing in Networking)에서 기본 기능을 제공합니다.
19.1R1
Junos OS 릴리스 19.1R1부터 MPC 및 MIC 인터페이스와 PTX 시리즈 라우터가 있는 MX 시리즈 라우터에서 추가 센서가 도입되어 본질적으로 IP-to-MPLS 인 MPLS 수신 트래픽에 대한 세그먼트 라우팅 통계를 수집합니다. 이 기능을 사용하면 레이블 IS-IS 세그먼트 라우팅 트래픽에 대한 센서만 활성화하고 통계를 gRPC 클라이언트로 스트리밍할 수 있습니다.
17.4R1
릴리스 17.4R1 Junos OS 세그먼트 라우팅 네트워크의 트래픽 통계를 레이어 3 인터페이스에 대한 OpenConfig 호환 형식으로 기록할 수 있습니다.