У мене є 2 сайти Центру управління, кожен з яких має 2 N7K з повною сіткою та 2 Nexus 5548UP як агрегацію внутрішнього фермерського сервера та 2 брандмауери ASA, що звисають з кожного N5K Agg. Обидва сайти мають дизайн дзеркального зображення. У нас є користувачі, яким потрібен прямий доступ до внутрішніх додатків для фермерських серверів, а також нам потрібна межа безпеки для запитів на вихідні з'єднання із додатків внутрішніх серверів. Крім того, мені потрібно розмістити приватні DMZ в межах Agg, щоб виділити запити вхідного з'єднання від того, що ми класифікуємо як нижчі зони безпеки (N7K CORE буде використовувати vrf: Global для маршрутів до нижчих підмереж безпеки).
Зазвичай користувачем вважаються нижчі захищені зони, але ця конструкція призначена для розміщення системи управління для великої електромережі. Зважаючи на це, я також не хочу підключати користувачів безпосередньо до Ag5 N5K, щоб дозволити SITE1 Server Farm Agg знижуватися, дозволяючи SITE 2 розміщувати програми (зараз ми підключаємо користувачів до того ж фізичного перемикача, що і програми) . Я хотів би надати класичний дизайн Центру обробки даних, коли користувачі рухаються до ферми серверів від HA L3 CORE (4 x N7K Full Mesh). Однак, оскільки вони вважаються таким же рівнем безпеки, що і "внутрішні сервери", я хочу виділити їх у приватну хмару VPN, розміщену на N7K CORE. Як підтримка MPLS від N7K, це було б найбільш логічно, моя поточна конструкція має межу L2 / L3 для внутрішніх серверів на агрегації Nexus 5548, оскільки між ними також підключені міжмережеві стіни. Nexus 5K не підтримує MPLS, але вони підтримують VRF Lite. N5K також підключаються в повній сітці до локальних N7K на кожній ділянці.
Щоб використовувати всі 4 ланки між N5K і N7K, мені або потрібно налаштувати pt на pt L3 посилання, які блукають ідеєю виділення внутрішнього трафіку користувача від Core від трафіку, який потребує переадресації брандмауера, або я можу використовувати FabricPath між 5K та 7K та використовуйте vrf lite, де єдиним вланом FabricPath буде інтерфейс SVI між 4-ма вузлами та зовнішньою програмою брандмауера для підключення vrf таблиці N7K: Global Routing. Це, мабуть, надмірне значення, оскільки вони мають бути ліцензованими, але у нас є унікальні вимоги безпеки, тому вартість, як правило, є невеликою проблемою.
Для маршрутизації я б встановив маршрут у брандмауері за замовчуванням, щоб вказати на N7K vrf: Global, який би запускав OSPF або EIGRP та навчав маршрути до інших нижчих мереж безпеки. Для зони високої безпеки я встановив би vrf: Internal на всіх N5K та N7K, і більшість подібних запускається BGP, оскільки MPLS в N7K вимагає використання MP-BGP. Це дізнається лише маршрути для внутрішньої ферми серверів SITE2 та внутрішніх користувачів (для наших додатків потрібен L3 між Сайтами, щоб запобігти розбиттю мозку). Я також повинен дуже обережно не дозволити vrf: Global не обмінюватися маршрутами з vrf: Internal, оскільки це створило б асиметричний кошмар із брандмауерами Stateful, що забезпечують зв'язок L3 між двома vrf-кодами. Простий маршрут за замовчуванням на локальних веб-сайтах N5K та брандмауер та зведений маршрут у N7K, що вказує на внутрішні підмережі сервера, запобігатиме цій проблемі.
Альтернативно, я розглядав можливість побудувати ще один VDC від N7K, щоб забезпечити FHRP та перемістити брандмауери до VDC. N5K використовує лише FabricPath і не має жодного L3.
Оскільки це, швидше за все, не типовий дизайн, я буду вдячний за будь-які відгуки з цього приводу.
