{"id":"IL-0347","org":"Scaleway","date":"2024-10-18","docs":["https://github.com/FRRouting/frr/pull/17163"],"title":{"en":"About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck","ko":"FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다"},"domain":["networking","kubernetes"],"impact":{"scope":"VPC connectivity for about 25% of FR-PAR-1 hypervisors and the products built on it: Managed Database and Redis, Serverless Functions and Containers, Kubernetes Kapsule nodes and control planes; earlier, about a minute of heavy packet loss for instances in one rack","users":"Customers with resources on the affected hypervisors and in the affected rack","region":"FR-PAR-1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.scaleway.com/incidents/g3q3c4d43gkb","kind":"official-status","archived":"https://web.archive.org/web/20251016130326/https://status.scaleway.com/incidents/g3q3c4d43gkb"}],"summary":{"en":"Scaleway's VPC networks are a software-defined network on top of hypervisors, and BGP route reflectors are one of its building blocks. Critical systems run at least two active instances so that one can carry the whole load. At 6:20 UTC on 18 October 2024 a ToR switch crashed; its unstable software modules took about 50 seconds to move all rack traffic to the second ToR switch, and packets to and from the rack's hypervisors were dropped meanwhile. Traffic was fully rerouted by 6:21 UTC, and the crashed switch finished its automatic reboot at 6:38 UTC.\n\nThe instability spread to a VPC route reflector hosted on a hypervisor in that rack. Its software stack became stuck in an abnormal state that its auto-restart could not clear, and VPC kept working on the second route reflector without redundancy. At 7:50 UTC the second route reflector also became stuck in a non-operational state, and about 25% of the hypervisors lost VPC connectivity with the rest of the region. Health-check monitoring on both route reflectors detected the anomaly, but the auto-restart mechanism failed. Scaleway's Customer Excellence and SRE teams detected the impact and opened an incident, both route reflectors were fixed by hand, VPC connectivity was back by 8:01 UTC, and redundancy was back to normal by 8:07 UTC. Scaleway fixed the autohealing that had failed to repair route reflectors in a stale state, linking a pull request to FRRouting, and planned to run different software versions on the route reflectors so one bug cannot stop all of them.","ko":"2024-10-18 6:20 UTC 에 FR-PAR-1 의 랙 하나에서 Top of Rack 스위치, 곧 ToR 스위치 한 대의 소프트웨어가 충돌했다. 소프트웨어 모듈이 불안정해서 네트워크 프로토콜이 랙의 모든 트래픽을 두 번째 ToR 스위치로 넘기는 데 약 50초가 걸렸고, 그동안 랙의 하이퍼바이저를 오가는 트래픽에서 패킷이 불규칙하게 많이 버려졌다. 6:21 UTC 에 트래픽이 예비 장비로 모두 옮겨졌고, 충돌한 스위치는 6:38 UTC 에 자동 재부팅을 마치고 이중화 상태로 돌아왔다.\n\n이 불안정은 그 랙의 하이퍼바이저에서 돌던 VPC 용 BGP 경로 반사기, 곧 RR 에 번졌다. RR 소프트웨어는 비정상 상태에 멈췄고 자동 재시작으로도 풀리지 않았다. 예비 RR 이 정상이라 고객 영향은 없었지만 RR 이중화는 사라진 상태였다. 7:50 UTC 에 두 번째 RR 도 심각한 상태에 빠져 멈췄고, 하이퍼바이저 약 25% 가 리전의 나머지와 VPC 연결을 잃었다. 두 RR 모두 헬스 체크와 자동 재시작 장치가 있었고, 헬스 체크는 이상을 잡았지만 자동 재시작이 실패했다.\n\nScaleway 의 Customer Excellence 팀과 SRE 팀이 영향을 알아채 사고를 열고 기술 경영진에 알렸다. 두 RR 을 손으로 고쳐 8:01 UTC 에 VPC 연결이 모두 돌아왔고, 8:07 UTC 에 이중화까지 정상으로 돌아왔다. Kapsule 클러스터는 8:04 UTC 까지 거의 모두 회복했다."},"trigger":{"en":"At 6:20 UTC a Top of Rack switch in FR-PAR-1 had a software crash. One of the two BGP route reflectors for VPC ran on a hypervisor in that rack and was left in an abnormal state.","ko":"6:20 UTC 에 랙 하나의 ToR 스위치 소프트웨어가 충돌했다. 이 불안정이 같은 랙의 하이퍼바이저에서 돌던 VPC 용 BGP 경로 반사기를 비정상 상태에 빠뜨렸다."},"severity":"unknown","symptoms":["network-unreachable","packet-loss","node-not-ready"],"timeline":{"detected_after":null,"resolved_after":"1h 41m"},"date_kind":"incident","detection":{"en":"Health-check monitoring on both route reflectors detected the anomaly, and the Scaleway Customer Excellence and SRE teams detected the customer impact and opened an incident.","ko":"Scaleway 의 Customer Excellence 팀과 SRE 팀이 영향을 알아채고 사고를 열었다. RR 의 헬스 체크 모니터링도 이상을 잡았지만 자동 재시작은 실패했다."},"components":["network-control-plane","bgp","network-switch","database","managed-control-plane"],"root_cause":"software-bug","remediation":[{"text":{"en":"Fixed both VPC route reflectors by manual action","ko":"멈춘 VPC 경로 반사기 두 대를 손으로 고쳤다."}}],"action_items":[{"text":{"en":"Fixed the autohealing mechanism that had failed to fix route reflectors stuck in a stale state; the fix is https://github.com/FRRouting/frr/pull/17163","ko":"멈춘 상태의 경로 반사기를 고치지 못한 자동 복구 장치를 고쳤다. 수정 내용은 https://github.com/FRRouting/frr/pull/17163 이다."}},{"text":{"en":"Run different software versions on the route reflectors so a single bug cannot stop several instances","ko":"버그 하나가 여러 경로 반사기를 한꺼번에 멈추지 않도록 경로 반사기의 소프트웨어 버전을 서로 다르게 둔다."}},{"text":{"en":"Investigate the software issue that left the route reflectors in a stale state","ko":"경로 반사기를 멈춘 상태에 빠뜨린 소프트웨어 문제를 깊이 조사한다."}}],"contributing":["blast-radius-too-wide","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"On 18 October 2024, from 7:50 to 8:01 UTC, about 25% of the hypervisors in Scaleway's FR-PAR-1 availability zone lost VPC connectivity with the rest of the region, and products that use VPC failed with them. Public internet connectivity and Elastic Metal VPC connectivity were not affected.\n\nAn earlier, shorter disturbance came first. At 6:20 UTC a Top of Rack (ToR) switch had a software crash, and for about 50 seconds, until traffic had failed over to the second ToR switch of the rack, instances in that single rack saw heavy packet loss on all kinds of network connectivity. Some managed database customers got 500 HTTP errors on connections to their databases during that minute. The status page later described the service as degraded since 08:20 AM CEST and down between 09:49 and 10:04 AM CEST.\n\nDuring the VPC outage, customers of Managed Database and Redis could not reach their databases over VPC. One serverless compute node was unavailable, and some Serverless Functions and Containers customers could get 500 errors while their workloads were rescheduled. In Kubernetes Kapsule, a network partition between nodes stopped applications on different nodes from communicating, some control planes were unavailable because the infrastructure that hosts them uses VPC, and autohealing replaced some nodes that could not report their availability, so workloads were rescheduled or restarted. By 8:04 UTC almost all Kapsule clusters had recovered.","ko":"FR-PAR-1 가용 영역의 하이퍼바이저 약 25% 가 리전의 나머지와 VPC 로 통신하지 못했다. 7:50 부터 8:01 UTC 까지 Managed Database, Redis, Serverless, Kubernetes Kapsule 처럼 VPC 에 기대는 제품이 함께 영향을 받았다.\n\n이보다 앞선 6:20 부터 6:21 UTC 까지 약 1분 동안 랙 하나에 있는 소수 인스턴스가 모든 종류의 네트워크 연결에서 패킷 손실을 크게 겪었다. 이때 Managed Database 고객 일부는 데이터베이스에 연결할 때 HTTP 500 오류를 받았다.\n\nVPC 가 끊긴 동안 Managed Database 와 Redis 고객 일부는 VPC 로 데이터베이스에 접속하지 못했다. Serverless 컴퓨트 노드 한 대를 쓸 수 없게 되어, 그 노드의 워크로드가 다시 스케줄되는 동안 함수와 컨테이너 호출이 500 오류를 낼 수 있었다.\n\nKapsule 에서는 노드 사이에 네트워크 분할이 생겨 서로 다른 노드에 있는 애플리케이션끼리 통신하지 못했다. 컨트롤 플레인을 올린 인프라도 VPC 를 써서 일부 컨트롤 플레인을 쓸 수 없었다. 가용 상태를 보고하지 못한 노드 일부는 오토힐링이 교체했고, 그 노드의 워크로드가 다시 스케줄되거나 재시작됐다.\n\n이 구간에도 공용 인터넷 연결과 Elastic Metal 의 VPC 연결은 영향을 받지 않았다."},"updated_at":"2026-11-14T12:34:00.196803Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0347","org_slug":"scaleway"}