본문 바로가기
CCIE EI/WAN

BGP Deep Dive

by Optimus Joo 2026. 3. 20.
 
 
 
 
BGP · Deep Dive 원리 중심 · Zero to Hero

BGP
완전 정복

Border Gateway Protocol — 왜 만들어졌는가에서 시작하는 진짜 이해
AS · Path-Vector · Attributes · Community · Policy · Best Path · iBGP/eBGP
인터넷이 BGP로 돌아가는 이유, 모든 원리를 뿌리부터 파헤칩니다

⏱ 총 85H 커리큘럼 🌐 eBGP · iBGP · Route Reflector 🏷 Community · Attribute · Policy 📊 Best Path 12단계 완전 분석 🔐 Security · RPKI · MANRS 🏅 CCNP ENCOR · CCIE ENT/SP
📑 Table of Contents
  1. Phase 0 — BGP는 왜 만들어졌는가 (존재 이유)
  2. Phase 1 — BGP 기초: AS · Path-Vector · TCP
    • EGP의 실패 · AS 번호 · iBGP/eBGP · FSM 6단계
  3. Phase 2 — BGP 메시지 & 세션 수립
    • OPEN · UPDATE · KEEPALIVE · NOTIFICATION · 세션 최적화
  4. Phase 3 — BGP Attributes 완전 분석
    • Well-Known · Optional · Weight · LOCAL_PREF · AS_PATH · MED · NEXT_HOP
  5. Phase 4 — Best Path Selection 12단계 Deep Dive
    • 각 단계의 존재 이유 · 실무 활용 · 함정
  6. Phase 5 — Community Deep Dive ★
    • Well-Known Community · 커스텀 커뮤니티 · Large Community · ISP 실전 예시
  7. Phase 6 — iBGP · Route Reflector · Confederation
  8. Phase 7 — Policy: Route-Map · Filter · Prefix-List
  9. Phase 8 — BGP Security (RPKI · MANRS · Hijacking)
  10. Phase 9 — 고급 기능 & 실전 설계
  11. 트러블슈팅 완전 가이드
🗺 커리큘럼 로드맵
PHASE 0
Why BGP?
EGP 실패, 인터넷 폭발, BGP 탄생 배경
⏱ 4H
PHASE 1
BGP 기초
AS · Path-Vector · iBGP/eBGP · FSM
⏱ 8H
PHASE 2
메시지 & 세션
OPEN · UPDATE · KEEPALIVE · NOTIFICATION
⏱ 6H
PHASE 3
Attributes ★
모든 속성의 존재 이유와 동작 원리
⏱ 12H
PHASE 4
Best Path 12단계
각 단계가 왜 그 순서인지 완전 분석
⏱ 10H
PHASE 5
Community ★★
Well-Known · Custom · Large · ISP 실전
⏱ 12H
PHASE 6
iBGP · RR · Confed
풀메시 문제, RR 원리, Cluster
⏱ 10H
PHASE 7
Policy
Route-Map · Filter · Prefix-List
⏱ 10H
PHASE 8
Security
RPKI · ROA · Hijacking · MANRS
⏱ 8H
PHASE 9
고급 & 실전
Multipath · Graceful Restart · EVPN
⏱ 5H
 
🌍 Phase 0 — BGP는 왜 만들어졌는가 4H
💭
핵심 질문: 왜 기존 라우팅 프로토콜로 인터넷이 안 되는가?
OSPF와 EIGRP는 훌륭한 프로토콜입니다. 그런데 인터넷 전체(900,000개+ 경로)를 OSPF로 돌리면 어떻게 될까요? 모든 라우터가 전체 토폴로지를 저장하고 SPF를 계산해야 합니다. 1990년대 초 인터넷이 폭발적으로 성장하면서 이 방식이 한계에 봉착했습니다. 그리고 결정적으로 — 서로 다른 조직의 네트워크를 하나의 OSPF 도메인으로 묶는 것은 신뢰(Trust)와 정책(Policy) 문제로 애초에 불가능합니다.
0-1. EGP의 실패 — BGP의 전신
시기 사건 문제점
1982년 EGP (Exterior Gateway Protocol, RFC 827) 등장 트리 구조 가정. 루프 방지 불가. AS 간 정책 표현 방법 없음
1988년 인터넷 급성장 — EGP 한계 봉착 EGP는 ARPANET 단일 백본을 가정. 멀티홈, 상업적 ISP 등장 대응 불가
1989년 BGP-1 (RFC 1105) 발표 "3 napkin protocol" — 세 명이 냅킨에 설계. Path-Vector 개념 도입
1994년 BGP-4 (RFC 1771) — CIDR 지원 Classless Inter-Domain Routing 지원으로 주소 고갈 지연
2006년 BGP-4 업데이트 (RFC 4271) 현재 표준. 4바이트 ASN, IPv6, Multiprotocol 확장
0-2. BGP가 해결해야 했던 3가지 근본 문제
🔄
① 루프 방지
수백만 개 라우터가 연결된 인터넷에서 경로 루프는 재앙. AS_PATH에 자신의 AS 번호를 추가하여, 자신의 ASN이 포함된 경로를 받으면 무시함으로써 루프를 원천 차단.
📜
② 정책 표현
KT는 SK를 통해 중국 트래픽을 전달하고 싶지 않을 수 있습니다. Attributes + Route Policy로 "어떤 경로를 받고, 어떤 경로를 광고할지"를 세밀하게 제어.
📏
③ 확장성
900K+ 경로를 모든 라우터가 처리해야 합니다. Link-State는 전체 토폴로지 계산이 필요하지만, Path-Vector는 "다음 홉(AS)만" 알면 됩니다.
🗺
비유로 이해하는 BGP
OSPF/IS-IS가 "도시 내 도로 지도 앱"이라면, BGP는 "국가 간 항공 노선 협약"입니다. 도시 내에서는 모든 도로를 알아야 하지만, 뉴욕→서울 항공편은 "어느 항공사, 어느 경유지를 쓸지"만 알면 됩니다. 각 항공사(AS)는 자신의 내부 운항 경로를 공개하지 않아도 됩니다. 그리고 "우리는 A항공사 경유는 받지 않겠다"는 비즈니스 정책도 표현할 수 있어야 합니다. BGP는 이 국제 항공 협약 체계입니다.
🔩 Phase 1 — BGP 기초: AS · Path-Vector · TCP 8H
1-1. AS (Autonomous System) — BGP의 기본 단위
💡
왜 AS 개념이 필요한가?
인터넷은 단일 조직이 아닌 수천 개의 독립적인 네트워크(KT, AWS, Google, 기업 등)가 모인 집합체입니다. 각 조직은 독자적인 라우팅 정책을 가지고, 내부 구조는 외부에 공개하지 않으면서 서로 연결됩니다. 이 독립적 관리 단위가 AS입니다.
항목 내용
AS 번호 (2바이트) 1~65535 / 공인: 1~64495 / 사설: 64512~65534 / 예약: 65535
AS 번호 (4바이트) RFC 4893. 1~4,294,967,295 / 사설: 4,200,000,000~4,294,967,294
AS 번호 획득 한국: KRNIC/KISA → APNIC → IANA 위임 구조
AS 타입 Transit AS (타 AS 트래픽 통과), Stub AS (자신 트래픽만), Multi-Homed (복수 연결)
표기법 Dotted notation: 2바이트.2바이트 (예: 65001.1 = 4,259,840,001)
1-2. Path-Vector — BGP 알고리즘의 핵심 원리
💡
왜 Distance-Vector도 Link-State도 아닌 Path-Vector인가?
Distance-Vector (RIP): "목적지까지의 거리(홉 수)만 광고" → 루프 방지를 위해 Split Horizon 등 복잡한 메커니즘 필요. 수렴 느림.
Link-State (OSPF): "전체 토폴로지 공유" → 900K 경로 환경에서 SPF 계산 불가. 타 조직 내부 구조 공개 필요.
Path-Vector (BGP): "목적지까지의 AS 경로 목록을 광고" → AS_PATH에 자신이 포함되면 루프 즉시 감지. 타 AS 내부 구조 불필요. 정책 표현 용이.
1-3. eBGP vs iBGP — 왜 두 가지가 필요한가?
💡
iBGP의 존재 이유
큰 ISP나 기업은 AS 내부에 여러 라우터가 있습니다. 외부(eBGP)에서 받은 경로를 AS 내부 모든 라우터에 전달하려면 어떻게 해야 할까요? IGP(OSPF)로는 BGP 속성을 전달할 수 없습니다. 그래서 같은 AS 내에서도 BGP를 사용하는데, 이것이 iBGP입니다. iBGP는 AS 내부에서 BGP 경로와 속성을 보존하며 전달하는 역할을 합니다.
항목 eBGP iBGP
피어 관계 서로 다른 AS 간 같은 AS 내부
TTL 기본값 1 (직접 연결 필수) 255 (멀리서도 가능, Loopback 피어링)
AD (Administrative Distance) 20 (매우 신뢰) 200 (낮은 신뢰, IGP 우선)
NEXT_HOP 변경 자신으로 변경 변경 안 함 (기본) → next-hop-self 필요
LOCAL_PREF 전파 전파 안 함 (AS 내부 속성) 전파함
MED 전파 인접 AS에만 전파 전파함
루프 방지 AS_PATH (자신 ASN 포함 시 거부) Split Horizon (iBGP→iBGP 재광고 금지)
풀메시 요구 불필요 기본적으로 필요 (RR로 해소)
1-4. BGP Finite State Machine (FSM) — 6단계
1
Idle — 대기
BGP 프로세스 시작 전 또는 에러 후 대기 상태. ConnectRetry 타이머 초기화. 관리자의 clear ip bgp 또는 에러 후 이 상태로 복귀.
2
Connect — TCP 연결 시도
TCP 3-way handshake 시도 (Port 179). 성공 시 OpenSent로 이동. 실패 시 ConnectRetry 타이머 초기화 후 Active로.
3
Active — 재시도 중
TCP 연결 실패 후 재시도. ⚠️ Active 상태가 지속된다면: ACL 차단, 라우팅 문제, update-source 미설정, 방화벽 TCP 179 차단 등.
4
OpenSent — OPEN 메시지 전송
TCP 수립 후 OPEN 메시지 전송. AS 번호, BGP 버전, Hold Time, BGP ID, Capabilities 포함. 상대의 OPEN을 기다림.
5
OpenConfirm — OPEN 수신, KEEPALIVE 교환
양쪽 OPEN 검증 성공. KEEPALIVE 교환으로 Hold Time 협상 완료. NOTIFICATION 수신 시 Idle로 복귀.
6
Established ✅ — 세션 수립 완료
BGP 피어 관계 완전 수립. UPDATE 메시지로 경로 교환 시작. Hold Timer(기본 180초) 내 KEEPALIVE 미수신 시 세션 종료.
📨 Phase 2 — BGP 메시지 & 세션 수립 6H
2-1. BGP 메시지 타입 4종 — 각 메시지의 존재 이유
메시지 역할 왜 필요한가 주요 필드
OPEN 세션 협상 피어 간 AS 번호, 능력(Capabilities), Hold Time 합의. 한 번만 교환. Version(1), My AS(2), Hold Time(2), BGP ID(4), Opt Params
UPDATE 경로 추가/철회 새 경로 광고 또는 기존 경로 철회. Path Attributes + NLRI 포함. Withdrawn Routes, Path Attributes, NLRI
KEEPALIVE 세션 유지 TCP 위에서 동작하므로 세션 생존 여부를 주기적으로 확인. 19바이트 고정. Header만 (19B)
NOTIFICATION 에러 보고 + 종료 오류 발생 시 이유를 상대에게 알리고 세션 종료. TCP 연결도 닫음. Error Code(1), Subcode(1), Data
2-2. UPDATE 메시지 구조 심층 분석
🔑
UPDATE 메시지가 BGP의 핵심
BGP의 모든 기능 — 경로 광고, 철회, 속성 전달, 정책 적용 — 이 UPDATE 하나에 담겨 있습니다.
① Withdrawn Routes: 더 이상 유효하지 않은 프리픽스 목록 (철회)
② Path Attributes: AS_PATH, NEXT_HOP, LOCAL_PREF, MED, Community 등 모든 속성
③ NLRI (Network Layer Reachability Information): 새로 광고할 프리픽스 목록
하나의 UPDATE에 여러 프리픽스를 묶어 전달할 수 있어 효율적입니다.
2-3. BGP 세션 타이머 — 왜 이 값인가
타이머 기본값 존재 이유 권장 설정
Hold Timer 180초 이 시간 내 KEEPALIVE/UPDATE 미수신 시 세션 종료. 죽은 피어 감지. 인터넷: 90초 / 데이터센터: 30초
Keepalive Timer 60초 (Hold/3) Hold Timer의 1/3마다 KEEPALIVE 전송으로 세션 유지. Hold와 연동. BFD로 대체 가능
ConnectRetry 120초 TCP 연결 실패 후 재시도 간격. 너무 짧으면 CPU 낭비. 보통 기본값 유지
Min Route Advertisement 30초(eBGP)/5초(iBGP) 동일 피어에게 너무 자주 UPDATE 전송하지 않도록 속도 제한. instability 방지
BGP 기본 설정 + 타이머 최적화
! ─── eBGP 기본 세션 설정 ─────────────────────────
router bgp 65001
  bgp router-id 1.1.1.1
  bgp log-neighbor-changes
  no bgp default ipv4-unicast         ! AFI/SAFI 명시적 활성화 권장

  ! eBGP 피어 (ISP)
  neighbor 203.0.113.1 remote-as 65000
  neighbor 203.0.113.1 description ISP-A-eBGP
  neighbor 203.0.113.1 timers 30 90    ! Keepalive 30s / Hold 90s
  neighbor 203.0.113.1 password BGPsecure2024!  ! MD5 인증

  ! iBGP 피어 (내부 라우터)
  neighbor 10.255.0.2 remote-as 65001
  neighbor 10.255.0.2 update-source Loopback0  ! 안정적 소스
  neighbor 10.255.0.2 timers 10 30      ! 빠른 감지 (데이터센터)
  neighbor 10.255.0.2 next-hop-self         ! iBGP next-hop 자신으로

  address-family ipv4 unicast
    neighbor 203.0.113.1 activate
    neighbor 10.255.0.2 activate
    network 198.51.100.0 mask 255.255.255.0  ! 자신의 프리픽스 광고
    neighbor 203.0.113.1 soft-reconfiguration inbound
  exit-address-family
🏷 Phase 3 — BGP Attributes 완전 분석 12H
💡
왜 BGP는 이렇게 많은 속성이 필요한가?
BGP는 단순히 "경로가 있다/없다"를 알리는 것이 아닙니다. "이 경로를 어떻게 처리해야 하는지"를 함께 전달합니다. 각 속성은 특정 문제를 해결하기 위해 독립적으로 설계되었습니다. 속성이 많은 것은 인터넷 운영의 복잡한 현실을 반영합니다.
3-1. 속성 분류 체계
분류 세부 전파 범위 모르는 속성 처리 예시
Well-Known Mandatory 모든 구현 필수, 반드시 포함 항상 전파 해당 없음 ORIGIN, AS_PATH, NEXT_HOP
Well-Known Discretionary 모든 구현 인식, 포함은 선택 인식 시 전파 해당 없음 LOCAL_PREF, ATOMIC_AGGREGATE
Optional Transitive 일부 구현, 전파됨 모르더라도 전파 Partial 비트 설정 후 전파 Community, AGGREGATOR
Optional Non-Transitive 일부 구현, 전파 안 됨 이해하는 AS만 사용 조용히 삭제 MED, ORIGINATOR_ID, CLUSTER_LIST
3-2. 핵심 Attributes 상세 — 각각의 존재 이유
ORIGIN 경로가 어떻게 BGP에 들어왔는가 Well-Known Mandatory
💡
왜 필요한가
BGP는 다양한 경로를 흡수합니다. "이 경로가 원래 어디서 왔는지"를 추적하는 신뢰도 지표입니다. IGP에서 온 경로(i)가 불완전 재분배 경로(?)보다 신뢰도가 높다는 것을 Best Path 선택에 반영합니다.
값 의미 Best Path 선호도
i (IGP) network 문 또는 aggregate로 직접 광고 가장 선호 ✅
e (EGP) 구식 EGP 프로토콜에서 유래 (현재 거의 없음) 중간
? (Incomplete) redistribute로 BGP에 유입 (출처 불명확) 가장 낮음
AS_PATH 경로가 통과한 AS 목록 — 루프 방지의 핵심 Well-Known Mandatory
💡
왜 필요한가 (BGP 설계의 핵심)
BGP의 루프 방지는 전적으로 AS_PATH에 의존합니다. 경로를 광고할 때 자신의 AS 번호를 앞에 추가합니다(Prepend). 경로를 받았을 때 자신의 ASN이 이미 포함되어 있으면 → 이 경로는 자신을 거쳐 돌아온 것 → 즉시 거부. 이것이 Path-Vector의 핵심입니다.

또한 AS_PATH가 짧을수록 Best Path 선택에서 유리 → 더 적은 AS를 거치는 경로 선호 → 인터넷 트래픽의 자연스러운 최적화.
AS_PATH Prepending 예시
정상 광고: AS_PATH = [65001] → AS65000에서 65001로 1홉
이중 Prepend: AS_PATH = [65001 65001 65001] → 같은 경로지만 3홉처럼 보임
→ 상대 AS가 이 경로를 덜 선호하게 만드는 인바운드 트래픽 조정 기법
NEXT_HOP 실제 트래픽이 향할 다음 IP 주소 Well-Known Mandatory
⚠️
iBGP의 흔한 장애 원인
eBGP는 경로를 받으면 NEXT_HOP을 자신의 IP로 변경합니다. 그러나 iBGP는 NEXT_HOP을 변경하지 않습니다 — 원래 eBGP 피어의 IP가 유지됩니다. AS 내부 라우터가 그 IP에 도달할 수 없으면 경로는 있지만 통신이 안 됩니다. 해결: next-hop-self 또는 IGP에서 외부 피어 IP 광고.
LOCAL_PREF AS 내부 출구 경로 결정 — 아웃바운드 트래픽 제어 Well-Known Discretionary
💡
왜 필요한가
AS에 여러 출구(ISP A, ISP B)가 있을 때, 내부 모든 라우터가 일관된 출구를 선택하게 하려면 어떻게 해야 할까요? LOCAL_PREF는 AS 내부에서만 공유되는 선호도 값입니다. ISP A 경유 경로에 LP=200, ISP B에 LP=100을 설정하면 AS 내 모든 라우터가 ISP A를 선택합니다. eBGP로는 전파되지 않아 외부에 정책이 노출되지 않습니다.
높을수록 선호 (기본 100)
ISP A (Primary): LP = 200
ISP B (Backup): LP = 100
→ AS 내 모든 라우터가 ISP A 선택
전파 범위
iBGP 피어: ✅ 전파됨
eBGP 피어: ❌ 전파 안 됨
→ 내부 정책 외부 노출 없음
MED Multi-Exit Discriminator — 인바운드 트래픽 진입점 제어 Optional Non-Transitive
💡
왜 필요한가 (LOCAL_PREF와의 차이)
LOCAL_PREF가 "우리가 어디로 나갈지"를 제어한다면, MED는 "상대방이 우리에게 들어올 때 어느 입구를 쓸지"를 제안하는 메커니즘입니다. 낮을수록 선호. 인접한 AS에게만 전파되며, 그 AS가 MED를 존중할 의무는 없습니다(권고). 서로 다른 AS에서 온 MED는 기본적으로 비교하지 않습니다(bgp always-compare-med로 변경 가능).
3-3. WEIGHT — Cisco 전용, 로컬 우선순위
🔑
WEIGHT의 특수성
WEIGHT는 Cisco 전용 속성으로 RFC 표준이 아닙니다. UPDATE 메시지에 포함되지 않으며 해당 라우터에서만 적용되어 피어에게 전파되지 않습니다. 가장 높은 WEIGHT가 Best Path 선택의 1순위입니다. 특정 라우터에서만 특정 경로를 선호하고 싶을 때 사용합니다.
🏆 Phase 4 — Best Path Selection 12단계 Deep Dive 10H
💡
왜 12단계나 필요한가?
BGP는 동일한 목적지(프리픽스)에 대해 여러 경로가 존재할 때 하나를 선택해야 합니다. "단순히 가장 짧은 경로"로는 인터넷의 복잡한 비즈니스 관계와 정책을 표현할 수 없습니다. 각 단계는 특정 사용 사례와 정책 레벨을 계층적으로 반영합니다. 1~2단계는 로컬 정책, 3~6단계는 경로 품질, 7~12단계는 tie-breaking입니다.
1
Weight (Cisco 전용)
높을수록 유리 · 기본 0
로컬 라우터에서만 적용. 피어에게 전파 안 됨. 존재 이유: 특정 라우터에서만 빠르게 선호도를 변경하고 싶을 때. 네이버 설정에서 직접 조정.
2
LOCAL_PREF
높을수록 유리 · 기본 100
AS 내부 정책 표현. iBGP로 전파됨. 존재 이유: 멀티홈 환경에서 AS 전체가 일관된 출구를 선택하게 함. "우리 AS는 ISP A를 통해 나간다" 선언.
3
Locally Originated
직접 생성 경로 우선
network/aggregate/redistribute로 자신이 만든 경로. 존재 이유: 자신이 기원(Origin)인 경로가 가장 신뢰도 높다는 원칙. 자신의 경로를 다른 AS에서 받은 경로보다 항상 우선.
4
AS_PATH Length
짧을수록 유리
통과하는 AS 수가 적을수록 선호. 존재 이유: 인터넷 홉 수 최소화 = 지연 감소 + 장애 가능성 감소. AS_PATH Prepend로 인위적 조작 가능 → 인바운드 트래픽 유도.
5
ORIGIN
IGP(i) > EGP(e) > Incomplete(?)
경로 신뢰도 지표. 존재 이유: 명확하게 정의된 경로(network 문)가 재분배된 불확실한 경로보다 신뢰도가 높다는 것을 표현.
6
MED
낮을수록 유리 · 기본 0
같은 AS에서 온 경로들 사이에서만 비교(기본). 존재 이유: 상대 AS가 우리 AS로 진입할 때 어느 입구를 쓸지 "제안". 주의: 서로 다른 AS 경로의 MED는 기본 비교 안 함.
7
eBGP > iBGP
eBGP 경로 우선
외부에서 직접 받은 경로를 내부 경유 경로보다 선호. 존재 이유: iBGP 경로는 이미 AS를 하나 더 거친 경로. eBGP 경로가 더 "신선"하고 직접적.
8
IGP Metric to Next-Hop
낮을수록 유리
BGP Next-Hop까지의 IGP 비용. 존재 이유: Overlay(BGP)와 Underlay(IGP)를 연결하는 핵심. BGP는 경로를 알고 IGP는 실제 전달 방법을 알므로, 더 빠른 물리 경로로 가는 BGP 경로를 선호.
9
Oldest eBGP Path
오래된 경로 우선
존재 이유: 안정성 우선. 오래된 경로 = 더 안정적인 피어 관계를 의미. 빈번한 경로 변경(flapping) 방지. 주의: 동일 eBGP 경로끼리만 비교.
10
BGP Router-ID
낮을수록 유리
피어의 Router-ID(BGP ID) 비교. 존재 이유: 순수 tie-breaking. 어느 피어에서 받았느냐로 결정. 일관성 보장 (같은 환경에서 항상 같은 결과).
11
Cluster List Length
짧을수록 유리
Route Reflector 환경에서만 적용. 존재 이유: RR 클러스터를 적게 거친 경로가 더 직접적인 경로.
12
Neighbor IP Address
낮을수록 유리
피어 IP 주소 비교. 존재 이유: 최후의 tie-breaking. 모든 조건이 같을 때 결정론적(deterministic)으로 하나를 선택해야 하므로.
🧠
Best Path 12단계 암기법 & 실무 인사이트
We Love Oranges AS Oranges Make Pure Refreshment
Weight · Local_pref · Originated · AS_path · Origin · MED · Peer(eBGP>iBGP) · RIF(IGP metric)...

실무에서 실제로 건드리는 단계: 1(Weight), 2(LOCAL_PREF), 4(AS_PATH Prepend), 6(MED). 나머지는 주로 tie-breaking이나 특수 상황에서 관여합니다.
4-1. Best Path 실전 예시 — 이중 ISP 환경
이중 ISP 환경에서 Best Path 제어 — 아웃바운드 + 인바운드
Our AS 65001 두 개의 Border 라우터 BR-1 ISP A 연결 BR-2 ISP B 연결 ISP A (AS 64500) Primary — 10G 전용선 ISP B (AS 64510) Backup — 1G 인터넷 Internet 아웃바운드 제어 (LOCAL_PREF) BR-1 수신 경로: LP=200 설정 BR-2 수신 경로: LP=100 설정 인바운드 제어 (AS_PATH Prepend) BR-1에서: 정상 광고 (1홉) BR-2에서: Prepend 2회 (3홉처럼) 결과: ISP A가 IN/OUT 모두 PrimaryISP A 장애 시 자동으로 ISP B 사용
🏷 Phase 5 — Community Deep Dive ★★ 12H
💡
Community는 왜 만들어졌는가? — BGP의 "태그 시스템"
BGP 경로에 정책을 적용하려면 라우터마다 각각 Route-Map을 설정해야 합니다. 100개의 라우터에 같은 정책을 배포한다고 상상해보세요. Community는 이 문제를 해결합니다. 경로 자체에 "태그(Community)"를 붙이면, 이 태그를 이해하는 모든 라우터가 약속된 정책을 자동으로 적용합니다.

ISP와 고객 간에 Community 값을 약속하면, 고객이 경로에 특정 Community를 붙여 보내는 것만으로 ISP가 해당 경로에 LOCAL_PREF 조정, 광고 범위 제한, AS_PATH Prepend 등을 자동으로 수행합니다. 이것이 인터넷 규모에서 유연한 정책 제어가 가능한 이유입니다.
5-1. Community 형식과 구조
형식 크기 구조 예시
Standard Community (RFC 1997) 32비트 AS Number (16b) : Value (16b) 65001:100, 65001:200
Large Community (RFC 8092) 96비트 Global Admin (32b) : LocalData1 (32b) : LocalData2 (32b) 65001:1:100, 65001:2:50
Extended Community (RFC 4360) 64비트 Type(2b) : Admin(4b) : Value(4b) RT:65001:100 (MPLS VPN에서)
💡
Large Community가 만들어진 이유
Standard Community는 AS 번호 16비트 + 값 16비트입니다. 4바이트 ASN이 보급되면서 ASN 자체가 32비트가 필요하게 됐고, Standard Community에는 담을 수 없게 됐습니다. 또한 정책 분류를 위해 두 개의 독립적인 32비트 값이 필요한 경우도 생겼습니다. 그래서 32+32+32=96비트의 Large Community(RFC 8092, 2017)가 등장했습니다.
5-2. Well-Known Community — 모든 구현이 이해해야 하는 표준 값
Community 값
이름
동작
왜 필요한가
no-export
0xFFFFFF01
NO_EXPORT
이 경로를 eBGP 피어에게 광고하지 않는다. 자신의 AS 내부에서만 사용.
고객 경로를 AS 내부에서만 사용하고 인터넷에 광고하지 않을 때. 내부 서버 경로 유출 방지.
no-advertise
0xFFFFFF02
NO_ADVERTISE
어떤 피어(iBGP 포함)에게도 광고하지 않는다. 받은 라우터에서만 사용.
특정 경로를 받아서 로컬 포워딩에만 사용하고 절대 전파하지 않을 때.
local-as
0xFFFFFF03
NO_EXPORT_SUBCONFED
현재 Confederation의 Sub-AS 내에서만 광고. Confederation 경계를 넘지 않음.
BGP Confederation 사용 시 Sub-AS 내부 경로 격리.
internet
0x00000000
INTERNET
제한 없이 모든 피어에게 광고. 기본 동작과 동일.
다른 Community로 제한된 경로를 다시 전체 광고로 되돌릴 때.
blackhole
0xFFFF029A
BLACKHOLE (RFC 7999)
이 경로로 오는 트래픽을 Null 인터페이스로 버린다. DDoS 방어용.
DDoS 공격 대상 IP를 ISP에게 알려 트래픽을 업스트림에서 차단.
5-3. Custom Community — ISP와 고객 간 약속
🗺
비유: 소포에 붙이는 특수 라벨
택배사(ISP)와 발송인(고객)이 약속합니다: "빨간 라벨 = 빠른배송, 파란 라벨 = 특정 창고 경유, 노란 라벨 = 해외 발송 금지". 발송인은 소포에 라벨만 붙이면 되고, 택배사의 모든 직원(라우터)은 라벨을 보고 약속된 처리를 합니다. BGP Community는 바로 이 "라벨 시스템"입니다. 고객이 경로에 Community를 붙이면 ISP 전체가 약속된 정책을 자동으로 적용합니다.
5-4. ISP Community 실전 예시 — KT/SKT 스타일 Community 설계
Community
ISP 정책 이름
동작 설명
사용 사례
65000:100
LOCAL_PREF 100
고객이 이 community를 붙이면 ISP가 해당 경로의 LP=100 설정 → 낮은 선호도
백업 경로로 사용하고 싶을 때
65000:200
LOCAL_PREF 200
ISP가 해당 경로의 LP=200 설정 → 높은 선호도
주경로로 강제 지정
65000:666
Blackhole
해당 목적지로 오는 모든 트래픽을 Null로 버림 (DDoS 방어)
DDoS 공격 시 피해 IP 차단
65000:1000
국내 피어만 광고
해외 Transit ISP에게는 광고 안 함. 국내 피어링 노드에만 광고
지역 트래픽 최적화
65000:2000
AS_PATH Prepend ×2
이 ISP에서 광고할 때 고객 ASN을 2회 Prepend → 덜 선호되는 경로로
이 ISP를 통한 인바운드 트래픽 줄이기
65000:9999
광고 차단
이 경로를 이 ISP의 어떤 피어에게도 광고하지 않음
특정 경로의 선택적 광고 제어
5-5. Community 설정 실전 코드
Community 설정 — 송신(고객) + 수신(ISP) 처리
! ════════════════════════════════════════════════
! [고객 라우터] — 경로에 Community 태깅
! ════════════════════════════════════════════════

! Community 전송 활성화 (필수! 기본은 전송 안 함)
router bgp 65001
  neighbor 203.0.113.1 send-community
  ! 또는: send-community both (standard + extended 모두)

! Route-Map으로 Community 붙이기
route-map SET_COMMUNITY permit 10
  match ip address prefix-list MY_PREFIXES
  set community 65000:200          ! ISP에게 LP=200 요청

route-map SET_COMMUNITY permit 20
  match ip address prefix-list BACKUP_PREFIX
  set community 65000:100 additive  ! additive: 기존 Community 유지하며 추가

! No-Export: 이 경로를 ISP가 다른 AS에 광고하지 않도록
route-map NO_EXPORT_TO_ISP permit 10
  set community no-export

! Blackhole: DDoS 공격 대상 IP를 ISP에서 차단
route-map BLACKHOLE permit 10
  match ip address prefix-list ATTACKED_IPS
  set community 65000:666 no-advertise  ! no-advertise는 ISP 내부용으로만

! ════════════════════════════════════════════════
! [ISP 라우터] — Community 수신 후 정책 적용
! ════════════════════════════════════════════════

! Community 매칭을 위한 ip community-list
ip community-list 1 permit 65000:200     ! LP 200 요청
ip community-list 2 permit 65000:100     ! LP 100 요청
ip community-list 3 permit 65000:666     ! Blackhole 요청
ip community-list 4 permit 65000:2000    ! Prepend 요청

! Community에 따른 정책 적용
route-map CUSTOMER_IN permit 10
  match community 1
  set local-preference 200

route-map CUSTOMER_IN permit 20
  match community 2
  set local-preference 100

route-map CUSTOMER_IN permit 30
  match community 3
  set local-preference 50
  set ip next-hop 192.0.2.1             ! Null 경로 next-hop

! Outbound: Prepend 요청 처리
route-map CUSTOMER_OUT permit 10
  match community 4
  set as-path prepend 65001 65001         ! 고객 ASN 2회 Prepend

route-map CUSTOMER_OUT permit 100          ! 나머지 기본 광고

! Community 삭제 (외부 광고 시 내부 Community 제거)
route-map STRIP_COMMUNITIES permit 10
  set community none
5-6. Large Community 실전 — 4바이트 ASN 환경
Large Community — 구조와 활용 예시
! Large Community 형식: ASN:Function:Parameter
! 예: 65001:1:100
!     ^^^^^  ^  ^^^
!     우리AS  분류  값
! 
! Function 설계 예시:
!   1 = LOCAL_PREF 제어
!   2 = AS_PATH Prepend 횟수
!   3 = 광고 지역 제한
!   4 = 광고 AS 제한
! ────────────────────────────────────────────

! 예: 65001:1:200  → LP=200 설정 요청
!    65001:2:3     → 3회 Prepend 요청
!    65001:3:410   → 한국(국가코드 410)에만 광고

! Large Community 설정 (Cisco IOS XE)
route-map TAG_WITH_LARGE_COMMUNITY permit 10
  set large-community 65001:1:200           ! LP 200 요청
  set large-community 65001:3:410 additive  ! 한국에만 광고 + 기존 유지

! Large Community 매칭
ip large-community-list standard LC_LP200 permit 65001:1:200

route-map APPLY_LC_POLICY permit 10
  match large-community LC_LP200
  set local-preference 200

! 검증
show bgp ipv4 unicast [prefix]
! 출력에서:
! Community: 65000:200
! Large Community: 65001:1:200 65001:3:410
5-7. Community 기반 트래픽 엔지니어링 — 전체 시나리오
Community 기반 정책 — 고객이 ISP에게 경로 처리 방식을 지시
Customer AS 65001 198.51.100.0/24 보유 경로에 Community 태그 부착 set community 65000:200 (Primary) set community 65000:100 (Backup) ISP AS 65000 Community 수신 → LP 자동 설정 65000:200 → LP=200 (Primary) 65000:100 → LP=100 (Backup) ISP Peer AS 64500 인터넷으로 경로 전달 Community는 전파 안 됨 (정책) ISP가 Community strip 후 광고 ISP-PE-1 eBGP 수신 ISP-PE-2 eBGP 수신 ISP-PE-1에서 Community 처리 65000:200 수신 → LP=200 설정 AS 내부 iBGP로 전파 결과: 고객이 자신의 경로 정책을Community 태그 하나로 ISP에 위임
🔗 Phase 6 — iBGP · Route Reflector · Confederation 10H
6-1. iBGP Full-Mesh 문제 — 왜 Route Reflector가 필요한가
💡
iBGP Split Horizon이 풀메시를 강제하는 이유
iBGP에서 "iBGP로 받은 경로를 다른 iBGP 피어에게 재광고하지 않는다"는 규칙(Split Horizon)이 있습니다. 이유는 루프 방지입니다. 그런데 이 규칙 때문에 AS 내 모든 라우터가 서로 직접 피어링해야 합니다(Full-Mesh). N개 라우터면 N×(N-1)/2개의 세션이 필요합니다. 100개 라우터라면 4,950개 세션! 이건 관리 불가능합니다.
라우터 수 필요 세션 수 (풀메시) 현실성
5개 10개 가능
20개 190개 힘듦
100개 4,950개 불가능
1,000개 499,500개 완전 불가
6-2. Route Reflector — 풀메시 없이 경로 전파
💡
Route Reflector의 원리
RR은 iBGP Split Horizon의 예외입니다. RR은 클라이언트에서 받은 경로를 다른 클라이언트와 비클라이언트에게 "반사(Reflect)"합니다. 대신 루프 방지를 위해 ORIGINATOR_ID와 CLUSTER_LIST 속성을 추가합니다. 자신의 ORIGINATOR_ID가 포함된 경로를 받으면 무시하여 루프를 방지합니다.
경로 수신 출처 RR의 광고 행동
eBGP 피어 모든 iBGP 피어(클라이언트 + 비클라이언트)에게 광고
RR 클라이언트 (iBGP) 모든 iBGP 피어(클라이언트 + 비클라이언트 + eBGP)에게 광고
비클라이언트 (iBGP) 클라이언트에게만 광고 (비클라이언트 간 풀메시는 여전히 필요)
Route Reflector 설정
! ─── Route Reflector 설정 ────────────────────────
router bgp 65001
  bgp cluster-id 1.1.1.1               ! 클러스터 ID (루프 방지용)

  ! 클라이언트 피어 설정
  neighbor 10.0.0.2 remote-as 65001
  neighbor 10.0.0.2 update-source Loopback0
  neighbor 10.0.0.2 route-reflector-client  ! 이 피어를 RR 클라이언트로

  neighbor 10.0.0.3 remote-as 65001
  neighbor 10.0.0.3 update-source Loopback0
  neighbor 10.0.0.3 route-reflector-client

  ! 비클라이언트 (다른 RR — 풀메시 여전히 필요)
  neighbor 10.0.0.10 remote-as 65001
  neighbor 10.0.0.10 update-source Loopback0
  ! route-reflector-client 없음 = 비클라이언트

  address-family ipv4 unicast
    neighbor 10.0.0.2 activate
    neighbor 10.0.0.3 activate
    neighbor 10.0.0.10 activate
    neighbor 10.0.0.2 route-reflector-client
    neighbor 10.0.0.3 route-reflector-client
    neighbor 10.0.0.2 send-community both    ! Community 전달 필수

! 검증
show bgp ipv4 unicast [prefix]
! ORIGINATOR_ID: 10.0.0.3 (경로 원래 생성자)
! CLUSTER_LIST: 1.1.1.1   (RR 클러스터 경유 표시)
⚖️ Phase 7 — Policy: Route-Map · Filter · Prefix-List 10H
💡
BGP Policy가 필요한 이유
인터넷에서 "모든 경로를 받아서 모든 경로를 광고한다"는 것은 위험하고 비효율적입니다. 정책은 세 가지를 제어합니다: ① 어떤 경로를 받을지 (Inbound Filter), ② 어떤 경로를 광고할지 (Outbound Filter), ③ 받거나 광고할 때 속성을 어떻게 바꿀지 (Attribute Modification).
7-1. 필터링 도구 비교 — 언제 무엇을 쓸까
도구 매칭 기준 속성 수정 권장 용도
prefix-list IP 프리픽스 (정확한 매칭, le/ge) 불가 (허용/거부만) 특정 IP 대역 필터링. 가장 단순하고 명확.
route-map 프리픽스, AS_PATH, Community, 메트릭 등 복합 가능 (set 절) 속성 수정이 필요한 복합 정책. 가장 강력.
as-path access-list AS_PATH 정규식 불가 (허용/거부만) 특정 AS 경유 경로 필터링.
ip community-list Community 값 불가 (허용/거부만) Community 기반 필터링. route-map과 조합.
distribute-list IP ACL 기반 프리픽스 불가 레거시. prefix-list 권장.
7-2. 완전한 BGP Policy 설정 예시 — 이중 ISP 정책
완전한 BGP Inbound/Outbound Policy — 이중 ISP 환경
! ════════════════════════════════════════════════
! 1. Prefix-List 정의
! ════════════════════════════════════════════════
! 우리가 광고할 프리픽스 (자신의 IP 블록만)
ip prefix-list OWN_PREFIXES seq 5 permit 198.51.100.0/24
ip prefix-list OWN_PREFIXES seq 10 permit 203.0.113.0/24

! Default Route만 수신 허용 (Full table 받지 않을 때)
ip prefix-list DEFAULT_ONLY seq 5 permit 0.0.0.0/0

! RFC 5735 Bogon 필터 (사설/예약 대역 차단)
ip prefix-list BOGON_FILTER seq 5  deny 0.0.0.0/8 le 32
ip prefix-list BOGON_FILTER seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGON_FILTER seq 15 deny 172.16.0.0/12 le 32
ip prefix-list BOGON_FILTER seq 20 deny 192.168.0.0/16 le 32
ip prefix-list BOGON_FILTER seq 25 deny 100.64.0.0/10 le 32   ! Carrier-Grade NAT
ip prefix-list BOGON_FILTER seq 30 deny 169.254.0.0/16 le 32
ip prefix-list BOGON_FILTER seq 35 deny 192.0.2.0/24 le 32    ! TEST-NET
ip prefix-list BOGON_FILTER seq 1000 permit 0.0.0.0/0 le 32     ! 나머지 허용

! ════════════════════════════════════════════════
! 2. AS-Path Access-List
! ════════════════════════════════════════════════
! 특정 AS를 경유하는 경로 차단 (예: 비우호 국가 AS)
ip as-path access-list 10 deny _64999_            ! AS 64999 경유 거부
ip as-path access-list 10 permit .*              ! 나머지 허용

! 자신의 AS에서 온 경로 차단 (루프 방지 보조)
ip as-path access-list 20 deny ^65001            ! 자신의 ASN 포함 거부
ip as-path access-list 20 permit .*

! ════════════════════════════════════════════════
! 3. Route-Map 정의
! ════════════════════════════════════════════════
! [ISP A 인바운드 정책] — Primary, LP=200
route-map ISP_A_IN permit 5
  match ip address prefix-list BOGON_FILTER  ! Bogon은 이미 필터됨
  match as-path 10                           ! 금지 AS 제거
  set local-preference 200                  ! ISP A = Primary
  set community 65001:100                    ! 내부 태깅 (ISP A 경유 표시)

! [ISP B 인바운드 정책] — Backup, LP=100
route-map ISP_B_IN permit 5
  match ip address prefix-list BOGON_FILTER
  set local-preference 100                  ! ISP B = Backup
  set community 65001:200

! [ISP A 아웃바운드 정책] — 자신의 프리픽스만 광고
route-map ISP_A_OUT permit 10
  match ip address prefix-list OWN_PREFIXES
  set community 65000:200                   ! ISP A에게 LP 200 요청

route-map ISP_A_OUT deny 20                 ! 나머지 모두 차단 (기본 거부)

! [ISP B 아웃바운드] — AS_PATH Prepend로 인바운드 줄이기
route-map ISP_B_OUT permit 10
  match ip address prefix-list OWN_PREFIXES
  set as-path prepend 65001 65001           ! 2회 Prepend → B는 덜 선호됨
  set community 65000:100                   ! ISP B에게 LP 100 요청

route-map ISP_B_OUT deny 20

! ════════════════════════════════════════════════
! 4. BGP 피어에 정책 적용
! ════════════════════════════════════════════════
router bgp 65001
  address-family ipv4 unicast
    ! ISP A
    neighbor 203.0.113.1 route-map ISP_A_IN in
    neighbor 203.0.113.1 route-map ISP_A_OUT out
    neighbor 203.0.113.1 send-community

    ! ISP B
    neighbor 198.51.100.1 route-map ISP_B_IN in
    neighbor 198.51.100.1 route-map ISP_B_OUT out
    neighbor 198.51.100.1 send-community

    ! 최대 프리픽스 제한 (보안)
    neighbor 203.0.113.1 maximum-prefix 800000 80 ! 80% 경고, 80만개 초과 시 세션 종료
🔐 Phase 8 — BGP Security: RPKI · MANRS · Hijacking 8H
🚨
BGP는 설계상 Trust 기반 — 보안이 취약한 이유
BGP가 설계된 1989년에는 인터넷이 신뢰하는 학술/군사 기관들의 네트워크였습니다. 그래서 BGP는 기본적으로 상대방이 광고하는 경로를 믿습니다. 누구나 아무 프리픽스를 광고할 수 있습니다. 이것이 BGP Hijacking의 근본 원인입니다.
8-1. BGP Hijacking — 실제 사례와 원리
사건 연도 내용
Pakistan Telecom → YouTube 2008 파키스탄 정부 명령으로 YouTube 차단 시도. Pakistan Telecom이 208.65.153.0/24 경로를 광고 → 전 세계 YouTube 트래픽이 파키스탄으로 2시간 라우팅됨
China Telecom 대규모 유출 2010 China Telecom이 15분간 50,000개 이상 프리픽스를 잘못 광고. 미국 정부, 군, AWS 트래픽 일부가 중국을 경유
Rostelecom BGP Hijack 2020 러시아 ISP가 Google, Amazon, Cloudflare 등 8,800개 경로 하이재킹. 수십 분간 지속
Indosat 설정 오류 2014 인도네시아 ISP의 라우터 오설정으로 전 세계 경로 320,000개 유출. 인터넷 속도 저하
8-2. RPKI — Route Origin Validation
💡
RPKI가 만들어진 이유
BGP Hijacking을 막으려면 "이 AS가 이 프리픽스를 광고할 권한이 있는가?"를 검증해야 합니다. RPKI(Resource Public Key Infrastructure)는 암호학적 서명으로 이를 증명합니다. IP 주소 블록 소유자가 "AS X가 이 프리픽스를 광고할 수 있다"는 ROA(Route Origin Authorization)를 발급하면, 이를 RPKI 데이터베이스에 등록합니다. 라우터는 수신한 경로의 Origin AS와 프리픽스를 ROA와 대조합니다.
검증 상태 의미 권장 처리
Valid ✅ ROA가 존재하고 Origin AS와 프리픽스가 일치 수신하고 높은 LP 부여 (정상 처리)
Invalid ❌ ROA가 존재하지만 Origin AS 또는 프리픽스 길이가 불일치 → Hijacking 가능성 즉시 거부 (또는 낮은 LP)
Not Found (Unknown) 이 프리픽스에 대한 ROA가 없음 수신 (현재 인터넷의 대부분)
RPKI Route Origin Validation 설정 (IOS XE)
! ─── RPKI 서버 연결 설정 ─────────────────────────
router bgp 65001
  bgp rpki server tcp 192.0.2.1         ! RPKI 검증 서버 (RTR 프로토콜)
  bgp rpki server tcp 192.0.2.1 port 3323
  bgp rpki server tcp 192.0.2.1 refresh 600  ! 10분마다 갱신

! ─── RPKI 상태에 따른 정책 ───────────────────────
route-map RPKI_POLICY permit 10
  match rpki valid                      ! Valid 경로 우선
  set local-preference 200

route-map RPKI_POLICY permit 20
  match rpki not-found                  ! Unknown — 일반 처리
  set local-preference 100

route-map RPKI_POLICY deny 30
  match rpki invalid                    ! Invalid — 거부!

! 인바운드에 적용
  neighbor 203.0.113.1 route-map RPKI_POLICY in

! ─── 검증 ───────────────────────────────────────
show bgp rpki table                    ! ROA 데이터베이스 확인
show bgp rpki server summary          ! RPKI 서버 연결 상태
show bgp ipv4 unicast [prefix]        ! 경로에 rpki state: valid/invalid 표시
8-3. MANRS — 인터넷 라우팅 보안 원칙
MANRS 항목 내용 구현 방법
Filtering 자신이 광고하는 프리픽스를 엄격히 제한. 자신 소유가 아닌 경로 광고 금지 아웃바운드 prefix-list, IRR 기반 필터링
Anti-Spoofing 출발지 IP 위조 패킷 필터링 (BCP38) uRPF (Unicast Reverse Path Forwarding)
Coordination 다른 네트워크 운영자와 연락처 유지. 문제 발생 시 빠른 대응 WHOIS, NOC 연락처 최신화
Global Validation RPKI ROA 등록 및 검증 구현 ROA 생성, BGP Origin Validation
🚀 Phase 9 — 고급 기능 & 실전 설계 5H
9-1. BGP Multipath — ECMP 부하 분산
💡
왜 BGP는 기본적으로 Multipath를 하지 않는가?
BGP는 정책 기반 프로토콜입니다. 동일한 프리픽스에 대해 여러 경로가 있어도, Best Path 알고리즘으로 하나만 선택합니다. 이는 "예측 가능한 라우팅"을 위한 설계입니다. 그러나 데이터센터 환경에서는 트래픽 분산이 필요합니다. maximum-paths로 동일 AS_PATH 길이의 경로들을 동시에 사용할 수 있습니다.
BGP Multipath 설정
! eBGP Multipath (같은 AS에서 여러 경로)
router bgp 65001
  address-family ipv4 unicast
    maximum-paths 8                ! eBGP 최대 8개 경로 동시 사용
    maximum-paths ibgp 8           ! iBGP 경로도 포함

! BGP Multipath 조건:
! - AS_PATH 길이 동일
! - ORIGIN 값 동일
! - MED 동일 (bgp bestpath as-path multipath-relax 옵션)
! 
! 서로 다른 AS에서 온 경로도 Multipath 허용:
  bgp bestpath as-path multipath-relax  ! AS_PATH 내용 달라도 길이 같으면 ECMP
9-2. BGP Graceful Restart
💡
왜 Graceful Restart가 필요한가?
BGP 세션이 재시작되면 경로 철회(Withdraw) → 네트워크 전체에 경로 재계산 → 일시적 트래픽 손실이 발생합니다. Graceful Restart는 "재시작 중이니 기존 경로를 잠시 유지해줘"라고 피어에게 알립니다. 피어는 "stale" 표시로 경로를 유지하면서 재시작이 완료될 때까지 기다립니다. 컨트롤 플레인 재시작 시 데이터 플레인 중단을 최소화합니다.
Graceful Restart + BFD for BGP
! Graceful Restart 설정
router bgp 65001
  bgp graceful-restart                  ! GR 활성화
  bgp graceful-restart restart-time 120  ! 재시작 최대 시간 (초)
  bgp graceful-restart stalepath-time 360 ! Stale 경로 유지 시간

! BFD for BGP — ms 단위 장애 감지
router bgp 65001
  neighbor 203.0.113.1 fall-over bfd   ! BFD로 피어 장애 감지
! BFD 없으면 Hold Timer(기본 180초) 만료까지 기다림
! BFD 있으면 수백 ms 내 감지 → 빠른 수렴
9-3. BGP PIC (Prefix Independent Convergence)
🔬
BGP PIC — 프리픽스 수에 독립적인 빠른 수렴
전통적으로 BGP 피어 장애 시 수십만 개 프리픽스를 하나씩 재계산합니다. BGP PIC는 FIB에 백업 Next-Hop을 미리 프로그래밍해두어, 장애 감지 즉시 모든 경로를 한 번에 전환합니다. 프리픽스 수와 무관하게 수렴 시간이 일정합니다. 데이터센터와 ISP 환경에서 핵심 기능입니다.
9-4. 실전 설계 — 엔터프라이즈 이중 ISP 풀 구성
엔터프라이즈 BGP 이중 ISP 풀 설계 — Community + Policy + RPKI
Our AS 65001 Border Router 1 ISP A 연결 | LP=200 route-map ISP_A_IN/OUT Border Router 2 ISP B 연결 | LP=100 route-map ISP_B_IN/OUT Route Reflector iBGP RR — 내부 경로 전파 cluster-id + route-reflector-client ISP A (AS 64500) Primary / 10G 전용선 Community 지원 RPKI Validation 활성 ISP B (AS 64510) Backup / 1G Internet Community 지원 AS_PATH Prepend ×2 Internet 아웃바운드 정책 (BR-1) 자신의 프리픽스만 광고 Community: 65000:200 RPKI Invalid 경로 거부 Bogon 필터 적용 아웃바운드 정책 (BR-2) 자신의 프리픽스만 광고 AS_PATH Prepend ×2 Community: 65000:100 인바운드 트래픽 줄임 결과: ISP A 주경로 / ISP B 백업 / RPKI 보안 / Community 정책ISP A 장애 시 LP=100인 ISP B 경로로 자동 전환
 
🔧 트러블슈팅 완전 가이드
BGP 세션 트러블슈팅
증상 원인 확인 명령어 해결
BGP Active 상태 지속 TCP 179 차단 또는 라우팅 없음 telnet [peer] 179 ACL, 방화벽, 라우팅 확인
BGP Active 상태 지속 update-source 미설정 (Loopback 피어링) show bgp summary neighbor x update-source Lo0
NOTIFICATION: AS mismatch remote-as 오설정 debug ip bgp events 상대방 AS 번호 재확인
세션은 Established, 경로 없음 network 문 미설정 또는 라우팅 테이블 없음 show bgp ipv4 unicast network 명령어 + 정확한 라우팅 테이블 확인
경로 받았지만 RIB에 없음 NEXT_HOP 도달 불가 show bgp ipv4 unicast [pfx] next-hop-self 또는 IGP에서 NEXT_HOP 광고
경로 있어도 포워딩 안 됨 BGP AD(20/200)가 IGP에 졌음 show ip route [prefix] AD 값 확인, IGP 경로와 충돌 여부
Community 전달 안 됨 send-community 미설정 show bgp [pfx]에서 community 없음 neighbor x send-community both
iBGP 경로 전파 안 됨 Split Horizon (RR 없음) show bgp summary Route Reflector 구성
핵심 진단 명령어 Quick Reference
BGP 필수 진단 명령어 전체
═══ 세션 상태 ════════════════════════════════════
show bgp summary                   ! 전체 피어 상태 한눈에
show bgp neighbors [ip]            ! 특정 피어 상세 (Hold time, stats)
show bgp neighbors [ip] advertised-routes  ! 우리가 광고 중인 경로
show bgp neighbors [ip] received-routes    ! 받은 경로 (soft-reconfig 필요)
show bgp neighbors [ip] routes     ! 받아서 Best Path인 경로

═══ 경로 분석 ════════════════════════════════════
show bgp ipv4 unicast              ! 전체 BGP 테이블
show bgp ipv4 unicast [prefix]     ! 특정 프리픽스 상세 (모든 속성)
show bgp ipv4 unicast summary      ! 요약 통계
show ip route bgp                  ! RIB에 설치된 BGP 경로
show bgp ipv4 unicast regexp [regex] ! AS_PATH 정규식 검색
show bgp ipv4 unicast community [val] ! 특정 Community 경로

═══ 정책 확인 ════════════════════════════════════
show route-map [name]              ! Route-Map 설정 + 적중 카운터
show ip prefix-list [name]         ! Prefix-List 설정 + 적중 카운터
show ip bgp community-list [name]  ! Community-List
show ip as-path-access-list [num]  ! AS-Path ACL

═══ Community ════════════════════════════════════
show bgp ipv4 unicast [pfx]        ! Community 값 포함 확인
show bgp community [val] [val...]  ! 특정 Community 가진 경로
show bgp community-list [name]     ! Community-List 매칭

═══ RPKI ══════════════════════════════════════════
show bgp rpki table                ! ROA 데이터베이스
show bgp rpki server summary       ! RPKI 서버 연결 상태

═══ 디버그 (주의) ════════════════════════════════
debug ip bgp [ip] events           ! BGP 이벤트 (세션 수립 과정)
debug ip bgp [ip] updates          ! UPDATE 메시지 상세
! 프로덕션에서는 반드시 특정 피어 IP 지정

═══ 정책 검증 (Policy를 트래픽 없이 테스트) ═══
clear ip bgp [ip] soft in          ! Inbound 정책 재적용 (soft reset)
clear ip bgp [ip] soft out         ! Outbound 정책 재적용
트러블슈팅 순서 (Top-Down)
1
BGP 세션 상태 확인
show bgp summary — 모든 피어 Established 여부. Active/Idle이면 TCP 연결 문제부터 확인.
2
경로 수신 여부 확인
show bgp neighbors [ip] received-routes — 피어에서 경로를 보내고 있는지. 없으면 상대방 설정 문제.
3
Inbound 정책 확인
show bgp ipv4 unicast [prefix] — 경로가 BGP 테이블에 있는지. 없으면 route-map/prefix-list가 거부 중.
4
Best Path 확인
show bgp ipv4 unicast [prefix]에서 > 표시(Best Path) 확인. 왜 다른 경로가 선택됐는지 속성 비교.
5
RIB 설치 확인
show ip route [prefix] — BGP 경로가 라우팅 테이블에 있는지. NEXT_HOP 도달 불가 또는 IGP 경로에 졌을 수 있음.
6
Outbound 정책 확인
show bgp neighbors [ip] advertised-routes — 우리가 피어에게 광고 중인 경로. route-map out 필터 확인.
🏅 자격증 로드맵 & 학습 자료
자격증 시험 코드 BGP 범위 준비 기간
CCNP ENCOR 350-401 eBGP/iBGP 기초, 속성, Best Path, 기본 정책 6~9개월
CCNP ENARSI 300-410 BGP Policy 심화, Route Reflector, Community +3개월
CCIE Enterprise Lab 400-101 BGP 전체 설계·구현·트러블슈팅 1.5~2년+
CCIE SP Lab 400-201 BGP SP 아키텍처, Large Community, RPKI, EVPN 별도 커리큘럼
유형 자료 비고
RFC RFC 4271 (BGP-4), RFC 1997 (Community), RFC 8092 (Large Community) 원문 표준
도서 Internet Routing Architectures (Halabi) BGP 설계의 바이블
도서 BGP Design and Implementation (Zhang) 실무 BGP 설계
Cisco Live BRKRST-3310 — BGP Best Practices ciscolive.com
실습 BGP Looking Glass (route-views.oregon-ix.net) 실제 인터넷 BGP 테이블 조회
보안 RPKI.net, MANRS (manrs.org) BGP 보안 실무
BGP Deep Dive — 원리 중심 Zero to Hero
AS · Path-Vector · Attributes · Community · Best Path · RPKI · Policy
eBGP iBGP Attributes Community Policy RPKI
저작자표시 비영리 변경금지 (새창열림)

'CCIE EI > WAN' 카테고리의 다른 글

MPLS/MPLS VPN zero to Hero  (1) 2026.03.20
OSPF & BGP , zero to Hero  (1) 2026.03.20

관련글

티스토리툴바