{"id":"IL-0532","org":"Microsoft Azure","date":"2022-06-28","docs":["https://azure.microsoft.com/blog/advancing-safe-deployment-with-aiops-introducing-gandalf/"],"title":{"en":"Azure Software Load Balancer sent packets of one flow to different backends, dropping Firewall and Private Link traffic","ko":"Azure Software Load Balancer 뒤의 백엔드가 15개를 넘는 로드 밸런서에서 연결이 간헐적으로 끊기고 패킷이 사라졌다"},"domain":["azure","networking"],"impact":{"scope":"Connections to resources behind the Software Load Balancer for Azure Firewall deployments with more than 15 backend instances and for service endpoint and Private Link connections to services with more than 15 DIPs, such as SQL and Storage","users":"A subset of Azure customers","region":"14 regions for the Azure Firewall scenario, three regions for the service endpoint and Private Link scenario"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Microsoft wrote that the incident showed the need for more thorough end-to-end monitoring during safe deployments.","ko":"이번 장애로 Safe Deployment Practices 로 배포하는 동안 더 철저한 종단 간 모니터링이 필요하다는 것이 확인됐다."},"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=YVTL-RS0","kind":"official-status","archived":null}],"summary":{"en":"Azure's Software Load Balancer (SLB) routes and load balances all network traffic within Azure datacenters and clusters. It is a set of servers called multiplexers, or MUXs, grouped into SLB scale units. Each scale unit hosts many VIPs and directs their traffic to the DIPs, the IPs of the resources behind each VIP, that health probes show to be in service. The order in which a MUX stores the DIPs decides which backend receives a given connection. A change in the latest SLB code deployment made some MUX instances store the DIPs in a different order, but only for load balancers with more than 15 DIPs in the backend pool. Traffic that crossed more than one MUX could be sent to a different backend at each MUX.\n\nThat happened in two ways. Azure Firewall is a stateful firewall that scales out behind an Azure Load Balancer and pins each flow to one instance, so when the incoming and return paths of a flow crossed different MUXs, its packets reached different firewall instances and were dropped. Private Link and service endpoint traffic also had a changed flow identifier in an IPv6 packet routing header, so when a connection moved from one MUX to another after a routing change in the physical network, the new MUX forwarded it to a different backend server, which rejected it. Telemetry showed a small rise in errors and customers opened support requests, but because the failures were intermittent, the health checks of Safe Deployment Practices did not tie these signals to the change, and the code reached 14 regions before the impact was correlated with it. Separately, an independent Azure WAN incident (YKDK-TT8) overlapped in time.\n\nEngineers first mitigated the VIPs of customers identified as impacted by hand. In parallel engineers built a hotfix that could be applied without further impact to traffic, tested it and rolled it out in phases under Safe Deployment Practices, and ran automation that scanned all VIPs every five minutes and fixed any VIP in an inconsistent state until the hotfix was fully deployed. Consistent ordering of backend instances was restored to the state before the incident, and impact ended at 04:00 UTC on 1 July 2022.","ko":"Software Load Balancer 는 Azure 데이터센터와 클러스터 안의 모든 네트워크 트래픽의 라우팅과 부하 분산을 맡는 소프트웨어 서비스다. 멀티플렉서, 줄여서 MUX 라고 부르는 서버들이 모여 스케일 단위 하나를 이룬다. 스케일 단위마다 로드 밸런서의 프런트엔드 IP 인 VIP 를 많이 두고, MUX 가 각 VIP 뒤의 목적지 IP 들로 트래픽을 보낸다. 목적지 IP 의 순서는 어떤 연결을 어느 백엔드 서버가 받을지 고르는 과정과 바로 묶여 있다.\n\n최신 코드 배포에 든 변경 하나 때문에, 백엔드 풀에 목적지 IP 가 15개를 넘는 로드 밸런서에서 일부 MUX 인스턴스가 목적지 IP 를 다른 순서로 저장했다. 이 순서 차이는 MUX 를 둘 이상 거치는 트래픽에 영향을 주었다. 하나는 들어오는 길과 돌아가는 길 모두 방화벽을 거치는 트래픽이었다. Azure Firewall 은 Azure Load Balancer 를 써서 수평으로 늘어나는 상태 기반 방화벽이다. 방화벽은 흐름을 인스턴스에 고정하기 때문에, 한 흐름의 패킷이 다른 인스턴스에 닿으면 버려졌다. 다른 하나는 물리 네트워크의 경로가 바뀌어 연결이 다른 MUX 로 옮겨 가는 경우였다. Private Link 와 서비스 엔드포인트 트래픽이 쓰는 IPv6 패킷 라우팅 헤더의 흐름 식별자가 바뀌었다. 그래서 연결이 MUX 사이를 옮겨 갈 때 새 MUX 가 백엔드 풀의 다른 서버로 연결을 보냈고, 그 서버가 요청을 거부했다.\n\nAzure 는 Safe Deployment Practices 라는 단계별 배포 체계로 변경을 내보낸다. 텔레메트리에서 오류가 조금 늘고 고객 지원 요청이 들어왔지만, 실패가 간헐적이어서 헬스 체크가 이 신호를 최근 변경과 연결하지 못했다. 그사이 코드는 60개가 넘는 리전 가운데 14개 리전에 퍼졌다. 엔지니어들은 여러 조사와 완화 작업을 나란히 진행했다. 먼저 영향을 받은 것으로 확인된 고객의 VIP 를 손으로 완화했다. 이어서 고객 트래픽에 영향을 주지 않고 적용할 수 있는 핫픽스를 만들어 테스트한 뒤 단계적으로 배포했다. 핫픽스가 퍼지는 동안에는 5분마다 모든 VIP 를 검사해 상태가 어긋난 VIP 를 완화하는 자동화를 돌렸다. 백엔드 인스턴스의 순서는 장애 전처럼 일관되게 되돌렸다. 장애는 2022-07-01 04:00 UTC 에 끝났다."},"trigger":{"en":"A new SLB code deployment, rolled out through Safe Deployment Practices, made some MUX instances store the backend DIPs of load balancers with more than 15 DIPs in a different order.","ko":"Software Load Balancer 에 배포한 최신 코드의 변경 하나 때문에, 백엔드 풀에 목적지 IP 가 15개를 넘는 로드 밸런서에서 일부 MUX 인스턴스가 목적지 IP 를 다른 순서로 저장했다."},"severity":"unknown","symptoms":["intermittent-connection-failures","packet-loss","requests-misrouted"],"timeline":{"detected_after":null,"resolved_after":"70h 34m"},"date_kind":"incident","detection":{"en":"Telemetry showed a small increase in errors and customers raised support requests, but the health checks of Safe Deployment Practices did not correlate these intermittent signals with the deployment until the code had reached 14 regions.","ko":"텔레메트리에서 오류가 조금 늘었고 고객 지원 요청도 여러 건 들어왔지만, 실패가 간헐적이어서 헬스 체크가 이 신호를 최근 배포와 연결하지 못했다. 고객 영향을 이 배포와 연결했을 때 코드는 이미 14개 리전에 퍼져 있었다."},"components":["cloud-load-balancer"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Mitigated the VIPs of customers identified as impacted with targeted manual operations","ko":"원인을 파악하는 동안 먼저 영향을 받은 것으로 확인된 고객의 VIP 를 골라 손으로 완화했다."}},{"text":{"en":"Built and tested a hotfix and rolled it out in phases under Safe Deployment Practices","ko":"고객 트래픽에 더 영향을 주지 않고 적용할 수 있는 핫픽스를 만들어 테스트했고, Safe Deployment Practices 에 따라 단계적으로 배포했다."}},{"text":{"en":"Ran automation that scanned all VIPs every five minutes and fixed VIPs in an inconsistent state until the hotfix was out","ko":"핫픽스가 퍼지는 동안 5분마다 모든 VIP 를 검사해 상태가 어긋난 VIP 를 완화하는 자동화를 만들어, 오래 유지할 완화책이 다 배포될 때까지 돌렸다."}},{"text":{"en":"Restored consistent ordering of the backend instances to the state before the incident","ko":"백엔드 인스턴스의 순서를 장애 전처럼 일관되게 되돌렸다."}}],"action_items":[{"text":{"en":"Add Azure Firewall monitoring that detects when the upstream and downstream packets of one flow do not reach the same DIP","ko":"Azure Firewall 에서 한 흐름의 오가는 패킷이 같은 목적지 IP 에 닿지 않는 경우를 잡는 모니터링을 더한다."}},{"text":{"en":"Keep the IPv6 flow identifier consistent for the lifetime of a connection so all its packets land on one MUX","ko":"IPv6 흐름 식별자가 연결이 이어지는 동안 바뀌지 않도록 고쳐서 한 연결의 모든 패킷이 MUX 하나에 닿게 한다."}},{"text":{"en":"Improve packet capture support for firewalls","ko":"Azure Firewall 에 방화벽 전용 패킷 캡처 지원을 더해 이런 문제를 더 빨리 찾고 완화하게 한다."}},{"text":{"en":"Add logging of TCP flows, including invalid packets and RST, FIN and FIN-ACK packets","ko":"Azure Firewall 의 TCP 흐름 로그를 늘려 잘못된 패킷과 RST, FIN, FIN-ACK 패킷을 기록해 문제를 더 잘 좁히게 한다."}},{"text":{"en":"Onboard more Azure services to the Gandalf AIOps solution suite for end-to-end monitoring during safe deployments","ko":"Safe Deployment Practices 로 배포하는 동안 종단 간 모니터링을 늘리려고 더 많은 Azure 서비스가 내부 AIOps 도구인 Gandalf 를 쓰도록 서두른다."}}],"contributing":["early-signal-ignored"],"recurrence_of":null,"symptoms_text":{"en":"From 05:26 UTC on 28 June 2022, some Azure customers saw intermittent network failures and packet loss when connecting to resources behind a Software Load Balancer (SLB). Telemetry showed a small increase in errors and customers raised support requests, but the failures were intermittent and were not linked to a recent deployment at first.\n\nTwo kinds of load balancer frontend IPs (VIPs) were hit. The first was Azure Firewall deployments with more than 15 destination IP addresses (DIPs) behind an Azure Load Balancer, where the upstream and downstream packets of one flow must land on the same DIP; packets of one flow reached different firewall instances and were dropped. This scenario affected services in 14 regions. The second was service endpoint or Private Link connections to a service in the region with more than 15 DIPs, for example SQL or Storage; when a connection moved from one MUX to another, the new MUX sent it to a different backend server, which rejected the request. This scenario affected services in three regions.\n\nCorrelating the customer reports with the platform took longer because the number of instances behind the internal load balancer of an Azure Firewall depends on each customer's traffic pattern, and not every firewall's load balancer had more than 15 instances. By the time customer impact was correlated with the deployment, the code had reached 14 of more than 60 regions. Impact continued until 04:00 UTC on 1 July.","ko":"고객 일부가 Software Load Balancer 뒤의 리소스에 연결할 때 네트워크 실패와 패킷 손실이 간헐적으로 났다. 장애는 2022-06-28 05:26 UTC 부터 2022-07-01 04:00 UTC 까지 이어졌다.\n\n영향은 두 경우에 몰렸다. 첫째는 Azure Firewall 고객이었다. 이 고객의 방화벽은 Azure Load Balancer 뒤에 목적지 IP 가 15개를 넘었고, 한 흐름의 오가는 패킷이 늘 같은 목적지 IP 에 닿아야 했다. 이 경우는 14개 리전에서 났다. 둘째는 SQL 이나 Storage 처럼 리전 안에서 목적지 IP 가 15개를 넘는 서비스에 서비스 엔드포인트나 Private Link 엔드포인트로 연결하는 고객이었다. 이 경우는 세 리전에서 났다.\n\nMUX 는 Software Load Balancer 를 이루는 멀티플렉서 서버다. Azure Firewall 의 경우에는 한 흐름의 패킷이 서로 다른 방화벽 인스턴스에 닿아 버려졌다. Private Link 와 서비스 엔드포인트의 경우에는 연결이 한 MUX 에서 다른 MUX 로 옮겨 가면 새 MUX 가 연결을 백엔드 풀의 다른 서버로 보냈고, 그 서버가 요청을 거부했다.\n\n텔레메트리에서는 오류가 조금 늘었고 고객 지원 요청도 여러 건 들어왔다. 실패가 간헐적이어서 헬스 체크는 이 신호를 최근 배포와 연결하지 못했다. 방화벽 내부 로드 밸런서 뒤의 인스턴스 수는 고객의 트래픽 패턴에 따라 정해지고, 모든 방화벽이 15개를 넘지는 않는다. 그래서 고객이 알린 문제와 플랫폼 동작을 연결하는 데도 시간이 걸렸다."},"updated_at":"2026-11-14T12:34:17.518906Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0532","org_slug":"microsoft-azure"}