맨위로가기

경계 경로 프로토콜

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

경계 경로 프로토콜(BGP)은 인터넷에서 자율 시스템 간의 라우팅을 수행하는 핵심 프로토콜이다. 1989년에 처음 개발되었으며, 현재 버전은 BGP4(RFC 4271)이다. BGP는 라우터 간의 TCP 세션을 통해 작동하며, 내부 BGP(iBGP)와 외부 BGP(eBGP)로 구분된다. BGP는 유한 상태 머신을 사용하여 피어 간의 연결을 관리하며, 로컬 가중치, AS 경로 길이, 출처 유형 등을 포함한 여러 기준을 통해 최적의 경로를 선택한다. BGP는 확장성을 위해 루트 리플렉터, 컨페더레이션, 다중 프로토콜 BGP(MBGP)와 같은 기능을 지원하며, 라우팅 테이블 증가, 경로 플래핑, BGP 하이재킹과 같은 보안 문제에 직면해 있다.

더 읽어볼만한 페이지

  • 라우팅 프로토콜 - 라우팅 정보 프로토콜
    라우팅 정보 프로토콜(RIP)은 벨만-포드 알고리즘 기반의 거리 벡터 라우팅 프로토콜로, 홉 카운트를 사용하여 최적 경로를 설정하며 라우팅 루프 방지를 위해 최대 홉 수를 15로 제한하고, RIPv1, RIPv2, RIPng 등의 버전이 있다.
  • 라우팅 프로토콜 - IS-IS
    IS-IS는 대규모 네트워크에서 효율적인 라우팅을 제공하는 링크 상태 라우팅 프로토콜로, 빠른 컨버전스 속도와 확장성이 뛰어나 통신 사업자 및 데이터 센터에서 주로 사용되며 OSPF와 유사하지만 주소 체계 등에서 차이가 있다.
  • 인터넷 표준 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
  • 인터넷 표준 - IPv6
    IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.
  • 인터넷 프로토콜 - IPTV
    IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다.
  • 인터넷 프로토콜 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
경계 경로 프로토콜
프로토콜 개요
이름경계 경로 프로토콜
로마자 표기Gyeonggye Gyeongro Peurotokol
종류라우팅 프로토콜
기능자율 시스템 간의 라우팅 정보 교환
최초 정의RFC 1105 (1989년 6월)
관련 문서RFC 1105
개발 시작1989년 6월 1일
개발 기관IETF
기술 정보
계층애플리케이션 계층
전송 프로토콜TCP
포트 번호179
기타
사용 여부사용 중

2. 역사

BGP의 기원은 1989년 IETF 컨퍼런스에서 Kirk Lougheed, Len Bosack, Yakov Rekhter가 식사를 하던 중 냅킨 뒷면에 새로운 라우팅 프로토콜의 개요를 스케치하면서 시작되었는데, 이로 인해 "두 장의 냅킨 프로토콜"로 종종 언급된다.[4][5][6]

1989년 RFC 1105에 처음 기술되었으며, NSFNET 인터넷 백본을 폐지하고 복수의 백본 네트워크를 연결하는 완전 분산 라우팅으로 이행하기 위해 EGP를 대신하는 라우팅 프로토콜로서 탄생했다. 이렇게 탄생한 BGP는 인터넷을 진정한 분산 시스템으로 변화시켰다.[7]

IPv6 BGP는 1994년 RFC 1654에서 처음 정의되었으며, 1998년 RFC 2283에서 개선되었다.

BGP의 현재 버전은 버전 4(BGP4)이며, 1994년에 RFC 1654로 처음 출판되었고, 1995년 RFC 1771 및 2006년 RFC 4271로 업데이트되었다.[8] RFC 4271은 오류를 수정하고, 모호성을 명확히 하며, 일반적인 산업 관행에 따라 사양을 업데이트했다. BGP4의 주요 개선 사항은 클래스 없는 도메인 간 라우팅(CIDR) 지원과 라우트 집약 사용으로 라우팅 테이블의 크기를 줄이는 것이었다. RFC 4271은 BGP4가 광범위한 IPv4 및 IPv6 "주소 패밀리"를 전달할 수 있도록 하며, 이는 멀티프로토콜 BGP(MP-BGP)인 멀티프로토콜 확장이라고도 한다.

2. 1. 주요 BGP RFC

현재 BGP 버전은 버전 4(BGP4)이며 2006년 RFC 4271 사양으로 출판되었다.[49] 그 이전에는 RFC 1771 버전 4에 기반한 20개의 초안 문서들이 처리되었다. BGP4는 1994년부터 인터넷에 사용되고 있었다.[50]

주요 BGP RFC는 다음과 같다:

RFC 번호설명
RFC 4271A Border Gateway Protocol 4 (BGP-4)
RFC 4456BGP 경로 반사 – 전체 메시 내부 BGP (iBGP)의 대안
RFC 4278TCP MD5 서명 옵션(RFC 2385) 및 BGP-4 사양 관련 표준 성숙도 차이
RFC 4277BGP-4 프로토콜 경험
RFC 4276BGP-4 구현 보고서
RFC 4275BGP-4 MIB 구현 설문 조사
RFC 4274BGP-4 프로토콜 분석
RFC 4273BGP-4 관리 객체 정의
RFC 4272BGP 보안 취약점 분석
RFC 5492BGP-4를 사용한 기능 알림
RFC 5065BGP를 위한 자율 시스템 연합
RFC 2918BGP-4의 경로 새로 고침 기능
RFC 1772인터넷 프로토콜에서 SMIv2를 사용한 BGP-4 적용
RFC 48934옥텟 AS 번호 공간에 대한 BGP 지원
RFC 2439BGP 경로 플랩 댐핑
RFC 4760BGP-4를 위한 멀티프로토콜 확장


3. BGP의 동작

BGP(Border Gateway Protocol, 경계 경로 프로토콜)는 라우터 간의 수동 설정을 통해 포트 179번에서 TCP 세션을 생성하여 설정되는 BGP 피어(peer)라고 불리는 BGP 인접 관계를 갖는다.[9] BGP 스피커는 연결을 유지하기 위해 30초마다 19바이트의 킵얼라이브 메시지를 보내는데, 이는 프로토콜 기본값으로 조정 가능하다.[9] BGP는 라우팅 프로토콜 중에서 유일하게 TCP를 전송 프로토콜로 사용한다.[9]

BGP는 동일한 자율 시스템(AS) 내의 두 피어 간에 실행될 때 ''내부 BGP''(iBGP, 내부 경계 게이트웨이 프로토콜)라고 하고, 서로 다른 자율 시스템 간에 실행될 때는 ''외부 BGP''(eBGP, 외부 경계 게이트웨이 프로토콜)라고 한다. AS 경계에서 다른 AS와 정보를 교환하는 라우터를 ''경계'' 또는 ''엣지 라우터''라고 하며, 일반적으로 직접 연결되는 반면, ''iBGP 피어''는 다른 중간 라우터를 통해 상호 연결될 수 있다.

iBGP와 eBGP 피어링 간의 주요 차이점은 경로 전파 방식인데, eBGP 피어로부터 학습한 새로운 경로는 모든 iBGP 및 eBGP 피어에 다시 알리고, iBGP 피어로부터 학습한 새로운 경로는 모든 eBGP 피어에만 다시 알린다. 이러한 경로 전파 규칙은 AS 내의 모든 iBGP 피어가 iBGP 세션을 통해 완전 연결되어야 함을 의미한다.

경로 전파 방식은 ''경로 맵'' 메커니즘을 통해 제어할 수 있는데, 이는 일련의 규칙으로 구성되며, 각 규칙은 주어진 기준과 일치하는 경로에 대해 어떤 조치를 취해야 하는지 설명한다. 이 조치는 경로를 삭제하거나, 라우팅 테이블에 삽입하기 전에 경로의 일부 속성을 수정하는 것일 수 있다.

BGP는 IP 네트워크 또는 AS 간의 도달성을 나타내는 프리픽스(prefix영어)의 라우팅 테이블을 유지함으로써 라우팅을 수행하며, 경로 벡터형 라우팅 프로토콜(path vector protocol)로 분류된다. BGP는 클래스 없는 도메인 간 라우팅(CIDR)을 지원하며, 경로 집약을 수행하여 라우팅 테이블의 크기를 줄일 수 있다.

BGP를 이용하는 라우터 간에는 IGP 세션을 설정한다. 라우터의 수가 많은 네트워크에서 BGP를 이용하는 경우, IGP 세션의 수가 많아져 확장성 문제가 발생하는데, 이 문제를 해결하기 위해 루트 리플렉션과 컨페더레이션 기술을 이용한다.

AS 간의 경로가 변경된 경우, 변경된 차이 정보를 주고받는다. BGP는 NSFNET 인터넷 백본을 폐지하고, 복수의 백본 네트워크를 연결하는 완전 분산 라우팅으로 이행하기 위해, EGP를 대신하는 라우팅 프로토콜로서 탄생했으며, 인터넷을 진정한 분산 시스템으로 변화시켰다.

BGP의 2015년 현재 버전인 버전 4는 1994년에 제안되었으며, 2006년 1월에는 기존의 RFC 1771에서 RFC 4271로 갱신되었다.

동일한 AS 내에서 BGP 라우팅에 참여하는 모든 라우터는 원칙적으로 풀 메시(full mesh)로 구성되어야 하는데, 이는 네트워크 내 라우터 증가에 따라 연결 수가 2차 함수적으로 증가하여 스케일 문제에 직면하게 된다. 이를 해결하기 위해 RFC 2796에서 정해진 루트 리플렉터와 RFC 3065에서 정해진 컨페더레이션 방법이 사용된다.

3. 1. BGP 유한 상태 머신 (FSM)

BGP 피어는 다른 BGP 피어와의 동작을 결정하기 위해 간단한 유한 오토마톤(FSM)을 사용한다.[12] FSM에는 Idle, Connect, Active, OpenSent, OpenConfirm, Established의 6가지 상태가 있다.[12] BGP 피어는 TCP 연결이 이루어지면, 피어의 세션이 확립, 유지되는 방향으로 상태가 전이된다.

BGP 상태 머신


각 상태에 대한 설명은 다음과 같다.

  • '''유휴(Idle) 상태''':[12]
  • 모든 수신 BGP 연결을 거부한다.
  • 이벤트 트리거 초기화를 시작한다.
  • 구성된 BGP 피어와 TCP 연결을 시작한다.
  • 피어로부터 TCP 연결을 청취한다.
  • 상태를 Connect로 변경한다.
  • FSM 프로세스의 모든 상태에서 오류가 발생하면 BGP 세션이 즉시 종료되고 유휴 상태로 돌아간다.
  • '''연결(Connect) 상태''':[12]
  • 피어와의 성공적인 TCP 협상을 기다린다.
  • BGP는 TCP 세션이 성공적으로 설정된 경우 이 상태에서 많은 시간을 소비하지 않는다.
  • 피어에게 Open 메시지를 보내고 상태를 OpenSent로 변경한다.
  • 오류가 발생하면 BGP가 Active 상태로 이동한다.
  • '''활성(Active) 상태''':[12]
  • 라우터가 성공적인 TCP 세션을 설정할 수 없으면 Active 상태가 된다.
  • BGP FSM은 피어와 다른 TCP 세션을 다시 시작하려고 시도하고 성공하면 피어에게 Open 메시지를 보낸다.
  • 다시 실패하면 FSM이 유휴 상태로 재설정된다.
  • 반복적인 실패로 인해 라우터가 유휴 및 활성 상태 사이를 순환할 수 있다.
  • '''OpenSent 상태''':[12]
  • BGP FSM은 피어로부터 Open 메시지를 청취한다.
  • 메시지가 수신되면 라우터는 Open 메시지의 유효성을 확인한다.
  • 오류가 없으면 Keepalive 메시지가 전송되고 다양한 타이머가 설정되며 상태가 OpenConfirm으로 변경된다.
  • '''OpenConfirm 상태''':[12]
  • 피어는 피어로부터 Keepalive 메시지를 청취한다.
  • Keepalive 메시지가 수신되고 Keepalive 수신 전에 타이머가 만료되지 않으면 BGP는 Established 상태로 전환한다.
  • Keepalive 메시지를 수신하기 전에 타이머가 만료되거나 오류 조건이 발생하면 라우터는 다시 유휴 상태로 전환한다.
  • '''Established 상태''':[12]
  • 이 상태에서 피어는 Update 메시지를 보내 BGP 피어에 광고되는 각 경로에 대한 정보를 교환한다.
  • Update 메시지에 오류가 있으면 Notification 메시지가 피어로 전송되고 BGP는 다시 유휴 상태로 전환한다.


라우터 간의 네이버(neighbor, 인접 라우터) 또는 피어(peer, 동료 라우터)는 TCP의 포트 179번을 통해 수동으로 설정하여 확립된다.[12] BGP를 이용하는 라우터(BGP 스피커)는 연결을 유지하기 위해 19바이트의 킵얼라이브 (keepalive)를 정기적으로 전송한다(기본값은 60초마다).[12] 전송 프로토콜로 TCP를 사용하는 것은 라우팅 프로토콜 중에서 BGP뿐이다.[12]

3. 2. 경로 선택 과정

BGP 표준은 다른 일반적인 라우팅 프로토콜보다 더 많은 결정 요소를 사용하여 Loc-RIB에 넣을 NLRI를 선택한다. NLRI 평가의 첫 번째 단계는 다음 홉 속성이 도달 가능해야 한다는 것이다. 즉, 다음 홉 주소가 도달 가능한 접두사에 대한 활성 경로가 라우터의 기본 라우팅 테이블에 이미 있어야 한다.

각 이웃에 대해 BGP 프로세스는 Adj-RIB-In에 포함될 경로를 결정하기 위해 다양한 표준 및 구현 종속 기준을 적용한다. 이웃은 대상에 여러 경로를 보낼 수 있지만, 기본 설정은 각 대상에 대해 하나의 경로만 Adj-RIB-In에 설치하는 것이다. 이 프로세스는 이웃이 철회한 모든 경로를 Adj-RIB-In에서 제거하기도 한다.

Adj-RIB-In이 변경될 때마다 기본 BGP 프로세스는 이웃의 새 경로 중 Loc-RIB에 이미 있는 경로보다 선호되는 경로가 있는지 확인한다. 있다면 교체하고, 주어진 경로가 이웃에 의해 철회되었고 해당 대상에 대한 다른 경로가 없으면 Loc-RIB에서 제거하고 BGP에서 기본 라우팅 테이블 관리자로 더 이상 전송하지 않는다. 라우터가 BGP 이외의 소스에서 해당 대상에 대한 경로가 없으면 철회된 경로는 기본 라우팅 테이블에서도 제거된다.

타이 브레이커가 있는 경우 경로 선택 프로세스는 다음 단계로 이동한다.

최적의 경로를 결정하는 단계, 타이 브레이커 순서:[13][14]
단계범위이름기본값선호BGP 필드참고
1라우터 로컬로컬 가중치높음시스코 관련 매개변수
2AS 내부로컬 기본 설정높음LOCAL_PREF이웃에서 여러 iBGP 경로가 있는 경우, 동일한 로컬 기본 설정을 가진 여러 경로가 없는 한 가장 높은 로컬 기본 설정을 가진 경로가 선택됨.
3누적 내부 게이트웨이 프로토콜(AIGP)낮음AIGPrfc7311
4AS 외부자율 시스템(AS) 점프낮음AS-pathAS 점프는 광고된 대상에 도달하기 위해 거쳐야 하는 AS 번호의 수. AS1–AS2–AS3은 AS4–AS5–AS6–AS7보다 점프 수가 적은 더 짧은 경로.
5출처 유형"IGP"낮음ORIGIN0 = IGP
1 = EGP
2 = 불완전
6다중 출구 차별자(MED)낮음MULTI_EXIT_DISC기본적으로 동일한 AS를 가진 경로만 비교. 동일한 AS를 무시하도록 설정할 수 있음.
7라우터 로컬(Loc-RIB)iBGP 경로를 통한 eBGP"on"직접 연결됨, 간접적으로 연결됨
8BGP 다음 홉까지의 IGP 메트릭"on", IGP에서 가져옴낮음최적의 경로가 이미 선택된 경우에도 계속 진행. 기본 라우팅 테이블에 따라 다음 홉까지의 내부 비용이 가장 낮은 경로를 선호. 두 이웃이 동일한 경로를 광고했지만 한 이웃은 저비트율 링크를 통해 도달 가능하고 다른 이웃은 고비트율 링크를 통해 도달 가능한 경우, 그리고 내부 라우팅 프로토콜이 가장 높은 비트율을 기반으로 가장 낮은 비용을 계산하면 고비트율 링크를 통한 경로가 선호되고 다른 경로는 삭제됨.
9가장 먼저 수신된 경로"on"가장 오래됨단계 10+에서의 변경 사항을 무시하는 데 사용
10라우터 ID"on"낮음
11클러스터 목록 길이"on"낮음
12이웃 주소"on"낮음



로컬 기본 설정, 가중치 및 기타 기준은 로컬 구성 및 소프트웨어 기능으로 조작할 수 있다. 이러한 조작은 일반적이지만 표준 범위를 벗어난다. 예를 들어, ''커뮤니티'' 속성은 BGP 선택 프로세스에서 직접 사용되지 않는다. BGP 이웃 프로세스는 커뮤니티 값이 일부 패턴 일치 기준과 일치하는 경우 속성을 설정하기 위해 수동으로 프로그래밍된 규칙을 기반으로 로컬 기본 설정 또는 다른 요소를 설정하는 규칙을 가질 수 있다. 경로가 외부 피어로부터 학습된 경우 이웃별 BGP 프로세스는 로컬 정책 규칙에서 로컬 기본 설정 값을 계산한 다음 이웃으로부터의 모든 경로의 로컬 기본 설정을 비교한다.

BGP 커뮤니티는 들어오거나 나가는 접두사에 적용하여 몇 가지 일반적인 목표를 달성할 수 있는 속성 태그이다.[15] BGP를 통해 관리자는 ISP가 접두사를 처리하는 방법에 대한 정책을 설정할 수 있지만, 엄밀히 말하면 일반적으로 불가능하다. 예를 들어, BGP는 본질적으로 하나의 AS가 다른 AS에게 접두사를 북미 피어링 고객에게만 광고하도록 제한하라고 지시할 수 있는 개념을 가지고 있지 않다. 대신, ISP는 일반적으로 각각의 설명과 함께 잘 알려진 또는 독점적인 커뮤니티 목록을 게시하며, 이는 본질적으로 접두사를 처리하는 방법에 대한 계약이 된다.

잘 알려진 BGP 커뮤니티[16]
속성 값속성설명참조
0x00000000-0x0000FFFF예약됨
0x00010000-0xFFFEFFFF개인 사용을 위해 예약됨
0xFFFF0000GRACEFUL_SHUTDOWN인접 AS-피어에서 LOCAL_PREF 설정, 소스에서 멀어지도록 경로 낮춤.
0xFFFF0001ACCEPT_OWN하나의 VRF 내에서 시작된 경로가 다른 VRF로 가져오는 방식을 수정하는 데 사용됨
0xFFFF0002ROUTE_FILTER_TRANSLATED_v4RFC draft-l3vpn-legacy-rtc
0xFFFF0003ROUTE_FILTER_v4RFC draft-l3vpn-legacy-rtc
0xFFFF0004ROUTE_FILTER_TRANSLATED_v6RFC draft-l3vpn-legacy-rtc
0xFFFF0005ROUTE_FILTER_v6RFC draft-l3vpn-legacy-rtc
0xFFFF0006LLGR_STALE세션 오류 후 더 오래된 경로가 유지됨
0xFFFF0007NO_LLGRLLGR 기능은 적용되지 않아야 함
0xFFFF0008accept-own-nexthopRFC draft-agrewal-idr-accept-own-nexthop
0xFFFF0009Standby PEBGP/MPLS VPN에서 다양한 유형의 장애에 대한 연결 복구를 더 빠르게 허용합니다.
0xFFFF029ABLACKHOLE인접 AS에 해당 접두사로의 모든 트래픽을 폐기하도록 요청하여 서비스 거부 공격으로부터 일시적으로 보호하기 위함(블랙홀링)
0xFFFFFF01NO_EXPORTBGP 연합 경계로 제한
0xFFFFFF02NO_ADVERTISEBGP 피어로 제한
0xFFFFFF03NO_EXPORT_SUBCONFEDAS로 제한
0xFFFFFF04NOPEER피어 링크를 통해 광고할 "필요 없음"



일반적인 커뮤니티의 예는 다음과 같다.



ISP는 다음과 같은 예를 사용하여 고객으로부터 수신한 모든 경로를 설명할 수 있다.

  • 고객 북미 (동부 해안) 3491:100
  • 고객 북미 (서부 해안) 3491:200


고객은 각 경로에 대해 올바른 커뮤니티 또는 커뮤니티를 포함하도록 구성을 조정하기만 하면 되며, ISP는 접두사가 누구에게 광고되는지 제어할 책임이 있다. 최종 사용자는 ISP가 올바른 조치를 취하도록 강제할 기술적인 능력이 없지만, 이 영역의 문제는 일반적으로 드물고 우발적이다.[17][18]

최종 고객이 ISP가 광고된 경로에 할당하는 로컬 기본 설정을 제어하기 위해 MED를 사용하는 대신 (효과는 유사함) BGP 커뮤니티 (일반적으로 ASN:70,80,90,100)를 사용하는 것이 일반적인 전술이다. 커뮤니티 속성은 전이적이지만, 고객이 적용한 커뮤니티는 다음 홉 AS 외부로 전파되는 경우가 매우 드물다. 모든 ISP가 커뮤니티를 대중에게 공개하는 것은 아니다.[19]

BGP는 경로 선택에 있어 상위에서 하위 순으로 다음 기준을 사용한다.

  • 다음 홉 라우터로의 명시적인 라우트(디폴트 라우트가 아님)가 라우팅 테이블에 존재한다.
  • 더 높은 Weight 속성을 가진 경로를 선택(시스코 시스템즈사의 라우터만 해당)
  • 더 높은 로컬 설정 속성을 가진 경로를 선택
  • 라우터를 기점으로 하는 BGP를 선택
  • AS 경로가 가장 짧은 것을 선택
  • Origin 속성 값이 더 낮은 라우트를 선택(IGP < EGP < Incomplete)
  • MED(Multi exit discriminator영어) 속성 값이 가장 낮은 경로를 선택
  • 내부 경로보다 외부 경로를 선택
  • 다음 홉으로의 경로에서 IGP 메트릭 값이 가장 낮은 것을 선택
  • 만약 모든 경로가 외부에서 온 것이라면, 가장 오래된 것을 선택
  • 가장 낮은 BGP ID를 가진 다음 홉 라우터를 선택

3. 3. BGP 확장

BGP 스피커는 피어링 핸드셰이크 과정에서 OPEN 메시지를 교환하며, 세션의 선택적 기능을 협상할 수 있다. 여기에는 다중 프로토콜 확장[11] 및 다양한 복구 모드가 포함된다.[10] BGP에 대한 다중 프로토콜 확장이 생성 시점에 협상되면, BGP 스피커는 광고하는 NLRI(Network Layer Reachability Information)에 주소 패밀리 접두사를 붙일 수 있다. 이러한 패밀리에는 IPv4 (기본값), IPv6, IPv4/IPv6 가상 사설망 및 멀티캐스트 BGP가 포함된다. BGP는 VPN과 같이 글로벌 인터넷의 일부가 아닐 수 있는 경로에 대한 정보를 전달하는 일반화된 신호 프로토콜로 사용되기도 한다.[12]

BGP 확장 커뮤니티 속성은 2006년에 추가되어[20] 이러한 속성의 범위를 확장하고 유형 필드를 통해 커뮤니티 속성 구조화를 제공했다. 확장된 형식은 유형 필드에 대해 1 또는 2 옥텟으로 구성되며, 그 뒤에 각각의 커뮤니티 속성 콘텐츠에 대해 7 또는 6 옥텟이 따른다. 이 확장 커뮤니티 속성의 정의는 RFC 4360에 문서화되어 있다. IANA는 BGP 확장 커뮤니티 유형에 대한 레지스트리를 관리한다.[21] 확장 커뮤니티 속성 자체는 전이적 선택적 BGP 속성이다. 속성 내의 유형 필드의 비트는 인코딩된 확장 커뮤니티가 전이적인지 또는 비전이적인지를 결정한다. 따라서 IANA 레지스트리는 속성 유형에 대해 서로 다른 숫자 범위를 제공한다. 확장된 속성 범위로 인해 그 사용법은 다양할 수 있다. RFC 4360은 예시로 "2옥텟 AS 특정 확장 커뮤니티", "IPv4 주소 특정 확장 커뮤니티", "불투명 확장 커뮤니티", "경로 대상 커뮤니티" 및 "경로 원본 커뮤니티"를 정의한다. 여러 BGP QoS 초안에서도 이 확장 커뮤니티 속성 구조를 사용하여 도메인 간 QoS 시그널링을 수행한다.[22]

32비트 AS 번호가 도입되면서 16비트 ASN 필드만 정의하는 커뮤니티 속성은 몇 가지 문제가 즉시 분명해졌으며, 이는 이 필드와 실제 ASN 값 간의 일치를 방해한다. RFC 7153부터 확장 커뮤니티는 32비트 ASN과 호환된다. RFC 8092 및 RFC 8195는 각각 4바이트(AS:function:parameter)의 세 필드로 나뉜 12바이트의 대규모 커뮤니티 속성을 소개한다.[23]

다중 프로토콜 BGP(MBGP, Multiprotocol BGP 또는 멀티캐스트 BGP라고도 함)는 BGP의 확장 기능으로, 다양한 유형의 주소(주소 패밀리라고 함)를 병렬로 배포할 수 있게 한다. 표준 BGP는 IPv4 유니캐스트 주소만 지원하는 반면, 다중 프로토콜 BGP는 IPv4 및 IPv6 주소를 지원하며, 각 주소의 유니캐스트 및 멀티캐스트 변형을 지원한다. 다중 프로토콜 BGP를 사용하면 IP 멀티캐스트 지원 라우터의 토폴로지에 대한 정보를 일반 IPv4 유니캐스트 라우터의 토폴로지와 별도로 교환할 수 있다. 따라서 유니캐스트 라우팅 토폴로지와 다른 멀티캐스트 라우팅 토폴로지를 허용한다. MBGP를 통해 도메인 간 멀티캐스트 라우팅 정보를 교환할 수 있지만, 트리 구축 및 멀티캐스트 트래픽 전달에는 프로토콜 독립 멀티캐스트 계열과 같은 다른 프로토콜이 필요하다.

다중 프로토콜 BGP는 또한 MPLS L3 VPN의 경우, MPLS 네트워크를 통해 고객 사이트에서 라우팅을 위해 학습한 VPN 레이블을 교환하여 다른 고객 사이트의 트래픽이 프로바이더 에지 라우터에 라우팅을 위해 도착할 때, 이들을 구별하기 위해 널리 배포된다.

BGP의 또 다른 확장 기능은 멀티패스 라우팅이다. 일반적으로 동일한 MED, 가중치, 원본 및 AS 경로가 필요하지만, 일부 구현에서는 AS 경로 확인을 완화하여 경로의 실제 AS 번호가 일치하는 대신 동일한 경로 길이만 예상하도록 할 수 있다. 그런 다음, Cisco의 dmzlink-bw와 같은 기능으로 더 확장할 수 있으며, 개별 링크에 구성된 대역폭 값을 기반으로 트래픽 공유 비율을 활성화한다.

4. 내부 확장성

BGP는 단일 AS 내의 모든 라우터가 전체 메시(full mesh) 형태로 상호 연결되어야 하는 기본 구성에서 확장성 문제가 발생한다. 이는 라우터 수 증가에 따라 필요한 연결 수가 제곱 성장하기 때문이다.[24] 이러한 문제를 해결하기 위해 BGP는 라우트 리플렉터(RFC 4456)와 BGP 연합(RFC 5065) 두 가지 옵션을 제공한다.

내부 BGP (iBGP)에서는 모든 피어가 전체 메시 형태로 서로 연결되어야 하므로, 라우터 수가 많아지면 메모리 부족이나 높은 CPU 처리 부담으로 성능 저하가 발생할 수 있다. 라우트 리플렉터와 컨페더레이션은 iBGP 피어 수를 줄여 이러한 문제를 완화한다.

4. 1. 루트 리플렉터 (Route Reflector)

'''경로 반사기'''(Route reflector, RR)는 자율 시스템(AS)에서 필요한 연결 수를 줄이는 방법이다. 단일 라우터(또는 중복성을 위해 두 대)를 RR로 설정할 수 있으며, AS 내의 다른 라우터는 이 RR하고만 피어로 구성하면 된다.[25] RR은 iBGP의 논리적인 완전 연결 요구 사항에 대한 대안을 제공한다. RR의 목적은 집중이며, 여러 BGP 라우터가 중앙 지점인 RR과 피어링하여 완전 연결에서 다른 모든 라우터와 피어링하는 대신 RR 서버 역할을 수행한다. 다른 모든 iBGP 라우터는 RR 클라이언트가 된다.

이 방식은 OSPF의 DR/BDR 기능과 유사하며, 대규모 네트워크에 iBGP 확장성을 추가한다. 10개의 라우터로 구성된 완전 연결된 iBGP 네트워크에서는 각 피어의 원격 AS를 정의하기 위해 90개의 개별 CLI 문(토폴로지의 모든 라우터에 분산됨)이 필요하며, 이는 관리가 빠르게 어려워진다. RR 토폴로지는 이러한 90개의 문을 18개로 줄일 수 있어 ISP가 관리하는 대규모 네트워크에 실용적인 솔루션을 제공한다.

RR은 단일 실패 지점이 될 수 있으므로, 중복성을 제공하기 위해 최소한 두 번째 RR을 구성해야 한다. 다른 10개의 라우터에 대한 추가 피어이므로 CLI 문 수를 약 두 배로 늘린다. BGP 다중 경로 환경에서 추가 RR은 RR이 전용 RR 서버 역할이 아닌 일반 라우터 역할을 하는 경우 로컬 라우팅 처리량을 추가하여 네트워크에 이점을 줄 수도 있다.

RR과 연합은 각 라우터에 대한 iBGP 피어 수를 줄여 처리 부담을 줄인다. RR은 순수한 성능 향상 기술인 반면, 연합은 보다 세분화된 정책을 구현하는 데에도 사용할 수 있다.

RR과 해당 클라이언트는 ''클러스터''를 형성한다. 그러면 ''클러스터 ID''가 RR이 클라이언트 또는 비클라이언트 피어에게 광고하는 모든 경로에 첨부된다. 클러스터 ID는 누적적이고 비전이적인 BGP 속성이며, 모든 RR은 라우팅 루프를 방지하기 위해 로컬 클러스터 ID를 클러스터 목록 앞에 추가해야 한다.

4. 2. 컨페더레이션 (Confederation)

BGP 컨페더레이션(Confederation)은 상당히 큰 네트워크에서 사용하는 방법으로, 여러 개의 관리하기 쉬운 작은 AS들을 묶어 하나의 큰 AS로 보이게 하는 기법이다. 이는 AS 내부의 라우터 간에 필요한 전체 메시(full mesh) 연결 수를 줄여 확장성 문제를 해결하는 데 도움을 준다.[26]

컨페더레이션 AS는 여러 개의 AS로 구성된다. 각 컨페더레이션 AS 내부에서는 iBGP가 완전 연결(fully meshed)되어 있으며, 서로 다른 AS 간에는 eBGP와 유사한 방식으로 연결된다. 이때, 다음 홉(next-hop), 메트릭(metric), 로컬 선호도(local preference) 정보는 마치 iBGP를 사용하는 것처럼 보존된다. 외부에서는 이 컨페더레이션이 하나의 AS로 보이게 된다.[26]

이러한 방식은 iBGP 전송 AS에서 발생할 수 있는 라우팅 트래픽의 불필요한 중복과 많은 수의 TCP 세션 문제를 해결한다.

컨페더레이션은 라우트 리플렉터와 함께 사용될 수 있지만, 특정 설계 규칙을 따르지 않으면 경로 진동(route flapping)과 같은 문제가 발생할 수 있으므로 주의해야 한다.[27]

5. 안정성

BGP는 "모든 라우팅 프로토콜 중에서 가장 확장성이 뛰어나다."[24]

내부 BGP(iBGP)를 사용하는 자율 시스템은 모든 iBGP 피어가 전체 메시 형태로 서로 연결되어야 한다(모두가 서로 직접 통신). 이러한 구성은 각 라우터가 다른 모든 라우터와 세션을 유지해야 함을 요구한다. 대규모 네트워크에서는 메모리 부족이나 높은 CPU 처리 요구 사항으로 인해 이 세션 수가 라우터의 성능을 저하시킬 수 있다.

라우터 수가 많은 네트워크에서 BGP를 이용할 때, IGP 세션 수가 많아져 확장성 문제가 발생할 수 있다. 이 문제를 해결하기 위해 루트 리플렉션 기술을 사용한다.

5. 1. 경로 플랩 댐핑 (Route Flap Damping)

BGP 구현에 의해 관리되는 라우팅 테이블은 링크 또는 라우터의 다운 및 재가동과 같은 네트워크의 실제 변경 사항을 반영하기 위해 지속적으로 조정된다. 네트워크 전체에서 이러한 변경 사항이 거의 지속적으로 발생하는 것이 일반적이지만, 특정 라우터 또는 링크의 경우 변경 사항이 비교적 드물 것으로 예상된다. 라우터가 잘못 구성되거나 잘못 관리되면 다운 상태와 업 상태 사이에서 빠르게 순환할 수 있다. 라우트 플랩이라고 하는 이 반복적인 철회 및 재공표 패턴은 순환하는 엔티티에 대해 알고 있는 다른 모든 라우터에서 과도한 활동을 유발할 수 있다. 동일한 라우트가 라우팅 테이블에서 지속적으로 주입 및 철회되기 때문이다. BGP 설계는 라우트가 업데이트되는 동안 트래픽 전달이 작동하지 않을 수 있다. 인터넷에서 BGP 라우팅 변경은 몇 분 동안의 중단을 유발할 수 있다.

'''라우트 플랩 댐핑'''은 라우트 플랩의 영향을 완화하기 위해 많은 BGP 구현에 내장되어 있는 기능이다. 댐핑이 없으면 과도한 활동으로 인해 라우터에 과도한 처리 부하가 발생할 수 있으며, 이는 차례로 다른 라우트의 업데이트를 지연시켜 전체 라우팅 안정성에 영향을 미칠 수 있다. 댐핑을 사용하면 라우트의 플래핑이 지수 감쇠된다. 라우트가 사용 불가능해지고 빠르게 다시 나타나는 첫 번째 경우, BGP의 정상적인 페일오버 시간을 유지하기 위해 댐핑이 적용되지 않는다. 두 번째 발생 시, BGP는 해당 접두사를 일정 시간 동안 회피한다. 후속 발생은 지수적으로 더 오래 무시된다. 이상 현상이 중단되고 위반 라우트에 적합한 시간이 지나면 접두사를 초기화하여 복원할 수 있다. 댐핑은 또한 서비스 거부 공격을 완화할 수 있다.

또한 RFC 2439에서는 라우트 플랩 댐핑이 내부 경계 게이트웨이 프로토콜 세션(iBGP 세션 또는 단순히 내부 피어라고 함)이 아닌 외부 경계 게이트웨이 프로토콜 세션(eBGP 세션 또는 단순히 외부 피어라고 함)에 구현하는 것이 더 바람직한 기능이라고 제안한다. 이 접근 방식을 사용하면 자율 시스템 내에서 라우트가 플랩될 때 외부 AS로 전파되지 않으며 eBGP에 라우트를 플래핑하면 백본 전체에서 특정 라우트에 대한 일련의 플래핑이 발생한다. 이 방법은 또한 iBGP 세션에 대한 라우트 플랩 댐핑의 오버헤드를 성공적으로 방지한다.

후속 연구에서 플랩 댐핑이 실제로 경우에 따라 수렴 시간을 늘리고 링크가 플래핑되지 않더라도 연결 중단을 유발할 수 있음이 밝혀졌다.[29][30] 또한, 백본 링크와 라우터 프로세서가 빨라짐에 따라 일부 네트워크 설계자는 라우팅 테이블에 대한 변경 사항을 라우터가 훨씬 더 빠르게 처리할 수 있으므로 플랩 댐핑이 예전만큼 중요하지 않을 수 있다고 제안했다.[31] 이로 인해 RIPE 라우팅 워킹 그룹은 "현재의 BGP 플랩 댐핑 구현에서는 ISP 네트워크에서 플랩 댐핑 적용을 권장하지 않습니다. ... 플랩 댐핑을 구현하면 해당 네트워크를 운영하는 ISP가 고객과 고객의 콘텐츠 및 서비스의 인터넷 사용자에게 부작용을 일으킬 것입니다. ... 이러한 부작용은 단순히 플랩 댐핑을 전혀 실행하지 않는 것보다 더 나쁠 가능성이 큽니다."라고 하였다.[32] 플랩 댐핑 문제 없이 안정성을 개선하는 것은 현재 연구의 주제이다.[33]

6. 라우팅 테이블 증가

인터넷 상의 BGP 테이블 성장


인터넷 상의 AS 수와 등록된 AS 수


BGP와 인터넷 인프라가 직면한 가장 큰 문제 중 하나는 인터넷 라우팅 테이블의 증가이다. 글로벌 라우팅 테이블이 커져서 오래되거나 성능이 떨어지는 일부 라우터가 테이블을 유지하는 데 필요한 메모리나 CPU 부하에 대처할 수 없게 되면, 인터넷 연결에서 효과적인 게이트웨이 역할을 할 수 없게 된다. 또한, 라우팅 테이블이 커질수록 주요 연결 변경 후 안정화되는 데 시간이 오래 걸려 네트워크 서비스가 불안정해지거나 사용할 수 없게 될 수 있다.

2001년 말까지 글로벌 라우팅 테이블은 지수적으로 성장하여 광범위한 연결 중단을 위협했다. 이를 방지하기 위해 ISP들은 클래스 없는 도메인 간 라우팅(CIDR)과 경로 집약을 사용하여 글로벌 라우팅 테이블을 가능한 작게 유지하는 데 협력했다. 이는 라우팅 테이블의 성장을 수년 동안 선형적인 과정으로 늦추었지만, 최종 사용자 네트워크의 멀티호밍에 대한 수요가 확대되면서 2004년 중반에는 성장이 다시 초선형적으로 변했다.

경로 집약은 BGP 글로벌 라우팅 테이블의 집계를 개선하여 AS의 라우터에서 필요한 테이블 크기를 줄이는 데 자주 사용된다. 예를 들어, AS1이 172.16.0.0/16의 큰 주소 공간을 할당받았지만, 고객 요구 사항이나 트래픽 엔지니어링 목적 때문에 172.16.0.0/18, 172.16.64.0/18, 172.16.128.0/18의 더 작고 구체적인 경로를 공지해야 하는 상황을 가정해 보자.

AS공지하는 경로경로 수
AS1172.16.0.0/161
AS1172.16.0.0/18, 172.16.64.0/18, 172.16.128.0/18, 172.16.192.0/184



AS2는 AS1에서 여러 경로를 확인할 수 있으며, AS2의 라우팅 정책에 따라 모든 경로를 복사할지, 아니면 일부만 저장할지 결정한다.

ASAS1에서 확인되는 경로AS2의 라우팅 정책에 따른 결정
AS2172.16.0.0/16, 172.16.0.0/18, 172.16.64.0/18, 172.16.128.0/184개의 경로를 모두 복사하거나, 172.16.0.0/16만 저장
AS2172.16.0.0/18, 172.16.64.0/18, 172.16.128.0/183개의 경로를 모두 복사하거나, 172.16.0.0/17 및 172.16.128.0/18 2개만 저장



만약 AS2가 172.16.192.0/18 프리픽스로 데이터를 전송하려 할 때, AS1의 라우터 구성에 따라 데이터가 삭제되거나, 도달할 수 없는 ICMP 메시지가 전송될 수 있다.

2014년에는 업데이트되지 않은 모델에서 Y2K와 유사한 오버플로우가 발생했다.

6. 1. 512k Day

2014년 8월 현재 완전한 IPv4 BGP 테이블은 512,000개 이상의 프리픽스를 포함하고 있었지만,[36] 많은 구형 라우터는 512k(512,000–524,288) 라우팅 테이블 항목의 제한이 있었다.[37][38] 2014년 8월 12일, 전체 테이블로 인한 중단으로 eBay, LastPass, Microsoft Azure 등이 영향을 받았다.[39]

일반적으로 사용되는 여러 Cisco 라우터는 BGP가 공지한 경로를 저장하기 위해 고속 content-addressable memory의 한 형태인 TCAM을 가지고 있었다. 영향을 받은 라우터에서 TCAM은 기본적으로 512k IPv4 경로와 256k IPv6 경로로 할당되었다. 보고된 IPv6 공지 경로 수는 약 20k에 불과했지만, 공지된 IPv4 경로 수는 기본 제한에 도달하여 라우터가 TCAM을 통한 빠른 하드웨어 라우팅 대신 느린 소프트웨어 라우팅을 사용하여 이 문제를 해결하려고 시도하면서 spillover effect가 발생했다.

이 문제를 처리하는 주요 방법은 운영자가 IPv6 경로에 할당된 TCAM의 일부를 재할당하여 더 많은 IPv4 항목을 허용하도록 TCAM 할당을 변경하는 것이며, 이는 대부분의 라우터에서 재부팅이 필요하다. 512k 문제는 많은 IT 전문가들이 예측했다.[40][41][42]

실제로 경로 수를 512k 이상으로 밀어 올린 할당은 07:48 UTC부터 시작하여 짧은 시간에 약 15,000개의 새로운 경로를 공지한 것이었다. 이러한 경로는 거의 모두 Verizon 자율 시스템 701 및 705에 대한 것이었으며, 더 큰 블록의 비집계의 결과로 생성되어 수천 개의 경로를 도입하고 라우팅 테이블이 515,000개 항목에 도달하게 만들었다. 새로운 경로는 5분 이내에 다시 집계된 것으로 보이지만 인터넷 전반의 불안정성은 몇 시간 동안 지속된 것으로 보인다.[43] Verizon이 라우팅 테이블이 단기간에 512k 항목을 초과하게 만들지 않았더라도 자연스러운 증가를 통해 곧 발생했을 것이다.

6. 2. 부하 분산

BGP가 직면한 가장 큰 문제 중 하나는 인터넷 라우팅 테이블의 성장이다. 이는 인터넷 인프라 전체의 문제이기도 하다. 글로벌 라우팅 테이블이 너무 커지면, 오래되거나 성능이 떨어지는 일부 라우터는 테이블을 유지하는 데 필요한 메모리나 CPU 부하를 감당할 수 없게 된다. 이렇게 되면 해당 라우터는 인터넷 연결 부분 간의 효과적인 게이트웨이 역할을 할 수 없게 된다. 또한, 라우팅 테이블이 커질수록 주요 연결 변경 후 안정화되는 데 시간이 더 오래 걸려 네트워크 서비스가 불안정해지거나 사용할 수 없게 될 수 있다.

2001년 말까지 글로벌 라우팅 테이블은 지수적으로 성장하여 광범위한 연결 중단을 위협했다. 이를 막기 위해 ISP들은 클래스 없는 도메인 간 라우팅(CIDR)과 경로 집약을 사용하여 글로벌 라우팅 테이블을 가능한 작게 유지하는 데 협력했다. 이로 인해 라우팅 테이블의 성장은 수년 동안 선형적인 과정으로 늦춰졌지만, 최종 사용자 네트워크의 멀티호밍에 대한 수요가 확대되면서 2004년 중반에는 성장이 다시 초선형적으로 변했다.[9]

라우팅 테이블 증가의 또 다른 요인은 멀티 홈 네트워크의 부하 분산 필요성이다. BGP 경로 선택 프로세스의 제한 때문에 멀티 홈 네트워크로 들어오는 인바운드 트래픽을 여러 경로에 분산하는 것은 쉽지 않다. 멀티 홈 네트워크의 경우 모든 BGP 피어를 통해 동일한 네트워크 블록을 알리면 외부 네트워크가 혼잡한 경로를 최적으로 선택하게 되어, 하나 이상의 인바운드 링크가 혼잡해지고 다른 링크는 활용도가 낮아질 수 있다. 다른 대부분의 라우팅 프로토콜과 마찬가지로 BGP는 혼잡을 감지하지 못한다.

이 문제를 해결하기 위해 해당 멀티 홈 네트워크의 BGP 관리자는 큰 연속 IP 주소 블록을 더 작은 블록으로 나누고, 서로 다른 블록이 서로 다른 경로에서 최적으로 보이도록 경로 공지를 조정할 수 있다. 이렇게 하면 외부 네트워크가 멀티 홈 네트워크의 다른 블록에 도달하기 위해 다른 경로를 선택하게 된다. 그러나 이 경우 글로벌 BGP 테이블에서 보이는 경로 수가 증가한다.

부하 분산과 관련된 라우팅 테이블 문제를 해결하는 한 가지 방법은 로케이터/식별자 분리 프로토콜(BGP/LISP) 게이트웨이를 인터넷 교환 지점 내에 배포하여 여러 링크에서 인그레스 트래픽 엔지니어링을 허용하는 것이다. 이 기술은 글로벌 BGP 테이블에서 보이는 경로 수를 증가시키지 않는다.

7. 보안

기본적으로 BGP를 실행하는 라우터는 다른 BGP 라우터가 공지하는 경로를 기본적으로 수락한다. 이는 인터넷을 통해 트래픽을 자동적이고 분산적으로 라우팅할 수 있게 해주지만, BGP 하이재킹이라고 알려진 사고 또는 악의적인 방해 행위에 인터넷이 취약해질 수 있다. BGP가 인터넷의 핵심 시스템에 내장된 정도와 인터넷을 구성하는 많은 다른 조직이 운영하는 다양한 네트워크의 수로 인해, 이 취약성을 수정하는 것(예: BGP 라우터의 신원을 확인하기 위해 암호화 키 사용을 도입하는 것)은 기술적, 경제적으로 어려운 문제이다.[46]

8. 구현

BGP4는 인터넷 라우팅의 표준이며, 대부분의 인터넷 서비스 제공업체(ISP)가 서로 간의 라우팅을 설정하는 데 필요하다. 매우 큰 사설 IP 네트워크는 내부적으로 BGP를 사용하기도 한다. 예를 들어, 여러 개의 대형 최단 경로 우선(OSPF) 네트워크를 결합하거나, 더 나은 이중화를 위해 네트워크를 멀티호밍(단일 ISP에 대한 여러 접속 지점 또는 여러 ISP에 대한 접속 지점)하는 경우에 BGP를 사용할 수 있다.

소규모 사무실/홈 오피스(SOHO)용 소형 라우터는 BGP 기능을 포함하지 않을 수 있다. 다른 상용 라우터는 BGP를 지원하는 특정 소프트웨어 실행 이미지 또는 이를 활성화하는 라이선스가 필요할 수 있다. 레이어 3 스위치는 라우터보다 BGP를 지원할 가능성이 적지만, 많은 고급 레이어 3 스위치는 BGP를 실행할 수 있다.

스위치로 판매되는 제품은 전체 인터넷 테이블과 내부 경로보다 훨씬 작은 BGP 테이블 크기 제한을 가질 수 있다. 이러한 장치는 BGP 백본 오브 백본에 의해 연결된 여러 소규모 기업 중 하나를 나타내는 컨페더레이션 AS 또는 ISP에 경로를 알리지만 기본 경로와 소수의 집계된 경로만 수락하는 소규모 기업과 같은 네트워크의 일부에 대한 BGP 라우팅에 사용될 때 유용할 수 있다.

인터넷에 대한 단일 진입점만 있는 네트워크에 사용되는 BGP 라우터는 다중 홈 네트워크보다 훨씬 작은 라우팅 테이블 크기(따라서 RAM 및 CPU 요구 사항)를 가질 수 있다. 간단한 다중 홈 설정조차도 적당한 라우팅 테이블 크기를 가질 수 있다. BGP 라우터에 필요한 실제 메모리 양은 다른 BGP 피어와 교환되는 BGP 정보의 양과 특정 라우터가 BGP 정보를 저장하는 방식에 따라 달라진다. 라우터는 특정 인접 AS에 대한 경로 광고 및 수락에 대한 서로 다른 정책을 관리하기 위해 경로의 사본을 두 개 이상 보관해야 할 수 있다. "뷰"라는 용어는 실행 중인 라우터에서 이러한 서로 다른 정책 관계에 자주 사용된다.

한 라우터 구현이 다른 구현보다 경로당 더 많은 메모리를 사용하는 경우 이는 처리 속도와 메모리를 교환하는 정당한 설계 선택일 수 있다. 전체 IPv4 BGP 테이블은 2015년 8월 현재 590,000개 이상의 접두사를 초과한다. 대형 ISP는 내부 및 고객 경로에 대해 50%를 더 추가할 수 있다. 다시 구현에 따라 서로 다른 피어 AS의 각 보기에 대해 별도의 테이블이 유지될 수 있다.

8. 1. 자유 및 오픈 소스 BGP 구현

BGP의 주요 자유 및 오픈 소스 구현은 다음과 같다.

  • BIRD: 유닉스 계열 시스템을 위한 GPL 라우팅 패키지이다.
  • FRRouting: 유닉스 계열 시스템을 위한 Quagga의 포크이다.
  • * Quagga: 유닉스 계열 시스템을 위한 GNU Zebra의 포크이다. (더 이상 개발되지 않음).
  • * GNU Zebra: BGP4를 지원하는 GPL 라우팅 제품군이다.(중단됨).[47]
  • OpenBGPD: OpenBSD 팀에서 제공하는 BSD 라이선스 구현이다.
  • XORP: eXtensible Open Router Platform, BSD 라이선스 라우팅 프로토콜 제품군이다.


BGP 적합성, 부하 또는 스트레스 성능을 테스트하기 위한 시스템은 다음 공급업체에서 제공된다.

참조

[1] 웹사이트 History for rfc1105 https://datatracker.[...] IETF 1989-06
[2] 웹사이트 BGP: Border Gateway Protocol Explained http://www.orbit-com[...] 2013-10-08
[3] 웹사이트 Network Routing with Path Vector Protocols: Theory and Applications https://conferences.[...] 2003
[4] 웹사이트 The Two-Napkin Protocol https://computerhist[...] 2015-03-04
[5] 웹사이트 The Two-Napkin Protocol #WeAreCisco https://weare.cisco.[...] 2020-07-02
[6] 간행물 BGP - A Tale of Two Napkins https://weare.cisco.[...] Cisco Systems
[7] 웹사이트 The History of Border Gateway Protocol https://datapath.io/[...]
[8] IETF A Border Gateway Protocol 4 (BGP-4)
[9] 문서 RFC 4274
[10] IETF Capabilities Advertisement with BGP-4 2000-05
[11] IETF Multiprotocol Extensions for BGP-4 2000-06
[12] IETF BGP/MPLS VPNs 2004-04
[13] 웹사이트 BGP Best Path Selection Algorithm https://www.cisco.co[...]
[14] 웹사이트 Understanding BGP Path Selection https://www.juniper.[...]
[15] IETF RFC 1997
[16] 웹사이트 Border Gateway Protocol (BGP) Well-known Communities https://www.iana.org[...]
[17] 웹사이트 BGP Community Support {{!}} iFog GmbH https://ifog.ch/en/b[...]
[18] 웹사이트 BGP communities https://retn.net/bgp[...]
[19] 웹사이트 BGP Community Guides http://www.onesc.net[...]
[20] IETF RFC 4360
[21] 웹사이트 Border Gateway Protocol (BGP) Extended Communities https://www.iana.org[...]
[22] 웹사이트 IETF drafts on BGP signalled QoS http://www.bgp-qos.o[...] Thomas Knoll 2008
[23] 웹사이트 Large BGP Communities http://largebgpcommu[...]
[24] 웹사이트 Border Gateway Protocol (BGP) https://www.cisco.co[...]
[25] IETF BGP Route Reflection: An Alternative to Full Mesh Internal BGP (iBGP) 2006-04
[26] 웹사이트 Info http://www.ietf.org/[...] www.ietf.org
[27] 웹사이트 Info http://www.ietf.org/[...] www.ietf.org
[28] 웹사이트 Info http://www.ietf.org/[...] www.ietf.org
[29] 웹사이트 Route Flap Damping Exacerbates Internet Routing Convergence http://web.eecs.umic[...] 1998-11
[30] 웹사이트 Timer Interaction in Route Flap Damping http://www.cs.arizon[...] 2005-06
[31] 뉴스 BGP Route Flap Damping https://tools.ietf.o[...] Tools.ietf.org 1998-11
[32] 뉴스 RIPE Routing Working Group Recommendations On Route-flap Damping http://www.ripe.net/[...] RIPE Network Coordination Centre 2006-05-10
[33] 뉴스 draft-ymbk-rfd-usable-02 - Making Route Flap Damping Usable http://tools.ietf.or[...] Tools.ietf.org
[34] 웹사이트 CAT 6500 and 7600 Series Routers and Switches TCAM Allocation Adjustment Procedures https://www.cisco.co[...]
[35] 웹사이트 Internet Touches Half Million Routes: Outages Possible Next Week http://www.renesys.c[...] 2014-08-13
[36] 웹사이트 BGP Reports http://bgp.potaroo.n[...]
[37] 웹사이트 CAT 6500 and 7600 Series Routers and Switches TCAM Allocation Adjustment Procedures http://www.cisco.com[...] 2015-03-09
[38] 웹사이트 Internet Touches Half Million Routes: Outages Possible Next Week https://web.archive.[...] 2015-01-02
[39] 뉴스 Internet infrastructure 'needs updating or more blackouts will happen' https://www.theguard[...] 2014-08-14
[40] 웹사이트 BOF report https://www.nanog.or[...] www.nanog.org 2019-12-17
[41] 웹사이트 TCAM — a Deeper Look and the impact of IPv6 http://etherealmind.[...] 2011-01-26
[42] 웹사이트 The IPv4 Depletion site http://www.ipv4deple[...]
[43] 웹사이트 What caused today's Internet hiccup https://www.bgpmon.n[...]
[44] 문서 16-bit Autonomous System Report http://www.potaroo.n[...] 2011
[45] 간행물 BGP Support for Four-octet AS Number Space IETF 2007-05
[46] 뉴스 Quick fix for an early Internet problem lives on a quarter-century later https://www.washingt[...] 2015-05-31
[47] 웹사이트 Zebra - GNU Project - Free Software Foundation https://www.gnu.org/[...]
[48] 웹인용 Archived copy http://www.orbit-com[...] 2013-10-08
[49] 웹인용 RFC 4271 - A Border Gateway Protocol 4 (BGP-4) http://tools.ietf.or[...]
[50] 웹인용 The History of Border Gateway Protocol https://datapath.io/[...]



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com