HP NIC Teaming: Transmit Load Balancing verursacht Flood im Netzwerk

Manche Probleme möchte man einfach nicht haben. In diesem Fall ein teilweise bis zum Zusammenbruch ausgelastetes Layer-2-Netzwerk (Cisco) – völlig sporadisch, mal das gesamte Netzwerk, dann wieder nur einige Segmente betreffend. Folgendes Bild zeigt die Auslastung eines Switches (Cisco C2960G-24TC-L) während des Problems:

Zu sehen sind zehn Gigabit-Ports mit einer Auslastung von knapp 640 Mbps sowie zwei FastEthernet-Anschlüsse mit einer Auslastung von 100 Mbps. Die Quelle des Traffics musste also mit GbE senden. Zuerst denkt man bei sowas natürlich an einen Broadcast Storm – der durch aktiviertes Broadcast Strom Control auf den Switchen allerdings ausgeschlossen werden konnte. Es musste sich also um einen Flood von Unicast-Frames oder ein völlig unbekanntes Problem handeln.

Zunächst sollte der Verursacher des Traffics ausfindig gemacht werden. Nach Analyse einiger Problemfälle mittels PRTG Network Monitor war die Quelle gefunden: Mal war es ein Fileserver, dann ein SAP-Applikationsserver, an einem anderen Tag der FTP-Server – ein bunter Mix verschiedener Server! Warum waren es immer unterschiedliche Systeme? Was hatte sie zum Senden derart hoher Datenmengen bewegt?

Ein Mitschnitt des Traffics mit tcpdump förderte zumindest das Ziel der Pakete ans Tageslicht: Den Backup Exec Medienserver! Das erklärte schließlich die großen Datenmengen und die Tatsache, warum mehrere Server betroffen waren – alle wurden mit Backup Exec gesichert. Warum aber ging der Traffic nicht Punkt-zu-Punkt von der Quelle bis zum Medienserver und weshalb traten diese Symptome nur sporadrisch auf?

Bei dem Medienserver handelte es sich um einen HP ProLiant DL380 G3 mit Windows Server 2003 als Betriebssystem. Beide Netzwerkkarten waren mittels HP-Software im Teaming konfiguriert – und zwar im sogenannten „Transmit Load Balancing with Fault Tolerance“:

    Transmit Load Balancing with Fault Tolerance (TLB) is a team type that allows the server to load balance its transmit traffic. TLB is switch independent and supports switch fault tolerance by allowing the teamed ports to be connected to more than one switch in the same LAN. With TLB, traffic received by the server is not load balanced. The primary teamed port is responsible for receiving all traffic destined for the server. In case of a failure of the primary teamed port, the NFT mechanism ensures connectivity to the server is preserved by selecting another teamed port to assume the role.

Wie im obigen Text des HP ProLiant Network Adapter Teaming Whitepapers beschrieben, werden beide Netzwerkkarten zum Senden, aber nur eine zum Empfangen verwendet. Genau hier lag der Hase im Pfeffer.

  • NIC 1 vom Medienserver hatte die MAC-Adresse 000e.7f27.3df3 und war auf Switch 1.
  • NIC 2 vom Medienserver hatte die MAC-Adresse 000e.7f27.3df2 und war auf Switch 2.

Die Teamingsoftware erstellt für beide Netzwerkkarten ein virtuelles Interface mit der MAC-Adresse von NIC1. ARP-Requests werden ausschließlich mit dieser MAC-Adresse beantwortet, wodurch sichergestellt werden soll, dass Antworten den Server immer nur über ein- und dieselbe Netzwerkkarte erreichen (in diesem Fall NIC1).

Alle vom Medienserver generierten Frames hatten laut Wireshark (beim Sniffen des virtuellen Interfaces) diese MAC als Quelladresse. Der Teaming-Treiber nimmt dann später die Lastverteilung auf beide Netzwerkkarten vor und ändert die Quell-MAC-Adresse in die tatsächliche MAC-Adresse der sendenden NIC.

Jetzt aber zum Problem – zuerst getestet und reproduziert habe ich es mit einem Ping. Um eine saubere Ausgangssituation zu schaffen, habe ich dazu auf dem Switch des Fileservers (nennen wir ihn mal Switch 3) alle dynamischen Einträge aus seiner MAC-Address-Table entfernt und auf dem Fileserver den ARP-Cache geleert. Anschließend habe ich auf dem Fileserver einen Ping auf den Medienserver abgesetzt:

  1. Der Fileserver broadcastet einen ARP-Request, um die MAC-Adresse des Medienservers herauszubekommen.
  2. Der Medienserver antwortet auf den ARP-Request und schreibt in sein ARP-Reply, dass er über die MAC-Adresse 000e.7f27.3df3 der virtuellen NIC (physikalisch NIC1) erreichbar ist. Der ARP-Reply wird via Transmit Load Balancing über NIC2 verschickt und kommt damit auf dem Fileserver von der Quell-MAC 000e.7f27.3df2 an und nicht von der MAC-Adresse, die im Payload des ARP-Replies steht.

    In der MAC-Address-Table von Switch 3 existiert dadurch ein Eintrag für die MAC-Adresse 000e.7f27.3df2 (NIC2 des Medienservers). Dagegen wird in der ARP-Tabelle des Fileservers ein Eintrag für die MAC-Adresse des Medienservers erstellt, der der Information aus dem Payload des ARP-Replies entspricht (000e.7f27.3df3e).

  3. Der Fileserver sendet den ersten ICMP-Request an die in seiner ARP-Tabelle stehende MAC-Adresse 000e.7f27.3df3 des Medienservers.

    Da Switch 3 noch keinen Eintrag für 000e.7f27.3df3 in seiner Tabelle hat, wird das Frame an alle Ports geflooded.

  4. Das gefloodete Frame mit dem ICMP-Request erreicht den Medienserver und dieser sendet sein ICMP-Reply via Load Balancing dieses Mal über NIC1 mit der Quell-MAC 000e.7f27.3df3 zum Fileserver.

    In der MAC-Address-Table von Switch 3 entsteht dadurch ein Eintrag für die MAC-Adresse 000e.7f27.3df3 und ab diesem Zeitpunkt erfolgt die Kommunikation zwischen beiden Servern Punkt-zu-Punkt (jedenfalls solange sich beide Netzwerkkarten des Medienservers tatsächlich mit dem Senden abwechseln und die MAC-Adresse von NIC1 nicht aus der Tabelle von Switch 3 verschwindet)

Soweit so gut – in folgender Konstellation kam es aber zum beschriebenen Problem:

  • Der Fileserver hatte bereits einen Eintrag für den Medienserver in seiner ARP-Tabelle.
  • Auf Switch 3 war kein Eintrag in der MAC-Address-Table vorhanden.

In diesem Fall war es (warum auch immer) so, dass die vom Fileserver an die MAC-Adresse 000e.7f27.3df3 gesendeten Frames vom Medienserver ausschließlich über NIC2 beantwortet wurden. Aus diesem Grund hatte Switch 3 für die MAC-Adresse 000e.7f27.3df3 natürlich keinen Eintrag in seiner Tabelle, sondern ausschließlich für 000e.7f27.3df2.

Infolgedessen kannte Switch 3 den Weg zu 000e.7f27.3df3 nicht und hat alle Frames mit dieser Zieladresse an alle Ports geflooded. Die Switches hinter dem Uplink von Switch 3 dagegen hatten noch einen Eintrag für die MAC-Adresse 000e.7f27.3df3 in ihrer Tabelle, weshalb der Traffic ab da wieder Punkt-zu-Punkt war. Das erklärt, warum das Problem nur sporadisch aufgetreten ist – mal war auf dem zu sichernden Server vor dem Backup bereits ein Eintrag in der ARP-Tabelle vorhanden, mal nicht.

Außerdem erklärt es, warum der Traffic auch manchmal an alle Switche und Ports innerhalb der gesamten Broadcastdomäne gegangen ist – nämlich immer dann, wenn auf keinem Switch im Netzwerk ein Eintrag für die MAC-Adresse 000e.7f27.3df3 vorhanden war. In so einem Fall wurde immer geflooded. Und zwar solange, bis irgendwann zufällig NIC1 vom Medienserver wieder etwas gesendet hat und somit Einträge in den Tabellen der Switche erstellt worden sind.

Abschließend bleibt also zu sagen, dass derartige Varianten eines Teamings immer mit Vorsicht zu genießen sind. Switche lernen die MAC-Adressen anhand der Frames, die sie auf ihren Ports empfangen. Wenn allerdings die für den Empfang designierte Netzwerkkarte eines Servers nie sendet, weiß kein anderes Gerät, über welchen Pfad die NIC erreichbar ist.

Im Zweifel sollte man sich immer m.E. immer für möglichst einfache und wenig fehleranfällige Konfigurationen entscheiden. Ist eine entsprechende Sonderkonfiguration z.B. aufgrund gestiegender Anforderungen an die Performance erforderlich, muss das Vorgehen genau evaluiert werden. In diesem Fall sind die Probleme nach Auflösung des Teamings jedenfalls nicht wieder aufgetreten und es kam zu keinerlei Einbußen hinsichtlich der Performance.

3 Responses to “HP NIC Teaming: Transmit Load Balancing verursacht Flood im Netzwerk”


  1. 1 MCBurner März 21, 2012 um 3:45 pm

    Ein sehr guter Beitrag mit hilfreichen Details. Ich bin vor Kurzem über exakt die gleiche Problematik gestolpert und wundere mich noch immer, warum Wundermittel „google“ bei Stichworten wie Arcserve Backup, port flooding, cisco, layer2 so gut wie nichts ausspuckt.
    Der Sache gebührt besondere Aufmerksamkeit!

  2. 3 sean Juli 24, 2012 um 11:40 am

    sehr guter artikel, danke!


Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





%d Bloggern gefällt das: