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

[Andrii Oliinyk]

1. Я бы избегал консолидации BN|CP в Stackwise (если только это не FIAB, но, насколько я понимаю, это не ваш случай). Некоторые учетные записи по-прежнему консолидируют BN|CP в VSL, что делает его более надежным, чем Stackwise. В данном конкретном случае VSL подойдет лучше, чем другие.
2. При включенной функции Pub/Sub она будет настроена автоматически в одном пиринге VPNV4 (без пиринга VRF Option A).
3. Учитывая, что Active FW будет единственной точкой для пиринга eBGP с уровнем BN|CP, VSL'ed BN|CP будет лучше подходить здесь, так как требуется единственная сессия. Кроме того, BGP в случае отработки отказа FW будет иметь лучшую конвергенцию. В случае разделенных BN|CP у вас будет 2 варианта: a) пиринг в одной транзитной VLAN (на VRF); б) пиринг в 2 разных транзитных VLAN (на VRF). В последнем случае вам нужно будет настроить 2xINSIDE в одной зоне на FW.
4. В принципе, похоже, что у вас нет лучших вариантов :0)
5. Я бы сказал, что WLC должен быть включен в фабрику. Вы никогда не подключаете его к BN, а только к фабрике.

[jedolphi]

Привет, не прочитал всю ветку, просто отвечаю на последний вопрос. 1. В сети Pub/Sub каждый BN должен иметь как минимум одну передачу на уровне 3 (EBGP peering) на устройство Fusion. 2. Это не является строго необходимым, но рекомендуется иметь как минимум одно точечное маршрутизированное соединение между парами BN. Это соединение будет использовать любой протокол маршрутизации, который использует остальная часть подстилающего уровня, например ISIS. 3. Если BN1/CP1 теряет связь с fusion, он фактически удаляет себя из действительного пути в LISP Pub/Sub. Я расскажу об этом в своей новой лекции Cisco Live Melbourne LISP на следующей неделе. Напомните мне через несколько недель, и я поделюсь ссылкой на запись, если вам интересно. Если BN1/CP1 полностью выходит из строя, он удаляется из подключения IGP, что заставляет все остальные узлы в структуре SDA маршрутизировать трафик на BN2/CP2. С уважением, Джером

[jedolphi]

Практика установки ручного IBGP для каждого VRF между BN была характерна для LISP/BGP. В новых развертываниях следует использовать LISP Pub/Sub. Развертывания LISP/BGP должны быть перенесены на LISP Pub/Sub, когда мы выпустим инструмент миграции в будущем. С Pub/Sub нам больше не нужно вручную настраивать IBGP между BN, пожалуйста, не настраивайте его, это не поможет, а только отнимет ваше время и усложнит сеть. Учитывая, что нам не нужен IBGP между BN, нет необходимости настраивать портовый канал между BN. РЕКОМЕНДУЕТСЯ, но не обязательно, использовать p2p underlay маршрутизированную связь между BN, по крайней мере одну, возможно две. Это позволяет быстро перенаправить исходящий трафик с BN1 на BN2, если BN1 теряет соединение с fusion.

[balaji.bandi]

Сначала я бы посоветовал ознакомиться с руководством по развертыванию: 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

[thenetadmin]

Спасибо
[, @balaji.bandi] 1- В отдельных узлах модели Layer 3 для BNs. Нужно ли нам вручную настраивать IBGP между пограничными узлами, или в последней версии программного обеспечения DNAC есть возможность автоматизировать этот процесс? 2- Я составил схему, чтобы лучше объяснить предлагаемую конструкцию сети. Пожалуйста, не стесняйтесь добавлять свои ценные замечания и рекомендации. 3- Для маршрутизации
интернет-трафика через брандмауэр Internet Edge и трафика DC через брандмауэр DC. Нужно ли настраивать два отдельных пиринга BGP — один с брандмауэром Internet Edge для интернет-трафика, а другой с брандмауэром DC для трафика, направляемого в центр обработки данных? Как здесь будет настроена VN/VRF?

[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.