Ищу рекомендации по развертыванию SDA — конфигурация Fusion FWs и BGP

[thenetadmin]

Спасибо,
@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 будет подключаться к сети?

[Andrii Oliinyk]

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.

[thenetadmin]

Буду благодарен за любые дополнительные предложения
@Andrii Oliinyk
@balaji.bandi

[thenetadmin]

Привет
[, @Andrii Oliinyk] В случае раздельных BN|CP у вас будет 2 варианта: a) пиринг в одной транзитной VLAN (по VRF); b) пиринг в 2 разных транзитных VLAN (по VRF). В последнем случае вам нужно будет настроить 2xINSIDE в одной зоне на FW. Для варианта B нужен ли нам выделенный L2-коммутатор между брандмауэрами и BN/CP?

[Andrii Oliinyk]

Нет. Просто подключите каждый 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
)

[thenetadmin]

Привет
[, @Andrii Oliinyk] Я обновил схему. Учитывая это,
две отдельные границы, оба пограничных узла будут иметь отдельные активные BGP-соединения с брандмауэрами Internet Edge и Data Center. Каждая граница может независимо маршрутизировать трафик к этим брандмауэрам и от них. Объявите маршрут по умолчанию для брандмауэров Fusion от брандмауэров Internet. Благодарим вас за ценный вклад.

[Andrii Oliinyk]

выглядит просто, как диаграммы из CVD :0)

1. между BN|CPs также имеется маршрутизированное соединение IS-IS, которое используется для пиринга IBGP в VPNv4 AF.
2. рекомендуется пересмотреть все ваши сценарии использования доступа в Интернет, чтобы правильно решить эту проблему с помощью этой простой диаграммы.

[thenetadmin]

Привет
[, @Andrii Oliinyk] Зачем нам нужен iBGP между границами, если по этому каналу не будет проходить трафик? Соединения от каждой границы к слиянию вполне подходят. Крайняя точка фабрики будет иметь сессии LISP с балансировкой нагрузки типа BN/CP. Обе границы имеют BGP-пиринг с Fusion, поэтому оба BN/CP также будут балансировать нагрузку на Fusion.

[Andrii Oliinyk]

Ответ находится здесь
[)

[thenetadmin]

Привет
[, @Andrii Oliinyk] Для резервирования границ мы будем использовать
LISP Pub/Sub
при их настройке как BN/CP, что должно обеспечить динамическую настройку границ по умолчанию. Я обновил схему сети. Мы также настроим два физических соединения между пограничными узлами. Мой вопрос: Требуют ли эти межграничные соединения ручной настройки, или Cisco DNA Center автоматически подключит и настроит эти соединения в рамках настройки LISP Pub/Sub?
WLC будет поддерживать фабрику. Можем ли мы подключить WLC к вышестоящим коммутаторам в пространстве центра обработки данных (коммутаторы Nexus), как показано на схеме, но между BN и коммутаторами Nexus находится брандмауэр Буду признателен за вашу помощь.

[Andrii Oliinyk]

Ссылка Inter BN|CP: указано, что она настраивается автоматически с PubSub:
[)
. Но я заметил, что Cisco CX предпочитает настраивать это вручную в рамках предварительной подготовки перед миграцией в коричневых полях... Я не пробовал автоматизировать этот процесс.
WLC: если у вас есть веские причины избегать развертывания первичного/вторичного eWLC на BN|CP, вы можете сделать это, как только RTT и т. д. будут соответствовать требованиям SDA. Я уверен, что вы не забудете открыть CAPWAP и LISP на FW для интерфейсов AP-WLC и CP-WLC.