Ich habe 2 Control Center-Sites mit jeweils 2 N7Ks in einem vollständigen Mesh-Design und 2 Nexus 5548UPs als interne Serverfarmaggregation und 2 ASA-Firewalls, die an jedem N5K-Agg hängen. Beide Websites sind spiegelbildlich gestaltet. Wir haben Benutzer, die direkten Zugriff auf die internen Serverfarmanwendungen benötigen, und wir benötigen auch eine Sicherheitsgrenze für ausgehende Verbindungsanforderungen von den internen Serveranwendungen. Darüber hinaus muss ich private DMZs innerhalb des Agg hosten, um eingehende Verbindungsanforderungen von den von uns als niedrigere Sicherheitszonen klassifizierten zu isolieren (der N7K CORE verwendet vrf: Global für Routen zu Subnetzen mit niedrigerem Sicherheitsnetzwerk).
Normalerweise wird der Benutzer als niedrigere Sicherheitszonen betrachtet, aber dieses Design dient zum Hosten eines Steuerungssystems für ein großes Stromnetz. In diesem Sinne möchte ich die Benutzer auch nicht direkt mit dem N5K Agg verbinden, damit SITE1 Server Farm Agg heruntergefahren werden kann, sodass SITE 2 die Anwendungen hosten kann (derzeit verbinden wir Benutzer mit demselben physischen Switch wie die Anwendungen). . Ich möchte ein klassisches Rechenzentrumsdesign bereitstellen, bei dem die Benutzer vom HA L3-KERN (4 x N7K-Vollnetz) zur Serverfarm weiterleiten. Da sie jedoch die gleiche Sicherheitsstufe wie die „internen Server“ haben, möchte ich sie in eine private VPN-Cloud isolieren, die auf dem N7K CORE gehostet wird. Da N7K MPLS unterstützt, wäre dies jedoch am logischsten Mein aktuelles Design hat die L2 / L3-Grenze für die internen Server bei der Nexus 5548-Aggregation, da dort auch die Firewalls verbunden sind. Nexus 5Ks unterstützen kein MPLS, aber VRF Lite. Die N5Ks sind außerdem in einem vollständigen Netz mit den lokalen N7Ks an jedem Standort verbunden.
Um alle 4 Verbindungen zwischen den N5Ks und den N7Ks zu nutzen, muss ich entweder pt-zu-pt-L3-Verbindungen konfigurieren, die die Idee, den internen Benutzerverkehr vom Core vom Verkehr zu isolieren, der zur Weiterleitung der Firewall benötigt wird, in eine Schublade stecken, oder ich kann FabricPath zwischen den 5Ks verwenden und 7Ks und verwenden Sie vrf lite, wobei die einzigen FabricPath-vlans die Schnittstellen-SVIs zwischen den 4 Knoten und dem externen vlan der Firewall zum Verbinden der vrf: Global Routing-Tabelle des N7K sind. Dies ist wahrscheinlich übertrieben, da diese lizenziert werden müssen, aber wir haben spezielle Sicherheitsanforderungen, sodass die Kosten in der Regel ein kleines Problem darstellen.
Für das Routing würde ich eine Standardroute in der Firewall installieren, die auf N7K vrf: Global verweist, auf der OSPF oder EIGRP ausgeführt und Routen zu anderen Netzwerken mit niedrigerer Sicherheit gelernt werden. Für die High Secure Zone würde ich eine vrf installieren: Intern auf allen N5Ks und N7Ks und am wahrscheinlichsten würde BGP ausgeführt, da MPLS auf den N7Ks die Verwendung von MP-BGP erfordert. Dies würde nur Routen für die interne SITE2-Serverfarm und die internen Benutzer lernen (unsere Anwendungen benötigen L3 zwischen Sites, um ein gespaltenes Gehirn zu verhindern). Ich muss auch sehr darauf achten, dass vrf: Global keine Routen mit vrf: Internal austauscht, da dies einen assymetrischen Albtraum mit Stateful Firewalls verursachen würde, die eine L3-Verbindung zwischen den beiden vrf herstellen. Eine einfache Standardroute am lokalen Standort N5K und der Firewall sowie eine zusammenfassende Route im N7K, die auf die internen Serversubnetze verweist, verhindern dieses Problem.
Alternativ habe ich überlegt, ein weiteres VDC aus dem N7K zu bauen, um FHRP bereitzustellen und die Firewalls auf das VDC zu verschieben. Der N5K würde nur FabricPath und keinerlei L3 verwenden.
Da dies höchstwahrscheinlich kein typisches Design ist, würde ich mich über ein Feedback dazu freuen.
