{"id":"IL-0146","org":"Microsoft Azure","date":"2020-12-04","docs":["https://docs.microsoft.com/en-us/azure/aks/node-image-upgrade"],"title":{"en":"New AKS clusters with Azure CNI in Central India lost tunnel connectivity because VMs began getting MAC addresses with a 06 prefix, which exposed a dormant bug in bridge-mode Azure CNI","ko":"Central India 에서 새로 만든 Azure CNI 클러스터의 VM 이 높은 값의 MAC 주소를 받으면서 bridge 모드 Azure CNI 의 오래된 버그가 드러나 터널 연결이 끊기고 kubectl exec 와 파드 간 통신이 타임아웃됐다."},"domain":["kubernetes","azure","networking"],"impact":{"scope":"Newly created AKS clusters using Azure CNI in bridge mode; clusters using kubenet were not affected","users":"unknown","region":"Central India"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A change in how the platform assigns MAC addresses can wake a long-dormant bug in the network plugin. Knowing which CNI mode the nodes run (bridge or transparent) and keeping node images current decides whether such a bug reaches you.","ko":"VM 에 배정되는 MAC 주소 범위처럼 플랫폼 쪽에서 바뀐 값 하나가 오래 드러나지 않던 CNI 버그를 드러낼 수 있다. 같은 증상이라도 노드의 MAC 주소와 CNI 모드를 함께 봐야 영향 여부를 가를 수 있다."},"related":[],"sources":[{"url":"https://github.com/Azure/AKS/issues/2023","kind":"github","license":"unknown","archived":null}],"summary":{"en":"From about 00:00 UTC on 4 December 2020 to 00:10 UTC on 15 December 2020, newly created AKS clusters with Azure CNI in Central India could have tunnel connectivity problems. VMs in the region began to receive MAC addresses with a 06 prefix instead of the usual 00, and that revealed a bug in Azure CNI that had been dormant for a long time. The newest Azure CNI, which no longer uses a bridge, was not affected.\n\nThe AKS team published a way to check each node with az vmss run-command (or az vm run-command for availability sets) for the MAC address and the CNI mode. The fix was to get the newer CNI: on scale sets a node image upgrade, or any Kubernetes upgrade such as a patch version; on availability sets, scaling out and deleting the affected VMs; for a brand-new cluster, recreating it. A hotfix to make transparent mode the default in all regions was in progress; existing clusters still had to be upgraded.","ko":"2020년 12월 4일 00:00 UTC 무렵부터 12월 15일 00:10 UTC 무렵까지 Central India 에서 Azure CNI 로 새로 만든 클러스터에 터널 연결 문제가 생길 수 있었다. kubenet 을 쓰는 클러스터는 영향이 없었다.\n\n이 리전의 VM 들이 이전보다 훨씬 높은 값의 MAC 주소를 받기 시작했다. 평소에는 00 으로 시작했는데 이번에는 06 으로 시작하는 주소가 나왔다. 그러자 Azure CNI 에서 오랫동안 드러나지 않던 버그가 나타났다. 이 버그는 bridge 모드에서만 문제가 됐고, 더 이상 bridge 를 쓰지 않는 최신 Azure CNI 는 영향을 받지 않았다.\n\nMicrosoft 는 VMAS 클러스터에는 클러스터를 늘린 뒤 영향을 받은 VM 을 지우라고 안내했다. VMSS 클러스터에는 노드 이미지를 업그레이드해 최신 CNI 를 받는 방법이 가장 안전하다고 권했다. 쿠버네티스 패치 버전 업그레이드로도 고칠 수 있었고, 막 만든 클러스터라면 다시 만드는 것도 방법이었다. 이미 있는 클러스터는 이 절차로 직접 업그레이드해야 했다."},"trigger":{"en":"VMs in Central India started being assigned MAC addresses in a much higher range than before (06 prefix rather than the usual 00).","ko":"Central India 의 VM 들이 평소처럼 00 으로 시작하는 MAC 주소가 아니라 06 으로 시작하는, 훨씬 높은 값의 MAC 주소를 받기 시작했다."},"severity":"unknown","symptoms":["intermittent-timeouts"],"timeline":{"detected_after":null,"resolved_after":"11d 10m"},"date_kind":"incident","detection":null,"components":["azure-cni","node-image"],"root_cause":"software-bug","remediation":[{"text":{"en":"told owners of affected scale-set clusters to run a node image upgrade, or any Kubernetes upgrade such as a patch version, to get the Azure CNI that does not use a bridge","ko":"VMSS 클러스터 사용자에게 노드 이미지 업그레이드나 패치 버전 업그레이드 같은 쿠버네티스 업그레이드로 bridge 를 쓰지 않는 Azure CNI 를 받으라고 안내했다."}},{"text":{"en":"told owners of availability-set clusters to scale out and delete the VMs with a high-range MAC address in bridge mode","ko":"VMAS 클러스터 사용자에게 클러스터를 늘린 뒤 MAC 주소 값이 높고 bridge 모드로 동작하는 VM 을 지우라고 안내했다."}},{"text":{"en":"advised recreating affected clusters that were brand new","ko":"영향을 받은 클러스터가 막 만든 것이라면 다시 만들라고 안내했다."}}],"action_items":[{"text":{"en":"Roll out a hotfix that makes transparent mode the default in all regions","ko":"transparent 모드를 모든 리전의 기본값으로 만드는 핫픽스를 배포한다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"In newly created AKS clusters using Azure CNI in Central India, kubectl exec and kubectl logs could time out, and pod-to-pod or pod-to-node traffic could time out. The cluster diagnostics page showed tunnel exec issues. Clusters using kubenet were not affected.\n\nOn an affected node, ip addr show eth0 showed a MAC address beginning link/ether 60:45:.. and /etc/cni/net.d/10-azure.conflist showed \"mode\":\"bridge\". A node with link/ether 00:0d:.. in bridge mode, or 60:45:.. in \"mode\":\"transparent\", was not affected.","ko":"2020년 12월 4일 00:00 UTC 무렵부터 Central India 에서 Azure CNI 로 새로 만든 AKS 클러스터에 터널 연결 문제가 생겼다. 진단 페이지에는 터널 exec 문제가 표시됐다.\n\nkubectl exec 와 kubectl logs 가 타임아웃될 수 있었다. 파드와 파드 사이, 파드와 노드 사이의 통신도 타임아웃될 수 있었다. kubenet 을 쓰는 클러스터는 영향을 받지 않았다.\n\n영향을 받았는지는 노드에서 `ip addr show eth0 && cat /etc/cni/net.d/10-azure.conflist` 를 실행해 확인할 수 있었다. VMSS 는 `az vmss run-command invoke`, VMAS 는 `az vm run-command invoke` 로 같은 명령을 돌릴 수 있었다. 출력에 `link/ether 60:45:..` 와 `\"mode\":\"bridge\"` 가 함께 나오면 영향을 받은 노드였다. `link/ether 00:0d:..` 이면서 bridge 모드이거나, `link/ether 60:45:..` 이면서 `\"mode\":\"transparent\"` 이면 영향을 받지 않았다."},"updated_at":"2026-11-10T00:00:36.047826Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0146","org_slug":"microsoft-azure"}