Getting Started with Azure Network Monitoring

Getting knowledge and control on the network aspects of cloud is vital. In this post, lets recap the different options available for you in Microsoft Azure.

This is a webinar that we had on March 21, which is now available on demand here:  



Overview of network monitoring solutions:

Monitoring VM

Virtual machine network bandwidth:

Azure Monitor for Networking

Analysis of network connection data with Azure Monitor for virtual machines: 

Azure Connection Monitor

Monitor network communication:

Azure Packet Capture

Manage packet captures with Azure Network Watcher:

Azure NSG Flow Logs

Reading NSG flow logs:

Azure Traffic Analytics

Introduction to Traffic Analytics: 

Azure Virtual Network Tap

Virtual network TAP:

Enjoy the fun and lets catchup on @arnaudlheureux 

Virtualized Services Directory on Hyper-V for Windows Server 2012 R2 – part 2

In the previous article of this serie, we deployed an empty VM to host our VSD server, in this second part, we are getting serious and deploy the Linux OS and the VSD server role!

Proceed to CentOS 6.7 Installation

We will proceed to default minimal install of Centos 6.7:

1. Double click on the Contoso – VSD VM and click the Power Button to start it.
2. Start the setup of CentOS:centos2_thumb[2]
3. Proceed to setup choosing the desired keyboard, then select “Basic Storage Device” and “Yes, Discard Any Data”

Type the hostname for this machine “vsd.contoso.local” and the desired timezone.

Select the root password and Use All Space, Write Changes to Disk.

Click Done and Begin Installation.

4. Once the setup is finished, restart the virtual machine and log in to do basic networking setup:

dhclient eth0

In order to edit my configuration files, I don’t like vi and I prefer nano, so I get it online.

sudo yum install nano –y

Edit the file Ethernet NIC settings to match your network:

nano /etc/sysconfig/network-scripts/ifcfg-eth0









Then verify the network name:

nano /etc/sysconfig/network



Add the server IP address to the host file:

nano /etc/hosts vsd.contoso.local

Restart networking:

nano service network restart

Check your hostname settings with the following command:

hostname -f

5. Install and configure NTP service:

sudo yum install ntp -y

sudo nano /etc/ntp.conf

Modify the ntp.conf to have the internal server:

nano /etc/ntp.conf


We choose to use a local NTP server in our environment with IP address Please note that Microsoft Active Directory provides a NTP server feature, however, we are not able to use it as a time source for VSD, so we use an alternate NTP Server.

Save the file and restart the NTP client:

sudo service ntpd restart

Set the ntpd service to start automatically:

sudo chkconfig ntpd on

Verify that host is synchronized by using the following command:



6. We will pin our distribution to CentOS 6.7 repository in order to avoid it to be upgraded to later builds.

We create a new file with repo information:

sudo nano /etc/yum.repos.d/c67.repo






7. Install dependencies

sudo yum install openssh-clients libedit bind-utils -y

Linux Integration Services Update

Microsoft regularly updates Kernel driver and user mode components in order to make Linux work best and add new supported features. We need to install Linux Integrated Services (LIS) in order to ensure best behavior.

1. Open a SSH session to the newly configured machine, in this guide, we use MobaXTerm:


2. Download LIS 4.1.2 components from Microsoft Website with the following command:

sudo yum install wget -y


3. Extract the files using the following command:

tar -xvzf lis-rpms-4.1.2-1.tar.gz

4. Update the components using:


sudo ./


5. Once the setup is finished, restart the virtual machine and log back in.

Deploying the VSD Components on the VM

In this section, we will copy the VSD installation binaries to the VSD VM and proceed to setup.

1. Extract the “Nuage-VSD-*-ISO.tar.gz” file that you have downloaded. Get the .ISO file and go to Hyper-V manager and mount it to the “CONTOSO-VSD” VM.
2. Mount the ISO file on your system:

sudo mkdir /media/cdrom

sudo mount /dev/sr0 /media/cdrom

3. Launch VSD Setup process:

cd /media/cdrom

sudo ./


Select standalone option by hitting s and confirm with yes.


4. Wait for the install to finish, note that it can take several minutes.

Once the setup is finished, you can check that all the components are active using the following command:

monit summary

This should display you the following output for a fully ready environment:


Verify that VSD is operational

Once the setup has completed, you can verify the configuration and log in the portal for the first time. After reviewing operations, you will be able to install a product key to start using licensed features of your VSD.

1. Open your favorite browser and enter the URL:

Add exception to your browser as this is expected for a first configuration running with self-signed certificate


2. Login with the default credentials:


3. Welcome to the world of VSD!


So that you have VSD installed, you can start playing and creating organizations, networks, network policies.

But in order to have it enforced somewhere, you need a network controller. Monitor this blog and we will review the steps to make Nuage Networks controller run on Hyper-V!

For more information:

You can also reach me at my email if you need more info and trial: [first].[last]!


Hyper-V Network Virtualization – montage pas à pas d’une plateforme – partie 10 – Windows Server Gateway

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 sur un réseau IP de Datacenter de multiples réseaux IP (de clients d’un cloud par exemple).

Pour cela, nous utilisons dans Windows Server 2012 (R2) et System Center Virtual Machine Manager 2012 SP1/R2  l’encapsulation NVGRE (voir mon article précédent)

Puisque la vocation principale de HNV est de virtualiser et d’isoler les réseaux, lorsque nos machines isolées doivent communiquer avec l’extérieur, il faudra donc utiliser une passerelle qui permettra décapsuler/encapsuler pour envoyer ces paquets à :

  • Destination d’un réseau physique de Datacenter
  • Destination d’un autre protocole de virtualisation (VXLAN, ou autre)
  • Destination d’un réseau distant (VPN site-à-site, etc. )

Le but de cet article est de mettre en œuvre, étape par étape le composant Windows Server Gateway de Windows Server 2012 R2, avec l’aide de Virtual Machine Manager 2012 R2. Dans un prochain article, on décrira la mise en œuvre dans un VM Network et son utilisation. 


Pour mettre en œuvre ces fonctionnalités du point de vue de nos machines virtuelles, il nous faut System Center Virtual Machine Manager 2012 R2.

Pour utiliser le rôle de passerelle “Windows Server Gateway” de Windows Server 2012 R2, ils nous faut deux choses :

  • un hyperviseur Windows Server 2012 R2 Hyper-V : 

Cet Hyperviseur ne doit pas héberger de machines virtuelles utilisant la virtualisation de réseau (mais il peut héberger des VM classiques)

  • une machine virtuelle Windows Server 2012 R2 avec le rôle d’accès distant activé. C’est celle qui fera réellement toutes les opérations réseau et fera le rôle de passerelle de manière active.

Voici la plateforme que j’utilise :


Cette machine virtuelle/passerelle HNV nécessite 3 interfaces réseaux virtuelles :

  • une carte réseau dans le réseau virtualisé HNV (la carte qui est sur le réseau provider/Datacenter, dans l’espace d’adressage PA),
  • une carte réseau sur le réseau extérieur (le réseau physique classique du Datacenter)
  • optionnellement (vraiment?) une carte réseau d’administration

1. Paramétrage de l’hyperviseur pour les opérations de passerelle

La première étape se déroule dans System Center 2012 R2 VMM et consiste à configurer l’hyperviseur pour activer le rôle de passerelle, on va donc pour cela dans les propriétés de l’hyperviseur dans la partie Fabric pour activer l’option This host is a dedicated network virtualisation Gateway…  :


Une fois cela validé, on va ajouter le couple hyperviseur/machine virtuelle dans notre configuration.

2. Configuration des cartes réseau de la VM

Démarrons la machine virtuelle de la passerelle et vérifions l’état des connexions réseau, on doit avoir :

  • une carte sur le réseau physique extérieur (elle obtiendra son adresse IP par le DHCP du réseau physique ou par configuration manuelle).
  • une carte d’administration dans l’espace d’adressage du Datacenter (la machine doit pouvoir contacter des contrôleurs de domaine de l’organisation). Dans mon cas, le réseau d’administration et le réseau extérieur sont les mêmes, je n’ai que deux cartes.
  • une carte sur le réseau NVGRE (on devra configurer l’adresse IP manuellement dans la VM, on la laisse dans l’état déconnecté au moment du setup pour la repérer.)

La configuration de la carte NVGRE doit se faire via SCVMM, la difficulté est qu’il faut la connecter à un réseau logique sans la connecter à un VM Network, alors que cette option n’est pas présentée dans l’interface graphique !

Il faut alors :

Dans les propriétés de la carte réseau non connectée, on sélectionne l’option VM Network et on clique sur Clear Selection comme suit :


On vérifie alors que la carte est connectée sur le réseau NVGRE, appelé dans notre cas LogicalSwitch-CloudProvider.


On valide et continue la configuration.

3. Déploiement de la passerelle dans VMM 2012 R2

Allons maintenant déclarer la passerelle comme ressource de la fabrique. Nous allons donc pour cela dans la console Fabric :



Nous spécifions ensuite le type de service réseau que nous ajoutons :


Il s’agit ici de la passerelle implémentée dans Windows Server 2012 R2.

Nous devons ensuite spécifier un compte d’action qui a des droits administratifs :

  • sur l’hyperviseur physique
  • sur la machine virtuelle qui sert de passerelle


Nous spécifions ensuite la chaine de connexion à la plateforme. Cette chaine se compose comme suit : VMHost=serveurPhysiqueHyperV;RRASServer=VMquiTourneLeServiceRRASS



A l’étape étape test, on va se connecter à la machine physique et la machine virtuelle pour vérifier les différentes capacités de virtualisation.


On spécifie ensuite pour quels groupes d’hyperviseurs est disponible la passerelle.


Validons la création.


Une fois l’ajout validé, on obtient alors l’écran de résumé de la passerelle. On peut alors constater qu’une passerelle HNV peut supporter dans cette version :

  • 50 routing domains (VM Networks)
  • 500 sous-réseaux virtuels (sous réseaux dans les VM networks)
  • 200 connections VPN site à site

Normalement, en situation de production, on devrait avoir saturé le lien avant d’avoir atteint ces chiffres.


Lorsque la passerelle est ajoutée, il nous faut ensuite la configurer pour l’environnement.

4. Paramétrage de la passerelle

L’étape de paramétrage est assez simple et va permettre de déterminer à quels usages sont destinées différentes cartes réseaux de la VM et du serveur physique.


Nous devons à cette étape déterminer les interfaces réseau et leurs bindings :

  • back-end : interface connectée au réseau virtualisé HNV (réseau PA) (ici ma carte réseau appelée NVGRE, sur le site Paris du réseau logicque NetCloudPRovider)


A cette étape, il se passe en fait plusieurs choses, le paramétrage des cartes réseaux virtuelles pour le service RAS, et le paramétrage du mode multi-locataire sur la carte virtuelle. On peut vérifier cela avec la commande PowerShell :



Dans cet article, nous configurons la plateforme de base, dans un article suivant, nous configurerons les VM networks pour tirer partie de la passerelle ! Stay tuned !


Pour revenir aux premiers articles qui décrivent l’installation de la plateforme pas à pas :

partie 1 (introduction et principe à HNV) :

partie 2 (description de la plateforme technique minimale) :

partie 3 (création du réseau logique) :

partie 4 (création des IP Pool pour Logical Network) :

partie 5 (création du switch logique) :

partie 6 (affectation du switch logique aux hyperviseurs de la plateforme) :

partie 7 (création d’un VM Network) :

partie 8 (création des IP Pool pour Virtual Subnet) :

partie 9 – connexion de VM à des VM Networks :

Encapsulation NVGRE :

Références : – Windows Server Gateway – How to Use a Server Running Windows Server 2012 R2 as a Gateway with VMM – Configuring VM Networks and Gateways in VMM

Pour tester Windows Server 2012 R2 et Hyper-V, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :
– d'une image ISO :
– d'un fichier VHD avec un système préinstallé :

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, vous pouvez vous inscrire gratuitement à un de nos IT Camps : La liste des IT Camps de septembre 2013 à juin 2014 sera bientôt en ligne. Attention, il n’y aura qu’une date par sujet et par semestre par ville et le nombre de place est limité.

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 : 

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).



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 qui va envoyer un ping vers 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


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:



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


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



Regardons maintenant au paquet en hexa:


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:




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…


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



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 ( en Beta pour le moment. Ouvrons la trace précédente et observons le résultat :


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 :


L’hyperviseur qui envoi le paquet va remplir le GRE Key avec le VSID du destinataire, aussi lorsque la machine 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 : 

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 :


Références : – Premier article de la série de Stanislas – NVGRE @ IETF – Détails techniques sur la virtualisation de réseau – Test Lab Guide: Windows Server 2012 R2 Hyper-V Network Virtualization with System Center 2012 R2 VMM

Arnaud – les bons tuyaux