Cases1 case

1 to 1 of 1

1. IL-0146 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

   Microsoft Azure2020

   Symptoms

   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.

   Intermittent timeouts

   Trigger

   VMs in Central India started being assigned MAC addresses in a much higher range than before (06 prefix rather than the usual 00).

   Root cause

   Software defect

   Component

   Azure CNINode operating system image

   Contributing factor

   –

   Remediation

   • 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
   • told owners of availability-set clusters to scale out and delete the VMs with a high-range MAC address in bridge mode
   • advised recreating affected clusters that were brand new

   Action items

   • Roll out a hotfix that makes transparent mode the default in all regions

   Lessons

   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.

   View case

By root cause1