11
NIC-Teaming in Server 2012
Hallo allerseits,
wir haben nun einen neuen ProLiant Gen8 auf dem Server 2012 als Hyper-V Host läuft. Nun wollte ich das schöne neue NIC-Teaming Feature nutzen und stehe vor einem kleinen Problem. Port 1 und 2 besitzen statische Adressen und wurden zu einem Team zusammengefasst.
Wenn ich nem neuen Team-NIC nun auch eine statische IP vergebe, habe ich keinen Internetzugriff. Stelle ich dagegen DHCP ein, erhalte ich Internetzugriff. In der Firewall ist die statische IP (Team-NIC) aber für HTTP etc. freigegeben. Zudem kann ich die Team-NIC auch nicht anpingen, RDP hingegen funktioniert. Irgendwie habe ich glaub ich einen Denkfehler bei diesem Feature!
wir haben nun einen neuen ProLiant Gen8 auf dem Server 2012 als Hyper-V Host läuft. Nun wollte ich das schöne neue NIC-Teaming Feature nutzen und stehe vor einem kleinen Problem. Port 1 und 2 besitzen statische Adressen und wurden zu einem Team zusammengefasst.
Wenn ich nem neuen Team-NIC nun auch eine statische IP vergebe, habe ich keinen Internetzugriff. Stelle ich dagegen DHCP ein, erhalte ich Internetzugriff. In der Firewall ist die statische IP (Team-NIC) aber für HTTP etc. freigegeben. Zudem kann ich die Team-NIC auch nicht anpingen, RDP hingegen funktioniert. Irgendwie habe ich glaub ich einen Denkfehler bei diesem Feature!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 202486
Url: https://administrator.de/forum/nic-teaming-in-server-2012-202486.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
11 Kommentare
Neuester Kommentar
Hi Gullie,
Also Teaming bedeutet, selbst wenn es richtig am Server und am Switch konfiguriert ist nur eine IP und ein Interface, aber zwei Netzwerkkabel und zwei Gigabit-Ports. Konfiguriert wird mit dem entsprechenden Utility auf die passende Funktion zwischen Load-Balancing und Hot-standby.
GRuß
Netman
Also Teaming bedeutet, selbst wenn es richtig am Server und am Switch konfiguriert ist nur eine IP und ein Interface, aber zwei Netzwerkkabel und zwei Gigabit-Ports. Konfiguriert wird mit dem entsprechenden Utility auf die passende Funktion zwischen Load-Balancing und Hot-standby.
GRuß
Netman
Fehler gefunden. Ich hatte in der ersten NIC noch ein Standard-Gateway angegeben. Habe jetzt alle physischen NICs auf DHCP gestellt und nur im virtuellen Team-NIC die statische Adresse mit dem Standard-Gateway hinterlegt.
Physischen Teaming Memberports eine IP zu vergeben ist völliger Blödsinn, da sie so oder so ignoriert werden.
Einzig relevant ist lediglich die IP, die auf dem Teaming Interface vergeben ist und NICHTS anderes.
Teaming / Link Aggregation ist eine reine Layer 2 Angelegenheit und hat rein gar nix mit IP Adressen zu tun.
http://de.wikipedia.org/wiki/Link_Aggregation
Du tust also gut daran die IP Adressen auf den physischen Ports komplett zu entfernen um dir keine Probleme einzuhandeln !
Ferner darfst du nicht vergessen das Link Aggregation / Teaming nach IEEE 802.3ad / LACP IMMER eine 2seitige Angelegenheit ist !!
Solange du also auch nicht die Switchports wo diese NICs angeschlossen sind am LAN Switch mit Link Aggregation konfigurierst machst du überhaupt gar kein Teaming mit dem Server ! Hoffentlich ist dir das bewusst.
Mit einem nicht managebaren Billigswitch wird man da generell also nix !
Bedenke das... !
Wenns das dann war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Einzig relevant ist lediglich die IP, die auf dem Teaming Interface vergeben ist und NICHTS anderes.
Teaming / Link Aggregation ist eine reine Layer 2 Angelegenheit und hat rein gar nix mit IP Adressen zu tun.
http://de.wikipedia.org/wiki/Link_Aggregation
Du tust also gut daran die IP Adressen auf den physischen Ports komplett zu entfernen um dir keine Probleme einzuhandeln !
Ferner darfst du nicht vergessen das Link Aggregation / Teaming nach IEEE 802.3ad / LACP IMMER eine 2seitige Angelegenheit ist !!
Solange du also auch nicht die Switchports wo diese NICs angeschlossen sind am LAN Switch mit Link Aggregation konfigurierst machst du überhaupt gar kein Teaming mit dem Server ! Hoffentlich ist dir das bewusst.
Mit einem nicht managebaren Billigswitch wird man da generell also nix !
Bedenke das... !
Wenns das dann war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Windows 2012 besitzt integriertes NIC-Teaming welches auch switch-unabhängig funktioniert! Und ja das mit den statischen IPs auf den Member-Ports war sicherlich falsch, aber ist ja auch das erste Mal dass wir das so nutzen. Von daher habt Nachsicht 
Nein das ist technischer Unsinn, sowas gibt es nicht im Netzwerk Umfeld ! Schlimm genug das MS so einen Unsinn verbreitet.
Ein physisches Teaming 2er NICs oder 2er oder mehrerer NIC Ports ist nie und nimmer nicht unabhängig von einem LAN Switch !!
Das ist technischer Blödsinn was MS da erzählt. Kein Wunder denn von Netzwerken verstehen sie nichts.
Wenn das ein interner, also ein virtueller Switch im Hypervisor ist, dann mag das durchaus richtig sein.
Bei allem aber was de facto mit einem physischen Ethernet Draht nach draussen geht auf einen physischen LAN Switch ist die MS Aussage technischer Blödsinn !
Oder...du verwechselst das schlicht und einfach mit MS NLB-Cluster. Das ist dann aber wieder eine ganz andere Baustelle und hat mit Teaming/Link Aggregation im LAN Netzwerk rein gar nix zu tun.
Abgesehen davon erfordert das noch eine weitaus aufwendigere Switchkonfig und Features auf dem LAN Switch !
Ein physisches Teaming 2er NICs oder 2er oder mehrerer NIC Ports ist nie und nimmer nicht unabhängig von einem LAN Switch !!
Das ist technischer Blödsinn was MS da erzählt. Kein Wunder denn von Netzwerken verstehen sie nichts.
Wenn das ein interner, also ein virtueller Switch im Hypervisor ist, dann mag das durchaus richtig sein.
Bei allem aber was de facto mit einem physischen Ethernet Draht nach draussen geht auf einen physischen LAN Switch ist die MS Aussage technischer Blödsinn !
Oder...du verwechselst das schlicht und einfach mit MS NLB-Cluster. Das ist dann aber wieder eine ganz andere Baustelle und hat mit Teaming/Link Aggregation im LAN Netzwerk rein gar nix zu tun.
Abgesehen davon erfordert das noch eine weitaus aufwendigere Switchkonfig und Features auf dem LAN Switch !
Wie gesagt... die Funktion nennt sich "switch independent" NIC-Teaming und wird sicherlich auch funktionell sein. Klar hätte ich es auch direkt auf der Hardware setzen können, aber leider sind unsere LevelOne Switches nicht managable und so ist dies doch eine nette Alternative.
http://www.medic-daniel.de/microsoft-window-server/2012/11/nic-teaming- ...
http://www.medic-daniel.de/microsoft-window-server/2012/11/nic-teaming- ...
Herzlichen Glückwunsch!
Das Teaming auf nicht managebaren Switchen führt genau dann zur Katastrofe, wenn man die zusätzliche Bandbreite brauchen könnte. Und die Katastrofe nennt sich Zumüllen des Netzwerks. Bandbreitenintensive Backups erzeugen evtl. auch den selben Effekt.
Kleine Ausnahme: Im Link wird eine aktiv- passiv Funktion erwähnt. Das klappt und ist auch für kritische Situationen nutzbar. Die einzig nutzbare Funktion ohne den Switch sauber zu konfigurieren. Aber dann gibt es auch nur 1 GBit/s.
GRuß
Netman
Das Teaming auf nicht managebaren Switchen führt genau dann zur Katastrofe, wenn man die zusätzliche Bandbreite brauchen könnte. Und die Katastrofe nennt sich Zumüllen des Netzwerks. Bandbreitenintensive Backups erzeugen evtl. auch den selben Effekt.
Kleine Ausnahme: Im Link wird eine aktiv- passiv Funktion erwähnt. Das klappt und ist auch für kritische Situationen nutzbar. Die einzig nutzbare Funktion ohne den Switch sauber zu konfigurieren. Aber dann gibt es auch nur 1 GBit/s.
GRuß
Netman
Also ich nutze momentan Hyper-V Port Load Balancing - hierbei wird je nach Verfügbarkeit einer VM eine einzelnen NIC zugewiesen. Es wird NICHT der ganze Verkehr auf alle verfügbaren aufgeteilt! Gibt es hier denn niemanden der diese Funktion des 2012 schon produktiv einsetzt?
Sobald ich einen managebaren Switch bekomme werde ich sicherlich über die anderen Varianten nachdenken, aber momentan sollte es doch die beste Variante sein, oder nicht?
Sobald ich einen managebaren Switch bekomme werde ich sicherlich über die anderen Varianten nachdenken, aber momentan sollte es doch die beste Variante sein, oder nicht?
Na ja wie immer die zitierte Beschreibung oben nicht richtig gelesen und vermutlich wenig oder kein Netzwerk Fachwissen, sorry aber genau DAS sind das tägliche Brot der Teaming Fehler hier im Forum !!
Zitieren wir mal aus dem obigen Artikel:
In meinem Fall habe ich mich für “Switch Independent” und zwar Active/Passiv entschieden.
Daran kann man sofort sehen das auch der Artikel Schreiber kein- oder nur sehr rudimentäres Netzwerk Wissen hat wie leider oft im Internet und dieses Halbwissen auch noch verbreitet...schlimm !
Mit dem obigen Feature von "Switch Independent " Teaming zu reden ist natürlich totaler Schwachsinn !
Sorry für die Drastigkeit der Worte hier, aber es macht einen wütend wenn man so einen technischen Bullshit lesen muss.
"Active Passive" ist logischerweise niemals ein Teaming von NICs und hat auch nicht im entferntesten Sinne etwas damit zu tun. Das Wort "aktiv" und "passiv" sagt das ja schon in sich...
Teaming ist immer eine Link Aggregation (Bonding für Linux) also ein aktives Nutzen beider zusammengefügter Links mit einer aktiven Netzwerk Lastverteilung auf beiden Links zur Performancesteigerung !!
Du ahnst was jetzt kommt wenn man sowas wie " Active/Passiv " liest !!!
Das ist KEIN Teaming im Sinne von Teaming sondern eine simple Link Redundanz Konfig also ein Failover.
Hier gibt es einen primären aktiven Link und einen passiven sekundären Link.
Sowas macht Sinn wenn man aus Redundanzgründen (Hochverfügbarkeit) die 2 Links auf 2 unterschiedliche Switches steckt.
Du siehst selber das ist natürlich keinerlei Teaming sondern nichts anderes als ein simpler Link Failover, denn du nutzt nur einen einzigen Link aktiv.
Fazit: Vergiss den Unsinn der oben steht und glaube nicht alles was du im Internet liest bzw. macht dich technisch kundig !
Für dich und deine Billigswitches heist das letztlich: Teaming und damit eine Performancesteigerung im Server Zugriff kannst du dir mit der Level One Blödmarkt Billighardware aus dem Kopf schlagen...damit wird das logischerweise nix ! Für nur 10 Euro Mehrinvest im Switch hättest du es gehabt...
Zitieren wir mal aus dem obigen Artikel:
In meinem Fall habe ich mich für “Switch Independent” und zwar Active/Passiv entschieden.
Daran kann man sofort sehen das auch der Artikel Schreiber kein- oder nur sehr rudimentäres Netzwerk Wissen hat wie leider oft im Internet und dieses Halbwissen auch noch verbreitet...schlimm !
Mit dem obigen Feature von "Switch Independent " Teaming zu reden ist natürlich totaler Schwachsinn !
Sorry für die Drastigkeit der Worte hier, aber es macht einen wütend wenn man so einen technischen Bullshit lesen muss.
"Active Passive" ist logischerweise niemals ein Teaming von NICs und hat auch nicht im entferntesten Sinne etwas damit zu tun. Das Wort "aktiv" und "passiv" sagt das ja schon in sich...
Teaming ist immer eine Link Aggregation (Bonding für Linux) also ein aktives Nutzen beider zusammengefügter Links mit einer aktiven Netzwerk Lastverteilung auf beiden Links zur Performancesteigerung !!
Du ahnst was jetzt kommt wenn man sowas wie " Active/Passiv " liest !!!
Das ist KEIN Teaming im Sinne von Teaming sondern eine simple Link Redundanz Konfig also ein Failover.
Hier gibt es einen primären aktiven Link und einen passiven sekundären Link.
Sowas macht Sinn wenn man aus Redundanzgründen (Hochverfügbarkeit) die 2 Links auf 2 unterschiedliche Switches steckt.
Du siehst selber das ist natürlich keinerlei Teaming sondern nichts anderes als ein simpler Link Failover, denn du nutzt nur einen einzigen Link aktiv.
Fazit: Vergiss den Unsinn der oben steht und glaube nicht alles was du im Internet liest bzw. macht dich technisch kundig !
Für dich und deine Billigswitches heist das letztlich: Teaming und damit eine Performancesteigerung im Server Zugriff kannst du dir mit der Level One Blödmarkt Billighardware aus dem Kopf schlagen...damit wird das logischerweise nix ! Für nur 10 Euro Mehrinvest im Switch hättest du es gehabt...
Warum diese ganze Hostilität? Es ist richtig dass ich im Netzwerk-Wissen sicherlich lernfähig bin, aber dennoch zweifel ich daran, dass, wie du es Microsoft ja offensichtlich bescheinigst, hier eine Sinnlos-Funktion eingebaut hat. Wenn für dich "Teaming" nur die eine Bedeutung hat, dann bitte, dann sei es so...
Hier noch mal eine ausführliche Erklärung...
http://blogs.technet.com/b/keithmayer/archive/2012/10/16/nic-teaming-in ...
Hyper-V Port - If your server is a Hyper-V host with multiple running VMs, this load balancing mode is normally preferred in most situations. When using "Hyper-V Port" load balancing, VM's will be distributed across the network team and each VM's outbound and inbound traffic will be handled by a specific active NIC. This mode works really well in scenarios where you are consolidating many VM's on a physical Hyper-V host, but where none of the VM's are generating a network load that exceeds the bandwidth of one NIC in the team. In this use case, NIC teaming provides a very cost-effective way of load balancing the aggregate traffic from all VMs across the active team members, but remember ... each VM is assigned to a specific NIC in the team, so none of the VM's will be able to access more bandwidth than what one NIC provides.
...also nix mit Failover, dafür müsste ich ja noch ein Adapter als Standby definieren. Wir haben mit 30 Usern auch nicht den Mega-Traffic - wir sprechen hier nicht von einem Riesen-Datenzentrum mit zig geschäftskritischen Diensten!
P.S. Die "Billig"-Switches waren schon vorhanden bevor ich hier angefangen habe. Ich kann leider nur mit dem arbeiten was da ist, da bei uns in der Geschäftsleitung keiner den Wert einer gut funktionierenden IT schätzt.
Hier noch mal eine ausführliche Erklärung...
http://blogs.technet.com/b/keithmayer/archive/2012/10/16/nic-teaming-in ...
Hyper-V Port - If your server is a Hyper-V host with multiple running VMs, this load balancing mode is normally preferred in most situations. When using "Hyper-V Port" load balancing, VM's will be distributed across the network team and each VM's outbound and inbound traffic will be handled by a specific active NIC. This mode works really well in scenarios where you are consolidating many VM's on a physical Hyper-V host, but where none of the VM's are generating a network load that exceeds the bandwidth of one NIC in the team. In this use case, NIC teaming provides a very cost-effective way of load balancing the aggregate traffic from all VMs across the active team members, but remember ... each VM is assigned to a specific NIC in the team, so none of the VM's will be able to access more bandwidth than what one NIC provides.
...also nix mit Failover, dafür müsste ich ja noch ein Adapter als Standby definieren. Wir haben mit 30 Usern auch nicht den Mega-Traffic - wir sprechen hier nicht von einem Riesen-Datenzentrum mit zig geschäftskritischen Diensten!
P.S. Die "Billig"-Switches waren schon vorhanden bevor ich hier angefangen habe. Ich kann leider nur mit dem arbeiten was da ist, da bei uns in der Geschäftsleitung keiner den Wert einer gut funktionierenden IT schätzt.
Du würfelst jetzt im freien Fall diverse Szenarien durcheinander. Die Hyper V Story beschreibt einzig einen internen virtuellen vSwitch im Hypervisor und eben NICHT einen externen Switch.
Es steht außer Zweifel das hier bei internen, Hypervisor basierten vSwitches gewisse Load Balancing Optionen möglich sind, letztlich ist das aber auch internes 802.3ad Load Balancing. Hier klappt das, denn dieser vSwitch ist quasi managebar, er ist ja nur ein Stück Software intern. Du redest oben aber von einem externen LAN Switch also nix virtuelles in Software sondern um ein Stück reales Blech.
Es bleibt aber dabei:
Alles was physisch auf einem Draht nach draussen ins reale LAN geht ist ohne einen managebaren Switch der kein 802.3ad / LACP kann NICHT Teaming oder Link Aggregation fähig.
Das ist ein technischer Fakt und da beisst die Maus keinen Faden ab.... Alles andere ist bar jeglicher Realität.
Die "Hostilität" bezog sich auch eher auf den oben zitierten Blog ! Was dort drinsteht ist technisch gesehen schlicht falsch !
Es steht außer Zweifel das hier bei internen, Hypervisor basierten vSwitches gewisse Load Balancing Optionen möglich sind, letztlich ist das aber auch internes 802.3ad Load Balancing. Hier klappt das, denn dieser vSwitch ist quasi managebar, er ist ja nur ein Stück Software intern. Du redest oben aber von einem externen LAN Switch also nix virtuelles in Software sondern um ein Stück reales Blech.
Es bleibt aber dabei:
Alles was physisch auf einem Draht nach draussen ins reale LAN geht ist ohne einen managebaren Switch der kein 802.3ad / LACP kann NICHT Teaming oder Link Aggregation fähig.
Das ist ein technischer Fakt und da beisst die Maus keinen Faden ab.... Alles andere ist bar jeglicher Realität.
Die "Hostilität" bezog sich auch eher auf den oben zitierten Blog ! Was dort drinsteht ist technisch gesehen schlicht falsch !
