네트워크 인프라 이해하기 · 제5부 · 사내망을 지사·클라우드·인터넷과 연결하기
두 ISP가 같은 목적지를 알려 주면 BGP는 어느 경로를 고를까
TCP 세션에서 UPDATE·정책·Path Attribute를 거쳐 Prefix가 설치·광고되는 과정
두 ISP가 같은 Prefix를 알려 줘도 BGP는 단순히 가까워 보이는 경로를 고르지 않습니다. Peer에서 받은 Route에 정책을 적용하고 LOCAL_PREF, AS_PATH와 NEXT_HOP 같은 Attribute를 비교한 뒤 사용할 경로를 RIB와 FIB에 반영합니다. 이 글에서는 eBGP·iBGP, Route Reflector와 RPKI가 맡는 범위를 구분하고 Route가 수신·정책·선택·광고 중 어느 단계에서 멈췄는지 찾습니다.
BGP Peer가 TCP로 연결된 뒤 실제 Route를 교환하기까지 어떤 단계를 거칠까↑
BGP Peer는 TCP 포트 179를 사용해 세션을 만들고 OPEN 메시지로 Version과 AS Number를 확인하고 Hold Time과 사용할 Capability를 정합니다. 관계가 성립하면 KEEPALIVE로 생존을 확인하고 UPDATE로 경로를 광고하거나 철회합니다. 심각한 오류는 NOTIFICATION으로 알리고 세션을 닫을 수 있습니다.
TCP가 연결되었다고 원하는 경로를 주고받았다는 뜻은 아닙니다. Peer는 Established인데 Prefix가 없을 수 있고, UPDATE를 받았지만 정책이 거부했을 수도 있습니다. 세션 상태와 Route 상태를 분리해서 봐야 합니다.
TCP Three-Way Handshake가 실패하면 BGP OPEN까지 가지 못합니다. Source IP와 Route, TCP/179 ACL, Multihop TTL 설정과 인증 불일치처럼 Transport 전제부터 확인해야 합니다. TCP가 성립한 뒤 OPEN으로 받은 AS Number가 기대값과 다르거나 세션에 필요한 Capability를 상대가 지원하지 않으면 NOTIFICATION 후 세션이 종료될 수 있습니다. 다만 RFC 5492에 따라 알지 못하거나 지원하지 않는 Capability를 받았다는 이유만으로 세션을 끊어서는 안 됩니다. Idle, Connect, Active, OpenSent, OpenConfirm, Established 같은 상태는 어느 단계에서 반복되는지 알려 주는 진단 단서입니다.
Established는 Control Channel이 살아 있다는 뜻입니다. Peer가 아무 NLRI도 보내지 않거나 우리 수신 정책이 모두 거부해도 세션은 Established일 수 있습니다. 반대로 Route Refresh나 Graceful Restart Capability가 있는지에 따라 정책 변경·재시작 때 경로 유지 방식이 달라집니다. 세션 Uptime, Prefix Received·Accepted 수와 마지막 Notification을 함께 봐야 “BGP가 붙었다”를 실제 Route 교환 상태로 해석할 수 있습니다.
Peer가 안 올라오면 Source 인터페이스와 Update Source, eBGP Multihop/TTL, ACL·방화벽, AS Number와 인증을 양쪽에서 확인합니다. TCP Established만으로 BGP Capability 합의가 성공한 것은 아닙니다. 상태 변화 로그와 SYN/SYN-ACK, OPEN·NOTIFICATION을 같은 시각으로 맞춰 Transport 실패와 BGP Parameter 거부를 구분합니다.
이 절의 근거 IETF RFC 4271
BGP UPDATE에는 Prefix뿐 아니라 경로를 판단할 여러 Attribute가 함께 온다↑
UPDATE에는 도달 가능한 Prefix와 Path Attribute가 포함됩니다. AS_PATH는 광고가 거쳐 온 AS Sequence를 보여 주며, 자신의 AS가 이미 들어 있으면 Loop로 판단하는 기본 근거가 됩니다. NEXT_HOP은 해당 경로로 패킷을 보낼 다음 지점을 나타냅니다.
BGP는 링크 대역폭이나 물리적 지연을 직접 측정해 최단 경로를 고르지 않습니다. AS_PATH가 짧은 경로를 선호하는 단계가 흔히 있지만, 그보다 앞선 Local 정책이 결과를 바꿀 수 있고 정확한 Decision Process는 구현별 확장을 포함합니다.
한 UPDATE는 도달 가능한 목적지를 나타내는 NLRI와 그 경로에 공통인 Path Attribute를 전달하고, Withdrawn Route로 더 이상 사용할 수 없는 Prefix를 알릴 수 있습니다. MP-BGP에서는 Address Family별 Reachability를 별도 Attribute로 표현합니다. 같은 TCP 세션이 연결된 상태여도 IPv4 Unicast와 IPv6 Unicast Address Family의 활성·정책이 다르면 한쪽 Prefix만 보일 수 있습니다.
AS_PATH는 Loop 방지와 선택에 쓰이고, NEXT_HOP은 실제 전달 전에 라우팅 테이블로 해석해야 하는 주소이며, Data Plane은 그 결과로 마련된 전달 정보를 사용합니다. ORIGIN, MED, LOCAL_PREF, Community도 각기 다른 범위와 의미가 있습니다. Community는 정책에 쓰는 표식입니다. 운영자가 정한 Community는 수신 측이 대응하는 정책을 적용해야 의도한 효과가 납니다. 다만 RFC 1997의 NO_EXPORT처럼 광고 제한이 표준으로 정해진 값도 있습니다. 실제 처리 방식은 상대 운영자에게 확인해야 합니다. Prefix와 모든 Attribute를 한 Route 객체로 읽어야 광고 경로의 의도를 알 수 있습니다.
모든 Attribute가 모든 세션에서 같은 방식으로 전달되는 것은 아닙니다. LOCAL_PREF는 일반적으로 AS 내부 정책에 쓰이고 eBGP 외부로 광고되지 않으며, NEXT_HOP 처리와 Community 전파도 정책에 좌우됩니다. Route를 비교할 때 Prefix만 보지 말고 수신한 전체 Attribute, 적용된 Import 변경과 최종 Best 표시를 저장합니다.
이 절의 근거 IETF RFC 4271
도해에서 확인할 내용 TCP 179 연결과 BGP FSM, OPEN Capability 협상부터 경로 정보가 Adj-RIB-In·Import Policy·Loc-RIB·RIB/FIB·Export Policy·Adj-RIB-Out을 거치는 과정을 확인합니다. 상단의 Idle부터 Established까지의 상태와 하단의 정책·경로 처리 상자를 나누어 읽습니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
우리 AS가 원하는 출구는 거리보다 Local 정책으로 먼저 표현한다↑
한 AS 안에서 LOCAL_PREF를 높여 특정 출구를 선호하거나, 수신 정책으로 Community와 Prefix를 분류할 수 있습니다. 반대로 외부 AS의 유입 경로에 영향을 주기 위해 AS_PATH Prepending, MED, 더 구체적인 Prefix Advertisement 등을 사용할 수 있지만 상대 AS가 그 정보를 어떻게 다룰지는 상대 정책에 달려 있습니다.
“LOCAL_PREF 다음은 항상 AS_PATH”처럼 순서를 하나로 단정하기보다 장비의 Best-Path 문서와 실제 Route 속성을 확인해야 합니다. Weight처럼 Vendor 고유 속성이 앞에 붙거나 Multipath 조건이 별도로 적용될 수 있습니다. 중요한 것은 각 속성이 내부 출구 선택인지, 이웃에게 주는 힌트인지 구분하는 일입니다.
ISP-A에서 받은 Route에 높은 LOCAL_PREF를 주면 우리 AS 내부 라우터가 일반적으로 ISP-A를 Egress로 선호하도록 만들 수 있습니다. 이 값은 iBGP로 내부에 전달되지만 eBGP 이웃에게 그대로 보내는 속성이 아닙니다. 반대로 AS_PATH Prepend와 MED는 외부에서 우리 망으로 들어오는 Inbound 경로 선택에 영향을 주려는 수단입니다. 다만 상대가 자체 LOCAL_PREF를 우선하면 효과가 없을 수 있습니다. Outbound와 Inbound 트래픽을 조정할 때 통제할 수 있는 범위가 다른 이유입니다.
정책은 Prefix List, AS_PATH, Community와 RPKI 상태를 대조해 Attribute를 바꾸거나 Route를 거부합니다. 넓은 Match 하나가 Default Route나 고객 Prefix까지 바꿀 수 있으므로 적용 전 후보 Route 수와 변경 결과를 미리 확인해야 합니다. Best Path 순서는 Vendor 기능과 설정에 따라 확장되므로 암기한 순서보다 장비가 표시하는 선택 사유를 봅니다. 정책의 목표, Match 범위와 기대 승자를 Prefix 예시로 문서화하는 편이 안전합니다.
정책은 Prefix List, AS_PATH·Community 조건과 Route Map/정책 Statement로 값을 허용·거부·수정합니다. 결과를 설명할 때 “BGP가 짧은 길을 골랐다”보다 어느 후보가 어떤 정책을 거쳐 어떤 Attribute 차이에서 탈락했는지 기록합니다. 동일 비용 Multipath 사용 여부와 최대 경로 수도 설정에 따라 달라집니다.
이 절의 근거 IETF RFC 4271 · IETF RFC 7454
도해에서 확인할 내용 왼쪽은 LOCAL_PREF로 우리 망의 출구를 고르는 예이고, 오른쪽은 AS_PATH를 길게 광고해 상대 망의 선택에 영향을 주는 예입니다. MED도 외부에 전달하는 경로 선택 정보이지만, 도해의 설정 예시는 AS_PATH Prepending에 해당합니다. 두 경우 모두 실제 선택 결과는 적용 범위와 상대 망의 정책까지 확인해야 합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
외부에서 받은 BGP Route를 내부 라우터까지 전달하는 방식이 따로 있다↑
서로 다른 AS 사이의 eBGP는 외부 Reachability를 교환하고, 같은 AS 안의 iBGP는 선택에 필요한 BGP 경로를 내부 라우터에 전달합니다. iBGP에서 배운 경로를 다른 iBGP Peer에게 그대로 다시 광고하지 않는 기본 규칙 때문에 대규모 네트워크는 Full Mesh 대신 Route Reflector를 사용하기도 합니다.
Route Reflector는 세션 수를 줄이지만 경로 가시성과 선택 구조를 바꿉니다. 모든 클라이언트가 모든 대안을 직접 보는 것은 아니므로, IGP Cost와 NEXT_HOP Reachability까지 포함해 실제 출구가 의도대로 선택되는지 검증해야 합니다.
Edge 라우터가 ISP에서 받은 NEXT_HOP을 iBGP로 내부에 전달할 때 그 주소까지 IGP·정적 경로·직접 연결 경로 등으로 도달할 수 있어야 실제 패킷이 나갑니다. 환경에 따라 Next-Hop Self로 내부 라우터가 Edge 자신을 Next Hop으로 보게 할 수 있습니다. BGP Route가 Best인데 FIB에 설치되지 않거나 트래픽이 엉뚱한 Exit로 가면 NEXT_HOP Reachability와 IGP Cost를 함께 확인해야 합니다.
Route Reflector는 클라이언트에게 받은 Route를 다른 클라이언트로 전달해 Full Mesh 요구를 줄입니다. 그러나 각 클라이언트가 모든 외부 대안을 직접 비교하지 않고 Reflector가 선택해 보여 준 경로에 의존할 수 있어 Path Hiding이 생길 수 있습니다. Cluster 설계, Add-Path 같은 확장과 IGP 토폴로지를 고려해야 합니다. 세션 수 감소와 최적 경로 가시성 사이의 Trade-off를 실제 장애 시나리오와 트래픽 경로로 검증합니다.
iBGP로 Prefix를 받았어도 라우팅 테이블에서 NEXT_HOP까지의 경로를 찾을 수 있어야 실제 전달에 쓸 수 있습니다. IGP뿐 아니라 정적 경로·직접 연결 경로도 이 조건을 충족할 수 있습니다. Edge 라우터가 next-hop-self로 자신을 Next Hop으로 바꾸거나 외부 링크 주소를 IGP에 알리는 설계가 필요할 수 있습니다. BGP 테이블, RIB, Next-Hop Route와 FIB를 함께 보아 Control Plane 전달과 Data Plane 출구를 연결합니다.
이 절의 근거 IETF RFC 4271 · IETF RFC 4456
RPKI는 이 Prefix를 Origin AS가 광고해도 되는지 어떻게 확인할까↑
RPKI의 Route Origin Authorization은 어떤 AS가 어떤 Prefix 길이까지 Origin으로 광고할 수 있는지 서명된 형태로 나타냅니다. 라우터는 수신한 BGP Route를 Valid, Invalid, NotFound 같은 검증 상태로 분류하고 Local 정책에 활용할 수 있습니다.
이 검증은 AS_PATH 전체가 진짜인지 증명하지 않습니다. Origin AS와 Prefix의 관계를 확인하는 단계입니다. 또한 Invalid를 어떻게 처리할지는 운영 정책이며, 검증 정보의 가용성과 예외 처리까지 설계해야 합니다. RPKI는 Prefix Filter, Max-Prefix, Peer별 Import·송신 정책을 대체하지 않습니다.
수신 Route의 Prefix를 포함하는 검증된 ROA 정보 중 Origin AS와 Prefix 길이 조건을 모두 만족하는 항목이 하나라도 있으면 Valid입니다. Prefix를 포함하는 ROA 정보는 있지만 AS와 길이 조건을 모두 만족하는 항목이 없으면 Invalid이고, Prefix를 포함하는 ROA 정보 자체가 없으면 NotFound입니다. 더 구체적인 Prefix가 ROA의 Max Length를 넘고 이를 허용하는 다른 항목도 없으면 Invalid가 되므로 ROA 생성 때 실제 광고 길이를 확인해야 합니다. 이 상태는 검증된 정보를 수신 경로와 대조한 결과로, 라우터가 경로 정책을 적용할 때 쓰는 입력값입니다.
라우터가 Validation Cache와 통신하지 못했을 때 기존 결과를 얼마나 유지하는지, Stale 정보와 Fail-Open·Fail-Closed 동작은 구현과 운영 정책에 따라 다릅니다. Invalid Route를 자동 거부하기 전에는 고객·자사 Prefix의 ROA 오류 대응 절차가 필요합니다. Origin Validation은 Route Leak, 잘못된 AS_PATH 전체와 모든 Hijack을 막지 못합니다. Prefix Filter, Max-Prefix와 Peer 계약 검증을 함께 유지해야 합니다.
이 검증은 AS_PATH 전체가 실제 이동 경로인지 보장하지 않고, Prefix 소유권이나 서비스 안전성을 완전히 판정하지도 않습니다. 운영자는 Validation 상태를 수신 정책에서 어떻게 처리할지 정하고, Validator 장애와 오래된 Cache가 경로 선택에 미치는 영향도 설계합니다. Route 누락 시 ROA 원문, 검증 시각, 광고 Prefix Length와 실제 정책 Action을 함께 확인합니다.
이 절의 근거 IETF RFC 6811
Route가 보이지 않으면 수신부터 광고까지 어느 단계에서 멈췄는지 찾는다↑
상황: ISP-A에서 Prefix를 받았다고 보이지만 트래픽은 계속 ISP-B로 나갑니다.
- Peer의 TCP·BGP 상태, Remote AS, Capability와 마지막 Reset 이유를 확인합니다.
- 해당 Prefix를 실제로 받았는지, 수신 정책을 통과했는지 구분합니다.
- 각 후보의 NEXT_HOP, LOCAL_PREF, AS_PATH, MED, Community와 RPKI 상태를 나란히 비교합니다.
- Best Path로 선택된 경로가 RIB와 FIB에 설치되었는지, 더 구체적인 Prefix가 따로 있는지 확인합니다.
- 라우팅 테이블에서 NEXT_HOP까지의 경로와 실제 출력 인터페이스를 조회합니다.
- 우리 라우터가 각 Peer에 무엇을 광고했는지 송신 정책의 결과까지 검증합니다.
한 Prefix의 수명주기를 네 단계로 나눕니다. 먼저 Peer에서 UPDATE를 실제로 받았는지 확인합니다. 이어 수신 정책을 통과했는지, 후보 가운데 Best Path로 선택되어 RIB·FIB에 설치되었는지, 마지막으로 송신 정책을 거쳐 다른 Peer에 광고되었는지 확인합니다. 각 단계의 Route 수만 보지 말고 문제 Prefix의 Attribute와 거부 사유를 확인합니다. Soft-Reconfiguration 없이도 Route Refresh와 정책 추적 기능을 제공하는지는 플랫폼 문서를 따릅니다.
트래픽 검증에서는 Best Path의 NEXT_HOP을 재귀 조회하고 실제 Egress 카운터와 외부 Trace를 확인합니다. Return 트래픽은 상대 AS 정책이 정하므로 우리 Advertised Route, Looking Glass와 통신 흐름 Telemetry를 별도로 봅니다. 정책 수정 전후 Route Snapshot과 예상 영향 Prefix 수를 보존하고 Max-Prefix 같은 안전장치를 확인합니다. 세션 Reset이 필요하다면 다른 Prefix의 중단 범위와 되돌림 계획을 먼저 정합니다.
Route를 받은 단계(Received), 정책을 통과한 단계(Accepted), 선택·설치된 단계(Best·Installed), 다른 Peer에 광고한 단계(Advertised)는 서로 다릅니다. 장비가 저장하지 않는 정책 적용 전 Route를 확인하려면 Route Refresh나 별도 관측이 필요할 수 있으므로 운영 영향과 플랫폼 동작을 검토한 뒤 실행합니다.
이 절의 근거 IETF RFC 8212 · IETF RFC 7454
용어사전↑
출처와 검증
- IETF RFC 4271 — BGP-4 Message, Path Attribute와 Decision Process
- IETF RFC 4456 — BGP Route Reflection
- IETF RFC 8212 — eBGP Import·Export Policy가 없을 때의 기본 거부 동작
- IETF RFC 6811 — BGP Prefix Origin Validation
- IETF RFC 7454 — BGP 운영과 보안 권고
- IETF RFC 5492 — BGP Capability 광고와 오류 처리
- IETF RFC 1997 — Community와 NO_EXPORT의 의미
- IETF RFC 8642 — Community 처리의 구현 차이와 운영 확인
Best-Path의 세부 순서, Vendor 고유 Attribute, Multipath 조건과 RPKI 상태 처리 정책은 구현마다 다릅니다. 본문은 RFC 표준 동작과 Local 정책의 역할을 분리합니다.