Ищу рекомендации по развертыванию SDA — конфигурация Fusion FWs и BGP
-
Сначала я бы посоветовал ознакомиться с руководством по развертыванию: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/sda-fabric-deploy-2019oct.pdf У SVL и Seperated есть свои плюсы и минусы (для крупномасштабного развертывания лучше обратиться к системному интегратору или партнеру, чтобы получить хорошие рекомендации по долгосрочной поддержке). 1. По моему мнению, я выбираю модель с отдельными узлами Layer 3. 2. Ответ на этот вопрос дан выше. 3. Все зависит от того, как вы подключаетесь к коммутатору Uplink, поток трафика зависит от того, где находится активный брандмауэр и какая у вас настройка маршрутизации. 4. Опять же, все зависит от того, какой трафик должен проходить через какой брандмауэр, и от вашего решения по маршрутизации. 5. Проверьте руководство по проектированию, где должен находиться WLC (должен быть в DC или домене управления), посмотрите, является ли это SDA-Wireless или over the top. BB
=====Preenayamo Vasudevam=====
***** Оцените все полезные ответы *****
Как обратиться за помощью к сообществу Cisco -
Спасибо
[, @balaji.bandi] 1- В отдельных узлах модели Layer 3 для BNs. Нужно ли нам вручную настраивать IBGP между пограничными узлами, или в последней версии программного обеспечения DNAC есть возможность автоматизировать этот процесс? 2- Я составил схему, чтобы лучше объяснить предлагаемую конструкцию сети. Пожалуйста, не стесняйтесь добавлять свои ценные замечания и рекомендации. 3- Для маршрутизации
интернет-трафика через брандмауэр Internet Edge и трафика DC через брандмауэр DC. Нужно ли настраивать два отдельных пиринга BGP — один с брандмауэром Internet Edge для интернет-трафика, а другой с брандмауэром DC для трафика, направляемого в центр обработки данных? Как здесь будет настроена VN/VRF?
-
Спасибо,
@Andrii Oliinyk Некоторые учетные записи по-прежнему объединяют BN|CP в VSL, что делает его более надежным, чем Stackwise. В данном конкретном случае VSL подойдет лучше, чем другие. Здесь вы имеете в виду VSS. Я согласен, VSS будет гораздо лучше, чтобы избежать создания большого количества BGP-пирингов. Но VSS может быть проблематичным для окна обслуживания при обновлении программного обеспечения. BN/CP будет недоступен с включенной функцией Pub/Sub он будет настроен автоматически в одном пиринге VPNV4 (без пиринга VRF Option A) Я не понял, не могли бы вы пояснить подробнее В принципе, похоже, что у вас нет лучших вариантов :0) Но является ли целесообразным или стандартной практикой создавать отдельные пиринги BGP с каждым брандмауэром Internet Edge и DC, если у клиента два отдельных развертывания брандмауэра Я бы сказал, что WLC должен быть включен в фабрику. Вы никогда не подключаете его к BN, а только к внешней фабрике. В обоих случаях, с поддержкой Fabric и без поддержки Fabric, где WLC будет подключаться к сети? -
VSL против отдельных BN|CP: решение зависит от вас, учитывая все «за» и «против»
VRF Вариант A: по сути, это пиринг в произвольном VRF: адресная семья ipv4 vrf CAPMUS. именно это BN|CPs делают по отношению к FN.
между собой они осуществляют пиринг в адресной семье vpnv4. таким образом, они обмениваются VPNV4 NLRIs для каждого из своих VRF в рамках единого пиринга.
Пиринг с FNs разного типа: CVD рекомендует использовать отдельные BN-слои для пиринга с внутренними сущностями и Интернетом (Internal BN & External BN). Если вы хотите остаться с одним BN-слоем, вам нужно использовать Anywhere BN.
Расположение WLC: вы можете использовать eWLC на ваших BN|CP. Он будет работать как для VSL, так и для отдельных узлов. Но с отдельными узлами ваша беспроводная избыточность будет основана на первичном и вторичном WLS вместо HA SSO с VSL. -
Буду благодарен за любые дополнительные предложения
@Andrii Oliinyk
@balaji.bandi -
Привет
[, @Andrii Oliinyk] В случае раздельных BN|CP у вас будет 2 варианта: a) пиринг в одной транзитной VLAN (по VRF); b) пиринг в 2 разных транзитных VLAN (по VRF). В последнем случае вам нужно будет настроить 2xINSIDE в одной зоне на FW. Для варианта B нужен ли нам выделенный L2-коммутатор между брандмауэрами и BN/CP? -
Нет. Просто подключите каждый FW-блок к BN|CP1 и BN|CP2 с помощью отдельного физического соединения. С обеих сторон это должен быть интерфейс с .1Q encap (l.s. VLAN 300-302 для пиринга с FW из BN|CP1 в 3 разных VRF и VLAN 310-312 для пиринга с FW из BN|CP2 в тех же 3 VRF).
Затем вы создаете сессии между FW (вручную) и BN|CP (рабочие процессы L3-handoff). Еще нужно учесть (на примере ASA
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118050-config-bgp-00.html#:~:text=individual%20routing%20protocols.-,BGP%20and%20Failover,-BGP%20is%20supported
) -
Привет
[, @Andrii Oliinyk] Я обновил схему. Учитывая это,
две отдельные границы, оба пограничных узла будут иметь отдельные активные BGP-соединения с брандмауэрами Internet Edge и Data Center. Каждая граница может независимо маршрутизировать трафик к этим брандмауэрам и от них. Объявите маршрут по умолчанию для брандмауэров Fusion от брандмауэров Internet. Благодарим вас за ценный вклад.
-
выглядит просто, как диаграммы из CVD :0)
- между BN|CPs также имеется маршрутизированное соединение IS-IS, которое используется для пиринга IBGP в VPNv4 AF.
- рекомендуется пересмотреть все ваши сценарии использования доступа в Интернет, чтобы правильно решить эту проблему с помощью этой простой диаграммы.
-
Привет
[, @Andrii Oliinyk] Зачем нам нужен iBGP между границами, если по этому каналу не будет проходить трафик? Соединения от каждой границы к слиянию вполне подходят. Крайняя точка фабрики будет иметь сессии LISP с балансировкой нагрузки типа BN/CP. Обе границы имеют BGP-пиринг с Fusion, поэтому оба BN/CP также будут балансировать нагрузку на Fusion. -
Ответ находится здесь
[) -
Привет
[, @Andrii Oliinyk] Для резервирования границ мы будем использовать
LISP Pub/Sub
при их настройке как BN/CP, что должно обеспечить динамическую настройку границ по умолчанию. Я обновил схему сети. Мы также настроим два физических соединения между пограничными узлами. Мой вопрос: Требуют ли эти межграничные соединения ручной настройки, или Cisco DNA Center автоматически подключит и настроит эти соединения в рамках настройки LISP Pub/Sub?
WLC будет поддерживать фабрику. Можем ли мы подключить WLC к вышестоящим коммутаторам в пространстве центра обработки данных (коммутаторы Nexus), как показано на схеме, но между BN и коммутаторами Nexus находится брандмауэр Буду признателен за вашу помощь.
-
Ссылка Inter BN|CP: указано, что она настраивается автоматически с PubSub:
[)
. Но я заметил, что Cisco CX предпочитает настраивать это вручную в рамках предварительной подготовки перед миграцией в коричневых полях... Я не пробовал автоматизировать этот процесс.
WLC: если у вас есть веские причины избегать развертывания первичного/вторичного eWLC на BN|CP, вы можете сделать это, как только RTT и т. д. будут соответствовать требованиям SDA. Я уверен, что вы не забудете открыть CAPWAP и LISP на FW для интерфейсов AP-WLC и CP-WLC.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти