{"id":"IL-0263","org":"GitHub","date":"2012-11-30","docs":[],"title":{"en":"GitHub was slow and erroring all day and down for 18 minutes as links between access and aggregation switches saturated","ko":"새 애그리게이션 스위치로 옮기는 작업 뒤 데이터센터 스위치 사이 링크가 포화되어 GitHub 가 하루 종일 느렸고 18분 동안 완전히 멈췄다"},"domain":["networking"],"impact":{"scope":"GitHub: 18 minutes of complete unavailability and sporadic slow responses and intermittent errors for the whole day; one fileserver pair offline for a large part of the day","users":"all GitHub users during the 18 minutes of downtime; a small percentage of repositories on the offline fileserver pair","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"GitHub had designed the maintenance to have no impact on customers and clearly failed, so it plans to invest in a staging copy of its network to test such changes and catch bugs like this one. During the response the team fixated for a long time on a bridge loop, which kept it from considering other causes. GitHub had a very positive experience with the vendor's support staff, so it will contact that support team at the first sign of network trouble.","ko":"GitHub 는 고객에게 영향이 없도록 설계한 점검 작업이 결국 고객에게 영향을 줬다고 인정했다. 장애 대응 중에 브리지 루프라는 생각에 오래 매달려 다른 원인을 보지 못했고, 그래서 한 가지 가설에 갇히는 것을 더 경계해야 한다고 했다. GitHub 는 공급사 지원팀과 일한 경험이 좋았다며, 앞으로는 문제 조짐이 처음 보일 때 바로 지원팀에 연락하겠다고 했다."},"related":[],"sources":[{"url":"https://github.blog/news-insights/the-library/network-problems-last-friday/","kind":"blog","archived":"https://web.archive.org/web/20261003045537/https://github.blog/news-insights/the-library/network-problems-last-friday/"}],"summary":{"en":"GitHub's switches had been connected each to the switches in neighbouring racks, so traffic across the network passed through every switch in between, saturating the links in the middle of the chain. Actions that should take under a millisecond had been taking several times that long, with spikes of hundreds of times. To fix this GitHub bought aggregation switches for a tree topology in which access switches in each cabinet connect directly to the aggregation switches. Each server is connected to two redundant switches, A and B, so the plan was to disconnect, reconfigure and reconnect the B switches first, which was done on Thursday 29 November with only small hiccups, and the A switches on Friday morning.\n\nConnecting the last A switch caused a bridge loop from a misconfiguration on that switch pair, and the switches disabled links; GitHub fixed it quickly and completed the migration. The links between access and aggregation switches were then saturated, which GitHub took to be a broadcast storm from an undetected loop. While hunting for it by disconnecting single links, GitHub found that a setting meant to detect partial link failure, by checking that both transmit and receive work, is not supported between its aggregation and access switch models: shutting down one link made this watchdog trigger falsely and disable all the links, and losing several switches at once during this troubleshooting caused the 18 minutes of downtime. With the vendor's help the setting was removed, after which any single switch could be removed without affecting servers.\n\nStill unable to find a loop, GitHub escalated again to the network vendor, which raised the case to its highest severity. Five hours of troubleshooting on Friday night found a bug in the aggregation switches: they could not learn a large share of MAC addresses and flooded frames for those addresses to all ports, saturating the access-to-aggregation links. In a maintenance window on Saturday morning at 0600 Pacific, GitHub restarted some core processes on the aggregation switches so they could learn MAC addresses again, and traffic and performance returned to normal. The vendor found the root cause of the MAC learning issue from GitHub's diagnostic data and was expected to ship a fix.","ko":"GitHub 의 네트워크는 각 스위치가 옆 랙의 스위치와 이어진 구조였다. 그래서 반대쪽 끝까지 가는 데이터가 가운데 스위치들을 모두 지나야 했고, 가운데 링크가 포화되곤 했다. GitHub 는 이를 풀려고 애그리게이션 스위치가 각 캐비닛의 액세스 스위치와 바로 이어지는 트리 구조의 애그리게이션 네트워크를 만들기로 했다. 서버는 저마다 A, B 두 스위치에 이어져 있었다. GitHub 는 11월 29일 목요일에 B 스위치를 먼저 옮겼고, 큰 문제는 없었다.\n\n11월 30일 금요일 아침 A 스위치를 하나씩 옮기다가 마지막 스위치에서 설정 오류로 브리지 루프가 생겨 같은 캐비닛의 B 스위치와 연결이 끊겼다. 이를 빨리 고쳐 이전을 마쳤지만 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 상태였다. 엔지니어들은 이를 브리지 루프가 일으킨 브로드캐스트 스톰으로 보고 그날 대부분을 루프를 찾는 데 썼다. 엔지니어들은 링크를 하나씩 끊어 보다가 공급사와 함께 다른 문제를 찾았다. 두 링크 사이의 부분 링크 장애를 감지하는 설정이 이 애그리게이션 스위치와 액세스 스위치 모델 조합에서는 지원되지 않아서, 링크 하나를 끊으면 모든 링크를 꺼 버렸다. 18분 동안의 완전한 중단은 이 조사 중에 여러 스위치와 연결이 한꺼번에 끊기면서 났다. 이 설정을 지우자 페일오버는 기대대로 작동했다.\n\n몇 시간을 더 찾아도 설정 문제가 나오지 않자 GitHub 는 네트워크 공급사에 다시 에스컬레이션했다. 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 함께 조사했다. 금요일 밤 다섯 시간의 조사 끝에 애그리게이션 스위치의 버그가 원인으로 드러났다. 스위치가 MAC 주소의 상당 부분을 학습하지 못해서 그 주소로 가는 트래픽을 모든 포트로 플러딩했고, 이 트래픽이 액세스 스위치와 애그리게이션 스위치 사이 링크를 모두 채웠다. 태평양 시간 토요일 오전 6시의 점검 시간에 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습시켰고, 트래픽과 성능이 정상으로 돌아왔다. 파일 서버 한 쌍은 이 네트워크 문제가 고가용성 클러스터링에 영향을 줘서 하루 대부분 내려가 있었다."},"trigger":{"en":"On the morning of 30 November GitHub moved the A switches in its server cabinets onto the new aggregation switches, the second half of a migration whose B-switch half had been done the day before.","ko":"새 애그리게이션 스위치를 들이려고 액세스 스위치를 떼어 설정을 바꾸고 다시 연결하는 작업을 했다. 11월 30일 아침 A 스위치를 옮기던 중 마지막 스위치에서 브리지 루프가 생겼다."},"severity":"unknown","symptoms":["high-latency","high-error-rate","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Engineers saw the problems during the maintenance itself: connectivity to the B switch was lost as the last A switch was connected, and afterwards performance stayed low and the links between access and aggregation switches showed as completely saturated.","ko":"마지막 A 스위치를 연결할 때 같은 캐비닛의 B 스위치와 연결이 끊겼다. 문제를 고친 뒤에도 성능이 기대만큼 나오지 않아 들여다보다가 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 것을 봤다."},"components":["network-switch","network-link"],"root_cause":"software-bug","remediation":[{"text":{"en":"Fixed the bridge-loop problem and returned the affected B switch to service","ko":"마지막 A 스위치에서 난 첫 문제를 빨리 해결하고, 영향받은 B 스위치를 다시 서비스에 넣어 이전을 마쳤다."}},{"text":{"en":"Removed the partial link failure detection setting from the access switches","ko":"액세스 스위치에서 잘못된 설정을 지웠다. 그 뒤로는 링크를 시험해도 페일오버가 기대대로 작동했고, 애그리게이션 계층이나 액세스 계층의 스위치 하나를 빼도 서버에 영향이 없었다."}},{"text":{"en":"Escalated to the network vendor, which raised the case to its highest severity level","ko":"몇 시간을 더 찾아도 설정 문제가 나오지 않자 네트워크 공급사에 다시 에스컬레이션했고, 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 바로 함께 조사했다."}},{"text":{"en":"Restarted core processes on the aggregation switches in a Saturday 0600 Pacific maintenance window so they learned MAC addresses again","ko":"태평양 시간 토요일 오전 6시에 네트워크 점검 시간을 잡고 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습하게 했다. 이 우회책이 통해서 트래픽과 성능이 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Deploy the vendor's software update that fixes the MAC learning issue to the switches","ko":"공급사가 MAC 학습 문제의 근본 원인을 찾았고, 1주일쯤 안에 최종 수정이 나오면 스위치에 소프트웨어 업데이트를 배포한다."}},{"text":{"en":"Closely monitor aggregation-to-access capacity and keep a workaround process ready if the problem returns","ko":"그때까지 애그리게이션 계층과 액세스 계층 사이 용량을 면밀히 지켜보고, 문제가 다시 나면 쓸 우회 절차를 둔다."}},{"text":{"en":"Build a duplicate of the network stack, from the routers through the access switches, as a staging environment for testing such changes","ko":"라우터부터 액세스 계층 스위치까지 네트워크 스택을 똑같이 한 벌 더 갖춰 스테이징 환경으로 쓰고, 이런 변경을 미리 더 충분히 시험한다."}},{"text":{"en":"Add automated network monitoring that alerts sooner on similar issues","ko":"비슷한 문제가 생기면 더 빨리 알림을 받도록 네트워크에 자동 모니터링을 더한다."}},{"text":{"en":"Run scheduled incident response exercises with scenarios that counter tunnel vision","ko":"앞으로 몇 달 동안 정기적인 장애 대응 훈련을 늘리고, 한 가지 가설에 매달리지 않도록 하는 시나리오를 만든다."}},{"text":{"en":"Contact the network vendor's support at the first sign of trouble in the network","ko":"앞으로는 네트워크에 문제 조짐이 처음 보일 때 바로 공급사 지원팀에 연락한다."}}],"contributing":["overlapping-failures","assumption-unverified","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"On Friday, 30 November 2012, GitHub had sporadic bursts of slow responses and intermittent errors for the whole day and was completely unavailable for 18 minutes. One fileserver pair was offline for a large part of the day, which affected a small percentage of repositories; this was a side effect of the network problems on the high-availability clustering between the fileserver nodes.\n\nThe problems began during a planned migration of the datacenter switches to a new aggregation network. When the final A switch was connected, GitHub lost connectivity with the B switch in the same cabinet: a misconfiguration on that pair of switches had caused a \"bridge loop\", and the switches disabled links to protect the network. After that was fixed and the migration completed, performance stayed below expectations, and all of the connections between the access switches and the aggregation switches were completely saturated.\n\nEngineers diagnosed the saturation as a \"broadcast storm\" from a bridge loop that had gone undetected, and spent most of the day auditing switch configurations port by port. While disconnecting single access-to-aggregation links to narrow the problem down, they found that taking down one link of a redundant pair made the access switch disable its redundant link too, so the network could not survive the loss of an aggregation switch. With the switch vendor they found the cause: a setting meant to detect partial link failure is not supported between the aggregation and access switch models, and shutting down one link made it falsely disable all the links. The 18 minutes of hard downtime happened during this troubleshooting, when connectivity to several switches was lost at the same time. After that setting was removed, a couple more hours of testing links found no loop.\n\nThe cause turned out to be different. In a five-hour investigation with the switch vendor on Friday night, GitHub found that the aggregation switches were missing many MAC addresses from their MAC address tables and could not learn a significant share of them, so they flooded traffic for those devices to every port. That flooded traffic was enough to saturate all of the links between the access and aggregation switches.","ko":"2012년 11월 30일 금요일, GitHub 는 18분 동안 완전히 접속이 안 됐고, 하루 종일 응답이 이따금 느려지고 오류가 간헐적으로 났다. 파일 서버 한 쌍이 하루 대부분 내려가 있어 일부 저장소가 영향을 받았다.\n\n그날 아침 GitHub 는 새 애그리게이션 스위치로 옮기는 작업의 두 번째 단계로 각 캐비닛의 A 스위치를 하나씩 옮기고 있었다. 마지막 A 스위치를 연결하자 같은 캐비닛의 B 스위치와 연결이 끊겼다. 이 스위치 한 쌍의 설정 오류가 브리지 루프를 만들었고, 스위치는 설정대로 문제를 감지한 링크를 꺼서 네트워크를 보호했다.\n\n이 문제를 고쳐 이전을 끝낸 뒤에도 성능이 기대만큼 나오지 않았다. 들여다보니 액세스 스위치와 애그리게이션 스위치를 잇는 링크가 전부 꽉 차 있었다.\n\n엔지니어들은 이것을 감지되지 않은 브리지 루프가 일으키는 브로드캐스트 스톰으로 판단했다. 그날 대부분을 스위치 설정을 다시 점검하고 포트를 하나하나 살피며 루프를 찾는 데 썼다. 범위를 좁히려고 액세스 스위치와 애그리게이션 스위치 사이 링크를 하나씩 끊어 봤다.\n\n링크를 끊어 보다가 다른 문제가 드러났다. 이중으로 묶인 링크 하나를 끊는 순간 액세스 스위치가 짝이 되는 다른 링크까지 꺼 버렸다. 애그리게이션 스위치 하나가 고장 나면 버틸 수 없다는 뜻이었다. 공급사와 함께 원인을 찾아보니, 부분 링크 장애를 감지하려고 켜 둔 설정이 문제였다. 이 설정은 이 애그리게이션 스위치와 액세스 스위치 모델 조합에서는 지원되지 않아서, 링크 하나를 끊으면 모든 링크를 꺼 버렸다. 18분 동안의 완전한 중단은 이 조사 도중 여러 스위치와 연결이 한꺼번에 끊기면서 생겼다.\n\n이 설정을 지운 뒤 링크를 계속 시험했지만 몇 시간이 지나도 설정에서 문제를 찾지 못했다. 엔지니어들은 여전히 루프가 원인인 브로드캐스트 스톰이라고 믿고 있었다. 금요일 밤 공급사와 함께 다섯 시간을 조사한 끝에 애그리게이션 스위치가 MAC 주소 테이블에서 많은 주소를 빠뜨리고 그 주소로 가는 트래픽을 모든 포트로 플러딩하는 버그를 찾았다."},"updated_at":"2026-11-14T12:33:51.427082Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0263","org_slug":"github"}