43292
29.09.2011, aktualisiert am 18.10.2012
31396
12
1
Link Aggregation zur Speederhöhung zwischen 2 Switches herstellen
Hallo miteinander,
obwohl ich nun einiges an Material durchgelesen habe, hab ich noch einige Fragen zum Thema Link Aggregation und hoffe ein paar Profis von euch können mich etwas aufklären. Zum Szenario und meiner Idee:
Ich hab einen ProCurve 1800-24g Switch, der laut Anleitung LACP 802.3ad unterstützt, sowohl mit statischen Trunks als auch dynamischer Link Aggregation. In diesem Switch stecken all meine Clients.
Ich hab einen zweiten Switch, Dell PowerConnect 2724, der laut Anleitung "Link Aggregation" kann. In diesem Switch stecken all meine Server.
Leider steht im PDF nix vom genutzten Standard, und ob der 802.3ad unterstützt. Es steht nur was von LAG (Link Aggregation Group). Ich hab ein PDF gefunden, da steht unter anderem zum Dell PowerConnect Switch folgendes:
[quote]
LAGs
A Link Aggregated Group (LAG) is composed of ports with the same speed, set to full-duplex
operation. Up to six Aggregated Links may be defined, each with up to four member ports, to form
a single Link Aggregated Group (LAG). This enables:
• Fault tolerance protection from physical link disruption
• Higher bandwidth connections
• Improved bandwidth granularity
• High bandwidth server connectivity
With the departmental PowerConnect 2708/2716/2724 switches installed, network redundancy and
improved traffic performance are facilitated. The PowerConnect device serves to connect the
departmental groups of users to another switch that is located on another floor. In addition, LAGs
are used to ensure that a backup, in case one line is disabled.
Link Aggregation optimizes port usage by linking a group of ports together to form a single LAG
(aggregated group). Aggregating ports multiplies the bandwidth between the devices, increases
port flexibility, and provides link redundancy.
Consider the following when aggregating ports:
• Link Aggregation is allowed between two devices only.
• All ports within a LAG must be the same media type.
• A VLAN is not configured on the port.
• The port is not assigned to a different LAG.
• An available MAC address exists which can be assigned to a port.
• Auto-negotiation mode is not configured on the port.
• The port is in full-duplex mode.
• All ports in the LAG have the same ingress filtering and tagged modes.
• All ports in the LAG have the same back pressure and flow control modes.
• All ports in the LAG have the same priority.
• All ports in the LAG have the same transceiver type.
• The device supports up to six LAGs, and up to four ports in each LAG.
Ports added to a LAG do not their individual port configuration. When ports are removed from the
LAG, the original port configuration is applied to the ports. The device considers an Aggregated
Link a single logical port.
[/quote]
Wie auch immer. Ich hatte eigentlich folgende Idee, und würde gerne wissen, ob das grundsätzlich möglich sei, oder ob es Probleme bereiten könnte. Ich habe zwischen den zwei Switches insgesamt 4 physikalische Netzwerkkabel zur Verfügung. Bisher verbindet nur ein Netzwerkkabel die zwei Switches. Dieses Kabel steckt in beiden Switches in Port1. Port2-4 sind momentan noch frei. Ich wollte überhaupt erstmal wissen, ob die Verbindung zwischen den zwei Switches in Geschwindigkeit und FailSafe erhöht werden könnte, wenn ich alle 4 Kabel zusammen verwende (also wenn ich auch Port2,3 und 4 miteinander verbinde.
Wenn ich das ohne LACP machen würde, hätte ich bestimmt Netzwerkprobleme, weil die Switches nicht wüssten, über welche der 4 Kabel sie gehen sollen, oder nicht?
Nun, angenommen ich könnte mit meiner jetztigen Hardware Link Aggregation doch verwenden, stellt sich für mich die Frage, wie ich das korrekt konfigurieren müsste. Als allererstes habe ich dabei auf beiden Switches die Ports 1-4 bereits wie folgt konfiguriert: Autonegotiation=OFF, Speed=1000MBit/s, DuplexMode=FULL und FlowControl=OFF. JumboFrames sind auf beiden Switches aktiviert.
Im ProCurve habe ich natürlich die volle 802.3ad LACP Unterstützung, das heisst ich kann zwischen 6 verschiedenen Load-Balancing Modi wählen, egal ob ich statische oder dynamische Trunks verwende: SMAC, DMAC, SMAC XOR DMAC, SMAC XOR DMAC XOR IP-Info, Pseudo-randomized, IP-Info. Die Beschreibung habe ich zwar durchgelesen, aber ich verstehe das Prinzip nicht, vielleicht kann mir das jemand erklären und wie ich mich für den passenden Modus entscheiden müßte.
Im Dell-Switch finde ich solche Einstellungen nicht. Da kann ich lediglich eine LAG1 erstellen, und dieser die Ports 1-4 hinzufügen. Toll, jetzt habe ich 'ne Gruppe erstellt, aber woher weiß der Dell wie er das handhaben soll und dass er über diesen Link mit dem ProCurve korrekt kommuniziert?
Fragen über Fragen, vielleicht kann mir der eine oder andere ein wenig unter die Arme greifen und etwas Licht ins Dunkle bringen.
Bin für jede Anregung, Hilfestellung und Tips sehr dankbar.
Grüße,
Michael.
obwohl ich nun einiges an Material durchgelesen habe, hab ich noch einige Fragen zum Thema Link Aggregation und hoffe ein paar Profis von euch können mich etwas aufklären. Zum Szenario und meiner Idee:
Ich hab einen ProCurve 1800-24g Switch, der laut Anleitung LACP 802.3ad unterstützt, sowohl mit statischen Trunks als auch dynamischer Link Aggregation. In diesem Switch stecken all meine Clients.
Ich hab einen zweiten Switch, Dell PowerConnect 2724, der laut Anleitung "Link Aggregation" kann. In diesem Switch stecken all meine Server.
Leider steht im PDF nix vom genutzten Standard, und ob der 802.3ad unterstützt. Es steht nur was von LAG (Link Aggregation Group). Ich hab ein PDF gefunden, da steht unter anderem zum Dell PowerConnect Switch folgendes:
[quote]
LAGs
A Link Aggregated Group (LAG) is composed of ports with the same speed, set to full-duplex
operation. Up to six Aggregated Links may be defined, each with up to four member ports, to form
a single Link Aggregated Group (LAG). This enables:
• Fault tolerance protection from physical link disruption
• Higher bandwidth connections
• Improved bandwidth granularity
• High bandwidth server connectivity
With the departmental PowerConnect 2708/2716/2724 switches installed, network redundancy and
improved traffic performance are facilitated. The PowerConnect device serves to connect the
departmental groups of users to another switch that is located on another floor. In addition, LAGs
are used to ensure that a backup, in case one line is disabled.
Link Aggregation optimizes port usage by linking a group of ports together to form a single LAG
(aggregated group). Aggregating ports multiplies the bandwidth between the devices, increases
port flexibility, and provides link redundancy.
Consider the following when aggregating ports:
• Link Aggregation is allowed between two devices only.
• All ports within a LAG must be the same media type.
• A VLAN is not configured on the port.
• The port is not assigned to a different LAG.
• An available MAC address exists which can be assigned to a port.
• Auto-negotiation mode is not configured on the port.
• The port is in full-duplex mode.
• All ports in the LAG have the same ingress filtering and tagged modes.
• All ports in the LAG have the same back pressure and flow control modes.
• All ports in the LAG have the same priority.
• All ports in the LAG have the same transceiver type.
• The device supports up to six LAGs, and up to four ports in each LAG.
Ports added to a LAG do not their individual port configuration. When ports are removed from the
LAG, the original port configuration is applied to the ports. The device considers an Aggregated
Link a single logical port.
[/quote]
Wie auch immer. Ich hatte eigentlich folgende Idee, und würde gerne wissen, ob das grundsätzlich möglich sei, oder ob es Probleme bereiten könnte. Ich habe zwischen den zwei Switches insgesamt 4 physikalische Netzwerkkabel zur Verfügung. Bisher verbindet nur ein Netzwerkkabel die zwei Switches. Dieses Kabel steckt in beiden Switches in Port1. Port2-4 sind momentan noch frei. Ich wollte überhaupt erstmal wissen, ob die Verbindung zwischen den zwei Switches in Geschwindigkeit und FailSafe erhöht werden könnte, wenn ich alle 4 Kabel zusammen verwende (also wenn ich auch Port2,3 und 4 miteinander verbinde.
Wenn ich das ohne LACP machen würde, hätte ich bestimmt Netzwerkprobleme, weil die Switches nicht wüssten, über welche der 4 Kabel sie gehen sollen, oder nicht?
Nun, angenommen ich könnte mit meiner jetztigen Hardware Link Aggregation doch verwenden, stellt sich für mich die Frage, wie ich das korrekt konfigurieren müsste. Als allererstes habe ich dabei auf beiden Switches die Ports 1-4 bereits wie folgt konfiguriert: Autonegotiation=OFF, Speed=1000MBit/s, DuplexMode=FULL und FlowControl=OFF. JumboFrames sind auf beiden Switches aktiviert.
Im ProCurve habe ich natürlich die volle 802.3ad LACP Unterstützung, das heisst ich kann zwischen 6 verschiedenen Load-Balancing Modi wählen, egal ob ich statische oder dynamische Trunks verwende: SMAC, DMAC, SMAC XOR DMAC, SMAC XOR DMAC XOR IP-Info, Pseudo-randomized, IP-Info. Die Beschreibung habe ich zwar durchgelesen, aber ich verstehe das Prinzip nicht, vielleicht kann mir das jemand erklären und wie ich mich für den passenden Modus entscheiden müßte.
Im Dell-Switch finde ich solche Einstellungen nicht. Da kann ich lediglich eine LAG1 erstellen, und dieser die Ports 1-4 hinzufügen. Toll, jetzt habe ich 'ne Gruppe erstellt, aber woher weiß der Dell wie er das handhaben soll und dass er über diesen Link mit dem ProCurve korrekt kommuniziert?
Fragen über Fragen, vielleicht kann mir der eine oder andere ein wenig unter die Arme greifen und etwas Licht ins Dunkle bringen.
Bin für jede Anregung, Hilfestellung und Tips sehr dankbar.
Grüße,
Michael.
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: 173909
Url: https://administrator.de/contentid/173909
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
12 Kommentare
Neuester Kommentar
Die Bezeichnung "LAG" ist nichts anderes als ein Oberflächlicher Begriff wie "Trunking" sagt also rein gar nix aus.
Vielleicht hilft das etwas weiter zum Verständnis:
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Die Geschwindigkeit erhöhst du natürlich nicht, denn du kannst den physischen Speed des Links ja logischerweise nicht erhöhen.
Was passiert ist eine reine Verteilung der Layer 2 Mac Sessions auf Basis der Mac Adresse (oder IP) auf alle verfügbaren Links.
Die Güte der Verteilung ist dabei zwangsläufig von der Anzahl der Macs abhängig. Viele Macs gute Verteilung.
Du verteilst die bestehenden Sessions also lediglich auf die vorhandenen parallele Links um sie weniger zu belasten. Mehr macht Trunking nicht !
Jede Session wird immer mit dem Speed der einzelnen verbindung übertragen, nicht schneller ! Geht ja auch gar nicht !
Viele Switchhersteller lassen auch noch weitere Kriterien wie TCP oder UDP Ports in die Hashberechnung mit einfliessen um so einen granularere Verteilung auf den Links zu erreichen.
Bei deinen Billgprodukten ist das aber nicht der Fall da wird nur schlicht und einfach die letzten 4 Bits der Mac geXORed und gut iss. Darf ja bei den Billigheimern Dell und Procurve nix kosten.... Sieht man auch an der sehr mickrigen Skalierbarkeit von 4 Links pro Gruppe und die Begrenzung auf max. 6 Gruppen. Andere liegen da bei 8 Links und 32 Gruppen und mehr. Aber in dem Preisbereich schafft die schwachbrüstige Switchhardware nicht mehr.
Vermutlich halten sich aber beide an den 802.3ad Standard was das Hashing anbetrifft. LACP vermutlich auch, damit werden aggregierte Links dynamisch ausgehandelt bei den Partnern. Genaues sagt dir das Datenblatt zur Hardware.
Bei den statischen Links musst du aufpassen das du dort nicht die Ports verwechselst und Spanning Tree aktiviert hast. Das Hashing ist das gleiche !
Vielleicht hilft das etwas weiter zum Verständnis:
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Die Geschwindigkeit erhöhst du natürlich nicht, denn du kannst den physischen Speed des Links ja logischerweise nicht erhöhen.
Was passiert ist eine reine Verteilung der Layer 2 Mac Sessions auf Basis der Mac Adresse (oder IP) auf alle verfügbaren Links.
Die Güte der Verteilung ist dabei zwangsläufig von der Anzahl der Macs abhängig. Viele Macs gute Verteilung.
Du verteilst die bestehenden Sessions also lediglich auf die vorhandenen parallele Links um sie weniger zu belasten. Mehr macht Trunking nicht !
Jede Session wird immer mit dem Speed der einzelnen verbindung übertragen, nicht schneller ! Geht ja auch gar nicht !
Viele Switchhersteller lassen auch noch weitere Kriterien wie TCP oder UDP Ports in die Hashberechnung mit einfliessen um so einen granularere Verteilung auf den Links zu erreichen.
Bei deinen Billgprodukten ist das aber nicht der Fall da wird nur schlicht und einfach die letzten 4 Bits der Mac geXORed und gut iss. Darf ja bei den Billigheimern Dell und Procurve nix kosten.... Sieht man auch an der sehr mickrigen Skalierbarkeit von 4 Links pro Gruppe und die Begrenzung auf max. 6 Gruppen. Andere liegen da bei 8 Links und 32 Gruppen und mehr. Aber in dem Preisbereich schafft die schwachbrüstige Switchhardware nicht mehr.
Vermutlich halten sich aber beide an den 802.3ad Standard was das Hashing anbetrifft. LACP vermutlich auch, damit werden aggregierte Links dynamisch ausgehandelt bei den Partnern. Genaues sagt dir das Datenblatt zur Hardware.
Bei den statischen Links musst du aufpassen das du dort nicht die Ports verwechselst und Spanning Tree aktiviert hast. Das Hashing ist das gleiche !
Hallo Aqui und danke soweit,
es wundert mich nicht, von dir eine Antwort hier zu bekommen
denn die von dir genannten Links hatte ich bereits alle gelesen (eigentlich so ziemlich alles was mit Link Aggregation zu tun hatte hier im Forum). Dabei ist mir natürlich deine rege Teilnahme sofort aufgefallen. Ich meinte auch eigentlich "Datendurchsatz erhöhen" und nicht Geschwindigkeit erhöhen. Du hast natürlich Recht, die physikalische Speed kann ja nicht einfach so erhöht werden. Leider helfen mir die Links nicht wirklich weiter, beim Auswählen der richtigen Hash-Bestimmung. Es ist ja (leider Gottes) kein Cisco-Router, damit ich die Befehle vom anderen Thread zur Hilfestellung heranziehen könnte, sondern lediglich (wie du richtig sagtest) ein BILLIGPRODUKT *seufz*. Ich habe auf wikipedia zu Link Aggregation gelesen, als auch diesen WiKi hier reingezogen und detaillierter noch wegen der Lastverteilungs-Berechnung.
http://de.wikipedia.org/wiki/Link_Aggregation
http://www.thomas-krenn.com/de/wikiDE/index.php?title=Link_Aggregation_ ...
http://www.thomas-krenn.com/de/wiki/Link_Aggregation_Lastverteilungs-Al ...
Ich hab eigentlich noch folgende Fragen offen, bzw. stehe auf dem Schlauch. Verwenden möchte ich natürlich gerne dynamische Link Aggregation, also LACP.
1.) im DELL Switch habe ich bereits eine LAG Nr. 1 gebildet, und die Ports 1-4 hinzugefügt. Anschliessend kann ich die LAG Nr.1 wie ein eigenes Interface behandeln, dementsprechend habe ich dieser Gruppe sicherheitshalber nochmal gesagt, dass Autoneg.=OFF, FDX=ON, und FlowControl=OFF sein soll. Der DELL jedoch bietet mir keine Möglichkeit wegen dieser HASH-Berechnungs-Geschichte. Das kann nur mein ProCurve. Langt es wenn ich diese Daten nur im ProCurve eingebe? Tauschen sich die zwei Switches dann irgendwie aus, oder woher soll der Dell Switch wissen was er zu tun hat? Wie kann ich anschließend überprüfen, ob alles gut gelaufen ist?
2.) Wenn ich mir den ProCurve anschaue (also in den Settings der Weboberfläche) dann kann ich z.B. LACP aktivieren, aber nur auf den Ports, die bisher nicht als Trunking Ports konfiguriert wurden. LACP wäre doch das einfachste, wenn ich es richtig verstanden habe, oder? Damit würde sich der Switch automatisch über das Link Aggregation Control Protocol mit dem anderen Switch verständigen und den korrekten Link herstellen. Ich hab mal testweise in den LACP-Einstellungen im ProCurve das LACP für Port 1,2,3,4 aktiviert mit dem key value=0 (bedeutet er generiert automatisch den key). Apply gedrückt und mir den LACP status angeguckt. Wie ich vermutet habe, steht da keine Gegenstelle drin, mit der erfolgreich über LACP der Link hergestellt wurde. Wie auch, wenn mein beschissener Dell womöglich kein LACP kann
Also hab ich LACP wieder deaktiviert. Ich könnte jetzt im ProCurve in den Trunk-Settings folgendes machen. Ich wähle für den Trunk1 die Ports1,2,3,4 und übernehme die Einstellung (trotz Warnung dass Port1+2 im selben trunk sind, siehe Anhang am Ende). Soweit ok, der Trunk1 ist also nun erstellt, und beinhaltet die Ports 1-4. Als Hash-Methode habe ich die SMAC XOR DMAC gewählt, aber dazu später mehr.
Wie zum Geier weiß ich nun ob der Link steht und ob alles so funktioniert wie es sollte?
3.) welche Hash-Methode würdest du mir denn empfehlen? Am Dell-Switch hängen momentan ca. 12 Server/Geräte. Am ProCurve-Client-Switch hängen 24 Clients. Sollte ich SMAC XOR DMAC belassen, oder wäre evtl. SMAC XOR DMAC XOR IP-Info besser? Evtl. auch Pseudo-randomized? Ich wüßte echt nicht, welchen Wert ich verwenden sollte.
Hoffe ihr könnt mir helfen.
Danke nochmals.
Michael.
Anhang (Warnmeldung):
Caution: The switch has detected that ports 1 and 2 are in the same trunk, which is not recommended. If the switches that use this trunk reboot at the same time, the switch configuration settings may be reset to factory-default values. Do you want to continue?
Ich versteh das nicht, warum er das sagt. Was haben Port 1 + 2 so besonderes an sich? Was für n Switch-Rebooten meint der?
es wundert mich nicht, von dir eine Antwort hier zu bekommen
denn die von dir genannten Links hatte ich bereits alle gelesen (eigentlich so ziemlich alles was mit Link Aggregation zu tun hatte hier im Forum). Dabei ist mir natürlich deine rege Teilnahme sofort aufgefallen. Ich meinte auch eigentlich "Datendurchsatz erhöhen" und nicht Geschwindigkeit erhöhen. Du hast natürlich Recht, die physikalische Speed kann ja nicht einfach so erhöht werden. Leider helfen mir die Links nicht wirklich weiter, beim Auswählen der richtigen Hash-Bestimmung. Es ist ja (leider Gottes) kein Cisco-Router, damit ich die Befehle vom anderen Thread zur Hilfestellung heranziehen könnte, sondern lediglich (wie du richtig sagtest) ein BILLIGPRODUKT *seufz*. Ich habe auf wikipedia zu Link Aggregation gelesen, als auch diesen WiKi hier reingezogen und detaillierter noch wegen der Lastverteilungs-Berechnung.http://de.wikipedia.org/wiki/Link_Aggregation
http://www.thomas-krenn.com/de/wikiDE/index.php?title=Link_Aggregation_ ...
http://www.thomas-krenn.com/de/wiki/Link_Aggregation_Lastverteilungs-Al ...
Ich hab eigentlich noch folgende Fragen offen, bzw. stehe auf dem Schlauch. Verwenden möchte ich natürlich gerne dynamische Link Aggregation, also LACP.
1.) im DELL Switch habe ich bereits eine LAG Nr. 1 gebildet, und die Ports 1-4 hinzugefügt. Anschliessend kann ich die LAG Nr.1 wie ein eigenes Interface behandeln, dementsprechend habe ich dieser Gruppe sicherheitshalber nochmal gesagt, dass Autoneg.=OFF, FDX=ON, und FlowControl=OFF sein soll. Der DELL jedoch bietet mir keine Möglichkeit wegen dieser HASH-Berechnungs-Geschichte. Das kann nur mein ProCurve. Langt es wenn ich diese Daten nur im ProCurve eingebe? Tauschen sich die zwei Switches dann irgendwie aus, oder woher soll der Dell Switch wissen was er zu tun hat? Wie kann ich anschließend überprüfen, ob alles gut gelaufen ist?
2.) Wenn ich mir den ProCurve anschaue (also in den Settings der Weboberfläche) dann kann ich z.B. LACP aktivieren, aber nur auf den Ports, die bisher nicht als Trunking Ports konfiguriert wurden. LACP wäre doch das einfachste, wenn ich es richtig verstanden habe, oder? Damit würde sich der Switch automatisch über das Link Aggregation Control Protocol mit dem anderen Switch verständigen und den korrekten Link herstellen. Ich hab mal testweise in den LACP-Einstellungen im ProCurve das LACP für Port 1,2,3,4 aktiviert mit dem key value=0 (bedeutet er generiert automatisch den key). Apply gedrückt und mir den LACP status angeguckt. Wie ich vermutet habe, steht da keine Gegenstelle drin, mit der erfolgreich über LACP der Link hergestellt wurde. Wie auch, wenn mein beschissener Dell womöglich kein LACP kann
Also hab ich LACP wieder deaktiviert. Ich könnte jetzt im ProCurve in den Trunk-Settings folgendes machen. Ich wähle für den Trunk1 die Ports1,2,3,4 und übernehme die Einstellung (trotz Warnung dass Port1+2 im selben trunk sind, siehe Anhang am Ende). Soweit ok, der Trunk1 ist also nun erstellt, und beinhaltet die Ports 1-4. Als Hash-Methode habe ich die SMAC XOR DMAC gewählt, aber dazu später mehr.
Wie zum Geier weiß ich nun ob der Link steht und ob alles so funktioniert wie es sollte?
3.) welche Hash-Methode würdest du mir denn empfehlen? Am Dell-Switch hängen momentan ca. 12 Server/Geräte. Am ProCurve-Client-Switch hängen 24 Clients. Sollte ich SMAC XOR DMAC belassen, oder wäre evtl. SMAC XOR DMAC XOR IP-Info besser? Evtl. auch Pseudo-randomized? Ich wüßte echt nicht, welchen Wert ich verwenden sollte.
Hoffe ihr könnt mir helfen.
Danke nochmals.
Michael.
Anhang (Warnmeldung):
Caution: The switch has detected that ports 1 and 2 are in the same trunk, which is not recommended. If the switches that use this trunk reboot at the same time, the switch configuration settings may be reset to factory-default values. Do you want to continue?
Ich versteh das nicht, warum er das sagt. Was haben Port 1 + 2 so besonderes an sich? Was für n Switch-Rebooten meint der?
1.) Ja, das langt. Jeder Switch arbeitet dann nach seinem Hashing und behält das bei. Hashing werden nur outgoing gesetzt also nicht incoming. Deshalb stört es also auch nicht wenn beide unterschiedliches machen sollten was sie aber sicher nicht tun. Default ist die XOR Verknüpfung der letzten 4 Bits der Mac Adresse.
2.) Ja das ist normal, denn LACP Ports sorgen selber dafür das die Ports zum Trunk werden wenn sie einen anderen LACP Link auf der anderen Seite detektieren. LACP macht das also dynamisch, da ist es logisch das er dann merckert wenn man das auf statischen Trunks machen will...wäre ja auch unsinnig, denn das einen schliesst das andere aus !
Wenn die Dell Gurke kein LACP kann hast du geloost... Dell wechschmeissen und was "richtiges" kaufen oder ganz einfach dann mit statischen Trunks arbeiten auf beiden Seiten...ist eh deine einzige Chance !
Checken ob die Links funktionieren kannst du indem du mal SNMP aktivierst und dir 4 kleine fensterchen dieser Applikation aufmachst:
http://www.wtcs.org/informant/stg.htm
Damit fragst du die Paket Counter OID der Ports 1 bis 4 ab und checkst ob sich die Last gleichmässig verteilt.
SNMP v2 werden deine beiden Billiggurken doch wohl hoffentlich supporten oder ??
Wenn das der Fall ist...Bingo ! Dann hast du gewonnen und deine statischen Trunks laufen.
Zur not kannst du auch mit 4 mal "show int eth 1 bis 4" das machen aber wer sowas macht zieht sich auch die Hose mit der Kneifzange an...die grafische SNMP Variante ist da erheblich schöner und übersichtlicher !!
3.) Die Hash Methode würd ich mal probieren, das ist schwer zu sagen.
Wie gesagt lass die SNMP Grafiken für die 4 Links laufen und sieh dir das an. Der hash der am besten verteilt den solltest du nehmen.
Ist ja eh nur einseitig auf dem HP da die Dell Gurke das ja gar nicht kann !!
2.) Ja das ist normal, denn LACP Ports sorgen selber dafür das die Ports zum Trunk werden wenn sie einen anderen LACP Link auf der anderen Seite detektieren. LACP macht das also dynamisch, da ist es logisch das er dann merckert wenn man das auf statischen Trunks machen will...wäre ja auch unsinnig, denn das einen schliesst das andere aus !
Wenn die Dell Gurke kein LACP kann hast du geloost... Dell wechschmeissen und was "richtiges" kaufen oder ganz einfach dann mit statischen Trunks arbeiten auf beiden Seiten...ist eh deine einzige Chance !
Checken ob die Links funktionieren kannst du indem du mal SNMP aktivierst und dir 4 kleine fensterchen dieser Applikation aufmachst:
http://www.wtcs.org/informant/stg.htm
Damit fragst du die Paket Counter OID der Ports 1 bis 4 ab und checkst ob sich die Last gleichmässig verteilt.
SNMP v2 werden deine beiden Billiggurken doch wohl hoffentlich supporten oder ??
Wenn das der Fall ist...Bingo ! Dann hast du gewonnen und deine statischen Trunks laufen.
Zur not kannst du auch mit 4 mal "show int eth 1 bis 4" das machen aber wer sowas macht zieht sich auch die Hose mit der Kneifzange an...die grafische SNMP Variante ist da erheblich schöner und übersichtlicher !!
3.) Die Hash Methode würd ich mal probieren, das ist schwer zu sagen.
Wie gesagt lass die SNMP Grafiken für die 4 Links laufen und sieh dir das an. Der hash der am besten verteilt den solltest du nehmen.
Ist ja eh nur einseitig auf dem HP da die Dell Gurke das ja gar nicht kann !!
Ok, LACP (automatische Aushandlung) kann ich wohl erden, da es der Dell-Hannes wohl nicht unterstützt (sonst hätte ich im LACP status ja gesehen, dass die Verbindung zustandekommt). Also bleiben mir die statischen Trunks. Habe ich ja auch gemacht, wie bereits erläutert. Aus den Ports 1-4 habe ich den Trunk1 gebildet mit SMAC XOR DMAC.
Du wirst lachen, der DELL kann tatsächlich kein SNMP, zumindest sehe ich definitiv nix davon im Web-Konfigurationsmenü. Beim Procurve habe ich mal SNMP aktiviert mit public string. Wenn ich mir jetzt das von dir genannte Tool downloade, dann starte ich stg.exe direkt (nicht die .bat, denn sonst öffnen sich ja die vordefinitierten Graphen, die mir nix bringen). In den Settings habe ich die IP des Procurves angegeben, er scheint sich auch zu verbinden. Aber wie sage ich ihm nun, was für Sachen er vom Switch abrufen soll? Ich hab von meinem ProCurve nen Haufen MIB Dateien, wenn das in Zusammenhang stehen sollte. Ich hab bisher mit SNMP nie gearbeitet, sorry.
Bringt das alles überhaupt was, wenn ich über SNMP nicht auf den DELL Switch komme? Wenn nicht, hat sich ja die Frage oben erübrigt, dann bräuchte ich auch gar nicht mit SNMP auf dem ProCurve schnüffeln.
Welche anderen Alternativen zum Testen meines statischen Links würden mir noch bleiben?
Danke für deiner Unterstützung.
PS: Kannst du mir einen max. 24port Switch bis max. 500-600 EUR empfehlen ?
Du wirst lachen, der DELL kann tatsächlich kein SNMP, zumindest sehe ich definitiv nix davon im Web-Konfigurationsmenü. Beim Procurve habe ich mal SNMP aktiviert mit public string. Wenn ich mir jetzt das von dir genannte Tool downloade, dann starte ich stg.exe direkt (nicht die .bat, denn sonst öffnen sich ja die vordefinitierten Graphen, die mir nix bringen). In den Settings habe ich die IP des Procurves angegeben, er scheint sich auch zu verbinden. Aber wie sage ich ihm nun, was für Sachen er vom Switch abrufen soll? Ich hab von meinem ProCurve nen Haufen MIB Dateien, wenn das in Zusammenhang stehen sollte. Ich hab bisher mit SNMP nie gearbeitet, sorry.
Bringt das alles überhaupt was, wenn ich über SNMP nicht auf den DELL Switch komme? Wenn nicht, hat sich ja die Frage oben erübrigt, dann bräuchte ich auch gar nicht mit SNMP auf dem ProCurve schnüffeln.
Welche anderen Alternativen zum Testen meines statischen Links würden mir noch bleiben?
Danke für deiner Unterstützung.
PS: Kannst du mir einen max. 24port Switch bis max. 500-600 EUR empfehlen ?
Sieh in die MIB Dateien, dort stehen die OIDs drin. Du brauchst die OID für die Paket Counter auf deinen 4 Interfaces. Das müsste eine Ethernet Standard OID sein.
Hammer das Dell nicht mal SNMP kann, das können ja sogar die billigsten D-Links und Longshines...aber egal.
Du kannst dann natürlich die Verteilung nur einseitig sehen.
Sinn macht das aber schon, denn du siehst ja auch die eingehenden Packete vom Dell am HP. Auch damit siehst du dann ob die Verteilung homogen passiert.
Wenn der Dell den Trunk nicht formen sollte wirst du auf einem Interface beim HP dann eine ungleich höhere Verteilung sehen.
Hammer das Dell nicht mal SNMP kann, das können ja sogar die billigsten D-Links und Longshines...aber egal.
Du kannst dann natürlich die Verteilung nur einseitig sehen.
Sinn macht das aber schon, denn du siehst ja auch die eingehenden Packete vom Dell am HP. Auch damit siehst du dann ob die Verteilung homogen passiert.
Wenn der Dell den Trunk nicht formen sollte wirst du auf einem Interface beim HP dann eine ungleich höhere Verteilung sehen.
Das mit den OIDs, den MIB-Files, und der SNMAP Geschichte leg ich mal beiseite weil ich definitiv keinen Plan von dieser OID und MIB Geschichte habe. Wie gesagt, hatte nie mit SNMP gearbeitet. Ich möchte meine LAG checken, und hab mir gedacht, ich zieh einfach netio zur Hilfe. Dabei checke ich ClientA<-->ServerA und ClientB<--->ServerB. Wenn ich die einzeln checke, erreiche ich vollen Speed (~105-max. 113 MByte/sec, was richtigerweise 900MBit/s entspricht), also bisher alles sauber. Wenn ich die Checks parallel, also GLEICHZEITIG ausführe, dann habe ich dadurch die Hälfte der Geschwindigkeit erreicht. Bedeutet also, dass diese gleichzeitigen zwei Checks über denselben Link stattgefunden haben und sich die 900MBit/s Leitung aufteilten. Ich hab nen ClientC als Testkandidat hinzugenommen und ihn statt ClientA testen lassen. Siehe da --> bei gleichzeitigem Testen hatte ich volle 900MBit/s, also für ClientB und ClientC gleichzeitig. Bedeutet doch also, dass die Checks ClientB und ClientC auf zwei verschiedenen Links stattgefunden haben. LAG funktionierte dann meiner Meinung nach (bitte ggf. berichtigen!)
nun zu meinem Problem und Fragestellung:
(1.) Frage:
Welche Methode muss ich anwenden, damit der Switch die Daten nach der Last checkt, und so die zwei lasthöchsten Clients jeweils auf einen eigenen physikalischen Link verteilt? Mit SMAC oder DMAC bringts ja nix wie wir im obigen Beispiel gesehen haben. Selbst mit pseudo-randomized war ich nicht ganz zufrieden. Da sah die Sache halt wieder anders aus: ClientA und ClientB konnten full speed gleichzeitig erreichen, aber ClientA und ClientC nicht, sondern nur fullspeed half-duplex, also beim Tx war full speed, aber beim Empfang nicht. Also: wie genau managed diese LAG das eigentlich? Wie lange behält ein Client seine Zuweisung an einen Port eigentlich bei, wie schnell oder langsam wechselt so was? Weiß das jemand und kann mir helfen? Ich möchte dem Switch verständlich machen, dass er erkennen soll, wenn hohes Datenaufkommen besteht, damit er die Verbindungen dann auf zwei physikalische Links trennt innerhalb meines Trunks. Mich stört momentan folgendes Testergebnis mit Netio (immer gleichzeitige Tests!):
ClientA <----> ServerA
ClientB<----> ServerB
Ich krieg von netio sowohl im TX als auch im RX auf beiden Client-Fenstern die volle Bandbreite (112 MByte/sec). Lasse ich die Clients jedoch auf den jeweils anderen Server verbinden ...
ClientA <---> ServerB
ClientB <---> ServerA
dann krieg ich vollen Speed (112MByte/sec) im TX aber beim RX teilen sie sich einen Link (also bei einem sinds z.B. 68MByte/s und beim andren 44MByte/s).
Krieg ich das überhaupt hin, dass es in beide Richtungen mit full speed funktioniert ???
Meine (2.) Frage:
... impliziert auch die obige. Ich hab momentan 3 physikalische Links in einen Trunk hinzugefügt, das heisst meine LAG Nr.1 besteht aus den Ports 1,2,3. Das gleiche natürlich bei beiden Switches konfiguriert. Angenommen ich trenne die physikalische Verbindung zwischen den zwei Switches am Port 2. Dann fallen natürlich erstmal Verbindungen, die über diesen Link verliefen aus und die Verbindung bricht auseinander. Wie lange braucht der Switch, damit er das selbstätig erkennt und alle Verbindungen auf Port1 oder Port3 aufschaltet um ordnungsgemäß die Verbindungen wieder aufzunehmen, bzw. neu aufzubauen?
Und meine (3.) Frage:
Ist es ok, wenn ich drei Links für eine LAG verwende, oder sollte ich eine Zweierpotenz verwenden, also 2, 4, 8 usw... ?? Hab das irgendwo mal aufgegriffen, bin mir aber nicht mehr sicher.
nun zu meinem Problem und Fragestellung:
(1.) Frage:
Welche Methode muss ich anwenden, damit der Switch die Daten nach der Last checkt, und so die zwei lasthöchsten Clients jeweils auf einen eigenen physikalischen Link verteilt? Mit SMAC oder DMAC bringts ja nix wie wir im obigen Beispiel gesehen haben. Selbst mit pseudo-randomized war ich nicht ganz zufrieden. Da sah die Sache halt wieder anders aus: ClientA und ClientB konnten full speed gleichzeitig erreichen, aber ClientA und ClientC nicht, sondern nur fullspeed half-duplex, also beim Tx war full speed, aber beim Empfang nicht. Also: wie genau managed diese LAG das eigentlich? Wie lange behält ein Client seine Zuweisung an einen Port eigentlich bei, wie schnell oder langsam wechselt so was? Weiß das jemand und kann mir helfen? Ich möchte dem Switch verständlich machen, dass er erkennen soll, wenn hohes Datenaufkommen besteht, damit er die Verbindungen dann auf zwei physikalische Links trennt innerhalb meines Trunks. Mich stört momentan folgendes Testergebnis mit Netio (immer gleichzeitige Tests!):
ClientA <----> ServerA
ClientB<----> ServerB
Ich krieg von netio sowohl im TX als auch im RX auf beiden Client-Fenstern die volle Bandbreite (112 MByte/sec). Lasse ich die Clients jedoch auf den jeweils anderen Server verbinden ...
ClientA <---> ServerB
ClientB <---> ServerA
dann krieg ich vollen Speed (112MByte/sec) im TX aber beim RX teilen sie sich einen Link (also bei einem sinds z.B. 68MByte/s und beim andren 44MByte/s).
Krieg ich das überhaupt hin, dass es in beide Richtungen mit full speed funktioniert ???
Meine (2.) Frage:
... impliziert auch die obige. Ich hab momentan 3 physikalische Links in einen Trunk hinzugefügt, das heisst meine LAG Nr.1 besteht aus den Ports 1,2,3. Das gleiche natürlich bei beiden Switches konfiguriert. Angenommen ich trenne die physikalische Verbindung zwischen den zwei Switches am Port 2. Dann fallen natürlich erstmal Verbindungen, die über diesen Link verliefen aus und die Verbindung bricht auseinander. Wie lange braucht der Switch, damit er das selbstätig erkennt und alle Verbindungen auf Port1 oder Port3 aufschaltet um ordnungsgemäß die Verbindungen wieder aufzunehmen, bzw. neu aufzubauen?
Und meine (3.) Frage:
Ist es ok, wenn ich drei Links für eine LAG verwende, oder sollte ich eine Zweierpotenz verwenden, also 2, 4, 8 usw... ?? Hab das irgendwo mal aufgegriffen, bin mir aber nicht mehr sicher.
Ist eigentlich kinderleicht mit den OIDs. Soweit hast du das schon richtig gemacht. Die OID ist eine aus der Standard Ethernet MIB. Ist nur die Frage wie HP die Indexierung macht. Beispiel hier:
http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=192 ...
Oh Wunder ! Dell Beispiel: http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=596 ...
Du musst also sowas wie
OID: 1.3.6.1.2.1.2.2.1.2.1, = Interface 1
OID : 1.3.6.1.2.1.2.2.1.2.2, = Interface 2
OID : 1.3.6.1.2.1.2.2.1.2.3, = Interface 3
OID: 1.3.6.1.2.1.2.2.1.2.4 = Interface 4
usw. eingeben.
Die OID müsste gültig sein für alle Switches.
Der NetIO Check wird dir nichts bringen, es sei denn du machst ihn auf mehreren Clients gleichzeitig. Bedenke das die Session Verteilung auf Basis der Mac Adresse gemacht.
Ein immer gleiches NetIO Pärchen landet also immer auf dem gleichen physischen Link...logisch !
Auch wenn du mehrere hast kann auch der und andere zufällig auf diesem gleichen Link landen. Das ist die Crux bei 802.3ad wenn dort nur die Macs ins Hashing einfliessen. Fazit: Viel Macs...bessere Verteilung !!
Zufällig kann aber die Verteilung korrekt sein so wie bei dir oben mit dem Client C. Dann ist das ein Indix das der Trunk funktioniert.
Frage 1.)
Ein Last abhängiger Check ist mit diesem Trunk Algorithmus auf dem OSI Layer 2 technisch völlig unmöglich. Sollte dir auch klar sein, da der Hashing Algorythmus nur dumm nach Mac Adresse geht. Niemals fragt er also aktiv über SNMP z.B. die Link Auslastung ab und reagiert dann.
Das ist also pure Utopie ! Randomzied verteilt nach dem Lotteriespiel... Eine aktive Verteilung nach Auslastung ist so nicht möglich.
Das funktioniert nur im Layer 3 z.B. wenn du auf parallelen Links routetst mit OSPF.
OSPF ECMP sorgt dann dafür das es eine lastabhängige Verteilung auf dynamischer Basis gibt. Das würde also funktionieren.
Nur...mit deinen beiden Billiggurken wirst du da natürlich nix, denn die supporten kein Layer 3, also kannst das Ansinnen gleich begraben ohne Neuinvestition.
Andere Möglichkeiten der dynamischen aktiven per Paket Verteilung hast du nur mit spezialsierten Data Center Switches wie der Cisco Nexus Serie oder Brocade VDX. Vermutlich aber auch weit jenseits deines Budget Horizonts ?!
Deine asymetrischen Tests resultieren aus der Tatsache das du vermutlich einen Hashing Mismatch zwischen Dell und HP hast, da der Dell ja nun aus Trunk Sicht rein gar nix kann, nichtmal LACP und damit nichtmal wirklich Standard konform ist, also dem absoluten Minimum. Generell also keine gute Voraussetzung einen performanten Trunk aufzusetzen.
Folglich steht die Frage :"...krieg ich das hin..." schon unter keinem guten Stern mit dieser HW...leider.
Frage 2.)
Normalerweise funktioniert die Trunk Konvergenz im µS Bereich, da sofort ein neuer Hash gefunden wird und die Pakete dann wieder geforwardet werden. Ziehst du den Link gerade wo der Frame "auf der Leitung" ist ist dieser natürlich verloren aber das TCP sorgt dann für eine Retransmission im Layer 4.
Fazit: Ein Anwender merkt das gar nicht. Ein Datenfluss ist also nicht unterbrochen wenn sowas passiert, da die Unterbrechung marginal ist und die Recovery time im Sub Second Bereich liegt. Genau das ist ja der Sinn bei Trunks das man dort im Grunde eine Performance Erhöhung mit gleichzeitiger Redundanz hat !
Frage 3.)
Normalerweise ja. Es ist OK allerdings lauert dort der Teufel im Detail. Es gibt Hersteller die ein Spardesign mit den Switch ASICS machen und dort kann (muss nicht) es Limitierungen geben. Meist wird das dann aber im GUI oder CLI Kommadoseitig geblockt. Zum Mindesten steht es aber in der Doku (Handbuch) oder in den Release Notes zur Firmware.
Ein Blick darein bei Trunk Konfigs kann also nie schaden !!
http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=192 ...
Oh Wunder ! Dell Beispiel: http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=596 ...
Du musst also sowas wie
OID: 1.3.6.1.2.1.2.2.1.2.1, = Interface 1
OID : 1.3.6.1.2.1.2.2.1.2.2, = Interface 2
OID : 1.3.6.1.2.1.2.2.1.2.3, = Interface 3
OID: 1.3.6.1.2.1.2.2.1.2.4 = Interface 4
usw. eingeben.
Die OID müsste gültig sein für alle Switches.
Der NetIO Check wird dir nichts bringen, es sei denn du machst ihn auf mehreren Clients gleichzeitig. Bedenke das die Session Verteilung auf Basis der Mac Adresse gemacht.
Ein immer gleiches NetIO Pärchen landet also immer auf dem gleichen physischen Link...logisch !
Auch wenn du mehrere hast kann auch der und andere zufällig auf diesem gleichen Link landen. Das ist die Crux bei 802.3ad wenn dort nur die Macs ins Hashing einfliessen. Fazit: Viel Macs...bessere Verteilung !!
Zufällig kann aber die Verteilung korrekt sein so wie bei dir oben mit dem Client C. Dann ist das ein Indix das der Trunk funktioniert.
Frage 1.)
Ein Last abhängiger Check ist mit diesem Trunk Algorithmus auf dem OSI Layer 2 technisch völlig unmöglich. Sollte dir auch klar sein, da der Hashing Algorythmus nur dumm nach Mac Adresse geht. Niemals fragt er also aktiv über SNMP z.B. die Link Auslastung ab und reagiert dann.
Das ist also pure Utopie ! Randomzied verteilt nach dem Lotteriespiel... Eine aktive Verteilung nach Auslastung ist so nicht möglich.
Das funktioniert nur im Layer 3 z.B. wenn du auf parallelen Links routetst mit OSPF.
OSPF ECMP sorgt dann dafür das es eine lastabhängige Verteilung auf dynamischer Basis gibt. Das würde also funktionieren.
Nur...mit deinen beiden Billiggurken wirst du da natürlich nix, denn die supporten kein Layer 3, also kannst das Ansinnen gleich begraben ohne Neuinvestition.
Andere Möglichkeiten der dynamischen aktiven per Paket Verteilung hast du nur mit spezialsierten Data Center Switches wie der Cisco Nexus Serie oder Brocade VDX. Vermutlich aber auch weit jenseits deines Budget Horizonts ?!
Deine asymetrischen Tests resultieren aus der Tatsache das du vermutlich einen Hashing Mismatch zwischen Dell und HP hast, da der Dell ja nun aus Trunk Sicht rein gar nix kann, nichtmal LACP und damit nichtmal wirklich Standard konform ist, also dem absoluten Minimum. Generell also keine gute Voraussetzung einen performanten Trunk aufzusetzen.
Folglich steht die Frage :"...krieg ich das hin..." schon unter keinem guten Stern mit dieser HW...leider.
Frage 2.)
Normalerweise funktioniert die Trunk Konvergenz im µS Bereich, da sofort ein neuer Hash gefunden wird und die Pakete dann wieder geforwardet werden. Ziehst du den Link gerade wo der Frame "auf der Leitung" ist ist dieser natürlich verloren aber das TCP sorgt dann für eine Retransmission im Layer 4.
Fazit: Ein Anwender merkt das gar nicht. Ein Datenfluss ist also nicht unterbrochen wenn sowas passiert, da die Unterbrechung marginal ist und die Recovery time im Sub Second Bereich liegt. Genau das ist ja der Sinn bei Trunks das man dort im Grunde eine Performance Erhöhung mit gleichzeitiger Redundanz hat !
Frage 3.)
Normalerweise ja. Es ist OK allerdings lauert dort der Teufel im Detail. Es gibt Hersteller die ein Spardesign mit den Switch ASICS machen und dort kann (muss nicht) es Limitierungen geben. Meist wird das dann aber im GUI oder CLI Kommadoseitig geblockt. Zum Mindesten steht es aber in der Doku (Handbuch) oder in den Release Notes zur Firmware.
Ein Blick darein bei Trunk Konfigs kann also nie schaden !!
Vielen Dank aqui !
ich werde die Dell-Gurke ins Jenseits befördern (sprich entkoppeln und anderweitig verwenden, z.B. als Abtreter). Kannst du mir vielleicht adhoc einen guten Switch empfehlen, der sowohl LACP-fähig ist, (vielleicht sogar auch Layer3 kann?), min.16Ports hat und nicht 4stellig kostet? Sollte ich bei dieser Gelegenheit wohl den ProCurve auch tauschen, oder? Obwohl der (laut technischen Details und Webkonfigurationsmöglichkeiten) doch einiges mehr wie der verschissene Dell bietet.
Nach welchen Produkten sollte ich also Ausschau halten, deiner Meinung nach?
ich werde die Dell-Gurke ins Jenseits befördern (sprich entkoppeln und anderweitig verwenden, z.B. als Abtreter). Kannst du mir vielleicht adhoc einen guten Switch empfehlen, der sowohl LACP-fähig ist, (vielleicht sogar auch Layer3 kann?), min.16Ports hat und nicht 4stellig kostet? Sollte ich bei dieser Gelegenheit wohl den ProCurve auch tauschen, oder? Obwohl der (laut technischen Details und Webkonfigurationsmöglichkeiten) doch einiges mehr wie der verschissene Dell bietet.
Nach welchen Produkten sollte ich also Ausschau halten, deiner Meinung nach?
Nimm einen preiswerten Cisco Switch aus der 200er Serie !
http://www.cisco.com/cisco/web/solutions/small_business/products/router ...
SF = 10/100 und SG = 10/100/1000
SG-200-18 also für dich bei GiG Ethernet (bei Layer 3 **SG 300-20) oder SF-200-24 wenn du nur 100 Mbit machst auf dem Kupfer bzw. 300 im L3
Die 300er Serie ist Layer 3 aber teurer.
Damit hast du keinerlei Probleme. Auch nicht mit Trunks auf HP, D-Link und Co !
http://www.cisco.com/cisco/web/solutions/small_business/products/router ...
SF = 10/100 und SG = 10/100/1000
SG-200-18 also für dich bei GiG Ethernet (bei Layer 3 **SG 300-20) oder SF-200-24 wenn du nur 100 Mbit machst auf dem Kupfer bzw. 300 im L3
Die 300er Serie ist Layer 3 aber teurer.
Damit hast du keinerlei Probleme. Auch nicht mit Trunks auf HP, D-Link und Co !
Danke dir. Ich hab mir mal die Modelle angeschaut. Ich hab den SG300-28 im Visier, damit ich für freie Ports und somit die Zukunft noch etwas Reserve habe. Was mich ein wenig wundert: wenn ich nach den Preisen für den SG300-28 schaue, dann krieg ich 410-580 euro zu sehen. Wieso so grosse Unterschiede (alles Neuware) ?? Gibts Unterschiede, auf die ich unbedingt achten sollte? Ich hab nämlich in den Bezeichnungen auch "SRW2024-K9-EU" gesehen und war etwas verwirrt. Auf eBay zum Bleistift gibts dieses Angebot hier, wie kommt dieser niedrige Preis im Vergleich zu den anderen zustande? Wo ist da der Haken?
http://www.ebay.de/itm/NEU-Cisco-SG300-28-Ethernet-Switch-28-Anschluss- ...
Und wieso ist der SGE2000P (=24port, stackable) soviel teurer als der SG300-28 (26port) ?
http://www.ebay.de/itm/NEU-Cisco-SG300-28-Ethernet-Switch-28-Anschluss- ...
Und wieso ist der SGE2000P (=24port, stackable) soviel teurer als der SG300-28 (26port) ?
Der SG 300 ist ein Layer 3 Switch (deshalb die "3" im Namen!) kann also gleichzeitig noch mit allem Drum und Dran routen zwischen den VLANs.
Die 200er sind baugleich aber ohne Layer 3 (deshalb die "2" für Layer 2 im Namen!)
Wenn du also kein Routing benötigst auf dem Switch kannst du dir das Geld sparen und die L2 only Version (200er Model) verwenden.
Die stackables sind deshalb so teuer weil sie stackfähig sind. Man kann also bis zu 8 Switches zusammenstecken, die sich dann wie ein einziger Switch analog zu einem Chassis Switch verhalten. Klar das dieses SW Feature erheblich teurer ist.
Ist wie ein Baukastenprinzip: F=nur 100 Mbit auf dem Kupfer, G=1000Mbit Kupfer, 2xx=L2 only, 3xx=L3, P= mit PoE, E= Stacking
Ohne L3 und Stacking wäre also der SG200-26 für dich das Modell der Wahl !
Die 200er sind baugleich aber ohne Layer 3 (deshalb die "2" für Layer 2 im Namen!)
Wenn du also kein Routing benötigst auf dem Switch kannst du dir das Geld sparen und die L2 only Version (200er Model) verwenden.
Die stackables sind deshalb so teuer weil sie stackfähig sind. Man kann also bis zu 8 Switches zusammenstecken, die sich dann wie ein einziger Switch analog zu einem Chassis Switch verhalten. Klar das dieses SW Feature erheblich teurer ist.
Ist wie ein Baukastenprinzip: F=nur 100 Mbit auf dem Kupfer, G=1000Mbit Kupfer, 2xx=L2 only, 3xx=L3, P= mit PoE, E= Stacking
Ohne L3 und Stacking wäre also der SG200-26 für dich das Modell der Wahl !
Ok, bevor es zu off-topic wird, habe ich dir wegen dem Switch noch eine PN gesendet.
