Sommario

Introduzione

Vincoli che utilizzano la rete tradizionale

Prerequisiti

Requisiti

Componenti usati

Panoramica della soluzione

Progettazione incentrata sulla rete

Progettazione incentrata sull'applicazione

Approcci alla migrazione

Approccio alla migrazione incentrata sulla rete: fase 1

Approccio alla migrazione incentrata sulla rete: fase 2

Approccio alla migrazione incentrata sulla rete: fase 3

Approccio alla migrazione incentrata sull'applicazione: fase 1

Analisi dei dati CSW/Tetration

Contratto

parser_contratto

Considerazioni

Alcune sfide dell'installazione e della soluzione incentrata sull'applicazione

Incremento valore

Introduzione

Questo documento descrive l'approccio per raggiungere la micro-segmentazione e la sicurezza all'interno e tra le applicazioni utilizzando la soluzione Cisco ACI SDN.

Vincoli che utilizzano la rete tradizionale

- Nelle reti tradizionali, la segmentazione all'interno di una VLAN/subnet è impossibile.

- I gateway delle applicazioni si trovano sugli switch di base. Se due applicazioni vogliono comunicare, sullo switch principale sono necessari Access Control Lists (ACL) complessi.

- Il loop Spanning-Tree tra gli switch interrompe il flusso del centro dati e genera una perdita di traffico.

- La stessa subnet IP contiene più applicazioni, che non forniscono la protezione tra di esse. La gestione di queste comunicazioni non è possibile sulle reti tradizionali.

- Si consideri un esempio illustrato anche mediante il diagramma. Sono disponibili tre applicazioni: EP_MB, EP_IB e EP_UPI che fanno parte della stessa VLAN e subnet IP. Con qualsiasi traffico L2, il traffico viene sempre inondato verso tutte le applicazioni, anche se non è richiesta la comunicazione tra di esse. Le restrizioni tra le due applicazioni non sono possibili in questo scenario.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Per raccogliere i dati del flusso di traffico tra le applicazioni, è necessario implementare nell'ambiente Cisco Secure Workload (CSW)/Tetration (Secure Workload).

- Gli agenti devono essere distribuiti sui server per raccogliere i dati. Pertanto, ciò è possibile solo in caso di distribuzione in modalità brownfield.

- Gli agenti devono essere installati sui server per almeno 3-4 settimane per la raccolta dei dati.

- Se non sono disponibili strumenti ADM (Application Dependency Mapping), è necessario fornire i relativi dati.

- Il gateway del server deve essere configurato utilizzando il fabric ACI (Application Centric Infrastructure).

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Panoramica della soluzione

Per ottenere una micro-segmentazione, è necessario innanzitutto migrare la rete a una soluzione SDN Cisco dall'infrastruttura tradizionale e riprogettare la rete da una vista incentrata sull'applicazione. In questa sezione vengono descritte le due fasi di progettazione necessarie per ottenere la segmentazione desiderata in base al flusso dell'applicazione acquisito tramite lo strumento ADM. Inizialmente, la soluzione Cisco ACI viene implementata in modalità Network Centric (così come è con la progettazione esistente) e quindi spostata verso la modalità application-centric.

Nota: è inoltre possibile combinare questa modalità di distribuzione per eseguire la migrazione diretta dei servizi dalla rete tradizionale alla modalità incentrata sull'applicazione.

Progettazione incentrata sulla rete

Nell'esempio mostrato nel diagramma, EPG_VL-100 contiene tre applicazioni, EP_MB, EP_IB e EP_UPI, condivide la stessa subnet IP e utilizza VLAN 100.

- Migrazione As-Is dalla rete tradizionale ad ACI.

- Un gruppo di endpoint (EPG) può contenere più applicazioni.

- Nessuna segmentazione delle applicazioni all'interno dello stesso EPG in questo tipo di distribuzione.

- 1 BD = 1 EPG = 1 VLAN

Progettazione incentrata sull'applicazione

L'esempio mostrato nel diagramma è un EPG separato per tre applicazioni: EP_MB, EP_IB e EP_UPI che condividono la stessa subnet IP e utilizzano VLAN diverse mappate a ciascun EPG.

- Nel tipo di distribuzione incentrata sull'applicazione, vengono configurati diversi EPG in base all'applicazione.

- Le applicazioni continuano a utilizzare la stessa subnet IP e il relativo gateway.

- Gli EPG delle applicazioni segmentate per usare una nuova VLAN.

- 1 BD da configurare con subnet IP e mappare su più EPG dell'applicazione.

- 1 BD = N EPG = N VLAN

- Ora due EPG (applicazioni) possono comunicare tra loro tramite contratto.

Approcci alla migrazione

Prima di distribuire ACI come applicazione-centrico, ACI può essere distribuito come rete-centrico e ulteriormente, le applicazioni possono essere segmentate.

Approccio alla migrazione incentrata sulla rete: fase 1

- È necessario stabilire un collegamento temporaneo di layer 2 tra Border Leaf e Core Switch.

- Configurare il gruppo di domini e di endpoint con bridging di layer 2 sull'ACI in base alle VLAN esistenti configurate nelle reti tradizionali.

- Configurare tutte queste VLAN sul collegamento provvisorio di layer 2 tra gli switch Border Leaf e Core.

- ACI deve apprendere tutti gli endpoint presenti sugli switch core.

- Il gateway rimane sugli switch core.

- La connettività del firewall rimane sugli switch core.

Approccio alla migrazione incentrata sulla rete: fase 2

- Spostare i carichi di lavoro dagli switch di accesso alla foglia del server.

- Il gateway rimane sugli switch core.

- Verificare che il gateway sia raggiungibile dai server.

- Verificare che il server o l'applicazione sia raggiungibile.

Approccio alla migrazione incentrata sulla rete: fase 3

- Spegnere i gateway sugli switch core e configurare su ACI.

- Spostare il collegamento al firewall dagli switch principali a ACI Leaf.

- Configurare l'uscita L3 verso il firewall/router.

- Aggiungere le route nel firewall/router e nella foglia ACI.

- Chiudere il collegamento tra Border Leaf e Core Switch.

- Verificare che il server o l'applicazione sia raggiungibile.

Rappresentazione logica di ACI dopo l'approccio alla migrazione incentrata sulla rete.

Approccio alla migrazione incentrata sull'applicazione: fase 1

- Raccolta e analisi dei dati CSW/Tetration.

- Nuova configurazione EPG in base ai dati CSW/Tetration (WEB, APP e DB).

- Ad esempio, per l'applicazione MB, vengono creati tre EPG come EPG_MB_WEB, EPG_MB_APP e EPG_MB_DB. Questi EPG devono essere configurati in un profilo applicazione AP_MB.

- In caso di integrazione di Virtual Machine Manager (VMM), è necessaria la configurazione vDS per il mapping dei server nel nuovo EPG con la nuova VLAN.

- Eseguire il mapping della macchina virtuale (VM) al nuovo vDS sottoposto a push tramite l'integrazione VMM.

- Per i baremetal, il team del server deve modificare l'ID VLAN sul server.

- L'indirizzo IP deve essere lo stesso per queste implementazioni.

- Configurazione del contratto tra EPG in base ai dati CSW/Tetration.

Analisi dei dati CSW/Tetration

Esempio di analisi basata sui dati CSW/Tetration:

ip_origine

ambito_consumer

dst_ip

ambito_provider

protocollo

port

192.168.34.248

Predefinito:Interno:Sede centrale

192.168.20.81

PRODAPP

TCP

443

192.168.78.45

Predefinito:Interno:Sede centrale

192.168.20.81

PRODAPP

TCP

443

192.168.78.16

Predefinito:Interno:Sede centrale

192.168.20.81

PRODAPP

TCP

443

192.168.78.25

Predefinito:Interno:Sede centrale

192.168.20.81

PRODAPP

TCP

443

192.168.44.69

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:Discovery

192.168.20.81

PRODAPP

UDP

137

192.168.44.69

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:Discovery

192.168.20.81

PRODAPP

TCP

445

192.168.32.173

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:DMZ

192.168.20.81

PRODAPP

TCP

7777

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

135

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

UDP

137

192.168.44.48

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

UDP

137

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

443

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

445

192.168.44.48

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

445

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

5985

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

49154

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

49169

192.168.44.29

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

4750

192.168.44.30

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.81

PRODAPP

TCP

4750

192.168.44.21

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:AAA

192.168.20.81

PRODAPP

ICMP

0

192.168.103.80

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:DHCP

192.168.20.81

PRODAPP

TCP

7777

192.168.103.71

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:DHCP

192.168.20.81

PRODAPP

TCP

7777

192.168.103.20

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:DHCP

192.168.20.81

PRODAPP

TCP

7777

192.168.103.21

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:DHCP

192.168.20.81

PRODAPP

TCP

7777

192.168.44.68

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:Discovery

192.168.20.85

PRODDB

UDP

137

192.168.44.69

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:Discovery

192.168.20.85

PRODDB

UDP

137

192.168.44.68

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:Discovery

192.168.20.85

PRODDB

TCP

445

192.168.44.69

Impostazione predefinita:Internal:Datacenter:DC:Application:Prod:Discovery

192.168.20.85

PRODDB

TCP

445

172.16.32.173

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:MZ

192.168.20.85

PRODDB

TCP

1522

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

135

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

UDP

137

192.168.44.48

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

UDP

137

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

UDP

161

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

445

192.168.44.48

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

445

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

5985

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

49154

192.168.44.47

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

60801

192.168.44.30

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

4750

192.168.44.29

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

TCP

4750

192.168.44.21

Predefinito:Interno:Datacenter:DC:Applicazione:Prod:Monitoraggio

192.168.20.85

PRODDB

ICMP

0

Esempio di raccomandazione EPG da CSW/Tetration:

EPG

IP

PRODAPP

192.168.20.81

RODDB

192.168.20.85

In base ai dettagli, i dati devono essere analizzati per la configurazione del contratto. Esempio di dati analizzati:

ip_origine

ambito_consumer

EPG_consumer

dst

provider_EPG

protocollo

port

192.168.44.69

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Individuazione

INDIVIDUAZIONE_EPG

192.168.20.81

EPG-PROD-APP

UDP

137

192.168.44.69

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Individuazione

INDIVIDUAZIONE_EPG

192.168.20.81

EPG-PROD-APP

TCP

445

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

135

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

UDP

137

192.168.44.48

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

443

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

445

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

5985

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

49154

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

49169

192.168.44.48

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

TCP

4750

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.81

EPG-PROD-APP

ICMP

0

192.168.103.21

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:DHCP

EPG_VL_157

192.168.20.81

EPG-PROD-APP

TCP

7777

192.168.44.68

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Individuazione

INDIVIDUAZIONE_EPG

192.168.20.85

EPG-PROD-DB

UDP

137

192.168.44.68

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Individuazione

INDIVIDUAZIONE_EPG

192.168.20.85

EPG-PROD-DB

TCP

445

192.168.44.69

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

TCP

135

192.168.44.69

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

UDP

137

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

UDP

161

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

TCP

445

192.168.44.48

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

TCP

5985

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

TCP

49154

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

TCP

60801

192.168.44.48

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

TCP

4750

192.168.44.47

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Monitoraggio

MONITORAGGIO_EPG

192.168.20.85

EPG-PROD-DB

ICMP

0

192.168.48.45

Predefinito:Interno:Datacenter: DC:Applicazione:Prod:Backup

EPG_VL_71

192.168.20.85

EPG-PROD-DB

TCP

5555

In base all'indirizzo IP, vengono menzionati gli EPG del consumer e del provider. Le voci duplicate e il traffico Nord-Sud (ad esempio Internet, traffico tra controller di dominio, traffico tra zone e così via) devono essere esclusi da questi dati. Alcuni EPG vengono denominati con VLAN, ad esempio EPG_VL_157, EPG_VL_71 e così via. Ciò significa che questi server non vengono spostati nell'EPG di destinazione come parte della migrazione incentrata sull'applicazione. Quindi, il contratto tra di loro deve essere configurato con l'attuale mappatura di EPG. Una volta eseguita la migrazione di questi server a EPG target, i contratti esistenti devono essere eliminati come parte del processo di pulizia e il contratto appropriato deve essere aggiunto a EPG target.

Contratto

I contratti sono necessari per la comunicazione tra gli EPG. In questa sezione viene illustrato il flusso di implementazione durante il processo di configurazione del contratto.

1. Inizialmente, il contratto VzAny deve essere applicato al livello VRF (Virtual Routing and Forwarding).

2. In base ai dati di CSW/Tetration, devono essere creati contratti EPG specifici.

3. Configurare la regola Deny_All con priorità bassa in modo che il contratto VzAny non consenta comunicazioni del traffico non specificate. Per le applicazioni non ancora migrate come basate sulle applicazioni, la comunicazione avviene tramite il contratto VzAny.

4. Dopo tutta la migrazione, eliminare il contratto VzAny dal VRF.

L'analisi dei dati CSW/Tetration e la loro conversione in oggetti ACI appropriati è un passo molto critico. Quindi, dopo l'analisi iniziale, è importante discutere la nostra osservazione con gli interessati e ottenere una riconferma sullo stesso. Anche durante l'implementazione, è necessario prestare particolare attenzione per garantire che tutto il traffico sia autorizzato come previsto. Per la risoluzione dei problemi, è possibile abilitare la registrazione sul contratto e anche il rilevamento di qualsiasi perdita di pacchetto su una porta specifica usando un'interfaccia GUI o una CLI.

foglia# show logging ip access-list internal packet-log deny

[ Mar 1 ott 10:34:37 2019 377572 usec]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: sconosciuto, Vlan-Id: 0, SMac: 0x000c0c0c0c0c, DMac:0x000c0c0c0c, SIP: 192.168.21 1, DIP: 192.168.22.11, SPort: 0, DPort: 0, Src Intf: Tunnel7, Proto: 1, PktLen: 98

[ Mar 1 ott 10:34:36 2019 377731 usec]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: sconosciuto, Vlan-Id: 0, SMac: 0x000c0c0c0c0c, DMac:0x000c0c0c0c, SIP: 192.168.21 1, DIP: 192.168.22.11, SPort: 0, DPort: 0, Src Intf: Tunnel7, Proto: 1, PktLen: 98

parser_contratto

Script Python sul dispositivo che genera un output che mette in correlazione le regole di zoning, i filtri e le statistiche di accesso durante l'esecuzione di ricerche di nomi da ID. Questo script è estremamente utile in quanto prende un processo a più fasi e lo trasforma in un singolo comando che può essere filtrato in base a EPG/VRF specifici o ad altri valori correlati al contratto.

foglia# parser_contratto.py

Chiave:

[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flag][contratto:{str}] [hit=count]

[7:4131] [vrf:common:default] permette ip tcp tn-Prod1/ap-Services/epg-NTP(16410) tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]

[7:4156] [vrf:common:default] permette ip tcp tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 tn-Prod1/ap-Services/epg-NTP(16410) [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]

[12:4169] [vrf:common:default] deny,log any tn-Prod1/l3out-L3Out1/instP-extEpg(25) epg:any [contract:implicit] [hit=0]

[16:4167] [vrf:common:default] consente qualsiasi epg:any tn-Prod1/bd-Services(32789) [contract:implicit] [hit=0]

I pacchetti scartati possono essere mostrati anche nella GUI usando il percorso: Tenant > Nome_Tenant > Operativo > Flussi/Pacchetti.

Considerazioni

Raccomandazione nell'applicare i contratti tra EPG:

1. ACI non può essere considerato un firewall in termini di mappatura delle policy che può causare l'utilizzo di TCAM (Content Addressable Memory) ad alto livello.

2. Utilizzare un intervallo di filtri anziché un numero elevato di singoli filtri.

3. I contratti non devono utilizzare più di quattro intervalli di filtri. Può consumare elevata capacità di overflow della memoria indirizzabile del contenuto ternario (OTCAM).

4. Se un EPG richiede un numero elevato di porte, provare a utilizzare un contratto "allow any" (permette qualsiasi).

5. Come parte della soluzione, se si prevede la distribuzione di un numero elevato di contratti, valutare l'opportunità di modificare di conseguenza il profilo della scala di inoltro (FSP).

6. Prima di distribuire un numero di contratti in blocco, calcolare il TCAM utilizzando la formula: N. di Fornisci EPG * N. di EPG consumer * Numero di regole.

7. La dimensione TCAM esistente può essere verificata sull'interfaccia utente ACI utilizzando il percorso: Operazioni > Dashboard capacità > Capacità foglia o

LEAF-101# vsh_lc

module-1# show platform internal hal health-stats | _conteggio grep

conteggio_mcast : 0

max_mcast_count : 8192

policy_count : 221

max_policy_count : 65536

policy_otcam_count: 322

max_policy_otcam_count: 8192

policy_label_count : 0

max_policy_label_count : 0

Alcune sfide dell'installazione e della soluzione incentrata sull'applicazione

1. Un maggior numero di contratti può comportare un elevato utilizzo TCAM di switch foglia.

Pertanto, è importante tenere traccia in modo attivo dell'utilizzo di TCAM e preparare un aumento stimato del valore di TCAM quando viene eseguita una grande quantità di installazione della configurazione. È consigliabile utilizzare un processo di controllo del produttore per garantire che la configurazione sottoposta a push sia appropriata. Inoltre, si consiglia di apportare le modifiche con un'adeguata finestra di manutenzione pianificata.

2. La configurazione di massa (oltre 50.000 TCAM) in un singolo push di contratto può causare un crash della memoria di Policy Manager.

Si consiglia di eseguire il push della configurazione in blocchi più piccoli, in particolare quando la configurazione è di grandi dimensioni. Ciò fornisce un approccio sistematico e privo di rischi alla configurazione del contratto. Inoltre, a ogni pressione della configurazione, misurare l'aumento dei valori TCAM.

3. Il flusso del traffico non viene acquisito se le applicazioni non comunicano durante l'intervallo di tempo di installazione di CSW/Tetration (3-4 settimane).

Per evitare una situazione di questo tipo, l'approccio migliore consiste nel verificare nuovamente i dati CSW/Tetration dai proprietari dell'applicazione prima di eseguire l'attività di modifica. Inoltre, dopo l'implementazione, verificare i log per individuare eventuali riscontri di errore.

Incremento valore

1. Tutte le domande sono state segmentate e limitate in base agli orientamenti per le banche centrali.

2. Visibilità della comunicazione tra applicazioni dopo la migrazione alla distribuzione incentrata sulle applicazioni.

3. L'applicazione è sottoposta a microsegmentazione.

4. Una vista del flusso dell'applicazione. In un profilo applicazione, gli EPG vengono mappati in base al flusso di traffico, ad esempio il profilo applicazione AP_Banking, in modo da avere tre EPG (EPG_Banking_WEB, EPG_Banking_APP e EPG_Banking_DB) indipendentemente dalla subnet IP.

4. Una vista del flusso dell'applicazione semplifica la risoluzione dei problemi.

5. L'infrastruttura è più sicura.

6. Approccio strutturato per l'attuazione e la futura espansione.