사례2건
2건 중 1~2번째
IL-0394Cloudflare Miami 라우터가 내부 IPv6 경로를 BGP 피어와 트랜짓 제공자에게 유출해 25분 동안 백본이 혼잡해지고 트래픽이 드롭됐다Cloudflare2026- 증상
2026년 1월 22일 20:25 UTC 부터 Cloudflare 의 Miami edge 라우터 하나가 BGP 트랜짓 제공자와 피어에게 예상하지 않은 경로를 광고했다. 20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했다.
- 촉발
20:25 UTC 에 정책 자동화 플랫폼으로 Bogotá 데이터센터용 BGP 광고를 Miami 에서 빼는 변경을 내보냈다. 이 변경이 Miami 라우터의 여러 BGP export 정책에서 prefix-list 6-BOG04-SITE-LOCAL 줄만 지워, 남은 정책이 route-type internal 인 경로를 모두 받아들여 밖으로 광고하게 됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했고, 20:44 UTC 에 대응을 조율하려고 인시던트를 열었다.
- 조치
- 20:50 UTC 에 네트워크 운영자가 잘못된 설정 변경을 손으로 되돌렸다. 이때 영향이 끝났다.
- 자동화가 같은 라우터에서 다시 돌지 않도록 그 라우터의 자동화를 멈췄다.
- 21:47 UTC 에 유출을 촉발한 변경을 네트워크 자동화 코드 저장소에서 되돌렸다.
- 22:07 UTC 에 운영자가 라우팅 정책 버그 없이 자동화가 다시 돌 수 있음을 확인했고, 22:40 UTC 에 Miami 라우터의 자동화를 다시 켰다.
- 후속 조치
- 경로 유출을 일으킨 라우팅 정책 자동화의 결함을 고치고, 이 결함과 비슷한 결함을 바로 막는다.
- 외부 export 정책에서 제공자와 피어에게서 받은 경로를 명시적으로 거부하는 BGP community 기반 안전장치를 라우팅 정책에 더한다.
- 비어 있거나 잘못된 정책 term 을 찾는 라우팅 정책 자동 평가를 CI/CD 파이프라인에 넣는다.
- 네트워크 설정 문제와 자동 변경의 나쁜 영향을 더 일찍 알아채도록 개선한다.
- RFC9234 의 BGP role 과 Only-to-Customer Attribute 를 배포하기에 앞서 라우팅 장비 공급사의 구현을 검증한다. BGP role 과 Only-to-Customer Attribute 는 라우팅 정책과 상관없이 자기 AS 에서 생기는 경로 유출을 막는 유일한 방법이다.
- 비정상적인 AS path 를 가진 경로를 네트워크가 자동으로 거부할 수 있게 하는 RPKI Autonomous System Provider Authorization, 곧 ASPA 를 장기적으로 채택하도록 권한다.
- 교훈
Cloudflare 는 이번 사고로 경로 유출을 실수로 일으키기가 얼마나 쉬운지 직접 겪었다고 적었다. 경로 유출을 막으려면 여러 갈래의 대책이 필요하고, 라우팅 정책 설정과 자동화에서 단기와 장기로 고칠 곳을 여럿 찾았다고 했다.
- 증상
2025년 8월 21일 16:27 UTC 부터 AWS us-east-1 에 오리진을 둔 고객과, us-east-1 의 서버를 거쳐 Cloudflare 와 트래픽을 주고받는 사용자에게 높은 지연, 패킷 손실, 오리진 연결 실패가 났다. 16:44 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다.
- 촉발
16:27 UTC 쯤 한 고객이 AWS us-east-1 에서 Cloudflare 캐시에 있는 객체를 대량으로 요청하기 시작했다. 그 응답 트래픽이 Cloudflare 에서 AWS 로 가는 전체 트래픽을 두 배로 늘렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애가 시작되고 17분 뒤인 16:44 UTC 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다. 17:45 에는 애시번 IAD 의 고객 영향을 이유로 장애가 선언됐다.
- 조치
- 19:05 UTC 에 트래픽 급증을 일으킨 고객 하나에 속도 제한을 걸어 혼잡을 줄였다.
- 네트워크 팀이 트래픽 엔지니어링 조치를 더 해 19:27 에 혼잡을 완전히 풀었다.
- 19:45 부터 Cloudflare 의 요청에 따라 AWS 가 BGP 광고 철회를 되돌렸고, 20:07 에 IAD PNI 로 Cloudflare 에 보내는 BGP 프리픽스 광고를 정상으로 돌려놓았다.
- 후속 조치
- 한 고객의 트래픽이 다른 고객에게 영향을 줄 만큼 네트워크를 혼잡하게 만들기 시작하면 그 트래픽의 우선순위를 골라서 낮추는 장치를 만든다.
- Data Center Interconnect 증설을 앞당겨 네트워크 용량을 지금보다 크게 늘린다.
- AWS 와 함께 양쪽의 BGP 트래픽 엔지니어링 조치가 앞으로 서로 부딪치지 않게 한다.
- 고객마다 네트워크 자원을 나눠 예산을 정하고, 예산을 넘긴 고객의 트래픽이 다른 고객의 서비스를 떨어뜨리지 못하게 하는 새 트래픽 관리 시스템을 만든다. 이 시스템은 이번에 손으로 한 혼잡 대응 조치 상당수도 자동화한다.
- 교훈
Cloudflare 는 이 사고로 한 고객의 사용 방식이 나머지 생태계를 해치지 못하게 막는 안전장치가 더 필요하다는 것이 드러났다고 했다. 어느 한 고객이 공유 자원을 독차지해 다른 고객의 안정성을 해치지 못하도록 고객 격리를 더 잘 설계해야 하고, 수요를 감당할 만큼 네트워크 인프라 용량을 늘려야 한다는 것을 핵심 교훈으로 꼽았다. 결론에서는 드물게 트래픽이 몰린 상황에서 네트워크 혼잡 관리가 모자라 장애가 났다고 했다.
이 2건에서 가장 많이 나오는 구성 요소: BGP 라우팅, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.