EtherChannel-Designs

Einleitung

In diesem Dokument werden verschiedene mögliche Kombinationen verschiedener Geräte beschrieben, die über den EtherChannel verbunden sind.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Switching- und Catalyst-Betrieb
• STP
• EtherChannel-Konzepte
• Cisco Layer-2-Protokolle

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf, sind jedoch nicht darauf beschränkt:

• Cisco Catalyst Switches.
• Cisco Nexus-Switches
• HA mit Virtual Switch Link (VSL), VSS, Stacking und vPC
• EtherChannel

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen einer Änderung der Verbindung auf der physischen Ebene verstehen.

Hintergrundinformationen

Dieses Dokument ist nützlich, um die verschiedenen empfohlenen Möglichkeiten zum Aufbau eines EtherChannels zwischen Cisco-Geräten oder einem Cisco-Gerät und einem Gerät eines Drittanbieters zu verstehen.

Erläuterung

Ein EtherChannel besteht aus einzelnen Schnittstellenverbindungen, die die gleichen logischen und physischen Eigenschaften aufweisen müssen. Diese Verbindungen sind als eine einzige logische Verbindung gebündelt, bei der es sich lediglich um den EtherChannel handelt.

Beispiele, 

Aus der Sicht der Verbindung: GigabitEthernet-Schnittstellen können gebündelt werden, GigabitEthernet-Schnittstellen können jedoch nicht mit FastEthernet oder TenGigabitEthernet gebündelt werden und umgekehrt.

Aus Gerätesicht: Ein EtherChannel kann zwischen zwei Geräten gebildet werden, d. h. zwei Switches oder ein Switch und ein Multilayer-Switch oder ein Switch und ein Server usw.

Sie kann auch zwischen zwei logischen Geräten, d. h. zwei Switch-Stacks, oder einem Switch und einem Switch-Stack, einem OR-Switch und einem vPC usw. gebildet werden.

Mehrere Exponate im EtherChannel

Entwurf 1. EtherChannel zwischen zwei Einzelswitches

Entwurf 1. EtherChannel zwischen zwei Einzelswitches

Die gezeigten Exponate des EtherChannels sind das grundlegende Design des EtherChannels, der aus zwei Verbindungen zwischen zwei Switches besteht.

Design 2. EtherChannel mit 8 Verbindungen

Design 2. EtherChannel mit 8 Verbindungen

Das oben gezeigte EtherChannel-Design basiert auf acht Verbindungen zwischen zwei Switches. Diese stellen die maximal unterstützten aktiven Verbindungen dar (gemäß PAGP).

Der EtherChannel kann insgesamt 16 Verbindungen aufweisen, wobei acht aktive Verbindungen und die anderen acht im Hot-Standby-Modus (SS pro LACP) sind.

Design 3. EtherChannel zwischen Stack und einem einzelnen Switch Variante 1.

Design 3. EtherChannel zwischen Stack und einem einzelnen Switch Variante 1

Dieses Design zeigt die EtherChannel-Verbindung in einer Stack-Umgebung. Stack-Switch 1 und Stack-Switch 2 sind zwei verschiedene Switches, die logisch jedoch als eine Einheit aus einem Switch fungieren, auf der StackWise als Protokoll ausgeführt wird.

Design 4: EtherChannel zwischen zwei Stacks Variante 1.

Design 4: EtherChannel zwischen zwei Stacks Variante 1

Dieses Design zeigt die EtherChannel-Verbindung zwischen zwei Stack-Switches.

Der logische Switch 1 auf der linken Seite besteht aus zwei physischen Switches, d.h. dem Stack-Switch 1 und dem Stack-Switch 2, die über Stack-Kabel verbunden sind, und auf der rechten Seite befindet sich ebenfalls ein logischer Switch 2.

Hier wird zwischen dem logischen Schalter 1 und dem logischen Schalter 2 ein EtherChannel gebildet.

Der hier erzeugte EtherChannel liegt zwischen zwei einzelnen logischen Einheiten, von denen die eine Einheit der logische Switch 1 und die andere der logische Switch 2 ist.

Design 5: EtherChannel zwischen zwei VSS/VSL-Konfigurationen

Design 5: EtherChannel zwischen zwei VSS/VSL-Konfigurationen

In diesem Design wird die EtherChannel-Verbindung zwischen zwei VSS/VSL-Setup-Switches veranschaulicht. Der Left Top Switch fungiert als Virtual Active Switch und der Left Bottom Switch fungiert als Virtual Stanby Switch und wird über das VSS/VSL-Protokoll miteinander verbunden. Dieses Protokoll fungiert als ein logischer Switch. Ebenso wurde die richtige virtuelle Konfiguration entwickelt.

Der hier abgebildete EtherChannel ist ein perfektes Beispiel für vollständige Redundanz zwischen zwei VSS/SVL-Konfigurationen.

Design 6: EtherChannel zwischen Stack und einem Switch Variante 2.

Design 6: EtherChannel zwischen Stack und einem Switch Variante 2

In diesem Design wird der EtherChannel zwischen dem logischen Switch auf der linken Seite und dem Switch auf der rechten Seite veranschaulicht.

Der logische Switch 1 agiert als einzelner Switch, besteht jedoch aus einem Stack aus drei physischen Switches, d. h. Switch 1, Switch 2 und Switch 3.

Es ist nicht zwingend erforderlich, eine EtherChannel-Mitgliedsverbindung mit jedem Switch im Stack zu verbinden.

Design 7: EtherChannel zwischen zwei Stacks Variante 2.

Design 7: EtherChannel zwischen zwei Stacks Variante 2

Dies ist die Variante des vorherigen Designs, aber in diesem Design haben wir den Stapel auch auf der rechten Seite.

Design 8: EtherChannel mit vPC

Design 8: EtherChannel mit vPC

In diesem Design befinden sich auf der linken Seite zwei physisch und logisch getrennte Nexus-Geräte: Nexus Switch 1 und Nexus Switch 2.

Auf diesen Nexus Switches wird das vPC-Protokoll (Virtual Port Channel) so ausgeführt, dass das Peer-Gerät (in diesem Fall sein Switch auf der rechten Seite) die Nexus-Konfiguration als einen einzigen Switch wahrnimmt.

vPC ist eine Funktion für Nexus-Switches. Über EtherChannel-Verbindungen können Sie zwei Nexus Switches miteinander verbinden, auf denen die vPC-Funktion und -Konfiguration ausgeführt wird. Auf diese Weise können Sie einen einzelnen logischen Knoten erstellen.

vPC verbindet zwei Nexus Switches durch Spoofing von Layer 2, einschließlich STP BPDU und FHRP (First Hop Routing Protocol - HSRP, VRRP, GLBP).

Nexus wird hauptsächlich für Rechenzentren und VSS für Campus-Umgebungen verwendet. Sie können maximal zwei Geräte für vPC und VSS verwenden. Im Unterschied dazu verfügt VSS über eine Kontrollebene, vPC über zwei verschiedene. Mit VSS entfällt die Verwendung von VRRP, HSRP usw. Bei VPC müssen Sie immer noch einen HSRP oder VRRP verwenden.

vPC ist eine Virtualisierungstechnologie, mit der Verbindungen, die physisch mit zwei verschiedenen Geräten der Cisco Nexus Serie verbunden sind, für einen dritten Endpunkt als ein Port-Channel erscheinen.

Design 9:EtherChannel mit NIC Teaming

Design 9:EtherChannel mit NIC Teaming

NIC-Teaming ermöglicht die Kombination mehrerer physischer und virtueller Netzwerkschnittstellen in einem einzigen logischen virtuellen Adapter namens NIC-Team. 

In diesem Design wird eine EtherChannel-Verbindung zwischen dem Switch und dem Server veranschaulicht.

In diesem Fall kann der EtherChannel auf der Switch-Seite entweder mit dem EIN-Modus oder mit dem LACP Active/Passive Mode konfiguriert werden. Dies hängt vom Protokoll ab, das von der Peer-Seite ausgeführt wird.

Design 10: EtherChannel mit Firewall im HA-Modus

Design 10: EtherChannel mit Firewall im HA-Modus

Dieses Design zeigt die EtherChannel-Verbindung zwischen VSS/VSL-Setup-Switches und der Firewall im Hochverfügbarkeitsmodus.

Der Left Top Switch fungiert als aktiver Switch, und der Left Bottom Switch fungiert als Standby Switch und wird über das VSS/VSL-Protokoll miteinander verbunden. Sie fungieren daher beide als ein einziger logischer Switch.

Rechts befinden sich zwei logisch und physisch getrennte Firewalls, die im Allgemeinen als aktive und Standby-Firewalls fungieren. Um Redundanz zu erreichen, sollte von jeder Firewall ein Link zu beiden Switches der VSS/VSL-Einrichtungen angeschlossen sein. Die Redundanz wird durch zwei EtherChannels erreicht: PortChannel 10 und PortChannel 20. Port-Channel 10 besteht aus zwei Verbindungen, die von Firewall 1 ausgehen und an den VSS/VSL-Switch "Active" bzw. "Standby" enden, und der gleiche Port-Channel 20 startet von Firewall 2.

Muster 11. Nicht unterstütztes Design mit redundanter Firewall

Muster 11. Nicht unterstütztes Design mit redundanter Firewall

Dieses Design wird nicht unterstützt. Der Grund hierfür ist, dass die Port-Channel-Konfiguration auf der Switch-Seite falsch ist und zu einer Datenverkehrsblockierung auf dem Standby-Gerät führt. Ein solches Design wird nur unterstützt, wenn Sie ASA oder FTD im Cluster-übergreifenden Modus konfigurieren.

Weitere Informationen finden Sie im vorherigen Design.

Muster 12. Nicht unterstütztes Design mit FHRP-konfigurierten Routern

Muster 12. Nicht unterstütztes Design mit FHRP-konfigurierten Routern

Dieses Design wird nicht unterstützt, da es gegen das grundlegende Designprinzip von EtherChannel verstößt.

Bei diesem Design fungieren auf der linken Seite beide Switches als einzelner logischer Switch, auf der rechten Seite dagegen sind die Router physisch und logisch getrennt.

Router 1 und Router 2 sind mit dem FHRP-Protokoll verbunden und bieten keine Unterstützung für EtherChannel-Redundanz.

Daher ist es nicht legitim und wird auch nicht unterstützt, die von diesen Routern stammenden Verbindungen unter einem einzigen EtherChannel zu bündeln.