Часть 1 из серии из пяти частей об использовании ИИ для проектирования сетей: создание сетевой песочницы производственного уровня с Claude в качестве второго архитектора, а не просто инструмента, у которого я запрашиваю факты. Остальные материалы серии: Часть 2 — Фабрика, которую спроектировал Claude; Часть 3 — Почему я позволил Claude отговорить меня от его собственного проекта; Часть 4 — От доски для рисования до монтажа в стойку; Часть 5 — Сбой, который Claude диагностировал за считанные минуты.
Сразу скажу о своем первоначальном настрое: я был настроен скептически. В ходе одного короткого ревью сетевого дизайна с помощью ИИ Claude обнаружил ошибку в кабельной разводке, которую я собирался допустить, а всего несколько вопросов спустя два маршрутизатора, заложенные в бюджет, превратились в запасные.
Я строил сеть в песочнице на базе реальных межсетевых экранов Cisco, реальных пограничных маршрутизаторов и реальной коммутационной фабрики Nexus: это оборудование стоит реальных денег и не перекоммутируется по первому капризу. Я уже много раз пользовался ИИ-чат-ботами для составления чертежей и резюме, но я никак не ожидал, что один из них станет возражать против топологии корпоративной сети. В лучшем случае, думал я, он вежливо со мной согласится и просто выдаст спецификацию.
Поэтому, прежде чем проложить хотя бы один кабель, я открыл чат с Claude, выложил свою полную топологию и задал самый простой вопрос: рабочая ли это схема?
План: межсетевые экраны, маршрутизаторы и фабрика Nexus
Мой план включал два устройства Cisco Secure Firewall 3100 под управлением Secure Firewall Threat Defense (FTD) для подключения к интернету, два защищенных маршрутизатора Cisco C8475-G2 (серия Cisco 8400) за ними для обеспечения связи на периметре, а под ними — двухуровневую фабрику Nexus: коммутаторы Cisco Nexus 93600CD-GX в качестве магистралей (spines) и коммутаторы Cisco Nexus 93180YC-FX в качестве листьев (leaves). На бумаге все выглядело аккуратно: интернет, межсетевые экраны, маршрутизаторы, фабрика, готово.
Перед ответом он проверил оборудование
Первым действием Claude не было выражение мнения о моем дизайне. Он заявил, что сначала хочет проверить одну из моделей оборудования, после чего занялся ее поиском.
Этот маленький шаг сказал мне больше, чем я ожидал. Ему ничего не стоило просто кивнуть («да, это разумная топология»), и я бы, наверное, даже не стал сомневаться. Вместо этого он отнесся к вопросу «действительно ли я знаю это устройство» как к задаче, которую нужно решить в первую очередь — именно такого инстинкта я жду от коллеги, который проверяет мою работу, а не просто соглашается со мной ради вежливости.
Оборудование прошло проверку: C8475-G2 — это легитимная, довольно свежая платформа, входящая в семейство защищенных маршрутизаторов Cisco серии 8400. Проблема была в другом.
Нюанс: магистрали должны подключаться только к листьям
Вот как примерно все происходило:
Я: У меня есть два FTD для интернета, два маршрутизатора C8475 за ними, а затем магистрали 93600 и листья 93180. Claude: Оборудование в полном порядке, общая схема надежна, но есть две вещи, которые я бы изменил. В фабрике spine-leaf магистрали должны подключаться только к листьям. Ничего другого (никаких серверов, межсетевых экранов или WAN-маршрутизаторов) к магистралям подключаться не должно. Внешнее подключение вместо этого организуется через выделенные пограничные листья (border leaves). Подключение маршрутизаторов к магистралям нарушает это правило.
Я: У меня есть два FTD для интернета, два маршрутизатора C8475 за ними, а затем магистрали 93600 и листья 93180.
Claude: Оборудование в полном порядке, общая схема надежна, но есть две вещи, которые я бы изменил. В фабрике spine-leaf магистрали должны подключаться только к листьям. Ничего другого (никаких серверов, межсетевых экранов или WAN-маршрутизаторов) к магистралям подключаться не должно. Внешнее подключение вместо этого организуется через выделенные пограничные листья (border leaves). Подключение маршрутизаторов к магистралям нарушает это правило.
Я задумался над этим на секунду, потому что моя схема не казалась мне неправильной, когда я ее рисовал. Мысленная логика «маршрутизаторы — это периметр, магистрали — это верх фабрики, периметр подключается к верху» казалась вполне разумным сокращением.
Claude описал рекомендованную практику Cisco: магистрали подключаются только к листьям, а руководство по проектированию Cisco VXLAN BGP EVPN размещает внешние подключения на пограничных листьях. Использование пограничных магистралей поддерживается, но это усложняет масштабирование.
Моя схема нарушала то единственное свойство, которое позволяет фабрике Clos масштабироваться чисто. Магистрали остаются исключительно транзитными элементами, не хранящими никакой внешней информации о состоянии, поэтому последующее наращивание емкости фабрики никогда не требует изменения конфигурации магистралей. Стоит повесить маршрутизатор на магистраль, и каждое будущее расширение магистрали унаследует это исключение.
Claude подкрепил это фактом, который я мог проверить за 30 секунд: пропускная способность C8475-G2 составляет максимум 25 Гбит/с на порт (SFP28), в то время как порты магистрали 93600 — это QSFP (40/100 Гбит/с, а также 400 Гбит/с). Прямое соединение их кабелями потребовало бы применения переходных кабелей или адаптеров только для поднятия линка. Если оглянуться назад, это был физический намек на то, что эти два устройства никогда не предназначались для прямого соединения точка-точка.
Решение оказалось простым, как только его озвучили: перенести маршрутизаторы и межсетевые экраны на пару выделенных пограничных листьев, а магистралям вернуть их чисто магистральные функции. Пятиминутный разговор уберег меня от прокладки кабелей по ошибочной схеме, которую потом было бы неприятно переделывать после монтажа в стойку.
Топология после первого исправления: межсетевые экраны подключаются через пару пограничных листьев, а магистрали подключаются только к листьям.
Вопрос, который оказался важнее исправления
Именно это изменило мое отношение ко всему остальному проекту. Claude не остановился на фразе «я исправил твою схему, пожалуйста». Он задал вопрос, на который я сам себе еще не ответил:
Claude: Для чего вообще нужны маршрутизаторы? «Подключение к периметру сети» может означать головной узел WAN/SD-WAN для удаленных площадок и нескольких интернет-провайдеров, для чего это оборудование и создано, либо это может быть просто лишний хоп за межсетевыми экранами, которые и так выполняют NAT и инспекцию трафика. Это разные задачи, и они ведут к разным топологиям.
Claude: Для чего вообще нужны маршрутизаторы? «Подключение к периметру сети» может означать головной узел WAN/SD-WAN для удаленных площадок и нескольких интернет-провайдеров, для чего это оборудование и создано, либо это может быть просто лишний хоп за межсетевыми экранами, которые и так выполняют NAT и инспекцию трафика. Это разные задачи, и они ведут к разным топологиям.
У меня не было четкого ответа. Я унаследовал концепцию «маршрутизаторы за межсетевыми экранами» как готовую форму, не задаваясь вопросом о ее смысле. Это паттерн, с которым я сталкивался снова и снова на протяжении всего проекта: самое ценное, что сделал Claude, — это не исправление моей схемы, а отказ пустить на самотек расплывчатое требование без его предварительного анализа.
Один вопрос с ответом да/нет изменил всю архитектуру
В ходе дальнейшего обсуждения я внес ясность: маршрутизаторы не будут запускать BGP, межсетевым экранам нужен лишь стандартный маршрут по умолчанию (default route) от интернет-провайдера, а на фабрике будут использоваться классические VLAN, а не оверлей. Это подняло другой вопрос, над которым я не задумывался: если маршрутизаторы не используют BGP, должны ли они отвечать за межсегментную маршрутизацию (inter-VLAN routing) для фабрики?
Ответ Claude был прямым и подкрепленным реальными цифрами: нет. Оба коммутатора Nexus являются полноценными коммутаторами уровня Layer 3, которые выполняют маршрутизацию «железом» на скорости линии (line rate), в то время как производительность маршрутизаторов ограничена примерно 91 Гбит/с, что является максимальной скоростью форвардинга в Cisco 8400 Series Secure Routers data sheet.
Если настроить шлюзы фабрики на маршрутизаторах, то каждый межсегментный пакет (а это большая часть трафика в вычислительной среде) будет покидать фабрику, проходить петлей через это «бутылочное горлышко» и возвращаться обратно. Коммутаторы должны заниматься маршрутизацией; а маршрутизаторы, если они вообще нужны, должны отвечать только за северный маршрут по умолчанию (northbound default) и ничего более.
Затем последовала развилка, которая определила все дальнейшие решения: должны ли мои VLAN работать более чем на одном leaf-коммутаторе? Классические VLAN не могут простираться через маршрутизируемую фабрику spine-leaf без оверлея, поэтому ответ должен был определить выбор между маршрутизируемой архитектурой Clos (routed-access) и двухуровневой архитектурой aggregation/access.
Я подтвердил: да, их нужно объединить. Вывод Claude был простым: эта фабрика на самом деле больше не является архитектурой spine-leaf. Это двухуровневый дизайн vPC.
Без той роли на уровне Layer 3, которую я им мысленно отвел, у маршрутизаторов ничего не осталось на пути передачи данных. Оставьте их в качестве резервных или для будущих нужд WAN. Не выбрасывайте. Просто они ничего не делают сегодня.
Чему этот первый обмен мнениями научил меня в области проектирования сетей с помощью ИИ
Я шел туда в расчете на быструю проверку. То, что я получил, было ближе к экспертной оценке дизайна от того, кто отказался позволить фразе «выглядит правильно» заменить собой «я проверил, почему это правильно».
Два устройства, которые я заложил в бюджет как базовую инфраструктуру, оказались запасными еще до того, как я потратил хоть доллар на кабельную разводку. Это тот тип ошибок, исправление которых дешево в окне чата и дорого в дата-центре.
Что этот раунд прояснил для меня:
- Просите об оценке, а не о факте. Предоставьте агенту весь проект и открытый вопрос. Хороший обзор не просто исправляет схему; он спрашивает, что вы на самом деле пытались построить.
- Заставьте систему проверить, а затем проверьте ее сами. Claude проверил номер детали, прежде чем высказать свое мнение, а я подтвердил его довод о скорости портов за 30 секунд. Эту привычку полезно иметь как у человека, так и у инструмента.
- Точно отвечайте на его вопросы. Самый важный вопрос в этом проекте — должны ли VLAN охватывать более чем один leaf-коммутатор? — состоял всего из одного предложения, и я даже не подумал задать его себе.
Прежде чем монтировать что-либо в стойку, попробуйте провести аналогичную проверку сетевого дизайна с помощью ИИ для собственной топологии.
Мы остановились на двухуровневом дизайне vPC, потому что он соответствовал требованиям, которые я фактически озвучил. Но я хотел узнать, от чего я откажусь, пропустив оверлей в первый же день, поэтому в следующем разговоре я попросил Claude спроектировать и эту версию. Часть 2 посвящена именно этой фабрике: той, которую мы полностью спроектировали и в итоге не построили.
