7
NLB im Unicast-Mode
Der Switch eines Kunden kann kein Unicast und ich muss NLB einrichten auf Teufel komm raus 
Konfiguration:
2 Server (Win 2008)
Server 1:
NIC 1 (LAN): 192.168.100.11 NLB
NIC 2 : deaktiviert
Server 2:
NIC 1 (LAN): 192.168.100.12 NLB
NIC 2 : deaktiviert
Farm-IP: 192.168.100.20
Nichts geht mehr! Der Grund ist, dass die Mac-Adressen der beiden NLB-NICs (NIC 1 beider Server) durch eine überschrieben werden. Deshalb können die Clusterknoten auch nicht mehr miteinander reden. Noch dazu kommt, dass der Switch wegen der Unicast Mac-Adresse (02:...) geflutet wird - kann eben die MAC-Adresse nicht lernen:
Wie setzte ich das um?
Beide NIC 2 mit IP-Adressen aus dem gleichen Bereich wie die von den NICs konfigurieren.
Beide NIC 2 als NLB-Cluster konfigurieren.
Auf dem Switch außer dem Default VLan (VLAN 1) an den die NICs 1 angeschlossen sind ein VLAN 2 konfigurieren an den die NICs 2 angeschlossen werden
Aber dann brauche ich doch noch einen Router, oder?
Die gelesene Lösung, beide NIC 1 an Switch, HUB an Switch anschließen und die NIC 2 an den HUB anschließen ist doch kirre, oder?
Ich wäre dankbar für jede Hilfe!!!!!!!!!!!!!
Viele Grüße
Sven
2 Server (Win 2008)
Server 1:
NIC 1 (LAN): 192.168.100.11 NLB
NIC 2 : deaktiviert
Server 2:
NIC 1 (LAN): 192.168.100.12 NLB
NIC 2 : deaktiviert
Farm-IP: 192.168.100.20
Nichts geht mehr! Der Grund ist, dass die Mac-Adressen der beiden NLB-NICs (NIC 1 beider Server) durch eine überschrieben werden. Deshalb können die Clusterknoten auch nicht mehr miteinander reden. Noch dazu kommt, dass der Switch wegen der Unicast Mac-Adresse (02:...) geflutet wird - kann eben die MAC-Adresse nicht lernen:
Wie setzte ich das um?
Beide NIC 2 mit IP-Adressen aus dem gleichen Bereich wie die von den NICs konfigurieren.
Beide NIC 2 als NLB-Cluster konfigurieren.
Auf dem Switch außer dem Default VLan (VLAN 1) an den die NICs 1 angeschlossen sind ein VLAN 2 konfigurieren an den die NICs 2 angeschlossen werden
Aber dann brauche ich doch noch einen Router, oder?
Die gelesene Lösung, beide NIC 1 an Switch, HUB an Switch anschließen und die NIC 2 an den HUB anschließen ist doch kirre, oder?
Ich wäre dankbar für jede Hilfe!!!!!!!!!!!!!
Viele Grüße
Sven
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 159101
Url: https://administrator.de/contentid/159101
Printed on: April 19, 2024 at 14:04 o'clock
7 Comments
Latest comment
Nein, das ist keineswegs "kirre" sondern höchst sinnvoll weil der Switch nur auf den Ethernet Header der NICs sieht um die Mac Adresse zu lernen der Client aber aur den ARP Reply der virtuellen MAC.
Da der Switch somit die wahre MAC der Cluster IP nie lernen kann muss er zwangsweise fluten, also quasi HUB spielen.
Einen HUB ist also sehr sinnvoll zu verwenden:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configur ...
...oder eben halt Multicast verwenden, was aber nur geht wenn dein Switch statische ARP Einträge supportet.
Du bist also in der Zwickmühle und musst dich entscheiden....
Oder dein Kunde muss einen HW Loadbalancer kaufen von F5, Foundry usw. dann stellt sich das Problem gar nicht erst.
Da der Switch somit die wahre MAC der Cluster IP nie lernen kann muss er zwangsweise fluten, also quasi HUB spielen.
Einen HUB ist also sehr sinnvoll zu verwenden:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configur ...
...oder eben halt Multicast verwenden, was aber nur geht wenn dein Switch statische ARP Einträge supportet.
Du bist also in der Zwickmühle und musst dich entscheiden....
Oder dein Kunde muss einen HW Loadbalancer kaufen von F5, Foundry usw. dann stellt sich das Problem gar nicht erst.
Hallo Aqui,
vielen Dank für die Unterstützung!!!
Da ich beide TS einzeln warten oder SW installieren muss, muss ich per RDP direkt drauf. Momentan ist es so, dass ich wegen der virtturllen Mac zufallsmäßig auf TS1 oder 2 Lande und das geht gar nicht. Das wäre ja auch nicht mit der Hublösung gelöst, sondern lediglich das Fluten der Switche, stimmt's? Was hälst Du davon:
Die NICs 1 (Lan) auf ein Default Vlan und die 2 NLB Cluster (NICs 2) auf ein seperates VLAN und beide VLANs per Router verbinden.
Die Hardware-Lösung prüfe ich noch. Wo bewegen wir uns da ca. preislich bei sagen wir mal 3 Servern?
Viele Grüße
Sven
Was ha
vielen Dank für die Unterstützung!!!
Da ich beide TS einzeln warten oder SW installieren muss, muss ich per RDP direkt drauf. Momentan ist es so, dass ich wegen der virtturllen Mac zufallsmäßig auf TS1 oder 2 Lande und das geht gar nicht. Das wäre ja auch nicht mit der Hublösung gelöst, sondern lediglich das Fluten der Switche, stimmt's? Was hälst Du davon:
Die NICs 1 (Lan) auf ein Default Vlan und die 2 NLB Cluster (NICs 2) auf ein seperates VLAN und beide VLANs per Router verbinden.
Die Hardware-Lösung prüfe ich noch. Wo bewegen wir uns da ca. preislich bei sagen wir mal 3 Servern?
Viele Grüße
Sven
Was ha
Hallo aqui,
zu meinem Vlan /Router Vorschlag: So nicht realisierbar?
zu meinem und dem Hubvorschlag: Beide lösen das Flooding-Problem aber das Problem, dass die Nlb-Knoten wegen der virt. Mac-Adresse nicht sauber miteinder reden (siehe auch ganz oben) habe ich wieder, oder? Auch der Rdp-Zugang auf einen TS (ohne Nutzung der Farm-IP sondern die richtige NIC IP) ohne doch auf dem anderem zu landen habe ich immer noch.
Wenn ich recht habe ist Unicast in einer Produktivimhebung nicht umsetzbar - siehst Du es anders?
Gruß
Sven
zu meinem Vlan /Router Vorschlag: So nicht realisierbar?
zu meinem und dem Hubvorschlag: Beide lösen das Flooding-Problem aber das Problem, dass die Nlb-Knoten wegen der virt. Mac-Adresse nicht sauber miteinder reden (siehe auch ganz oben) habe ich wieder, oder? Auch der Rdp-Zugang auf einen TS (ohne Nutzung der Farm-IP sondern die richtige NIC IP) ohne doch auf dem anderem zu landen habe ich immer noch.
Wenn ich recht habe ist Unicast in einer Produktivimhebung nicht umsetzbar - siehst Du es anders?
Gruß
Sven
Nein, damit löst du das Mac Problem beim Unicast ja nicht sondern verschiebst es nur in ein anderes VLAN. NLB über Router geht generell nicht da nur L2 möglich !
Es ist auch eher unwahrscheinlich das deine Aussage von oben "Switch eines Kunden kann kein Unicast" überhaupt stimmt.
Damit würde der Switch gegen grundlegende Standards verstossen was ziemlich unrealistisch ist. Der Switch muss zwangsweise in der Mac Forwarding Tabelle unbekannte Macs an alle Ports fluten. Das der das nicht kann wäre höchst unwahrscheinlich !!
Besser ist also du bewaffnest dich mit einem Wireshark und siehst dir das wirklich mal an.....
Nimm sonst einen billigen Switch Hub vom Blödmarkt Grabbeltisch, schalte die 2 Cluster Rechner da drauf und das an den Switch...das sollte doch final dein Problem lösen, da das Fluten dann nur noch an einem Port stattfindet.
Kannst du nicht auf Multicast und static ARP Einträge umschalten. Das ist das was in 99% aller Fälle bei MS NLB im Netzwerk gemacht wird !!
Es ist auch eher unwahrscheinlich das deine Aussage von oben "Switch eines Kunden kann kein Unicast" überhaupt stimmt.
Damit würde der Switch gegen grundlegende Standards verstossen was ziemlich unrealistisch ist. Der Switch muss zwangsweise in der Mac Forwarding Tabelle unbekannte Macs an alle Ports fluten. Das der das nicht kann wäre höchst unwahrscheinlich !!
Besser ist also du bewaffnest dich mit einem Wireshark und siehst dir das wirklich mal an.....
Nimm sonst einen billigen Switch Hub vom Blödmarkt Grabbeltisch, schalte die 2 Cluster Rechner da drauf und das an den Switch...das sollte doch final dein Problem lösen, da das Fluten dann nur noch an einem Port stattfindet.
Kannst du nicht auf Multicast und static ARP Einträge umschalten. Das ist das was in 99% aller Fälle bei MS NLB im Netzwerk gemacht wird !!
Hallo aqui,
Du hast natürlich recht - ich meinte Kundenswitch kann kein Multicast!!!
Ich habe jetzt auch die Nase voll, mitunter auch von Hub- und Switch-Hublösungen. Der Kunde nimmt nun einen günstigeren Switch mit wenigen Ports und dann richten wir es mit Multicast ein.
Ich denke www.ntsystems.it/post/NLB-e28093-Unicast-vs-Multicast-Konfiguration-Port-Rules.spx bringt es dann auf den Punkt.
aqui, ich (NLB-Frischling
) bedanke mich recht herzlich!!!
Immer gerne wieder!
Viele Grüße
Sven
Du hast natürlich recht - ich meinte Kundenswitch kann kein Multicast!!!
Ich habe jetzt auch die Nase voll, mitunter auch von Hub- und Switch-Hublösungen. Der Kunde nimmt nun einen günstigeren Switch mit wenigen Ports und dann richten wir es mit Multicast ein.
Ich denke www.ntsystems.it/post/NLB-e28093-Unicast-vs-Multicast-Konfiguration-Port-Rules.spx bringt es dann auf den Punkt.
aqui, ich (NLB-Frischling
) bedanke mich recht herzlich!!!Immer gerne wieder!
Viele Grüße
Sven
Mmmhhhh, eigentlich kann jeder Switch Multicast !! Billige Dummswitches müssen laut Ethernet Spezifikation Multicast Frames mit dem IP Ziel Adressbereich 224.0.0.0 bis 239.255.255.255 (Mac Adressen die mit "01-...." anfangen) dann einfach fluten auf alle Ports, was sie dann auch machen. So kann auch der billige, nicht managebare Blödmarktswitch vom Grabbeltisch dann Multicast. In der Beziehung irrst du also technisch....sorry.
http://de.wikipedia.org/wiki/MAC-Adresse#Pseudo-Empf.C3.A4nger_.22Broad ...
Mit der o.a. Lösung bist du aber auf dem richtigen Weg !
Wenns das war bitte
How can I mark a post as solved?
nicht vergessen.
http://de.wikipedia.org/wiki/MAC-Adresse#Pseudo-Empf.C3.A4nger_.22Broad ...
Mit der o.a. Lösung bist du aber auf dem richtigen Weg !
Wenns das war bitte
How can I mark a post as solved?
nicht vergessen.
Hallo ich sehe das hier gerade und habe zu dem Unicastbetrieb auch noch eine Frage. Vllt. kann mir ja wer weiterhelfen.
Also, ich betreibe 2 physikalische Windows Server 2008 R2 Systeme. Auf jedem der beiden physikalischen Systeme läuft in einer Hyper V Umgebung ein virtueller Windows Server 2008R2. Die beiden Virtuellen Systeme habe arbeiten in einem NLB Cluster welcher im Unicast Modus läuft (Da kein passender Switch vorhanden) und sollen später zusammen eine TS Farm bilden. Der physikalische Server hat 3 physikalische LAN Karten. Eine für den physikalischen Server selber, die beiden anderen Netzwerkkarten sind direkt für die jeweilige Virtuelle Maschiene. Die virtuellen Server haben folgende LAN Konfigurationen:
Server1: LAN1: 172.20.1.10; LAN2(NLB): 192.168.1.10
Server2: LAN1: 172.20.1.11; LAN2(NLB): 192.168.1.11
Der NLB Cluster, welchen ich erstellt habe hat die Cluster IP 192.168.1.20 und funktioiert. D.h. beide Server in der Netzwerklastausgleichskonsole sind grün und auch ein Ping bzw. eine RDP Verbindung lässt sich über den Cluster aufbauen. Das funktioniert, wenn beide Server an sind, bzw. jeweils einer aus ist immer wunderbar. Soweit so gut. Nun, laut meinem Verständnis, dürften sich die beiden Server untereinander nur über das 172.20.1.0 Subnetz unterhalten, da das 192.168.1.0 Subnetz ja für den NLB verwendet wird und der Cluster im Unicast Modus läuft. Jedoch stehe ich hier nun vor einem großen Fragezeichen. Die beiden Server können sich untereinander prima im 192.168.1.0 Subnetz unterhalten. Jeder Ping von Server1 geht sauber zu Server 2 über das 192.168.1.0 Subnetz rüber und umgekehrt. Auch Client seitig lässt sich jeder der Server noch über seine jeweilige 192.168.1.10 bzw. 192.168.1.11 Adresse erreichen. Kann mir jemand sagen wieso das funktioniert obwohl es ansich nicht klappen dürfte? Hat das etwas mit dem internen Hyper V R2 Switch zu tun?
In einem Testsystem mit zwei reinen physikalischen Servern (auch Win2008R2) und jeweils nur einer Netzwerkkarte habe ich das selbe Problem. Der Cluster funktioniert. Beide Server sind drin und in der Management Console beides Grün. RDP Verbindungen auf den Cluster werden verteilt. Jedoch können sich beide untereinander wunderbar unterhalten. Ein Ping sowie eine RDP Verbindung untereinander geht sauber rüber.
Hat evtl. irgendwer eine Idee?
Also, ich betreibe 2 physikalische Windows Server 2008 R2 Systeme. Auf jedem der beiden physikalischen Systeme läuft in einer Hyper V Umgebung ein virtueller Windows Server 2008R2. Die beiden Virtuellen Systeme habe arbeiten in einem NLB Cluster welcher im Unicast Modus läuft (Da kein passender Switch vorhanden) und sollen später zusammen eine TS Farm bilden. Der physikalische Server hat 3 physikalische LAN Karten. Eine für den physikalischen Server selber, die beiden anderen Netzwerkkarten sind direkt für die jeweilige Virtuelle Maschiene. Die virtuellen Server haben folgende LAN Konfigurationen:
Server1: LAN1: 172.20.1.10; LAN2(NLB): 192.168.1.10
Server2: LAN1: 172.20.1.11; LAN2(NLB): 192.168.1.11
Der NLB Cluster, welchen ich erstellt habe hat die Cluster IP 192.168.1.20 und funktioiert. D.h. beide Server in der Netzwerklastausgleichskonsole sind grün und auch ein Ping bzw. eine RDP Verbindung lässt sich über den Cluster aufbauen. Das funktioniert, wenn beide Server an sind, bzw. jeweils einer aus ist immer wunderbar. Soweit so gut. Nun, laut meinem Verständnis, dürften sich die beiden Server untereinander nur über das 172.20.1.0 Subnetz unterhalten, da das 192.168.1.0 Subnetz ja für den NLB verwendet wird und der Cluster im Unicast Modus läuft. Jedoch stehe ich hier nun vor einem großen Fragezeichen. Die beiden Server können sich untereinander prima im 192.168.1.0 Subnetz unterhalten. Jeder Ping von Server1 geht sauber zu Server 2 über das 192.168.1.0 Subnetz rüber und umgekehrt. Auch Client seitig lässt sich jeder der Server noch über seine jeweilige 192.168.1.10 bzw. 192.168.1.11 Adresse erreichen. Kann mir jemand sagen wieso das funktioniert obwohl es ansich nicht klappen dürfte? Hat das etwas mit dem internen Hyper V R2 Switch zu tun?
In einem Testsystem mit zwei reinen physikalischen Servern (auch Win2008R2) und jeweils nur einer Netzwerkkarte habe ich das selbe Problem. Der Cluster funktioniert. Beide Server sind drin und in der Management Console beides Grün. RDP Verbindungen auf den Cluster werden verteilt. Jedoch können sich beide untereinander wunderbar unterhalten. Ein Ping sowie eine RDP Verbindung untereinander geht sauber rüber.
Hat evtl. irgendwer eine Idee?
