Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP 원본 검증

BGP에 대한 원본 검증 이해

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

참고:

Junos OS 릴리스 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1 이전에는 RPKI 인증을 활성화하면 Junos OS가 예고 없이 TCP 포트 2222를 자동으로 엽니다. 필터를 적용하여 이 포트를 차단하고 보호할 수 있습니다.

Junos OS 릴리스 20.1R3, 20.2R3, 20.3R2, 20.4R2, 21.1R1부터 RPKI 인증을 활성화하면 Junos OS가 더 이상 TCP 포트 2222를 자동으로 열지 않습니다.

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

그림 1 은 샘플 토폴로지를 보여줍니다.

그림 1: 원본 검증 Network diagram showing two sites within AS 100. Site 1 has a PoP with a cache server; both sites have interconnected routers. 을 위한 샘플 토폴로지

지원되는 표준

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

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

  • RFC 6811, BGP 접두사 원본 검증

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

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

Origin 검증 작동 방식

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

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

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

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

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

최대 길이 값은 승인된 접두사의 길이보다 크거나 같아야 하며 주소 패밀리(IPv4의 경우 32, IPv6의 경우 128)에 있는 IP 주소의 길이(비트)보다 작거나 같아야 합니다. 최대 길이는 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(Serial Query Protocol Data Unit)를 전송하여 수행됩니다. 캐시 서버는 0개 이상의 업데이트와 EOD(End-of-Data) PDU로 응답하며, 이 PDU는 캐시 서버의 활성 상태를 새로 고치고 기록 수명 타이머를 재설정합니다.

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

  • Valid—접두사와 AS 쌍이 데이터베이스에서 발견되었음을 나타냅니다.

  • Invalid—접두사가 발견되었지만, EBGP 피어로부터 수신된 해당 AS가 데이터베이스에 나타나는 AS가 아니거나 BGP 업데이트 메시지의 접두사 길이가 데이터베이스에서 허용되는 최대 길이보다 길다는 것을 나타냅니다.

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

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

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

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

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

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

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

그림 2: BGP 및 경로 검증
Architecture and workflow of RPKI for securing BGP routing, featuring components like remote distributed RPKI repository, RPKI cache server, RPKI-RTR protocol, route validation database, BGP routing table, and event-based reevaluation of import policy.

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

그림 3에 나온 것처럼 가져오기 라우팅 정책을 사용하여 BGP가 라우팅 테이블에 배치하는 경로를 제어하고 내보내기 라우팅 정책을 사용하여 BGP가 라우팅 테이블에서 인접 라우터로 보급하는 경로를 제어라우팅 테이블을 사용합니다.

그림 3: 라우팅 정책 Diagram of network routing process showing flow of routing info from neighbors through import policies into routing table, then to export policies and neighbors. Forwarding table is derived from routing table for packet forwarding. 가져오기 및 내보내기

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

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

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

접두사 검증은 외부 BGP(EBGP) 업데이트에 대해서만 수행됩니다. AS 내에서 모든 내부 BGP(IBGP) 라우터에서 RPKI 세션을 실행하는 것은 좋지 않을 것입니다. 대신, 모든 IBGP 스피커가 일관된 정보를 갖도록 IBGP 메시 전반에 걸쳐 검증 상태를 전달하는 방법이 필요합니다. 이는 비전이적 확장 커뮤니티에서 검증 상태를 전달함으로써 수행됩니다. community 속성은 IBGP 이웃 간 접두사의 검증 상태를 발표하고 수신합니다.

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

  • origin-validation-state-valid

  • origin-validation-state-invalid입니다.

  • origin-validation-state-unknown

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

RPKI 세션이 있는 라우터

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

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

NST(Nonstop Active Routing) 및 발신 검증

듀얼 라우팅 엔진이 있고 무중단 활성 라우팅 이 활성화된 라우터에서 원본 검증을 구성하는 경우, 기본 및 대기 라우팅 엔진 모두 RV 데이터베이스의 복사본을 갖게 됩니다. 이 두 RV 데이터베이스는 서로 동기화된 상태를 유지합니다.

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

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

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

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

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

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

BGP에 대한 오리진 검증의 사용 사례 및 이점

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

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

하이재킹된 접두사는 전송 라우터가 업데이트된 경로 정보를 전파할 때 인터넷 전반에 걸쳐 널리 표시됩니다. 잘못된 경로는 기본 자유 영역(DFZ)의 라우터가 하이재킹된 경로를 전달하기 때문에 인터넷 전반에 광범위하게 배포될 수 있습니다. 결국 올바른 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) 캐시 서버.

  • TCP 연결을 통해 캐시 서버와 통신하는 라우팅 디바이스에서 실행되는 Junos OS 릴리스 12.2 또는 이후 버전

개요

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

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

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

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

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

예를 들면 다음과 같습니다.

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

그림 4는 샘플 토폴로지를 보여줍니다.

그림 4: 원본 검증 Network topology diagram with Cache 1 server, central router R0 in AS 65100, R1 router in AS 65100 via IBGP, and R2 router in AS 65200 via EBGP. 을 위한 토폴로지

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

구성

CLI 빠른 구성

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

디바이스 R0

디바이스 R1

디바이스 R2

디바이스 R0 구성

단계별 절차

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

디바이스 R0 구성:

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

  2. BGP를 구성합니다.

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

    가져오기 정책을 적용 validation 하여 디바이스 R0의 EBGP 피어에서 가져오거나 수신한 모든 경로에 대한 validation-state 및 BGP community 속성을 설정합니다.

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

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

    참고:

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

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

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

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

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

결과

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

디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .

디바이스 R1 구성

단계별 절차

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

디바이스 R1 구성:

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

  2. BGP를 구성합니다.

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

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

  3. OSPF를 구성합니다.

  4. 디바이스 R0에서 수신된 BGP 경로의 validation-state BGP community 속성을 기반으로 수정할 속성을 지정하는 라우팅 정책 구성합니다.

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

결과

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

디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .

디바이스 R2 구성

단계별 절차

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

디바이스 R2 구성:

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

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

  2. BGP를 구성합니다.

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

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

결과

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

디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .

검증

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

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

목적

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

작업

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

의미

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

추적 작업 사용

목적

원본 검증을 위한 추적 작업을 구성하고 새로 보급된 경로의 결과를 모니터링합니다.

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

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

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

의미

경로 검증이 예상대로 작동하고 있습니다.

검증 정보 표시

목적

다양한 검증 명령을 실행합니다.

작업