보더 게이트웨이 프로토콜

Border Gateway Protocol
「BGP」는 여기서 리다이렉트 됩니다.그 외의 사용법에 대해서는, 「BGP(동음이의인 설명)」를 참조해 주세요.
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

BGP(Border Gateway Protocol)는 [1]인터넷상의 자율 시스템(AS) 간에 라우팅 및 도달 가능성 정보를 교환하도록 설계된 표준화된 외부 게이트웨이 프로토콜입니다.BGP는 Path-Vector [2]Routing Protocol로 분류되며 네트워크 관리자가 설정한 경로, 네트워크 정책 또는 규칙 집합을 기반으로 라우팅 결정을 합니다.

자율 시스템 내에서의 라우팅에 사용되는 BGP는 Interior Border Gateway Protocol, Internal BGP(iBGP)라고 불립니다.반대로, 이 프로토콜의 인터넷 애플리케이션은 External Border Gateway Protocol, External BGP(eBGP)라고 불립니다.

역사

Border Gateway Protocol은 1989년 기술자들에 의해 "세 개의 케첩으로 얼룩진 냅킨"[3] 뒤에 스케치되었으며, 여전히 스리 냅킨 프로토콜로 알려져 있다.1989년 RFC 1105에 처음 기술되어 [4]1994년부터 인터넷에서 사용되고 있습니다.IPv6 BGP 는, 최초로 정의되었습니다. 1994년에는 RFC1654가, 1998년에는 RFC 2283으로 개선되었습니다.

BGP의 현재 버전은 버전 4(BGP4)로 2006년에 [5]RFC 4271로 발행되었습니다.RFC 4271은 오류를 수정하고 모호성을 명확히 하며 업계의 일반적인 관행에 따라 사양을 갱신했습니다.주요 확장 기능은 Classless Inter-Domain Routing(CIDR; 클래스리스 도메인 간 라우팅) 지원 및 라우팅 테이블의 크기를 줄이기 위한 루트 집약 사용입니다.새로운 RFC 에서는, BGP4 는 폭넓은 범위의 IPv4 및 IPv6 「주소 패밀리」를 전송할 수 있습니다.멀티프로토콜 BGP(MP-BGP)라고도 합니다.

작동

BGP 네이버(피어)는 포트 179에 TCP 세션을 작성하기 위해 라우터 간에 수동으로 설정함으로써 확립됩니다.BGP 스피커는 [6]연결을 유지하기 위해 30초마다 19바이트의 킵얼라이브 메시지를 보냅니다(프로토콜 기본값, 조정 가능).라우팅 프로토콜 중에서 BGP는 TCP를 전송 프로토콜로 사용하는 것이 독특합니다.

BGP가 같은 Autonomous System(AS; 자율 시스템)내의 2개의 피어간에 동작하는 경우는, Internal BGP(iBGP 또는 Interior Border Gateway Protocol)라고 불립니다.다른 자율 시스템 간에 동작하는 경우는, 외부 BGP(eBGP 또는 외부 경계 게이트웨이 프로토콜)라고 불립니다.어떤 AS가 다른 AS와 정보를 교환하는 경계에 있는 라우터는 보더 라우터 또는 엣지 라우터 또는 단순히 eBGP 피어라고 불리며 일반적으로 직접 접속됩니다.iBGP 피어는 다른 중간 라우터를 통해 상호 접속할 수 있습니다.VPN 터널 내에서 eBGP 피어링을 실행하여 2개의 리모트사이트가 안전하고 격리된 방법으로 라우팅 정보를 교환할 수 있도록 하는 등 다른 배치 토폴로지도 가능합니다.

iBGP 피어링과 eBGP 피어링의 주요 차이점은 1개의 피어에서 수신된 루트가 디폴트로 다른 피어에 전파되는 방법입니다.

  • eBGP 피어에서 학습한 새로운 루트는 모든 iBGP 및 eBGP 피어에 재애드버타이즈 됩니다.
  • iBGP 피어에서 학습한 새로운 루트는 모든 eBGP 피어에만 재애드버타이즈 됩니다.

이러한 루트 전파 규칙에서는 AS 내의 모든 iBGP 피어가 iBGP 세션과 완전한 메쉬로 상호 접속되어 있어야 합니다.

루트가 전파되는 방법은 루트 맵메커니즘을 통해 상세하게 제어할 수 있습니다.이 메커니즘은 일련의 규칙으로 구성됩니다.각 규칙에서는 특정 기준에 일치하는 루트에 대해 수행해야 할 액션을 설명합니다.루트를 폐기하거나 라우팅 테이블에 삽입하기 전에 루트의 Atribute 일부를 변경하는 경우가 있습니다.

확장 네고시에이션

BGP 스테이트 머신

피어 핸드쉐이크 중에 OPEN 메시지가 교환되면 BGP 스피커는 멀티프로토콜 확장[8] 및 다양한 회복 모드 등 세션의 [7]옵션 기능을 네고시에이트할 수 있습니다.BGP에 대한 멀티프로토콜 확장이 작성 시 네고시에이트 되어 있는 경우, BGP 스피커는 어드버타이즈 하는 Network Layer Reachability Information(NLRI; 네트워크층 도달 가능성 정보)에 주소 패밀리프리픽스를 부가할 수 있습니다.이러한 패밀리에는, IPv4(디폴트), IPv6, IPv4/IPv6 가상 프라이빗 네트워크, 및 멀티 캐스트 BGP 가 포함됩니다.BGP는 VPN [9]등 글로벌인터넷에 속하지 않을 가능성이 있는 루트에 관한 정보를 전송하기 위한 범용 시그널링 프로토콜로 사용되고 있습니다.

BGP 피어는, 피어와의 동작에 관한 결정을 내리기 위해서, 다음의 6개의 스테이트로 이루어진 Simple Finite State Machine(FSM; 단순 유한 상태 머신)을 사용합니다.Idle, Connect, Active, OpenSent, OpenConfirm 및 Established.각 피어 투 피어 세션에 대해서, BGP 실장에서는, 세션이 어느 상태에 있는지를 추적하는 상태 변수가 유지됩니다.BGP는 세션을 어떤 상태에서 다른 상태로 변경하기 위해 각 피어가 교환해야 하는 메시지를 정의합니다.

첫 번째 상태는 Idle 상태입니다.아이돌 상태에서는, BGP 는 모든 자원을 초기화해, 모든 착신 BGP 접속의 시행을 거부해, 피어에의 TCP 접속을 개시합니다.두 번째 상태는 Connect입니다.Connect 상태에서 라우터는 TCP 접속이 완료될 때까지 대기하고 성공하면 OpenSent 상태로 이행합니다.실패하면 ConnectRetry 타이머가 시작되고 유효기간이 만료되면 Active 상태로 이행합니다.Active 상태에서 라우터는 ConnectRetry 타이머를 제로로 리셋하고 Connect 상태로 돌아갑니다.OpenSent 상태에서 라우터는 OpenConfirm 상태로 이행하기 위해 Open 메시지를 발송하고 OpenConfirm 메시지를 기다립니다.킵얼라이브 메시지가 교환되어 정상적으로 수신되면 라우터는 Established 상태가 됩니다.Established 상태에서는 라우터는 피어와의 사이에서 Keepalive, Update 및 Notification 메시지를 송수신할 수 있습니다.

  • 아이돌 상태:
    • 착신 BGP 접속을 모두 거부합니다.
    • 이벤트 트리거의 초기화를 시작합니다.
    • 설정되어 있는 BGP 피어와의 TCP 접속을 개시합니다.
    • 피어로부터의 TCP 접속을 수신합니다.
    • 상태를 Connect로 변경합니다.
    • FSM 프로세스의 어느 하나의 스테이트에서 에러가 발생했을 경우, BGP 세션은 즉시 종료되어 Idle 스테이트로 돌아옵니다.라우터가 아이돌 상태에서 진행되지 않는 이유는 다음과 같습니다.
      • TCP 포트 179가 열려 있지 않습니다.
      • 1023을 넘는 랜덤 TCP 포트는 오픈되지 않습니다.
      • 어느 라우터에서도 피어 주소가 올바르게 설정되어 있지 않다.
      • 어느 라우터에서도 AS 번호가 올바르게 설정되어 있지 않습니다.
  • 연결 상태:
    • 피어와의 TCP 네고시에이션이 성공할 때까지 기다립니다.
    • TCP 세션이 정상적으로 확립되어 있는 경우, BGP 는 이 스테이트에 많은 시간을 소비하지 않습니다.
    • Open 메시지를 피어에 보내고 상태를 OpenSent로 변경합니다.
    • 에러가 발생하면, BGP 는 Active 상태로 이행합니다.에러의 원인은 다음과 같습니다.
      • TCP 포트 179가 열려 있지 않습니다.
      • 1023을 넘는 랜덤 TCP 포트는 오픈되지 않습니다.
      • 어느 라우터에서도 피어 주소가 올바르게 설정되어 있지 않다.
      • 어느 라우터에서도 AS 번호가 올바르게 설정되어 있지 않습니다.
  • 활성 상태:
    • 라우터가 TCP 세션을 정상적으로 확립할 수 없었던 경우는, 액티브 상태가 됩니다.
    • BGP FSM은 피어와의 다른 TCP 세션을 재기동하려고 하고 성공하면 피어에 Open 메시지를 보냅니다.
    • 다시 실패하면 FSM은 Idle 상태로 리셋됩니다.
    • 장애가 반복되면 라우터가 Idle 상태와 Active 상태를 순환할 수 있습니다.여기에는 다음과 같은 이유가 있습니다.
      • TCP 포트 179가 열려 있지 않습니다.
      • 1023을 넘는 랜덤 TCP 포트는 오픈되지 않습니다.
      • BGP 설정 오류입니다.
      • 네트워크의 congestion.
      • 플래핑 네트워크인터페이스
  • OpenSent 상태:
    • BGP FSM은 피어로부터의 오픈메시지를 리슨합니다.
    • 메시지가 수신되면 라우터는 Open 메시지의 유효성을 확인합니다.
    • 에러가 발생했을 경우, 피어간에 Open 메시지의 필드 중 하나가 일치하지 않기 때문입니다(BGP 버전의 불일치, 피어 라우터는 다른 My AS 를 상정하고 있는 등).다음으로 라우터는 에러가 발생한 이유를 나타내는 통지 메시지를 피어에 송신합니다.
    • 오류가 없으면 킵얼라이브 메시지가 발송되고 다양한 타이머가 설정되며 상태가 OpenConfirm으로 변경됩니다.
  • OpenConfirm 상태:
    • 피어는 피어로부터의 킵얼라이브 메시지를 수신하고 있습니다.
    • 킵얼라이브 메시지가 수신되고 킵얼라이브 수신 전에 타이머가 만료되지 않은 경우 BGP는 Established 상태로 이행합니다.
    • 킵얼라이브 메시지가 수신되기 전에 타이머가 만료되거나 오류 상태가 발생하면 라우터는 Idle 상태로 돌아갑니다.
  • 확립된 상태:
    • 이 상태에서는 피어는 업데이트메시지를 발송하여 BGP 피어에 애드버타이즈되는 각 루트에 대한 정보를 교환합니다.
    • Update 메시지에 오류가 있으면 알림 메시지가 피어에 전송되고 BGP는 Idle 상태로 돌아갑니다.

라우터 접속 경로 및 학습 경로

가장 간단한 방법으로 단일 AS 내에서 BGP 라우팅에 참여하는 모든 라우터를 풀 메쉬로 설정해야 합니다.각 라우터는 다른 모든 라우터에 대한 피어(peer)로 설정해야 합니다.이로 인해 필요한 접속 수가 관련된 라우터의 수에 따라 2차적으로 증가하기 때문에 스케일링 문제가 발생합니다.이 문제를 완화하기 위해 BGP는 루트 리플렉터(RFC 4456)와 BGP 컨페더레이션(RFC 5065)의 2가지 옵션을 실장합니다.다음 기본 업데이트 처리에 대한 설명은 완전한 iBGP 메쉬를 전제로 합니다.

소정의 BGP 라우터는 여러 네이버로부터의 Network-Layer Reachability Information(NLRI; 네트워크층 도달 가능성 정보) 업데이트를 받아들여 NLRI를 동일 또는 다른 네이버세트에 애드버타이즈 할 수 있습니다.개념적으로 BGP는 라우터의 메인라우팅 테이블과는 별도로 Local Routing Information Base(Loc-RIB; 로컬라우팅 정보 베이스)라고 불리는 독자적인 마스터라우팅 테이블을 유지합니다.BGP 프로세스에서는 네이버별로 개념적인 인접 라우팅 정보 베이스, 네이버로부터 수신한 NLRI를 포함한 착신(Adj-RIB-In) 및 NLRI가 네이버에 송신되는 개념적인 발신 정보 베이스(Adj-RIB-Out)가 유지됩니다.

이러한 개념 테이블의 물리 스토리지와 구조는 BGP 코드의 실장자에 의해 결정됩니다.이러한 구조는 다른 BGP 라우터에서는 볼 수 없지만 보통 로컬라우터 상에서 관리 명령어를 사용하여 조회할 수 있습니다.예를 들어, 2개의 Adj-RIB와 Loc-RIB를 같은 데이터 구조 내에 함께 저장하고 RIB 엔트리에 추가 정보를 부가하는 것은 매우 일반적입니다.추가 정보는 BGP 프로세스에 대해 특정 네이버의 Adj-RIB에 개개의 엔트리가 속해 있는지 여부, 피어 네이버루트 선택 프로세스에 의해 수신된 정책이 Loc-RIB에 적합하게 되어 있는지 여부, Loc-RIB 엔트리가 로컬라우터의 라우팅 테이블 관리 프로세스에 송신될 수 있는지 여부 등의 정보를 제공합니다.

BGP는 최선이라고 생각되는 루트를 메인라우팅 테이블프로세스에 송신합니다.이 프로세스의 실장에 따라서는, 반드시 BGP 루트가 선택되는 것은 아닙니다.예를 들어 라우터의 자체 하드웨어에서 학습한 직접 연결된 프레픽스가 일반적으로 가장 선호됩니다.직접 접속되어 있는 루트의 인터페이스가 액티브한 한, 행선지에의 BGP 루트는 라우팅 테이블에 배치되지 않습니다.인터페이스가 다운되어 우선 루트가 없어지면 Loc-RIB 루트가 메인라우팅 테이블에 설치됩니다.

BGP 는, BGP 스피킹 라우터내의 룰이 정책을 결정할 수 있는 정보를 전달합니다.정책 결정에 사용되도록 명시적으로 의도된 일부 정보는 지역사회와 Multi-Exit Discriminator(MED; 멀티 출구 식별자)이다.

BGP 표준에서는 Loc-RIB에 들어가는 NLRI를 선택하기 위해 다른 일반적인 라우팅 프로세스에서 사용되는 결정 요인보다 많은 결정 요인이 지정되어 있습니다.NLRI를 평가하는 첫 번째 결정 포인트는 넥스트홉 Atribut이 도달 가능(또는 해결 가능)해야 한다는 것입니다.넥스트 홉이 도달 가능해야 함을 나타내는 또 다른 방법은 넥스트홉 주소가 도달 가능한 프레픽스에 대한 액티브루트가 이미 라우터의 메인라우팅 테이블에 존재해야 한다는 것입니다.

다음으로 BGP 프로세스는 네이버별로 다양한 표준 및 구현 의존 기준을 적용하여 개념적으로 Adj-RIB-In에 들어갈 루트를 결정합니다.네이버는 수신처에 여러 루트를 전송할 수 있지만 첫 번째 프리퍼런스레벨은 네이버레벨입니다개념상의 Adj-RIB-In에는, 각 행선지에의 루트가 1개만 인스톨 됩니다.이 프로세스에서는 인접 라우터에 의해 취소된 루트도 Adj-RIB-In에서 삭제됩니다.

개념적인 Adj-RIB-In이 변경될 때마다 메인 BGP 프로세스는 Loc-RIB에 이미 있는 루트보다 네이버의 새로운 루트 중 하나가 우선되는지 여부를 판단합니다.이 경우, 그 대신 사용됩니다.특정 루트가 네이버에 의해 취소되고 그 수신처에 대한 다른 루트가 없는 경우 루트는 Loc-RIB에서 삭제되며 BGP에 의해 메인라우팅 테이블 매니저로 전송되지 않습니다.라우터에 비 BGP 송신원으로부터 그 행선지에의 루트가 없는 경우, 취소된 루트는 메인라우팅 테이블에서 삭제됩니다.

넥스트 홉이 도달 가능한지 확인한 후 루트가 내부(iBGP 등) 피어에서 온 경우 표준에 따라 적용되는 첫 번째 규칙은 로컬프리퍼런스 속성을 확인하는 것입니다네이버로부터의 iBGP 루트가 여러 개 있는 경우 로컬프리퍼런스가 같은 루트가 여러 개 없는 한 로컬프리퍼런스가 가장 높은 루트가 선택됩니다후자의 경우 루트 선택 프로세스는 다음 타이브레이커로 이동합니다.표준에서는 로컬프리퍼런스가 첫 번째 규칙이지만 넥스트홉의 도달 가능성이 확인되면 시스코 및 기타 여러 벤더는 우선 라우터에 로컬한(BGP에 의해 전송되지 않음) 중량이라고 불리는 결정 계수를 검토합니다.무게가 가장 큰 루트가 우선됩니다.

로컬 프리퍼런스, 무게 및 기타 기준은 로컬 설정 및 소프트웨어 기능에 의해 조작할 수 있습니다.이러한 조작은 일반적으로 사용되기는 하지만 표준의 범위를 벗어난다.예를 들어 커뮤니티 어트리뷰트(아래 참조)는 BGP 선택 프로세스에서 직접 사용되지 않습니다.단, BGP 네이버프로세스에는 커뮤니티 값이 패턴 일치 기준에 일치할 경우 수동으로 프로그래밍된 규칙에 따라 로컬프리퍼런스 또는 다른 요인을 설정하는 규칙을 설정할 수 있습니다.루트가 외부 피어에서 학습된 경우 네이버별 BGP 프로세스는 로컬정책 규칙에서 로컬프리퍼런스 값을 계산하여 네이버로부터의 모든 루트의 로컬프리퍼런스를 비교합니다

네이버 단위 수준에서 구현 고유의 정책 수식자를 무시하면 연계 해제 규칙의 순서는 다음과 같습니다.

  1. AS 패스가 가장 짧은 루트를 우선합니다.AS 패스는, 애드버타이즈 된 행선지에 도달하기 위해서 통과할 필요가 있는 AS 번호의 세트입니다.AS1 – AS2 – AS3는 AS4 – AS5보다 짧습니다.AS6– AS7
  2. ORIGIN Atribute 값이 가장 작은 루트를 우선합니다.
  3. Multi-Exit Discriminator([a]MED) 값이 가장 작은 루트를 우선합니다.

후보 루트가 네이버로부터 수신되면 Loc-RIB 소프트웨어는 같은 수신처에 대한 루트에 추가 타이 브레이커를 적용합니다.

  1. 적어도 1개의 루트가 외부 네이버에서 학습된 경우(즉, 루트가 eBGP에서 학습된 경우), iBGP에서 학습된 모든 루트를 폐기합니다.
  2. 메인 라우팅 테이블에 따르면 넥스트홉보다 내부 비용이 가장 낮은 루트를 우선합니다.2개의 네이버가 같은 루트를 애드버타이즈 하는데 한쪽 네이버가 저비트레이트링크 경유로, 다른 한쪽 네이버가 고비트레이트링크 경유로 도달 가능하며 내부 라우팅 프로토콜이 최고 비트환율을 기반으로 최저 비용을 계산하면 고비트레이트 링크를 통과하는 루트가 우선되고 다른 루트가 폐기됩니다.
이 시점에서 아직 여러 루트가 연결되어 있는 경우, 여러 BGP 실장에서는 루트 간에 로드 쉐어링을 실시하여 모든 것(또는 최대 몇 개까지)을 받아들이도록 설정할 수 있는 옵션이 제공됩니다.
  1. BGP 스피커에서 학습한 루트를 BGP ID가 수치적으로 가장 작은 루트로 우선합니다.
  2. 피어 IP 주소가 최소인 BGP 스피커에서 학습한 루트를 우선합니다.

커뮤니티

BGP 커뮤니티는,[10] 착신 프리픽스 또는 발신 프리픽스에 적용되어 공통의 목적을 달성할 수 있는 속성 태그입니다.BGP를 통해 관리자가 ISP에 의한 프레픽스 처리 방법에 관한 정책을 설정할 수 있다고 하는 것이 일반적이지만, 엄밀하게 말하면 이것은 일반적으로 불가능합니다.예를 들어, BGP에서는, 1개의 AS가 다른 AS에 프리픽스의 애드버타이즈먼트를 북미의 피어링 고객에 한정하는 것을 허가하는 개념이 기본적으로 없습니다.대신 ISP는 일반적으로 각 커뮤니티에 대한 설명과 함께 잘 알려진 커뮤니티 또는 독자 커뮤니티 목록을 공개합니다.이 목록은 기본적으로 프레픽스 처리 방법에 대한 합의가 됩니다.RFC 1997에서는 글로벌하게 중요한3개의 기존 커뮤니티(NO_EXPORT, NO_ADVERTISE 및 NO_EXPORT_SUBCONFED)가 정의되어 있습니다.RFC 7611에서는 ACCEPT_OWN이 정의되어 있습니다.공통 커뮤니티의 예로는 로컬프리퍼런스 조정, 지리적 또는 피어 타입의 제한, 서비스 거부 공격 식별, AS 프리펜딩 옵션 등이 있습니다.ISP는 커뮤니티 XXX:500을 가진 고객으로부터 수신한 루트가 모든 피어(디폴트)에 애드버타이즈 되는 반면 커뮤니티 XXX:501은 북미에만 애드버타이즈 되는 경우가 있습니다.고객은 각 루트의 올바른 커뮤니티를 포함하도록 설정을 조정하기만 하면 되며, ISP는 프리픽스가 애드버타이즈되는 사용자를 제어할 책임이 있습니다.이 영역의 문제는 일반적으로 드물고 우발적이지만 최종 사용자는 ISP에 의한 올바른 조치를 강제할 수 있는 기술적 능력이 없습니다.

최종사용자는 BGP 커뮤니티(통상은 ASN:70,80,90,100)를 사용하여 ISP가 MED를 사용하는 대신 애드버타이즈된 루트에 할당하는 로컬프리퍼런스를 제어하는 일반적인 방법입니다(효과는 비슷합니다).커뮤니티 어트리뷰트는 transitive이지만 고객이 적용한 커뮤니티는 넥스트홉 AS 외부로 전파되는 경우는 없습니다.모든 ISP가 커뮤니티를 일반에 [11]제공하는 것은 아닙니다.

BGP 확장 커뮤니티 어트리뷰트는 이러한 어트리뷰트의 범위를 확장하고 유형 필드에 의한 커뮤니티 어트리뷰트 구조화를 제공하기 위해 2006년에 추가되었습니다.확장 포맷은 type 필드의 1개 또는2개의 옥텟에 이어 각 커뮤니티 Atribute 콘텐츠의 7개 또는6개의 옥텟으로 구성됩니다.이 확장 커뮤니티 어트리뷰트의 정의는 RFC 4360에 기재되어 있습니다.IANA는, BGP 확장 커뮤니티 [12]타입의 레지스트리를 관리합니다.Extended Communitys Attribute 자체는 Transitional 옵션 BGP Attribute입니다.단, Atribute 내의 type 필드 내의 비트에 따라 부호화된 확장 커뮤니티가 transitive 또는 non-transitive 중 어느 쪽인지 결정됩니다.따라서 IANA 레지스트리는 Atribut 타입에 대해 다른 번호 범위를 제공합니다.확장된 속성 범위로 인해 그 용도는 다양할 수 있습니다.RFC 4360 에서는, 「2 옥텟 AS 고유 확장 커뮤니티」, 「IPv4 주소 고유 확장 커뮤니티」, 「Opaque 확장 커뮤니티」, 「루트 타겟 커뮤니티」, 및 「루트 오리진 커뮤니티」의 예를 정의하고 있습니다.다수의 BGP QoS 초안에서는 도메인 간 QoS [13]시그널링에도 이 확장 커뮤니티 속성 구조가 사용됩니다.

32비트 AS 번호의 도입으로 이 필드와 실제 ASN 값의 조회가 방해되는 16비트 ASN 필드만을 정의하는 커뮤니티 속성에서 몇 가지 문제가 즉시 발견되었습니다.RFC 7153 이후 확장 커뮤니티는 32비트 ASN과 호환성이 있습니다.RFC 8092 및 RFC 8195에서는 각각4 바이트의 3개의 필드로 분할된12 바이트의 Large Community Atribute가 도입되어 있습니다(AS: function: parameter).[14]

다중 출구 식별자

메인 BGP 표준에 정의되어 있는MED는 원래 착신 트래픽에 대해 어떤 링크가 우선되는지에 대한 애드버타이즈 AS의 프리퍼런스를 다른 네이버 AS에 표시하는 것을 목적으로 하고 있었습니다.MED 의 또 다른 어플리케이션에서는, IXP 에 존재하는 복수의 AS 의 값(통상은 지연에 근거해)을 어드버타이즈 해, 트래픽을 특정의 행선지에 송신하는 것이 있습니다.

메시지 헤더 형식

BGP 버전4 메시지헤더[15] 형식
비트 오프셋 0–15 16–23 24–31
0 마커
32
64
96
128 길이 유형
  • 마커: 호환성을 위해 포함되며, 모두로 설정해야 합니다.
  • [Length] : 헤더를 포함한 옥텟 단위의 메시지의 총 길이.
  • 유형: BGP 메시지 유형.다음 값이 정의되어 있습니다.
    • 오픈 (1)
    • 갱신(2)
    • 통지(3)
    • 킵얼라이브 (4)
    • 루트 리프레쉬(5)

내부 확장성

BGP는 '모든 라우팅 프로토콜 [16]중 가장 확장성이 높다'고 할 수 있습니다.

내부 BGP(iBGP)를 갖춘 자율 시스템에서는 모든 iBGP 피어가 풀 메쉬로 서로 접속되어 있어야 합니다(모두와 직접 대화합니다).이 풀 메쉬 설정에서는, 각 라우터가 다른 모든 라우터와의 세션을 유지할 필요가 있습니다.대규모 네트워크에서는 메모리 부족 또는 CPU 프로세스 요건이 높기 때문에 이 세션 수가 라우터의 성능을 저하시킬 수 있습니다.

루트 리플렉터

Route Reflector(RR; 루트 리플렉터)는 AS에서 필요한 연결 수를 줄입니다.1대의 라우터(용장성의 경우는 2대)를 RR로 할 수 있습니다.AS 내의 다른 라우터는 라우터의 피어로서만 설정할 필요가 있습니다.RR은 iBGP의 논리 풀 메쉬 요건 대신 사용할 수 있습니다.RR의 목적은 집중력입니다.복수의 BGP 라우터는, 풀 메쉬내의 다른 모든 라우터와 피어링 하는 것이 아니라, RR 서버로서 기능하는 중앙 포인트와 피어링 할 수 있습니다.다른 모든 iBGP 라우터는 RR [17]클라이언트가 됩니다.

이 접근방식은 OSPF의 DR/BDR 기능과 마찬가지로 대규모 네트워크에 iBGP 확장성을 추가합니다.10대의 라우터로 이루어진 풀 메쉬 iBGP 네트워크에서는 각 피어의 리모트 AS를 정의하기 위해서만 90개의 개별 CLI 스테이트먼트(토폴로지 내의 모든 라우터에 분산)가 필요합니다.이것은, 곧바로 관리가 골칫거리가 됩니다.RR 토폴로지는 이러한 90개의 문을 18개로 줄일 수 있기 때문에 ISP에 의해 관리되는 대규모 네트워크에 실행 가능한 솔루션을 제공할 수 있습니다.

RR은 단일 장애점이므로 용장성을 제공하기 위해 적어도두 번째 RR을 설정할 수 있습니다.다른 10대의 라우터에 대한 추가 피어이므로 CLI 문의 수는 약 2배가 됩니다.이 경우 11 × 2 - 2 = 20개의 추가 문이 필요합니다.BGP 멀티패스 환경에서는 RR이 전용 RR 서버 역할뿐만 아니라 기존 라우터로서 기능하는 경우 로컬라우팅 스루풋을 추가하는 것으로, 네트워크에 메리트를 줄 수도 있습니다.

규칙.

섹션 6, RFC 4456에서 제안하는 BGP RR 배치의 일반적인 설정.

RR 서버는 다음 규칙에 따라 AS 내부에 루트를 전파합니다.

  • 루트는 항상 eBGP 피어에 반영됩니다.
  • 루트는 루트의 발신자에 반영되지 않습니다.
  • 비클라이언트 피어로부터 루트를 수신했을 경우는, 클라이언트피어에 반영합니다.
  • 클라이언트 피어로부터 루트를 수신했을 경우는, 클라이언트피어 및 비클라이언트피어에 반영합니다.

클러스터

RR과 그 클라이언트는 클러스터를 형성합니다.다음으로 클러스터 ID는 RR에 의해 클라이언트피어 또는 비클라이언트피어에 애드버타이즈되는 모든 루트에 부가됩니다.클러스터 ID는 누적적이고 비전이적인 BGP Atribut으로 라우팅 루프를 피하기 위해 모든 RR이 로컬클러스터 ID를 클러스터 목록에 부가해야 합니다.RR 및 컨페더레이션 모두 각 라우터에 대한 iBGP 피어 수를 줄이고 처리 오버헤드를 줄입니다.RR은 순수 퍼포먼스 향상 기술이지만 컨페더레이션은 보다 세밀한 정책 구현에도 사용할 수 있습니다.

BGP 컨페더레이션

컨페더레이션은 자율 시스템 세트입니다.일반적으로 [18]컨페더레이션 AS 번호는 인터넷 전체에서1개만 표시됩니다.컨페더레이션은 대규모 네트워크에서 사용되며, 대규모 AS는 보다 작고 관리하기 쉬운 내부 AS를 포함하도록 설정할 수 있습니다.

연합된 AS는 여러 AS로 구성됩니다.컨페더레이션된 각 AS만 iBGP 풀메쉬로 컨페더레이션 내의 다른 AS에 접속합니다.이러한 AS에는 컨페더레이션 내의 AS에 대한eBGP 피어가 있는데도 AS는 iBGP를 사용하고 있는 것처럼 루팅을 교환합니다.이와 같이 컨페더레이션은 넥스트홉, 메트릭 및 로컬프리퍼런스 정보를 유지합니다.외부에서는 컨페더레이션이 단일 AS로 보입니다.이 솔루션을 사용하면 iBGP는 모든 BGP 라우터 간에 대량의 TCP 세션과 불필요한 라우팅 트래픽 복제 등 풀메쉬를 필요로 하기 때문에 iBGP 중계 AS 문제를 해결할 수 있습니다.

컨페더레이션은 루트 리플렉터와 조합하여 사용할 수 있습니다.컨페더레이션과 루트 리플렉터 모두 BGP와 내부 라우팅 프로토콜 모두에 영향을 주는 특정 설계 규칙을 [19]따르지 않는 한 영속적인 발진이 발생할 수 있습니다.

다만, 이러한 대체 수단에서는, 다음과 같은 독자적인 문제가 발생할 가능성이 있습니다.

  • 경로 진동
  • 최적이 아닌 라우팅
  • BGP 컨버전스[20] 시간의 증가

또, 루트 리플렉터와 BGP 컨페더레이션은, BGP 라우터의 설정을 용이하게 하도록 설계되어 있지 않습니다.다만, 이것들은 경험이 풍부한 BGP 네트워크 아키텍트에게 있어서 일반적인 툴입니다.이러한 툴은 예를 들어 루트 리플렉터의 계층으로서 조합할 수 있습니다.

안정성.

BGP 실장에 의해 관리되는 라우팅 테이블은 링크의 절단 및 복원, 라우터의 정지 및 복귀 등 네트워크 내의 실제 변경을 반영하기 위해 지속적으로 조정됩니다.네트워크 전체에서는 이러한 변경이 거의 연속적으로 발생하는 것은 정상이지만, 특정 라우터 또는 링크에 대해서는 변경은 비교적 드물 것으로 생각됩니다.라우터가 잘못 설정되어 있거나 잘못 관리되고 있는 경우, 다운 스테이트와 업스테이트의 사이에 급속한 사이클이 발생하는 일이 있습니다.루트 플랩핑이라고 불리는 이 반복적인 탈퇴 및 재방송 패턴에 의해 같은 루트가 라우팅 테이블에서 지속적으로 삽입 및 탈퇴되기 때문에 파손된 링크를 인식하고 있는 다른 모든 라우터에서 과도한 액티비티가 발생할 수 있습니다.BGP 설계에서는 루트 갱신 중에는 트래픽 전달이 기능하지 않을 수 있습니다.인터넷에서는, BGP 라우팅이 변경되면, 몇분간 정지하는 일이 있습니다.

루트 플랩핑의 영향을 경감하기 위해 루트플랩 댐핑(RFC 2439)이라고 불리는 기능이 많은 BGP 실장에 포함되어 있습니다.댐핑이 없을 경우 과도한 액티비티에 의해 라우터에 처리 부하가 걸려 다른 루트의 갱신이 지연되어 라우팅 전체의 안정성에 영향을 줄 수 있습니다.댐핑에서는 루트의 플랩핑이 기하급수적으로 감소합니다.루트를 사용할 수 없게 되어 재빠르게 다시 표시되는 첫 번째 경우, BGP의 통상적인 페일오버 시간을 유지하기 위해서, 댐핑은 유효하게 되지 않습니다.두 번째 오카렌스에서는 BGP는 일정 기간 프리픽스를 배제합니다.이후의 오카렌스는 지수적으로 타임아웃 됩니다.이상이 없어지고 문제가 있는 루트에 적절한 시간이 경과한 후 프레픽스를 회복하여 슬레이트를 깨끗이 소거할 수 있습니다.댐핑은 서비스 거부 공격도 완화할 수 있습니다.덤핑 타이밍은 커스터마이즈성이 높습니다.

그것은 또한 RFC2439에("설계 Choices ->, 루트 광고의 안정성에 민감한 억제"에)만약 실내 BGP-4Sessions는(iBGP 세션에 도착하거나 외부 경계 경로 프로토콜 Sessions는(eBGP 세션 또는 단순히라고 불리는 외부 동료들)을 구현된 길은 플랩 제동 기능이 더 바람직하다고 제안한다. 모형으로,내부 피어라고 불리는 프라이;이 방법에서는 루트가 자율 시스템 내에서 플랩될 때 외부 AS로 전파되지 않습니다.eBGP로의 루트를 플랩하면 백본 전체에서 특정 루트에 대해 플랩 체인이 됩니다.이 방법을 사용하면 iBGP 세션의 루트플랩 댐핑 오버헤드도 정상적으로 회피됩니다.

그러나 후속 조사에서는 플랩 감쇠가 실제로 컨버전스 시간을 연장할 수 있으며 링크가 [21][22]플랩되지 않은 경우에도 접속이 중단될 수 있다는 것이 밝혀졌습니다.또한 백본링크와 라우터 프로세서가 고속화됨에 따라 일부 네트워크 설계자는 라우터에 [23]의해 라우팅 테이블에 대한 변경이 훨씬 빠르게 처리될 수 있기 때문에 플랩 댐핑이 예전만큼 중요하지 않을 수 있다고 제안했습니다.이로 인해 RIPE 라우팅 워킹 그룹은 다음과 같이 기술하고 있습니다.「BGP 플랩 댐핑의 현재 실장에서는, ISP 네트워크에서의 플랩 댐핑의 적용은 추천하지 않습니다.플랩 댐핑이 구현되면 해당 네트워크를 운영하는 ISP는 고객 및 인터넷 사용자에게 고객의 콘텐츠와 서비스에 대한 부작용을 일으킬 수 있습니다.이러한 부작용은 플랩 댐핑을 [24]전혀 실행하지 않음으로써 발생하는 영향보다 훨씬 더 심각할 수 있습니다."플랩 댐핑 문제 없이 안정성을 개선하는 것이 현재 연구의 [25]주제입니다.

라우팅 테이블의 증가

인터넷에서의 BGP 테이블 증가
인터넷상의 AS 수와 등록된 AS 수

BGP, 나아가 인터넷인프라스트럭처 전체가 직면한 가장 큰 문제의 하나는 인터넷라우팅 테이블의 증가입니다.글로벌 라우팅 테이블이 확장되어 일부 오래된 라우터가 메모리 요건 또는 테이블 유지보수에 따른 CPU 부하에 대응할 수 없을 경우 이들 라우터는 접속하는 인터넷 부분 간의 효과적인 게이트웨이가 되지 않게 됩니다.또한 더 중요한 것은 큰 라우팅 테이블은 큰 접속 변경 후 안정화(상기 참조)에 시간이 걸리기 때문에 그 사이에 네트워크 서비스를 신뢰할 수 없거나 이용할 수 없게 됩니다.

2001년 후반까지 글로벌 라우팅 테이블은 기하급수적으로 증가하여 결국 접속이 광범위하게 중단될 위험이 있었습니다.이를 방지하기 위해 ISP는 Classless Inter-Domain Routing(CIDR; 클래스리스 도메인 간 라우팅)과 루트 집약을 사용하여 글로벌라우팅 테이블을 가능한 한 작게 유지하기 위해 협력했습니다.이로 인해 라우팅 테이블은 몇 년 동안 선형 프로세스로 성장세가 둔화되었지만, 최종 사용자 네트워크에 의한 멀티호밍에 대한 수요 확대로 2004년 중반에는 다시 초선형 프로세스가 되었습니다.

512k일

적절하게 업데이트되지 않은 모델에 대해 2014년에 Y2K와 같은 오버플로가 발생하였습니다.

2014년 8월(512k일)[26][27] 시점에서 완전한 IPv4 BGP 테이블은 512,000 [28]프리픽스를 초과하고 있었지만, 많은 오래된 라우터는 512k(512,000~524,288)[29][30]의 라우팅 테이블엔트리를 가지고 있었습니다.2014년 8월 12일, 전체 테이블로 인한 운영 중단이 eBay, LastPass 및 Microsoft Azure를 [31]강타했습니다.일반적으로 사용되고 있는 많은 시스코 라우터에는 BGP 애드버타이즈된 루트를 저장하기 위한 고속 콘텐츠주소 지정 메모리의 일종인TCAM이 탑재되어 있습니다.영향을 받는 라우터에서는 TCAM이 512k IPv4 루트 및 256k IPv6 루트로 기본 할당되었습니다.보고된 IPv6 애드버타이즈된 루트의 수는 약 20k에 불과했지만 애드버타이즈된 IPv4 루트의 수는 디폴트 제한에 이르렀습니다.이는 TCAM을 통한 고속 하드웨어 라우팅과는 달리 라우터가 저속 소프트웨어 루팅을 사용하여 문제를 보완하려고 했기 때문에 스필오버 효과를 초래했습니다.이 문제에 대처하기 위한 주된 방법에는, 오퍼레이터가 IPv6 루트용으로 예약된 TCAM의 일부를 재할당해, 보다 많은 IPv4 엔트리를 허가하도록 TCAM 할당을 변경하는 것이 있습니다.이것에 의해, 대부분의 라우터에서 재기동이 필요하게 됩니다.512k의 문제는 많은 IT [32][33][34]전문가들에 의해 예견되었습니다.

512k를 넘는 루트의 수를 실제로 할당한 것은 UTC 07:48에 시작하는 약 15,000개의 새로운 루트가 단시간에 발표되었기 때문입니다.이들 루트의 거의 대부분은 Verizon Autonomous Systems 701 및 705에 대한 것입니다.이는 더 큰 블록의 애그리게이션 해제, 수천 개의 새로운 /24 루트 도입, 라우팅 테이블이 515,000 엔트리에 도달한 결과 작성되었습니다.새로운 루트는 5분 이내에 재집결된 것으로 보이지만 인터넷상의 불안정성은 몇 [35]시간 동안 계속된 것으로 보입니다.Verizon이 라우팅 테이블을 512k엔트리를 넘지 않았더라도 자연스러운 성장에 의해 머지않아 라우팅 테이블이 증가했을 것입니다.

루트 집약은 종종 BGP 글로벌라우팅 테이블의 집약을 개선하기 위해 사용되며, 그 결과 AS 라우터에서 필요한 테이블사이즈를 줄일 수 있습니다.AS1에는 172.16.0.0/16이라는 큰 주소 공간이 할당되어 있습니다.이것은 테이블 내의 1개의 루트로 카운트되지만, 고객의 요건 또는 트래픽엔지니어링 목적에 따라 AS1에서는 172.16.0.0/18, 172.16.64.0/18 및 172.16.128.0/18의 보다 작고 구체적인 루트를 방송하려고 합니다.프리픽스 172.16.192.0/18에는 호스트가 없기 때문에 AS1은 특정 루트 172.16.192.0/18을 방송하지 않습니다.이는 모두 4개의 루트를 방송하는 AS1로 카운트됩니다.

AS2는 AS1로부터의 4개의 루트(172.16.0.0/16, 172.16.0.0/18, 172.16.64.0/18 및 172.16.128.0/18)를 인식합니다.또, 4개의 루트의 카피를 취득할 것인지, 172.16.0/16의 다른 모든 루트가 중복할 것인지를 결정하는 것은 AS2의 라우팅 정책에 달려 있습니다.

AS2 가 프리픽스 172.16.192.0/18 에 데이터를 송신하는 경우는, 루트 172.16.0/16 의 AS1 의 라우터에 송신됩니다.AS1의 라우터에서는 AS1의 라우터 설정에 따라 해당 메시지는 폐기되거나 수신처 도달 불능 ICMP 메시지가 반송됩니다.

AS1이 나중에 루트 172.16.0.0/18, 172.16.64.0/18 및 172.16.128.0/18을 남기고 루트 172.16.0/16을 드롭하면 AS1은 브로드캐스트한 루트 수를 3으로 드롭합니다.AS2는 3개의 루트를 인식하고 AS2의 라우팅 정책에 따라 3개의 루트의 복사본을 저장하거나 프리픽스의 172.16.0/18과 172.16.64.0/18을 172.16.0/17로 집약하여 AS2가 저장하는 루트 수를 172.16.0.0/172.18의 2개로 줄입니다.

AS2 가 프리픽스 172.16.192.0/18 에 데이터를 송신하는 경우는, 172.16.192.0/18 이 라우팅 테이블에 존재하지 않기 때문에, AS2 의 라우터(이전 AS1 이 아님)로 데이터가 드롭 되거나, 행선지 도달 불능 ICMP 메세지가 반송됩니다.

AS 번호 고갈 및 32비트 ASN

RFC 1771(BGP-4)에서는 ASN 64512~65534는 프라이빗용으로 예약되어 있기 때문에(BGP-4는 금지되어 있습니다), 64510의 가능한 퍼블릭 AS에 대해 16비트로 AS 번호의 부호화를 계획하고 있습니다.2011년에는 15,000개의 AS 번호만 사용할 수 있었고 2013년[36] 9월에는 사용 가능한 AS 번호가 완전히 고갈될 것으로 예상되었습니다.

RFC 6793에서는 AS 코딩이 16비트에서32비트(16비트 AS 범위 0 ~65535 및 그 예약된 AS 번호 유지)로 확장되어 최대 40억의 AS를 사용할 수 있게 되었습니다.RFC 6996 에는, 한층 더 프라이빗 AS 범위도 정의되어 있습니다(4200000000 ~4294967294, 4294967295는 RFC 7300에서는 금지되어 있습니다).

이러한 새로운 ASN을 관리할 수 없는 라우터 그룹의 통과를 허용하기 위해 새로운 Atribut OT AS4_PATH가 사용됩니다.

32비트 ASN 할당은 2007년에 시작되었습니다.

로드 밸런싱

라우팅 테이블의 증가를 일으키는 또 다른 요인은 멀티홈네트워크 로드밸런싱의 필요성입니다.BGP 루트 선택 프로세스의 제한에 의해 멀티홈네트워크에 대한 착신 트래픽의 밸런스를 복수의 착신 패스로 실시하는 것은 간단한 작업이 아닙니다.멀티홈 네트워크의 경우, 모든 BGP 피어간에 같은 네트워크 블록을 아나운스 하는 경우, 외부 네트워크 모두가 그 congestion 패스 세트를 최적으로 선택했기 때문에, 그 결과, 착신 링크의 1개 또는 복수의 congestion가 발생하고, 다른 링크의 사용율이 저하하는 경우가 있습니다.대부분의 다른 라우팅 프로토콜과 마찬가지로 BGP는 congestion를 검출하지 않습니다.

이 문제를 회피하기 위해 그 멀티홈네트워크의 BGP 관리자는 인접하는 큰 IP 주소 블록을 작은 블록으로 분할하여 루트 방송을 조정하여 다른 블록이 다른 경로에서 최적으로 보이도록 함으로써 외부 네트워크가 그 멀티홈네트워크의 다른 블록에 도달하는 다른 경로를 선택할 수 있습니다.이러한 경우 글로벌 BGP 테이블에 표시되는 루트 수가 증가합니다.

로드밸런싱 문제에 대처하기 위해 널리 보급되고 있는 방법 중 하나는 인터넷 교환 포인트 내에 BGP/LISP(Locator/Identifier Separation Protocol) 게이트웨이를 배치하여 여러 링크에서 입력 트래픽엔지니어링을 가능하게 하는 것입니다.이 방법을 사용해도 글로벌 BGP 테이블에서 볼 수 있는 루트의 수는 증가하지 않습니다.

보안.

'BGP 하이잭'도 참조해 주세요.

기본적으로는 BGP를 실행하고 있는 라우터는 다른 BGP 라우터로부터의 애드버타이즈된 루트를 받아들입니다.이것에 의해, 인터넷을 개입시켜 트래픽을 자동적으로 분산 라우팅 할 수 있게 됩니다만, BGP 하이잭이라고 불리는 우발적 또는 악의적 중단에 인터넷이 취약해질 가능성도 있습니다.BGP가 인터넷의 핵심 시스템에 내장되어 있는 정도와 인터넷을 구성하는 많은 다른 조직에 의해 운용되는 다양한 네트워크의 수에 따라 (BGP 라우터의 ID를 검증하기 위한 암호 키 사용 등) 이 취약성을 수정하는 것은 기술적으로나 경제적으로도 중요합니다.냉혹하게 어려운 [37]문제

내선번호

BGP에 대한 확장은 멀티패스를 사용하는 것입니다.일반적으로 동일한 MED, 가중치, 오리진 및 AS 패스가 필요합니다.다만, 일부 실장에서는, AS 패스 체크를 완화해, 패스내의 실제의 AS 번호도 일치하는 것이 아니고, 같은 패스 길이만을 상정하는 기능이 있습니다.그 후 시스코의 dmzlink-bw 등의 기능을 사용하여 이 기능을 더욱 확장할 수 있습니다.이 기능을 사용하면 개개의 링크에 설정된 대역폭 값에 따라 트래픽 공유 비율을 설정할 수 있습니다.

Multiprotocol Extensions for BGP(MBGP)는 Multiprotocol BGP 또는 Multicast BGP라고도 불리며 IETF RFC 4760에서 정의되어 있는 (BGP)에 대한 확장입니다.이 확장에서는 다양한 유형의 주소(주소 패밀리라고 불립니다)를 병렬로 배포할 수 있습니다.표준 BGP 는 IPv4 유니캐스트주소만을 서포트하고 있습니다만, 멀티프로토콜 BGP 는 IPv4 및 IPv6 주소를 서포트해, 각각의 유니캐스트 및 멀티 캐스트 배리언트를 서포트합니다.멀티프로토콜 BGP 를 사용하면, IP 멀티 캐스트 대응 라우터의 토폴로지에 관한 정보를 통상의 IPv4 유니캐스트라우터의 토폴로지와는 별도로 교환할 수 있습니다.따라서 유니캐스트라우팅 토폴로지와는 다른 멀티캐스트라우팅 토폴로지를 사용할 수 있습니다.MBGP는 도메인 간 멀티캐스트라우팅 정보의 교환을 가능하게 하지만, 트리를 구축하고 멀티캐스트트래픽을 전송하기 위해서는 Protocol Independent Multicast 패밀리와 같은 다른 프로토콜이 필요합니다.

또한 MPLS L3 VPN의 경우 다른 고객 사이트에서 라우팅용으로 트래픽이 Provider Edge Router(PE 라우터)에 도달했을 때 서로 다른 고객 사이트를 구별하기 위해 MPLS 네트워크를 통해 고객 사이트에서 학습된 VPN 라벨을 교환하기 위해 멀티프로토콜 BGP가 널리 배치됩니다.

사용하다

BGP4는 인터넷라우팅의 표준 규격으로 대부분의 Internet Service Provider(ISP; 인터넷서비스 프로바이더)가 서로 간의 루팅을 확립하기 위해 필요합니다.매우 큰 프라이빗 IP 네트워크에서는 내부적으로 BGP가 사용됩니다.예를 들어 OSPF 자체가 필요한 크기까지 확장되지 않는 경우 다수의 대규모 Open Shortest Path First(OSPF) 네트워크에 가입할 수 있습니다.BGP를 사용하는 또 다른 이유는 다중성을 높이기 위해 단일 ISP의 여러 액세스포인트 또는 여러 ISP에 대한 네트워크를 멀티호밍하는 것입니다.

실장

라우터, 특히 Small Office/Home Office(SOHO; Small Office/Home Office)용으로 설계된 소형 라우터에는 BGP 소프트웨어가 포함되지 않을 수 있습니다.일부 SOHO 라우터는 단순히 BGP를 실행하거나 어떤 크기의 BGP 라우팅 테이블을 사용할 수 없습니다.다른 상용 라우터에는 BGP를 포함한 특정 소프트웨어 실행 가능 이미지 또는 BGP를 이노블로 하는 라이선스가 필요할 수 있습니다.BGP를 실행하는 오픈소스 패키지에는 GNU Zebra, Quagga, OpenBGPD, BORD, XORP 및 Vyatta가 있습니다.레이어 3 스위치로 시판되는 디바이스는 라우터로 시판되는 디바이스보다 BGP를 지원할 가능성은 낮지만 일반적으로 하이엔드 레이어3 스위치에서는 BGP를 실행할 수 있습니다.

스위치로 시판되는 제품에서는 20,000개의 루트 등 BGP 테이블의 사이즈 제한이 있을 수도 있고 없을 수도 있습니다.이는 완전한 인터넷테이블과 내부 루트보다 훨씬 작습니다.단, 이러한 디바이스는 네트워크의 일부 작은 부분의 BGP 라우팅(백본의 BGP 백본에 의해 링크된 여러 소규모 기업 중 하나를 나타내는 confederation-AS, ISP에 대한 루트를 방송하지만 디폴트루트만 받아들이는 소규모 기업 등)에 사용할 경우 매우 합리적이고 편리할 수 있습니다.집약된 소수의 루트

인터넷에의 단일 엔트리 포인트를 가지는 네트워크 전용으로 사용되는 BGP 라우터는, 멀티 홈네트워크보다 라우팅 테이블사이즈(및 RAM 요건과 CPU 요건)가 훨씬 작은 경우가 있습니다.단순한 멀티호밍이라도 라우팅 테이블의 사이즈는 그다지 크지 않습니다.컨트롤 플레인에서의 싱글 BGP 라우터 컨버전스에 관한 벤더에 의존하지 않는 퍼포먼스 파라미터에 대해서는 RFC 4098을 참조해 주십시오.BGP 라우터에서 실제로 필요한 메모리의 양은 다른 BGP 스피커와 교환되는 BGP 정보의 양 및 특정 라우터가 BGP 정보를 저장하는 방법에 따라 달라집니다.라우터는 특정 네이버 AS에 대한 루트애드버타이즈 및 수용을 위한 다양한 정책을 관리할 수 있도록 여러 개의 루트 복사본을 보유해야 할 수 있습니다.뷰라는 용어는 실행 중인 라우터에서 이러한 다양한 정책 관계를 나타낼 때 자주 사용됩니다.

어떤 라우터 구현이 다른 구현보다 루트당 더 많은 메모리를 사용하는 경우 이는 메모리와 처리 속도를 교환하는 정당한 설계 선택일 수 있습니다.2015년 8월 현재 완전한 IPv4 BGP 테이블은 [28]590,000개의 프레픽스를 초과합니다.대규모 ISP는 내부 및 고객 루트에 대해 50%를 추가할 수 있습니다.실장에 따라서는, 다른 피어 AS 의 뷰 마다 다른 테이블을 보관 유지할 수 있습니다.

BGP의 주요 프리 소스 및 오픈소스 실장은 다음과 같습니다.

  • BORD는 Unix와 유사한 시스템용 GPL 라우팅 패키지입니다.
  • FRRouting은 Unix와 유사한 시스템용 Quagga의 포크입니다.
  • GNU Zebra, BGP4를 지원하는 GPL 라우팅 스위트(임무 해제)[38]
  • OpenBGPD, OpenB에 의한 BSD 라이선스 실장SD팀
  • Quagga는 Unix와 유사한 시스템용 GNU Zebra의 포크입니다.
  • XORP, eXtensible Open Router Platform은 BSD 라이선스의 라우팅 프로토콜 스위트입니다.

BGP 적합성, 부하 또는 부하 성능을 테스트하기 위한 시스템은 다음과 같은 벤더로부터 제공됩니다.

표준 문서

  • RFC 1772: SMIv2를 사용한 인터넷 프로토콜(BGP-4)에서의 경계 게이트웨이 프로토콜 적용
  • RFC 1997, BGP 커뮤니티 어트리뷰트
  • RFC 2439, BGP 루트플랩 댐핑
  • RFC 2918, BGP-4의 루트 리프레시 기능
  • RFC 3765, NOPER 커뮤니티 for Border Gateway Protocol(BGP) 루트 범위 제어
  • RFC 4271, BGP-4(Border Gateway Protocol 4)
  • RFC 4272, BGP 보안 취약성 분석
  • RFC 4273, BGP-4의 관리 대상 객체의 정의
  • RFC 4274, BGP-4 프로토콜 분석
  • RFC 4275, BGP-4 MIB 구현 조사
  • RFC 4276, BGP-4 구현 보고서
  • RFC 4277, BGP-4 프로토콜 사용 경험
  • RFC 4278, TCP MD5 시그니처 옵션(RFC 2385) 및 BGP-4 사양에 관한 표준 성숙도 차이
  • RFC 4360, BGP 확장 커뮤니티 애틀리뷰트
  • RFC 4456, BGP 루트 리플렉션: 풀 메쉬 내부 BGP(iBGP) 대체 수단
  • RFC 4724, BGP의 그레이스 풀재시작 메커니즘
  • RFC 4760, BGP-4용 멀티프로토콜 확장
  • RFC 5065, 자율 시스템 컨페더레이션 for BGP
  • RFC 5492, BGP-4에 의한 기능 애드버타이즈먼트
  • RFC 5575, 흐름 사양 규칙 배포
  • RFC 5701, IPv6 주소 고유의 BGP 확장 커뮤니티 어트리뷰트
  • RFC 6793, 4옥텟 자율 시스템(AS) 번호 공간에 대한 BGP 지원
  • RFC 7153, BGP 확장 커뮤니티용 IANA 레지스트리
  • RFC 7606, BGP UPDATE 메시지 오류 처리 수정
  • RFC 7752, BGP를 사용한 링크스테이트 및 트래픽엔지니어링 정보의 노스바운드 배포
  • RFC 7911, BGP에서의 복수 경로 애드버타이즈먼트
  • RFC 8092, BGP 대규모 커뮤니티 애틀리뷰트
  • RFC 8195, BGP 대규모 커뮤니티 사용
  • RFC 8642, Well-known BGP 커뮤니티 정책 동작
  • draft-ietf-idr-custom-decision-08 – BGP 커스텀 결정 프로세스, 2017년2월 3일
  • BGP, IETF 드래프트의 선택적 루트 리프레시
  • RFC 1105, 사용되지 않음– BGP
  • RFC 1654, 사용되지 않음– BGP-4 ( Border Gateway Protocol 4 )
  • RFC 1655, 구식 – 인터넷에서의 BGP 적용
  • RFC 1657, 사용되지 않음– 네 번째 버전의 보더 게이트웨이를 위한 관리 대상 객체의 정의
  • RFC 1771, 사용되지 않음– BGP-4 ( Border Gateway Protocol 4 )
  • RFC 1965, 구식 – BGP용 자율 시스템 연합
  • RFC 2796, 사용되지 않음– BGP 루트 리플렉션– 풀 메쉬 iBGP 대체 방법
  • RFC 2858, 폐지 - BGP-4용 멀티프로토콜 확장
  • RFC 3065, 구식 – BGP용 자율 시스템 연합
  • RFC 3392, 사용되지 않음– BGP-4에 의한 기능 애드버타이즈먼트
  • RFC 4893 - 4옥텟 AS 번호 공간에 대한 BGP 지원

「 」를 참조해 주세요.

메모들

  1. ^ 최신 버전의 BGP 표준 이전에는 업데이트에 MED 값이 없는 경우 여러 구현에서 가능한 한 높은 값을 가진 MED가 생성되었습니다.그러나 현재 표준에서는 누락된 MED가 가능한 최소값으로 처리되도록 규정되어 있습니다.현재의 규칙에 의해 벤더의 해석과는 다른 동작이 발생할 수 있기 때문에 비표준 기본값을 사용한BGP 실장에서는 오래된 규칙 또는 표준 규칙을 선택할 수 있는 설정 기능이 있습니다.

레퍼런스

  1. ^ "BGP: Border Gateway Protocol Explained". Orbit-Computer Solutions.Com. Archived from the original on 2013-09-28. Retrieved 2013-10-08.
  2. ^ Sobrinho, João Luís (2003). "Network Routing with Path Vector Protocols: Theory and Applications" (PDF). Retrieved March 16, 2018.
  3. ^ Timberg, Craig (31 May 2015). "Net of Insecurity; Quick fix for an early Internet problem lives on a quarter-century later". The Washington Post. Archived from the original on 1 June 2015. Retrieved 4 January 2021. As the prospect of system meltdown loomed, the men began scribbling ideas for a solution onto the back of a ketchup-stained napkin. Then a second. Then a third. The “three-napkins protocol,” as its inventors jokingly dubbed it, would soon revolutionize the Internet. And though there were lingering issues, the engineers saw their creation as a “hack” or “kludge,” slang for a short-term fix to be replaced as soon as a better alternative arrived.
  4. ^ "The History of Border Gateway Protocol". blog.datapath.io. Archived from the original on 20 October 2020.
  5. ^ A Border Gateway Protocol 4 (BGP-4). RFC 4271.
  6. ^ RFC 4274
  7. ^ R. Chandra; J. Scudder (May 2000). Capabilities Advertisement with BGP-4. doi:10.17487/RFC2842. RFC 2842.
  8. ^ T. Bates; et al. (June 2000). Multiprotocol Extensions for BGP-4. doi:10.17487/RFC2858. RFC 2858.
  9. ^ E. Rosen; Y. Rekhter (April 2004). BGP/MPLS VPNs. doi:10.17487/RFC2547. RFC 2547.
  10. ^ RFC 1997
  11. ^ "BGP Community Guides". Retrieved 13 April 2015.
  12. ^ BGP 확장 커뮤니티 유형을 위한 IANA 레지스트리, IANA, 2008
  13. ^ Wayback Machine, Thomas Knoll, 2008에서 시그널링된QoS 2009-02-23의 IETF 초안
  14. ^ "Large BGP Communities". Retrieved 2021-11-27.
  15. ^ Y. Rekhter; T. Li; S. Hares, eds. (January 2006). A Border Gateway Protocol 4 (BGP-4). Network Working Group. doi:10.17487/RFC4271. RFC 4271. 4.1항
  16. ^ "Border Gateway Protocol (BGP)". Cisco.com.
  17. ^ T. Bates; et al. (April 2006). BGP Route Reflection: An Alternative to Full Mesh Internal BGP (iBGP). RFC 4456.
  18. ^ "Info". www.ietf.org. Retrieved 2019-12-17.
  19. ^ "Info". www.ietf.org. Retrieved 2019-12-17.
  20. ^ "Info". www.ietf.org. Retrieved 2019-12-17.
  21. ^ "Route Flap Damping Exacerbates Internet Routing Convergence" (PDF). November 1998.
  22. ^ Zhang, Beichuan; Pei Dan; Daniel Massey; Lixia Zhang (June 2005). "Timer Interaction in Route Flap Damping" (PDF). IEEE 25th International Conference on Distributed Computing Systems. Retrieved 2006-09-26. We show that the current damping design leads to the intended behavior only under persistent route flapping. When the number of flaps is small, the global routing dynamics deviates significantly from the expected behavior with a longer convergence delay.
  23. ^ Villamizar, Curtis; Chandra, Ravi; Govindan, Ramesh (November 1998). "BGP Route Flap Damping". Tools.ietf.org.
  24. ^ "RIPE Routing Working Group Recommendations On Route-flap Damping". RIPE Network Coordination Centre. 2006-05-10. Retrieved 2013-12-04.
  25. ^ "draft-ymbk-rfd-usable-02 - Making Route Flap Damping Usable". Tools.ietf.org. Retrieved 2013-12-04.
  26. ^ 2014년 8월 12일 현재 시스코 및 기타 벤더에 의해 제조된 여러 인터넷라우터에서 기본 소프트웨어 제한은 512,000~524,288입니다.
  27. ^ "Renesys 512k global routes".
  28. ^ a b "BGP Reports". potaroo.net.
  29. ^ "CAT 6500 and 7600 Series Routers and Switches TCAM Allocation Adjustment Procedures". Cisco. 9 March 2015.
  30. ^ Jim Cowie. "Internet Touches Half Million Routes: Outages Possible Next Week". Dyn Research.
  31. ^ Garside, Juliette; Gibbs, Samuel (14 August 2014). "Internet infrastructure 'needs updating or more blackouts will happen'". The Guardian. Retrieved 15 Aug 2014.
  32. ^ "BOF report" (PDF). www.nanog.org. Retrieved 2019-12-17.
  33. ^ Greg Ferro (26 January 2011). "TCAM — a Deeper Look and the impact of IPv6". EtherealMind.
  34. ^ "The IPv4 Depletion site". ipv4depletion.com.
  35. ^ "What caused today's Internet hiccup". bgpmon.net.
  36. ^ 16비트 Autonomous System Report, Geoff Huston 2011 (원본은 https://web.archive.org/web/20110906085724/http 에서 보관)
  37. ^ Craig Timberg (2015-05-31). "Quick fix for an early Internet problem lives on a quarter-century later". The Washington Post. Retrieved 2015-06-01.
  38. ^ "GNU Zebra".

추가 정보

외부 링크