Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지에서
 

BGP 개요

BGP 이해

BGP는 다양한 AS(Autonomous System) 내 라우터 간에 라우팅 정보를 교환하는 데 사용되는 외부 게이트웨이 프로토콜(EGP)입니다. BGP 라우팅 정보에는 각 목적지에 대한 전체 경로가 포함됩니다. BGP는 라우팅 정보를 사용하여 네트워크 연결성 정보 데이터베이스를 유지 관리할 수 있으며, 이것은 다른 BGP 시스템과 교환합니다. BGP는 네트워크 연결성 정보를 사용하여 AS 연결 그래프를 구성할 수 있으며, 이를 통해 라우팅 루프를 제거하고 AS 수준에서 정책 결정을 시행할 수 있습니다.

멀티프로토콜 BGP(MBGP) 확장을 통해 BGP는 IP 버전 6(IPv6)을 지원할 수 있습니다.MBGP는 IPv6 연결성 정보를 전달하는 데 사용되는 MP_REACH_NLRI 및 MP_UNREACH_NLRI 속성을 정의합니다. NLRI(Network Layer Reachability Information) 업데이트 메시지가 실행 가능한 경로의 IPv6 주소 접두사를 전달합니다.

BGP는 정책 기반 라우팅을 허용합니다. 라우팅 정책을 사용하여 목적지에 대한 여러 경로 중에 선택하고 라우팅 정보의 재배포를 제어할 수 있습니다.

BGP는 연결 설정을 위해 포트 179를 사용하며, TCP를 전송 프로토콜로 활용합니다. 신뢰할 수 있는 전송 프로토콜을 통해 실행하면, BGP에서 업데이트 단편화, 재전송, 승인 및 시퀀싱을 구현할 필요가 없습니다.

Junos OS 라우팅 프로토콜 소프트웨어는 BGP 버전 4를 지원합니다. 이 버전의 BGP는 CIDR(Classless Interdomain Routing)에 대한 지원을 추가하여 네트워크 클래스 개념을 없앱니다. 첫 번째 옥텟을 보고 주소의 어떤 비트가 네트워크를 대표한다고 가정하는 대신, CIDR을 통해 네트워크 주소의 비트 수를 명시적으로 지정할 수 있으므로 라우팅 테이블의 크기를 줄일 수 있습니다. 또한 BGP 버전 4는 AS 경로 집계를 포함하여 경로 집계도 지원합니다.

이 섹션은 다음 주제에 대해 설명합니다.

AS(Autonomous System)

AS(Autonomous System)는 단일 기술 관리 하에 있는 라우터 세트이며, 일반적으로 단일 내부 게이트웨이 프로토콜과 공통된 메트릭 세트를 사용하여 라우터 세트 내에서 라우팅 정보를 전파합니다. 다른 AS의 경우, AS는 일관성 있는 단일 내부 라우팅 계획을 갖고 있는 것처럼 보이며, 이를 통해 도달할 수 있는 목적지에 대해 일관된 그림을 제시합니다.

AS 경로 및 속성

BGP 시스템이 교환하는 라우팅 정보에는 각 목적지에 대한 전체 경로와 해당 경로에 대한 추가 정보가 포함됩니다. AS 경로는 경로가 통과하는 자율 시스템의 시퀀스이며 추가 경로 정보는 경로 속성에 포함됩니다. BGP는 AS 경로와 경로 속성을 사용하여 네트워크 토폴로지를 완전히 결정합니다. BGP가 토폴로지를 파악하면 라우팅 루프를 감지하여 제거하고 경로 그룹 중에서 선택하여 관리 선호와 라우팅 정책 결정을 시행할 수 있습니다.

외부 및 내부 BGP

BGP는 두 가지 유형의 라우팅 정보 교환, 즉 서로 다른 AS 간의 교환과 단일 AS 내의 교환을 지원합니다. AS 간에 사용될 때 BGP는 외부 BGP(EBGP)라고 하며, BGP 세션은 AS 간의 라우팅을 수행합니다. AS 내에서 사용될 때 BGP는 내부 BGP(IBGP)라고 하며, BGP 세션은 AS 내부 라우팅을 수행합니다. 그림 1은 AS, IBGP, EBGP를 보여줍니다.

그림 1: AS, EBGP 및 IBGPAS, EBGP 및 IBGP

BGP 시스템은 인접 BGP 시스템과 네트워크 연결성을 공유하며, 이를 인접 라우터 또는 피어라고 합니다.

BGP 시스템은 그룹으로 분류됩니다. IBGP 그룹에서 그룹 내 모든 피어(내부 피어라고 함)는 동일한 AS에 있습니다. 내부 피어는 로컬 AS 내의 어디에나 있을 수 있으며, 서로 직접 연결할 필요가 없습니다. 내부 그룹은 IGP 경로를 사용하여 포워딩 주소를 확인할 수 있습니다. 또한 IBGP를 실행하는 다른 모든 내부 라우터 간에 외부 경로를 전파하고, 경로와 함께 수신된 BGP 다음 홉을 가져와서 내부 게이트웨이 프로토콜 중 하나의 정보를 사용해 이를 해결하면서 다음 홉을 계산합니다.

EBGP 그룹에서 그룹 내 피어(외부 피어라고 함)는 서로 다른 AS에 있으며 일반적으로 서브넷을 공유합니다. 외부 그룹에서 다음 홉은 외부 피어와 로컬 라우터 간에 공유되는 인터페이스와 관련하여 계산됩니다.

BGP의 여러 인스턴스

다음 계층 수준에서 여러 BGP 인스턴스를 구성할 수 있습니다.

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

BGP의 여러 인스턴스는 주로 레이어 3 VPN 지원에 사용됩니다.

IGP 피어 및 외부 BGP(EBGP) 피어(non다중 홉 및 다중 홉 모두)는 라우팅 인스턴스에 대해 모두 지원됩니다. BGP 피어링은 routing-instances 계층에서 구성된 인터페이스 중 하나를 통해 설정됩니다.

주:

BGP 인접 라우터가 BGP 메시지를 로컬 라우팅 장치로 보낼 때, 이러한 메시지가 들어오는 수신 인터페이스는 BGP 인접 라우터 구성이 존재하는 동일한 라우팅 인스턴스에서 구성되어야 합니다. 이것은 단일 홉이나 멀티홉 위치의 인접 라우터에 해당합니다.

BGP 피어에서 학습한 경로는 기본적으로 instance-name.inet.0 테이블에 추가됩니다. 가져오기 및 내보내기 정책을 구성하여 인스턴스 라우팅 테이블로 들어오고 나가는 정보 흐름을 제어할 수 있습니다.

레이어 3 VPN 지원의 경우, 고객 에지(CE) 라우터에서 경로를 수신하고 필요에 따라 인스턴스 경로를 CE 라우터로 전송하도록 프로바이더 에지(PE) 라우터에서 BGP를 구성합니다. 여러 BGP 인스턴스를 사용하여 PE 라우터에서 VPN 트래픽을 별도로 유지하기 위해 별도의 사이트별 포워딩 테이블을 유지할 수 있습니다.

서비스 프로바이더가 고객과 주고 받는 트래픽을 제어하고 속도를 제한할 수 있는 가져오기 및 내보내기 정책을 구성할 수 있습니다.

VRF 라우팅 인스턴스에 대해 EBGP 다중 홉 세션을 구성할 수 있습니다. 또한 인터페이스 주소 대신 CE 라우터의 루프백 주소를 사용하여 PE와 CE 라우터 사이에 EBGP 피어를 설정할 수 있습니다.

보안 영역의 인터페이스에 프로토콜 트래픽 허용

SRX 시리즈 방화벽의 경우, 지정된 인터페이스나 영역의 모든 인터페이스에서 예상되는 host-inbound 트래픽을 활성화해야 합니다. 그렇지 않으면 이 디바이스로 향하는 인바운드 트래픽이 기본적으로 삭제됩니다.

예를 들어 SRX 시리즈 방화벽의 특정 영역에서 BGP 트래픽을 허용하려면 다음 단계를 사용하십시오.

(모든 인터페이스) (지정된 인터페이스)

참조

BGP 경로 개요

BGP 경로는 IP 주소 접두사로 설명되는 목적지이며 목적지에 대한 경로를 설명하는 정보입니다.

다음 항목에서는 경로에 대해 설명합니다.

  • AS 경로는 로컬 라우터에 도달하기 위해 경로가 통과하는 AS 번호 목록입니다. 경로의 첫 번째 숫자는 경로의 마지막 AS 번호(로컬 라우터에 가장 가까운 AS)입니다. 경로의 마지막 숫자는 로컬 라우터에서 가장 먼 AS이며, 일반적으로 경로의 원점입니다.

  • 경로 속성은 라우팅 정책에 사용되는 AS 경로에 대한 추가 정보를 포함합니다.

BGP 피어는 업데이트 메시지에서 서로에 대한 경로를 보급합니다.

BGP는 Junos OS 라우팅 테이블(inet.0)에 경로를 저장합니다. 라우팅 테이블은 BGP 경로에 대한 다음 정보를 저장합니다.

  • 피어에서 받은 업데이트 메시지에서 학습한 라우팅 정보

  • 로컬 정책으로 인해 BGP가 경로에 적용하는 로컬 라우팅 정보

  • BGP가 업데이트 메시지에서 BGP 피어에 보급하는 정보

라우팅 테이블의 각 접두사에 대해 라우팅 프로토콜 프로세스는 활성 경로라고 하는 단일 최적 경로를 선택합니다. 동일한 목적지에 대한 여러 경로를 보급하도록 BGP를 구성하지 않는 한 BGP는 활성 경로만 보급합니다.

경로를 처음 보급하는 BGP 라우터는 해당 경로를 식별하기 위해 다음 값 중 하나를 할당합니다. 경로 선택 중에는 가장 낮은 원점 값이 선호됩니다.

  • 0—라우터는 원래 IGP(OSPF, IS-IS 또는 정적 경로)를 통해 경로를 학습했습니다.

  • 1—라우터는 원래 EGP(대개 BGP)를 통해 경로를 학습했습니다.

  • 2—경로의 원점을 알 수 없습니다.

참조

BGP 경로 확인 개요

원격 BGP neighbor(프로토콜 다음 홉)에 대한 다음 홉 주소가 있는 내부 BGP(IBGP) 경로는 다른 일부 경로를 사용해 다음 홉을 확인해야 합니다. BGP는 다음 홉 해석을 위해 rpd 확인자 모듈에 이 경로를 추가합니다. RSVP가 네트워크에서 사용되면 RSVP 수신 경로를 사용해 BGP 다음 홉이 확인됩니다. 이로 인해 BGP 경로가 간접적 다음 홉을 가리키고 간접적 다음 홉은 포워딩 다음 홉을 가리킵니다. 포워딩 다음 홉은 RSVP 경로 다음 홉에서 파생됩니다. 종종 동일한 프로토콜 다음 홉을 지닌 내부 BGP 경로 모음이 대규모로 존재하므로, 이런 경우 BGP 경로 모음이 동일한 간접 다음 홉을 참조합니다.

Junos OS 릴리스 17.2R1 이전에는 라우팅 프로토콜 프로세스(rpd)의 확인자 모듈은 다음 방법으로 IBGP 수신 경로 내 경로를 확인했습니다.

  1. 부분적 경로 확인—프로토콜 다음 홉은 RSVP 또는 IGP 경로 등 도우미 경로를 기반으로 확인됩니다. 메트릭 값은 도우미 경로로부터 파생되며 다음 홉은 도우미 경로에서 상속된 다음 홉을 전달하는 확인자로 참조됩니다. 이러한 메트릭 값은 라우팅 테이블로 알려진 RIB(Routing Information Base)에서 경로를 선택하는 데 사용됩니다.

  2. 완전한 경로 확인—마지막 다음 홉이 파생되며 포워딩 내보내기 정책을 기반으로 다음 홉을 전달하는 커널 라우팅 테이블(KRT)로 참조됩니다.

Junos OS 릴리스 17.2R1부터 rpd 확인자 모듈이 인바운드 처리 flow 처리량을 증진할 수 있도록 최적화됩니다. 이를 통해 RIB와 FIB의 학습 속도를 가속할 수 있습니다. 이러한 향상으로 경로 확인은 다음의 영향을 받습니다.

  • 비록 각 경로가 동일하게 확인된 포워딩 다음 홉 또는 KRT 포워딩 다음 홉을 상속하더라도 부분 및 전체 경로 확인 방법은 각 IBGP 경로에 대해 트리거됩니다.

  • BGP 경로 선택은 BGP neighbor에서 수신된 NLRI(Network Layer Reachability Information)에 대해 완전한 경로 확인이 수행될 때까지 연기됩니다. 이는 경로 선택 후 RIB에서 최선의 경로가 아닐 수 있습니다.

rpd 확인자 최적화의 이점은 다음을 포함합니다.

  • 더 낮은 RIB 확인 조회 비용—확인된 경로 출력은 확인자 캐시에 저장됩니다. 그러므로 동일하게 파생된 다음 홉 및 메트릭 값은 부분 및 전체 경로 확인 flow 모두를 수행하는 대신 동일한 경로 동작을 공유하는 또 다른 경로 모음에 상속될 수 있습니다. 이를 통해 제한된 깊이의 캐시에 있는 가장 빈도수 높은 확인자 상태만 유지함으로써 경로 확인 조회 비용을 절감할 수 있습니다.

  • BGP 경로 선택 최적화—BGP 경로 선택 알고리즘은 수신된 모든 IBGP 경로에 대해 두 번 트리거됩니다. 첫 번째는 다음 홉을 사용할 수 없는 것으로 RIB에 경로를 추가하는 동안이고, 두 번째는 (경로 확인 후) RIB에서 확인된 다음 홉과 경로를 추가하는 동안에 이루어집니다. 이로 인해 두 번 최상의 경로를 선택하게 됩니다. 확인자 최적화를 통해 확인자 모듈의 다음 홉 정보를 수신한 이후에만 수신 flow에서 경로 선택 프로세스가 트리거됩니다.

  • 잦은 조회를 피하기 위한 내부 캐싱—확인자 캐시는 가장 빈도가 높은 확인자 상태를 유지합니다. 이 결과 다음 홉 조회, 경로 조회 등과 같은 조회 기능이 로컬 캐시에서 수행됩니다.

  • 동등 경로 그룹—각기 다른 경로가 동일한 전달 상태를 공유하거나 동일한 프로토콜 다음 홉에서 수신된 경우 해당 경로는 단일 동등 경로 그룹에 속합니다. 이 접근 방식을 사용하면 이러한 경로에 대해 완전한 경로 확인을 수행할 필요가 없습니다. 새로운 경로에 완전한 경로 확인이 필요한 경우, 동등 경로 그룹 데이터베이스에서 먼저 조회됩니다. 해당 데이터베이스는 간접 다음 홉 및 포워딩 다음 홉 등과 같은 확인된 경로 출력을 포함합니다.

참조

BGP 메시지 개요

모든 BGP 메시지에는 동기화 및 인증에 사용되는 마커 필드, 패킷 길이를 나타내는 길이 필드 및 메시지 유형을 나타내는 유형 필드(예: open, update, notification, keepalive 등)가 포함된 동일한 고정 크기 헤더가 있습니다.

이 섹션은 다음 주제에 대해 설명합니다.

Open 메시지

두 BGP 시스템 간에 TCP 연결이 설정된 후, 두 시스템 간에 BGP open 메시지를 교환하여 BGP 연결을 만듭니다. 연결이 설정되면 두 시스템은 BGP 메시지와 데이터 트래픽을 교환할 수 있습니다.

Open 메시지는 BGP 헤더와 다음 필드로 구성됩니다.

  • Version—현재 BGP 버전 번호는 4입니다.

  • Local AS number: [edit routing-options] 또는 [edit logical-systems logical-system-name routing-options] 계층 수준에서 autonomous-system 문을 포함하여 구성합니다.

  • Hold time—제안된 hold-time 값입니다. 로컬 보류 시간은 BGP hold-time 문을 사용하여 구성합니다.

  • BGP identifier—BGP 시스템의 IP 주소입니다. 이 주소는 시스템이 시작될 때 결정되며 모든 로컬 인터페이스와 모든 BGP 피어에서 동일합니다. BGP 식별자는 [edit routing-options] 또는 [edit logical-systems logical-system-name routing-options] 계층 수준에서 router-id 문을 포함하여 구성할 수 있습니다. 기본적으로 BGP는 라우터에서 찾은 첫 번째 인터페이스의 IP 주소를 사용합니다.

  • Parameter field length and the parameter itself—이러한 필드는 선택 사항입니다.

Update 메시지

BGP 시스템은 네트워크 연결성 정보를 교환하기 위해 update 메시지를 보냅니다. BGP 시스템은 이 정보를 사용하여 알려진 모든 AS 간의 관계를 설명하는 그래프를 구성합니다.

Update 메시지는 BGP 헤더와 다음 선택 필드로 구성됩니다.

  • Unfeasible routes length—철회된 경로 길이 필드

  • Withdrawn routes—더 이상 연결할 수 없는 것으로 간주되어 서비스에서 철회되는 경로에 대한 IP 주소 접두사

  • Total path attribute length—경로 속성 필드의 길이; 목적지까지 실행 가능한 경로에 대한 경로 속성을 나열

  • Path attributes—경로 출처, MED(Multiple Exit Discriminator), 경로에 대한 원래 시스템의 선호, 집계, community, 컨페더레이션 및 경로 반영에 대한 정보를 포함한 경로의 속성

  • Network layer reachability information (NLRI)—Update 메시지에서 보급되는 실행 가능한 경로의 IP 주소 접두사

Keepalive 메시지

BGP 시스템은 링크 또는 호스트가 실패했는지 또는 더 이상 사용할 수 없는지 확인하기 위해 keepalive 메시지를 교환합니다. 보류 타이머가 만료되지 않도록 Keepalive 메시지가 충분히 자주 교환됩니다. 이러한 메시지는 BGP 헤더로만 구성됩니다.

Notification 메시지

BGP 시스템은 오류 조건이 감지되면 Notification 메시지를 보냅니다. 메시지가 전송된 후 BGP 세션과 BGP 시스템 간의 TCP 연결이 닫힙니다. Notification 메시지는 BGP 헤더와 오류 코드 및 하위 코드, 오류를 설명하는 데이터로 구성됩니다.

Route-Refresh 메시지

BGP 시스템은 피어로부터 경로 새로 고침 기능 알림을 받은 경우에만 Route-Refresh 메시지를 피어에 보냅니다 BGP 시스템이 Route-Refresh 메시지를 수신하려면 BGP 기능 알림을 사용하여 해당 피어에 경로 새로 고침 기능을 보급해야 합니다. 이 선택적 메시지는 BGP 피어에서 동적 인바운드 BGP 경로 업데이트를 요청하거나 BGP 피어로 outbound route 업데이트를 전송하기 위해 전송됩니다.

Route-refresh 메시지는 다음 필드로 구성됩니다.

  • AFI—Address Family Identifier(16비트)

  • Res—Reserved(8비트) 필드, 이 필드는 발신인이 0으로 설정하고 receiver가 무시해야 합니다.

  • SAFI—Subsequent Address Family Identifier(8비트)

route-refresh 기능이 없는 피어가 원격 피어로부터 Route-refresh 요청 메시지를 수신할 경우 receiver는 메시지를 무시합니다.

참조

BGP RIB sharding 및 BGP Update IO 스레드 이해

BGP 경로 처리는 일반적으로 업데이트 수신, 업데이트 구문 분석, 경로 생성, 다음 홉 해결, BGP 피어 그룹의 내보내기 정책 적용, 피어 업데이트 구성 및 피어 업데이트 전송과 같은 여러 파이프라인 단계를 거친다.

BGP RIB sharding은 통합 BGP RIB를 여러 개의 서브 RIB로 분할하고 각 서브 RIB는 BGP 경로의 서브셋을 처리합니다. BGP shard 스레드로 불리는 별도의 RPD 스레드는 동시성을 달성하기 위해 각 하위 RIB에 서비스를 제공한다. BGP shard 스레드는 피어별 업데이트를 형성하고 피어에 업데이트를 보내는 것을 제외하고 모든 BGP 경로 처리 파이프라인 단계를 담당합니다. BGP shard 스레드는 업데이트의 접두사를 해시하는 BGP Update IO 스레드와 함께 BGP Update IO 스레드에서 피어에서 보낸 업데이트를 수신하고 해시 계산에 따라 해당 BGP shard 스레드로 업데이트를 보냅니다. BGP shard 스레드는 RPD 주 스레드와 동일한 방식으로 구성을 처리하고 peers, groups, route-tables을 만들고 BGP 경로 처리를 위한 구성 정보를 사용합니다.

BGP Update IO 스레드는 개별 BGP 그룹에 대한 피어별 업데이트를 생성하고 피어에 보내는 작업을 포함하여 이 BGP 파이프라인의 끝 부분을 담당합니다. 하나의 Update 스레드가 하나 이상의 BGP 그룹에 서비스를 제공할 수 있습니다 BGP Update IO 스레드는 다른 Update 스레드에서 서비스되는 다른 그룹과 독립적으로 병렬로 그룹에 대한 업데이트를 구성합니다. 이렇게 하면 쓰기 집약적인 작업 부하에서 상당한 컨버전스 개선을 제공할 수 있으며, 이는 여러 그룹에 분산된 많은 동료에게 광고를 하는 것을 수반합니다. BGP Update IO 스레드는 이전에 BGPIO 스레드에 의해 제공되었던 BGP 피어의 TCP 소켓에 대한 쓰기 및 읽기 작업도 담당합니다(따라서 BGP Update IO의 접미사 IO).

BGP Update IO 스레드는 RIB sharding 기능과 독립적으로 구성할 수 있지만 아웃바운드 BGP 업Update 메시지에서 더 나은 접두사 패킹 효율성을 달성하기 위해 RIB sharding과 함께 사용해야 합니다. BGP sharding은 RIB를 여러 개의 하위 RPD 스레드로 분할합니다. 따라서 단일 아웃바운드 업데이트로 들어갈 수 있는 접두사는 서로 다른 조각으로 끝납니다. 다른 RPD shard 스레드에 속할 수 있는 동일한 송신 특성을 가진 접두사로 BGP Update를 구성할 수 있도록 모든 shard 스레드는 해당 BGP 피어 그룹을 서비스하는 Update 스레드에 보급될 접두사에 대한 압축 광고 정보를 보냅니다. 이렇게 하면 이 BGP 피어 그룹에 서비스를 제공하는 Update 스레드가 동일한 특성을 가진 접두사를 패킹할 수 있으며, 잠재적으로 동일한 아웃바운드 업데이트 메시지의 다른 shard에 속합니다. 이를 통해 보급할 업데이트 수를 최소화하여 컨버전스를 개선하는 데 도움이 됩니다. Update IO 스레드는 피어, 그룹, 접두사, TSI 및 RIB 컨테이너의 로컬 캐시를 관리합니다.

BGP Update 스레드 및 BGP RIB sharding은 기본적으로 사용되지 않도록 설정됩니다. 라우팅 엔진에 update-threading 및 rib-sharding을 구성하는 경우 RPD가 업데이트 스레드를 생성합니다. 기본적으로 생성된 Update 스레드 및 shard 스레드 수는 라우팅 엔진의 CPU 코어 수와 동일합니다. Update threading은 64비트 라우팅 프로토콜 프로세스(rpd)에서만 지원됩니다. 선택적으로, [edit system processes routing bgp] 계층 수준에서 set update-threading <number-of-threads>과 set rib-sharding <number-of-threads>문을 사용하여 작성할 스레드 수를 지정할 수 있습니다. BGP Update 스레드의 경우 현재 범위는 1~128이고 BGP RIB sharding의 경우 현재 1~31입니다.

BGP RIB sharding 및 BGP Update IO 기능에 대해 NSR을 구성하는 경우 백업 RPD는 백업 라우팅 엔진에 동일한 수의 BGP shard 및 BGP Update IO 스레드를 생성합니다. 백업 RPD BGP Update IO 스레드는 복제된 BGP Update, 피어에서 받은 다른 메시지와 복제된 BGP Update 및 피어로 전송된 다른 메시지를 읽습니다. 접두사의 해시를 기반으로 백업 RPD BGP Update IO 스레드는 이러한 BGP 메시지를 해당 BGP shard 및 RPD 기본 스레드로 보냅니다. 백업 RPD의 BGP shard 및 RPD 기본 스레드는 이러한 복제된 BGP 메시지를 사용하여 수신 및 보급된 경로 상태를 생성합니다. 기본 라우팅 엔진에 장애가 발생하면 백업 라우팅 엔진이 기본 라우팅 엔진이 되고 백업 RPD가 피어와의 BGP 세션에 영향을 주지 않고 원활하게 기본 RPD가 됩니다.

BGP 경로 선택 이해

라우팅 테이블의 각 접두사에 대해, 라우팅 프로토콜 프로세스는 단일 최적 경로를 선택합니다. 최적의 경로가 선택되면 해당 경로가 라우팅 테이블에 설치됩니다. 관리 거리라고도 하는 더 낮은(더 선호되는) 전역 선호 값을 가진 프로토콜에 의해 동일한 접두사가 학습되지 않는 경우 최상의 경로가 활성 경로가 됩니다. 활성 경로를 결정하는 알고리즘은 다음과 같습니다.

  1. 다음 홉이 해결될 수 있는지 확인합니다.

  2. 가장 낮은 선호 값(라우팅 프로토콜 프로세스 설정)으로 경로를 선택합니다.

    포워딩에 사용되기 적합하지 않은 경로(예: 라우팅 정책에 의해 거부되었거나 다음 홉에 액세스할 수 없기 때문에)는 선호가 -1이거나 선택되지 않습니다.

  3. 로컬 선호가 높은 경로가 선호됩니다.

    비 BGP 경로의 경우, preference2 값이 가장 낮은 경로를 선택하십시오.

  4. AIGP(누적된 내부 게이트웨이 프로토콜) 속성이 활성화된 경우, IGP 메트릭을 추가하고 낮은 AIGP 속성이 있는 경로를 선호합니다.

  5. AS(Autonomous System) 경로 값이 가장 짧은 경로를 선호합니다(as-path-ignore 문이 구성된 경우 생략).

    컨페더레이션 세그먼트(시퀀스 또는 세트)에 길이가 0인 경로가 있습니다. AS 세트에 길이가 1인 경로가 있습니다.

  6. 원본 코드가 더 낮은 경로가 선호됩니다.

    IGP에서 학습한 경로는 외부 게이트웨이 프로토콜(EGP)에서 학습한 경로보다 낮은 출처 코드를 가지고 있으며, 둘 다 불완전한 경로(원점을 알 수 없는 경로)보다 낮은 출처 코드를 가지고 있다.

  7. 다중 출구 판별기(MED) 메트릭이 가장 낮은 경로가 선호됩니다.

    불명확한 라우팅 테이블 경로 선택 동작의 구성 여부에 따라 가능한 사례가 2가지가 있습니다.

    • 불명확한 라우팅 테이블 경로 선택 동작이 구성되지 않은 경우(즉, path-selection cisco-nondeterministic 명령문이 BGP 구성에 포함되지 않은 경우) AS 경로의 전면에 있는 인접 AS 번호가 동일한 경로에 대해서는 MED 메트릭이 가장 낮은 경로가 선호됩니다. 비교된 경로의 피어 AS가 동일한지 여부에 관계없이 항상 MED를 비교하려면 path-selection always-compare-med문을 포함합니다.

    • 비결정적 라우팅 테이블 경로 선택 동작이 구성된 경우(즉, BGP 구성에 path-selection cisco-nondeterministic 문이 포함됨), 가장 낮은 MED 메트릭을 가진 경로를 선호합니다.

    이웃 AS를 결정할 때 페더레이션은 고려되지 않습니다. 누락된 MED 메트릭은 MED가 있지만 0인 것처럼 처리됩니다.

    주:

    MED 비교는 AS 내의 단일 경로 선택(경로에 AS 경로가 포함되지 않은 경우)에 대해 작동하지만, 자주 사용되지는 않습니다.

    기본적으로 동일한 피어 AS(Autonomous System)를 가진 경로의 MED만 비교됩니다. 라우팅 테이블 경로 선택 옵션을 구성하여 다른 동작을 획득할 수 있습니다.

  8. IGP 경로 및 로컬에서 생성된 경로(정적, 직접, 로컬 등)를 포함하는 내부 경로를 엄격하게 선호합니다.

  9. 내부 BGP(IBGP) 세션을 통해 학습된 외부 경로보다 엄격하게 외부 BGP(EBGP) 경로를 선호합니다.

  10. 메트릭이 가장 낮은 IGP 경로를 통해 다음 홉이 확인되는 경로를 선호합니다. IGP를 통해 해결된 BGP 경로는 연결할 수 없거나 거부된 경로보다 선호됩니다.

    주:

    이전 단계 이후에 타이브레이크가 수행되는 경우 경로는 BGP 등비용 경로로 간주됩니다(포워딩에 사용). 다중 경로 지원 BGP 이웃 라우터에 의해 학습된 동일한 이웃 AS를 가진 모든 경로가 고려됩니다.

    BGP 다중 경로는 동일한 MED-plus-IGP 비용을 공유하지만 IGP 비용이 다른 경로에는 적용되지 않습니다. 다중 경로 경로 선택은 IGP 비용 메트릭을 기반으로 하며, 2개의 경로에서 MED-plus-IGP 비용이 동일한 경우에도 마찬가지입니다.

  11. 두 경로가 모두 외부인 경우, 가장 오래된 경로, 즉 먼저 학습된 경로를 선호합니다. 이 작업은 경로 플래핑을 최소화하기 위해 수행됩니다. 이 규칙은 다음 조건 중 하나라도 참일 경우 적용되지 않습니다.

    • path-selection external-router-id이 구성됩니다.

    • 두 피어가 동일한 라우터 ID를 갖습니다.

    • 두 피어 중 하나는 컨페더레이션 피어입니다.

    • 두 피어 모두 현행 활성 경로가 아닙니다.

  12. 기본 경로가 2차 경로보다 선호됩니다. 기본 경로는 라우팅 테이블에 속하는 경로입니다. 2차 경로는 내보내기 정책을 통해 라우팅 테이블에 추가되는 경로입니다.

  13. 가장 낮은 라우터 ID가 있는 피어의 경로가 선호됩니다. 원본자 ID 속성이 있는 모든 경로의 경우, 라우터 ID 비교 과정에서 라우터 ID에 대한 원본자 ID를 대체하십시오.

  14. 클러스터 목록 길이가 가장 짧은 경로가 선호됩니다. 목록이 없으면 길이가 0입니다.

  15. 피어 IP 주소가 가장 낮은 피어의 경로가 선호됩니다.

라우팅 테이블 경로 선택

알고리즘의 최단 AS 경로 단계는 기본적으로 AS 경로의 길이를 평가하고 활성 경로를 결정합니다. as-path-ignore 옵션을 추가하여 Junos OS가 알고리즘의 이 단계를 생략하도록 옵션을 구성할 수 있습니다.

주:

Junos OS 릴리스 14.1R8부터 14.2R7, 15.1 R4, 15.1 F6 및 16.1 R1까지, 라우팅 인스턴스에 대해 as-path-ignore 옵션이 지원됩니다.

라우팅 프로세스 경로 선택은 BGP가 경로를 라우팅 테이블로 넘겨 결정을 내리기 전에 이루어집니다. 라우팅 테이블 경로 선택 동작을 구성하려면 path-selection 명령문을 포함하십시오.

이 명령문을 포함할 수 있는 계층 수준의 목록은 이 명령문에 대한 요약 섹션을 참조하십시오.

라우팅 경로 선택은 다음 중 하나의 방식으로 구성이 가능합니다.

  • Cisco IOS 기본 동작을 에뮬레이트하십시오(cisco-non-deterministic). 이 모드는 수신된 순서대로 경로를 평가하며 인접 AS에 따라 경로를 그룹화하지 않습니다. cisco-non-deterministic 모드에서는 활성 경로가 항상 우선입니다. 모든 비활성 적격 경로는 활성 경로를 따르며 수신된 순서대로 유지됩니다. 즉, 가장 최신 경로가 우선합니다. 부적합 경로는 목록의 끝에 남아 있습니다.

    예를 들어, 192.168.1.0/24 경로에 3개의 경로 보급이 있다고 가정하겠습니다.

    • 경로 1—EBGP를 통해 학습, 65010의 AS 경로, 200 MED

    • 경로 2—IBGP를 통해 학습, 65020의 AS 경로, 150 MED, IGP 비용 5

    • 경로 3—IBGP를 통해 학습, 65010의 AS 경로, 100 MED, IGP 비용 10

    이러한 보급은 나열된 순서대로 1초 이내에 빠르게 연속 수신됩니다. 경로 3은 가장 최근에 수신된 것으로, 라우팅 디바이스는 해당 경로를 2번째 최신 경로인 경로 2와 비교합니다. IBGP 피어의 비용은 경로 2에서 더 낫기 때문에, 라우팅 디바이스는 경합에서 경로 3을 제거합니다. 경로 1과 2를 비교할 때, 라우팅 디바이스는 경로 1이 EBGP를 통해 수신되므로 1을 선호합니다. 이를 통해 라우팅 디바이스는 경로 1을 라우팅에 대한 활성 경로로 설치합니다.

    주:

    귀하의 네트워크에서 이 구성 옵션을 사용하는 것을 권장하지 않습니다. 해당 옵션은 네트워크상의 모든 라우팅 디바이스가 일관적으로 경로를 선택하도록 허용하는 상호운용성을 위해서만 제공됩니다.

  • 비교 경로의 피어 AS에 관계없이 항상 MED를 비교하는 것은 동일합니다(always-compare-med).

  • 두 경로가 모두 외부일 경우 현행 활성 경로가 선호된다는 규칙을 재정의하십시오(external-router-id). path-selection 프로세스에서 다음 단계(단계 12)로 계속 진행합니다.

  • 경로 선택을 위해 MED 값을 비교하기 전에 다음 홉 목적지에 IGP 비용을 MED 값에 추가합니다(med-plus-igp).

    BGP 다중 경로는 동일한 MED-plus-IGP 비용을 공유하나 IGP 비용이 다른 경로에 적용되지 않습니다. 다중 경로 경로 선택은 IGP 비용 메트릭을 기반으로 하며, 2개의 경로에서 MED-plus-IGP 비용이 동일한 경우에도 마찬가지입니다.

BGP 테이블 경로 선택

BGP의 경로 선택에 대해 다음 매개 변수가 따릅니다.

  1. 가장 높은 로컬-선호 값이 선호됩니다.

  2. 가장 짧은 AS-path 길이가 선호됩니다.

  3. 가장 낮은 원본값이 선호됩니다.

  4. 가장 낮은 MED 값이 선호됩니다.

  5. IPGB 피어보다 EBGP 피어에서 학습된 경로가 선호됩니다.

  6. AS에서 최적의 종료가 선호됩니다.

  7. EBGP 수신 경로의 경우, 현행 활성 경로가 선호됩니다.

  8. 라우터 ID가 가장 낮은 피어의 경로가 선호됩니다.

  9. 클러스터 길이가 가장 짧은 경로가 선호됩니다.

  10. 피어 IP 주소가 가장 낮은 피어의 경로가 선호됩니다. 2단계, 6단계, 12단계는 RPD 기준입니다.

목적지에 여러 경로를 보급하면 발생하는 효과

목적지에 여러 경로를 보급하도록 BGP를 구성하지 않는 이상 BGP는 활성 경로에만 보급됩니다.

라우팅 테이블에 목적지에 대한 경로가 4개 있고 최대 3개의 경로를 보급하도록 구성된 라우팅 디바이스를 가정해 보겠습니다(add-path send path-count 3). 경로 선택 기준에 따라 3개 경로가 선택됩니다. 즉, path-selection 순서에서 최적 경로 3개가 선택됩니다. 최적의 경로는 활성 경로입니다. 이 경로는 고려 대상에서 제거되며 새로운 최적 경로가 선택됩니다. 이 프로세스는 지정된 경로 수에 도달할 때까지 반복됩니다.

참조

BGP 지원 표준

Junos OS는 IP 버전 4(IPv4) BGP에 대한 표준을 정의하는 다음 RFC 및 인터넷 초안을 주로 지원합니다.

지원되는 IP 버전 6(IPv6) BGP 표준 목록의 경우 지원되는 IPv6 표준을 참조하십시오.

Junos OS BGP는 프로토콜 교환에 대한 인증(MD5 인증)을 지원합니다.

  • RFC 1745, IP—OSPF 상호 작용을 위한 BGP4/IDRP

  • RFC 1772, 인터넷에서 BGP(Border Gateway Protocol) 적용

  • RFC 1997, BGP 커뮤니티 속성

  • RFC 2283, BGP-4에 대한 멀티프로토콜 확장

  • RFC 2385, TCP MD5 서명 옵션을 통한 BGP 세션 보호

  • RFC 2439, BGP RFD(Route Flap Damping)

  • RFC 2545, IPv6 도메인 간 라우팅을 위한 BGP-4 멀티프로토콜 확장

  • RFC 2796, BGP 경로 리플렉션(Route Reflection) – 풀 메시 IBGP에 대한 대안

  • RFC 2858, BGP-4에 대한 멀티프로토콜 확장

  • RFC 2918, BGP-4에 대한 경로 새로 고침 기능

  • RFC 3065, BGP를 위한 AS(Autonomous System) 컨페더레이션

  • RFC 3107, BGP-4에서 레이블 정보 전달

  • RFC 3345, BGP(Border Gateway Protocol) 연속 경로 진동 조건

  • RFC 3392, BGP-4를 통한 기능 보급

  • RFC 4271, BGP-4(Border Gateway Protocol 4)

  • RFC 4273, BGP-4를 위한 관리 대상 정의

  • RFC 4360, BGP 확장 커뮤니티 속성

  • RFC 4364, BGP/MPLS IP VPN

  • RFC 4456, BGP 경로 리플렉션: 풀 메시 내부 BGP(IBGP)에 대한 대안

  • RFC 4486, BGP BGP Cease Notification 메시지 하위 코드

  • RFC 4659, IPv6 VPN을 위한 BGP-MPLS IP VPN 확장 프로그램

  • RFC 4632, CIDR(Classless Inter-domain Routing): 인터넷 주소 할당 및 집계 계획

  • RFC 4684, BGP/MPLS(Border Gateway Protocol/MultiProtocol Label Switching) 인터넷 프로토콜(IP) VPN에 대한 제한된 경로 배포

  • RFC 4724, BGP를 위한 GR(Graceful Restart) 메커니즘

  • RFC 4760, BGP-4를 위한 멀티프로토콜 확장

  • RFC 4781, MPLS를 사용하는 BGP를 위한 GR(Graceful Restart) 메커니즘

  • RFC 4798, IPv6 프로바이더 에지 라우터(6PE)를 사용해 IPv4 MPLS로 IPv6 아일랜드 연결

    옵션 4b(AS부터 neighbor AS까지 레이블된 IPv6 경로의 eBGP 재배포)는 지원되지 않습니다.

  • RFC 4893, 4개의 옥텟 AS 번호 공백을 위한 BGP 지원

  • RFC 5004, 외부 간의 BGP 최적 경로 전환 방지

  • RFC 5065, BGP를 위한 AS(Autonomous System) 컨페더레이션

  • RFC 5082, 일반화된 TTL 보안 메커니즘(GTSM)

  • RFC 5291, BGP-4를 위한 Outbound Route 필터링 기능(부분적 지원)

  • RFC 5292, BGP-4를 위한 Address-Prefix 기반 Outbound Route 필터(부분적 지원)

    Junos OS가 실행되는 디바이스는 접두사 기반 ORF 메시지를 수신할 수 있습니다.

  • RFC 5396, AS(Autonomous System) 번호의 텍스트 표현

  • RFC 5492, BGP-4를 통한 기능 보급

  • RFC 5512, BGP encapsulation SAFI(Subsequent Address Family Identifier) 및 BGP 터널 encapsulation 속성

  • RFC 5549, IPv6 다음 홉을 통해 IPv4 NLRI(Network Layer Reachability Information) 보급

  • RFC 5575, flow 사양 규칙의 보급

  • RFC 5668, 4-옥텟 AS 특정 BGP 확장 Community

  • RFC 6286, BGP-4 완전 준수를 위한 AS(Autonomous System)-Wide 고유 BGP 식별자

  • RFC 6368, BGP/MPLS IP VPN에 대한 프로바이더/고객 에지 프로토콜로서의 내부 BGP

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

  • RFC 6811, BGP 접두사 Origin Validation

  • RFC 6996, 개인 사용을 위한 AS(Autonomous System) 예약

  • RFC 7300, 마지막 AS(Autonomous System) 번호 예약

  • RFC 7611, BGP ACCEPT_OWN Community 속성

    Juniper 라우터를 활성화하고 RFC를 지원하여 accept-own 커뮤니티 값으로 경로 리플렉터에서 수신한 경로를 허용합니다.

  • RFC 7752, BGP를 사용한 Link-State 및 트래픽 엔지니어링(TE) 정보 북향 배포

  • RFC 7854, BMP(BGP Monitoring Protocol)

  • RFC 7911, BGP에서 다중 경로 보급

  • RFC 8212, 정책 완전 준수 없이 기본 외부 BGP(EBGP) 경로 구축 동작

    예외:

    RFC 8212의 동작은 기존 고객 구성의 중단을 방지하기 위해 기본적으로 구현되지 않습니다. 기본 동작은 여전히 EBGP 피어와 관련된 모든 경로를 승인하고 보급하기 위해 유지됩니다.

  • RFC 8326, Graceful BGP 세션 Shutdown

  • RFC 9069, BMP(BGP Monitoring Protocol)에서 로컬 RIB 지원

  • 인터넷 초안 draft-idr-rfc8203bis-00, BGP 관리 Shutdown 커뮤니케이션(2018년 10월 만료)

  • 인터넷 초안 draft-ietf-grow-bmp-adj-rib-out-01, BMP(BGP Monitoring Protocol)에서 Adj-RIB-Out 지원(2018년 9월 3일 만료)

  • 인터넷 초안 draft-ietf-idr-aigp-06, BGP에 대한 누적 IGP 메트릭 속성(2011년 12월 만료)

  • 인터넷 초안 draft-ietf-idr-as0-06, AS 0 프로세싱 코드화(2013년 2월 만료)

  • 인터넷 초안 draft-ietf-idr-link-bandwidth-06.txt, BGP 링크 대역폭 확장 커뮤니티(2013년 7월 만료)

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

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

  • 인터넷 초안 draft-kato-bgp-ipv6-link-local-00.txt, IPv6 link-local 주소를 사용한 BGP4+ 피어링

다음 RFC 및 인터넷 초안은 표준을 정의하지 않지만 BGP 및 관련 기술에 대한 정보를 제공합니다. IETF는 이를 "실험적" 또는 "정보성"으로 다양하게 분류합니다.

  • RFC 1965, BGP를 위한 AS(Autonomous System) 컨페더레이션

  • RFC 1966, BGP 경로 리플렉션—풀 메시 IBGP의 대안

  • RFC 2270, 단일 프로바이더에게 호밍된 사이트에 대한 전용 AS 사용

  • 인터넷 초안 draft-ietf-ngtrans-bgp-tunnel-04.txt, BGP를 통해 IPv4 전반에서 IPv6 아일랜드 연결(2002년 7월 만료)

참조

변경 내역 표

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

릴리스
설명
17.2R1
Junos OS 릴리스 17.2R1부터 rpd 확인자 모듈이 인바운드 처리 flow 처리량을 증진할 수 있도록 최적화됩니다. 이를 통해 RIB와 FIB의 학습 속도를 가속할 수 있습니다.
14.1R8
Junos OS 릴리스 14.1R8부터 14.2R7, 15.1 R4, 15.1 F6 및 16.1 R1까지, 라우팅 인스턴스에 대해 as-path-ignore 옵션이 지원됩니다.