MAC Collision Alert!
summary
Examines the existing kubemacpool design: kubemacpool uses a webhook + controller to reserve MACs and mutate VM manifests, which prevents duplicates but blocks VM creation if the webhook or pool rejects an address, supports only one global pool and VMs, and treats collisions as rare. Proposes a reactive detection approach that lets VMs start, records the actual MAC in the manifest, monitors ARP/SDN (OVN/OVS) for collisions, and resolves them by shutting links or stopping affected VMs; the reactive solution is a proposal, not yet fully implemented.
AI-written summary · about
chapters (14)
- 0:00MAC collision alert intro
- 1:47Kubernetes MAC management
- 3:17Why MAC management matters
- 5:29MAC duplication problems
- 8:00Current MAC management solution
- 12:18Limitations of prevention
- 15:35MAC collision probability
- 15:57Reactive collision detection
- 17:22Sticky MAC addresses
- 20:13Network monitoring for collisions
- 21:38Proposed solution details
- 24:24Gaps in MAC management
- 25:51Real MAC duplication cases
- 27:57Q&A
related talks
30mFrom Frankenstein To Kamaji: Lessons in Building a Single CAPI Cluster Across Multiple Providers
37mKubernetes for Mac: How to Consume Shiny AWS Mac Shapes for iOS Builds
40mAttacking Kubernetes Clusters Through Your Network Plumbing
29mAttack of the mutant tags!
40mMangle -Systematically Introducing Chaos to Your Application
33mCAP_NET_RAW And ARP Spoofing in Your Cluster: It's Going Downhill From Here
37mProactive Kubernetes Security: Anomaly Detection and Runtime Alertin...
33mNavigating and Optimizing Karpenter - Avoiding Common Pitfalls