Jump to content

Catalyst Switch mit Etherchannel LACP vs. PAgP


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

ich stehe immer wieder vor der Entscheidung - bei einem Etherchannel LACP oder PAgP zu verwenden. Wenn ich das ganze zu einem Server oder anderen Switch (non Cisco) machen muss - ist LACP klar gesetzt - da ja der Standard. Was würded ihr zuwischen Cisco Komponenten verwenden ? LACP oder PAgP

 

Würde gerne mal eure Meinung dazu hören - vielleicht fällt mir ja dann die Enscheidung einfacher.

Link zu diesem Kommentar

Hallo,

 

also ich würde LACP machen, PAgP ist ja CISCO proprietär.

 

Ergo wenn mal ein anderer Switch kommt (entweder nicht CISCO oder ein CISCO der kein PAgP mehr kann) bist du auf der sicheren Seite.

 

Ist meiner(!) Meinung nach wie bei V-LAN, wer nimmt noch ISL wenn es 802.1Q als standarddisiertes Protokoll gibt?

 

mfg

Link zu diesem Kommentar

Hi,

 

das sind genau die Antworten die mich in meinen Entscheidungen bestätigen - wollte einfach mal hören wie andere drüber denken - den ich stand am Freitag wieder vor der Entscheidung und habe mich für LACP entschieden - finden für "normale" Umgebungen sonst kein Argument für PAgP. (Normale Umgebung heisst so im 2960 - 3750er Umfeld)

 

Falls jemand noch was für PAgP einfällt - nur her damit.

Link zu diesem Kommentar
Ausser du willst VSS zwischen zwei 6500ern (SUP720-10G) machen.

Dann musst du PAgP+.

 

hab mich mit VSS noch nicht auseinandergesetzt bisher, aber ist das nur ein Clustering der Switche oder könnte man damit auch ein Failover erreichen, wenn sämtliche Verbindungen zu den Switchen doppelt ausgelegt wären?

 

 

weil im Moment läuft noch ein 20G Etherchannel zwischen unseren 6500er. Wäre aber schon sehr interessant.

Link zu diesem Kommentar
ich würds (sofern die Gegenseite das kann) einfach of on setzen und fertig.

 

Wow - damit kannst du dir aber echt heftige Loops einfangen / generieren. Wenn mal die Gegenstelle falsch konfiguriert wird, oder man sich verpatcht. Nene, auf ON würde ich das ganze nur im Notfall setzen.

 

(Ausser beim WLAN Controller - der kann ja offensichtlich nix anderes. --> Rüge an Cisco :-) )

Link zu diesem Kommentar
Wow - damit kannst du dir aber echt heftige Loops einfangen / generieren. Wenn mal die Gegenstelle falsch konfiguriert wird, oder man sich verpatcht. Nene, auf ON würde ich das ganze nur im Notfall setzen.

 

(Ausser beim WLAN Controller - der kann ja offensichtlich nix anderes. --> Rüge an Cisco :-) )

 

@Offtopic

 

Rüge auch an VMware, bei ESXi braucht man auch "on", ich habe mich gesträubt aber es ging nicht anders.

 

mfg

Link zu diesem Kommentar
man muss halt wissen wo man das macht :) wir haben ausschließlich on im Betrieb. Allerdins auch nur Cisco Switches,allesamt von uns verwaltet.

 

Ich muss mich da anschliessen, prinzipiell nur ON, und prinzipiell nur Cisco. Meiner Meinung nach ist es fahrlaessiger Switche diverser Hersteller zu mischen als einfach LACP einzusetzen.

 

Klar, wenn man vorher schon gemischt hat gehts halt nicht anders, keine Frage.

 

 

Wow - damit kannst du dir aber echt heftige Loops einfangen / generieren. Wenn mal die Gegenstelle falsch konfiguriert wird, oder man sich verpatcht. Nene, auf ON würde ich das ganze nur im Notfall setzen.

 

(Ausser beim WLAN Controller - der kann ja offensichtlich nix anderes. --> Rüge an Cisco :-) )

 

Hast du dazu ein Fallbeispiel?

Link zu diesem Kommentar
Hast du dazu ein Fallbeispiel?

 

Jupp.

Understanding EtherChannel Inconsistency Detection - Cisco Systems

 

Errdisable Port State Recovery on the Cisco IOS Platforms - Cisco Systems

 

Ich erkenne keine Nachteile bei der Nutzung von PAgP oder LACP gegenüber "on". Verstehen kann ich auch, dass PAgP ausscheided, wegen 3rd Party Unterstützung.

Jede andere Netzwerkkomponente sollte eigentlich LACP unterstützen. Na gut - es gibt Endgeräte wie WLC/ESX und HP UX [...], die nur Etherchannel ohne Steuerprotokoll können. Da hat man dann keine Alternative.

Aber zu Cisco-Cisco oder Cisco-"Fremdhersteller" würde ich wenn möglich immer versuchen ein Channel-Protokoll zu verwenden.

Link zu diesem Kommentar

Merci fuer die Links! :) Gut, das beruhigt mich schon mal, denn ich setze das natuerlich voraus, dass man sowas schon richtig konfiguriert hat, bzw. sich damit auskennt wenn mans auch einsetzen will.

 

Der groesste Vorteil bei on ist, ich muss mir keine Gedanken machen ob was active, passive, desireable, auto sein muss/soll. Gibt halt nur "on" :D

Link zu diesem Kommentar
Jupp.

Understanding EtherChannel Inconsistency Detection - Cisco Systems

 

Errdisable Port State Recovery on the Cisco IOS Platforms - Cisco Systems

 

Ich erkenne keine Nachteile bei der Nutzung von PAgP oder LACP gegenüber "on". Verstehen kann ich auch, dass PAgP ausscheided, wegen 3rd Party Unterstützung.

Jede andere Netzwerkkomponente sollte eigentlich LACP unterstützen. Na gut - es gibt Endgeräte wie WLC/ESX und HP UX [...], die nur Etherchannel ohne Steuerprotokoll können. Da hat man dann keine Alternative.

Aber zu Cisco-Cisco oder Cisco-"Fremdhersteller" würde ich wenn möglich immer versuchen ein Channel-Protokoll zu verwenden.

 

Hallo, da ich Teilzeit HP-UX Admin bin, habe ich etwas gesucht und das gefunden.

 

HP Server Connectivity - Cisco & HP Fast Etherchannel & Auto-Port Aggregation Software

 

Wir haben HP-UX 11i2 (11.23) und 11i3 (11.31) in Einsatz.

 

mfg

Link zu diesem Kommentar
Hallo, da ich Teilzeit HP-UX Admin bin, habe ich etwas gesucht und das gefunden.

 

HP Server Connectivity - Cisco & HP Fast Etherchannel & Auto-Port Aggregation Software

 

Wir haben HP-UX 11i2 (11.23) und 11i3 (11.31) in Einsatz.

 

mfg

 

Hmmm .... muss gestehen, dass ich jetzt nicht alles in dem Artikel gelesen habe. Aber ich nehme die Aussage zurück, das HP-UX kein Channel-Protokoll kann :-)

Ersetze HP-UX durch andere Server/Endgeräte/DataStores etc., die kein Channeling Protokoll können. Aber ich bleib dabei, dass man ein Channeling Protokoll verwenden sollte, wo es möglich ist :D

Link zu diesem Kommentar
Hmmm .... muss gestehen, dass ich jetzt nicht alles in dem Artikel gelesen habe. Aber ich nehme die Aussage zurück, das HP-UX kein Channel-Protokoll kann :-)

Ersetze HP-UX durch andere Server/Endgeräte/DataStores etc., die kein Channeling Protokoll können. Aber ich bleib dabei, dass man ein Channeling Protokoll verwenden sollte, wo es möglich ist :D

 

Dieser Meinung bin ich auch, ich hatte mich nur gewundert weil es alut HP geht und ich damit zu tun habe.

 

mfg

 

PS Ich kriege auch immer ne Anfall wenn ich ESX an meine CISCOs ohne PAgP oder LACP hängen muss.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...