Incident Library

IL-0258 Fastmail · 2016-02-06networking

DDoS 방어 업체에서 데이터센터로 가는 GRE 터널이 끊겨 FastMail 이 두 시간 가까이 접속되지 않았다

2015년 11월 DDoS 공격을 받은 뒤, 주 데이터센터 업체 NYI 는 FastMail 의 네트워크 기반 DDoS 방어를 Black Lotus 에서 Level 3 로 옮겼다. 인터넷 백본의 큰 부분을 이루는 Level 3 의 용량이 이유였다. 이 방식은 BGP 와 GRE 터널로 이루어진다. Level 3 는 FastMail 의 IP 대역 66.111.4.0/24 를 자기 네트워크에서 BGP 로 광고해 모든 트래픽을 받아 걸러 낸다. 걸러 낸 트래픽은 Level 3 에서 NYI 로 이어진 GRE 터널을 거쳐 FastMail 네트워크로 보낸다. 예전에는 트래픽이 치솟을 때만 NYI 가 BGP 광고로 트래픽을 Black Lotus 로 돌렸다. 바뀐 뒤에는 조용할 때도 모든 트래픽이 Level 3 를 거치는 상시 방어였고, NYI 는 이를 직접 바꿀 수 없었다.

멜버른 시간 일요일 오전 4시 50분에 Level 3 와 NYI 사이의 GRE 터널이 끊겨 트래픽이 FastMail 네트워크에 들어오지 못했다. NYI 는 금방 알아챘지만 고칠 권한이 없었다. NYI 가 Level 3 지원 창구에 전화해 계속 상급자에게 올려 보낸 끝에, FastMail 의 공인 IP 대역이 다시 NYI 를 가리키게 됐다. 서비스는 오전 6시 45분, UTC 로는 토요일 오후 7시 45분에 돌아왔다. 장애 동안 데이터센터 사이 보조 네트워크 덕분에 내부 시스템은 계속 동작했다. DNS 도 보조 네트워크로 연결되는 CloudFlare Virtual DNS 로 옮겨 두어서 계속 동작했다.

심각도
–
영향 범위
FastMail was unavailable to customers for almost two hours; internal systems kept working
영향 사용자
FastMail customers
지역
–
감지까지
–
복구까지
1h 55m

증상

멜버른 시간 2016년 2월 7일 일요일 오전 4시 50분, UTC 로는 2월 6일 오후 6시 무렵 Level 3 와 NYI 사이의 GRE 터널이 끊겼다. FastMail 로 오는 트래픽이 FastMail 네트워크에 전혀 들어오지 못해 고객은 서비스를 쓸 수 없었다.

데이터센터 사이에 따로 둔 보조 네트워크 덕분에 내부 시스템은 장애 내내 정상으로 돌았다. 이미 FastMail 로 메일 저장소를 옮긴 Pobox Mailstore 고객은 다른 네트워크로 들어와서 장애를 겪지 않았다.

주 네트워크를 쓸 수 없을 때는 Amsterdam 의 보조 수신 메일 서버가 들어오는 메일을 받는다. 이 서버들은 용량이 모자라 메일의 상당량을 나중에 다시 보내라고 미룬다. 그러면 보내는 쪽 서버가 한동안 기다렸다가 다시 보내므로 메일 배달이 늦어진다.

증상 서비스 중단네트워크 도달 불가

원인

촉발
멜버른 시간 2016년 2월 7일 오전 4시 50분에 DDoS 방어를 맡은 Level 3 와 주 데이터센터 NYI 사이의 GRE 터널이 끊겼다.

감지

데이터센터 업체 NYI 가 장애를 금방 알아챘다.

조치

후속 조치

교훈

이렇게 복구가 늦어지는 것은 받아들일 수 없다. FastMail 과 NYI 가 쌓아 온 신뢰성의 큰 부분은 NYI 가 인프라를 직접 통제하는 데서 나왔다. 상시 DDoS 방어로 옮기면서 그 통제를 잃었다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: DDoS 방어 서비스, BGP 라우팅. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.