Remote Live Monitoring avec Windows Server 2012 R2

Windows Server 2012 R2 permet désormais de prendre des traces réseau et système à distance. Pour le mettre en œuvre vous devez d’abord télécharger Message Analyzer (le successeur de Network Monitor).

Ceci est possible grâce au tracing ETW (Event Tracing for Windows) pris en remoting WMI. Plutôt que de philosopher, regardons comment le mettre en place !

masplash

Première trace à distance

Au démarrage de MA, on sélectionne l’écran Capture/Trace et on obtient l’écran suivant :

trace0

On commence par spécifier l’hôte de capture. Par défaut c’est localhost mais on peut ajouter des machines Windows Server 2012 R2 (et Windows 8.1) distants comme ceci :

trace1

On fois l’hôte sélectionné, on spécifie les éléments que l’on veut tracer en sélectionnant le scénario (partie centrale de l’écran), ce qui a pour effet d’ajouter les composants à tracer dans la section de droite :

trace2

Dans cette liste on a le premier élément : Microsoft-Windows-NDIS-PacketCapture qui a une option Configure disponible :

trace3

On peut ainsi restreindre la capture :

  • a des machines virtuelles ou switch virtuel
  • a des cartes réseau physiques ou logiques

Mon petit conseil, n’oubliez pas de cocher la case “All layers” qui n’est pas mise par défaut. Si vous ne la cochez pas, la capture ne contiendra que les infos de bas niveau (udp/tcp). Une fois cela effectué, on lance la trace réseau avec le bouton Play et on génère un peu de trafic en utilisant le partage SMB sur mon serveur hyperspeed-2.

On obtient alors ce qui commence à ressembler à une trace réseau :

trace4

Pour ceux qui ont déjà mis en œuvre de l’Unified Tracing depuis Windows 7 cela devrait leur être familier car on a bien une trace réseau avec en plus des évènements de trace système.

De la couleur !

Si vous trouvez que la trace est un peu tristoune (c’est ce que beaucoup de clients reprochaient à Netmon, le manque de couleurs !!!), il y a maintenant par défaut un ensemble de filtres de couleurs pour discriminer rapidement les éléments d’une trace (le traffic Kerberos, les resets TCP, les débuts et fins de sessions TCP, etc.) :

trace7

Des Dashboards

Regardons rapidement quelques écrans intéressants de Message Analyzer comme les Dashboard de protocoles et les Flux SMB :

trace5

Voici le protocol Dashboard :

trace6

Celui-ci permet d’avoir un aperçu des trafic présents dans la trace, ainsi que de discriminer les volumes de trafic dans le temps. Il est interactif et permet par exemple de zoomer sur un protocole en particulier pour examiner les flux. 

Le diagramme des flux SMB ressemble à ceci :

trace8

Ce deux vues par défaut ont été créées pour offrir une vue rapide sur les protocoles utilisées dans une conversation réseau ainsi que les fichiers échangés SMB dans une trace. Il existe bien d’autres subtilités dans Message Analyzer que nous découvrirons dans d’autres articles.

On est maintenant prêt à tracer à distance ce que se passe, sur une carte réseau physique ou virtuelle ou sur une VM ou un switch virtuel, et cela, c’est plutôt pratique !

Références :

Microsoft Message Analyzer Operating Guide – http://technet.microsoft.com/en-us/library/jj649776.aspx

Pour tester Windows Server 2012 R2, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :

Si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride, vous pouvez vous inscrire gratuitement à un de nos IT Camps :

https://aka.ms/itCampFr

Arnaud – les bons tuyaux

Hyper-V Network Virtualization – Encapsulation NVGRE

Dans une série d’articles, Stanislas décrit comment mettre en place la virtualisation de réseau avec Hyper-V (HNV). C’est une technique fondamentale qui permet de faire cohabiter de manière isolée plusieurs réseaux IP (de clients d’un cloud par exemple) à l’intérieur d’un réseau IP de Datacenter.

Lors de la mise sur le câble des paquets échangés entre machines Hyper-V, nous utilisons dans Windows Server 2012 (R2) et System Center Virtual Machine Manager 2012 SP1/R2  l’encapsulation NVGRE telle que définie dans : http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-02 

Cette encapsulation du trafic d’un client d’un cloud se fait sur le réseau provider (espace d’adressage PA). Alors que l’espace d’adressage PA est unique, plusieurs espaces d’adressages de clients (CA) vont cohabiter sur le PA et seront discriminés grâce à leur identifiant “GRE Key” qui contient les différents réseaux (VSID).

SchemaTopo

 

Regardons de plus près à quoi ressemble l’encapsulation réseau avec nos outils préférés: Netmon Monitor et Message Analyzer.

Pour notre exemple nous prendrons, la machine sur le réseau “blue” avec pour adresse IP 10.1.0.2 qui va envoyer un ping vers 10.2.0.2. Les masques de sous réseaux sont /16 donc, les machines sont dans le même réseau virtuel (VM Network), mais dans un “VM Subnet” différent.

 

Network Monitor

Lorsque nous activons la virtualisation de réseau Hyper-V, la carte réseau qui y est attachée se voit retirer tous les attachements de protocoles pour n’avoir uniquement :

  • Windows Network Virtualization Filter Driver (uniquement en Windows Server 2012, supprimé en R2 car intégré dans le switch virtuel Hyper-V)
  • Hyper-V Extensible Virtual Switch

bindingsw2k12

Si l’on veut effectuer une trace réseau, il faut alors cocher la case “Microsoft Network Monitor 3 Driver”; le filter driver de Netmon qui permet de capturer des paquets.

Cochons cette case et lançons la trace réseau sur l’interface qui a été activé pour la virtualisation de réseau:

NM34-Bindings

 

Démarrons alors la trace et regardons de plus près à l’encapsulation:

NM34-trace

Dans notre exemple, nous voyons sur la trace un paquet envoyé depuis 172.16.0.2 vers 172.16.0.3 avec pour protocole GRE. Nous sommes sur le réseau du provider, c’est donc bien ce qu’on s’attend à voir :

NM34-ip

 

Regardons maintenant au paquet en hexa:

NM34-hex

Pour nos amis les plus avertis, cela ressemble à une payload de ping (abcd…. à la fin du paquet.) Essayons d’y voir un peu plus clair. D’après ce que l’on sait de l’encapsulation NVGRE, on doit y trouver quelque part l'identifiant de sous réseau virtuel (VSID).

Si l’on veut retrouver les VSID de nos machines virtuelles, on peut faire de la sorte en Powershell:

Get-NetVirtualizationLookupRecord

Get-NetVirtualizationLookupRecord

 

Nous avons donc 4020644 (decimal) que nous devons convertir en hexadécimal. un petit coup de calc.exe nous permet de trouver 3D59A4. Cherchons cette séquence dans le paquet…

NM34-VSIDhex

Si l’on continue l’exploration du paquet, on voit même l’adresse IP de destination 10.2.0.2:

NM34-IPCA

 

Voila comment se passe l’encapsulation NVGRE, c’est intéressant si l’on aime faire le parseur humain, sinon Message Analyzer sait interpréter automatiquement ces messages, regardons donc la même trace avec ce dernier outil !

 

Message Analyzer

Message Analyzer est le remplaçant de Network Monitor qui permet d'Analyzer bien plus que des traces réseau, il est disponible sur connect (http://connect.microsoft.com/site216) en Beta pour le moment. Ouvrons la trace précédente et observons le résultat :

MAB3-NVGRE

On a ici une meilleure vue sur l’encapsulation de protocoles, on retrouve le VSID dans le champ Key, et on a désormais le paquet complètement parsé. Beaucoup plus facilement utilisable pour dépannage !

 

Notons au passage que pour l’exemple de la démonstration, nous utilisons des machines sur des sous réseaux virtuels (VSID) différents :

Get-NetVirtualizationLookupRecord2

L’hyperviseur qui envoi le paquet va remplir le GRE Key avec le VSID du destinataire, aussi lorsque la machine 10.2.0.2 va répondre au ping que l’on vient d’émettre, alors l’hyperviseur qui herberge la VM utilisera le VSID 8793502 enfin je veux dire 86 2D 9E !

 

 

Si vous en voulez plus, vous pourrez trouver sur Microsoft Virtual Academy, un ensemble de contenus dédiés à Windows Server 2012 et le réseau : http://www.microsoftvirtualacademy.com/training-courses/services-reseaux-de-windows-server-2012 

Et si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride par Microsoft, vous pouvez vous inscrire gratuitement à un de nos IT Camp : https://aka.ms/itCampFr.

 

Références :

http://blogs.technet.com/b/stanislas/archive/2013/07/19/hyper-v-network-virtualization-montage-pas-224-pas-d-une-plateforme-partie-1-introduction.aspx – Premier article de la série de Stanislas

http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-02 – NVGRE @ IETF

http://technet.microsoft.com/fr-fr/library/jj134174.aspx – Détails techniques sur la virtualisation de réseau

http://www.microsoft.com/en-us/download/details.aspx?id=39284 – Test Lab Guide: Windows Server 2012 R2 Hyper-V Network Virtualization with System Center 2012 R2 VMM

Arnaud – les bons tuyaux

Dépannage du Switch Hyper-V Extensible de Windows Server 2012

Avec Windows Server 2012 apparait le switch extensible Hyper-V un vrai petit bijou dont on parlera encore souvent sur ce blog. Dans cet article concentrons nous sur les techniques et outils disponibles lorsque l’on veut comprendre ce qui se passe dans la bête.

Traces unifiées:

Les traces unifiées sont apparues avec Windows 7 et permettent de récupérer des traces système corrélées via ETW (Event Tracing for Windows). Cela signifie que les différents éléments inclus dans la traces sont mis en relation entre eux pour former un tout plus facile à interpréter.

Pour lancer une trace ETW, utilisons le contexte netsh trace avec le fournisseur approprié:

netsh trace start provider=Microsoft-Windows-Hyper-V-VmSwitch

Si l’on veut une trace réseau en même temps, on peut même y ajouter l’argument qui va bien:

netsh trace start provider=Microsoft-Windows-Hyper-V-VmSwitch capture=yes

Parfois on a besoin de tracer le comportement au boot, on utilise alors l’argument persistent:

netsh trace start provider=Microsoft-Windows-Hyper-V-VmSwitch persistent=yes

Par défaut on trace dans le profile de l’utilisateur courant avec une taille max de 250MB:

netsh1 

Une fois le comportement problématique reproduit, on arrête la trace avec

netsh trace stop

netsh2

Une fois la trace obtenue, on peut l’ouvrir avec le journal d’évènements, mais ce n’est pas l’outil le plus efficace pour explorer et filtrer ce genre de traces. Utilisons plutôt des outils appropriés comme Network Monitor et Message Analyzer.

Vous allez entendre parler de plus en plus de Message Analyzer c’est le successeur de Network Monitor, et il permet de tracer à peu près tout et n’importe quoi dans Windows, bien au delà de son prédécesseur.

Vous pouvez suivre le blog de l’équipe produit ici: http://blogs.technet.com/b/messageanalyzer/ 

==> Pour l’instant Message Analyzer n’est disponible qu’en beta publique que vous pouvez télécharger ici: https://connect.microsoft.com/site216 (vous devrez joindre le groupe Message Analyzer et Network Monitor pour télécharger les éléments dont nous discutons ici). <==

Si vous n’avez pas envie de vous familiariser avec Message Analyzer, vous pouvez juste télécharger les parseurs pour Network Monitor 3.4, ce qui vous permettra d’interpréter les messages du Switch Virtuel Hyper-V. Etudions les deux cas pour notre exemple.

Avec Network Monitor 3.4:

La trace suivante (passage en mode plein écran recommandé), montre un exemple basique. On remarque dans la partie gauche, les network conversations permettent de filtrer les différent types d’activités du Switch de manière rapide:

nm34-1

On peut voir les opérations courantes sur le Switch: routage, delivery et reception que l’on peut filtrer avec les mécanismes habituels sous Netmon:

VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_DELIVER
VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_RECEIVE
VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_ROUTE

Si votre dépannage ne concerne pas ces opérations, vous pouvez déjà retirer ce bruit en utilisant le filtre d’affichage

!(VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_DELIVER OR VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_RECEIVE OR VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_ROUTE)

Selon les scénarios que l’on dépannage on pourra également vouloir mettre en évidence différents problèmes comme les drops de paquets: 

VMSWITCH_MicrosoftWindowsHyperVVmSwitch.VM_NBL_INCOMING_DROP

Le petit exemple ci-dessous vous permettra d’apprécier les subtilités de ma configuration domestique Sourire

nm34-2

 

Et pour terminer une séquence de requête de configuration et de suppression de Switch Virtuel:

nm34-3

 

Avec Message Analyzer:

Le même message que précédemment, vu avec Message Analyzer:

ma40-1

 

Message Analyzer est vraiment passionnant et son interface extensible quasiment à l’infini. Rajoutons ici une colonne pour voir rapidement quels sont les switch virtuals des différents messages:

ma40-2

Nous avons alors une vue rapide sur les différents switch et les différents dialogues:

ma40-3

 

Pour l’instant, aucun soucis dans notre trace, il s’agit juste de se familiariser avec l’outillage, nous verrons prochainement des cas concrets!

 

Bon amusement avec Message Analyzer et Windows Server 2012!

 

Plus d’informations:

Hyper-V Extensible Switch – http://msdn.microsoft.com/en-us/library/windows/hardware/hh598161(v=vs.85).aspx

Hyper-V Extensible Switch Components – http://msdn.microsoft.com/en-us/library/windows/hardware/hh598163(v=vs.85).aspx

Improve Debugging And Performance Tuning With ETW – http://msdn.microsoft.com/en-us/magazine/cc163437.aspx 

Unified Tracing Overview – http://technet.microsoft.com/en-us/library/hh848933.aspx

http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns955/ns963/solution_overview_c22-687087.html

 

Enfin comme de tradition, pour mettre tout ça en pratique, Windows Server 2012, c’est par ici: https://aka.ms/jeveuxWindows2012

 

Arnaud