{"id":"IL-0336","org":"Amazon Web Services","date":"2021-09-02","docs":[],"title":{"en":"AWS Direct Connect traffic into the Tokyo Region had packet loss and intermittent connectivity for about six hours","ko":"도쿄 리전으로 가는 Direct Connect 트래픽에 패킷 손실과 간헐적인 연결 끊김이 6시간 넘게 이어졌다"},"domain":["aws","networking"],"impact":{"scope":"Direct Connect traffic from customer data centers to VPCs in the Tokyo Region; traffic between Availability Zones, internet connectivity to the Region, AWS VPN and Direct Connect traffic to other Regions were not affected","users":"Direct Connect customers connecting to the Tokyo Region","region":"Tokyo (AP-NORTHEAST-1)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://aws.amazon.com/message/17908/","kind":"official-status","archived":"https://web.archive.org/web/20260706043052/https://aws.amazon.com/message/17908/"}],"summary":{"en":"AWS Direct Connect gives customers a private connection from their own data centers to their AWS VPCs. In the Tokyo Region on 2 September 2021, a subset of network devices in one layer on the path from the Direct Connect edge locations to the Tokyo datacenter network stopped forwarding traffic correctly from 7:30 AM JST. The normal automation did not remove them. Engineers removed affected devices from service, but other devices in the layer kept failing in the same way, and resetting devices and bringing them back slowly did not hold. By 12:00 PM JST the engineers suspected a new protocol that had been introduced to shorten the network's reaction time to rare network convergence events and fiber cuts. They suspected that the protocol interacted badly with a new traffic pattern on the devices of this layer. They disabled the protocol in one Availability Zone first to confirm a lasting recovery, while preparing the same change for the whole Region. Customers reported recovery from 12:30 PM JST, and by 1:42 PM JST the devices were stable and Direct Connect worked normally.\n\nIn the following days AWS confirmed the root cause as a latent defect in the network device operating system. The operating system version that enables the new protocol, which improves the network's failover time, was first deployed to production in January 2021 and had been released gradually to all AWS Regions over 8 months without any sign of the problem. AWS had followed its usual procedure: stress tests in a dedicated lab with valid and malformed packets, then a slow production rollout on individual devices from which traffic could fail away to devices that had not been upgraded, with close monitoring. The defect needs a very specific set of packet attributes and contents, and in Tokyo customer traffic happened to produce packets matching that signature consistently. AWS states that it has no reason to suspect malicious intent. AWS disabled the protocol in Tokyo.","ko":"Direct Connect 는 고객 데이터 센터와 VPC 를 사설 연결로 잇는다. 트래픽은 AWS 가 고객과 만나는 에지 로케이션에서 여러 네트워크 계층을 거쳐 리전까지 간다. 계층마다 이중화된 장비가 많다. 일본 시간 2021년 9월 2일 오전 7시 30분, 도쿄 리전으로 가는 경로의 한 계층에서 장비 일부가 트래픽을 제대로 전달하지 못하기 시작했다. 고장 난 장비를 자동으로 빼내는 절차는 이 장비들을 빼내지 않았다. 엔지니어가 장비를 서비스에서 빼고 리셋했지만 다른 장비들이 계속 같은 고장을 일으켜 정상 용량을 지키지 못했다.\n\n낮 12시쯤 엔지니어는 장애 전환 시간을 줄이려고 넣은 새 프로토콜을 의심했다. 엔지니어는 한 가용 영역에서 먼저 이 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 고객은 낮 12시 30분부터 애플리케이션이 회복되는 것을 보기 시작했고, 오후 1시 42분에 장비들이 안정을 되찾아 Direct Connect 가 정상으로 돌아왔다.\n\n이후 조사에서 원인은 네트워크 장비 운영체제의 잠재 결함으로 확인됐다. 새 프로토콜은 이 버전의 운영체제에서 켜지는 기능이었다. 운영체제를 바꾸고 새 프로토콜을 들일 때 AWS 는 전용 실험실에서 정상 패킷과 형식이 잘못된 패킷으로 스트레스 테스트를 먼저 한다. 운영 환경에는 업그레이드한 장비에서 업그레이드하지 않은 장비로 트래픽을 쉽게 돌릴 수 있는 곳부터 천천히 배포한다. 새 운영체제와 프로토콜은 2021년 1월 처음 운영에 들어가 8개월 동안 모든 AWS 리전에 차례로 배포됐고, 그동안 결함의 징후는 없었다. 결함은 아주 특정한 패킷 속성과 내용이 있어야 드러났다. 그런데 고객 트래픽이 이 조건에 맞는 패킷을 꾸준히 만들어 냈다."},"trigger":{"en":"Customer traffic consistently generated packets with a very specific set of attributes and contents, and these packets set off a latent defect in the network device operating system on one layer of the Direct Connect network in Tokyo.","ko":"네트워크 장비 운영체제에 결함이 있었고, 이 결함은 아주 특정한 패킷 속성과 내용이 맞아야만 드러났다. 고객 트래픽이 그 조건에 맞는 패킷을 꾸준히 만들어 내 결함을 건드렸다. AWS 는 악의를 의심할 이유가 없다고 밝혔다."},"severity":"unknown","symptoms":["packet-loss","intermittent-connection-failures"],"timeline":{"detected_after":"0m","resolved_after":"6h 12m"},"date_kind":"incident","detection":{"en":"Internal alarms alerted AWS engineers to elevated packet loss for Direct Connect customers connecting to the Tokyo Region at 7:30 AM JST. The automation that monitors network devices also saw a higher rate of failed devices than normal and alerted engineers.","ko":"오전 7시 30분, 도쿄 리전에 접속하는 Direct Connect 고객의 패킷 손실 증가를 알리는 내부 알람이 AWS 엔지니어에게 울렸다. 고장 난 장비를 감시하는 자동화도 고장 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어에게 조사와 조치를 요청했다."},"components":["interconnect"],"root_cause":"software-bug","remediation":[{"text":{"en":"Removed the failing network devices from service so healthy devices carried the traffic, which helped only for a time","ko":"이 계층에 이중화가 충분하다고 보고 영향받은 장비를 서비스에서 빼, 정상 장비가 트래픽을 처리하게 했다. 잠시 나아졌지만 다른 장비들이 같은 고장을 일으켰다."}},{"text":{"en":"Reset failed devices and brought them back into service slowly, without stopping the failures","ko":"고장 난 장비를 리셋하고 천천히 서비스에 되돌려 봤지만 고장은 이어졌다."}},{"text":{"en":"Disabled the new protocol in a single Availability Zone, then across the Tokyo Region","ko":"한 가용 영역에서 먼저 새 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 그 뒤 도쿄 리전에서 새 프로토콜을 껐다."}}],"action_items":[{"text":{"en":"Apply the change carefully to all other AWS Regions, with a new way to detect and remediate the issue before customers are affected","ko":"고객 영향이 나기 전에 이 결함을 찾아 고치는 개선된 방법을 갖추고, 나머지 모든 AWS 리전에 이 변경을 조심스럽게 적용한다."}}],"contributing":["delayed-effect-change","staging-not-representative"],"recurrence_of":null,"symptoms_text":{"en":"From 7:30 AM JST on 2 September 2021, AWS Direct Connect customers saw intermittent connectivity problems and elevated packet loss on traffic going to their VPCs in the Tokyo (AP-NORTHEAST-1) Region. Internal AWS alarms on Direct Connect packet loss fired at the same time.\n\nDirect Connect carries traffic from the edge locations where AWS meets customer networks to the Region through several network layers, each with many redundant devices. The alarms pointed to several devices in a single one of those layers. The devices were not forwarding traffic correctly, yet the automation that normally takes failed network devices out of service did not remove them. The automation instead saw a higher rate of failed devices than usual and called in engineers. Traffic between Availability Zones, internet traffic to the Region, AWS VPN connections, which some customers use as a backup for Direct Connect, and Direct Connect traffic to other Regions all kept working.\n\nEngineers judged that the layer had enough redundancy and took the failing devices out of service so that healthy devices would carry the traffic. This helped only for a while: more devices then failed in the same way, and Direct Connect customers saw congestion, connectivity problems or packet loss. Resetting the failed devices and returning them to service slowly did not stop the failures, and the engineers could not keep enough healthy capacity in the layer. Engineers also looked for any recent deployment that could have set off the failure.","ko":"일본 시간 2021년 9월 2일 오전 7시 30분부터 Direct Connect 로 도쿄 리전에 접속하는 고객의 트래픽에 간헐적인 연결 문제와 패킷 손실 증가가 나타났다. 같은 시각 AWS 엔지니어는 패킷 손실 증가를 알리는 내부 알람을 받았다.\n\n알람은 Direct Connect 네트워크의 한 계층에서 장비 여러 대가 고장 난 것을 가리켰다. 이 장비들은 트래픽을 제대로 전달하지 못했는데도, 고장 난 네트워크 장비를 감시해 빼내는 평소의 자동화 절차가 이 장비들을 네트워크에서 빼내지 않았다. 자동화는 대신 고장 난 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어를 불렀다.\n\n엔지니어가 영향받은 장비를 빼자 잠시 나아졌지만, 다른 장비들이 차례로 같은 고장을 일으켰다. 고객 쪽에서는 네트워크 혼잡, 연결 문제, 패킷 손실 증가가 이어졌다. 고장 난 장비를 리셋해 천천히 서비스에 되돌려도 고장은 계속됐고, 엔지니어는 고객 영향을 막을 만큼 정상 용량을 유지하지 못했다.\n\n엔지니어는 고장을 일으켰을 만한 최근 배포를 찾았다. 낮 12시쯤 엔지니어는 드물게 일어나는 네트워크 수렴 이벤트와 광섬유 절단에 네트워크가 더 빨리 반응하도록 넣은 새 프로토콜을 의심했다. 이 프로토콜은 몇 달 전에 들어와 그동안 문제없이 돌고 있었다. 엔지니어는 이 프로토콜이 이 계층 장비들에 나타난 새 트래픽 패턴과 맞물려 고장이 났다고 봤다.\n\n가용 영역 사이의 트래픽, 리전으로 가는 인터넷 연결, 일부 고객이 Direct Connect 의 백업으로 쓰는 AWS VPN 연결은 영향을 받지 않았다. 다른 AWS 리전으로 가는 Direct Connect 트래픽도 멀쩡했다."},"updated_at":"2026-11-14T12:33:59.134585Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0336","org_slug":"amazon-web-services"}