У меня есть 2 центра управления, каждый из которых имеет 2 N7K в дизайне с полной сеткой и 2 Nexus 5548UP в качестве агрегации внутренней фермы серверов и 2 межсетевых экрана ASA, свисающие с каждой агрегации N5K. Оба сайта имеют зеркальный дизайн. У нас есть пользователи, которым необходим прямой доступ к приложениям внутренней серверной фермы, а также нам нужна граница безопасности для запросов на исходящее соединение от внутренних серверных приложений. Кроме того, мне нужно разместить частные DMZ в Agg, чтобы изолировать входящие запросы на соединение от того, что мы классифицируем как зоны с более низким уровнем безопасности (N7K CORE будет использовать vrf: Global для маршрутов к более низким сетевым подсетям безопасности).
Обычно пользователя считают зонами с более низкой безопасностью, но этот дизайн предназначен для размещения системы управления большой электрической сетью. Имея это в виду, я также не хочу подключать пользователей напрямую к N5K Agg, чтобы позволить SITE1 Server Farm Agg возможность отключаться, позволяя SITE 2 размещать приложения (в настоящее время мы подключаем пользователей к тому же физическому коммутатору, что и приложения) , Я хотел бы представить классический дизайн центра обработки данных, в котором пользователи направляются на ферму серверов из HA L3 CORE (4 x N7K Full Mesh). Однако, поскольку они считаются с тем же уровнем безопасности, что и «Внутренние серверы», я хочу изолировать их в частном облаке VPN, размещенном на N7K CORE. Поскольку N7K поддерживает MPLS, это было бы наиболее логичным, однако, мой текущий дизайн имеет границу L2 / L3 для внутренних серверов в агрегации Nexus 5548, поскольку там также подключены межсетевые экраны. Nexus 5K не поддерживают MPLS, но они поддерживают VRF Lite. N5K также подключены в полной сетке к локальным N7K на каждом сайте.
Чтобы использовать все 4 канала связи между N5K и N7K, мне нужно либо настроить каналы pt на pt L3, которые не дают возможности изолировать трафик внутреннего пользователя от ядра от трафика, необходимого для пересылки через брандмауэр, или я могу использовать FabricPath между 5K и 7K и использовать vrf lite, где единственными vlans FabricPath будут интерфейсные SVI между 4 узлами и внешним vlan брандмауэра для подключения таблицы vrf: Global Routing N7K. Это, вероятно, излишне, так как они должны быть лицензированы, но у нас есть уникальные требования безопасности, поэтому стоимость, как правило, небольшая проблема.
Для маршрутизации я бы установил маршрут по умолчанию в брандмауэре, чтобы он указывал на N7K vrf: Global, который будет запускать OSPF или EIGRP и изучать маршруты в другие сети с более низким уровнем безопасности. Для зоны высокой безопасности я бы установил vrf: Internal на всех N5K и N7K, и, скорее всего, запустил бы BGP, поскольку MPLS на N7K требует использования MP-BGP. Это позволит узнать только маршруты для внутренней фермы серверов SITE2 и внутренних пользователей (нашим приложениям необходим L3 между сайтами для предотвращения разделения мозга). Я также должен быть очень осторожен, не позволяя vrf: Global обмениваться маршрутами с vrf: Internal, поскольку это создаст асимметричный кошмар с Stateful Firewall, обеспечивающим соединение L3 между двумя vrf. Простой маршрут по умолчанию на локальном сайте N5K и межсетевом экране и суммарный маршрут в N7K, указывающий на подсети внутреннего сервера, предотвратят эту проблему.
В качестве альтернативы я рассмотрел возможность создания другого VDC на N7K для обеспечения FHRP и перемещения брандмауэров на VDC. N5K будет использовать только FabricPath, а не L3.
Поскольку это, скорее всего, не типичный дизайн, я был бы признателен за любые отзывы по этому поводу.
