Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP 오리진 검증

BGP에 대한 오리진 검증 이해

출처 확인은 의도하지 않은 경로 보급을 방지하는 데 도움이 됩니다. 네트워크 관리자가 자신이 제어하지 않는 네트워크에 대한 경로를 잘못 보급하는 경우가 있습니다. 이 보안 문제는 원본 검증(보안 도메인 간 라우팅이라고도 함)을 구성하여 해결할 수 있습니다. 오리진 검증은 경로 보급이 예상 자율 시스템(AS)에서 시작되는 것으로 인증될 수 있는 메커니즘입니다. 오리진 검증은 하나 이상의 리소스 공개 키 인프라(RPKI) 캐시 서버를 사용하여 지정된 BGP 접두사에 대한 인증을 수행합니다. 접두사를 인증하기 위해 라우터(BGP 스피커)는 캐시 서버에서 다운로드한 검증된 접두사-AS 매핑 데이터베이스를 쿼리하고 접두사가 예상 AS에서 유래했는지 확인합니다.

주:

RPKI 인증을 활성화하면 Junos OS는 예고 없이 TCP 포트 2222를 자동으로 엽니다. 필터를 적용하여 이 포트를 차단하고 보호할 수 있습니다.

Junos OS는 IPv4 및 IPv6 접두사에 대한 원본 검증을 지원합니다.

그림 1 에는 샘플 토폴로지가 나와 있습니다.

그림 1: Origin Validation을 위한 샘플 토폴로지Origin Validation을 위한 샘플 토폴로지

지원되는 표준

원본 검증의 Junos OS 구현은 다음 RFC 및 초안을 지원합니다.

  • RFC 6810, 라우터 프로토콜에 대한 리소스 공개 키 인프라(RPKI)

  • RFC 6811, BGP 접두사 Origin Validation

  • 인터넷 초안 draft-ietf-sidr-origin-validation-signaling-00, BGP 접두사 원래 검증 상태 확장 커뮤니티 (부분 지원)

    확장 커뮤니티(원래 검증 상태)는 Junos OS 라우팅 정책에서 지원됩니다. 경로 선택 절차에서 지정된 변경 사항은 지원되지 않습니다.

Origin Validation 작동 방식

RPKI 및 원본 검증은 RFC 3779, IP 주소에 대한 X.509 확장 및 AS 식별자에 지정된 확장자를 가진 X.509 인증서를 사용합니다.

RPKI는 분산된 정보 모음으로 구성됩니다. 각 인증 기관은 EE(최종 엔터티) 인증서, CRL(인증서 해지 목록) 및 서명된 개체를 특정 위치에 게시합니다. 이러한 모든 저장소는 모든 RPKI 캐시 서버에서 사용할 수 있는 완전한 정보 세트를 형성합니다.

각 RPKI 캐시 서버는 로컬 캐시의 각 요소를 원래 리포지토리 게시 지점과 정기적으로 동기화하여 전체 분산 리포지토리 컬렉션의 로컬 캐시를 유지 관리합니다.

라우터에서 데이터베이스 항목은 RV(Route Validation) 레코드 형식으로 지정됩니다. RV 레코드는 (접두사, 최대 길이, 원본 AS) 트리플입니다. 접두사가 RV 접두사와 일치하고, 접두사 길이가 RV 레코드에 지정된 최대 길이를 초과하지 않으며, 원본 AS가 RV 레코드에 지정된 원본 AS와 동일한 모든 경로와 일치합니다.

RV 레코드는 ROA(Route Origin Authorization)의 간소화된 버전입니다. ROA는 IP 주소 블록 보유자가 주소 블록 내의 하나 이상의 접두사에 대한 경로를 시작하도록 AS에 권한을 부여했는지 확인하는 수단을 제공하는 디지털 서명 개체입니다. ROA는 경로 검증에 직접 사용되지 않습니다. 캐시 서버는 간소화된 버전의 ROA를 RV 레코드로 라우터에 내보냅니다.

최대 길이 값은 승인된 접두사의 길이보다 크거나 같아야 하며 주소 패밀리에 있는 IP 주소의 길이(비트 단위)보다 작거나 같아야 합니다(IPv4의 경우 32, IPv6의 경우 128). 최대 길이는 AS가 보급할 수 있는 권한이 부여된 IP 주소 접두사를 정의합니다.

예를 들어, IP 주소 접두사가 200.4.66/24이고 최대 길이가 26인 경우 AS는 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 및 200.4.66.192/26을 보급할 수 있는 권한이 부여됩니다. 최대 길이가 없으면 AS는 RV에 지정된 접두사를 정확히 보급할 수 있는 권한만 부여됩니다.

또 다른 예로, RV는 최대 길이가 26인 접두사 200.4.66/24와 최대 길이가 28인 접두사 200.4.66.0/28을 포함할 수 있습니다. 이 RV는 AS가 길이가 24 이상 26 이하인 200.4.66으로 시작하는 접두사와 특정 접두사 200.4.66.0/28을 광고할 수 있는 권한을 부여합니다.

경로의 원점은 AS_PATH 속성에서 가장 오른쪽에 있는 AS 번호로 표시됩니다. 오리진 검증은 라우팅 업데이트의 오리진 AS를 RV 레코드에 게시된 인증된 소스 AS와 비교하여 작동합니다.

원본 유효성 검사만으로 제공되는 보안은 소스 AS를 스푸핑하는 공격자에 대한 보호 기능이 없기 때문에 확인된 공격자에 대해 취약한 것으로 알려져 있습니다. 즉, 출처 검증은 우발적인 발표에 대한 유용한 보호 기능을 제공합니다.

각 라우터가 RPKI에 직접 참여하도록 하여 원본 검증을 구현할 수 있지만, 이는 RPKI 데이터를 검증하는 데 많은 공개 키 암호화 작업이 필요하기 때문에 리소스 집약적일 뿐만 아니라 각 라우터에서 RPKI 구성을 설정하고 유지하는 데 운영 집약적인 것으로 간주됩니다. 이러한 이유로 별도의 RPKI 캐시 서버가 공개 키 유효성 검사를 수행하고 접두사-AS 매핑의 검증된 데이터베이스를 생성합니다. 검증된 데이터베이스는 보안 TCP 연결을 통해 클라이언트 라우터에 다운로드됩니다. 따라서 라우터는 RPKI 인프라에 대한 정보를 거의 필요로 하지 않으며 암호화된 전송 비밀번호 외에는 공개 키 암호화 요구 사항이 없습니다. 이후 라우터는 다운로드한 데이터를 사용하여 수신된 경로 업데이트의 유효성을 검사합니다.

서버 세션을 구성할 때 세션을 함께 그룹화하고 그룹의 각 세션에 대한 세션 매개 변수를 구성할 수 있습니다. 라우터는 캐시 서버에 대해 구성 가능한 최대 연결 수를 주기적으로 설정하려고 시도합니다. 연결 설정에 실패하면 주기적으로 새 연결이 시도됩니다.

그 동안 검증 가져오기 정책이 BGP 세션에 적용된 후에는 캐시 세션 상태(작동 또는 중단) 및 RV 데이터베이스(비어 있거나 비어 있지 않음)에 관계없이 경로 검증이 수행됩니다. RV 데이터베이스가 비어 있거나 캐시 서버 세션이 작동하지 않는 경우, 수신된 BGP 접두사를 평가할 RV 레코드가 없기 때문에 각 경로의 검증 상태가 알 수 없음으로 설정됩니다.

재시도 기간은 구성할 수 있습니다. 캐시 서버에 성공적으로 연결한 후 라우터는 최신 데이터베이스 일련 번호를 쿼리하고 RPKI 캐시가 해당 버전의 데이터베이스에 속한 모든 RV 항목을 전송하도록 요청합니다.

각 인바운드 메시지는 RPKI 캐시 서버에 대한 활성도 타이머를 재설정합니다. 모든 업데이트가 학습된 후 라우터는 구성 가능한 간격에 따라 주기적인 활성도 검사를 수행합니다. 이 작업은 캐시 서버가 최신 알림 PDU에 보고한 것과 동일한 일련 번호를 가진 직렬 쿼리 프로토콜 데이터 단위(PDU)를 전송하여 수행됩니다. 캐시 서버는 0개 이상의 업데이트와 EOD(데이터 끝) PDU로 응답하며, 이 PDU는 캐시 서버의 활성 상태를 새로 고치고 레코드 수명 타이머를 다시 설정합니다.

외부 BGP(EBGP) 피어에서 접두사를 수신하면 가져오기 정책에 의해 검사되고 유효, 유효하지 않음, 알 수 없음 또는 확인되지 않음으로 표시됩니다.

  • Valid(유효) - 접두사 및 AS 쌍이 데이터베이스에서 발견됨을 나타냅니다.

  • Invalid(유효하지 않음) - 접두사를 찾았지만 EBGP 피어에서 수신한 해당 AS가 데이터베이스에 표시되는 AS가 아니거나 BGP 업데이트 메시지의 접두사 길이가 데이터베이스에서 허용되는 최대 길이보다 길음을 나타냅니다.

  • 알 수 없음 - 접두사가 데이터베이스의 접두사 또는 접두사 범위에 속하지 않음을 나타냅니다.

  • Unverified(확인되지 않음) - 접두사의 원본이 데이터베이스에 대해 확인되지 않았음을 나타냅니다. 이는 원본 검증이 활성화되어 있거나 BGP 피어에 대해 원본 검증이 활성화되어 있지 않지만 데이터베이스가 채워지고 BGP 가져오기 정책에서 검증이 요청되지 않기 때문입니다.

유효성 검사 데이터베이스의 경로에 대해 일치하는 항목이 있는 경우 경로가 유효하려면 그 중 하나와 일치해야 합니다. 그렇지 않으면 유효하지 않습니다. 모든 일치 항목은 경로를 유효하게 만드는 데 적합합니다. 가장 잘 어울리는 것일 필요는 없습니다. 잠재적인 일치 항목이 없는 경우에만 경로가 알 수 없는 것으로 간주됩니다. 접두사-AS 매핑 데이터베이스 로직에 대한 자세한 내용은 인터넷 초안 draft-ietf-sidr-pfx-validate-01, BGP 접두사 오리진 검증의 섹션 2를 참조하십시오.

주:

RPKI 검증은 기본 인스턴스에서만 사용할 수 있습니다. 라우팅 인스턴스에 대해 RPKI 검증을 구성하는 경우, 다음 오류 메시지 와 함께 RPKI 검증이 실패합니다.RV instance is not running

경로 검증 데이터베이스와의 BGP 상호 작용

RV(Route Validation) 데이터베이스에는 라우터가 RPKI 캐시 서버에서 다운로드하는 RV 레코드 컬렉션이 포함되어 있습니다. RV 데이터베이스가 RV 레코드로 채워지면 RV 데이터베이스는 RIB-Local 라우팅 테이블을 스캔하여 데이터베이스의 RV 레코드의 영향을 받을 수 있는 RIB-Local의 접두사가 있는지 확인합니다. (RIB-Local에는 명령의 출력에 표시된 IPv4 및 IPv6 경로가 포함되어 있습니다.)show route protocol bgp

이 프로세스는 BGP 가져오기 정책(내보내기 정책 아님)의 BGP 재평가를 트리거합니다.

그림 2 프로세스를 보여줍니다.

그림 2: BGP 및 경로 검증

가져오기 정책은 RIB-In에 적용됩니다. 이를 이해하는 또 다른 방법은 가져오기 정책은 명령의 출력에 표시된 경로에 적용되고, 내보내기 정책은 명령에 의해 표시된 경로에 적용된다는 것입니다.show route receive-protocol bgpshow route advertising-protocol bgp

에 표시된 대로 라우팅 정책 가져오기를 사용하여 라우팅 테이블에 BGP가 배치하는 경로를 제어하고, 라우팅 정책을 내보내 BGP가 라우팅 테이블에서 인접 라우터로 광고하는 경로를 제어합니다.그림 3

그림 3: 라우팅 정책 가져오기 및 내보내기라우팅 정책 가져오기 및 내보내기

경로 유효성 검사 가져오기 정책을 구성할 때 정책 구성은 일치 조건을 사용합니다 .validation-database 이 일치 조건은 RV 데이터베이스에서 지정된 라우팅 인스턴스에서 접두사의 검증 상태에 대한 쿼리를 트리거합니다. 기본 작업은 라우팅 인스턴스와 일치하는 검증 데이터베이스를 쿼리하는 것입니다. 경로 유효성 검사 인스턴스를 찾을 수 없는 경우 기본 인스턴스를 쿼리합니다.

다음 BGP 가져오기 정책 에서 조건은 라우터의 RV 데이터베이스에서 조회를 트리거합니다.from validation-database 유효성 검사 상태가 유효한 경우 작업이 수행됩니다. 작업은 경로를 수락하고 라우팅 테이블의 을( 를) 유효하게 설정하는 것입니다.validation-state

IBGP 이웃에 RPKI 검증 상태를 알리기 위한 커뮤니티 속성

접두사 검증은 외부 BGP(EBGP) 업데이트에 대해서만 수행됩니다. AS 내에서는 모든 내부 BGP(IBGP) 라우터에서 RPKI 세션을 실행하지 않을 수 있습니다. 대신, 모든 IBGP 발표자가 일관된 정보를 가질 수 있도록 IBGP 메시 전체에 검증 상태를 전달하는 방법이 필요합니다. 이는 비전이적 확장 커뮤니티에서 유효성 검사 상태를 전달하여 수행됩니다. 커뮤니티 속성은 IBGP neighbor 간 접두사의 검증 상태를 발표하고 수신합니다.

Junos OS는 경로 검증을 위해 다음과 같은 잘 알려진 확장 커뮤니티를 지원합니다.

  • 오리진-검증-상태-유효

  • 오리진-검증-상태-유효하지 않음

  • 원본 유효성 검사 상태 알 수 없음

다음 샘플 BGP 가져오기 정책은 RPKI 서버와의 세션이 있는 라우터에서 구성됩니다.

RPKI 세션이 있는 라우터

다음 샘플 BGP 가져오기 정책은 RPKI 서버와의 세션이 없는 IBGP 피어 라우터에서 구성됩니다.

RPKI 세션이 없는 IBGP 피어 라우터

논스톱 액티브 라우팅 및 오리진 검증

이중 라우팅 엔진이 있고 무중단 활성 라우팅이 활성화된 라우터에서 원본 검증을 구성하면 기본 및 대기 라우팅 엔진 모두에 RV 데이터베이스 사본이 있습니다. 이 두 RV 데이터베이스는 서로 동기화된 상태로 유지됩니다.

라우터는 RPKI 서버와 두 개의 동일한 세션을 유지하지 않습니다. RPKI-RTR 프로토콜은 기본 라우팅 엔진에서만 실행됩니다. 대기 라우팅 엔진에서 RPKI 캐시 서버 세션은 항상 중단됩니다.

RV 데이터베이스는 RPKI 서버와의 세션을 통해 기본 라우팅 엔진에 의해 능동적으로 유지 관리됩니다. 이 데이터베이스는 대기 라우팅 엔진에 복제됩니다. 대기 라우팅 엔진에서 세션이 중단되었지만 복제된 RV 데이터베이스에는 RV 레코드가 포함되어 있습니다. 스탠바이 라우팅 엔진이 전환되어 기본 라우팅 엔진이 되면 이미 완전히 채워진 RV 데이터베이스가 있습니다.

두 데이터베이스의 내용을 보려면 및 명령을 사용합니다.show validation databaseshow validation replication database

접두사 범위를 허용되지 않음으로 표시

경로 검증 모델에는 한 가지 주요 단점이 있습니다. 긍정적인 업데이트만 제공합니다. 접두사의 합법적인 소유자인 AS를 선언할 수 있습니다. 그러나 다음과 같이 부정적인 업데이트를 명시적으로 전달할 수는 없습니다. 이 접두사는 지정된 AS에서 유래되지 않습니다. 이 기능은 AS 0 해결 방법을 사용하여 어느 정도 제공될 수 있습니다.

Junos OS 구현은 캐시에서 입력을 제한하려고 시도하지 않습니다. 예를 들어, 원점이 0인 RV 레코드가 다른 레코드와 마찬가지로 설치되고 일치합니다. 이렇게 하면 AS 0이 유효한 AS가 아니므로 접두사 범위를 발표가 허용되지 않는 것으로 표시할 수 있습니다. RV 레코드의 AS는 EBGP 피어에서 수신한 AS와 일치하지 않습니다. 따라서 일치하는 접두사는 유효하지 않은 것으로 표시됩니다.

BGP에 대한 Origin Validation의 사용 사례 및 이점

AS(Autonomous System)의 관리자가 다른 회사에 할당된 네트워크의 전체 또는 일부를 보급하기 시작하면 BGP에는 오류를 인식하고 서비스 중단을 방지하는 방식으로 대응할 수 있는 기본 제공 방법이 없습니다.

예를 들어, 고객 네트워크의 관리자가 실수로 고객의 서비스 프로바이더 AS 1로 트래픽을 전달하는 경로(예: 10.65.153.0/24)를 광고했다고 가정해 보겠습니다. 이 /24 경로는 트래픽을 AS 2로 전달하는 실제 콘텐츠 제공자(10.65.152.0/22)가 사용하는 경로보다 더 구체적인 경로입니다. 라우터의 작동 방식 때문에 대부분의 라우터는 보다 구체적인 경로를 선택하고 AS 2가 아닌 AS 1로 트래픽을 전송합니다.

하이재킹된 접두사는 전송 라우터가 업데이트된 경로 정보를 전파할 때 인터넷을 통해 널리 볼 수 있습니다. 잘못된 경로는 DFZ(Default Free Zone)의 라우터가 하이재킹된 경로를 전달하므로 인터넷을 통해 광범위하게 배포될 수 있습니다. 결국 올바른 AS 경로가 BGP 피어로 복원되지만 그 동안 서비스 중단이 예상됩니다.

BGP는 전이적 신뢰 모델에 의존하기 때문에 고객과 프로바이더 간의 검증이 중요합니다. 위의 예에서 서비스 프로바이더 AS 1은 10.65.153.0/24에 대한 잘못된 보급을 검증하지 않았습니다. 이 광고를 수락하고 동료 및 공급자에게 다시 광고함으로써 AS 1은 잘못된 경로를 전파하고 있었습니다. AS 1에서 이 경로를 수신한 라우터는 이 경로가 더 구체적인 경로이므로 이 경로를 선택했습니다. 실제 콘텐츠 공급자는 실수가 발생하기 전에 10.65.152.0/22를 광고하고 있었습니다. /24는 더 작은(그리고 더 구체적인) 광고였습니다. 그런 다음 일반적인 BGP 경로 선택 프로세스에 따라 /24가 선택되어 하이재킹을 효과적으로 완료했습니다.

콘텐츠 제공자의 빠른 탐지 및 반응과 다른 제공자와의 협력에도 불구하고 접두사에 대한 서비스는 몇 분에서 최대 몇 시간 동안 중단될 수 있습니다. 정확한 중단 기간은 인터넷의 유리한 지점에 따라 다릅니다. 이러한 종류의 이벤트가 발생하면 이 취약점에 대한 솔루션에 대한 관심이 다시 높아지고 있습니다. BGP는 프로바이더 관계의 기본이며 곧 사라지지 않을 것입니다. 이 예제에서는 원본 검증을 사용하는 솔루션을 보여 줍니다. 이 솔루션은 BGP에 대한 암호화 확장과 라우터 CPU의 과도한 부담을 방지하는 분산 클라이언트-서버 모델에 의존합니다.

출처 검증은 공급자가 고객으로부터 수락하는 광고를 제한할 수 있도록 하여 전이적 신뢰의 취약성을 극복하는 데 도움이 됩니다. 메커니즘에는 확장된 BGP 커뮤니티 속성을 기반으로 하는 라우팅 정책의 통신이 포함됩니다.

예: BGP에 대한 오리진 검증 구성

이 예는 수신된 경로 보급이 예상 AS(Autonomous System)에서 전송(발신)되도록 하여 BGP 피어 간에 발신 검증을 구성하는 방법을 보여줍니다. 원본 AS가 검증되면 정책은 접두사가 차례로 보급되도록 지정할 수 있습니다.

요구 사항

이 예제의 하드웨어 및 소프트웨어 요구 사항은 다음과 같습니다.

  • BGP 접두사를 인증하기 위해 타사 소프트웨어를 사용하는 RPKI(Resource Public Key Infrastructure) 캐시 서버.

  • Junos OS 릴리스 12.2 이상은 TCP 연결을 통해 캐시 서버와 통신하는 라우팅 디바이스에서 실행됩니다.

개요

운영자 오류로 인해 경로가 의도치 않게 광고되는 경우가 있습니다. 이 보안 문제를 방지하기 위해 BGP를 구성하여 발신 AS를 검증하고 이러한 잘못된 알림을 거부할 수 있습니다. 이 기능은 캐시 서버를 사용하여 접두사 또는 접두사 범위를 인증합니다.

다음 구성 명령문은 원본 AS 검증을 활성화합니다.

이 예에서는 유효성 검사 매개 변수에 기본 설정을 사용합니다.

사용 가능한 구성 문의 대부분은 선택 사항입니다. 필요한 설정은 다음과 같습니다.

계층 수준을 사용하면 라우팅 디바이스에서 정적 레코드를 구성할 수 있으므로 RPKI 캐시 서버에서 수신한 레코드를 덮어쓸 수 있습니다.[edit routing-options validation static]

예:

경로 접두사의 검증 상태에 따라 작동하는 라우팅 정책을 구성할 수 있습니다. 커뮤니티 속성을 사용하여 외부 BGP(EBGP)와 내부 BGP(IBGP) 피어 간 접두사의 검증 상태를 발표하고 수신할 수 있습니다. 라우팅 정책을 사용하는 것이 RPKI 서버와의 세션을 구성하는 것보다 일부 라우터에서 더 편리할 수 있습니다. 이 예는 IBGP 피어 간에 validation-state community 속성을 사용하는 방법을 보여줍니다.

그림 4은 샘플 토폴로지를 표시합니다.

그림 4: 오리진 검증을 위한 토폴로지오리진 검증을 위한 토폴로지

이 예에서 디바이스 R0은 디바이스 R1에 대한 IBGP 연결 및 디바이스 R2에 대한 EBGP 연결을 가지고 있습니다. 디바이스 R0은 인터넷 초안 draft-ietf-sidr-rpki-rtr-19, RV 레코드를 전송하기 위한 RPKI/라우터 프로토콜에 정의된 프로토콜을 사용하여 캐시 서버로부터 RV(Route Validation) 레코드를 수신합니다. RPKI-라우터 프로토콜은 TCP를 통해 실행됩니다. RV 레코드는 디바이스 R0에서 로컬 RV 데이터베이스를 구축하는 데 사용됩니다. 디바이스 R1에서 검증 상태는 경로와 함께 수신되는 validation-state라는 BGP 커뮤니티를 기반으로 설정됩니다.

구성

CLI 빠른 구성

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

디바이스 R0

디바이스 R1

디바이스 R2

디바이스 R0 구성

단계별 절차

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

디바이스 R0 구성:

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

  2. BGP를 구성합니다.

    직접 경로가 라우팅 테이블에서 BGP로 내보내지도록 내보내기 정책을 적용합니다.send-direct

    가져오기 정책을 적용하여 디바이스 R0의 EBGP 피어에서 가져오는(또는 받은) 모든 경로에 대해 validation-state 및 BGP 커뮤니티 속성을 설정합니다.validation

    디바이스 R1과의 IBGP 세션을 구성합니다. 디바이스 R2와의 EBGP 세션을 구성합니다.

  3. IBGP 피어를 향하는 인터페이스와 루프백 인터페이스에서 OSPF(또는 다른 내부 게이트웨이 프로토콜[IGP])를 구성합니다.

    주:

    IBGP 문에서 루프백 인터페이스 주소를 사용하는 경우 루프백 인터페이스에서 IGP를 활성화해야 합니다.neighbor 그렇지 않으면 IBGP 세션이 설정되지 않습니다.

  4. 라우팅 테이블에서 BGP로 직접 경로를 내보내는 라우팅 정책을 구성합니다.

  5. 각 BGP 경로의 검증 상태에 따라 수정할 속성을 지정하는 라우팅 정책을 구성합니다.

  6. RPKI 캐시 서버와의 세션을 구성합니다.

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

결과

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

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

디바이스 R1 구성

단계별 절차

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

디바이스 R1 구성

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

  2. BGP를 구성합니다.

    가져오기 정책을 적용하여 디바이스 R1의 IBGP 피어에서 수신된 모든 경로에 대한 validation-state 및 BGP 커뮤니티 속성을 설정합니다.validation-ibgp

    디바이스 R0과의 IBGP 세션을 구성합니다.

  3. OSPF를 구성합니다.

  4. 디바이스 R0에서 수신한 BGP 경로의 검증 상태 BGP 커뮤니티 속성을 기반으로 수정할 속성을 지정하는 라우팅 정책을 구성합니다.

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

결과

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

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

디바이스 R2 구성

단계별 절차

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

디바이스 R2 구성:

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

    루프백 인터페이스에는 데모 목적의 경로로 사용되는 여러 주소가 구성됩니다.

  2. BGP를 구성합니다.

  3. 라우팅 정책 구성

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

결과

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

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

검증

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

수정된 속성이 라우팅 테이블에 표시되는지 확인

목적

디바이스 R0 및 디바이스 R1의 BGP 경로가 예상되는 검증 상태와 예상되는 로컬 기본 설정을 갖는지 확인합니다.

작업

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

의미

경로는 RPKI 캐시 서버에서 수신한 정보를 기반으로 예상되는 검증 상태 및 local-preference 값을 갖습니다.

추적 작업 사용

목적

오리진 검증을 위한 트레이스 작업을 구성하고, 새로 보급된 라우팅의 결과를 모니터링합니다.

작업
  • 디바이스 R0에서 추적을 구성합니다.

  • 디바이스 R2에서 루프백 인터페이스에 다른 주소를 추가하여 경로를 추가합니다.

  • 디바이스 R0에서 추적 파일을 확인합니다.

의미

경로 유효성 검사가 예상대로 작동하고 있습니다.

검증 정보 표시

목적

다양한 유효성 검사 명령을 실행합니다.

작업