BGP(경계 경로 프로토콜)란? 인터넷 라우팅 기초 완전정복

한눈에 보기

BGP(Border Gateway Protocol)는 서로 다른 조직이 운영하는 자율 시스템(AS) 사이에서 "어떤 IP 대역으로 가는 길이 있는가"를 교환하는 프로토콜입니다. 현재 규격은 RFC 4271(BGP-4)이며, TCP 179번 포트 위에서 동작합니다. 이 글은 BGP의 기원, 메시지와 경로 선택 방식, 피어링과 트랜짓, 하이재킹과 RPKI, 실제 사건 두 건(2008 YouTube, 2021 Facebook)을 공개 자료로 확인된 범위만 정리합니다.

BGP는 AS 사이의 경로(AS_PATH)를 교환하며 내부망 프로토콜과 목적이 다릅니다.
경로 선택은 정책이 먼저이고, 동률일 때 AS_PATH 길이 등 정해진 순서로 가립니다.
기본 설계에는 광고의 정당성을 검증하는 기능이 없고, RPKI가 이를 보완합니다.
실제 장애는 악의적 공격뿐 아니라 설정 실수와 내부 도구 결함에서도 나옵니다.

기원: EGP에서 BGP로

BGP의 첫 규격인 RFC 1105(1989년 6월, K. Lougheed와 Y. Rekhter)는 NSFNET 백본에서 쓰이던 EGP(RFC 904)의 경험을 바탕으로 AS 사이의 도달 가능성 정보를 교환하는 방법을 제시했고, 초기 구현은 TCP 179번 포트를 사용했습니다. RFC 1105의 "AS 경로" 개념으로 AS 연결 그래프를 만들어 경로 루프를 걸러내고 AS 단위 정책을 적용할 수 있게 된 것이 핵심이었습니다. 이후 RFC 4271(BGP-4)로 이어졌고, RFC 6793이 AS 번호를 2바이트에서 4바이트로 확장했습니다.

메시지와 경로 선택 규칙

RFC 4271은 네 가지 메시지를 정의합니다. 번호순으로 OPEN(1), UPDATE(2), NOTIFICATION(3), KEEPALIVE(4)입니다. 같은 AS 안의 피어는 IBGP, 다른 AS와의 연결은 EBGP라 부릅니다. UPDATE에는 ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC(MED), LOCAL_PREF 같은 경로 속성이 실립니다. EBGP로 내보낼 때는 AS_PATH에 자신의 AS 번호를 덧붙이고, IBGP로 보낼 때는 AS_PATH를 고치지 않습니다. LOCAL_PREF는 같은 AS 내부 피어에게 전달되는 속성입니다.

순서	기준 (RFC 4271 9.1.1, 9.1.2.2 기준)
1	선호도(degree of preference): 내부 피어에서는 LOCAL_PREF를 직접 쓰거나 정책으로 계산
2	AS_PATH에 든 AS 수가 적은 경로
3	ORIGIN 값이 낮은 경로
4	같은 이웃 AS 사이에서 MED가 더 선호되는 경로
5	EBGP로 배운 경로가 있으면 IBGP 경로 제외
6	NEXT_HOP까지의 내부 비용이 낮은 경로
7	BGP 식별자가 가장 낮은 광고자, 그다음 가장 낮은 피어 주소

실제 장비는 벤더별 확장 규칙이 있을 수 있으므로 표는 표준 문서의 기본 순서로만 이해하세요.

AS 번호

AS 번호는 지역 인터넷 레지스트리가 할당합니다. RFC 4271은 AS 번호를 2바이트 정수로 정의했고, RFC 6793이 4바이트로 확장하면서 2바이트만 아는 구형 장비를 위해 23456번을 AS_TRANS로 예약했습니다. 아래 사례에 나오는 AS 번호는 모두 공개 분석 자료에 적힌 값입니다.

실제 사례

2008년 2월 24일: 파키스탄 통신사와 YouTube

RIPE NCC가 공개한 사례 분석에 따르면 YouTube(AS36561)는 208.65.152.0/22를 광고하고 있었습니다. 협정 세계시(UTC) 18:47에 파키스탄 텔레콤(AS17557)이 더 구체적인 208.65.153.0/24를 광고했고, 상위 사업자 PCCW(AS3491)가 이를 전파하면서 YouTube 트래픽이 끌려갔습니다. 위키백과는 파키스탄 규제기관의 YouTube 차단 조치가 의도치 않게 전 세계 BGP 테이블에서 블랙홀 경로가 되었다고 설명합니다. 이후 YouTube가 같은 /24와 더 좁은 /25 두 개를 광고하자 가장 길게 일치하는 경로가 우선하는 규칙에 따라 트래픽이 YouTube로 돌아갔고, PCCW가 해당 광고를 철회한 마지막 시각은 21:01경(약 2시간 14분)입니다. 배울 점은 BGP에서 더 구체적인 프리픽스가 이긴다는 점과, 광고의 출처를 검증하는 장치가 없으면 한 곳의 실수가 널리 퍼질 수 있다는 점입니다.

2021년 10월 4일: Facebook 장애

Cloudflare의 공개 분석에 따르면 UTC 15:40경 Facebook의 라우팅 변화가 정점에 이르렀고, 15:58에 Facebook이 DNS 프리픽스로 가는 경로를 광고하지 않는 것이 관측되었습니다(Facebook의 AS 번호는 AS32934). Meta의 공식 설명은 백본 용량을 점검하는 유지보수 명령이 전 세계 백본 연결을 모두 끊었고, 이를 막아야 할 감사 도구의 버그로 중단되지 않았다고 밝힙니다. 데이터센터가 연결을 잃으면 DNS 서버가 BGP 광고를 스스로 철회하도록 되어 있어 DNS 서버가 가동 중이어도 외부에서 닿을 수 없게 되었습니다. Cloudflare는 재시도가 몰려 1.1.1.1의 DNS 질의가 평소의 약 30배가 되었다고 밝혔고, facebook.com은 21:20 무렵 다시 조회되기 시작했습니다. 이 사건은 외부 공격이 아니라 내부 설정·도구 문제였다는 점, 그리고 복구에 물리적 접근이 필요했다는 점이 교훈입니다.

RPKI와 경로 출처 검증

RFC 6811은 BGP 경로의 출처 AS가 해당 프리픽스 보유자에게 승인받았는지 확인하는 방식을 정의합니다. ROA(서명된 객체)에서 얻은 검증된 정보(VRP)는 IP 주소, 프리픽스 길이, 최대 길이, 출처 AS 번호를 담고, 경로는 NotFound, Valid, Invalid 중 하나가 됩니다. RFC는 이 방식이 프리픽스 오광고와 중간자 위협을 부분적으로만 해결한다고 밝힙니다. 출처만 확인할 뿐 경로 전체를 검증하지는 않습니다.

흔한 오해와 정정

오해: BGP는 가장 빠른 길을 고른다. 실제: 속도·지연이 아니라 정책과 AS_PATH 길이 같은 속성으로 고릅니다.
오해: BGP 장애는 대부분 해킹이다. 실제: 위 두 사례는 각각 통신사 차단 조치의 부작용과 내부 도구 결함에서 비롯되었다고 공개 자료가 설명합니다.
오해: RPKI가 있으면 하이재킹이 사라진다. 실제: 출처 검증만 담당하며 채택하지 않은 네트워크에서는 효과가 없습니다.

한계와 더 알아볼 점

이 글은 RFC 4271, RFC 1105, RFC 6811, RFC 6793, RIPE NCC와 Cloudflare, Meta의 공개 문서로 확인한 내용만 담았습니다. 사건의 영향 규모는 보고마다 달라 수치를 단정하지 않았고, RPKI 도입률 같은 변하는 통계는 싣지 않았습니다. 경로 속성이 실제 장비에서 어떻게 설정되는지는 벤더 문서를 확인하세요.

자주 묻는 질문

일반 가정에서 쓰는 공유기도 BGP를 사용하나요?

보통은 사용하지 않습니다. 가정이나 사무실 내부망은 정적 경로나 DHCP로 받은 기본 게이트웨이 정보로 충분합니다. BGP는 자체 AS 번호를 가진 조직이 다른 조직과 경로를 교환할 때 씁니다.

BGP 하이재킹이 발생하면 사용자가 알아챌 수 있나요?

사용자는 특정 사이트가 안 열리는 정도로 느끼는 경우가 많습니다. 2008년 사례처럼 네트워크 운영자와 연구 기관의 모니터링으로 원인이 밝혀지는 경우가 일반적입니다.

BGP는 어떤 포트를 쓰나요?

RFC 4271은 BGP가 TCP 179번 포트에서 대기한다고 규정합니다.

피어링과 트랜짓은 무엇이 다른가요?

일반적으로 피어링은 네트워크끼리 직접 연결해 트래픽을 교환하는 관계(무료인 경우가 많음)이고, 트랜짓은 상위 사업자에게 비용을 내고 인터넷 전체로 나가는 경로를 받는 계약입니다. 조건은 사업자마다 다릅니다.

왜 더 구체적인 프리픽스가 이기나요?

라우터는 목적지 주소와 가장 길게 일치하는 프리픽스를 따릅니다. 2008년 사례에서 /22보다 좁은 /24가 먼저 선택된 이유이며, YouTube가 /25를 광고해 트래픽을 되찾은 방법이기도 합니다.

BGP(경계 경로 프로토콜)란? 인터넷 라우팅 기초 완전정복