Mam 2 witryny Centrum sterowania, z których każda zawiera 2 N7K w pełnej strukturze siatki i 2 Nexus 5548UP jako agregację farmy serwerów wewnętrznych i 2 zapory ogniowe ASA zwisające z każdym agregatem N5K. Obie witryny mają lustrzane odbicie. Mamy użytkowników, którzy potrzebują bezpośredniego dostępu do wewnętrznych aplikacji farmy serwerów, a także potrzebujemy granicy bezpieczeństwa dla żądań połączeń wychodzących z aplikacji serwera wewnętrznego. Ponadto muszę hostować prywatne strefy DMZ w Agg, aby odizolować żądania połączeń przychodzących od tego, co klasyfikujemy jako niższe strefy bezpieczeństwa (CORE N7K użyje vrf: Global dla tras do podsieci sieciowych o niższym poziomie bezpieczeństwa).
Zwykle użytkownik byłby uważany za niższe strefy bezpieczeństwa, ale ten projekt służy do hostowania systemu sterowania dla dużej sieci energetycznej. Mając to na uwadze, nie chcę również podłączać użytkowników bezpośrednio do N5K Agg, aby umożliwić SITE1 Server Farm Agg możliwość opuszczenia, umożliwiając SITE 2 hostowanie aplikacji (obecnie podłączamy użytkowników do tego samego przełącznika fizycznego co aplikacje) . Chciałbym przedstawić klasyczny projekt centrum danych, w którym użytkownicy kierują się do farmy serwerów z HA L3 CORE (4 x N7K Full Mesh). Ponieważ jednak są one uważane za taki sam poziom bezpieczeństwa jak „serwery wewnętrzne”, chcę je odizolować w prywatnej chmurze VPN hostowanej na rdzeniu N7K. Ponieważ jednak N7K obsługuje MPLS, byłoby to najbardziej logiczne, mój obecny projekt ma granicę L2 / L3 dla serwerów wewnętrznych w agregacji Nexus 5548, ponieważ tam również są zapory ogniowe. Nexus 5K nie obsługuje MPLS, ale obsługuje VRF Lite. N5K są również połączone w pełnej siatce z lokalnymi N7K w każdym miejscu.
Aby wykorzystać wszystkie 4 łącza między N5K a N7K, muszę albo skonfigurować łącza pt do pt L3, które gołąbek dziurawią izolację ruchu użytkownika wewnętrznego od rdzenia od ruchu wymagającego przesłania zapory ogniowej, lub mogę użyć FabricPath między 5K oraz 7K i użyj vrf lite, gdzie jedynymi sieciami FabricPath byłby interfejs SVI między 4 węzłami i zewnętrznym vlanem zapory do połączenia tabeli vrf: Global Routing w N7K. Jest to prawdopodobnie przesada, ponieważ muszą być licencjonowane, ale mamy unikalne wymagania bezpieczeństwa, więc koszty są zwykle niewielkim problemem.
W przypadku routingu zainstalowałbym domyślną trasę w zaporze ogniowej, aby wskazywać N7K vrf: Global, która uruchamiałaby OSPF lub EIGRP i uczyła tras do innych sieci o niższym poziomie bezpieczeństwa. W przypadku strefy High Secure, zainstalowałbym vrf: Internal na wszystkich N5K i N7K i najbardziej podobna działałaby BGP, ponieważ MPLS w N7K wymaga użycia MP-BGP. To nauczyłoby się tylko tras dla farmy serwerów wewnętrznych SITE2 i użytkowników wewnętrznych (nasze aplikacje potrzebują L3 między witrynami, aby zapobiec podziałowi mózgu). Muszę również bardzo uważać, aby nie zezwolić vrf: Global na wymianę tras z vrf: Internal, ponieważ stworzyłoby to asymetryczny koszmar z Stateful Firewalls zapewniającymi połączenie L3 między 2 vrf. Prosta domyślna trasa w lokalnej witrynie N5K i zaporze oraz trasa podsumowująca w N7K wskazująca na wewnętrzne podsieci serwera zapobiegnie temu problemowi.
Alternatywnie, rozważałem zbudowanie kolejnego VDC poza N7K, aby zapewnić FHRP i przenieść zapory ogniowe do VDC. N5K używałby tylko FabricPath, a nie L3 jakiegokolwiek rodzaju.
Ponieważ prawdopodobnie nie jest to typowy projekt, byłbym wdzięczny za wszelkie opinie na ten temat.
