{"id":"IL-0590","org":"Mailgun","date":"2014-09-27","docs":["http://www.rackspace.com/blog/an-apology/"],"title":{"en":"F5 load balancers cached a path MTU of 296 after Rackspace reboots, and Mailgun connections failed intermittently","ko":"Rackspace ORD 재부팅 뒤 Mailgun 연결이 간헐적으로 실패하고 이벤트 유실과 이메일 중복 발송이 났다"},"domain":["networking"],"impact":{"scope":"Connections to Mailgun: intermittent connection failures, events lost between 2:30 a.m. and 7:00 a.m. UTC, and approximately 100,000 duplicate emails sent","users":"A portion of Mailgun customers, including Rackspace dedicated customers using Mailgun","region":"Rackspace Chicago data center (ORD); internal traffic between Mailgun's environments in all regions"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://www.mailgun.com/blog/mailgun-post-mortem-september-2014/","kind":"blog","archived":"https://web.archive.org/web/20211027131746/https://www.mailgun.com/blog/mailgun-post-mortem-september-2014/"}],"summary":{"en":"Mailgun runs several environments in multiple Rackspace data centers on a hybrid cloud setup in which F5 load balancers are the primary gateway for all incoming and outgoing connections. During outages or maintenance Mailgun moves traffic between environments by changing the load balancing ratios of F5 virtual IP pools, without DNS changes. On Friday, September 26, Rackspace told Mailgun it would reboot cloud instances in ORD between Sunday, September 28, 11:00 a.m. UTC and Monday, September 29, 11:00 a.m. UTC. Mailgun prepared to switch traffic away from ORD, but on September 27 its database replicas and the traffic between environments started timing out, and Mailgun could not find why before the reboots began.\n\nThe cloud maintenance put Mailgun's F5 servers into an error condition in which they reported a path MTU of 296 for the IPs on Mailgun's networks, and the F5s of all Rackspace dedicated customers using Mailgun cached that value. The servers behind those F5s could only send packets with a minimum MTU of 512, while Mailgun's F5 enforced the smaller value, so packets were lost. The Rackspace networking team cleared the caches on Mailgun's F5s and on some dedicated customers' F5s and set up a new virtual IP for Mailgun services, and Mailgun changed DNS settings, which forced the remote F5s to clear their caches. Mailgun said all messages reported as accepted during the outage were delivered. When the post was written, Mailgun and Rackspace were still investigating the root cause of the unusually low path MTU value.","ko":"Mailgun 은 Rackspace 하이브리드 클라우드의 여러 데이터 센터에 환경을 두고, F5 로드 밸런서를 데이터 센터로 들어오고 나가는 모든 연결의 관문으로 쓴다. 장애나 유지 보수 때는 F5 virtual IP 풀로 트래픽을 다른 환경으로 옮겨 DNS 변경 없이 고객 영향을 피한다. 9월 26일 금요일 Rackspace 는 9월 28일 일요일 11:00 UTC 부터 9월 29일 월요일 11:00 UTC 사이에 ORD 의 클라우드 인스턴스를 재부팅한다고 알렸다. Mailgun 은 ORD 트래픽을 옮길 준비를 하다가 9월 27일 18:50 UTC 에 데이터베이스 복제와 환경 사이 내부 트래픽이 타임아웃으로 끊긴 것을 발견했다. 재부팅 전까지 원인을 찾지 못해 트래픽을 제때 옮기지 못했다.\n\n재부팅은 9월 30일 월요일 01:10 UTC 에 시작됐고, 11:29 UTC 까지 간헐적 연결 실패와 이벤트 유실과 약 100,000건의 중복 발송이 이어졌다. Mailgun 이 Rackspace 기업 네트워크 팀과 함께 조사한 결과, 클라우드 유지 보수가 Mailgun F5 서버에 오류 상태를 일으켜 Mailgun 네트워크의 IP 에 Path MTU 를 296 으로 보고하게 만들었다. Mailgun 을 쓰는 Rackspace 전용 고객의 F5 가 모두 이 값을 캐시했다. 그 F5 뒤의 서버는 최소 512 MTU 의 패킷만 보낼 수 있었는데, Mailgun 의 F5 가 더 작은 값을 강제해 패킷이 손실됐다. Rackspace 네트워크 팀이 F5 캐시를 지우고 새 virtual IP 를 만들고, Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시를 비우게 하자 남은 문제가 풀렸다. 근본 원인은 글을 쓸 때 아직 조사 중이었고, Mailgun 의 F5 로드 밸런서가 처음 캐시하고 강제한 비정상적으로 낮은 path MTU 값과 관련이 있다는 데까지 밝혀졌다."},"trigger":{"en":"Rackspace, Mailgun's parent company and hosting provider, rebooted cloud instances in its Chicago data center (ORD), and the cloud maintenance triggered an error condition on Mailgun's F5 load balancers.","ko":"Rackspace 가 시카고 데이터 센터 ORD 의 클라우드 인스턴스를 재부팅한 유지 보수가 Mailgun 의 F5 서버에 오류 상태를 일으켰다."},"severity":"unknown","symptoms":["intermittent-connection-failures","intermittent-timeouts","packet-loss"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Mailgun noticed at 6:50 p.m. UTC on September 27 that all database replicas and the internal traffic between its environments were broken and reporting timeouts.","ko":"9월 27일 18:50 UTC 에 ORD 트래픽 전환을 준비하던 Mailgun 이 모든 데이터베이스 복제와 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 발견했다."},"components":["cloud-load-balancer","database-replication"],"root_cause":"dns-network","remediation":[{"text":{"en":"The Rackspace networking team cleared the cached path MTU on Mailgun's F5s and on some Rackspace dedicated customers' F5s","ko":"Rackspace 네트워크 팀이 Mailgun 의 F5 와 일부 Rackspace 전용 고객의 F5 에서 캐시를 지웠다."}},{"text":{"en":"Set up a new virtual IP for Mailgun services","ko":"Rackspace 네트워크 팀이 Mailgun 서비스용 새 virtual IP 를 만들었다."}},{"text":{"en":"Changed Mailgun's DNS settings, which forced the remote F5s to clear their caches","ko":"Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시가 강제로 비워지게 했다."}}],"action_items":[{"text":{"en":"Finish the root cause analysis of the F5 path MTU problem with Rackspace","ko":"Rackspace 와 함께 F5 문제의 근본 원인을 계속 조사한다."}},{"text":{"en":"Make sure maintenance of Mailgun's cloud infrastructure has no impact on Mailgun customers","ko":"근본 원인 분석을 마치면 클라우드 인프라 유지 보수가 Mailgun 고객에게 영향을 주지 않도록 조치한다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"On Saturday, September 27, 2014 at 6:50 p.m. UTC, Mailgun saw that all its database replicas and the internal traffic between its environments in all regions were broken and reporting timeouts. Once Rackspace began rebooting cloud instances in its Chicago data center (ORD), Mailgun customers had intermittent connection failures.\n\nThe reboots began at 1:10 a.m. UTC on September 30, and from then until 11:29 a.m. UTC customers saw intermittent connection failures, events were lost between 2:30 a.m. and 7:00 a.m. UTC, and approximately 100,000 duplicate emails were sent. A portion of Mailgun customers kept having intermittent connection loss and failures through the afternoon of Tuesday, September 30.\n\nMailgun had prepared to move traffic away from the ORD environment before the reboots, but it could not find the cause of the timeouts before the reboots started, so traffic was not moved in time. The source of the problem was found later, together with the Rackspace enterprise networking team.","ko":"2014년 9월 27일 토요일 18:50 UTC 에 Mailgun 은 모든 데이터베이스 복제와 모든 리전의 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 알아챘다. 그때 Mailgun 은 Rackspace 의 ORD 재부팅을 앞두고 트래픽을 다른 환경으로 옮길 준비를 하고 있었다.\n\nRackspace 의 시카고 데이터 센터 ORD 에서 클라우드 인스턴스 재부팅이 9월 30일 월요일 01:10 UTC 에 시작됐다. 그때부터 11:29 UTC 까지 연결이 간헐적으로 실패했고, 02:30 UTC 부터 07:00 UTC 사이의 이벤트가 유실됐으며, 이메일 약 100,000건이 중복 발송됐다. 이 동안 수락됐다고 보고된 메시지는 모두 전달됐다.\n\n일부 고객은 9월 30일 화요일 오후까지 간헐적인 연결 끊김과 실패를 계속 겪었다. 마지막까지 남은 문제는 Mailgun 을 쓰는 Rackspace 전용 고객 쪽에 있었다.\n\nMailgun 은 재부팅이 시작되기 전까지 타임아웃의 원인을 찾지 못해, 고객에게 영향이 가기 전에 트래픽을 옮기지 못했다."},"updated_at":"2026-11-14T12:34:23.619588Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0590","org_slug":"mailgun"}