Tout ce dont vous avez besoin pour mieux comprendre le fonctionnement du NLB (Network Load Balancing)
Bonjour,
Comme annoncé, voici des informations sur l’implémentation du composant de répartition de charge réseau (NLB) dans Windows. NLB est principalement utilisé pour les fermes de serveur Web ou de serveur ‘Terminal Serveur’. L’idée est de répartir les connexions entrantes entre les différents membres en prenant en compte soit l’affinité (pour les sessions Terminal Server, il est par exemple préférable de se reconnecter au même serveur TS en cas de déconnexion temporaire), soit de l’équilibrage de charge pure sans autre condition que la répartition des connexions. NLB n’est pas un produit aditionnel car inclus dans les ditributions de Windows Server. Le présent document permet de choisir en connaissance de cause l’architecture qui convient pour l’implémentation NLB, et non pas la gestion au quotidien du NLB.
1. Modes de fonctionnement de NLB pour Windows 2000 et 2003
Network Load Balancing peut être configuré selon l'un des quatre modes disponibles. Ce post décrit les modèles avec les avantages et les inconvénients ainsi que les différents scenarii.
1.1 Une seule carte réseau (Unicast)
Description
Une simple interface réseau peut avoir deux, ou plus, adresses IP associées à l'adresse MAC du cluster : une pour le trafic du cluster (par exemple les accès clients ou les battements de cœur – heartbeat – du cluster), et une autre dédiée au trafic hors cluster (par exemple administration des serveurs).
Points clés
· L'adresse MAC initiale de l'adaptateur est désactivée.
· L'adresse MAC du cluster NLB (générée avec un début type 02-BF puis une partie propre au cluster NLB) remplace cette adresse.
· Cette interface réseau devient l'adaptateur du cluster.
· L'adresse MAC du cluster résout à la fois l'adresse IP dédiée et l'adresse IP du cluster.
· Parce que tous les nœuds partagent la même adresse MAC, et parce que l'adresse MAC originelle n'est plus utilisée, la communication ordinaire entre les nœuds n'est plus possible. Toutefois, le serveur est toujours capable de prendre en compte le trafic issu d'un autre subnet dans lequel le cluster se trouve, et du même subnet si l'adresse MAC des paquets IP est différente de l'adresse MAC du cluster.
Scenarii
Serveurs de l'intranet – Pour les serveurs à faible volumétrie.
Serveurs Web – plus particulièrement pour les serveurs Web avec peu ou pas d'interaction avec des serveurs backend (contenu statique par exemple), et pas de nécessité d'interagir avec d'autres membres du cluster.
Avantages
· Une seule interface réseau est requise. Il est inutile d'installer une autre carte réseau.
· Nécessite le moins de configuration car Unicast est l'option par défaut.
· Fonctionne avec tous les routeurs.
Inconvénients
· La communication entre les nœuds d'un cluster n'est pas possible.
· La performance globale peut en souffrir sachant que le trafic du cluster et le trafic dédié au membre utilisent le même adaptateur réseau.
· Comme la communication du cluster et du membre transitent par la même interface réseau, il existe potentiellement un risque que le trafic de la communication du membre soit sniffée.
1.2 Plusieurs cartes réseau (Unicast)
Description
Deux ou plusieurs interfaces réseau avec une ou plusieurs adresses sont associées à une adresse MAC par carte réseau. Une carte est dédiée au trafic du cluster (accès clients et battements de cœur) et une autre carte réseau gère le trafic dédié (gestion distante du serveur ou accès à des ressources dans le back end).
Points clés
La première carte réseau est celle du cluster.
· L'adresse MAC originelle de la carte est désactivée.
· L'adresse MAC du cluster NLB (générée avec un début type 02-BF puis une partie propre au cluster NLB) remplace cette adresse
· Si l'adresse IP de la carte réseau dédiée est utilisée, elle est aussi résolue par l'adresse MAC du cluster.
· La carte réseau du cluster gère le trafic client vers cluster au travers de l'adresse IP virtuelle (par exemple l'adresse IP primaire). Si l'adresse IP dédiée est utilisée, la carte réseau peut aussi gérer le trafic en provenance d'autres segments réseau, ou du même segment si l'adresse IP utilisée correspond à une autre adresse MAC que celle du cluster.
La deuxième interface réseau est la carte réseau dédiée.
· L'adresse IP de cette interface correspond à l'adresse MAC de la carte réseau.
· La couche NLB est désactivée sur cette interface réseau.
· Cette carte réseau gère le trafic spécifique au serveur, incluant les connexions venant du même segment réseau dans lequel se trouve le serveur, ou d'autres.
Scenarii
Pour les serveurs Web Internet qui ont besoin d'accéder à des ressources en back end (type SQL). Les requêtes clients transitent par l'interface réseau du cluster, et contactent les ressources du back end via la carte réseau dédiée permettant d'améliorer les performances et la sécurité.
Pour les serveurs Intranet fortement sollicités : serveurs qui requièrent un temps de réponse optimal.
Par exemple Application Center 2000 a besoin d'une interface réseau dédiée au back end, pour la gestion du serveur et pour le trafic de réplication.
Avantages
· Améliore la performance globale à partir du moment où le trafic du cluster et celle de la carte dédiée transitent par des interfaces réseau distinctes.
· Permet la connexion entre les membres du cluster NLB.
· Fonctionne avec tous les routeurs.
· Améliore la sécurité sachant que les trafics du cluster et avec le back sont distincts.
Inconvénients
· Nécessite une deuxième carte réseau sur le serveur.
1.3 Une seule interface réseau (Multicast)
Description
Une simple interface réseau peut avoir deux, ou plus, adresses IP associées à l'adresse MAC du cluster : une pour le trafic du cluster (par exemple les accès clients ou les battements de cœur – heartbeat – du cluster), et une autre dédiée au trafic (par exemple administration des serveurs).
Points clés
· Le NLB génère automatiquement une adresse MAC pour la carte réseau de type 03-BF-xxxx.
· L'adresse MAC originelle de la carte réseau est retenue.
· L'adresse MAC correspond à l'adresse IP du cluster.
· L'adresse MAC originelle correspond à l'adresse IP dédiée du serveur.
· Parce que les deux adresses MAC il n'y a pas de contrainte de trafic.
Scenarii
Pour les serveurs Internet répliqués : serveurs internet qui répliquent des informations entre eux, sur un même segment réseau.
Avantages
· Une seule interface réseau est nécessaire.
· Permet la communication interne entre les membres du cluster.
Inconvénients
· Parce qu'il n'y a qu'une seule carte réseau, la performance globale du trafic peut s'en ressentir car tout transite par la même carte réseau.
· Certains routeurs peuvent ne pas supporter l'utilisation d'une adresse MAC pour le multicast qui correspond à une adresse IP unicast. Voir un peu plus loin pour la partie relative aux routeurs.
· Le trafic du cluster et dédié au serveur transitent par la même interface réseau, ce qui peut potentiellement présenter un risque (par exemple tout le trafic interne et externe utilisant la même interface réseau, il est potentiellement possible de sniffer les paquets).
1.4 Plusieurs interfaces réseau (Multicast)
Description
Deux ou plusieurs interfaces réseau associées à une ou plusieurs adresses IP ou une ou plusieurs adresses MAC par carte réseau. Une carte réseau est dédiée au trafic du cluster NLB. Les autres sont pour le trafic réseau dédié (accès aux ressources par exemple ou gestion distante).
Points clés
La première carte réseau est celle du cluster NLB.
· L'adresse MAC originelle est retenue pour la carte réseau.
· L'adresse MAC du cluster est associée à l'adresse IP du cluster (générée automatiquement par le NLB du type 03-BF-xx-xx-xx ou 01-BF-xx-xx-xx si IGMP est activé).
· Si l'adresse IP du cluster est utilisée (normal pour du multicast), cette adresse IP correspond à l'adresse MAC originelle de la carte réseau.
· La carte réseau du cluster, peut toutefois gérer le trafic client vers cluster, et le trafic spécifique du serveur, et ce pour le trafic en provenance du même segment réseau ou d'un autre segment.
La deuxième carte réseau est celle pour la communication dédiée du serveur.
· L'adresse IP correspond à l'adresse MAC par défaut de la carte réseau.
· Network Load Balancing est désactivé pour cette carte réseau.
· Cette carte réseau est dédiée au trafic du serveur incluant tous les segments réseau.
Scenarii
Ce modèle est idéal pour les clusters pour lesquels la communication interne est nécessaire, et dans lequel le trafic réseau est conséquent.
Avantages
· Optimise la performance globale car utilise plusieurs interfaces réseau.
· Permet la communication entre les membres du cluster.
· Les trafics du cluster et du serveur utilisent des interfaces réseaux distinctes améliorant la sécurité.
Inconvénients
· Nécessite une deuxième carte réseau.
· Certains routeurs ne permettent pas l'utilisation d'une adresse MAC de multicast associée à une adresse IP unicast.
2 Fonctionnement d'un cluster NLB
2.1 Communication interne du cluster NLB
Par défaut, chaque nœud d'un cluster informe ses partenaires de sa présence au travers d'un heartbeat. Ce heartbeat est envoyé sous forme de broadcast lorsque le cluster NLB est en mode Unicast, ou via Multicast, lorsque le cluster NLB est en mode Multicast. Ce heartbeat est envoyé toutes les secondes. Par défaut le protocole Ethernet de ce battement de cœur (heartbeat) est 0x886F (voir Chapitre 5.2)
Il est possible de modifier la fréquence via la valeur REG_DWORD AliveMsgPeriod dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parametres\Interface\{GUID}.
Il est aussi possible de modifier le nombre de non réception du heartbeat avant de considérer que le partenaire n'est plus présent dans le cluster NLB, qui par défaut est de 5, via la valeur REG_DWORD AliveMsgTolerance dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parametres\Interface\{GUID}.
2.2 Fonctionnement de la répartition de charge
Pour calculer la répartition de charge, l'adressage IP du cluster NLB se fait en 60 parts (buckets). Chaque membre du cluster (nœud) est en charge d'un certain nombre de buckets.
Tous les paquets entrant sont "hashed" dans le but de déterminer à quel bucket ils correspondent. Le nœud qui est en charge du bucket en question va accepter le paquet entrant. Les autres nœuds vont rejeter ce paquet (suppression) au niveau du filtre pilote NLB.
Ceci implique qu'un cluster NLB de 32 membres (le maximum), chaque membre ne pourra avoir qu'une ou deux connexion possible (1 ou 2 buckets).
Voici un exemple d'identification du Bucket (en jaune ci après) :
C:\>wlbs filter TCP 172.16.1.19 172.16.1.118:80 WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation. Cluster 172.16.1.118 Filtering Client: 172.16.1.19,0 Server: 172.16.1.118,80 Protocol:TCP Flags:SYN Accept (Packet owned by this host) Hashing: Bin=48 , Connections=0, Current=0xfffffffffffffff, Idle=0xfffffffffffffff |
La commande ici est "wlbs filter <protocole> <IPclient> [:port] <IPcluster> [:port]"
2.3 Convergence
Lorsqu'un membre du cluster joint ou quitte le cluster NLB, une opération de convergence est lancée. Cette opération de convergence consiste dans la répartition des différents "buckets" entre les membres actifs du cluster NLB.
Lorsqu'une opération de type "drain", "disable" et "enable", le calcul de convergence est aussi lancé.
Pendant l'opération de convergence le battement de cœur sera inférieur à une seconde afin de permettre un calcul plus rapidement des membres actifs dans le cluster et ainsi la nouvelle répartition des buckets.
Voici les statuts pour la convergence envoyé via le heartbeat (voir chapitre 5.2) :
- 1 : convergence normale
- 2 : convergence calculée
- 3 : convergence en court
2.4 Affinités des clients
La gestion des affinités permet d'indiquer au cluster NLB comment procéder pour la ventilation du trafic entrant pour le cluster NLB en fonction des clients
None
Ce mode permet la meilleure répartition entre les différentes connexions TCP/UDP sur le cluster NLB. Dans ce cas, seule l'adresse IP du cluster et le port qui doivent être utilisés pour initier la connexion sont utilisés.
Single
Ce mode, essentiellement utilisé avec les serveurs Web en SSL, permet pour un même client d'ouvrir plusieurs sessions simultanées sur un même nœud. Dans ce cas, l'adresse IP est la seule utilisée pour les opérations de hashing (ventilation des connexions).
Class C
L'adresse IP est utilisée en considérant qu'elle est de classe C, comme par exemple 192.168.1.10.
3 Interaction du cluster NLB avec les équipements réseau
3.1 Les commutateurs (switches)
(Pour plus d'informations voir l'article KB193602)
Le but d'un commutateur (switch) est de réduire les broadcasts des paquets en apprenant l'adresse MAC (switch de niveau 2) ou l'adresse IP (switch de niveau 3) pour chaque port. Il permet ainsi de transférer directement les paquets sur les bons ports. Sachant que NLB implique que tous les membres du cluster puissent directement être joints via l'adresse MAC ou IP du cluster, il se peut que tous les membres du cluster ne puissent pas recevoir tous les paquets (limitation des switch de niveau 3). Il y a deux méthodes pour palier ceci :
Note : en mode multicast, le cluster utilise une adresse MAC de multicast qui correspond à une adresse IP unicast. De même en mode unicast, l'adresse MAC unicast pointe sur une adresse IP unicast. Les switches n'associent pas les adresses MAC multicast à un port et par conséquent le switch envoie les paquets vers cette adresse MAC sur tous les ports.
Masquer l'adresse MAC
Le paramètre par défaut pour le mode unicast du NLB est de masquer l'adresse MAC (MaskSourceMac=1). Ceci force le cluster à utiliser une MAC adresse virtuelle lorsqu'il envoie les paquets au switch. Le switch enregistre cette adresse MAC virtuelle et l'associe à un port, mais renvoie les paquets à l'adresse MAC du cluster, c’est-à-dire sur tous les ports du switch.
Si le switch n'a pas d'adresse MAC associé à un port, il envoie les paquets sur tous les ports. C'est ce que l'on appelle "port flooding" qui permet d'adresser les membres du cluster connectés sur ce switch. Dans ce cas le switch agit comme un hub.
Toutefois, si d'autres machines sont connectées sur ce switch, il est possible de minimiser le "port flooding" en isolant la configuration cluster NLB dans un VLAN ou un hub. Dans ce cas la configuration à une meilleure bande passante et élimine ainsi toutes les collisions. Le seul inconvénient est que cela ne fonctionne qu'avec les switch de niveau 2.
3.2 Les Hubs
Reconfigurer la valeur MaskSourceMAC=0 sur tous les membres du cluster. Connecter tous les membres sur le hub et connecter le hub à un switch. Ceci permet au switch d'apprendre les adresses MAC du cluster NLB, éliminant ainsi le "port flooding" sans avoir à recourir à un VLAN. Cette configuration est limitée par la bande passante du hub. Toutefois ceci minimise les collisions et fonctionne avec les switches de niveau 2 et de niveau 3.
Si vous disposez d'une autre interface réseau pour le front end connectée sur le même segment réseau, il suffit de connecter cette interface directement sur le switch.
3.3 Les routeurs
Le NLB peut fonctionner de deux manières : unicast et multicast.
Le support de l'unicast est activé par défaut, afin de s'assurer que cela puisse fonctionner avec tous les routeurs.
Vous pouvez choisir d'implémenter le mode multicast ce qui permet d'éviter d'avoir une deuxième interface réseau pour les connexions internes du cluster. Si les clients NLB doivent accéder au cluster (configuré en mode multicast) via un routeur, il faut être sûr que le routeur accepte les réponses ARP (Address Resolution Protocol) correspondant à l'adresse IP du cluster (unicast) avec une adresse MAC de type multicast dans le payload de la structure ARP. ARP est un protocole TCP/IP qui utilise un broadcast restreint sur le réseau afin de résoudre les adresses IP. Ceci permet à un routeur de faire correspondre l'adresse IP primaire du cluster et des autres adresses (multihomed) à l'adresse MAC. Si le routeur n'a pas n'a pas de prérequis en ce sens, il est possible d'utiliser une entrée ARP statique dans le routeur, ou de laisser le cluster NLB dans sa configuration unicast par défaut.
Certains routeurs requièrent d'avoir une entrée ARP statique parce qu'ils ne supportent pas une résolution d'une adresse IP unicast en MAC multicast. Par exemple, les routeurs Cisco requièrent une entrée ARP pour chaque adresse IP virtuelle. Cisco enregistre les différentes adresses MAC dans des CAM (Content Addressable Memory). Comme le NLB utilise le multicast de niveau 2 pour délivrer les paquets, l'interprétation par Cisco des RFC est stricte : les adresses IP multicast sont uniquement pour le multicast. Par conséquent le routeur ne voit pas d'adresse IP multicast, et donc ne peut pas créer automatiquement les entrées ARP dans le CAM, et c'est pourquoi il faut les ajouter manuellement.
3.4 Les pare-feu (firewalls)
Si le pare-feu agit aussi comme proxy du trafic client, il va identifier que toutes les connexions proviennent de la même adresse IP, et si la règle du NLB est configuré en affinité "single", tout le trafic réseau sera dirigé vers le même membre du cluster. Pour contourner ceci, il faut débrayer la translation d'adresse (proxying) sur le pare-feu, ou changer le mode d'affinité à "none".
4 Questions fréquentes
Le NLB fonctionne-t-il correctement avec les commutateurs ?
Comme le NLB utilise des adresses IP et MAC virtuelles, il peut y avoir des associations incorrectes par les commutateurs avec les adresses MAC (niveau 2) ou les IP (niveau 3) d'un cluster NLB en fonction des ports utilisés. Il existe plusieurs méthodes pour prévenir ce phénomène :
- L'une d'elle est de connecter les nœuds sur un Hub qui lui-même est connecté au commutateur (de niveau 2 ou 3)
- L'autre est de masquer l'adresse MAC du NLB (commutateurs de niveau 2 exclusivement). Cette option a pour effet que le commutateur lorsqu'il doit envoyer les paquets au cluster NLB le fera sur tous les ports. C'est ce que l'on appelle "port flooding". L'effet peut être limité si le cluster NLB est confiné dans un vLAN ou via un hub.
Le NLB fonctionne-t-il correctement avec les routeurs ?
NLB est compatible en mode Unicast avec tous les routeurs. Toutefois, lorsque le mode Multicast est implémenté, il peut y avoir des limitations avec des équipements type CISCO. Dans ce cas, il faut sur le routeur ajouter des entrées ARP statiques.
NLB est-il compatible avec les réseaux token-ring ?
Non car il n'est pas possible d'avoir plusieurs machines ayant la même adresse MAC.
Est-il possible d'avoir sur un même nœud plusieurs interfaces réseau déclarées dans NLB ?
En Windows 2000 ce n'est pas possible
En Windows Server 2003, la réponse est oui si les interfaces sont dans des clusters NLB distincts. Il n'est pas possible d'avoir deux, ou plus, interfaces réseau sur un même serveur qui soient déclarées dans le même cluster NLB.
Un nœud disposant d'une seule interface réseau peut-il fonctionner dans un cluster NLB
Oui, un nœud disposant d'une seule interface réseau peut fonctionner dans un cluster NLB. Toutefois, si le mode de fonctionnement est Unicast, ce nœud ne sera pas à même de 'communiquer' avec les autres nœuds du cluster NLB.
Est-il possible d'utiliser NLB sur une carte réseau avec du Teaming ?
Oui sous certaines conditions. Il faut en effet que sur la carte réseau virtualisée par le Team, il soit possible de modifier l'adresse MAC. Dans ce cas il faut faire référence à l'article KB278431.
NLB fonctionne-t-il avec des serveurs Web qui sont 'multihomed' ?
Oui car il est possible d'associer plusiers adresses IP à plusieurs serveurs Web et d'utiliser NLB pour répartir le trafic entre.
Un seul serveur répond-il à la connexion TCP 'handshake' ?
Un seul nœud du NLB répond au TCP handshake d'une connexion entrante. Cela signifie qu'un client qui se connecte sur le cluster NLB va contacter l'un des nœuds, établir sa connexion TCP et démarrer sa session. Ensuite le client restera avec la session sur ce nœud jusqu'à la fin de la session ou la déconnexion.
Comment configurer un cluster NLB sur VMWare ESX ?
Avec un serveur ESX, le VMkernel envoie un paquet RARP à chaque action particulière (par exemple, qu'une machine virtuelle est démarrée, lors d'une bascule du teaming, effectue certaines opérations type VMotion, etc.). Le paquet RARP notifie le switch de l'adresse MAC de la machine virtuelle. Dans un environnement de cluster NLB, cela revient à donner l'adresse MAC de l'interface réseau du cluster NLB aussitôt que le nœud du cluster NLB démarre. Ceci peut avoir pour cause que tout le trafic entrant passe par un seul et unique port du switch vers un seul des nœuds du cluster NLB.
Afin de prévenir cette mécanique, voici les étapes à effectuer sur le(s) serveur(s) ESX afin qu'il(s) n'envoie(nt) pas de paquet RAPR lorsqu'une machine virtuelle démarre.
1> Implémenter la solution cluster NLB en mode Multicast. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556
2> Débrayer Net.NotifySwitch
3> Ajouter une adresse MAC statique correspondant à l'adresse IP virtuelle. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006525
Pour plus d'informations : https://www.vmware.com/files/pdf/implmenting_ms_network_load_balancing.pdf
5 Gestion et administration
5.1 WLBS.exe
Filtre
Il est possible de vérifier quel nœud va traiter une connexion entrante sur un port précis :
Par exemple pour déterminer sur quel nœud d'un cluster NLB (ayant pour IP 172.16.1.118) un client (adresse IP 172.16.1.19) va se connecter au port 80 pour accéder à une page web : " wlbs filter TCP 172.16.1.19 172.16.1.118:80"
Le résultat est présenté ainsi :
C:\>wlbs filter TCP 172.16.1.19 172.16.1.118:80 WLBS Cluster Control Utility V2.4 (c) 1997-2003 Microsoft Corporation. Cluster 172.16.1.118 Filtering Client: 172.16.1.19,0 Server: 172.16.1.118,80 Protocol:TCP Flags:SYN Accept (Packet owned by this host) Hashing: Bin=48 , Connections=0, Current=0xfffffffffffffff, Idle=0xfffffffffffffff |
5.2 Comment capturer dans une trace réseau les paquets relatifs aux heartbeat ?
Par défaut, le pilote NLB est avant le pilote tcpip.sys et par conséquent, tout le trafic concernant le heartbeat n'est pas transmis par la couche NLB à la couche TCP. Il faut par conséquent activer une clé de registre pour autoriser la couche NLB à transférer tous les paquets à la couche TCP :
Il faut positionner la valeur NetmonAliveMsgs (REG_DWORD) à 1. Ensuite, pour que cela soit pris en compte, il faut recharger la configuration du NLB (en ligne de commande : "nlb reload")
- Pour Windows 2003 Server la clé de registre (REG_DWORD) est du type : HKLM/System/CCS/Services/WLBS/Parameters/Interface/<GUID>/NetmonAliveMsgs
- Pour Windows 2000 la clé de registre(REG_DWORD) est du type : HKLM/System/CCS/Services/WLBS/Parameters/NetmonAliveMsgs
Exemple de trace réseau relative au heartbeat :
- Heartbeat 'normal' :
Frame: Number = 3, Captured Frame Length = 1510, MediaType = ETHERNET - Ethernet: Etype = MS NLB Heartbeat,DestinationAddress:[00-15-5D-01-EE-22],SourceAddress:[00-15-5D-01-EE-22] + DestinationAddress: Microsoft Corporation 01EE22 [00-15-5D-01-EE-22] + SourceAddress: Microsoft Corporation 01EE22 [00-15-5D-01-EE-22] EthernetType: MS NLB Heartbeat, 34927(0x886f) - NLBHB: Memberhip; ClusterIPAdress : 192.168.99.10 ; DedicatedIPAddress : 192.168.99.22 Signature: 0xC0DE01BF - NLB Cluster Membership HeartBeat Version: 2.4 UniqueHostID: 2 ClusterIPAddressCode: 192.168.99.10 DedicatedIPAddressCode: 192.168.99.22 - NLBMemberShipHB: NLB Cluster Membership HeartBeat MyHostID: 1 (0x1) DefaultHostID: 0 (0x0) ConvergenceState: 1 (0x1) <= signifie que la convergence est active NumberOfPortRules: 2 (0x2) UniqueHostCode: 1264151240 (0x4B596AC8) PacketsHandled: 0 (0x0) + BDATeamingConfig: Reserved1: 0 (0x0) + PortRuleConfiguration: + CurrentMap: + NewMap: + IdleMap: + ReadyMap: + LoadWeights: + Reserved2: |
- Heartbeat "extended" :
Frame: Number = 9, Captured Frame Length = 90, MediaType = ETHERNET - Ethernet: Etype = MS NLB Heartbeat,DestinationAddress:[00-15-5D-01-EE-22],SourceAddress:[00-15-5D-01-EE-23] + DestinationAddress: Microsoft Corporation 01EE22 [00-15-5D-01-EE-22] + SourceAddress: Microsoft Corporation 01EE23 [00-15-5D-01-EE-23] EthernetType: MS NLB Heartbeat, 34927(0x886f) - NLBHB: Extended; ClusterIPAdress : 192.168.99.10 ; DedicatedIPAddress : 192.168.99.21 Signature: 0xC0DE01C0 - NLB Extended HeartBeat Version: 2.4 UniqueHostID: 1 ClusterIPAddressCode: 192.168.99.10 DedicatedIPAddressCode: 192.168.99.21 - NLBHBExtended: NLB Extended HeartBeat - NLBHBFQDN: BKE2003NLB1.contoso.com PayloadType: 1 FQDN Length8: 7 (0x7) Reserved1: 0 (0x0) Reserved2: 0 (0x0) FQDN: BKE2003NLB1.contoso.com |
6 References
Network Load Balancing : Frequently Asked Questions for Windows 2000 and Windows Server 2003
https://technet.microsoft.com/en-us/library/cc758834.aspx
Troubleshooting NLB :
Considérations générales :
https://technet.microsoft.com/en-us/library/cc778400(WS.10).aspx
https://technet.microsoft.com/en-us/library/cc758834(WS.10).aspx
https://technet.microsoft.com/en-gb/library/bb742455.aspx
https://www.microsoft.com/windows2000/docs/NLBtech2.doc
Articles de la base de connaissance :
193602 Configuration options for WLBS hosts connected to layer 2 switches
https://support.microsoft.com/default.aspx?scid=kb;EN-US;193602
247297 Network Load Balancing Connection to a Virtual IP Address Not Made Across a Switch
https://support.microsoft.com/default.aspx?scid=kb;EN-US;247297
323437 How To Configure Network Load Balancing Parameters in Windows Server 2003
https://support.microsoft.com/default.aspx?scid=kb;EN-US;323437