Incident Library

IL-0228 OVHcloud · 2021-10-13networking

라우터 설정 변경 중 인터넷 전체 라우팅 테이블이 IGP 로 광고돼 OVHcloud 전 세계 네트워크의 IPv4 라우팅이 멈췄다.

OVHcloud 는 몇 주째 늘어난 DDoS 공격을 막으며 방어 설정을 계속 강화하고 있었다. Change Advisory Board 가 정해진 Method of Procedures 와 동료 검토로 검증한 변경을 2021-10-12 16:28 CET 에 공지했고, 10월 13일 09:05 CET 에 계획대로 시작했다. 09:18 CET 까지 BGP 격리와 설정 업데이트가 예상대로 진행됐다. 09:20 CET 에 미국 Vint Hill 데이터 센터의 라우터가 BGP 경로를 OSPF 로 재분배하는 설정을 조절하려던 명령을 제대로 해석하지 못했고, 인터넷 전체 라우팅 테이블이 OVHcloud IGP 로 광고됐다. OVHcloud 네트워크는 모든 대륙에 걸친 풀 메시 구조라 모든 라우터가 서로 라우팅 정보를 주고받는다. 라우팅 정보가 몰려 OSPF 테이블이 가득 차고 라우터의 RAM 과 CPU 가 과부하에 걸렸다. BGP 와 OSPF 사이에 수렴 루프가 생겨 IPv4 라우팅이 동작하지 않았다. IPv6 트래픽은 영향을 받지 않았다.

팀은 09:21 CET 에 라우터 성능 문제를 감지해 에스컬레이션했고, 변경이 수렴하기를 기다리다가 09:25 CET 에 위기 관리 절차를 시작했다. 09:30 CET 에 롤백 절차가 효과가 없자 장비를 물리적으로 격리하기로 하고 현장 지원을 불렀다. 09:45 CET 에 데이터 센터 팀이 두 번째 우회 계획을 실행하러 통신실로 갔고, 현지 시각 새벽 3시인 10:00 CET 에 기술자가 작업을 시작했다. 10:02 CET 에 광 장비 연결을 끊어 달라고 요청했고, 10:10 CET 에 고장 라우터의 전원을 끄기로 해 10:18 CET 에 껐다. 라우터 D2 가 내려가자 네트워크가 수렴하면서 장비들의 OSPF 테이블이 비고 트래픽이 정상 게이트웨이로 흘렀다. 10:20 CET 에 첫 서비스가 돌아왔고, 10:30 CET 부터 남은 서비스를 되살리려고 연결 안정화를 시작해 10:57 CET 에 기술적으로 위기가 끝났다. 같은 날 오전 11시 30분에 먼저 낸 공지는 작업 시작을 오전 9시 12분 CET, 장비 격리를 오전 10시 15분으로 적었다.

심각도
–
영향 범위
IPv4 routing across OVHcloud's global network and all OVHcloud sites; IPv6 traffic unaffected
영향 사용자
–
지역
global
감지까지
1m
복구까지
1h 37m

증상

2021-10-13 09:20 CET 에 네트워크 설정을 바꾸던 중 문제가 생겼고, 09:21 CET 에 팀이 라우터 성능 문제를 감지해 곧바로 에스컬레이션했다. IPv6 트래픽은 계속 정상으로 오갔다.

인터넷 전체 라우팅 테이블이 OVHcloud IGP 로 광고되면서 라우팅 정보가 한꺼번에 몰려 일부 라우터가 불안정해졌다. OSPF 테이블이 가득 차 라우터의 RAM 과 CPU 가 과부하에 걸렸다. BGP 와 OSPF 사이에 수렴 루프가 생겨 IPv4 라우팅이 동작하지 않았고, OVHcloud 의 모든 사이트에서 IPv4 트래픽을 제대로 처리하지 못했다.

팀은 먼저 롤백 절차를 시도했지만 09:30 CET 에 롤백이 효과가 없었다. 그래서 문제 장비를 물리적으로 격리하기로 하고 현장 지원을 불렀다.

고장 라우터를 끈 뒤 10:20 CET 에 첫 서비스가 돌아왔고, 10:57 CET 에 기술적으로는 위기가 끝났다.

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

원인

원인 설정 변경

구성 요소 내부 라우팅BGP 라우팅백본망
기여 요인 롤백 무효과도한 영향 범위
촉발
늘어나는 DDoS 공격에 맞서 방어 설정을 강화하려고 미국 Vint Hill 데이터 센터의 라우터에 계획된 변경을 하던 중이었다. 이때 라우터가 BGP 경로를 OSPF 로 재분배하는 설정을 조절하려던 명령을 제대로 해석하지 못했다.

감지

변경 작업 중이던 09:21 CET 에 팀이 라우터 성능 문제를 감지하고 곧바로 에스컬레이션 절차를 시작했다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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