{"id":"IL-0225","org":"Microsoft Azure","date":"2023-01-25","docs":["https://aka.ms/AIR/VSG1-B90"],"title":{"en":"An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss","ko":"라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다."},"domain":["azure","networking"],"impact":{"scope":"Network connectivity to Azure regions and to other Microsoft services including Microsoft 365 and Power Platform, internet, inter-region and ExpressRoute or VPN/vWAN traffic, and Azure Government services that depend on the public cloud","users":"unknown","region":"global"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=VSG1-B90","kind":"official-status","archived":null}],"summary":{"en":"The task added new routers to Microsoft's global Wide Area Network (WAN) in Madrid: it changed each new router's IP address and joined it to the IGP (Interior Gateway Protocol, which connects all routers inside the WAN) and BGP routing domains. The standard operating procedure (SOP) for such work has four steps: testing in the Open Network Emulator, testing in the lab, a Safe-Fly Review with roll-out and roll-back plans, and Safe-Deployment, which allows access to one device at a time. The SOP had been changed before this event to fix problems from earlier runs, and the changed SOP was not re-tested and lacked proper post-checks. The added command purges the IGP database: on routers from two manufacturers it runs only on the local router, on the third it orders every IGP-joined router to recompute its topology. Microsoft's AAA system approves every router command and blocks commands with global impact, but this command's global default on that router model had not been found in the evaluation of high-impact commands and was not on the block list.\n\nAlthough the engineer had access to a single router, that router was joined to the rest of the WAN through the IGP. All routers recomputed IP connectivity across the internal network, and BGP routers then readvertised and validated the prefixes received from the internet; restoring connectivity to every prefix took about 1 hour and 40 minutes. Monitoring alerted the on-call engineers within 5 minutes, but because of the unqualified SOP changes the engineer making the change was not informed and repeated the operation on the second Madrid router 33 minutes later, causing a second wave. The team reviewed recent changes and identified the command by 08:20 UTC while automatic recovery was under way. Nearly all network devices and most regions and services had recovered by 09:05 UTC, and the last network equipment by 09:25 UTC. During the event the automated systems that keep the WAN healthy, including the one that removes unhealthy devices and the traffic engineering system, had been paused, so some paths stayed unoptimised and lost packets from 09:25 UTC until those systems were restarted by hand; recovery completed at 12:43 UTC.","ko":"2023-01-25 07:08 UTC 에 한 네트워크 엔지니어가 마드리드에서 Microsoft 의 전 세계 WAN 에 용량을 더하는 작업을 했다. 이 작업에는 새 라우터마다 IP 주소를 바꾸고 IGP 와 BGP 라우팅 도메인에 넣는 단계가 들어 있었다. 이런 작업의 표준 운영 절차는 Open Network Emulator 환경에서의 시험, 랩 시험, 두 시험과 롤아웃·롤백 계획을 문서로 남기는 Safe-Fly Review, 한 번에 장비 하나만 접근하게 하는 Safe-Deployment 의 네 단계다. 이번에는 앞선 실행에서 생긴 문제를 고치려고 작업 전에 절차를 바꿨다. 하지만 바꾼 절차를 다시 시험하지 않았고 사후 점검도 넣지 않았다. 바뀐 절차에는 IGP 데이터베이스를 비우는 명령이 들어 있었다. 두 제조사의 라우터는 이 명령을 로컬 라우터에서만 실행하지만, 세 번째 제조사의 라우터는 IGP 로 이어진 모든 라우터에 토폴로지 데이터베이스를 다시 계산하라고 지시한다. 라우터마다 모든 명령을 승인하는 실시간 AAA 시스템과, 전역 영향을 주는 명령의 차단 목록이 있었다. 하지만 이 라우터 모델에서 이 명령이 기본으로 전역에 영향을 준다는 사실은 고위험 명령을 평가할 때 드러나지 않았고, 그래서 이 명령은 차단 목록에 없었다.\n\n엔지니어는 라우터 한 대에만 접근했지만 그 라우터가 IGP 로 WAN 전체와 이어져 있었다. 그래서 전 세계 라우터가 내부 네트워크 전체의 IP 연결을 다시 계산했고, 이어 BGP 라우터가 인터넷에서 받은 prefix 를 다시 광고하고 검증했다. 모든 prefix 의 연결이 돌아오기까지 약 1시간 40분이 걸렸다. 모니터링은 5분 안에 당직 엔지니어에게 알렸다. 하지만 변경하던 엔지니어는 바뀐 절차 때문에 이를 전달받지 못했고, 33분 뒤 두 번째 마드리드 라우터에 같은 작업을 해 두 번째 장애를 일으켰다.\n\n팀은 08:20 UTC 에 문제의 명령을 찾았다. 09:05 UTC 에 거의 모든 네트워크 장비와 대부분의 리전, 서비스가 회복했고, 09:25 UTC 에 마지막 장비가 회복했다. 사고 동안 비정상 장비를 찾아 빼는 시스템과 트래픽 엔지니어링 시스템 같은 WAN 상태 관리 자동화가 멈춰 있어, 일부 경로가 최적화되지 않은 채 패킷 손실이 이어졌다. 이 시스템들을 손으로 다시 시작해 12:43 UTC 에 복구를 마쳤다."},"trigger":{"en":"A network engineer adding capacity to the global WAN in Madrid ran a step of a recently changed standard operating procedure that purged the IGP database; on the router manufacturer involved, that command runs on all IGP-joined routers instead of only the local one.","ko":"07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다."},"severity":"unknown","symptoms":["high-latency","intermittent-timeouts","intermittent-connection-failures","packet-loss","network-unreachable"],"timeline":{"detected_after":"3m","resolved_after":"5h 35m"},"date_kind":"incident","detection":{"en":"Monitoring detected DNS and WAN issues from 07:11 UTC and alerted the on-call engineers within 5 minutes of the command being run. The team reviewed all recent changes and identified the command by 08:20 UTC. The engineer making the change was not informed of the alerts because of the unqualified changes to the SOP.","ko":"모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다."},"components":["backbone-network","igp-routing","bgp"],"root_cause":"config-change","remediation":[{"text":{"en":"Restarted by hand the paused WAN health and traffic engineering systems, which ended the remaining packet loss","ko":"WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다."}}],"action_items":[{"text":{"en":"Audit and block similar widespread-impact commands across all three vendors for all WAN router roles","ko":"세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다."}},{"text":{"en":"Give on-call engineers real-time visibility of approved and unqualified activity on network devices","ko":"승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다."}},{"text":{"en":"Run regular mandatory operational training and attestation of following all SOPs","ko":"정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다."}},{"text":{"en":"Have the Change Advisory Board review all SOPs still pending qualification within 30 days","ko":"아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다."}}],"contributing":["no-config-tests","assumption-unverified","blast-radius-too-wide","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"From 07:08 UTC on 25 January 2023, customers saw long network latency and timeouts when connecting to resources in Azure regions and to other Microsoft services such as Microsoft 365 and Power Platform. Microsoft's monitoring detected DNS and WAN issues from 07:11 UTC.\n\nThe impact changed as routing converged across the network: some customers had intermittent connectivity, some saw connections time out, and others had long latency or lost connectivity completely. It hit traffic to and from the internet, traffic between regions, cross-premises traffic over ExpressRoute or VPN/vWAN, and Azure Government services that depend on the public cloud.\n\nAlerts reached the on-call engineers within 5 minutes of the command, but the engineer making the change was not told. The same operation was run on a second router in Madrid 33 minutes after the first, which sent a second wave of connectivity issues through the network. Because of the size of the network, restoring connectivity to every prefix took about 1 hour and 40 minutes. Responders began by reviewing all recent changes and identified the command at 08:20 UTC while automatic recovery was under way.\n\nMost regions and services recovered by 09:05 UTC and the last network equipment by 09:25 UTC, but parts of the network kept above-normal packet loss, and two routers could not recover automatically. Traffic crossing the regions in India and parts of North America recovered last, at 12:43 UTC.","ko":"2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.\n\n라우팅 불안정은 인터넷을 오가는 트래픽, 리전 사이 트래픽, ExpressRoute 나 VPN/vWAN 을 거친 온프레미스 연결, Azure 공용 클라우드에 기대는 US Gov Cloud 서비스에 모두 나타났다. 라우팅이 자동으로 수렴하는 동안 고객이 겪는 영향은 계속 바뀌었다. 어떤 고객은 연결이 끊겼다 이어지기를 반복했고, 어떤 고객은 연결 타임아웃을 겪었고, 다른 고객은 지연이 길어지거나 연결이 완전히 끊겼다.\n\n장애는 두 차례에 걸쳐 일어났다. 변경하던 엔지니어는 알림을 전달받지 못했고, 첫 변경 33분 뒤 마드리드의 두 번째 라우터에 같은 작업을 다시 했다. 네트워크 규모 때문에 모든 prefix 의 연결이 돌아오기까지 약 1시간 40분이 걸렸다.\n\n대부분의 리전과 서비스는 09:05 UTC 까지 회복했고 마지막 네트워크 장비는 09:25 UTC 에 회복했다. 그 뒤에도 네트워크 일부 구간에서 평소보다 높은 패킷 손실이 이어졌고, 자동으로 회복하지 못한 라우터 두 대 때문에 일부 고객은 간헐적인 연결 문제를 계속 겪었다. 인도 리전과 북미 일부를 지나는 트래픽이 가장 늦게 회복했다.\n\n팀은 최근 변경을 모두 살피는 것으로 조사를 시작했고, 자동 회복이 진행되던 08:20 UTC 에 장애를 일으킨 명령을 찾았다."},"updated_at":"2026-11-14T05:53:44.126944Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0225","org_slug":"microsoft-azure"}