Referenztopologien
Diese detaillierten Topologien sind Beispiele für Uplink-Konfigurationen, die getestet wurden und wie erwartet funktionieren. Jedes Beispiel enthält ein Diagramm zur Veranschaulichung und Konfigurationsrichtlinien.
Bei der Vorbereitung der Installation von Oracle Compute Cloud@Customer legen Sie fest, wie das System mit dem Data-Center-Netzwerk verbunden wird: Uplink-Anzahl, Verkabelungsmuster, Verbindungsgeschwindigkeit, Routingdesign usw. Entscheidungen über Uplinks basieren auf der Netzwerkinfrastruktur in Ihrem Data Center sowie den Bandbreiten- und Verfügbarkeitsanforderungen Ihrer Compute Cloud@Customer-Umgebung. Mit diesen Referenztopologien können Sie fundierte Entscheidungen für Ihre spezifische Umgebung treffen und Anleitungen zur Konfiguration der Switches für die ausgewählte Topologie bereitstellen.
Die Konfigurationsparameter in den Referenztopologien sind als Richtlinien für Netzwerkadministratoren gedacht. Die genauen Konfigurationsdetails Ihrer spezifischen Umgebung müssen an Ihrem Data Center-Netzwerkdesign ausgerichtet sein.
ECMP Mesh ermöglicht die Bereitstellung von Layer-3-Netzwerken gemäß bewährten Best Practices. Diese Uplink-Topologie wird dringend empfohlen.
Konfigurationseigenschaften
-
Mesh-Topologie – jeder Wirbelsäulen-Switch ist mit zwei unabhängigen Rechenzentrums-Switches verbunden
-
Statisches Routing – Der gesamte Egress-Traffic von einem Uplink durchläuft eine einzelne Gateway-IP, die auf seinem Peer-Netzwerkgerät im Data Center konfiguriert ist
-
ECMP – Bandbreitenoptimierung über mehrere redundante Links oder Pfade hinweg
-
Separate /30-Subnetze – jeder Uplink verbindet einen Spine Switch-Portkanal mit einem Data Center Switch-Portkanal in einem /30-Subnetz
Topologie-Highlights
-
Alle Uplinks sind als LACP-/aktive Portkanäle mit rate=fast konfiguriert
-
Portkanal Po41 stellt die erste Gruppe von Links auf beiden Wirbelsäulen-Switches dar. Sie verbinden sich gerade mit den entsprechenden ToR-Switches.
-
Portkanal Po42 stellt die zweite Gruppe von Links auf beiden Wirbelsäulen-Switches dar. Sie crossconnect zu den entsprechenden ToR-Switches.
-
-
Die Switch-Ports ToR, die eine Verbindung zu den Spine Switches herstellen, müssen im Zugriffsmodus eingerichtet werden. Das Spanning-Baumprotokoll muss deaktiviert sein.
-
Erfordert 4 eindeutige Subnetze: Eine /30-Subnetzgröße wird empfohlen, aber /31 ist möglich, wenn die ToR-Switches dies unterstützen.
-
Statische Routen mit gleichen Kosten zu beiden ToR-Switches werden automatisch eingerichtet.
-
Egress-Traffic kann zu einem der 4 Uplinks hashing.
-
Es ist NICHT möglich, bestimmten VCN-/VM-Egress-Traffic über einen bestimmten Uplink zu isolieren.
-

Beispiel für die Konfiguration des Spine Switch
-
Wirbelsäulenschalter 1
interface port-channel41 description "customer uplink" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.1/30 ip nat outside interface port-channel42 description "customer uplink 2" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.9/30 ip nat outside ip route 0.0.0.0/0 po41 10.25.16.2 20 ip route 0.0.0.0/0 po42 10.25.16.10 20
Routen hinzugefügt:
0.0.0.0/0, ubest/mbest: 2/0 *via 10.25.16.2, [20/0], 6d08h, static *via 10.25.16.10, [20/0], 6d08h, static
-
Wirbelsäulenschalter 2
interface port-channel41 description "customer uplink" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.5/30 ip nat outside interface port-channel42 description "customer uplink 2" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.13/30 ip nat outside ip route 0.0.0.0/0 po41 10.25.16.6 20 ip route 0.0.0.0/0 po42 10.25.16.14 20
Routen hinzugefügt:
0.0.0.0/0, ubest/mbest: 2/0 *via 10.25.16.6, [20/0], 6d07h, static *via 10.25.16.14, [20/0], 6d07h, static
VRRP Mesh würde sich negativ auf die Netzwerkleistung auswirken. Diese Uplink-Topologie wird NICHT empfohlen.
Wenn die Uplinks in einer Mesh-Topologie eingerichtet sind, gibt es 4 eindeutige Layer-3-Uplinks zu den ToR-Switches. In einer Switch-Konfiguration des Redundanzprotokolls für virtuelle Router wird Egress-Traffic in der Regel über den Uplink mit der primären/aktiven Rolle weitergeleitet. Somit würde eine VRRP-Mesh-Konfiguration die Egress-Bandbreite auf nur 25 Prozent der tatsächlichen Kapazität reduzieren. Daher wird diese Konfiguration als nicht unterstützt betrachtet.
Dynamic Mesh ermöglicht Layer-3-Netzwerkbereitstellung gemäß bewährten Best Practices. Diese Uplink-Topologie wird dringend empfohlen.
Konfigurationseigenschaften
-
Mesh-Topologie – jeder Wirbelsäulen-Switch ist mit zwei unabhängigen Rechenzentrums-Switches verbunden
-
Dynamisches Routing – sowohl autonome Peer-Systeme als auch die Appliance und das Data Center tauschen Routinginformationen mit eBGP (externes Border Gateway Protocol) aus. Der beste Routingpfad wird basierend auf den von den einzelnen AS bekannt gegebenen Informationen zur Netzwerkverfügbarkeit dynamisch angepasst.
-
Separate /30-Subnetze – jeder Uplink verbindet einen Spine Switch-Portkanal mit einem Data Center Switch-Portkanal in einem /30-Subnetz
Topologie-Highlights
-
Alle Uplinks sind als LACP-/aktive Portkanäle mit rate=fast konfiguriert
-
Portkanal Po41 stellt die erste Gruppe von Links auf beiden Wirbelsäulen-Switches dar. Sie verbinden sich gerade mit den entsprechenden ToR-Switches.
-
Portkanal Po42 stellt die zweite Gruppe von Links auf beiden Wirbelsäulen-Switches dar. Sie crossconnect zu den entsprechenden ToR-Switches.
-
-
Die Switch-Ports ToR, die eine Verbindung zu den Spine Switches herstellen, müssen im Zugriffsmodus eingerichtet werden. Das Spanning-Baumprotokoll muss deaktiviert sein.
-
Erfordert 4 eindeutige Subnetze: Eine /30-Subnetzgröße wird empfohlen, aber /31 ist möglich, wenn die ToR-Switches dies unterstützen.
-
Zwischen jeder Spine und beiden ToR-Switches werden zwei eBGP-Peering-Sessions eingerichtet.
-
Egress-Traffic kann zu einem der 4 Uplinks hashing.
-
Es ist NICHT möglich, bestimmten VCN-/VM-Egress-Traffic über einen bestimmten Uplink zu isolieren.
-

Konfigurationsdetails des Wirbels
-
Wirbelsäulenschalter 1
interface port-channel41 description "customer uplink" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.1/30 ip nat outside interface port-channel42 description "customer uplink 2" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.9/30 ip nat outside router bgp 136025 router-id 10.25.16.1 neighbor 10.25.16.2 bfd singlehop remote-as 50000 address-family ipv4 unicast neighbor 10.25.16.10 bfd singlehop remote-as 50000 address-family ipv4 unicast BGP Sessions: ASN 136025 VRF default, local ASN 136025 Neighbor ASN Flaps LastUpDn|LastRead|LastWrit St Port(L/R) Notif(S/R) 10.25.16.2 50000 0 1w4d |00:00:50|00:00:20 E 34408/179 0/0 10.25.16.10 50000 0 1w4d |00:00:43|00:00:20 E 57322/179 0/0
-
Wirbelsäulenschalter 2
interface port-channel41 description "customer uplink" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.5/30 ip nat outside interface port-channel42 description "customer uplink 2" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.13/30 ip nat outside router bgp 136025 router-id 10.25.16.5 neighbor 10.25.16.6 bfd singlehop remote-as 50000 address-family ipv4 unicast neighbor 10.25.16.14 bfd singlehop remote-as 50000 address-family ipv4 unicast BGP Sessions: ASN 136025 VRF default, local ASN 136025 Neighbor ASN Flaps LastUpDn|LastRead|LastWrit St Port(L/R) Notif(S/R) 10.25.16.6 50000 0 1w4d |00:00:50|00:00:20 E 34408/179 0/0 10.25.16.14 50000 0 1w4d |00:00:43|00:00:20 E 57322/179 0/0
ECMP Square ermöglicht die Bereitstellung von Layer-3-Netzwerken gemäß bewährten Best Practices der Branche. Diese Uplink-Topologie wird dringend empfohlen.
Konfigurationseigenschaften
-
Quadratische Topologie – jeder Wirbelsäulen-Switch ist mit einem anderen unabhängigen Rechenzentrums-Switch verbunden
-
Statisches Routing – Der gesamte Egress-Traffic von einem Uplink durchläuft eine einzelne Gateway-IP, die auf seinem Peer-Netzwerkgerät im Data Center konfiguriert ist
-
ECMP – Bandbreitenoptimierung über mehrere redundante Links oder Pfade hinweg
-
Separate /30-Subnetze – jeder Uplink verbindet einen Spine Switch-Portkanal mit einem Data Center Switch-Portkanal in einem /30-Subnetz
Topologie-Highlights
-
Alle Uplinks sind als LACP-/aktive Portkanäle mit rate=fast konfiguriert
-
Die Switch-Ports ToR, die eine Verbindung zu den Spine Switches herstellen, müssen im Zugriffsmodus eingerichtet werden. Das Spanning-Baumprotokoll muss deaktiviert sein. Die ToR-Switches dürfen NICHT mit vPC konfiguriert werden.
-
Erfordert 2 eindeutige Subnetze: Eine /30-Subnetzgröße wird empfohlen, aber /31 ist möglich, wenn die ToR-Switches dies unterstützen.
-
Statische Routen mit gleichen Kosten zu beiden ToR-Switches werden automatisch eingerichtet.
-
Egress-Traffic kann auf einen der 2 Uplinks Hash-Vorgänge ausführen.
-
Es ist NICHT möglich, bestimmten VCN-/VM-Egress-Traffic über einen bestimmten Uplink zu isolieren.
-

Beispiel für die Konfiguration des Spine Switch
-
Wirbelsäulenschalter 1
interface port-channel41 description "customer uplink" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.1/30 ip nat outside
Routen hinzugefügt:
0.0.0.0/0, ubest/mbest: 2/0 *via 10.25.16.2, [20/0], 6d08h, static *via 10.25.16.6, [100/0], 6d08h, static
-
Wirbelsäulenschalter 2
interface port-channel41 description "customer uplink" no switchport mtu 9216 speed 10000 no negotiate auto ip access-group ingress-ports-acl in no ip redirects ip address 10.25.16.5/30 ip nat outside
Routen hinzugefügt:
0.0.0.0/0, ubest/mbest: 2/0 *via 10.25.16.6, [20/0], 6d07h, static *via 10.25.16.2, [100/0], 6d07h, static
ECMP Triangle ermöglicht Peering mit einem einzelnen Data Center-Router oder -Switch.
Konfigurationseigenschaften
-
Dreieckstopologie – beide Wirbelsäulenschalter sind mit einem einzigen Rechenzentrumsschalter verbunden
-
Statisches Routing – Der gesamte Egress-Traffic von einem Uplink durchläuft eine einzelne Gateway-IP, die auf seinem Peer-Netzwerkgerät im Data Center konfiguriert ist
-
ECMP – Bandbreitenoptimierung über mehrere redundante Links oder Pfade hinweg
-
Separate /30-Subnetze – jeder Uplink verbindet einen Spine Switch-Portkanal mit einem Data Center Switch-Portkanal in einem /30-Subnetz
Topologie-Highlights
-
Alle Uplinks sind als LACP-/aktive Portkanäle mit rate=fast konfiguriert
-
Portkanal Po41 stellt die Gruppe von Links dar, die auf beiden Wirbelsäulen-Switches konfiguriert sind. Die Portkanäle Po14 und Po114 stellen die entsprechenden Linksets dar, die für den Switch ToR konfiguriert sind.
-
Die Switch-Ports ToR, die eine Verbindung zu den Spine Switches herstellen, müssen im Zugriffsmodus eingerichtet werden. Das Spanning-Baumprotokoll muss deaktiviert sein.
-
Erfordert 2 eindeutige Subnetze: Eine /30-Subnetzgröße wird empfohlen, aber /31 ist möglich, wenn der ToR-Switch dies unterstützt.
-
Gleichwertige statische Routen zum Schalter ToR werden automatisch eingerichtet.
-
Egress-Traffic kann auf einen der 2 Uplinks Hash-Vorgänge ausführen.
-
Es ist NICHT möglich, bestimmten VCN-/VM-Egress-Traffic über einen bestimmten Uplink zu isolieren.
-

Beispiel für die Konfiguration des Spine Switch
-
Wirbelsäulenschalter 1
interface port-channel41 no shutdown mtu 9216 ip address 10.25.16.2/30 no ipv6 redirects ip proxy-arp ip nat outside ip route 0.0.0.0/0 po41 10.25.16.1 20 ip route 0.0.0.0/0 po41 10.25.16.5 100
-
Wirbelsäulenschalter 2
interface port-channel41 no shutdown mtu 9216 ip address 10.25.16.6/30 no ipv6 redirects ip proxy-arp ip nat outside ip route 0.0.0.0/0 po41 10.25.16.5 20 ip route 0.0.0.0/0 po41 10.25.16.1 100
Topologie für segregierten Administrationsverkehr
Wenn Sie Compute Cloud@Customer-Administrationstraffic trennen möchten, können Sie die dedizierten Verbindungen für das Administrationsnetzwerk mit denselben Topologien wie das Datennetzwerk verbinden und konfigurieren. Es gelten dieselben Grundsätze.
Die Topologie des Administrationsnetzwerks muss nicht mit dem Datennetzwerk übereinstimmen: Sie kann auf einer anderen Referenztopologie basieren, wobei eine andere Anzahl physischer Ports verwendet wird, die mit einer anderen Verbindungsgeschwindigkeit arbeiten. Die Uplink-Konfiguration erfordert unterschiedliche Subnetze, IP-Adressen und Portkanäle, sieht aber ansonsten genau wie ein Datennetzwerk aus.
Bei den Spine Switches ist das Administrationsnetzwerk hartcodiert, um Portkanal 45 (Po45) zu verwenden, während das Datennetzwerk Po41 und Po42 verwendet. Auf der Data Center-Seite der Uplinks können Sie jede gültige Portkanal-ID verwenden, die der vorhandenen Data Center-Konfiguration entspricht.