Schlagwort-Archive: MAC Address collision

Virtuelle Maschine sporadisch nicht erreichbar

Gestern erreichte mich ein Problem, dass nach dem Umbau div. Hyper-V Singlehosts zwei virtuelle Maschinen auf einem neuen Host sporadisch nicht mehr erreichbar waren. Die Umgebung bestand aus div. HP Procuve Switchen incl. einem L3 Switch sowie div. HP Proliant DL Servern. Die Hyper-V Hosts hatten Windows Server 2008 R2 Enterprise und die virtuellen Maschinen Windows Server 2008 R2 Standard.

Ein Dauerping auf eine der betroffenen virtuellen Maschinen zeigte sporadische Timeouts.

Das riecht nach Troubleshooting. Beginnen wir mit dem Layer 1 – nachdem die Verkabelung zum betroffenen Singlehost geprüft und die Zuordnung der virtuellen Netze im Hyper-V Manager geprüft war ging direkt auf die nächste Ebene. Da es nach einem Netzwerkproblem aussieht (sogar ICMPs gehen nicht durch) könnte der Fehler bereits im Layer 2 liegen.

Gesagt getan, erster Punkt, pingen vom Routerinterface des VLANs. Auch hier klappte es mal und mal nicht – gleiches Fehlerbild.

sw1# ping 10.10.1.10
10.10.1.10 is alive, time = 6 ms
Request timed out.
Request timed out.
Request timed out.
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms

Als nächstes liegt es also nahe zu prüfen, ob die MAC Adresse hinter der virtuellen Maschine mit der IP 10.10.1.10 auch wirklich an dem Port des Public-Interfaces vom Hyper-V Host bekannt ist.

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk1 21

Der Ping lief zunächst, plötzlich brach der Ping weg und selbiger Befehl auf dem Switch sw1 zeigte nun folgendes:

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk2 21

Ok, die Ursache für die sporadische Nichterreichbarkeit scheint gefunden aber warum wechselt die ist die gleiche MAC plötzlich auf einem anderen Interface bekannt?

Es galt zu hinterfragen was genau beim Umbau passiert ist:

Es waren vor dem Umbau zwei Hyper-V Singlehost VH1 und VH2. Die IP des VH2 wurde geändert und es kam ein dritter Hyper-V Singlehost, VH3, hinzu und bekam die IP des VH2.

Ok der Fall wird klarer. Bei Hyper-V arbeitet Microsoft mit dynamischen MAC Adress Pools welche wie folgt zusammengesetzt sind:

Z. B. die MAC Adresse 00:15:5D:32:FB:01

  • 00:15:5D is the OEM identifier
  • 32:FB letzten zwei Oktetts des ersten Hyper-V Netzwerkadapters konvertiert in HEX
  • 01 aufsteigende Nummerierung

Nun war es relativ einfach, die dynamischen MAC Address Pools beider Hyper-V Singlehosts waren identisch. Warum? Als die Hyper-V Rolle auf dem VH2 zur Installation aktiviert wurde, wurde der MAC Adresspool generiert (wird abgelegt unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization bzw. ist im Hyper-V Netzwork Manager auch sichtbar) – der VH2 hatte zum Zeitpunkt der Aktivierung der Rolle „x.x.50.251“ gebunden insofern kam es zu „32:FB“. Während der Laufzeit des VH2 wurde die IP geändert aber der dynamische MAC Pool bleibt natürlich gleich.

Als der VH3 nun mit der alten IP des VH2 konfiguriert und dessen Hyper-V Rolle aktiviert wurde generierte er nach der gleichen Logik auch „32:FB“ und seine erste Maschine bekam die „01“ verpasst.

Btw: so ein Fehlerbild erhält man auch in größeren Umgebungen wenn jmd eine virtuelle Maschine von z.B. Singlehost A auf Singlehost B umzieht jedoch die alte VM auf Singlehost A heruntergefahren liegen lässt und dann später versehentlich hochfährt.

Hier ein weiterer interessanter Artikel zum Thema der MAC Address Kollision:

  • http://blogs.technet.com/b/jhoward/archive/2008/07/15/hyper-v-mac-address-allocation-and-apparent-network-issues-mac-collisions-can-cause.aspx