BGP Route Advertisement 완벽 이해하기 — FortiGate, Azure Virtual WAN, AWS Transit Gateway 실전 분석 이미지
글 요약
BGP Route Advertisement는 하이브리드 네트워크에서 경로 정보를 자동으로 교환하는 핵심 메커니즘이거든요. 이 글에서는 FortiGate, Azure Virtual WAN, AWS Transit Gateway 세 가지 환경에서 BGP 광고가 어떻게 동작하는지, 그리고 실무에서 자주 겪는 시행착오까지 모두 정리해 봤습니다.
“온프레미스와 클라우드 BGP를 연결했는데, 자꾸 광고한 라우트가 사라져요.”
BGP Route Advertisement 설정 실수 한 번이 전체 하이브리드 망을 마비시킬 수 있거든요. FortiGate CLI 명령어, Azure VWAN Hub 광고 정책, AWS TGW의 BGP 피어링 구조까지 차근차근 분해해서 보여드립니다. 이 글 하나면 어떤 클라우드 BGP 환경에서도 자신 있게 광고 경로를 설계할 수 있어요.
많은 엔지니어가 BGP를 “그냥 라우팅 프로토콜” 정도로만 이해하고 있더라고요. 실제로는 광고(Advertise) 단계에서 실수하면 광고한 prefix가 neighbor 쪽에 전혀 전달되지 않거나, 반대로 너무 많은 경로가 전파되어 메모리 문제가 터지기도 합니다. BGP는 명시적으로 광고하지 않으면 어떤 경로도 알려주지 않는 pull 방식 프로토콜이기 때문에, 이 원칙을 모르고 들어가면 첫 단계부터 막히거든요.
📑 목차
📌 이 글의 핵심 정리
- BGP Advertisement은 광고하지 않은 prefix는 절대 전파되지 않는 명시적 pull 모델이라는 점이 가장 중요합니다.
- FortiGate는 network 명령 + route-map 조합으로 광고 경로를 정밀하게 제어할 수 있습니다.
- Azure Virtual WAN Hub는 NVA를 통한 BGP 광고와 직접 라우팅을 구분해야 혼선이 없습니다.
- AWS Transit Gateway는 RAM 기반 BGP 피어 공유라는 클라우드 네이티브 방식을 채택하고 있습니다.
- 실무에서는 Hold Timer 미스매치, AS-PATH 루프, prefix 중복 광고가 3대 장애 원인이거든요.
- 세 솔루션은 비용 모델, 자동화 수준, 멀티클라우드 연동에서 명확한 차별점을 가지고 있습니다.
BGP Route Advertisement 기본 개념 정리
BGP 광고의 본질은 명시적 경로 공유
BGP는 다른 동적 라우팅 프로토콜과 달리, 내가 적극적으로 광고하지 않은 prefix는 neighbor에게 절대 전달되지 않습니다. OSPF나 EIGRP처럼 자동으로 인터페이스 네트워크를 학습해서 광고하는 방식이 아니거든요. 그래서 첫 단계에서 `network` 문을 빼먹으면 아무리 neighbor가 잘 살아 있어도 라우트 테이블은 텅 비게 됩니다.
광고 가능 여부를 결정하는 3요소
- network 문 일치: 라우팅 테이블에 해당 prefix가 active 상태로 존재해야 함
- route-map 또는 prefix-list 필터 통과: 정책에 부합해야 neighbor에게 advertise 가능
- next-hop reachability: next-hop 주소가 실제로 도달 가능한 상태여야 함
eBGP와 iBGP 광고 차이점
eBGP(외부 BGP)는 AS 경계를 넘어 advertise할 때 next-hop이 자동으로 변경되는 반면, iBGP(내부 BGP)는 next-hop이 변하지 않고 전파되거든요. 이 차이를 모르면 클라우드 NVA(Network Virtual Appliance)와 FortiGate를 iBGP로 연결했을 때 next-hop unreachable 문제가 발생합니다.
⚠️ BGP 광고 기본 주의
- default route 광고는 신중하게: `0.0.0.0/0`을 advertise하면 모든 트래픽이 해당 경로로 빨려들어갑니다.
- eBGP 멀티홉 설정 시 TTL 값과 인증(password) 누락이 보안 사고로 이어집니다.
FortiGate BGP Advertisement 실전 설정
FortiGate의 network 명령 동작 원리
FortiGate는 Cisco IOS처럼 `network` 명령을 사용할 때 라우팅 테이블에 해당 prefix가 정확히 일치해야 advertise를 시도합니다. 다만 FortiGate 고유하게, VLAN 인터페이스의 secondary IP도 광고 대상이 될 수 있다는 점이 Cisco와 다르거든요. 실전에서 이런 디테일이 의외로 광고 누락 원인이 됩니다.
FortiGate BGP 핵심 설정 명령어
- config router bgp → AS 번호, router-id 지정
- config neighbor → remote-as, update-source 인터페이스 명시
- config network → advertise할 prefix 1~n개 등록
- config route-map → inbound/outbound 정책으로 광고 제어
route-map으로 광고 prefix 정밀 필터링
단순히 `network` 문에 prefix를 나열하는 것보다, route-map + prefix-list 조합으로 광고 prefix를 제한하는 것이 운영상 훨씬 안전합니다. 이유는 라우팅 테이블에 새 경로가 자동으로 추가되어도 의도치 않게 advertise되지 않게 차단할 수 있기 때문이거든요. 실제 금융권 FortiGate 운영에서는 거의 이 패턴을 표준으로 사용합니다.
💡 FortiGate BGP 꿀팁
- `get router info bgp neighbors` 명령어로 advertise된 prefix를 즉시 확인 가능하거든요.
- `# diagnose ip route list`로 라우팅 테이블 active 상태를 먼저 확인 후 network 문 매칭 여부 검증이 순서입니다.
Azure Virtual WAN Hub BGP 광고 분석
Azure VWAN Hub의 BGP는 2-tier 구조
Azure Virtual WAN Hub는 내부적으로 MS 내부 ASN(65515)과 사용자 NVA ASN이 분리된 2-tier 구조로 동작합니다. 사용자가 직접 BGP neighbor를 맺는 건 Hub 내 NVA 또는 VPN/ExpressRoute 게이트웨이인데, advertise된 경로는 Hub 내부의 Any-to-Any 연결을 통해 다른 spoke VNet으로 자동 전파되거든요.
Azure VWAN BGP 광고 경로 3가지
- NVA → Hub 광고: FortiGate, Cisco CSR 등 사용자 NVA가 Hub로 prefix advertise
- Hub → Spoke 전파: Hub가 spoke VNet으로 라우트 자동 전파
- VPN/ER 게이트웨이 광고: 온프레미스 prefix가 Hub를 거쳐 spoke로 전달
NVA BGP advertise 시 주의할 함정
Azure NVA에서 BGP로 advertise한 prefix가 spoke에 전혀 안 보이는 경우가 종종 있더라고요. 대부분 원인은 NVA가 광고한 next-hop 주소가 Hub의 effective route 테이블에 등록되지 않은 경우입니다. Azure Portal의 Virtual WAN Hub → Routing에서 Default Route Table에 next-hop 전파 여부를 반드시 확인해야 합니다.
⚠️ Azure VWAN 주의
- Azure VWAN의 BGP ASN 변경 제한: Hub 생성 후 ASN은 변경 불가하므로 사전 설계 필수.
- NVA advertise prefix는 Hub 라우팅 의도(Intent) 설정을 함께 고려해야 의도대로 전파됩니다.
AWS Transit Gateway BGP 동작 방식
TGW는 BGP + RAM의 하이브리드 광고 방식
AWS Transit Gateway는 전통적인 BGP neighbor 방식과 다르게, RAM(Resource Access Manager)을 통해 Transit Gateway 자체를 다른 계정과 공유하고 각 attachment가 자동으로 라우트를 학습하는 구조입니다. VPN attachment에서 BGP가 활성화되면 customer gateway와 advertise가 일어나고, 해당 prefix는 TGW route table을 통해 모든 attachment로 전파되거든요.
AWS TGW BGP 광고의 핵심 특징
- Default Route Table Association / Propagation 자동 활성화 여부로 광고 범위 결정
- ASN은 64512 고정 (기본값), custom ASN 선택 가능하나 변경 후 회귀 어려움
- VPN attachment 전용 BGP advertise: VPC attachment는 BGP 없이 static CIDR만 등록
route table propagation 설정의 미묘한 차이
TGW에서 BGP advertise prefix가 보이지 않을 때 route table의 propagation 탭을 먼저 확인해야 합니다. attachment가 등록되어 있어도 propagation이 비활성화되어 있으면 BGP로 학습한 라우트가 route table에 들어오지 않거든요. AWS Console에서는 우측 상단 “Actions → Enable propagation”으로 즉시 활성화 가능합니다.
💡 AWS TGW BGP 꿀팁
- Blackhole route를 TGW route table에 등록하면 특정 advertise prefix를 명시적으로 무효화할 수 있습니다.
- VPN BGP advertise 디버깅은 CloudWatch의 Transit Gateway Metrics에서 BGP 상태 확인이 가능하거든요.
실무 시행착오 사례와 해결 노하우
대표 실패 사례 — AS-PATH 루프 무한 광고
실제로 금융권 멀티클라우드 프로젝트에서 가장 많이 겪는 사고가 동일 ASN을 여러 사이트에서 중복 사용한 경우의 AS-PATH 루프입니다. 예를 들어 FortiGate(AS 65001)와 Azure VWAN NVA(AS 65001)를 iBGP로 연결하면, FortiGate가 광고한 prefix가 NVA를 거쳐 다시 FortiGate로 들어오면서 loop 발생 → BGP flapping → 결국 neighbor down 되는 현상이 나타납니다.
증상: BGP neighbor가 Established 됐다가 30초 만에 Idle 상태로 반복 전환
원인 분석:
- FortiGate와 Azure NVA가 동일 ASN 사용
- Advertise한 prefix가 양방향으로 왕복
- BGP loop prevention이 발동해 자동 withdraw
전문가 해결 노하우 — 4단계 체크리스트
이 문제를 해결하기 위해 10년차 엔지니어들이 실무에서 쓰는 검증된 4단계 체크리스트가 있습니다. 단순히 ASN 변경만 하는 게 아니라 광고 방향과 정책까지 함께 통제해야 재발이 없거든요.
- 1단계 ASN 분리: 사이트별로 고유 ASN 부여 (예: FortiGate=65010, Azure NVA=65020)
- 2단계 route-map outbound: advertise 방향을 단방향으로 강제
- 3단계 prefix-list 필터: 의도하지 않은 prefix가 advertise되지 않도록 명시적 차단
- 4단계 BGP monitoring: Grafana + Telegraf로 neighbor 상태 시각화
핵심 인사이트
단순히 neighbor를 다시 맺는 임시방편보다, route-map을 적용한 단방향 광고 설계가 근본적인 해결책입니다. 이유는 BGP는 기본적으로 양방향 통신이기 때문에 한쪽 방향만 끊어도 neighbor는 유지되면서 advertise만 차단되거든요.
FortiGate·Azure·AWS 3가지 솔루션 비교 분석
솔루션별 BGP 광고 핵심 차이점 비교표
아래 표는 동일한 하이브리드 망 시나리오에서 세 솔루션의 BGP Advertisement 동작을 항목별로 비교한 결과입니다. 단순 기능 나열이 아니라 실제 운영에서 마주치는 결정 포인트 위주로 정리했거든요.
| 비교 항목 | FortiGate (온프레미스) | Azure Virtual WAN Hub | AWS Transit Gateway |
|---|---|---|---|
| BGP 광고 방식 | network + route-map 명시적 | NVA advertise + Hub 자동 전파 | VPN BGP + route table propagation |
| ASN 설정 | 자유 (private ASN 가능) | 생성 후 변경 불가 (65515 기본) | 64512 기본 / custom 변경 시 신규 생성 |
| 확장성 | 장비 성능에 종속 | Hub 단위 자동 확장 | 리전별 무제한 attachment |
| 광고 prefix 제어 | route-map 완전 제어 | Routing Intent로 제한적 제어 | Blackhole + propagation 제어 |
| 자동화 수준 | CLI/Ansible 수동 | ARM Template/Bicep | CloudFormation/Terraform |
| 비용 모델 | 하드웨어 라이선스 | Hub 시간당 과금 + 데이터 처리 | Attachment 시간당 + 데이터 처리 |
| 멀티클라우드 연동 | VPN/IPSec 직접 구성 | VWAN Inter-Hub 연결 | TGW Peering + RAM 공유 |
시중 대안과의 차별화된 통찰
Cisco ASA나 Palo Alto VM-Series 같은 다른 NVA 제품군과 비교했을 때 FortiGate의 차별점은 네이티브 BGP 지원과 route-map 문법의 Cisco 친화성입니다. Cisco ASA는 BGP 지원이 제한적이라 advertise 제어가 까다롭고, Palo Alto는 PAN-OS 정책 기반이라 route-map보다 App-ID 기반 필터링에 익숙한 운영팀에게는 진입장벽이 있거든요.
다른 클라우드 전용 솔루션 대비 차별점
- GCP Cloud Router는 Azure VWAN과 유사하지만 Custom Route advertisement를 지원하므로 더 유연함
- Alibaba Cloud CEN은 BGP 광고를 자동화하지만 정책 제어 기능은 AWS보다 부족
- Cloudflare Magic Transit은 BGP advertise를 인터넷 라우팅용으로만 제공, 사설망 연동에는 부적합
결국 어떤 솔루션을 선택하든 “어떤 prefix를, 어떤 방향으로, 어떤 정책으로 advertise 할 것인가”라는 동일한 설계 질문에 직면합니다. FortiGate가 가장 정밀한 제어를, Azure VWAN이 가장 자동화된 전파를, AWS TGW가 가장 유연한 멀티계정 확장을 제공하는 것이 핵심이거든요.
자주 묻는 질문
Q. BGP advertise가 정상적으로 됐는지 빠르게 확인하는 명령어는 무엇인가요?
A. FortiGate는 `get router info bgp neighbors
Q. Azure Virtual WAN과 AWS Transit Gateway를 동시에 사용 가능한가요?
A. 가능합니다. 일반적으로 온프레미스 FortiGate를 중앙 BGP 종단점으로 두고 양쪽 클라우드와 eBGP 피어링을 구성합니다. 다만 ASN 중복 방지와 route-map 단방향 광고 정책을 반드시 적용해야 AS-PATH 루프를 예방할 수 있습니다.
Q. default route를 advertise해도 안전한가요?
A. 매우 신중해야 합니다. 클라우드 spoke 입장에서 default route를 받으면 모든 인터넷 트래픽이 해당 경로로 흡수됩니다. Azure VWAN에서 `0.0.0.0/0`을 NVA로 광고하면 인터넷 egress가 NVA로 강제되어 비용 폭탄과 보안 사고로 이어질 수 있습니다.
Q. Hold Timer와 Keepalive 값은 어떻게 설정하는 게 표준인가요?
A. 표준은 Keepalive 60초, Hold Timer 180초입니다. 다만 클라우드 환경에서는 LinkLocal IP 특성상 빠른 장애 감지를 위해 Hold Timer를 9~12초로 줄이기도 합니다. 양쪽 neighbor 간 설정값이 다르면 BGP가 Established 되지 않으므로 반드시 일치시켜야 합니다.
BGP Route Advertisement는 단순히 라우팅 정보를 공유하는 것을 넘어, 하이브리드 네트워크 전체의 트래픽 흐름을 좌우하는 설계 결정이거든요. FortiGate의 정밀한 prefix 제어, Azure VWAN의 자동화된 Hub 전파, AWS TGW의 유연한 멀티계정 확장은 각기 다른 운영 철학을 반영합니다. 이 글이 세 환경의 BGP 광고 차이를 명확히 이해하는 데 실질적인 도움이 되었길 바랍니다.
면책조항: 본 글의 내용은 정보 공유 및 교육 목적으로 작성되었으며, 특정 제품의 공식 기술 문서를 대체하지 않습니다. 실제 네트워크 구성 시에는 각 벤더의 최신 공식 매뉴얼과 클라우드 제공사의 문서를 반드시 확인하시길 권장드립니다. 글에서 언급된 명령어와 설정값은 환경에 따라 동작이 달라질 수 있으며, 적용으로 인한 장애 발생 시 책임은 사용자 본인에게 있습니다.
