HP Procurve 1800 Switch-to-Switch-Trunks und LACP (und auch VLANs!)

HP Procurve 1800 Switch-to-Switch-Trunks und LACP (und auch VLANs!)

Ich überlege, zwei (und eventuell drei) HP Procurve 1800 Switches über Trunks oder mit LACP zu verbinden. Weder bei Google noch hier finde ich eine substantielle Antwort auf meine Fragen.

Ich habe diese Frage gefundenServer-zu-Switch-Trunking im Procurve-Switch, was bedeutet das?aber die Antwort auf die Frage scheint zu sein: a) Trunking könnte alles bedeuten; und b) LACP ist definiert. Die FrageWird ein Trunk oder ein LACP bevorzugt?wird nicht beantwortet - und es handelt sich nicht um Switch-zu-Switch, sondern um Switch-zu-Server.

Ich fand auch diese FrageFrage zum LAN-Design mit HP Procurveaber es beantwortet auch nicht die oben gestellte Frage:Wird ein Trunk oder ein LACP bevorzugt?Diese Frage ist in jedem Fall für den HP Procurve 2510 und nicht für den HP 1800 relevant.

Keine dieser Fragen scheint unsere genaue Situation zu beschreiben. Es gibt drei Switches (alle HP 1800):

SW1(VLAN1) <-> SW2(VLAN1) <-> SW3(VLAN1)
               SW2(VLAN6) <-> SW3(VLAN6)

Die Switches sind alle HP 1800-24G (Hardwareversion R01) mit den folgenden Softwareversionen:

  • SW1: PB.03.01
  • SW2: PB.03.01
  • SW3: PB.03.04

Die Verbindungen zwischen den Switches SW2 und SW3 erlauben alle nur markierte Pakete und haben keine PVID (gemäß den Empfehlungen der Hilfedokumentation). Andere Ports sind entweder VLAN 1 oder VLAN 6 und erlauben alle Pakete. Alle Ports werden automatisch ausgehandelt, mit Ausnahme der gelegentlichen 100-MB-Vollduplex-Einstellungen; andere sind alle 1 GB – keiner ist 10 MB.

Das Problem ist, dass SW2 nicht schnell auf Pings zu reagieren scheint und häufig Pakete verliert (wie vom Überwachungshost auf SW3 überwacht). Andere Switches sind in Ordnung und reagieren angemessen. Die Verbindung zwischen den Hosts scheint in Ordnung zu sein. Die HTTP-Antwort von SW1 und SW2 auf ihren Verwaltungsschnittstellen scheint langsam – langsamer als SW3.

Ich vermute einen Verkehrsengpass und möchte eine größere Leitung einrichten. Die Pings gehen an die IP-Adresse des Switches, und Verbindungen zum HTTP-Port zeigen ebenfalls langsame Antwortzeiten. Vermutlich befinden sich die Verbindungen (HTTP und ICMP) auf VLAN1, da dort die IP liegen würde – und VLAN1 ist ohnehin das Verwaltungs-VLAN.

Aus anderen Fragen geht hervor, dass ein „Trunk“ es ermöglichen würde, den Datenverkehr für beide VLANs auf demselben Kabel zu kombinieren – die beiden Verbindungen auf eine zu reduzieren oder den Datenverkehr über mehrere Kabel für mehrere VLANs laufen zu lassen. Es klingt auch so, als könnten Trunks mit LACP kombiniert werden, aber ist das wünschenswert?

Meine Fragen:

  1. Ist in dieser Situation ein Trunk oder LACP vorzuziehen? Warum?
  2. Was bezeichnet HP in diesem Fall als „Kofferraum“?
  3. Wie sollten die VLANs in dieser Situation behandelt werden?
  4. Versuche ich, das falsche Problem zu lösen?
  5. Würde ein Firmware-Upgrade helfen?

Ich hätte auf jeden Fall gerne auf alle Fragen eine Antwort.

AKTUALISIERENIch habe vergessen zu erwähnen, dass ich fanddiese Webseitedas schien hilfreich, beantwortete meine Fragen aber auch nicht direkt. Es klingt (aus den Antworten dort) so, als ob Trunking für die Kommunikation zwischen Switches und LACP für die Kommunikation zwischen Servern und Switches gedacht ist.

Antwort1

LACP ist das Link Aggregation Control Protocol. Es geht darum, Link Aggregation automatisch und dynamisch einzurichten, wenn mehr als ein Link verfügbar ist und die andere Seite auch LACP spricht. EsIstWird mit redundanter Server-Switch-Verbindung verwendet, da ein statisches Setup mit Link Aggregation die Serverkonnektivität unterbrechen würde, solange die NIC-Treiber (bei denen Link Aggregation implementiert ist) nicht geladen wurden, wodurch die Serververwaltung vor dem Booten oder die Netzwerkbootfunktionen effektiv unterbrochen würden.

Für Switch-Verbindungen wird normalerweise ein statischer Aufbau bevorzugt – obwohl ich das als reine Geschmacksfrage bezeichnen würde.

„Link Aggregation“ und „Trunking“ werden normalerweise synonym verwendet. Es gibt einen definierten IEEE-Standard für LA (802.3ad) und viele proprietäre Erweiterungen von Anbietern sind vor der Standardisierung entstanden, von denen die meisten aus Gründen der Abwärtskompatibilität sogar in neueren Switch-Modellen implementiert sind.

Wenn Sie eine Link Aggregation oder Trunk Group (LAG/TG) einrichten, sollten Sie für die Switches auf beiden Seiten dieselben VLANs als Mitglieder der Gruppe definieren. Mehr als einen Pfad (also mehr als eine LAG-Verbindung) zwischen zwei Switches sollten Sie nur dann definieren, wenn Sie a) genau wissen, was Sie tun und b) STP auf beiden verbundenen Switches aktiviert haben.

Wenn Sie nur einen Bandbreitenengpass vermuten, verwenden Sie die Portstatistikzähler Ihrer Switches, um dies zu überprüfen. Es ist durchaus möglich, dass die Bandbreitennutzung in Ordnung ist und Ihr Problem ein völlig anderes ist. Meistens haben Switches eher langsame CPUs und schnelle ASICs, die den Großteil der Verarbeitung ohne Belastung der CPU durchführen können. Einige Vorgänge würden dennoch CPU-Zyklen verbrauchen. Ein recht „beliebter“ Vorgang ist der Empfang von Broadcasts oder Multicast-Paketen. Wenn Ihr Netzwerk viel Broadcast-/Multicast-Verkehr erzeugt, kann die Verarbeitung und Verwerfung der Pakete selbst die CPU eines Switches über Gebühr belasten. Überprüfen Sie erneut die Zähler, um festzustellen, ob im Netz eine übermäßige Anzahl von Broadcasts zu sehen ist.

Antwort2

Im HP ProVision-Betriebssystem hat der Begriff „Trunk“ eine andere Bedeutung als der Cisco-Begriff „Trunk“

  • Nicht-802.1Q-Schnittstellen (wie Computer oder Drucker) werden alsUNTAGGEDmit ProVision und bei Cisco alsZUGANGHafen.
  • 802.1Q-Schnittstellen (wie Switch-to-Switch, Switch-to-Server und Switch-to-VoIP-Telefone) werden alsTAGGEDPort mit ProVision, und Cisco ist einSTAMMHafen.
  • Aggregierte Schnittstellen werden alsSTAMMPort mit ProVision, aberEtherkanalmit Cisco.

verwandte Informationen