{"id":"IL-0400","org":"PSBA","date":"2026-03-25","docs":[],"title":{"en":"Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default route","ko":"웨일스 공공 부문 광역 네트워크 PSBA 에서 웨일스 전역의 기관 사이트가 연결과 인터넷 접속을 잃었고, 관리 링크도 계속 끊겼다 붙었다"},"domain":["networking"],"impact":{"scope":"Sites on the PSBA network across Wales lost connectivity or internet access, fully or intermittently, including councils, health boards, fire and rescue services, Natural Resources Wales and others; PSBA management connectivity was also unstable","users":"public sector organisations across Wales","region":"Wales"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The report names eight lessons: a change was made outside PSBA change control; internal communication during the Major Incident was slow and fragmented; the organisation was not ready for a network-wide incident; losing management access stopped the resolver groups from seeing the network state and customer impact; the resolver groups did not understand customer impact in enough detail, which delayed finding the root cause; escalation to PSBA management was slow; legacy configuration left in the network contributed; and email and SMS communications did not reach some customers in time.","ko":"보고서가 밝힌 교훈은 여덟 가지였다. PSBA 가 합의한 변경 관리 절차 밖에서 계획에 없던 변경을 했다. P1 / Major Incident 동안 내부 소통이 효과적이지 않아 업데이트가 늦고 흩어졌다. 네트워크 전체에 걸친 큰 장애에 대응할 준비가 부족했다. 관리 접속을 잃어 해결 담당 그룹이 문제를 끝까지 찾지 못했고 네트워크 상태와 고객 영향을 보기 어려웠다. 고객 영향을 자세히 몰라 해결 담당 그룹이 충분한 정보를 받지 못했고, 그래서 문제 해결의 효과가 떨어지고 근본 원인을 찾는 일이 늦어졌다. PSBA 경영진에게 에스컬레이션하는 속도가 문제였다. 네트워크 안에 레거시 구성이 남아 있었다. 메일과 문자 공지가 효과적이지 않아 일부 고객이 제때 알맞은 업데이트를 받지 못했다."},"related":[],"sources":[{"url":"https://swanseabay.nhs.wales/about-us/our-health-board/our-board-business/health-board-committees/digital-data-research-and-innovation-committee/may-2026/4-1i-appendix-1-wales-wide-outage-pir-pdf/","kind":"runbook","archived":null}],"summary":{"en":"The PSBA network, run by BT PSBA, connects public sector organisations across Wales such as councils, health boards and fire and rescue services. BT/PSBA was taking over the management of legacy UPS devices operated by Capita. The devices were addressed in a /16 subnet, and managing them from BT/PSBA needed a routing change in which MPLS VPN routes were leaked in a controlled way. To see whether this was simple, a route map was applied to a PSBA core PE router without formal change control, because the change was considered non-service impacting. No impact was seen at first. When it became clear that return traffic from the UPS devices would need route import changes as well, the change was removed, since going further needed formal approval. About 20 to 30 minutes later a wider management connectivity problem appeared, and the outage was not linked to the change because the two management links were flapping; the cause of that flapping was still under investigation when the report was written.\n\nThe PE router at the Vantage Data Centre where the route map had been changed was exporting a default route, and customer VPNs that still carried legacy MPLS management configuration imported it, overriding the customers' own default routes. With management access unstable, 3rd line could not troubleshoot, and the Service Desk escalated through the Major Incident manager, the account director and a Technical Design Architect, who travelled to Cardiff and then to the Vantage Data Centre. At 22:00 the Technical Design Architect changed QoS on the BGP, management access returned and alarms cleared to single figures by 22:27, but health boards saw no improvement.\n\nFurther troubleshooting at the data centre found the exported default route. The route map amendment was confirmed removed, yet the default route was still advertised after routes were cleared and inbound BGP advertisements were reset. At 01:02 the configuration issue affecting the internet learned route was corrected, and at 01:10 the Technical Design Architect did a controlled reload of the router, which restored customer services and management connectivity. The network was stable from 01:15 and health boards confirmed restoration at 02:08. The report also records that the first incident communications at 17:27 went to distribution lists that missed some organisations and that no customer text message was sent with them; the contact list and SMS were widened to all customers across the PSBA estate at 21:48.","ko":"Capita 가 운영하던 레거시 UPS 장비는 BT/PSBA 소유와 관리로 넘어가는 중이었다. 이 장비들은 /16 서브넷에 있었고, BT/PSBA 가 이 장비들을 관리하려면 라우팅 구성을 바꿔 MPLS VPN 경로를 통제된 방식으로 leaking 해야 했다. 이 방법을 간단히 적용할 수 있는지 보려고 2026년 3월 25일 16:30 에 PSBA 코어 Provider Edge 라우터에 구성 변경을 적용했다. 서비스에 영향이 없는 변경으로 보고 정식 변경 관리를 거치지 않았다. route map 을 적용한 직후에는 영향이 보이지 않았다. UPS 장비에서 돌아오는 트래픽에도 route import 변경이 필요하다는 것을 알게 되자, 승인 없이 변경을 더 넓히는 것은 맞지 않다고 보고 16:40 에 구성을 지웠다.\n\n그러나 route map 을 바꿨던 Vantage Data Centre 코어 Provider Edge 라우터가 default route 를 내보냈고, 이 default route 가 레거시 MPLS 관리 구성을 가진 고객 VPN 으로 들어갔다. 고객 VRF 에 route target import 64627:16 이 있으면 고객의 default route 가 덮어써져, 그 고객은 인터넷 연결을 잃거나 연결이 나빠질 수 있었다. 20~30분 뒤 관리 연결 문제가 넓게 드러났다. 두 PSBA 관리 링크가 끊겼다 붙기를 되풀이하는 것이 보였기 때문에, 3rd line 지원 팀은 처음에 이 문제를 앞선 변경과 연결 짓지 않았다. 관리 링크가 흔들린 정확한 원인은 아직 조사 중이었다. 관리 접속을 잃어 해결 담당 그룹은 네트워크 상태와 고객 영향을 제대로 보지 못했다. 고객 영향의 자세한 내용도 해결 담당 그룹에 충분히 전달되지 않았고, 공지 메일과 문자는 일부 기관에 닿지 않았다.\n\n22:00 에 Technical Design Architect 가 현장에서 BGP 의 QoS 를 조정해 관리 링크를 안정시키자 경보가 줄었다. 이어진 점검에서 잘못 광고되는 default route 를 찾았다. route map 변경은 지워진 상태였고, 경로를 지우고 inbound BGP 광고를 리셋해도 default route 는 계속 잘못 광고됐다. 3월 26일 01:02 에 인터넷에서 학습한 경로에 영향을 주던 구성 문제를 찾아 고쳤고, 01:10 에 라우터를 통제된 방식으로 다시 올렸다. 네트워크는 01:15 부터 안정됐고, 보건위원회들은 02:08 에 서비스가 복구됐다고 확인했다."},"trigger":{"en":"At 16:30 a route map change was applied, outside formal change control, on a PSBA core Provider Edge (PE) router to leak MPLS VPN routes, so that legacy Capita-operated UPS devices in a /16 subnet could be managed by BT/PSBA. The change was removed at 16:40.","ko":"2026년 3월 25일 16:30 에 Capita 가 운영하던 레거시 UPS 장비를 BT/PSBA 관리로 옮기려고 PSBA 코어 Provider Edge 라우터의 route map 을 바꾸는 구성 변경을 적용했다. 이 변경은 정식 변경 관리를 거치지 않았다. 변경은 16:40 에 되돌렸지만 그 라우터가 default route 를 계속 잘못 광고했다."},"severity":"unknown","symptoms":["network-unreachable","intermittent-connection-failures","link-flapping"],"timeline":{"detected_after":"18m","resolved_after":"8h 35m"},"date_kind":"incident","detection":{"en":"At 16:57 Mid Wales Fire & Rescue Service phoned in a loss of connectivity at its Presteigne site, and at 16:58 a case was opened in Service Now for a group of about 400 alerts and a Major Incident was declared.","ko":"16:57 에 Mid Wales Fire & Rescue Service 가 Presteigne 사이트의 연결이 끊겼다고 전화했다. 16:58 에 모니터링 시스템이 묶어 보낸 경보로 Service Now 에 CS0287201 건이 열렸다. 그때 경보는 400개가 넘어 Major Incident 가 선언됐다."},"components":["bgp"],"root_cause":"config-change","remediation":[{"text":{"en":"Removed the route map change from the PE router at 16:40","ko":"16:40 에 네트워크 변경을 되돌렸다."}},{"text":{"en":"Changed QoS on the BGP to bring back the management links, after which alarms cleared","ko":"22:00 에 Technical Design Architect 가 BGP 의 QoS 를 바꿔 관리 접속을 되살렸고, 경보가 줄기 시작했다."}},{"text":{"en":"Cleared routes and reset inbound BGP advertisements, which did not stop the default route being advertised","ko":"경로를 지우고 inbound BGP 광고를 리셋했지만, default route 는 계속 잘못 광고됐다."}},{"text":{"en":"Corrected the configuration issue affecting the internet learned route at 01:02","ko":"01:02 에 인터넷에서 학습한 경로에 영향을 주던 구성 문제를 찾아 고쳤다."}},{"text":{"en":"Performed a controlled reload of the affected router at 01:10, which restored customer services and management connectivity","ko":"영향을 받은 라우터를 통제된 방식으로 다시 올렸고, 고객 서비스와 PSBA 관리 연결이 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Reinforce change control requirements with an internal briefing on formal change submission, the risks of unplanned changes and roles during planned and emergency changes","ko":"내부 브리핑으로 변경 관리 요구 사항을 다시 강조한다. 브리핑에서는 정식 변경 제출과 승인의 중요성, 계획에 없던 변경이 서비스 안정성과 고객에게 주는 위험, 계획 변경과 긴급 변경 때의 역할과 책임을 다룬다."}},{"text":{"en":"Create a dedicated Microsoft Teams channel as the single real-time communication point for all live P1 and Major Incidents","ko":"진행 중인 모든 Major Incident 에 쓰는 P1 / Major Incident 전용 Microsoft Teams 채널을 만든다. 이 채널을 서비스 데스크, 2nd·3rd line 팀, Incident Manager, 관련 이해관계자가 실시간으로 소통하는 단일 창구로 쓴다."}},{"text":{"en":"Explore disaster recovery and business continuity test exercises for major or P1 incidents","ko":"재해 복구와 업무 연속성 시험 훈련을 도입하는 것을 검토한다. 이 훈련으로 조직이 큰 장애와 P1 장애에 더 잘 대비하게 한다. 또 지금의 절차를 확인하고, 빈틈을 찾고, 장애 대응을 더 일관되게 한다."}},{"text":{"en":"During loss of management access, have all technical teams assess customer impact from what reporting organisations provide, captured and shared in real time by the Service Desk and Incident Management","ko":"관리 접속을 잃은 동안에는 참여한 모든 기술 팀이 신고한 기관이 준 정보로 고객 영향을 판단한다. 서비스 데스크와 장애 관리 담당은 고객이 알린 영향받은 사이트, 증상, 시각을 기록하고 확인해 모든 해결 담당 그룹에 실시간으로 나눈다. 도구나 관리 접속을 쓸 수 없을 때는 고객이 알린 영향을 근거로 문제를 풀고 판단한다."}},{"text":{"en":"Investigate a fixed link between Capital Quarter and the PSBA management racks in Vantage Data Centre at Newport, with dedicated management terminals and two-factor authentication for access outside the secure management platform","ko":"Capital Quarter 와 Newport 의 Vantage Data Centre 안 관리 랙 사이에 고정 링크를 까는 것을 검토한다. 전용 관리 단말과 이중 인증을 두어 secure management platform 인 SSP 밖에서도 네트워크에 접근해 상태를 확인할 수 있게 한다. 보안 설계와 승인이 갖춰지면 원격 작업자도 이 단말을 쓰게 할 수 있다."}},{"text":{"en":"Improve initial triage with stronger probing questions when incidents are reported and keep reassessing and communicating impact throughout the incident","ko":"장애를 접수할 때 묻는 질문을 강화해 첫 분류를 개선한다. 장애 내내 영향을 계속 다시 판단하고 알리도록 강조해, 근본 원인 분석을 더 정확하고 빠르게 한다."}},{"text":{"en":"Review the P1 and Major Incident process so escalation criteria and timeframes are clearly defined, and train the Service Desk to recognise and escalate them early","ko":"P1 / Major Incident 절차를 검토해 에스컬레이션 기준과 시간을 분명히 정한다. 서비스 데스크 교육으로 P1 / Major Incident 상황을 일찍 알아보고 정한 절차대로 바로 에스컬레이션하게 한다."}},{"text":{"en":"Review the PSBA estate for legacy configuration, set processes and timeframes for removing it and add controls so it is not introduced again","ko":"PSBA 네트워크 전체를 검토해 레거시 구성을 찾아 평가한다. 레거시 구성을 지우는 절차와 기한을 정하고, 앞으로 레거시 구성이 들어오거나 남아 있지 않도록 막는 통제를 둔다."}},{"text":{"en":"Review email and SMS distribution lists and processes and reinforce Service Desk training on customer communications during P1 and Major Incidents","ko":"메일과 문자 공지의 배포 목록과 절차를 검토해 정확하고 빠짐없게 한다. 서비스 데스크 교육을 강화해 P1 과 Major Incident 때 고객 공지가 일관되고 분명하며 제때 알맞은 대상에게 가게 한다."}}],"contributing":["revert-did-not-restore","review-missed","limited-debug-access","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"On 25 March 2026 from about 16:40, public sector organisations on the PSBA network across Wales lost connectivity at their sites. The Service Desk saw about 400 alerts at 16:58, when a Major Incident was declared, about 1,500 at 17:05 and about 5,000 across Wales at 17:08, while councils, a fire and rescue service and Natural Resources Wales phoned in to report sites down.\n\nCustomers described intermittent connectivity, complete loss of internet service at some locations, loss of network access and problems signing in. DHCW reported the loss of the default route from the data centre and VPN problems at 17:10, which was first handled as a separate case. Carmarthen had lost default routing at about 17:00. In the PSBA network, a customer VRF with the route target import 64627:16 could have its own default route overridden, which shows up as lost or degraded internet connectivity.\n\nAt the same time the engineers lost reliable management access. The core devices were reachable, but management access to both NAT devices kept dropping because BGP peering to the secure management platform was lost, and the two PSBA management links, Cardiff and Bangor, kept flapping. Sessions lasted less than 30 seconds, so 3rd line could only make brief checks, found no faults, and reported that the network looked stable and that troubleshooting had to wait for the management links.\n\nThe early investigation did not connect the outage to a routing change made and removed shortly before, because the flapping management links looked like the problem. Circuit checks on the management links and the circuit supplier found no faults, and the team also checked whether a major service outage in the London area was related; it was not.","ko":"2026년 3월 25일 16:57 부터 웨일스 곳곳의 기관이 사이트 연결이 끊겼다고 서비스 데스크에 전화했다. 16:58 에 모니터링 시스템에 경보가 400개 넘게 떠 Major Incident 가 선언됐다. 경보는 17:05 에 약 1,500개, 17:08 에 웨일스 전역에서 약 5,000개로 늘었다.\n\n고객은 사이트가 내려갔다, 연결이 느리다, 인터넷이 가끔 또는 완전히 끊긴다, 네트워크에 접근할 수 없다, 로그인이 안 된다고 알렸다. DHCW 는 17:10 에 데이터 센터에서 오는 default route 가 사라졌고 VPN 에 문제가 있다고 알렸다. 그러나 그때는 이 신고를 Major Incident 와 관련 없는 것으로 보고 2nd line 지원 팀에 따로 넘겼다. Carmarthen 은 17:00 무렵 default routing 을 잃었다가 나중에 안정됐다.\n\n3rd line 지원 팀은 CORE 장비에는 접근할 수 있었지만, secure management platform 과의 BGP peering 이 끊겨 두 NAT 장비의 관리 접속이 불안정했다. 장비 연결이 끊겼다 붙기를 되풀이하는 flapping 때문에 접속은 한 번에 30초도 가지 않았다. 짧게 붙은 동안 할 수 있었던 제한된 점검으로는 문제를 찾지 못했다. Cardiff 와 Bangor 의 관리 링크는 18:06 에도 끊겼다 붙기를 되풀이하고 있었다.\n\n3rd line 지원 팀은 처음에 관리 쪽 문제로 보고 관리 링크 복구를 기다렸다. 두 관리 링크가 끊겼다 붙기를 되풀이하는 것이 보였기 때문에, 이 문제를 앞선 구성 변경과 연결 짓지 않았다. PSBA 네트워크는 안정돼 보였기 때문에 고객이 알린 문제를 확인할 수 없었다.\n\n18:45 에 관리 링크 회선을 점검했지만 결함이 없었다. 18:55 에 확인한 회선 공급업체의 시스템에도 문제나 경보가 없었다. 런던 지역에서 진행 중이던 major service outage 인 MSO 와 관련이 있는지도 살폈다. 그러나 19:20 에 MSO 팀은 웨일스 사이트가 영향을 받지 않았다고 확인했다.\n\n22:00 에 BGP 의 QoS 를 바꾸자 관리 접속이 돌아오고 경보가 줄어 22:27 에는 한 자릿수가 됐다. 그러나 22:45 와 23:15 에 보건위원회들은 나아진 것이 없다고 했다."},"updated_at":"2026-11-14T12:34:05.143867Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0400","org_slug":"psba"}