{"id":"IL-0350","org":"IONOS Cloud","date":"2026-03-03","docs":[],"title":{"en":"Hosts in an IONOS TXL cluster lost connectivity when an InfiniBand fabric resweep failed on a full multicast table","ko":"TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다"},"domain":["networking","kubernetes"],"impact":{"scope":"Network connectivity for hosts in one TXL cluster, with spillover to the DCD web frontend through IAM, the AI Model Hub, DBaaS, Managed Kubernetes and provisioning of infrastructure changes","users":"unknown","region":"TXL data center (Location DE/TXL)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"IONOS identified the linking of services through the shared provisioning queue as a key reason the degradation lasted as long as it did. Alongside making each service more robust, it is decoupling the provisioning queue and addressing dependencies between services to reduce the blast radius of future incidents.","ko":"IONOS Cloud 는 서비스들이 프로비저닝 대기열로 서로 얽혀 있던 점이 서비스 저하를 길게 만든 핵심 요인이었다고 봤다. 앞으로는 서비스마다 견고하게 만드는 것과 함께 프로비저닝 대기열의 결합을 풀어 이번과 같은 파급을 줄이겠다고 했다. 서비스 사이의 의존도 찾아 풀어서 앞으로의 장애가 미치는 범위를 줄이겠다고 했다."},"related":[],"sources":[{"url":"https://status.ionos.cloud/incidents/3pyhtpglqf43","kind":"official-status","archived":"https://web.archive.org/web/20260312041952/https://status.ionos.cloud/incidents/3pyhtpglqf43"}],"summary":{"en":"The affected cluster in TXL runs two InfiniBand topologies. For a scheduled maintenance to replace a faulty switch, Topology 2 was disabled. The Multicast Forwarding Table (MFT) on all switches in Topology 1 was already strained by IPoIB multicast groups, so Topology 1 was running in a vulnerable state. A link flap on one switch flooded the InfiniBand control plane with alerts and triggered a fabric resweep, the automated mechanism that resets the network map. With the MFT at capacity the reprogramming failed, the surge of failed route updates overwhelmed the management layer and caused a critical gateway overload, BGP sessions dropped and hosts in the cluster lost connectivity. IONOS ended the network incident by switching from the affected control plane to its standby, rebooting the locked-up gateways and recovering Topology 1 from the scheduled maintenance.\n\nWhile hosts were unreachable, every provisioning job for them was queued, and self-healing in the affected services kept adding jobs. After the network recovered, this volume caused resource locking that slowed the provisioning queue, so volume operations and self-healing waited and several services stayed degraded: IAM, and with it the DCD frontend, Managed Kubernetes and DBaaS. IONOS paused provisioning in the cluster, re-enabled it once connectivity improved, and let the backlog drain; provisioning and DBaaS were back to full operation at 21:49 UTC. IONOS named the coupling of services through the provisioning queue as a key reason the degradation lasted so long. The report says a related incident, covered by an RCA released on 11.03.2026, had the same technical root cause.\n\nFor the network, IONOS made the control-plane failover timers less aggressive and reduced heavy sweep activity, reduced multicast group memberships, and added monitoring with early alerts on forwarding table use and control-plane memory. Longer term it is moving the control plane to dedicated servers, auditing IPv6 and IPoIB driver settings and modernising the interconnect fabric, and it is changing IAM, Managed Kubernetes provisioning and the provisioning engine so that one cluster's backlog spills over less.","ko":"2026-03-03 IONOS Cloud 는 TXL 데이터 센터의 한 클러스터에서 고장 난 스위치를 바꾸는 정비를 했다. 정비 중 이 클러스터의 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 이때 Topology 1 의 모든 스위치는 IPoIB 멀티캐스트 그룹 때문에 Multicast Forwarding Table, 곧 MFT 용량이 이미 빠듯한 위태로운 상태였다. Topology 1 의 스위치 하나에서 링크 흔들림이 일어나 InfiniBand 컨트롤 플레인에 알림이 쏟아졌고, 네트워크 지도를 다시 맞추려고 자동으로 동작하는 자가 치유 장치인 패브릭 resweep 이 시작됐다. MFT 가 이미 꽉 차 있어 재설정에 필요한 재프로그래밍이 실패했고, 실패한 경로 갱신이 몰려 관리 계층이 버티지 못했다. 게이트웨이가 심한 과부하에 빠지고 BGP 세션이 끊겨 클러스터의 호스트 연결이 끊겼다.\n\nIONOS Cloud 는 문제가 난 컨트롤 플레인을 대기 장비로 전환하고, 멈춘 게이트웨이를 재부팅하고, Topology 1 을 정비 상태에서 복구해 네트워크 장애를 풀었다. 그사이 영향을 받은 클러스터에서는 프로비저닝 작업이 성공할 수 없어 그 호스트의 자원에 예정된 변경이 모두 대기열에 쌓였고, 자가 치유에 들어간 서비스들이 작업을 더 넣었다. 네트워크가 돌아온 뒤 밀린 작업이 자원 잠금 지연을 일으켜 처리가 느려졌고, 자가 치유 작업을 기다리던 서비스들이 오래 나쁜 상태로 남았다. IAM 은 장애 중 시작된 IP 할당 정비 작업이 오래 끝나지 않아 Data Center Designer, 곧 DCD 의 프런트엔드에 응답하지 못했다. AI Model Hub 는 Managed Kubernetes 클러스터의 연결이 끊겨 쓸 수 없었고, DBaaS 와 Managed Kubernetes 는 BGP 연결 손실과 프로비저닝 지연을 함께 겪었다.\n\nIONOS Cloud 는 12:54 UTC 에 작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄고, 14:01 UTC 에는 네트워크가 나아지고 있어 프로비저닝을 다시 켜겠다고 알렸다. AI Model Hub 는 14:37 UTC 에, DCD 는 15:25 UTC 에 정상으로 돌아왔다. 21:49 UTC 에 프로비저닝과 DBaaS 가 완전히 돌아오고 밀린 작업이 모두 처리되어 사고가 닫혔다."},"trigger":{"en":"During a scheduled maintenance to replace a faulty switch, Topology 2 of 2 in the affected cluster was disabled as planned, and a link flap on a switch in Topology 1 then flooded the InfiniBand control plane with alerts and started a fabric resweep.","ko":"TXL 데이터 센터 클러스터의 고장 난 스위치를 바꾸는 정비로 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 그동안 남은 Topology 1 에서 스위치 하나의 링크 흔들림이 패브릭 resweep 을 일으켰다."},"severity":"unknown","symptoms":["network-unreachable","link-flapping","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"IONOS began investigating monitoring alerts in TXL; the first status update was posted at 11:36 UTC.","ko":"IONOS Cloud 는 TXL 에서 울린 모니터링 알림으로 장애를 알아챘고, 11:36 UTC 에 상태 페이지에 이 알림을 조사하고 있다고 올렸다."},"components":["infiniband","network-control-plane","bgp","network-link","model-hub","database"],"root_cause":"capacity","remediation":[{"text":{"en":"Switched from the affected control plane to its standby","ko":"문제가 난 컨트롤 플레인을 대기 장비로 전환했다."}},{"text":{"en":"Rebooted the locked-up gateways","ko":"멈춘 게이트웨이를 재부팅했다."}},{"text":{"en":"Recovered Topology 1 from the scheduled maintenance","ko":"예정된 정비 상태에서 Topology 1 을 복구했다."}},{"text":{"en":"Paused provisioning in the cluster that had a backlog of queued jobs","ko":"작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄다. 실행 중인 서비스는 영향이 없었지만 기존 자원의 변경은 다시 켤 때까지 처리되지 않았다."}},{"text":{"en":"Re-enabled provisioning once network connectivity improved and watched job execution","ko":"네트워크 연결이 나아지자 프로비저닝을 다시 켜고 작업 실행을 지켜봤다."}},{"text":{"en":"Re-established connectivity for the systems that support the DCD","ko":"DCD 를 받치는 시스템들의 연결을 다시 세워 DCD 서비스를 되살렸다."}}],"action_items":[{"text":{"en":"Adjusted the control-plane configuration to use less aggressive failover timers and reduced heavy sweep activity, lowering the load on the forwarding table","ko":"컨트롤 플레인 구성에서 failover 타이머를 덜 민감하게 바꾸고 무거운 sweep 작업을 줄여 전달 테이블의 부하를 낮췄다."}},{"text":{"en":"Reduced the number of multicast group memberships to relieve the forwarding table","ko":"멀티캐스트 그룹 가입 수를 줄여 전달 테이블의 부담을 더 덜었다."}},{"text":{"en":"Set up continuous monitoring of forwarding table use and control-plane memory with alerts before capacity limits are reached","ko":"전달 테이블 사용률과 컨트롤 플레인 메모리를 계속 감시해 용량 한도에 닿기 전에 알림이 오게 했다."}},{"text":{"en":"Move the control plane to dedicated high-performance servers, separate from data-plane traffic","ko":"네트워크 관리와 데이터 플레인 트래픽이 자원을 다투지 않도록 컨트롤 플레인을 전용 고성능 서버로 옮긴다. 2025년 4분기에 시작했고 2026년 2분기 완료가 목표다."}},{"text":{"en":"Audit IPv6 configurations and IPoIB driver settings","ko":"IPv6 구성과 IPoIB 드라이버 설정을 깊이 감사한다. 2026년 2분기 완료가 목표다."}},{"text":{"en":"Modernise the interconnect fabric, including switches, gateways and drivers","ko":"스위치, 게이트웨이, 드라이버를 포함한 인터커넥트 패브릭을 현대화해 복원력과 성능을 높인다. 2026년 3분기 완료가 목표다."}},{"text":{"en":"Hardened IAM maintenance protocols so that critical identity services keep working when the primary Cloud APIs are temporarily unavailable","ko":"주요 Cloud API 를 잠시 쓸 수 없어도 핵심 신원 서비스가 동작하도록 IAM 정비 절차를 강화했다."}},{"text":{"en":"Move IAM to a dedicated platform without a dependency on the standard managed Kubernetes clusters","ko":"IAM 을 전용 플랫폼으로 옮기는 작업을 앞당겨 IAM 이 일반 Managed Kubernetes 클러스터에 기대지 않게 한다. 목표 시점은 2026년 3분기다."}},{"text":{"en":"Introduce a dedicated provisioning provider for DBaaS and Managed Kubernetes","ko":"DBaaS 와 Managed Kubernetes 에 전용 프로비저닝 공급자를 두어 자가 치유 같은 변경 중에 서비스가 끊기는 일을 줄인다. 목표 시점은 2026년 3분기다."}},{"text":{"en":"Add automated circuit breakers to the provisioning engine against overload and queue buildup from self-healing services","ko":"자가 치유 서비스 때문에 과부하가 나거나 대기열이 끝없이 쌓이지 않도록 프로비저닝 엔진에 자동 서킷 브레이커를 넣는다. 목표 시점은 2026년 1분기다."}},{"text":{"en":"Improve visibility and control over job execution and prioritisation in the provisioning queue","ko":"프로비저닝 대기열에서 작업 실행과 우선순위를 더 잘 보고 다룰 수 있도록 QoS 를 개선한다."}},{"text":{"en":"Change the provisioning queue architecture to decouple services and reduce spillover","ko":"서비스 사이의 파급을 줄이도록 프로비저닝 대기열의 결합을 푸는 구조 변경을 한다."}}],"contributing":["automation-amplified","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"On 3 March 2026, during a scheduled maintenance to replace a faulty switch in a cluster in IONOS Cloud's TXL data center, monitoring alerts fired and the hosts in that cluster lost network connectivity. Customers saw intermittent network degradation or outages, and the Data Center Designer (DCD) web frontend and the AI Model Hub became unreachable.\n\nIn the network, a link flap on a switch in Topology 1, the topology still running while Topology 2 was disabled for the maintenance, flooded the InfiniBand control plane with alerts and started a fabric resweep. The Multicast Forwarding Table (MFT) on the Topology 1 switches was already near capacity from IPoIB multicast groups, so the reprogramming for the resweep failed. The flood of failed route updates overwhelmed the management layer, gateways locked up, BGP sessions dropped and the hosts in the cluster lost connectivity.\n\nEach service showed the outage differently. Servers hosting DBaaS and Managed Kubernetes workloads lost BGP connectivity directly, and DBaaS was added to the affected services because of a rising error count. The AI Model Hub kept working but could not be reached, because its Managed Kubernetes cluster lost network connectivity. The DCD frontend was unavailable because the IAM service behind it could not be reached: an IP assignment maintenance job started during the incident stayed pending for a long time.\n\nThe disruption lasted much longer than the network fault. Provisioning jobs for resources in the cluster could not succeed and were queued, and services that entered self-healing added more jobs, so the queue grew exponentially. After the network recovered, the backlog caused resource locking that slowed the queue, and volume attach and detach operations and self-healing actions waited, which kept IAM and Managed Kubernetes degraded. At 12:38 UTC the status page reported problems again on the DCD frontend and AI Model Hub after an earlier recovery; provisioning in the cluster was paused at 12:54 UTC, AI Model Hub was operational again at 14:37 UTC, the DCD at 15:25 UTC, and provisioning and DBaaS were restored at 21:49 UTC.","ko":"2026-03-03 11:36 UTC 에 상태 페이지가 TXL 의 모니터링 알림을 조사하고 있다고 알렸다. 정비 중이던 클러스터 한 곳의 호스트가 연결을 잃었고, 고객은 간헐적인 네트워크 서비스 저하나 중단을 겪었다.\n\n12:01 UTC 에 Data Center Designer, 곧 DCD 와 AI Model Hub 가 영향 목록에 올랐다. DCD 웹 프런트엔드는 그 밑의 IAM 서비스에 닿지 못해 쓸 수 없었다. 장애 중에 시작된 IP 할당 정비 작업이 오래 끝나지 않아 IAM 이 프런트엔드에 응답하지 못했다.\n\nAI Model Hub 서비스 자체는 계속 동작했지만, 그 서비스가 도는 Managed Kubernetes 클러스터의 네트워크가 끊겨 고객이 쓸 수 없었다. 12:09 UTC 에 회복이 보였다가 12:38 UTC 에 DCD 프런트엔드와 AI Model Hub 에서 문제가 다시 나타났다.\n\n12:45 UTC 에 오류 수가 늘어 DBaaS 도 영향 목록에 들어갔다. DBaaS 와 Managed Kubernetes 워크로드를 올린 서버는 BGP 연결을 바로 잃었다. 그 뒤에는 프로비저닝 대기열이 밀려 볼륨 연결과 해제, 자동으로 시작되는 자가 치유 작업이 미뤄졌고, 네트워크가 돌아온 뒤에도 복구가 늦어졌다.\n\n프로비저닝 시스템이 영향을 받은 클러스터의 자원에 연결하지 못해 먼저 대기열에 작업이 크게 쌓였다. 연결 문제로 자가 치유에 들어간 서비스가 작업을 더 넣으면서 작업 수가 기하급수적으로 늘었고, 네트워크가 돌아온 뒤에는 자원 잠금 병목으로 대기열 처리가 느려졌다. 고객이 DCD 에서 인프라 자원을 바꾸는 작업은 오래 걸렸다."},"updated_at":"2026-11-14T12:34:00.471609Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0350","org_slug":"ionos-cloud"}