{"id":"IL-0568","org":"DeNA","date":"2026-04-14","docs":[],"title":{"en":"A layer 2 loop after an access switch change broke network traffic across a whole DeNA site, with mass MACFLAP logs","ko":"DeNA의 한 사업장에서 L2 스위치 루프가 생겨 사업장 전체의 단말이 서버에 접속하지 못하거나 통신이 느려졌다"},"domain":["networking"],"impact":{"scope":"The network of one of DeNA's largest sites; terminals of a customer-facing system could not reach their servers or were very slow, affecting the business of the whole site","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Any change can cause an outage, through a mistake, an unexpected event or a bug, so changes need to be scheduled with a maintenance window agreed in advance. A change on a downstream access switch can affect the whole site. Changing many devices at once made it slow both to find the faulty device and to roll back, and the parts that can be prevented by mechanisms rather than by people's care, such as reviews and monitoring, should be enforced that way.","ko":"말단 장비 한 대라도 사업장 전체에 영향을 줄 수 있다. 작업 실수, 예상 못 한 상황, 버그 같은 이유로 작업 중에는 언제든 장애가 날 수 있으므로, 미리 일정을 맞춰 유지보수 시간을 확보해야 한다. 여러 대를 한꺼번에 바꾸면 원인 장비를 찾고 되돌리는 데 시간이 걸린다. 만일에 대비해 미리 준비하고, 사람이 아니라 구조로 막을 수 있는 부분은 막아야 한다. 지금이라면 로그를 AI에게 보여 주고 원인을 바로 찾을 수 있었을 것이다. 이번 같은 장애에는 AI의 사전 리뷰와 장애 상황 분석이 효과가 있었을 것이다."},"related":[],"sources":[{"url":"https://engineering.dena.com/blog/2026/04/lacp-network-failure/","kind":"blog","archived":"https://web.archive.org/web/20260516174724/https://engineering.dena.com/blog/2026/04/lacp-network-failure/"}],"summary":{"en":"DeNA's network group runs the networks of more than 20 sites of DeNA and its subsidiaries. A project to manage the settings of every site's switches in one uniform configuration included small changes, such as aligning the rate of ip dhcp snooping limit rate 100 and the description format. The engineer saw the work as minor, did not announce it to the site and did not schedule it around the site's hours; the site, unlike an office, was open for business at 19:00. The engineer configured 15 Cisco Catalyst 2960L switches remotely in bulk and was fine-tuning them one by one. Minutes after the start, the command that removes the allowed VLAN list, which permits all VLANs, went onto only one of the two ports of the LACP link aggregation between the most downstream switch SW3 and SW2. LAG member ports must have matching settings, and the expected result was that the mismatched link would go down; instead a loop formed and spread beyond SW3 to the whole site.\n\nThe site reported the outage at about 20:00. Without knowing which change was at fault, the engineer started rolling back; with many devices and changes and no prepared rollback procedure this took about 30 minutes, and service recovered at about 21:00 when the interface setting of one switch was restored. By about 22:00 the cause had been found and no other impact remained. Monitoring had missed the problem because the port's interface monitoring had never been configured, LACP monitoring had been dropped by an earlier mistake in a monitoring change, warning logs and a CPU rise of about 10% stayed below alert thresholds, and the final resource check had not yet been reached.\n\nLab tests later found that the loop happened only with specific models. Between 2960C pairs, 2960S pairs and 2960C with 2960S the LAG suspended the port and traffic on it stopped, but with SW2 as a 2960C or 2960S and SW3 as a 2960L, frames passed through a port that showed Status: up, Protocol: down and ifOperStatus=2, matching the incident. Because the port was Protocol: down, STP treated it as down and did not manage it, so the healthy link kept forwarding and the misconfigured link was not blocked, leaving two active links. The 2960L was end of life, no bug report was found and it ran the latest version; the team concluded that the problem lay in operations rather than the device and did not replace it.","ko":"DeNA 네트워크 그룹은 사업장마다 손으로 설정해 온 장비 설정을 모든 사업장에서 통일하고 구성 관리하는 프로젝트를 진행하고 있었다. 엔지니어는 평일 19시쯤 원격으로 한 사업장의 L2 스위치 Cisco Catalyst 2960L 15대에 description 수정, VLAN 정의 추가, Trunk 포트의 허용 VLAN 추가 같은 작업을 시작했다. 엔지니어는 가벼운 작업으로 여겨 시간대도 고려하지 않았고 작업 공지도 하지 않았다. 이 사업장은 DeNA가 운영하는 20곳이 넘는 사업장 가운데 특히 큰 곳이었고 오피스가 아니어서 그 시간에도 영업 중이었다. 작업을 시작하고 몇 분 뒤, SW1-SW2-SW3 순서로 이어진 구성에서 가장 아래에 있는 SW3의 LAG를 이루는 물리 포트 Gi0/15 하나에만 no switchport trunk allowed vlan 이 들어갔다.\n\n20시쯤 현장에서 단말이 서버에 접속하지 못한다는 연락이 왔지만 모니터링 알림은 없었다. 대상 포트에는 처음부터 인터페이스 모니터링이 설정돼 있지 않았고, LACP 모니터링은 직전에 다른 모니터링 설정을 고치다 낸 실수로 꺼져 있었다. 스위치 CPU는 10% 정도만 올라 알림이 울리지 않았다. 21시쯤 엔지니어가 원인을 모른 채 설정을 되돌리다가 장비 한 대의 인터페이스 설정을 되돌리자 통신이 복구됐다. 여러 대를 한꺼번에 바꾼 데다 되돌리는 절차를 만들어 두지 않아 시간이 걸렸다. 22시쯤 원인 지점을 확인하고 다른 영향이 없음을 확인해 1차 대응을 마쳤다.\n\nMACFLAP이 대량으로 나와 루프가 난 것은 분명했지만, Prometheus에서 Gi0/15는 장애 중 ifOperStatus=2 로 down이었고 STP도 켜져 있었다. 실제 장비로 검증해 보니 2960C끼리 연결하거나 2960S가 낀 조합에서는 LAG가 정상적으로 suspend돼 루프가 나지 않았다. 장애 때와 같이 SW2를 2960C, SW3를 2960L로 두고 한 포트의 allowed vlan을 지우자 루프가 재현됐다. 이때 포트는 Status: up, Protocol: down 이면서 down 상태의 포트로 프레임이 지나갔다. STP가 보기에는 이 포트가 down이어서 관리 대상이 아니었고, 정상 링크와 함께 링크 두 개가 열린 상태가 됐다. 2960L은 EoL 제품이고 버그 보고도 찾지 못했으며 장애 당시 버전은 최신이었다. DeNA는 문제가 장비가 아니라 운영에 있었다고 결론 내리고 장비를 교체하지 않았다."},"trigger":{"en":"During a routine change on 15 Cisco Catalyst 2960L access switches at the site, which tidied descriptions, added VLAN definitions and added allowed VLANs on trunk ports, `no switchport trunk allowed vlan` was applied to GigabitEthernet0/15 of switch SW3, only one of the two physical ports in the LACP bundle between SW3 and SW2.","ko":"Cisco Catalyst 2960L 15대의 설정을 맞추는 작업에서, SW2와 SW3 사이 LACP LAG를 이루는 물리 포트 두 개 중 SW3 쪽 한 포트에만 no switchport trunk allowed vlan 을 넣어 허용 VLAN 지정을 지웠다."},"severity":"unknown","symptoms":["intermittent-connection-failures","high-latency"],"timeline":{"detected_after":"1h","resolved_after":"2h"},"date_kind":"published","detection":{"en":"The site reported the problem at about 20:00; no monitoring alert fired, because the affected port had no interface monitoring and LACP monitoring had been removed by an earlier monitoring change.","ko":"모니터링 알림은 울리지 않았고, 20시쯤 사업장 현장에서 단말이 통신하지 못한다는 연락을 받고 알았다. 대상 포트의 인터페이스 모니터링은 처음부터 없었고, LACP 모니터링은 꺼져 있었으며, CPU 상승은 10% 정도라 리소스 알림에 걸리지 않았다."},"components":["network-switch"],"root_cause":"human-operation","remediation":[{"text":{"en":"Rolled back the switch changes without knowing the cause; service recovered when the interface setting of one switch was restored","ko":"원인 지점을 모른 채 작업을 되돌리기 시작했고, 30분쯤 뒤 장비 한 대의 인터페이스 설정을 원래대로 되돌린 시점에 복구됐다."}},{"text":{"en":"Found the faulty port and confirmed there was no other impact, completing the first response at about 22:00","ko":"22시쯤 이어진 조사에서 원인 지점을 확인하고 다른 영향이 없음을 확인한 뒤 1차 대응을 마쳤다."}}],"action_items":[{"text":{"en":"Fix the missing interface and LACP monitoring","ko":"대상 포트에 빠져 있던 인터페이스 모니터링과 꺼져 있던 LACP 모니터링을 즉시 바로잡았다."}},{"text":{"en":"Require a review for every monitoring change","ko":"모니터링 설정 변경은 가벼운 임계값 변경까지 모두 리뷰를 거치게 했다."}},{"text":{"en":"Block merges to the alert rule repository without a reviewer's approval","ko":"알림 규칙을 정의한 리포지토리의 PR은 리뷰어 승인 없이는 머지할 수 없도록 설정을 바꿨다."}},{"text":{"en":"Enable automatic AI review on pull requests","ko":"PR에 AI 자동 리뷰를 켜서 사람 말고도 누락을 찾을 수 있게 했다."}},{"text":{"en":"Announce every network change in advance, however minor","ko":"네트워크 변경 작업은 가벼운 작업이라도 스스로 판단하지 않고 미리 공지하는 규칙으로 바꿨다."}},{"text":{"en":"Agree the work date with the site's managers and avoid the site's event days","ko":"작업 일시는 사업장 책임자 등과 일정을 맞추고, 사업장의 운영 일정을 파악해 행사일을 피한다는 규칙을 다시 확인했다."}},{"text":{"en":"Prepare rollback procedures for high-impact maintenance and for work on several devices at once","ko":"영향이 큰 유지보수나 이번처럼 여러 대를 함께 바꾸는 작업처럼 되돌릴 때 시간이 걸리는 작업은 되돌리는 절차를 미리 만든다."}}],"contributing":["monitoring-blind-spot","no-staged-rollout","no-runbook","change-in-peak-hours"],"recurrence_of":null,"symptoms_text":{"en":"At about 20:00 on a weekday, one of DeNA's largest sites reported that terminals of a customer-facing system could not communicate and business was suffering. The network group's monitoring had raised no alert.\n\nAs other network group members investigated and the site sent more reports, the picture filled in: problems at the site had started about 30 minutes before the report, which matched the time of a switch change; an unspecified number of terminals were affected, in some places the problem cleared quickly and in others it continued; terminals of the affected system could not connect to their servers or were very slow; the CPU use of the site's main switch had risen, though not enough for an alert; and the site's switches were logging large numbers of MACFLAP messages.\n\nThe first report said the cause might be the terminals and asked the network group to check the network. With no device alerts, the engineer doing the switch work at first did not think the work was involved. Even later the cause was puzzling: Prometheus showed the misconfigured port Gi0/15 as ifOperStatus=2 (down) during the incident, and STP was enabled, so no loop seemed possible.","ko":"평일 20시쯤 사업장 현장에서 고객 업무에 쓰는 특정 시스템의 단말이 통신하지 못해 영업에 문제가 생겼다는 연락이 왔다. 네트워크 그룹의 모니터링에서는 알림이 하나도 울리지 않았다.\n\n현장 연락은 단말 쪽 문제일 수도 있지만 네트워크를 확인해 달라는 내용이었다. 장비 알림이 없었기 때문에 담당 엔지니어는 첫 연락을 받았을 때 자기 작업의 영향일 가능성을 크게 보지 않았다.\n\n조사해 보니 연락을 받기 30분 전부터 사업장 안에서 장애 보고가 나오기 시작했고, 시각은 작업 시작과 맞았다. 일부 단말은 곧 풀렸지만 다른 곳에서는 계속됐고, 특정할 수 없는 여러 단말에서 문제가 났다. 장애가 난 시스템의 단말은 서버에 접속하지 못하거나 접속해도 통신이 매우 느렸다.\n\n사업장 메인 스위치의 CPU 사용률이 알림 기준에는 못 미치지만 올라가 있었고, 사업장에서 MACFLAP 로그가 대량으로 나왔다. 원인은 끝내 특정하지 못했다. 그러나 그 시간에 작업한 사람이 담당 엔지니어뿐이어서, 엔지니어는 자기 작업을 원인으로 보고 되돌리기 시작했다."},"updated_at":"2026-11-14T12:34:21.621067Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0568","org_slug":"dena"}