Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

정적 경로 기본 설정 및 적격 다음 홉

정적 경로 기본 설정 및 적격 다음 홉 이해

정적 경로 대상 주소는 여러 개의 다음 홉을 연결할 수 있습니다. 이 경우 여러 경로가 라우팅 테이블 삽입되며 경로 선택이 반드시 발생해야 합니다. 경로 선택을 위한 기본 기준은 경로 선호이므로 특정 다음 홉과 연관된 경로 선호를 설정하여 특정 목적지의 기본 경로로 사용되는 경로를 제어할 수 있습니다. 경로 선호가 낮은 경로는 항상 트래픽을 라우팅하는 데 사용됩니다. 기본 경로를 설정하지 않으면 Junos OS 포워딩 테이블 설치할 다음 홉 주소 중 하나를 무작위로 선택합니다.

일반적으로 정적 경로에 할당된 기본 속성은 정적 경로에 대해 구성된 모든 다음 홉 주소에 적용됩니다. 그러나 특정 경로에 대해 가능한 두 개의 다음 홉 주소를 구성하고 해당 주소가 다르게 처리되도록 하려면 하나를 자격을 갖춘 다음 홉으로 정의할 수 있습니다.

자격을 갖춘 다음 홉을 사용하면 하나 이상의 속성을 특정 다음 홉 주소와 연결할 수 있습니다. 특정 정적 경로에 대한 전반적인 기본 설정을 설정한 다음 자격을 갖춘 다음 홉에 대해 다른 기본 설정을 지정할 수 있습니다. 예를 들어, 두 개의 다음 홉 주소(10.10.10.10 및 10.10.10.7)가 정적 경로 192.168.47.5/32와 연결되어 있다고 가정합니다. 일반적인 기본 설정은 전체 정적 경로에 할당되며, 자격을 갖춘 다음 홉 주소 10.10.10.7에만 다른 기본 설정이 할당됩니다. 예를 들어:

이 예에서는 자격을 갖춘 다음 홉 10.10.10.7에 기본 설정 6이 할당되고 다음 홉 10.10.10.10에 선호 5가 할당됩니다.

참고:

preference] 계층의 [edit route route qualified-next-hopmetric 옵션은 자격을 갖춘 다음 홉에만 적용됩니다. 자격을 갖춘 다음 홉 선호 및 메트릭은 경로 선호가 기본 선호 및 메트릭(해당 특정 경로에 대한)을 재정의하는 방법과 유사하게 해당 특정 자격을 갖춘 다음 홉에 대한 경로 선호와 메트릭을 재정의합니다.

참고:

릴리스 15.1R4 Junos OS 시작하여, 라우터는 더 이상 정적 경로가 가입자와 연결된 다음 홉을 가리키는 구성을 지원하지 않습니다. 일반적으로 RADIUS framed-IP-Address 속성으로 다음 홉을 할당할 때 발생할 수 있습니다. 이 잘못된 구성의 대안은 RADIUS 서버가 정적 경로와 일치하는 Framed-Route 속성을 제공하도록 하는 것입니다.

예: 정적 경로 선호도 구성 및 정규화된 다음 홉을 구성하여 정적 경로 선택을 제어합니다.

이 예는 정적 경로 선택을 제어하는 방법을 보여줍니다.

요구 사항

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

개요

이 예에서 정적 경로 192.168.47.0/24에는 두 개의 가능한 다음 홉이 있습니다. 하나의 링크에 더 높은 대역폭이 있으므로 이 링크가 선호되는 경로입니다. 이 기본 설정을 qualified-next-hop 적용하기 위해 문은 두 디바이스의 구성에 포함됩니다. 그림 1을 참조하십시오.

그림 1: 정적 경로 선택 Controlling Static Route Selection 제어

토폴로지

구성

절차

CLI 빠른 구성

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

프로바이더는 디바이스 B를 통해

고객 네트워크의 디바이스 D

단계별 절차

다음 예제에서는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 이를 수행하는 방법에 대한 지침은 Junos OS CLI 사용자 가이드구성 모드에서 CLI 편집기 사용을 참조하십시오.

정적 경로 선택을 제어하려면,

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

  2. 디바이스 B에서 고객 네트워크에 대한 정적 경로를 구성합니다.

  3. 디바이스 B에서 고객 네트워크에 대한 백업 경로를 구성합니다.

  4. 디바이스 D에서 인터페이스를 구성합니다.

  5. 디바이스 D에서 외부 네트워크에 대한 정적 기본 경로를 구성합니다.

  6. 디바이스 D에서 외부 네트워크에 대한 백업 정적 기본 경로를 구성합니다.

결과

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

디바이스 구성이 완료되면 두 디바이스의 구성 모드에서 커밋 을 입력합니다.

확인

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

라우팅 테이블 확인하기

목적

디바이스 B 및 디바이스 D의 라우팅 테이블에 정적 경로가 나타나는지 확인합니다.

작업
의미

라우팅 테이블의 별표(*)는 활성 경로를 표시합니다. 백업 경로는 다음에 나열됩니다.

원격 주소 Ping

목적

정적 경로가 작동하는지 확인합니다.

디바이스 B에서 디바이스 D의 루프백 인터페이스 주소 중 하나를 ping합니다.

디바이스 D에서 디바이스 B의 루프백 인터페이스 주소 중 하나를 ping합니다.

작업

백업 경로가 활성 경로가 되는지 확인

목적

기본 경로를 사용할 수 없게 되면 백업 보조 경로가 활성화되는지 확인합니다.

작업
  1. 디바이스 B에서 ge-1/2/0.0 인터페이스를 비활성화하여 활성 경로를 비활성화합니다.

  2. 디바이스 B의 라우팅 테이블 확인합니다.

의미

백업 경로가 활성 경로가 되었습니다.

정적 경로를 사용하여 IP 주소 보존

호스팅 프로바이더는 여러 고객을 위해 여러 서버를 호스팅하고 IP 주소 공간의 사용을 보존하고자 합니다. 일반적으로 호스팅 프로바이더 클라이언트가 새 서버를 추가하면 서버는 /29 블록과 같은 작은 IP 주소 블록을 할당하고 클라이언트 서버는 모두 해당 IP 주소 블록에 위치합니다.

그림으로 표시된 문제

예를 들어, 고객 A에는 3개의 서버가 필요할 수 있으며 블록 10.3.3.0/29(10.3.3.0~10.3.3.7)가 할당됩니다. 이 시나리오에서는 여러 IP 주소가 소비됩니다. 여기에는 네트워크 및 브로드캐스트 IP 주소(10.3.3.0 및 10.3.3.7), 서버가 연결된 라우터 게이트웨이의 주소 및 개별 서버의 주소가 포함됩니다. 서버 3개를 할당하려면 8개의 IP 주소를 할당해야 합니다. 단일/24 네트워크를 32/29 네트워크로 나누면 256개 중 96개의 IP 주소가 네트워크, 브로드캐스트 및 게이트웨이 주소에서 소비됩니다. 이러한 효과가 수천 개의 호스팅 프로바이더에 걸쳐 늘어나면 IP 주소 공간은 효율적으로 사용되는 데 그다지 큰 영향을 미치지 않습니다. 그림 2 는 문제를 보여줍니다.

그림 2: 비효율적인 IP 주소 공간 Inefficient Use of IP Address Space 사용

이 구성에서 각 고객은 /29 블록의 주소 공간을 할당합니다. 각 블록에 대해 네트워크, 브로드캐스트 및 게이트웨이 주소는 서버 IP 주소 지정에 사용할 수 없 않으므로 세 개의 IP 주소가 비효율적으로 사용됩니다. 또한 블록은 향후 확장을 위해 사용되지 않는 IP 주소를 소비합니다.

솔루션

이 문제는 공유 주소 공간(RFC 6598)을 위해 예약된 IPv4 접두사의 주소를 라우터에서 인터페이스를 구성하고 인터페이스를 가리키는 정적 경로를 사용하여 해결할 수 있습니다. IANA는 공유 주소 공간으로 사용하기 위한 IPv4/10 할당을 기록했습니다. 공유 주소 공간 주소 범위는 100.64.0.0/10입니다.

라우터의 인터페이스는 RFC 6598 공간에서 IP 주소를 할당하므로 공개적으로 라우팅 가능한 주소 공간을 소비하지 않으며 인터페이스의 정적 경로로 연결이 처리됩니다. 서버의 인터페이스는 공개적으로 라우팅 가능한 주소로 구성되지만 라우터 인터페이스는 구성되지 않습니다. 네트워크 및 브로드캐스트 주소는 공개적으로 라우팅 가능한 주소 공간이 아닌 RFC 6598 공간에서 소비됩니다.

이 기능은 Junos OS 17.1R1로 시작하는 QFX10000 스위치에서 지원됩니다.

그림 3 은 IP 주소 공간의 효율적인 사용을 보여줍니다.

그림 3: 공유 주소 공간을 Configuration Using the Shared Address Space 사용한 구성

이 구성에서 각 고객은 서버당 개별 IP 주소를 할당됩니다. 호스트 경로로 구성할 수 있는 정적 경로가 있습니다. 라우터의 인터페이스는 RFC 6598 공간에서 IP 주소를 할당하므로 공개적으로 라우팅 가능한 주소 공간을 소비하지 않으며 인터페이스에 대한 정적 경로로 연결이 처리됩니다.

구성

구성은 게이트웨이 라우터의 고객 A에 대해 다음과 같이 표시됩니다.

이러한 구성으로 공개적으로 라우팅 가능한 IP 주소가 낭비되지 않습니다. 이 구성에서 패킷이 라우터에서 고객 A 서버 203.0.113.10의 서버로 전달되면, 경로는 의 IP 주소를 100.64.0.1가진 인터페이스 ge-1/0/1.0으로 전달됩니다.

고객 A의 서버는 다음과 같이 구성됩니다.

이 예는 1:1 매핑인 서버당 단일 호스트 경로를 보여줍니다. 유지하면 많은 수의 정적 호스트 경로와 동일할 수 있습니다. 확장을 위해 이 환경에서는 비호스트 경로를 지원해야 합니다. 예를 들어, 이 구성에 서버 8개가 있는 고객 C가 있는 경우, 8개의 서버가 연결된 인터페이스를 지적하는 라우터에 /29 경로를 할당하는 것이 훨씬 더 효율적입니다. 고객 C가 203.0.114.8부터 203.0.114.15까지 서버 IP를 할당하고 인터페이스 ge-1/0/2.0을 통해 연결된 경우 다음과 같습니다.

라우팅 및 포워딩 테이블의 정적 경로 제어 이해

여러 방법으로 라우팅 및 포워딩 테이블로 정적 경로 가져오기를 제어할 수 있습니다. 주요 방법은 경로에 다음 속성 중 하나 이상을 할당하는 것을 포함합니다.

  • retain - 라우팅 프로세스가 종료되거나 디바이스가 재부팅된 후 경로를 포워딩 테이블 유지합니다.

  • no-readvertise — 경로가 다른 라우팅 프로토콜로 재보급되는 것을 방지합니다.

  • passive - 경로로 향하는 트래픽을 거부합니다.

이 주제에는 다음 섹션이 포함됩니다.

경로 유지

기본적으로 정적 경로는 라우팅 프로세스가 종료될 때 포워딩 테이블 유지되지 않습니다. 라우팅 프로세스가 다시 시작되면 정적 경로로 구성된 모든 경로를 포워딩 테이블 다시 추가해야 합니다. 이 지연을 피하기 위해 경로는 유지되는 것으로 플래그를 지정하여 라우팅 프로세스가 종료된 후에도 포워딩 테이블 유지됩니다. 유지를 통해 시스템 재부팅 직후에도 경로가 항상 포워딩 테이블 유지됩니다.

재버전 방지

정적 경로는 기본적으로 다른 라우팅 프로토콜에 의해 재 보급할 수 있습니다. 어떤 상황에서도 이러한 정적 경로를 재보급하지 않을 수 있는 스텁 영역에서 정적 경로를 재보급되지 않는 것으로 플래그 지정하실 수 있습니다.

수동 경로 트래픽 강제 거부

일반적으로 라우팅 및 포워딩 테이블에는 활성 경로만 포함됩니다. 정적 경로의 다음 홉 주소가 도달할 수 없는 경우 경로는 패시브로 표시되며 라우팅 또는 포워딩 테이블에 포함되지 않습니다. 다음 홉 도달 가능성과 관계없이 라우팅 테이블에 경로를 포함하도록 하려면 경로를 패시브로 플래그 지정하실 수 있습니다. 경로에 패시브 플래그가 지정되고 다음 홉 주소가 도달할 수 없는 경우, 경로가 라우팅 테이블 포함되고 경로로 향하는 모든 트래픽이 거부됩니다.

예: 정적 경로가 재보증되지 않도록 방지

이 예는 정적 경로가 OSPF로 다시 보급되는 것을 방지하여 라우팅 및 포워딩 테이블에 경로가 나타나지 않도록 하는 방법을 보여줍니다.

요구 사항

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

개요

이 예는 명령문으로 no-readvertise 태그 처리되어 재보증되지 않는 하나의 정적 경로를 제외하고 정적 경로를 OSPF로 다시 보급하는 라우팅 정책 구성하는 방법을 보여줍니다.

토폴로지

그림 4 는 샘플 네트워크를 보여줍니다.

그림 4: 서비스 프로바이더 Customer Routes Connected to a Service Provider 연결된 고객 경로

구성

절차

CLI 빠른 구성

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

디바이스 A

디바이스 B

디바이스 C

단계별 절차

다음 예제에서는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 이를 수행하는 방법에 대한 지침은 Junos OS CLI 사용자 가이드구성 모드에서 CLI 편집기 사용을 참조하십시오.

디바이스 A 구성:

  1. 디바이스 B에 대한 인터페이스를 구성합니다.

  2. OSPF를 구성하여 디바이스 B와 OSPF 피어 관계를 형성합니다.

단계별 절차

디바이스 B 구성:

  1. 디바이스 A 및 디바이스 C에 대한 인터페이스를 구성합니다.

  2. 하나 이상의 정적 경로와 AS(Autonomous System) 번호를 구성합니다.

  3. 라우팅 정책 구성합니다.

    이 정책은 라우팅 테이블 정적 경로를 OSPF로 내보냅니다.

  4. no-readvertise 192.168.0.0/24 경로가 OSPF로 내보내지는 것을 방지하기 위해 문을 포함합니다.

  5. 라우팅 프로토콜을 구성합니다.

    BGP 구성은 디바이스 C와 외부 BGP(EBGP) 피어 관계를 형성합니다.

    OSPF 구성은 디바이스 A와 OSPF 피어 관계를 형성하고 송신 정적 라우팅 정책 적용합니다.

단계별 절차

디바이스 C 구성:

  1. 디바이스 B에 대한 인터페이스를 생성하고 루프백 인터페이스를 구성합니다.

  2. 디바이스 B와 함께 EBGP 피어링 세션을 구성합니다.

  3. AS 번호를 구성합니다.

결과

, , show policy-optionsshow protocolsshow routing-options 명령을 실행하여 구성을 show interfaces확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.

디바이스 A

디바이스 B

디바이스 C

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

확인

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

라우팅 테이블 확인

목적

문이 작동하는지 확인 no-readvertise 합니다.

작업
  1. 디바이스 A에서 명령을 실행 show route protocol ospf 하여 192.168.0.0/24 경로가 디바이스 A의 라우팅 테이블 나타나지 않도록 합니다.

  2. 디바이스 B에서 문을 비활성화합니다 no-readvertise .

  3. 디바이스 A에서 명령을 다시 실행 show route protocol ospf 하여 192.168.0.0/24 경로가 디바이스 A의 라우팅 테이블 나타나는지 확인합니다.

의미

no-readvertise 문이 예상대로 작동하고 있습니다.

정적 경로 구성 확인

목적

정적 경로가 라우팅 테이블 중이고 해당 경로가 활성화되어 있는지 확인합니다.

작업

CLI에서 명령을 입력합니다 show route terse .

샘플 출력

명령명

의미

출력에는 현재 inet.0 라우팅 테이블 있는 경로 목록이 표시됩니다. 다음 정보를 확인합니다.

  • 구성된 각 정적 경로가 존재합니다. 경로는 IP 주소별로 오름차순으로 나열됩니다. 정적 경로는 출력의 프로토콜(P) 열에서 S로 식별됩니다.

  • 각 정적 경로가 활성화됩니다. 활성 경로는 다음 홉 열에 다음 IP 주소를 표시합니다. 경로의 다음 홉 주소가 도달할 수 없는 경우, 다음 홉 주소는 거부(Reject)로 식별됩니다. 이러한 경로는 활성 경로가 아니지만 패시브 속성이 설정되어 있기 때문에 라우팅 테이블 나타납니다.

  • 각 정적 경로에 대한 선호가 정확합니다. 특정 경로에 대한 기본 설정은 출력의 Prf 열에 나열되어 있습니다.

릴리스 기록 테이블
릴리스
설명
17.1R1
이 기능은 Junos OS 17.1R1로 시작하는 QFX10000 스위치에서 지원됩니다.