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 트래픽 엔지니어링 지원을 활성화할 수 있습니다. OSPF에 대한 트래픽 엔지니어링을 활성화하면 SPF(Shortest-Path-First) 알고리즘은 MPLS에 따라 구성된 다양한 LSP(Label-Switched Path)를 고려하고 트래픽 엔지니어링 매개 변수를 전달하는 불투명 LSA(Link-State Advertisement)를 생성하도록 OSPF를 구성합니다. 매개 변수는 트래픽 엔지니어링 데이터베이스를 채우는 데 사용됩니다. 트래픽 엔지니어링 데이터베이스는 물리적 토폴로지에서 LSP를 배치하기 위한 명시적 경로를 계산하는 용도로만 사용됩니다. CSPF(Constrained Shortest Path First) 알고리즘은 트래픽 엔지니어링 데이터베이스를 사용하여 MPLS LSP가 취하는 경로를 계산합니다. RSVP는 이 경로 정보를 사용하여 LSP를 설정하고 대역폭을 예약합니다.

기본적으로 트래픽 엔지니어링 지원은 비활성화되어 있습니다. 트래픽 엔지니어링을 활성화하려면 명령문을 traffic-engineering 포함합니다. 또한 다음과 같은 최단 경로 우선(OSPF) 트래픽 엔지니어링 확장을 구성할 수 있습니다.

  • advertise-unnumbered-interfaces—(OSPFv2 전용) link-local 트래픽 엔지니어링 LSA 패킷에서 link-local 식별자를 광고합니다. RSVP가 RFC 3477, Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)에 정의된 대로 번호가 지정되지 않은 인터페이스에 신호를 보낼 수 있는 경우 이 문을 포함할 필요가 없습니다.

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

  • 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 영역 내에서 배포되지 않습니다.

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

    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 메트릭을 구성할 수도 있습니다. 트래픽 엔지니어링 메트릭은 트래픽 엔지니어링 데이터베이스에 삽입되는 정보에 사용됩니다. 이 값은 일반 OSPF 전달에 영향을 주지 않습니다.

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

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

요구 사항

시작하기 전에:

개요

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

이 예에서는 영역 0.0.0.0에 4개의 라우팅 디바이스가 있으며, OSPF가 수신 디바이스 R1에서 송신 디바이스 R4로 이동하는 R1-to-R4라는 LSP를 링크로 처리하도록 할 수 있습니다.

OSPF의 경우, 명령문을 포함하여 해당 영역의 라우팅 디바이스 4개 모두에서 트래픽 엔지니어링을 traffic-engineering 활성화합니다. 이 구성은 SPF(Shortest-Path-First) 알고리즘이 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 빠른 구성

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

R1의 구성:

R2 구성:

R3의 구성:

R4의 구성:

단계별 절차

요약 LSA에서 LSP 메트릭을 광고하기 위해 OSPF 트래픽 엔지니어링 지원을 활성화하려면:

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

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

    메모:

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

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

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

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

결과

, show protocols ospf, 및 show 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 (를) 입력합니다.

트래픽 엔지니어링 데이터베이스에서 OSPF 항목 확인

목적

트래픽 엔지니어링 데이터베이스에서 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가 배포하고 트래픽 엔지니어링 데이터베이스에 포함할 원격 주소를 제공해야 합니다. OSPF 트래픽 엔지니어링 모드를 사용하면 MPLS LSP(Label-Switched Path)가 OSPF AS 경계 라우터를 동적으로 검색하고 라우터가 여러 자치 시스템에 걸쳐 트래픽 엔지니어링 LSP를 설정할 수 있습니다.

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

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

요구 사항

시작하기 전에:

개요

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

  • 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 count 필드는 0입니다. 이 필드 옆에 Passive라는 단어도 표시될 수 있습니다.

행동

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

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

네트워크에서 LSP(Label-Switched Path)를 구성하는 주된 이유 중 하나는 네트워크의 두 지점 사이의 최단 경로를 제어하기 위해서입니다. LSP를 OSPFv2에 포인트 투 포인트 링크로 보급하여 모든 참여 라우팅 디바이스가 SPF 계산을 수행할 때 LSP를 고려할 수 있도록 할 수 있습니다. 광고에는 로컬 주소(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 트래픽을 라우팅하려는 경우 이 방법을 선택할 수 있습니다.

이 예에서는 LSP를 OSPFv2에 알리기 위해 다음을 구성합니다.

  • 증권 시세 표시기

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

  • 증권 시세 표시기

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

  • 증권 시세 표시기

    모든 라우팅 디바이스에 대해 관리 인터페이스(fxp0.0)를 제외한 모든 인터페이스에서 RSVP를 활성화합니다. 이 네트워크의 디바이스에서 RSVP를 활성화하면 인터페이스가 LSP에 신호를 보낼 수 있습니다.

  • OSPFv2

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

  • 레이블 전환 경로

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

  • OSPFv2에서 LSP 보급

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

위상수학

그림 1 은 다음으로 구성된 샘플 네트워크 토폴로지를 보여줍니다.

  • BGP는 3개의 라우팅 디바이스를 포함하는 하나의 로컬 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 인접 연결을 구성합니다.

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

디바이스 R1의 구성:

디바이스 R3의 구성:

디바이스 R6의 구성:

LSP 구성

CLI 빠른 구성

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

단계별 절차

디바이스 R1에서 LSP를 구성하려면 다음과 같이 하십시오.

  1. MPLS 구성 모드를 시작합니다.

  2. LSP를 생성합니다.

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

결과

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

LSP를 OSPFv2로 보급

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에 대한 정적 인접 세그먼트 식별자

인접 세그먼트는 링크 비용에 관계없이 두 노드 사이의 특정 링크를 통해 패킷을 전달하는 엄격한 포워딩 단일 홉 터널입니다. 인터페이스에 정적 인접 세그먼트 식별자(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의 값을 명시적으로 구성해야 합니다. 다음은 샘플 구성입니다.

메모:

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

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

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

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

  • Protected(보호됨) - 인접 SID가 백업 경로를 가질 수 있고 인접 SID 보급에 B 플래그가 설정되도록 합니다.

  • 보호되지 않음 - 특정 인접 SID에 대해 백업 경로가 계산되지 않고 인접 SID 보급에 B 플래그가 설정되지 않도록 합니다.

다음은 샘플 구성입니다.

세그먼트 라우팅이 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 명령을 사용하여 구성을 확인합니다.

ospf neighbor detail 표시

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

네트워킹의 소스 패킷 라우팅 이해(SPRING)

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

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

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

  • 첫째, 링크 비용에 관계없이 두 노드 사이의 특정 링크를 통해 패킷을 전달하는 엄격한 포워딩된 단일 홉 터널을 인접 세그먼트라고 합니다.

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

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

세그먼트 라우팅은 소스 라우팅 패러다임을 활용합니다. 노드는 세그먼트라고 하는 정렬된 명령 목록을 통해 패킷을 조정합니다. 세그먼트는 토폴로지 또는 서비스 기반의 모든 명령을 나타낼 수 있습니다. 세그먼트는 세그먼트 라우팅 노드 또는 세그먼트 라우팅 도메인 내의 글로벌 노드에 대한 로컬 의미 체계를 가질 수 있습니다. 세그먼트 라우팅은 세그먼트 라우팅 도메인에 대한 수신 노드에서만 플로우당 상태를 유지하면서 모든 토폴로지 경로 및 서비스 체인을 통해 플로우를 적용합니다. 세그먼트 라우팅은 포워딩 플레인의 변경 없이 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 신호 경로를 사용하는 트래픽과 공존하며, 소스 라우팅은 레이블 작업인 pop, swap(동일한 레이블 값으로) 및 swap-push(인터페이스 보호용)를 사용하여 mpls.0 테이블을 통해 일반 레이블 스위칭으로 구현됩니다. 모든 경우에 트래픽은 여러 레이어 3 인터페이스 간에 또는 통합 인터페이스 내에서 로드 밸런싱될 수 있습니다. Junos OS 릴리스 17.4R1부터 세그먼트 라우팅 네트워크의 트래픽 통계는 레이어 3 인터페이스에 대한 OpenConfig 호환 형식으로 기록될 수 있습니다. 통계는 RSVP 및 LDP 신호 트래픽을 제외한 SPRING(Source Packet Routing in Networking) 트래픽에 대해서만 기록되며, 인터페이스당 제품군 MPLS 통계는 별도로 설명됩니다. SR 통계에는 LAG(Link Aggregation Group) 멤버 및 SID(Segment Identifier)당 SPRING 트래픽 통계도 포함됩니다. 세그먼트 라우팅 통계를 기록하려면 계층 수준에서 문을 [edit protocol isis source-packet-routing] 포함합니다sensor-based-stats.

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

구성 문 아래의 옵션을 사용하여 egress MPLS 수신 트래픽에 대한 세그먼트 라우팅 통계를 활성화할 수 있습니다 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 Routing Engine 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)는 지원되지 않습니다. 이러한 경우 세그먼트 라우팅 통계 카운터가 다시 시작됩니다.

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

변경 내역 테이블

기능 지원은 사용 중인 플랫폼 및 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.

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