{"id":"IL-0361","org":"SEEK","date":"2021-12-10","docs":[],"title":{"en":"Job searches on seek.com.au failed for 16 minutes as a Transit Gateway silently dropped 9001-byte packets","ko":"VPC 피어링을 Transit Gateway 로 옮기던 중 seek.com.au 의 구직 검색이 16분 동안 오류를 냈다"},"domain":["aws","networking"],"impact":{"scope":"Job searches on seek.com.au returned errors","users":"some users searching for jobs on seek.com.au","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A transit gateway has a smaller MTU than a same-region peering connection, drops oversized packets silently and clamps the MSS only on packets that cross it. When a migration leaves the two directions of a TCP connection on different paths, the clamp lands on the wrong side of the handshake and large packets are lost; the fix is not to send packets larger than 8500 bytes.","ko":"SEEK 는 피어링 연결과 Transit Gateway 의 MTU 가 다르다는 중요한 정보를 마이그레이션 전에 알지 못했다. Transit Gateway 가 큰 패킷을 알리지 않고 버린다는 사실은 AWS 의 Transit Gateway 할당량 문서에 적혀 있었지만, SEEK 는 이것이 할당량이라기보다 더 찾기 쉬운 곳에 있어야 할 기본 정보라고 봤다. SEEK 는 이 장애로 MTU, MSS, AWS 관리형 네트워크 장비의 세부 동작을 많이 배웠다. 장애에서 얼마나 배우는지는 장애의 심각도보다 근본 원인을 이해하려는 호기심과 의지에 달려 있다고 보았다."},"related":[],"sources":[{"url":"https://medium.com/seek-blog/beware-of-transit-gateways-bearing-large-packets-77702c4c1b20","kind":"blog","archived":"https://web.archive.org/web/20251116011230/https://medium.com/seek-blog/beware-of-transit-gateways-bearing-large-packets-77702c4c1b20"}],"summary":{"en":"SEEK had connected its AWS VPCs with peering connections, one per pair of VPCs, and was moving them onto a transit gateway that every VPC attaches to once. The cutover was planned in three steps: attach both VPCs to the transit gateway with no routes, change the routing table of the first VPC to use the transit gateway, then change the second. Between the second and third steps, packets from VPC A went to VPC B over the peering connection while packets from VPC B came back over the transit gateway. SEEK did not know before the migration that the two paths have different MTUs: a peering connection in the same region has an MTU of 9001, while a transit gateway has an MTU of 8500, drops larger packets without an ICMP 'Fragmentation Needed' reply, so path MTU discovery does not work, and clamps the MSS of every packet that crosses it. In AWS, Elastic Network Interfaces (ENIs) appear to default to an MTU of 9001.\n\nEvery mechanism that normally handles a small MTU on the path failed. TCP always sets the 'Don't Fragment' bit, so the transit gateway could not fragment the packets, and it sent no ICMP message for path MTU discovery. MSS clamping only helps when both handshake packets are clamped: the SYN from VPC A crossed the peering connection unchanged and told VPC B it could send 9001-byte packets, while only the SYN ACK from VPC B was clamped to 8500. VPC A therefore sent packets that fit, but VPC B sent 9001-byte packets that the transit gateway dropped. When the peering connection that handled search traffic for seek.com.au was migrated, large search responses stopped arriving, and the team rolled back the migration; the outage lasted 16 minutes. SEEK then confirmed the mechanism in a test setup and lowered the MTU of its EC2 instances to 8500.","ko":"SEEK 는 AWS 의 VPC 사이 트래픽 흐름을 바꾸는 마이그레이션을 하고 있었다. VPC 피어링은 VPC 쌍마다 연결이 하나씩 필요해서 VPC 가 늘면 연결 수가 n² 으로 늘어난다. SEEK 는 모든 VPC 를 Transit Gateway 하나에 붙여 연결 수를 n 으로 줄이려 했다. 중단 없이 옮기려고 세 단계를 짰다. 두 VPC 를 경로 없이 Transit Gateway 에 붙이고, 첫 VPC 의 라우팅 테이블을 Transit Gateway 로 바꾸고, 그다음 둘째 VPC 의 라우팅 테이블을 바꾸는 순서였다. 둘째 단계와 셋째 단계 사이에는 VPC 를 나가는 경로와 들어오는 경로가 달라진다.\n\nSEEK 가 마이그레이션 전에 몰랐던 것은 두 경로의 MTU 가 다르다는 점이었다. MTU 는 네트워크 장비가 다룰 수 있는 가장 큰 IP 패킷의 바이트 크기다. 같은 리전 안 피어링 연결의 MTU 는 9001 이고 Transit Gateway 의 MTU 는 8500 이며, AWS 의 ENI 도 기본 MTU 가 9001 로 보였다. Transit Gateway 는 8500 바이트보다 큰 패킷을 버린다. FRAG_NEEDED ICMP 응답을 만들지 않으므로 경로 MTU 탐색을 지원하지 않고, 모든 패킷에 MSS 클램핑을 강제한다. MSS 는 TCP 연결의 양쪽이 각자 받고 싶은 가장 큰 TCP 세그먼트 크기를 알리는 헤더 값이다. MSS 클램핑은 중간 장비가 SYN 이나 SYN ACK 의 MSS 를 자기 MTU 에 맞게 고쳐 써서 상대가 작은 패킷을 보내게 하는 방식이다.\n\nTCP 는 항상 'Don't Fragment' 비트를 켜므로 라우터가 패킷을 쪼갤 수 없었다. Transit Gateway 는 ICMP 'Fragmentation Needed' 를 보내지 않으므로 경로 MTU 탐색도 동작하지 않았다. MSS 는 협상이 아니라 양쪽이 각자 알리는 값이어서, 클램핑은 연결 양쪽의 패킷이 모두 클램핑될 때만 통한다. 이번에는 VPC A 가 보낸 SYN 이 피어링 연결을 지나 MSS 9001 그대로 VPC B 에 닿았고, VPC B 가 보낸 SYN ACK 만 Transit Gateway 에서 8500 으로 클램핑됐다. 그래서 VPC A 는 8500 바이트 이하로 보냈지만 VPC B 는 9001 바이트 패킷을 보냈고, Transit Gateway 가 이 패킷을 버렸다. 이때 옮기던 것이 seek.com.au 검색 트래픽을 처리하는 피어링 연결이었고, 결과가 많은 검색은 큰 패킷 여러 개를 보내야 했다. SEEK 는 검색이 동작하지 않는 것을 꽤 빨리 알아채고 마이그레이션을 롤백했으며, 장애는 16분 이어졌다. 그 뒤 같은 구성을 다시 만들고 패킷을 캡처해 원인을 확인했다."},"trigger":{"en":"In the second step of the migration, SEEK changed the routing table of the first VPC to use the transit gateway while the second VPC still routed over the peering connection, so the two directions of each connection took different paths.","ko":"SEEK 는 VPC 피어링 연결에서 Transit Gateway 로 옮기는 절차의 둘째 단계로 첫 VPC 의 라우팅 테이블만 Transit Gateway 를 쓰게 바꿨다. 이 상태에서는 VPC A 에서 나가는 패킷은 피어링 연결로, VPC B 에서 나가는 패킷은 Transit Gateway 로 가서 오가는 경로가 달라졌다."},"severity":"unknown","symptoms":["high-error-rate","packet-loss","intermittent-timeouts"],"timeline":{"detected_after":null,"resolved_after":"16m"},"date_kind":"published","detection":{"en":"The team noticed soon after the routing change that search on seek.com.au was not working.","ko":"마이그레이션 도중 SEEK 는 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다."},"components":["interconnect"],"root_cause":"config-change","remediation":[{"text":{"en":"Rolled back the migration of the search traffic's peering connection to the transit gateway","ko":"검색이 동작하지 않는 것을 보고 피어링 연결에서 Transit Gateway 로 옮기던 마이그레이션을 롤백했다."}}],"action_items":[{"text":{"en":"Lower the MTU of EC2 instances to 8500, on Amazon Linux 2 with a script at /sbin/ifup-local that runs whenever a network interface comes up","ko":"SEEK 환경의 EC2 인스턴스 MTU 를 8500 으로 낮춰 8500 바이트보다 큰 패킷을 보내지 않게 한다. Amazon Linux 2 에서는 네트워크 인터페이스가 올라올 때마다 인터페이스 이름을 인자로 받아 실행되는 /sbin/ifup-local 스크립트를 두어 인스턴스의 기본 MTU 를 8500 으로 덮어쓴다."}}],"contributing":["limit-unknown","default-config-unchanged","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"In May 2021 some users of seek.com.au got errors when they searched for jobs, for 16 minutes. SEEK was in the middle of moving the traffic between two VPCs, the one that carried searches, from a VPC peering connection to an AWS Transit Gateway, and the team noticed quickly that search was broken.\n\nSearches that return many results, such as all jobs in Melbourne, need several large packets in the response. In SEEK's later reproduction with EC2 instances, a transit gateway and a peering connection, an HTTP request from VPC A for a large file served from VPC B hung. Packet captures on both sides showed the machine in VPC B sending a 9001-byte packet that never reached VPC A, followed by endless TCP retransmission.\n\nThe transit gateway gave no sign of the drops. It does not send an ICMP 'Fragmentation Needed' reply for packets that are too large, and there are no metrics for the dropped packets. The only evidence came from the transit gateway attachment metrics: the 'packets in' count at the attachment of one VPC was roughly twice the 'packets out' count at the attachment of the other VPC.","ko":"2021년 5월 seek.com.au 에서 구직 검색을 하던 일부 사용자가 오류를 받았고, 장애는 16분 이어졌다. SEEK 는 검색 트래픽을 처리하던 피어링 연결을 Transit Gateway 로 옮기던 중이었고, 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.\n\n‘멜버른의 모든 일자리’ 같은 검색은 결과가 많아서 응답을 9001 바이트 단위의 큰 패킷 여러 개로 나눠 보내야 했다. 이런 큰 패킷이 상대에게 닿지 않았다.\n\nTransit Gateway 는 MTU 8500 보다 큰 패킷을 조용히 버리고 ICMP 'Fragmentation Needed' 패킷을 보내지 않는다. 버려진 패킷을 보여 주는 지표도 없었다. SEEK 는 한 VPC 쪽 Transit Gateway 어태치먼트의 'packets in' 수가 다른 VPC 쪽 어태치먼트의 'packets out' 수의 약 두 배인 것을 Transit Gateway 지표에서 보고서야 패킷이 버려지고 있음을 알았다.\n\nSEEK 는 EC2 인스턴스, Transit Gateway, 피어링 연결 구성을 똑같이 만들어 원인을 확인했다. VPC A 에서 VPC B 의 머신이 http 로 제공하는 큰 파일을 요청하면 요청이 멈췄다. 양쪽에서 패킷을 캡처해 보니 VPC B 의 머신이 보낸 9001 바이트 패킷은 VPC A 의 머신에 끝내 도착하지 않았고, TCP 재전송이 끝없이 이어졌다."},"updated_at":"2026-11-14T12:34:01.421469Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0361","org_slug":"seek"}