J'ai 2 sites de centre de contrôle chacun avec 2 N7K dans une conception maillée complète et 2 Nexus 5548UP en tant qu'agrégation de batterie de serveurs interne et 2 pare-feu ASA suspendus à chaque Agg N5K. Les deux sites ont une conception d'image miroir. Nous avons des utilisateurs qui ont besoin d'un accès direct aux applications de batterie de serveurs internes et nous avons également besoin d'une limite de sécurité pour les demandes de connexion sortantes des applications de serveur internes. De plus, j'ai besoin d'héberger des DMZ privées au sein de l'Agg pour isoler les demandes de connexion entrantes de ce que nous classons comme des zones de sécurité inférieures (le N7K CORE utilisera vrf: Global pour les routes vers des sous-réseaux de réseau de sécurité inférieurs).
L'utilisateur est généralement considéré comme des zones sécurisées inférieures, mais cette conception est destinée à héberger un système de contrôle pour un grand réseau électrique. Dans cet esprit, je ne veux pas non plus connecter les utilisateurs directement au N5K Agg pour permettre à SITE1 Server Farm Agg de descendre pour permettre au SITE 2 d'héberger les applications (actuellement, nous connectons les utilisateurs au même commutateur physique que les applications) . Je voudrais fournir une conception de centre de données classique où les utilisateurs acheminent vers la batterie de serveurs à partir du HA L3 CORE (4 x N7K Full Mesh). Cependant, comme ils sont considérés comme le même niveau de sécurité que les «serveurs internes», je souhaite les isoler dans un cloud VPN privé hébergé sur le N7K CORE. En tant que support MPLS de N7K, ce serait le plus logique, cependant, ma conception actuelle a la limite L2 / L3 pour les serveurs internes de l'agrégation Nexus 5548 car les pare-feu y sont également connectés. Les Nexus 5K ne prennent pas en charge MPLS mais ils prennent en charge VRF Lite. Les N5K sont également connectés en maillage complet aux N7K locaux de chaque site.
Pour utiliser les 4 liaisons entre les N5K et les N7K, je dois soit configurer des liaisons pt à pt L3, ce qui ébranle l'idée d'isoler le trafic des utilisateurs internes du noyau du trafic devant être transféré sur le pare-feu, ou je peux utiliser FabricPath entre les 5K. et 7K et utilisez vrf lite où les seuls vlans FabricPath seraient les SVI d'interface entre les 4 nœuds et le vlan extérieur du pare-feu pour connecter la table vrf: Global Routing du N7K. C'est probablement exagéré car ceux-ci doivent être sous licence, mais nous avons des exigences de sécurité uniques, donc le coût a tendance à être un petit problème.
Pour le routage, j'installerais une route par défaut dans le pare-feu pour pointer vers N7K vrf: Global qui exécuterait OSPF ou EIGRP et des routes d'apprentissage vers d'autres réseaux de sécurité inférieurs. Pour la zone hautement sécurisée, j'installerais un vrf: interne sur tous les N5K et N7K et la plupart des utilisateurs exécuteraient BGP car MPLS sur les N7K nécessite l'utilisation de MP-BGP. Cela n'apprendrait que les itinéraires pour la batterie de serveurs internes SITE2 et les utilisateurs internes (nos applications ont besoin de L3 entre les sites pour éviter la scission du cerveau). Je dois également prendre grand soin de ne pas autoriser vrf: Global à échanger des itinéraires avec vrf: Internal car cela créerait un cauchemar asymétrique avec des pare-feu avec état fournissant une connexion L3 entre les 2 vrf. Un itinéraire par défaut simple sur le site N5K local et le pare-feu et un itinéraire récapitulatif sur le N7K pointant vers les sous-réseaux de serveurs internes éviteront ce problème.
Alternativement, j'ai envisagé de construire un autre VDC hors du N7K pour fournir le FHRP et déplacer les pare-feu vers le VDC. Le N5K n'utiliserait que FabricPath et aucun L3 d'aucune sorte.
Étant donné que ce n'est probablement pas une conception typique, j'apprécierais tout commentaire à ce sujet.
