Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

넥스트 홉 기반 동적 터널

예: 다음 홉 기반 MPLS-Over-UDP 동적 터널 구성

이 예에서는 터널 복합 다음 홉을 포함하는 동적 MPLS-over-UDP 터널을 구성하는 방법을 보여줍니다. MPLS-over-UDP 기능은 디바이스에서 지원되는 IP 터널 수에 대한 확장 이점을 제공합니다.

Junos OS 릴리스 18.3R1부터 PTX 시리즈 라우터 및 QFX 시리즈 스위치에서 MPLS-over-UDP 터널이 지원됩니다. PTX 라우터 또는 QFX 스위치에 구성된 모든 동적 터널에 대해 터널 대상 경로를 해결하기 위해 터널 복합 다음 홉, 간접 다음 홉 및 포워딩 다음 홉이 생성됩니다. 또한 정책 제어를 사용하여 계층 수준에서 forwarding-rib 구성 문을 포함하여 일부 접두사를 통해 동적 터널을 [edit routing-options dynamic-tunnels] 해결할 수 있습니다.

요구 사항

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

  • MPC 및 MIC가 있는 MX 시리즈 라우터 5개.

  • 프로바이더 에지(PE) 라우터에서 실행되는 Junos OS 릴리스 16.2 이상.

시작하기 전에:

  1. 루프백 인터페이스를 포함하여 디바이스 인터페이스를 구성합니다.

  2. 디바이스의 라우터 ID 및 자동 시스템 번호를 구성합니다.

  3. 원격 PE 디바이스와의 내부 BGP(IBGP) 세션을 설정합니다.

  4. 디바이스 간에 OSPF 피어링을 설정합니다.

개요

Junos OS 릴리스 16.2부터 동적 UDP 터널은 구성된 모든 UDP 터널에 대해 터널 컴포지트 다음 홉의 생성을 지원합니다. 이러한 다음 홉 기반 동적 UDP 터널을 MPLS-over-UDP 터널이라고 합니다. 터널 복합 다음 홉은 MPLS-over-UDP 터널에 대해 기본적으로 활성화됩니다.

MPLS-over-UDP 터널은 기본적으로 양방향 또는 단방향일 수 있습니다.

  • Bidirectional—PE 디바이스가 MPLS-over-UDP 터널을 통해 양방향으로 연결되는 경우 이를 양방향 MPLS-over-UDP 터널이라고 합니다.

  • 단방향 - 두 PE 디바이스가 한 방향으로 MPLS-over-UDP 터널을 통해 연결되고 다른 방향으로 MPLS/IGP를 통해 연결되는 경우 이를 단방향 MPLS-over-UDP 터널이라고 합니다.

    단방향 MPLS-over-UDP 터널은 마이그레이션 시나리오 또는 두 PE 디바이스가 분리된 두 네트워크를 통해 서로 연결을 제공하는 경우에 사용됩니다. 단방향 MPLS-over-UDP 터널에는 역방향 터널이 존재하지 않기 때문에 트래픽을 전달하려면 원격 PE 디바이스에서 필터 기반 MPLS-over-UDP 캡슐화 해제를 구성해야 합니다.

Junos OS 릴리스 18.2R1부터 단방향 MPLS-over-UDP 터널이 있는 PTX 시리즈 라우터 및 QFX10000에서 MPLS-over-UDP 패킷에 대한 입력 필터와 역방향 터널 방향으로 패킷을 전달하기 위한 IP 및 UDP 헤더의 캡슐화 해제 작업으로 원격 PE 디바이스를 구성해야 합니다.

예를 들어, 원격 PE 디바이스인 디바이스 PE2에서 단방향 MPLS-over-UDP 터널에는 다음과 같은 구성이 필요합니다.

PE2

위의 샘플 구성에서 은(는) Decap_Filter MPLS-over-UDP 캡슐화 해제에 사용되는 방화벽 필터의 이름입니다. 이 용어는 udp_decap 디바이스 PE2의 코어 대면 인터페이스에서 UDP 패킷을 수락한 다음 포워딩을 위해 MPLS-over-UDP 패킷을 MPLS-over-IP 패킷으로 캡슐화 해제하기 위한 입력 필터입니다.

필터 기반 MPLS-over-UDP 캡슐화 해제를 보는 등의 기존 방화벽 운영 모드 명령을 show firewall filter 사용할 수 있습니다.

예:

주:

단방향 MPLS-over-UDP 터널의 경우:

  • IPv4 주소만 외부 헤더로 지원됩니다. 필터 기반 MPLS-over-UDP 캡슐화 해제는 외부 헤더에서 IPv6 주소를 지원하지 않습니다.

  • 캡슐화 해제 후에는 기본 라우팅 인스턴스만 지원됩니다.

Junos OS 릴리스 17.1부터 MPC 및 MIC가 있는 MX 시리즈 라우터에서 MPLS-over-UDP 터널의 확장 제한이 증가합니다.

Junos 릴리스 19.2R1부터 MPC 및 MIC가 있는 MX 시리즈 라우터에서 지원 서비스 프로바이더의 PE 디바이스 간에 설정된 동적 IPv4 UDP 터널을 통해 MPLS 트래픽을 전송하는 MPLS-over-UDP 터널을 통해 CSC(Carrier Support Carrier) 아키텍처를 구축할 수 있습니다. 이러한 향상을 통해 MPLS-over-UDP 터널이 제공하는 확장 이점이 더욱 증가합니다. IPv6 UDP 터널에서는 MPLS-over-UDP 터널을 사용하는 CSC 지원이 지원되지 않습니다.

기존 동적 터널 기능을 사용하려면 완전한 정적 구성이 필요합니다. 현재 보급된 경로의 피어 디바이스에서 수신된 터널 정보는 무시됩니다. Junos OS 릴리스 17.4R1부터 MX 시리즈 라우터에서 다음 홉 기반 동적 MPLS-over-UDP 터널은 BGP 캡슐화 확장 커뮤니티를 사용하여 시그널링됩니다. BGP 내보내기 정책은 터널 유형을 지정하고, 발신자 측 터널 정보를 보급하고, 수신자 측 터널 정보를 구문 분석 및 전달하는 데 사용됩니다. 터널은 수신된 유형의 터널 커뮤니티에 따라 생성됩니다.

BGP는 다중 터널 캡슐화를 지원합니다. 여러 기능을 수신하면 구성된 BGP 정책 및 터널 기본 설정에 따라 다음 홉 기반 동적 터널이 생성됩니다. 터널을 설정하려면 터널 양쪽 끝에서 터널 기본 설정이 일관되어야 합니다. 기본적으로 MPLS-over-UDP 터널은 GRE 터널보다 선호됩니다. 동적 터널 구성이 존재하는 경우, 수신된 터널 커뮤니티보다 우선합니다.

다음 홉 기반의 동적 MPLS-over-UDP 터널을 구성할 때 다음 사항을 고려해야 합니다.

  • PE 디바이스 간에 IBGP 세션을 구성해야 합니다.

  • 다음 홉 기반 동적 터널 캡슐화(UDP 및 GRE) 간의 전환이 허용되며, 이는 각 모드에서 지원되는 IP 터널 확장 값 측면에서 네트워크 성능에 영향을 미칠 수 있습니다.

  • 동일한 터널 대상에 대해 GRE 및 UDP 다음 홉 기반 동적 터널 캡슐화 유형을 모두 보유하면 커밋 실패가 발생합니다.

  • 단방향 MPLS-over-UDP 터널의 경우, 패킷이 전달되도록 원격 PE 디바이스에서 필터 기반 MPLS-over-UDP 캡슐화 해제를 명시적으로 구성해야 합니다.

  • GRES(Graceful Routing Engine Switchover)는 MPLS-over-UDP에서 지원되며, MPLS-over-UDP 터널 유형 플래그는 통합 ISSU 및 NSR을 준수합니다.

  • MPLS-over-UDP 터널은 라이트 모드의 가상 MX(vMX)에서 지원됩니다.

  • MPLS-over-UDP 터널은 새로운 IPv4-mapped-IPv6 다음 홉을 기반으로 동적 GRE 터널 생성을 지원합니다.

  • MPLS-over-UDP 터널은 Contrail과의 상호 운용성을 통해 지원되며, 여기서 MPLS-over-UDP 터널은 Contrail vRouter에서 MX 게이트웨이로 생성됩니다. 이를 위해서는 MX 시리즈 라우터에서 contrail vRouter로의 경로에 다음 커뮤니티를 보급해야 합니다.

    특정 시점에 contrail vRouter에서는 다음 홉 기반 동적 GRE 터널, MPLS-over-UDP 터널 또는 VXLAN의 한 가지 터널 유형만 지원됩니다.

  • 다음 기능은 다음 홉 기반 동적 MPLS-over-UDP 터널 구성에서 지원되지 않습니다.

    • RSVP 자동 메시

    • 일반 IPV6 GRE 및 UDP 터널 구성

    • 논리적 시스템

토폴로지

그림 1 에서는 동적 MPLS-over-UDP 터널을 통한 레이어 3 VPN 시나리오를 보여줍니다. 고객 에지(CE) 디바이스인 CE1 및 CE2는 각각 프로바이더 에지(PE) 디바이스인 PE1 및 PE2에 연결됩니다. PE 디바이스는 프로바이더 디바이스(디바이스 P1)에 연결되며, 내부 BGP(IBGP) 세션은 두 PE 디바이스를 상호 연결합니다. PE 디바이스 간에 동적 다음 홉 기반 양방향 MPL-over-UDP 터널이 구성됩니다.

그림 1: 동적 MPLS-over-UDP 터널동적 MPLS-over-UDP 터널

MPLS-over-UDP 터널은 다음과 같이 처리됩니다.

  1. MPLS-over-UDP 터널이 구성된 후, inet.3 라우팅 테이블의 터널에 대해 터널 복합 다음 홉이 있는 터널 대상 마스크 경로가 생성됩니다. 이 IP 터널 경로는 동적 터널 구성이 삭제되어야만 철회됩니다.

    터널 컴포지트 다음 홉 속성에는 다음이 포함됩니다.

    • 레이어 3 VPN 컴포지트 다음 홉이 비활성화된 경우—소스 및 목적지 주소, 캡슐화 문자열 및 VPN 레이블.

    • 레이어 3 VPN 컴포지트 다음 홉 및 접두사별 VPN 레이블 할당이 활성화된 경우—소스 주소, 목적지 주소 및 캡슐화 문자열.

    • 레이어 3 VPN 컴포지트 다음 홉이 활성화되고 접두사별 VPN 레이블 할당이 비활성화된 경우—소스 주소, 목적지 주소 및 캡슐화 문자열. 이 경우 경로는 보조 경로와 함께 다른 가상 라우팅 및 포워딩 인스턴스 테이블에 추가됩니다.

  2. PE 디바이스는 IBGP 세션을 사용하여 상호 연결됩니다. 원격 BGP neighbor에 대한 IBGP 경로 다음 홉은 프로토콜 다음 홉이며, 터널 다음 홉과 함께 터널 마스크 경로를 사용하여 확인됩니다.

  3. 프로토콜 다음 홉이 터널 복합 다음 홉을 통해 해결된 후 포워딩 다음 홉이 있는 간접 다음 홉이 생성됩니다.

  4. 터널 복합 다음 홉은 간접 다음 홉의 다음 홉을 포워딩하는 데 사용됩니다.

구성

CLI 빠른 구성

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

CE1

CE2

PE1

P1

PE2

절차

단계별 절차

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

디바이스 PE1 구성:

  1. 디바이스의 루프백 인터페이스를 포함한 디바이스 인터페이스를 구성합니다.

  2. 디바이스 P1을 다음 홉 대상으로 사용하여 디바이스 PE1의 경로에 대한 정적 경로를 구성합니다.

  3. 디바이스 PE1에 대한 라우터 ID 및 자율 시스템 번호를 구성합니다.

  4. (PTX 시리즈만 해당) 선택한 접두사를 통해 MPLS-over-UDP 동적 터널 경로를 해결하도록 정책 제어를 구성합니다.

  5. (PTX 시리즈만 해당) 를 통해 동적 터널 대상 경로를 확인하기 위한 inet-import 정책을 구성합니다.

  6. PE 디바이스 간의 IBGP 피어링을 구성합니다.

  7. 관리 인터페이스를 제외한 디바이스 PE1의 모든 인터페이스에서 OSPF를 구성합니다.

  8. 디바이스 PE1에서 다음 홉 기반 동적 GRE 터널 구성을 활성화합니다.

    주:

    이 단계는 다음 홉 기반 동적 GRE 터널과 MPLS-over-UDP 터널 간의 구현 차이를 설명하기 위해서만 필요합니다.

  9. 디바이스 PE1에서 디바이스 PE2로의 MPLS-over-UDP 터널 매개 변수를 구성합니다.

  10. 디바이스 PE1 및 기타 라우팅 인스턴스 매개 변수에 VRF 라우팅 인스턴스를 구성합니다.

  11. 디바이스 CE1과의 피어링을 위한 라우팅 인스턴스 구성에서 BGP를 활성화합니다.

결과

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

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

검증

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

PE 디바이스 간 연결 확인

목적

디바이스 PE1과 디바이스 PE2 간의 BGP 피어링 상태와 디바이스 PE2에서 수신된 BGP 경로를 확인합니다.

작업

운영 모드에서 및 show route receive-protocol bgp ip-address table bgp.l3vpn.0 명령을 실행합니다show bgp summary.

의미
  • 첫 번째 출력에서 BGP 세션 상태는 Establ이며, 이는 세션이 작동 중이고 PE 디바이스가 피어링되었음을 의미합니다.

  • 두 번째 출력에서 디바이스 PE1은 디바이스 PE2에서 BGP 경로를 학습 했습니다.

디바이스 PE1에서 동적 터널 경로 확인

목적

inet.3 라우팅 테이블의 경로와 디바이스 PE1의 동적 터널 데이터베이스 정보를 확인합니다.

작업

운영 모드에서 , show dynamic-tunnels database terse, show dynamic-tunnels databaseshow dynamic-tunnels database summary 명령을 실행합니다show route table inet.3.

의미
  • 첫 번째 출력에서는 디바이스 PE1이 MPLS-over-UDP 터널로 구성되었기 때문에 inet.3 라우팅 테이블 경로 항목에 대한 터널 복합 경로가 생성됩니다.

  • 나머지 출력에서는 MPLS-over-UDP 터널이 터널 캡슐화 유형, 터널 다음 홉 매개 변수 및 터널 상태와 함께 표시됩니다.

디바이스 PE2에서 동적 터널 경로 확인

목적

inet.3 라우팅 테이블의 경로와 디바이스 PE2의 동적 터널 데이터베이스 정보를 확인합니다.

작업

운영 모드에서 , 및 명령을 show dynamic-tunnels database terse 실행합니다show route table inet.3.

의미

출력은 디바이스 PE1과 유사하게 MPLS-over-UDP 터널 생성과 다음 홉 인터페이스로 할당된 다음 홉 ID를 보여줍니다.

경로에 예상되는 간접 다음 홉 플래그가 있는지 확인

목적

디바이스 PE1 및 디바이스 PE2가 패킷 전달 엔진 포워딩 테이블에서 포워딩 다음 홉 바인딩에 대한 간접 다음 홉을 유지하도록 구성되었는지 확인합니다.

작업

운영 모드의 디바이스 PE1 및 디바이스 PE2에서 명령을 실행합니다 show krt indirect-next-hop .

의미

출력은 PE 디바이스 간에 다음 홉 기반 동적 MPLS-over-UDP 터널이 생성됨을 보여줍니다.

문제 해결

다음 홉 기반 동적 터널 문제를 해결하려면 다음을 참조하십시오.

문제 해결 명령어

문제

next-hop-based 동적 MPLS-over-UDP 터널 구성은 적용되지 않습니다.

솔루션

다음 홉 기반 MPLS-over-UDP 터널 구성 문제를 해결하려면 문 계층에서 [edit routing-options dynamic-tunnels] 다음 traceroute 명령을 사용합니다.

  • traceoptions file file-name

  • traceoptions file size file-size

  • traceoptions flag all

예:

다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호 개요

데이터센터에 대규모 IP 터널의 구축이 증가함에 따라 사용자가 손상된 가상 머신(VM)의 악성 트래픽을 제한할 수 있는 보안 조치를 추가해야 할 필요가 있습니다. 한 가지 가능한 공격은 감염된 서버에서 게이트웨이 라우터를 통해 임의의 고객 VPN에 트래픽을 주입하는 것입니다. 이러한 경우 IP 터널에 대한 스푸핑 방지 검사를 통해 합법적인 소스만 지정된 IP 터널에서 데이터센터로 트래픽을 주입하도록 합니다.

다음 홉 기반 동적 IP 터널은 디바이스에서 생성된 모든 동적 터널에 대해 터널 복합 다음 홉을 생성합니다. 다음 홉 기반 동적 터널은 구성된 모든 새 동적 터널에 대한 물리적 인터페이스에 대한 종속성을 제거하기 때문에 다음 홉 기반 동적 터널을 구성하면 디바이스에서 생성할 수 있는 동적 터널 수에 비해 확장 이점을 제공합니다. Junos OS 릴리스 17.1부터 넥스트 홉 기반 동적 터널을 위한 넥스트 홉 기반 동적 IP 터널에 대한 스푸핑 방지 기능이 제공됩니다. 이러한 향상된 기능을 통해 게이트웨이 라우터를 통해 손상된 서버에서 임의의 고객 VPN으로 트래픽이 유입되는 것을 방지하기 위한 보안 조치가 구현됩니다.

스푸핑 방지는 패킷 전달 엔진에서 역방향 경로 전달 검사를 사용하여 구현됩니다. 터널을 통해 라우팅 인스턴스로 들어오는 트래픽에 대한 검사가 구현됩니다. 현재 게이트웨이 라우터가 터널에서 트래픽을 수신하면 대상 조회만 완료되고 그에 따라 패킷이 전달됩니다. 스푸핑 방지 보호가 활성화되면 게이트웨이 라우터는 터널 대상 조회 외에도 VPN에서 캡슐화 패킷 IP 헤더의 소스 주소 조회도 수행합니다. 이렇게 하면 합법적인 소스가 지정된 IP 터널을 통해 트래픽을 주입할 수 있습니다. 따라서 스푸핑 방지 보호 기능을 통해 지정된 터널의 합법적인 소스로부터 터널 트래픽을 수신할 수 있습니다.

그림 2 에서는 스푸핑 방지 보호에 대한 요구 사항이 있는 샘플 토폴로지를 보여 줍니다.

그림 2: 다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호

이 예에서 게이트웨이 라우터는 라우터 G입니다. 라우터 G에는 두 개의 VPN(녹색 및 파란색)이 있습니다. 서버 A와 서버 B의 두 서버는 각각 다음 홉 기반 동적 터널 T1과 T2를 통해 라우터 G의 Green 및 Blue VPN에 연결할 수 있습니다. 서버에 연결된 여러 호스트 및 가상 머신(P, Q, R, S 및 T)은 게이트웨이 라우터인 라우터 G를 통해 VPN에 연결할 수 있습니다. 라우터 G에는 Green 및 Blue VPN에 대한 VRF(Virtual Routing and Forwarding) 테이블이 있으며, 각 테이블에는 해당 VPN의 가상 머신에 대한 도달 가능성 정보가 채워져 있습니다.

예를 들어, VPN Green에서 라우터 G는 터널 T1을 사용하여 호스트 P에 도달하고, 터널 T2를 사용하여 호스트 R 및 S에 도달하며, 터널 T1과 T2 사이에서 로드 밸런싱을 수행하여 멀티홈 호스트 Q에 도달합니다. VPN Blue에서 라우터 G는 터널 T1을 사용하여 호스트 P와 R에 도달하고 터널 T2를 사용하여 호스트 Q와 T에 도달합니다.

다음과 같은 경우 역방향 경로 전달에 대한 검사가 통과됩니다.

  • 패킷은 지정된 터널의 합법적인 소스에서 옵니다.

    VPN Green의 호스트 P는 터널 T1을 사용하여 호스트 X에 패킷을 보냅니다. 라우터 G는 터널 T1을 통해 호스트 P에 도달할 수 있으므로 패킷이 호스트 X로 패킷을 전달하고 전달할 수 있습니다.

  • 패킷은 지정된 터널의 멀티홈 소스에서 나옵니다.

    VPN Green의 호스트 Q는 서버 A와 B에서 멀티호밍되며 터널 T1과 T2를 통해 라우터 G에 도달할 수 있습니다. 호스트 Q는 터널 T1을 사용하여 호스트 Y에 패킷을 보내고 터널 T2를 사용하여 호스트 X에 패킷을 보냅니다. 라우터 G는 터널 T1과 T2를 통해 호스트 Q에 도달할 수 있기 때문에 패킷이 각각 호스트 Y와 X로 전달되도록 합니다.

레이어 3 VPN은 기본적으로 스푸핑 방지 보호가 활성화되어 있지 않습니다. 다음 홉 기반 동적 터널에 대한 스푸핑 방지를 [edit routing-instances routing-instance-name routing-options forwarding-table] 활성화하려면 계층 수준에서 문을 포함합니다ip-tunnel-rpf-check. 역방향 경로 포워딩 검사는 VRF 라우팅 인스턴스에만 적용됩니다. 기본 모드는 로 설정됩니다 strict. 여기서 지정되지 않은 터널의 소스에서 오는 패킷은 검사를 통과하지 못합니다. 모드는 로 설정할 loose수 있으며, 여기서 패킷이 ip-tunnel-rpf-check 존재하지 않는 소스에서 온 경우 역방향 경로 전달 확인이 실패합니다. 문에서 ip-tunnel-rpf-check 선택적 방화벽 필터를 구성하여 역방향 경로 전달 검사에 실패한 패킷을 계산하고 기록할 수 있습니다.

다음 샘플 출력은 스푸핑 방지 구성을 보여줍니다.

다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호를 구성할 때 다음 지침을 고려하십시오.

  • 스푸핑 방지 보호는 IPv4 터널 및 IPv4 데이터 트래픽에 대해서만 활성화할 수 있습니다. 스푸핑 방지 기능은 IPv6 터널 및 IPv6 데이터 트래픽에서 지원되지 않습니다.

  • 다음 홉 기반 동적 터널에 대한 스푸핑 방지는 손상된 가상 머신을 탐지하고 방지할 수 있지만(내부 소스 역방향 경로 전달 확인) 손상된 레이블 스푸핑인 서버는 감지하지 못합니다.

  • 다음 홉 기반 IP 터널은 inet.0 라우팅 테이블에서 시작되고 종료될 수 있습니다.

  • 스푸핑 방지 보호는 VRF 라우팅 인스턴스에 레이블 스위치 인터페이스(LSI)( 사용 vrf-table-label) 또는 가상 터널(VT) 인터페이스가 있을 때 효과적입니다. VRF 라우팅 인스턴스에서 레이블을 사용하면 per-next-hop 스푸핑 방지 보호가 지원되지 않습니다.

  • rpf fail-filter 내부 IP 패킷에만 적용됩니다.

  • 스푸핑 방지 검사를 활성화해도 디바이스의 다음 홉 기반 동적 터널의 확장 제한에는 영향을 미치지 않습니다.

  • VRF 라우팅 인스턴스에 대해 스푸핑 방지 보호가 활성화된 시스템 리소스 사용률은 스푸핑 방지 보호가 활성화되지 않은 다음 홉 기반 동적 터널의 사용률보다 약간 높습니다.

  • 스푸핑 방지 보호에는 추가 소스 IP 주소 확인이 필요하며, 이는 네트워크 성능에 미치는 영향을 최소화합니다.

  • 스푸핑 방지 보호와 함께 GRES(Graceful Routing Engine Switchover) 및 ISSU(In-Service Software Upgrade)가 지원됩니다.

예: 다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호 구성

이 예에서는 다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호를 활성화하기 위해 VRF(Virtual Routing and Forwarding) 라우팅 인스턴스에 대한 역방향 경로 포워딩 검사를 구성하는 방법을 보여줍니다. 검사는 합법적인 소스가 지정된 IP 터널을 통해 트래픽을 주입하고 있는지 확인합니다.

요구 사항

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

  • MIC가 있는 3개의 MX 시리즈 라우터, 각각 호스트 디바이스에 연결됨.

  • Junos OS 릴리스 17.1 이상은 하나 또는 모든 라우터에서 실행됩니다.

시작하기 전에:

  • Flexible PIC Concentrator에서 터널 서비스 구성을 활성화합니다.

  • 라우터 인터페이스를 구성합니다.

  • 라우터 ID를 구성하고 라우터에 대한 자치 시스템 번호를 할당합니다.

  • 터널 엔드포인트와 내부 BGP(IBGP) 세션을 설정합니다.

  • 모든 라우터에서 RSVP를 구성합니다.

  • 모든 라우터에서 OSPF 또는 기타 내부 게이트웨이 프로토콜을 구성합니다.

  • 두 라우터 사이에 두 개의 동적 다음 홉 기반 IP 터널을 구성합니다.

  • 모든 라우터-호스트 연결에 대해 VRF 라우팅 인스턴스를 구성합니다.

개요

Junos OS 릴리스 17.1부터 스푸핑 방지 기능이 다음 홉 기반 동적 IP 터널에 추가되며, 패킷 전달 엔진에서 역방향 경로 포워딩을 사용하여 터널을 통해 라우팅 인스턴스로 들어오는 트래픽에 대한 검사가 구현됩니다.

현재 게이트웨이 라우터가 터널에서 트래픽을 수신하면 포워딩 전에 대상 주소 조회만 수행됩니다. 스푸핑 방지 보호 기능을 통해 게이트웨이 라우터는 VPN에서 캡슐화 패킷 IP 헤더의 소스 주소 조회를 수행하여 합법적인 소스가 지정된 IP 터널을 통해 트래픽을 주입하는지 확인합니다. 이를 엄격 모드라고 하며 스푸핑 방지 보호의 기본 동작입니다. 지정되지 않은 터널에서 트래픽을 전달하기 위해 손실 모드에서 역방향 경로 전달 확인이 활성화됩니다. 존재하지 않는 소스에서 수신된 트래픽의 경우, 엄격 모드와 느슨한 모드 모두에서 역방향 경로 전달 검사가 실패합니다.

스푸핑 방지는 VRF 라우팅 인스턴스에서 지원됩니다. 동적 터널에 대한 스푸핑 방지를 활성화하려면 계층 수준에서 문을 [edit routing-instances routing-instance-name routing-options forwarding-table] 포함합니다ip-tunnel-rpf-check.

토폴로지

그림 3 은 스푸핑 방지 보호가 활성화된 샘플 네트워크 토폴로지를 보여줍니다. 라우터 R0, R1 및 R2는 각각 호스트 Host0, Host1 및 Host2에 각각 연결되어 있습니다. 두 개의 GRE(Generic Routing Encapsulation) 넥스트 홉 기반 동적 터널인 터널 1과 터널 2는 라우터 R0을 각각 라우터 R1 및 R2와 연결합니다. VRF 라우팅 인스턴스는 각 라우터와 연결된 호스트 디바이스 간에 실행됩니다.

그림 3: 다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호다음 홉 기반 동적 터널에 대한 스푸핑 방지 보호

예를 들어, 라우터 R2에서 다음 홉 기반 동적 GRE 터널(터널 2)을 통해 라우터 0에서 3개의 패킷(패킷 A, B, C)이 수신됩니다. 이러한 패킷의 소스 IP 주소는 172.17.0.2(패킷 A), 172.18.0.2(패킷 B) 및 172.20.0.2(패킷 C)입니다.

패킷 A와 B의 소스 IP 주소는 각각 Host 2와 Host 1에 속합니다. 패킷 C는 존재하지 않는 소스 터널입니다. 이 예에서 지정된 터널은 터널 2이고, 지정되지 않은 터널은 터널 1입니다. 따라서 패킷은 다음과 같이 처리됩니다.

  • Packet A- 소스가 지정된 터널(터널 2)에서 오기 때문에 패킷 A는 역방향 경로 전달 검사를 통과하고 터널 2를 통해 전달하도록 처리됩니다.

  • Packet B- 소스가 목적지가 지정되지 않은 터널인 터널 1에서 오기 때문에 기본적으로 패킷 B는 엄격 모드에서 역방향 경로 전달 검사에 실패합니다. 느슨한 모드가 활성화되면 패킷 B를 전달할 수 있습니다.

  • Packet C- 소스가 존재하지 않는 터널 소스이기 때문에 패킷 C는 역방향 경로 전달 검사에 실패하고 패킷은 전달되지 않습니다.

구성

CLI 빠른 구성

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

라우터 R0

라우터 R1

R2

절차

단계별 절차

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

다음을 참조하여 라우터 R0를 구성하십시오:

  1. 루프백 인터페이스를 포함하여 라우터 R0의 인터페이스를 구성합니다.

  2. 라우터 R0에 대한 라우터 ID 및 자동 시스템 번호를 할당합니다.

  3. 라우터 간의 IBGP 피어링을 구성합니다.

  4. 관리 인터페이스를 제외한 라우터 R0의 모든 인터페이스에 OSPF를 구성합니다.

  5. 관리 인터페이스를 제외한 라우터 R0의 모든 인터페이스에서 RSVP를 구성합니다.

  6. 라우터 R0에서 다음 홉 기반 동적 GRE 터널 구성을 활성화합니다.

  7. 라우터 R0에서 라우터 R1로의 동적 GRE 터널 매개 변수를 구성합니다.

  8. 라우터 R0에서 라우터 R2로의 동적 GRE 터널 매개 변수를 구성합니다.

  9. 라우터 R0에서 가상 라우팅 및 포워딩(VRF) 라우팅 인스턴스를 구성하고 호스트 1에 연결하는 인터페이스를 VRF 인스턴스에 할당합니다.

  10. VRF 라우팅 인스턴스에 대해 호스트 1과의 외부 BGP 세션을 구성합니다.

  11. 라우터 R0에서 VRF 라우팅 인스턴스에 대한 스푸핑 방지 보호를 구성합니다. 이를 통해 라우터 0에서 다음 홉 기반 동적 터널인 T1 및 T2에 대한 역방향 경로 포워딩 확인을 수행할 수 있습니다.

결과

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

검증

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

기본 구성 확인

목적

라우터 R0과 라우터 R1 및 R2 간의 OSPF 및 BGP 피어링 상태를 확인합니다.

작업

운영 모드에서 및 show bgp summary명령을 실행합니다show ospf neighbor.

의미

OSPF 및 BGP 세션은 라우터 R0, R1 및 R2 간에 가동되어 실행됩니다.

동적 터널 구성 확인

목적

라우터 R0과 라우터 R1 및 R2 간의 다음 홉 기반 동적 GRE 터널의 상태를 확인합니다.

작업

운영 모드에서 , 및 명령을 show dynamic-tunnels database terse 실행합니다show route table inet.3.

의미

두 개의 다음 홉 기반 동적 GRE 터널인 터널 1과 터널 2가 작동 중입니다.

스푸핑 방지 보호 구성 확인

목적

라우터 R0의 VRF 라우팅 인스턴스에서 역방향 경로 포워딩 확인이 활성화되었는지 확인합니다.

작업

작동 모드에서 show krt table VPN1.inet.0 detail.

의미

구성된 역방향 경로 포워딩 검사는 엄격 모드의 VRF 라우팅 인스턴스에서 활성화됩니다.

Next-Hop 기반 동적 터널 현지화 개요

다음 홉 기반 동적 터널에는 GRE(Generic Routing Encapsulation) 터널과 MPLS-over-UDP 터널이 포함됩니다. 이러한 터널은 인터페이스 기반 터널에 비해 확장성 이점을 제공합니다. 그러나 인터페이스 기반 터널과 달리 넥스트 홉 기반 동적 터널은 본질적으로 앵커가 없으며, 터널의 포워딩 정보가 디바이스의 모든 라인 카드에 있는 패킷 포워딩 엔진(PFE)에 배포됩니다. 이는 디바이스에서 지원되는 최대 터널 수를 단일 라인 카드의 터널 용량으로 제한합니다. 현지화 지원을 통해 다음 홉 기반 동적 터널 현지화를 구성하여 앵커 PFE로 지정된 라인 카드의 PFE에만 포워딩 정보를 생성할 수 있습니다. 디바이스의 다른 라인 카드에 있는 PFE는 패킷을 앵커 PFE로 조정하기 위한 상태 전달 정보를 가지고 있습니다. 이는 디바이스에서 지원되는 최대 터널 수를 늘려 확장상의 이점을 제공합니다.

Next-Hop 기반 동적 터널 현지화의 이점

디바이스에서 지원되는 최대 터널 수를 늘려 확장 이점을 제공합니다.

Next-Hop 기반 동적 터널 현지화 사용 사례

  • 다수의 MS-MPC를 호스트하는 IPsec 게이트웨이 디바이스는 IPSec 터널을 종료하는 데 사용되며 보통 부하를 지원하는 데 필요합니다. 이 지원은 디바이스의 확장 제한에 도달할 때 다음 홉 기반 동적 터널을 사용할 때 영향을 받습니다. 넥스트 홉 기반 동적 터널의 현지화로 지원되는 터널의 최대 수가 증가하여 디바이스가 추가 패브릭 홉을 희생시키면서 더 많은 터널을 수용할 수 있습니다.

  • 가상 퍼블릭 클라우드 데이터 센터와 같은 인터넷 또는 VPN 게이트웨이 디바이스의 경우 게이트웨이 디바이스가 많은 수의 서버와 통신해야 합니다. 데이터센터 서버는 넥스트 홉 기반 동적 터널을 통해 연결할 수 있습니다. 동적 터널의 anchorless 속성은 디바이스의 전체 배율 조정 횟수를 제한합니다. 게이트웨이 디바이스는 트래픽 수요가 증가함에 따라 여러 MPC를 호스팅합니다. 넥스트 홉 기반 동적 터널의 현지화를 통해 터널이 MPC 전체에 분산될 수 있으므로 터널 확장 횟수를 쉽게 늘릴 수 있습니다.

Next-Hop 기반 동적 터널 현지화를 통한 트래픽 처리

현지화 지원을 통해 다음 홉 기반 동적 터널 상태는 앵커 패킷 전달 엔진으로 현지화되고, 다른 패킷 전달 엔진은 터널 앵커로 트래픽을 조정하기 위한 터널 상태를 갖습니다.

그림 4 은(는) 현지화되지 않은 다음 홉 기반 동적 터널의 전달 경로를 보여줍니다.

그림 4: 현지화 없이 Next-Hop 기반 동적 터널의 포워딩 경로현지화 없이 Next-Hop 기반 동적 터널의 포워딩 경로

그림 5 은(는) 현지화를 통한 다음 홉 기반 동적 터널의 전달 경로를 보여줍니다.

그림 5: 현지화를 통한 Next-Hop 기반 동적 터널의 포워딩 경로현지화를 통한 Next-Hop 기반 동적 터널의 포워딩 경로

Next-Hop 기반 동적 터널 현지화 구성

현지화 지원은 새로 생성된 다음 홉 기반 동적 터널 또는 기존의 비로컬 동적 터널에 대해 구성할 수 있습니다.

새로운 다음 홉 기반 동적 터널에 대한 현지화 구성

다음 홉 기반 동적 터널의 현지화는 정책 기반 접근 방식을 사용하여 접두사 그룹을 지정합니다. 즉, 경로 정책은 다음 홉 기반 동적 터널에 현지화 속성을 적용하는 데 사용됩니다. 동적 터널 속성 프로파일은 정책을 사용하여 접두사 그룹과 연결하기 위한 라우팅 옵션 아래에 생성 및 구성됩니다.

  1. 동적 터널 프로파일 생성.

    동적 터널 프로필은 터널 유형과 앵커 패킷 전달 엔진 정보를 지정합니다. 동적 터널의 현지화를 위해 여러 동적 터널 프로파일을 생성할 수 있습니다. 동적 터널 유형의 값은 GRE, UDP 또는 BGP-SIGNAL일 수 있습니다.

    BGP-SIGNAL이 유효한 터널 유형이 아니지만 BGP-SIGNAL을 터널 유형으로 할당하면 BGP 신호 속성에서 생성된 터널이 현지화됩니다. BGP-SIGNAL을 사용할 때 터널 유형은 해당 TLV에서 BGP가 광고하는 유형에 따라 결정됩니다. BGP-SIGNAL 터널은 항상 넥스트 홉 기반 터널입니다. BGP-SIGNAL에 의해 동적으로 생성된 GRE 터널은 사용자가 IFL을 사용하기 위해 GRE에 의해 생성된 터널을 수동으로 구성한 경우에도 항상 다음 홉 기반입니다.

    앵커 패킷 전달 엔진 값은 앵커 패킷 전달 엔진의 라인 카드입니다(예: pfe-x/y/0). 이 정보는 명령 출력에서 볼 수 있습니다 show interfaces terse pfe* .

    Sample Configuration:

  2. 동적 터널 프로파일을 접두사 목록에 연결합니다.

    작업을 사용하여 dynamic-tunnel-attributes 정책을 구성하면 동적 터널이 접두사 목록에 연결됩니다. 정책 from 작업을 사용하면 접두사 범위, 커뮤니티 또는 BGP 경로의 소스 주소 등과 같은 일치하는 조건에 대해 지정된 속성을 가진 터널을 생성할 수 있습니다.

    Sample configuration:

  3. 포워딩 테이블 내보내기 정책 아래에 터널 정책을 포함합니다.

    정책이 구성되면 정책 구문 분석을 위한 포워딩 테이블 내보내기 정책에 포함됩니다.

    export-policy를 사용하면 터널 속성이 경로와 연결됩니다. BGP의 경로가 확인을 위해 대기열에 대기될 때마다 포워딩 테이블 내보내기 정책이 평가되고 적용된 필터를 기반으로 정책 모듈에서 터널 속성을 가져옵니다. 그런 다음 획득한 터널 속성은 터널 복합 다음 홉의 형태로 다음 홉에 연결됩니다. 패킷 전달 엔진 이름 및 터널 유형을 기반으로 해당 앵커 전달 구조가 생성되어 터널 복합 다음 홉이 전송되기 전에 포워딩 테이블로 전송됩니다. 그러나 어떤 속성도 터널 컴포지트 다음 홉에 매핑되지 않으면 모든 패킷 포워딩 엔진에 포워딩 구조가 생성되며, 이는 현지화되지 않은 동적 터널과 유사합니다.

    Sample configuration:

기존 다음 홉 기반 동적 터널에 대한 현지화 구성

경고:

동적 터널 속성을 즉시 변경하면 높은 메모리 사용률로 인해 FPC 충돌이 발생할 수 있습니다. 따라서 현지화를 구성하기 전에 동적 터널 구성을 비활성화하는 것이 좋습니다.

기존 다음 홉 기반 동적 터널에 대한 터널 속성을 업데이트하려면 다음을 수행해야 합니다.

  1. 계층 수준에서 구성을 비활성화 dynamic-tunnels 합니다 [edit routing-options] .

    Sample configuration:

  2. 필요에 따라 터널 속성을 변경합니다.

  3. 계층 수준에서 구성을 [edit routing-options] 활성화합니다dynamic-tunnels.

    Sample configuration:

로컬이 아닌 기존 다음 홉 기반 동적 터널에 대한 현지화를 구성하려면 다음을 수행합니다.

경고:

기존의 로컬이 아닌 다음 홉 기반 동적 터널에 대한 현지화를 구성하기 위해 즉석에서 변경하면 높은 메모리 사용률로 인해 FPC 충돌이 발생할 수 있습니다. 따라서 현지화를 구성하기 전에 동적 터널 구성을 비활성화하는 것이 좋습니다.

  1. 계층 수준에서 구성을 비활성화 dynamic-tunnels 합니다 [edit routing-options] .

  2. tunnel-attributes 프로파일을 생성하고 새로운 다음 홉 기반 동적 터널과 유사하게 동적 터널을 현지화하기 위한 정책을 추가합니다.

  3. 구성을 활성화합니다 dynamic-tunnels .

현지화된 다음 홉 기반 동적 터널 문제 해결

다음 홉 기반 동적 터널의 현지화를 통해 터널 복합 다음 홉은 앵커 패킷 전달 엔진 ID와 연결됩니다. 계층 수준에서 다음 traceroute 구성 문 [edit routing-options] 은 현지화된 동적 터널의 문제를 해결하는 데 도움이 됩니다.

  • dynamic-tunnels traceoptions flag all- DTM에서 터널 생성 및 삭제를 추적합니다.

  • resolution traceoptions flag tunnel- BGP 경로에서 확인자 작업 추적.

  • forwarding-table traceoptions flag all- 커널로 전송된 터널 추적.

  • traceoptions flag all- 경로 학습 프로세스 추적.

다음 명령을 사용하여 경로가 현지화된 다음 홉 기반 동적 터널을 사용하고 있는지 확인할 수 있습니다.

  1. show route prefix extensive- 간접 다음 홉을 가져옵니다.

    예:

  2. show krt indirect-next-hop index indirect-next-hop detail- 간접 다음 홉의 세부 출력에서 앵커 패킷 전달 엔진 필드를 확인합니다.

    예:

다음 홉 기반 동적 터널 현지화에 지원되지 않는 기능

Junos OS는 다음 홉 기반 동적 터널의 현지화와 함께 다음 기능을 지원하지 않습니다.

  • 계층 수준에서 연결된 복합 다음 홉입니다 [edit routing-options forwarding-table chained-composite-next-hop ingress l3vpn] .

  • 앵커 패킷 전달 엔진 복원력.

    현지화된 다음 홉 기반 동적 터널에 대한 복원력 지원은 없습니다. 넥스트 홉 기반 동적 터널의 현지화 후, 앵커 패커 포워딩 엔진은 디바이스에서 주어진 터널을 처리하기 위한 단일 엔티티가 됩니다. 앵커 패커 포워딩 엔진 복원력은 지원되지 않지만, 게이트웨이 디바이스의 경우 게이트웨이 디바이스의 이중화를 통해 터널 복합 다음 홉이 위임된 패커 포워딩 엔진이 다운될 때 트래픽을 중복 게이트웨이 디바이스로 다시 라우팅해야 합니다. 라우팅 프로토콜 프로세스는 Packer 포워딩 엔진의 상태를 모니터링하고, 해당 패커 포워딩 엔진에 고정된 터널 복합 다음 홉을 가리키는 모든 경로의 BGP 보급을 철회합니다.

    고정된 패킷 전달 엔진에만 완전한 터널 복합 다음 홉이 있고 다른 모든 패킷 전달 엔진에는 앵커 패킷 전달 엔진으로 트래픽을 전달하기 위한 스티어링 항목만 있습니다. 앵커 FPC가 다운되어도 이러한 스티어링 엔트리는 철회되지 않습니다.

  • 다음 홉 기반 동적 터널의 현지화는 논리적 시스템에서 지원되지 않습니다.

  • IPv6는 다음 홉 기반 동적 터널의 현지화와 함께 지원되지 않습니다.

  • 현지화 show dynamic-tunnels database summary 를 사용하면 앵커 패킷 전달 엔진 라인 카드의 상태가 작동하지 않을 때 명령이 정확한 터널 요약을 표시하지 않습니다. 해결 방법으로 및 show dynamic-tunnels database terse 명령 출력을 사용합니다show dynamic-tunnels database.

IP-over-IP 캡슐화를 사용한 Next-Hop 기반 동적 터널링 개요

이점

IP-over-IP 터널링은 다음과 같은 이점을 제공합니다.

  • Alternative to MPLS over UDP- 서비스당 전용 디바이스가 있는 IP 서비스를 제공하기 위해 MPLS-over-UDP 터널링의 대안으로 사용할 수 있습니다.

  • Ability to steer specific traffic- MPLS 터널이 아닌 IP 터널을 통해 특정 트래픽을 조정하도록 경로를 필터링할 수 있으므로 MPLS 및 IP 네트워크가 공존할 때 원활한 마이그레이션을 지원합니다.

  • Ability to support tunnels at increasing scale—BGP 컨트롤 플레인을 사용한 동적 터널 생성은 대규모 터널 생성을 용이하게 할 수 있습니다.

IP-over-IP 동적 다음 홉 기반 터널링이란 무엇입니까?

IP 네트워크에는 에지 디바이스와 코어 디바이스가 포함됩니다. 이러한 디바이스 간에 더 높은 확장성과 안정성을 달성하려면 오버레이 캡슐화를 사용하여 에지 디바이스가 상호 작용하는 외부 네트워크와 코어 네트워크를 논리적으로 격리해야 합니다.

Junos OS 릴리스 20.3R1부터 IP 전송 네트워크를 통한 IP 오버레이 구축을 용이하게 하기 위해 IP-over-IP 캡슐화를 지원합니다. IP over IP는 더 높은 확장성을 지원하기 위해 다음 홉 기반 인프라에 의존합니다. 이 기능은 IPv6 및 IPv4 페이로드의 IPv4 캡슐화를 지원합니다. 지원되는 다른 오버레이 캡슐화 중에서 IP-over-IP 캡슐화는 다음을 허용하는 유일한 종류입니다.

  • 내부 페이로드를 구문 분석하고 해시 계산을 위해 내부 패킷 필드를 사용하는 전송 디바이스

  • 처리량 감소 없이 터널 안팎으로 트래픽을 라우팅하는 고객 에지 디바이스

MX 시리즈 라우터에서 라우팅 프로토콜 데몬(RPD)은 터널 복합 넥스트홉과 함께 캡슐화 헤더를 전송하고 패킷 전달 엔진(PFE)은 터널 대상 주소를 찾아 패킷을 전달합니다. PTX 시리즈 라우터 및 QFX10000 스위치에서 RPD는 완전히 확인된 다음 홉 기반 터널을 패킷 전달 엔진으로 보냅니다. BGP 프로토콜은 경로를 배포하고 동적 터널을 신호하는 데 사용됩니다.

다음 그림은 R-2와 R-4 사이에 설정된 IP 터널을 통해 IPv4 또는 IPv6 트래픽이 R-1에서 R-5로 전송되는 방법을 보여줍니다.

IP-over-IP 터널 연결

Junos OS 릴리스 21.3R1에서는 MX240, MX480, MX960, PTX1000, PTX10008, PTX10016 및 QFX10002에 IP-over-IP 터널 연결이 도입되었습니다. 이 기능을 사용하여 디바이스에서 IP-over-IP 터널을 종료하고 동일한 디바이스에서 다른 터널을 시작할 수 있습니다. 디바이스가 IP-over-IP 패킷을 수신하면 외부 패킷 헤더의 캡슐화를 해제하고 내부 패킷 조회가 발생합니다. 그런 다음 내부 IP 패킷 헤더는 동일한 디바이스의 다른 터널을 가리키며, 여기서 동일한 디바이스가 다른 IP-over-IP 헤더로 패킷을 다시 캡슐화합니다.

예: Next-Hop 기반 IP-over-IP 동적 터널 구성

IP-over-IP 캡슐화를 사용하여 다음 홉 기반 터널을 구성하는 방법을 알아봅니다.

요구 사항

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

  • MX 시리즈 라우터 5개.

  • Junos OS 릴리스 20.3R1 이상 버전.

개요

Junos OS 릴리스 20.3R1부터 IP 전송 네트워크를 통한 IP 오버레이 구축을 용이하게 하기 위해 IP-over-IP 캡슐화를 지원합니다. 이 예는 OSPF 코어를 통해 연결된 R2와 R4 사이의 IBGP 피어링을 통해 프로토콜 다음 홉(PNH)이 있는 디바이스 간에 유니캐스트 IP-over-IP 터널을 설정하여 경로와 신호 동적 터널을 교환하는 방법을 보여줍니다.

토폴로지

그림 1은 5개의 디바이스가 있는 IP-over-IP 시나리오를 보여줍니다.

이 예에서는 R2와 R4 사이에 설정된 IP-over-IP 동적 터널을 통해 R1에서 R5로 또는 그 반대로 경로를 교환합니다. 프로토콜 IS-IS를 사용하여 R1의 경로는 R2로 내보내고 R5의 경로는 R4로 내보냅니다. R2에서 R4로 유니캐스트 IPIP 터널 Tunnel-01 을 구성하고 R4에서 R2로 또 다른 터널 Tunnel-01 을 구성합니다. 피어 디바이스의 구성된 대상 네트워크에서 네트워크 마스크 내에서 생성된 경로 접두사는 터널을 생성하는 데 사용되며 터널의 경로와 반대 방향으로 트래픽이 흐릅니다.

프로토콜 다음 홉을 사용하여 IP-over-IP 동적 터널 구성

CLI 빠른 구성

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

R1

R2

R3

R4

R5

프로토콜 다음 홉으로 IP-IP 동적 터널 구성

R1에 대한 단계별 절차

R1 및 R5는 구성이 유사하므로 R1에 대한 단계별 절차만 보여줍니다.

  1. R1에서 구성 모드로 들어갑니다.

  2. R2 및 인터페이스 lo0에 연결된 인터페이스를 구성합니다. family inetiso를 모두 구성해야 합니다. 프로토콜 IS-IS에는 패밀리 iso 가 필요합니다.

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

  4. 프로토콜 IS-IS를 구성합니다. 경로는 IS-IS 프로토콜을 사용하여 R1과 R2 사이에 보급됩니다.

  5. 구성 모드에서 R1에 진입 commit 합니다.

R2에 대한 단계별 절차

R2 및 R4는 구성이 유사하므로 R2에 대한 단계별 절차만 보여드리겠습니다.

  1. R2에서 구성 모드를 시작합니다.

  2. R1 및 R3과 인터페이스 lo0에 연결된 인터페이스를 구성합니다. R1 및 lo0에 연결된 인터페이스에서 familyinetiso 를 모두 구성해야 합니다.

  3. R1에 연결된 인터페이스에 대한 프로토콜 IS-IS를 구성합니다. BGP 경로를 IS-IS로 보급하기 위한 내보내기 정책은 정책 구성 단계에서 표시됩니다.

  4. lo0 도달 가능성을 위해 R3에 연결된 인터페이스에 대한 OSPF 프로토콜을 구성합니다.

  5. R2와 R4 사이에 및 autonomous-system및 IBGP를 router-id 구성합니다. IS-IS 경로를 BGP로 보급하기 위한 내보내기 정책은 정책 구성 단계에서 표시됩니다.

  6. 이전 단계에서 적용된 BGP 및 IS-IS 내보내기 정책을 구성합니다. 이 export-bgp 정책은 BGP 경로를 IS-IS로 보급하기 위한 내보내기로 프로토콜 IS-IS에 적용되며, export-isis 이 정책은 IS-IS 경로를 BGP로 보급하기 위한 내보내기로 BGP에 적용됩니다. next-hop self 옵션을 사용하면 R2가 R1의 인터페이스 다음 홉 대신 R2를 다음 홉으로 사용하여 BGP에 IS-IS 경로를 알릴 수 있습니다.

  7. R2에서 R4로 IP-IP 동적 터널 Tunnel-01 을 구성합니다. 구성 옵션을 resolution-ribs inet.3 사용하면 inet.3에서 경로 확인이 수행되며 터널을 설정하는 데 필요합니다.

  8. (선택 사항) - R2에서 R4로의 IP-IP 동적 터널 Tunnel-01 에 대한 대체 구성. 를 resolution-ribs inet.3 구성하는 대신 터널 엔드포인트에 대한 경로에 대해 프로토콜 다음 홉 기본 설정보다 낮은 터널 기본 설정을 구성할 수 있습니다. R4에 대한 경로는 OSPF를 사용하여 학습되며 기본 설정은 10이고 터널의 기본 기본 설정은 305입니다. OSPF 기본 설정보다 낮은 터널 기본 설정을 구성하면 터널을 선호하고 설정할 수 있습니다.

  9. R2의 구성 모드에서 을(를) 입력합니다 commit .

R3에 대한 단계별 절차
  1. R3에서 구성 모드로 들어갑니다.

  2. R2 및 R4와 인터페이스 lo0에 연결된 인터페이스를 구성합니다.

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

  4. lo0 도달 가능성을 위해 R2 및 R4에 연결된 인터페이스에 대한 OSPF 프로토콜을 구성합니다.

  5. R3 디바이스의 구성 모드에서 입력합니다 commit .

결과

다음과 같이 디바이스의 아래 구성을 확인하여 구성을 검증합니다:

R2에서 구성을 확인하는 방법은 다음과 같습니다.

user@R2# show interfaces

user@R2# show routing-options

user@R2# show protocols

user@R2# show policy-options

검증

동적 터널 데이터베이스 확인
목적

동적 터널 데이터베이스 정보를 확인하려면 운영 모드 명령을 show dynamic-tunnels database 사용합니다.

작업
의미

출력은 R2(소스)와 R4(192.168.0.41대상) 사이에 IPoIP 터널이 설정되고 R4(192.168.0.21192.168.0.41소스)와 R2(대상) 사이에 또 다른 IPoIP 터널이 설정됨을192.168.0.21 나타냅니다.

inet.3에서 경로 테이블 확인
목적

inet.3 테이블에 생성된 경로를 확인하려면 운영 모드 명령을 show route table inet.3 사용합니다.

작업
의미

출력은 터널을 사용할 BGP 트래픽을 해결하는 데 사용되는 경로를 나타냅니다.

터널을 사용하여 BGP 경로 확인
목적

R1 및 R5에 대해 R2 및 R4에서 수신된 BGP 경로가 터널을 사용하고 있는지 확인합니다.

작업
의미

출력은 R2가 R5에 대한 BGP 경로에 터널을 사용하고 R4가 R1에 대한 BGP 경로에 터널을 사용하고 있음을 나타냅니다.

엔드 투 엔드 연결성 확인
목적

운영 모드 명령을 사용하여 R1이 R5를 ping할 ping 192.168.255.5 source 192.168.255.1 count 2 수 있는지 확인합니다.

작업
의미

R1의 출력은 R1이 R5를 ping할 수 있음을 보여줍니다.

예: 정적 구성을 사용하여 inetcolor.0을 통해 해결되는 LDP 터널이 있는 MPLS 환경에서 IPoIP 터널 구성

기본적으로 MPLS는 IP보다 더 높은 선호도를 갖습니다. 예를 들어, R2, R3 및 R4 사이에 구성된 MPLS 및 LDP의 경우, 여기서 R2는 LDP를 통해 R4로 연결할 수 있으며, R2의 경로는 더 높은 선호도로 인해 IP-over-IP 대신 LDP를 통해 확인됩니다.

LDP 대신 IP-over-IP를 통해 특정 경로를 해결하려는 경우 IP-over-IP가 더 높은 기본 설정을 갖는 inetcolor 테이블을 생성하고 inet3 테이블 대신 inetcolor 테이블을 통해 해당 경로를 확인하도록 BGP를 설정하여 이 작업을 수행할 수 있습니다. 다음 예제에서는 정적 구성을 사용하여 이 작업을 수행하는 방법을 보여 줍니다.

토폴로지

이 예에서는 R2와 R4 사이에 설정된 IP-over-IP 동적 터널을 통해 R1에서 R5로 또는 그 반대로 경로를 교환합니다. 프로토콜 IS-IS를 사용하여 R1의 경로는 R2로 내보내고 R5의 경로는 R4로 내보냅니다. R2에서 R4로 유니캐스트 IPIP 터널 Tunnel-01 을 구성하고 R4에서 R2로 또 다른 터널 Tunnel-01 을 구성합니다. 피어 디바이스의 구성된 대상 네트워크의 네트워크 마스크 내에서 생성된 경로 접두사는 터널을 생성하는 데 사용되며 터널의 경로와 반대 방향으로 트래픽이 흐릅니다.

CLI 빠른 구성

R1

R2

R3

R4

R5

절차

R1에 대한 단계별 절차

R1 및 R5는 구성이 유사하므로 R1에 대한 단계별 절차만 보여줍니다.

  1. R1에서 구성 모드로 들어갑니다.

  2. R2 및 인터페이스 lo0에 연결된 인터페이스를 구성합니다. family inetiso를 모두 구성해야 합니다. 프로토콜 IS-IS에는 패밀리 iso 가 필요합니다.

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

  4. 프로토콜 IS-IS를 구성합니다. 경로는 IS-IS 프로토콜을 사용하여 R1과 R2 사이에 보급됩니다.

  5. 구성 모드에서 R1에 진입 commit 합니다.

R2에 대한 단계별 절차

R2 및 R4는 구성이 유사하므로 R2에 대한 단계별 절차만 보여드리겠습니다.

  1. R2에서 구성 모드를 시작합니다.

  2. R1 및 R3과 인터페이스 lo0에 연결된 인터페이스를 구성합니다. R1 및 lo0에 연결된 인터페이스에서 familyinetiso 를 모두 구성하고, R3에 연결된 인터페이스에서 familyinetmpls 인터페이스를 모두 구성해야 합니다.

  3. R1에 연결된 인터페이스에 대한 프로토콜 IS-IS를 구성합니다. BGP 경로를 IS-IS로 보급하기 위한 내보내기 정책은 정책 구성 단계에서 표시됩니다.

  4. lo0 도달 가능성을 위해 R3에 연결된 인터페이스에 대한 OSPF 프로토콜을 구성합니다.

  5. R3에 연결된 인터페이스에 대한 LDP 및 MPLS 프로토콜을 구성합니다.

  6. 계층 아래에 routing-optionsautonomous-systemrouter-id 구성하고, R2와 R4 사이에 IBGP를 구성합니다. BGP를 사용하여 학습된 경로에 커뮤니티를 추가하는 가져오기 정책과 IS-IS 경로를 BGP로 보급하는 내보내기 정책은 정책 구성 단계에 표시됩니다. inetcolor.0 테이블을 사용하여 해석할 수 있도록 구성에 옵션을 family inet unicast 포함해야 extended-nexthop-color 합니다.

  7. R2에서 R4로 IP-IP 동적 터널 Tunnel-01 을 구성합니다. colors 구성 옵션을 사용하면 inetcolor.0 경로 테이블에 터널을 만들 수 있습니다. dyn-tunnel-attribute-policy set-dynamic-tunnel-ep 정적 터널 끝점을 구성합니다. 정책은 정책 구성 단계와 함께 표시됩니다.

  8. 이전 구성 단계에서 적용된 정책을 구성합니다. 이 export-bgp 정책은 BGP 경로를 IS-IS에 보급합니다. 이 정책은 다음 홉을 export-isis R2로 변경하여 IS-IS 경로를 BGP로 보급합니다. 이 ipip-tunnel-color 정책은 동적 터널의 구성에서 colors 일치하는 경로에 커뮤니티를 적용합니다. 이 set-dynamic-tunnel-ep 정책은 R4를 터널 엔드포인트로 구성합니다.

  9. 구성 모드에서 commit을(를) 입력합니다.

R3에 대한 단계별 절차
  1. R3에서 구성 모드로 들어갑니다.

  2. R2 및 R4와 인터페이스 lo0에 연결된 인터페이스를 구성합니다. R2 및 R4에 연결된 인터페이스에서 제품군 inetmpls 인터페이스를 모두 구성해야 합니다.

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

  4. lo0 도달 가능성을 위해 R2 및 R4에 연결된 인터페이스에 대한 OSPF 프로토콜을 구성합니다.

  5. R2 및 R4에 연결된 인터페이스에 대한 LDP 및 MPLS 프로토콜을 구성합니다.

  6. R3 디바이스의 구성 모드에서 입력합니다 commit .

결과

디바이스에서 아래 구성을 확인하여 구성을 확인합니다.

R2에서 구성을 확인하는 방법은 다음과 같습니다.

user@R2# show interfaces

user@R2# show protocols

user@R2#show routing-options

user@R2#show policy-options

검증

경로 확인 확인
목적

inet.3 및 inetcolor.0 테이블 모두에서 경로의 경로 확인을 확인하려면 및 show route table inetcolor.0 작동 모드 명령을 사용합니다show route table inet.3.

작업
의미

R2 출력은 inet.3 테이블에서 10.1.255.4 경로가 IP-over-IP보다 더 높은 선호도 때문에 LDP에 의해 확인되고 있음을 나타냅니다. 반면, 새로 생성된 inetcolor.0 테이블에서는 연결된 IP-over-IP 터널을 통해 경로가 10.1.255.4 확인되고 있습니다 <c> .

동적 터널 데이터베이스 확인
목적

inetcolor.0 테이블의 경로에 의해 생성된 IP-over-IP 동적 터널을 확인하려면 운영 모드 명령을 show dynamic-tunnels database terse 사용합니다.

작업
의미

R2 출력은 경로가 192.168.0.41 다음 홉 기반 동적 터널을 생성했음을 나타냅니다.

경로 다음 홉 확인
목적

IP-over-IP를 통해 확인하도록 설정된 경로의 모든 다음 홉을 확인하려면 운영 모드 명령을 show route 192.168.255.5 extensive expanded-nh 사용합니다.

작업
의미

R2의 출력은 경로에 대한 확장된 다음 홉을 192.168.255.5 보여줍니다. R2는 MX 시리즈 라우터이므로 프로토콜 다음 홉과 간접 다음 홉을 전송합니다.

엔드 투 엔드 연결성 확인
목적

운영 모드 명령을 사용하여 R1이 R5를 ping할 ping 192.168.255.5 source 192.168.255.1 count 2 수 있는지 확인합니다.

작업
의미

R1의 출력은 R1이 R5를 ping할 수 있음을 보여줍니다.

예: MPLS 클라우드에서 LDP 터널이 있는 IPoIP 터널 구성, inetcolor.0을 통해 해결됨 BGP 신호 사용

LDP가 활성화된 MPLS 환경에서는 MPLS가 IP보다 선호도가 높기 때문에 BGP 경로가 inet.3 테이블의 LDP를 통해 확인됩니다.

MPLS 환경에서 IP-over-IP를 통해 경로를 확인하려는 경우, IP-over-IP에 대해 더 높은 선호도를 할당하고 IP-over-IP를 통해 선택한 경로를 확인하는 inetcolor.0 테이블을 생성하면 됩니다. BGP를 사용하여 이 기능을 활성화하기 위해 터널의 원격 엔드 디바이스에서 경로 확인이 수행되고 원격 디바이스에 구성된 내보내기 정책을 사용하여 BGP 신호를 통해 경로가 수신 및 보급됩니다. 이 예에서는 BGP 프로토콜 구성을 사용하여 이를 구성하는 방법을 보여줍니다.

이 예에서는 R2와 R4 사이에 설정된 IP-over-IP 동적 터널을 통해 R1에서 R5로 또는 그 반대로 경로를 교환합니다. 프로토콜 IS-IS를 사용하여 R1의 경로는 R2로 내보내고 R5의 경로는 R4로 내보냅니다. R2에서 R4로 유니캐스트 IPIP 터널 Tunnel-01 을 구성하고 R4에서 R2로 또 다른 터널 Tunnel-01 을 구성합니다. 피어 디바이스의 구성된 대상 네트워크의 네트워크 마스크 내에서 생성된 경로 접두사는 터널을 생성하는 데 사용되며 터널의 경로와 반대 방향으로 트래픽이 흐릅니다.

CLI 빠른 구성

R1

R2

R3

R4

R5

절차

R1에 대한 단계별 절차

R1 및 R5는 구성이 유사하므로 R1에 대한 단계별 절차만 보여줍니다.

  1. R1에서 구성 모드로 들어갑니다.

  2. R2 및 인터페이스 lo0에 연결된 인터페이스를 구성합니다. family inetiso를 모두 구성해야 합니다. 프로토콜 IS-IS에는 패밀리 iso 가 필요합니다.

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

  4. 프로토콜 IS-IS를 구성합니다. 경로는 IS-IS 프로토콜을 사용하여 R1과 R2 사이에 보급됩니다.

  5. 구성 모드에서 R1에 진입 commit 합니다.

R2에 대한 단계별 절차

R2 및 R4는 구성이 유사하므로 R2에 대한 단계별 절차만 보여드리겠습니다.

  1. R2에서 구성 모드를 시작합니다.

  2. R1 및 R3과 인터페이스 lo0에 연결된 인터페이스를 구성합니다. R1 및 lo0에 연결된 인터페이스에서 familyinetiso 를 모두 구성하고, R3에 연결된 인터페이스에서 familyinetmpls 인터페이스를 모두 구성해야 합니다.

  3. R1에 연결된 인터페이스에 대한 프로토콜 IS-IS를 구성합니다. BGP 경로를 IS-IS로 보급하기 위한 내보내기 정책은 정책 구성 단계에서 표시됩니다.

  4. lo0 도달 가능성을 위해 R3에 연결된 인터페이스에 대한 OSPF 프로토콜을 구성합니다.

  5. R3에 연결된 인터페이스에 대한 LDP 및 MPLS 프로토콜을 구성합니다.

  6. 계층 아래에 routing-optionsautonomous-systemrouter-id 구성하고, R2와 R4 사이에 IBGP를 구성합니다. BGP를 사용하여 학습된 경로에 커뮤니티를 추가하는 가져오기 정책과 IS-IS 경로를 BGP에 광고하고 터널 속성을 설정하는 내보내기 정책은 정책 구성 단계에 표시됩니다. inetcolor.0 테이블을 사용하여 해석할 수 있도록 구성에 옵션을 family inet unicast 포함해야 extended-nexthop-tunnel 합니다.

  7. R2에서 라우팅 옵션을 구성하여 R2에서 R4로 터널을 생성합니다. 이 bgp-signal 옵션을 사용하면 BGP에서 신호를 보내는 터널 생성을 수행할 수 있습니다. colors 구성 옵션을 사용하면 inetcolor.0 경로 테이블에 터널을 만들 수 있습니다.

  8. 이전 구성 단계에서 적용된 정책을 구성합니다. 이 export-bgp 정책은 BGP 경로를 IS-IS에 보급합니다. 이 export-tunnel-route 정책은 R1에서 BGP tunnel-attribute 로 IS-IS 경로를 광고하고 다음 홉을 R2로 변경합니다. 은tunnel-attr-01 tunnel-attribute(는) , 터널 끝점 및 동적 터널의 구성에서 colors 일치하는 색상을 설정합니다tunnel-type.

  9. 구성 모드에서 commit을(를) 입력합니다.

R3에 대한 단계별 절차
  1. R3에서 구성 모드로 들어갑니다.

  2. R2 및 R4와 인터페이스 lo0에 연결된 인터페이스를 구성합니다. R2 및 R4에 연결된 인터페이스에서 제품군 inetmpls 인터페이스를 모두 구성해야 합니다.

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

  4. lo0 도달 가능성을 위해 R2 및 R4에 연결된 인터페이스에 대한 OSPF 프로토콜을 구성합니다.

  5. R2 및 R4에 연결된 인터페이스에 대한 LDP 및 MPLS 프로토콜을 구성합니다.

  6. R3 디바이스의 구성 모드에서 입력합니다 commit .

결과

구성 모드에서 다음 show 명령을 사용하여 구성을 확인할 수 있습니다.

R2 디바이스에서 구성을 확인하는 방법은 다음과 같습니다.

user@R2# show interfaces

user@R2# show protocols

user@R2# show routing-options

user@R2# show policy-options

검증

BGP 경로 확인

목적

BGP 프로토콜을 사용하여 전송된 경로를 확인합니다.

작업

R2

의미

출력에는 BGP의 경로가 표시됩니다.

수신 경로 확인

목적

다음 운영 모드 명령을 사용하여 BGP를 통해 수신된 경로를 확인합니다.

작업

R2

의미

R2 출력은 디바이스에서 수신된 경로를 나타냅니다.

동적 터널 확인

목적

동적 터널이 작동 중이고 BGP 신호가 전송되었는지 확인합니다.

작업

R2

의미

R2 출력은 터널이 작동 중이고 BGP 신호가 전송되었음을 나타냅니다.

경로 확인 확인

목적

inetcolor.0 테이블에 있는 경로의 경로 확인을 확인하려면 운영 모드 명령을 show route table inetcolor.0 사용합니다.

작업
의미

R2 출력은 에 대한 터널 10.1.255.4 이 BGP 신호를 받았음을 나타냅니다.

엔드 투 엔드 연결성 확인

목적

운영 모드 명령을 사용하여 R1이 R5를 ping할 ping 192.168.255.5 source 192.168.255.1 count 2 수 있는지 확인합니다.

작업
의미

R1의 출력은 R1이 R5를 ping할 수 있음을 보여줍니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

릴리스
설명
19.2R1
Junos 릴리스 19.2R1부터 MPC 및 MIC가 있는 MX 시리즈 라우터에서 지원 서비스 프로바이더의 PE 디바이스 간에 설정된 동적 IPv4 UDP 터널을 통해 MPLS 트래픽을 전송하는 MPLS-over-UDP 터널을 통해 CSC(Carrier Support Carrier) 아키텍처를 구축할 수 있습니다.
18.3R1
Junos OS 릴리스 18.3R1부터 PTX 시리즈 라우터 및 QFX 시리즈 스위치에서 MPLS-over-UDP 터널이 지원됩니다.
18.2R1
Junos OS 릴리스 18.2R1부터 단방향 MPLS-over-UDP 터널이 있는 PTX 시리즈 라우터 및 QFX10000에서 MPLS-over-UDP 패킷에 대한 입력 필터와 역방향 터널 방향으로 패킷을 전달하기 위한 IP 및 UDP 헤더의 캡슐화 해제 작업으로 원격 PE 디바이스를 구성해야 합니다.
17.4R1
Junos OS 릴리스 17.4R1부터 MX 시리즈 라우터에서 다음 홉 기반 동적 MPLS-over-UDP 터널은 BGP 캡슐화 확장 커뮤니티를 사용하여 시그널링됩니다.
17.1R1
Junos OS 릴리스 17.1부터 MPC 및 MIC가 있는 MX 시리즈 라우터에서 MPLS-over-UDP 터널의 확장 제한이 증가합니다.