NVGRE-netwerken met VMM 2012 R2. DNS verkeer komt niet door.

[Verwijderd]

Ik ben bezig de laatste hand te leggen aan de inrichting van een nieuw Hyper-V cloudplatform (5 hosts, 2012R2). Ik maak gebruik van Virtual Machine Manager (VMM) uit de System Center 2012 R2 suite, om het platform in te richten.

Een mooie feature in Hyper-V is het gebruik van Netwerk Virtualization met NVGRE. Hierbij wordt onderscheid gemaakt tussen een PA (Provider Address) en een CA (Customer Address). Ik heb de netwerken ingesteld o.a. conform deze technet handleiding.

Ik heb als test 2 VM's aangemaakt (een DC en een RDS), beide hebben netjes een CA toebedeeld gekregen (192.168.10.2 voor DC en 192.168.10.3 voor RDS). De DC is tevens DNS server en dat staat in de adapter van beide VM's ook zo ingesteld. Als ik de VM's op één host onderbreng kan ik alle vormen van netwerkverkeer tussen de VM's tot stand brengen. Bijv. Ping (op IP-basis), DNS resolven, RDP, SMB, HTTP enz.

Als ik één van de VM's naar een andere host verplaats blijft het gros van netwerkverkeer mogelijk zoals Pingen (Op IP-basis), RDP, SMB, HTTP, maar wat niet werkt is het resolven van DNS en daarmee dus ook het "in het domein" hangen van de RDS aan de DC.

Anders (korter) gezegd: Ik kan niet vanaf de RDS de hostnaam van de DC pingen, tenzij ik deze onderbreng op dezelfde Hyper-V host. Andere vormen van netwerkverkeer zijn wel mogelijk als de VM's op verschillende hosts zijn ondergebracht.

De firewalls in de VM heb ik uitgezet om te voorkomen dat deze een blokkade opwerpen. Helaas heb ik na zo'n 100 topics op internet nog nergens het antwoord gevonden.

Mogelijk weet hier iemand wat aan de hand zou kunnen zijn?

[Semt-x]

hoe zijn de hyperV hosts verbonden? snapt je switch NVGRE?

[Verwijderd]

De Hyper-V hosts beschikken allen over een 2x10GBe kaart welke met behulp van VMM is geconfigureerd als Team met daarop 4 virtuele adapters (Management, Cluster, Storage en Migration), elk in een andere IP-reeks.
Wanneer vanuit VMM een Team wordt gemaakt, verschijnt er een virtuele switch op de host. Deze virtuele switch is op alle hosts aanwezig. In VMM is ingesteld dat over deze virtuele switch, alle communicatie mag lopen van het logische netwerk waarop ik nvgre heb geconfigureerd. Vandaar waarschijnlijk dat de meeste vormen van netwerkverkeer gewoon prima werken.

Als fysieke switch gebruiken we de Netgear m7100-24x. Ik kan hier niet veel over vinden met NVGRE, maar voor de switch telt volgens mij alleen het PA-adres wat niet meer is als regulier TCP/IP-verkeer met een voor de hosts herkenbaar Subnet ID?

[Semt-x]

Ik bedoel de fysieke switch, ergens meen ik me te herinneren dat die dit sort tagging moet ondersteunen.

[Question Mark]

Het wordt encapsulalted middels GRE.

NVGRE = Network Virtualization using Generic Routing Encapsulation.

Verwijderd schreef op woensdag 22 oktober 2014 @ 16:04:
Als fysieke switch gebruiken we de Netgear m7100-24x. Ik kan hier niet veel over vinden met NVGRE, maar voor de switch telt volgens mij alleen het PA-adres wat niet meer is als regulier TCP/IP-verkeer met een voor de hosts herkenbaar Subnet ID?

Voor zover ik het kan zien lijkt dit inderdaad te kloppen.

With Windows Server 2012 and later, HNV fully supports NVGRE out of the box; it does NOT require upgrading or purchasing new network hardware such as NICs (Network Adapters), switches, or routers. This is because the NVGRE packet on the wire is a regular IP packet in the PA space, which is compatible with network infrastructure.

Windows Server 2012 made working with standards a high priority. Along with key industry partners (Arista, Broadcom, Dell, Emulex, Hewlett Packard, and Intel) Microsoft published a draft RFC that describes the use of Generic Routing Encapsulation (GRE), which is an existing IETF standard, as an encapsulation protocol for network virtualization. For more information, see the following Internet Draft: Network Virtualization using Generic Routing Encapsulation. As NVGRE-aware becomes commercially available the benefits of NVGRE will become even greater.

Ik zou eens met een sniffer gaan kijken of je gekke dingen ziet. Juist vanwege de extra encapsulation worden je ip-frames groter. Als jij ergens in Hyper-V ingesteld heb staan dat je package size 9000 bytes mag zijn, maar er komen stiekem nog een paar bytes bij vanwege de encapsulation, dan heb je kans dat je boven de ingestelde limiet van de rest van je netwerk infra komt.

Da's ook een van de reden dat bij NVGRE Recieve Side Scaling niet enabled mag worden.

Ik kom overigens hier nog iemand tegen met dezelfde issue's. Zijn oplossing is om Task offloading te disablen op de nic's.

[Verwijderd]

@question Mark:
Het uitschakelen van de Task Offloading op de fysieke HP 530T adapter was de oplossing. Ik kan nu succesvol de DNS resolven.

Bedankt voor je hulp!