ACI multisite with integration FW devices scenario and service-grapth best-practices

11.03 2022 | by massimiliano

ACI multisite with integration FW devices scenario and service-grapth best-practices L’integrazione di Firewall (CheckPoint) con ACI Multi-Site Fabric prevede […]

https://www.ingegnerianetworking.com/wp-content/uploads/2022/03/graph-1-6e4.png

L’integrazione di Firewall (CheckPoint) con ACI Multi-Site Fabric prevede l’inserimento in modo indipendente di questi elementi devices in cluster active-standby all’interno della stessa Fabric secondo delle opzioni.

Premessa:

si definisce Provider uno o più servers oppure un set di devices che provvede a fornire servizi ad altri server oppure devices;

si definisce Consumer uno o più client oppure un set di devices che fruisce dei servizi erogati dal provider;

dal punto di vista del Servizio il provider è spesso pensato come una inside interface (oppure il lato di fronte ai server), viceversa il consumer è spesso pensato come una outside interface (oppure il lato di fronte ai client).

Option 1:

Se il devices FW è collegato in L3 mode alla Fabric, è mandatorio il rilascio della funzionalità “ingress optimisation” la quale richiede host route advertisement

Option 2:

Mediante l’utilizzo di service graph.

In caso di PBR attraverso le seguenti operazioni:

Traffic Inbound

il traffico inbound può entrare un qualsiasi Site-Fabric quando destinato ad una rete di tipo stretched (se la funzionalità “ingress optimisation” non è presente o configurata)
una PBR policy è sempre applicata a livello Leaf node dove l’endpoint di destinazione è collegato
PBR sempre re-dirige il traffico al cluster Firewall locale
mandatorio l’uso di Leaf node modello EX – FX

Traffic Outbound

il traffico outbound deve sempre utilizzare un L3-out connection
una PBR policy è sempre applicata a livello Leaf node dove l’endpoint di destinazione è collegato
PBR sempre re-dirige il traffico al cluster Firewall locale
Mandatorio l’uso di Leaf node modello EX – FX

Traffico East-West InterSite

una comunicazione tra differenti EPG group può essere espanso attraverso le due Fabric
il node Leaf Consumer applica una policy PBR per re-dirigere il traffico al proprio FW locale
il node Leaf Provider non deve applicare policy PBR per assicurare il corretto traffico InterSite

Quando un service-graph è configurato il concetto di funzione è usato per specificare come il traffico deve fluire tra EPG Provider e EPG Consumer cosi come quali devices sono coinvolti nel path di comunicazione; queste funzioni possono essere definite come firewall, load-balancer, SSL offload, etc, ed APIC traduce queste operazioni dentro elementi di un service graph per mezzo di una tecnica chiamata rendering.

La tecnica di rendering, quindi, alloca le risorse di rete come un bridge-domain, vlans ed IP address per assicurare che gli EPG Provider e Consumer hanno le necessarie configurazioni per essere funzionali.

graph 1

Quando il graph è definito attraverso APIC, questi automaticamente configura il servizio specifico in accordo alle funzioni indicate nel services graph e configura sempre in modo automatico i parametri di rete necessari.

graph 2

Un service graph inoltre provvede ad ulteriori informazioni quali:

allocazione automatica di vlans che debbono essere impiegate e configura queste negli L4-L7 devices coinvolti;

health score reporting: provvede a fornire informazioni riguardo lo stato di salute dei devices e delle loro funzioni;

dynamic endpoint attach: è possibile aggiungere endpoint facenti parte di un determinato EPG per ACL oppure load-balancing rules (dipende dal vendor);

traffic redirect: è possibile redirigere specifiche ports (ad esempio SSH) verso un determinato devices L4-L7

Cisco ACI offre tre modalità di configurare un service graph:

Network Policy Mode (unmanaged): ACI configura la sola parte di rete del service graph e non applica (push) nessuna configurazione L4-L7; quest’ultime sono di competenza dell’amministratore devices L4 – L7:
- questo modello non richiede un device package;
- l’amministratore di rete configura le porte e le vlan collegate ai firewall/balancer;
- l’amministratore firewall/balancer configura le porte/vlan e si occupa di gestire le policies ACL ed altro necessario attraverso un tool di management terze part L4-L7 devices.

Service Policy Mode (manager):

questo modello richiede un device package;
l’amministratore di rete necessita di applicare le configurazioni di rete e di sicurezza L4-L7 attraverso APIC per mezzo di una “function profile”;

APIC programma le configurazioni sia per la Fabric ACI che per il device L4-L7;
l’amministratore L4-L7 può leggere le configurazioni applicate dal suo tool di management terze parti ma non può fare nessun change direttamente.

Service Manager Mode:

Questo modello richiede un device package;
l’amministratore L4-L7 definisce le configurazioni dal suo tool di management terze parti
l’amministratore di rete configura il service graph e referenzia le policies L4-L7 definite sopra

Gli appliance L4 – L7 devices che possono essere integrati sono Firewall, Balancer ed IDS/IPS, ognuno dei quali può essere rilasciato in multipli contesti; ACI ne supporta il rilascio con service graph configurati con differenti modelli di configurazione: go-to (routed mode), go-to with service graph redirect, go-through trasparent mode, one-arm mode.

I devices L4 – L7 che supportano routed mode integrati con ACI si basano su queste configurazioni:

Routed mode with L3out and NAT
Routed mode in which the L3out interface perform layer 3 peering with L4-7 devices
Routed mode with policy-based redirect (PBR) to the L4-7 devices

Di seguito si riportano in modo esemplificativo alcuni modelli di rilascio dei Firewall all’interno della Fabric di competenza

Go-To: il Firewall è un Layer 3 device che ruota il traffico e può essere usato come default gateway per i servers oppure come next-hop; ACI Fabric lavora solo a livello 2 forwarding

graph 3

Ogni EPG group è associato ad uno specifico bridge domain che ha solo funzionalità layer 2; entrambi i bridge-domain sono associati ad una VRF ma questa associazione è configurata solo per soddisfare i requisiti di object model (non ha un significato operativo);
Il Firewall provvede a fornire i default gateway ai rispettivi EPG group sulle sue interfacce external and internal;
Un contract è impiegato (policy) per permettere la comunicazione tra i due differenti EPG group e relativi servizi;
Unicast routing è settato with “NO” per non permettere nessuna adiacenza tra il Firewall e la Fabric ACI (la Fabric opera in questo caso solo a livello 2)

Go-To with L3 peering ACI Fabric : questo modello è impiegato quando abbiamo necessità di mettere in comunicazione EPG di tipo client che sono esterni alla Fabric ACI e quindi collegati attraverso l’opzione L3out e con EPG sempre di tipo client all’interno della Fabric ed EPG di tipo provider

graph 4

Ogni interface del FW è associata ad uno specifico bridge domain di cui uno con sole funzionalità layer 2 per i server EPG di tipo provider con la internal-IF del firewall configurata come loro default gateway e l’altro bridge domain, associato alla external-IF del firewall, configurato con funzionalità L3-mode.
La Fabric ACI provvede ad un L3out configuration in relazione alla external-IF del Firewall con un protocollo di routing (dinamico o statico) attraverso il quale la Fabric conosce le subnets che esistono dietro il firewall; un contract (policy) deve esistere per mettere in comunicazione i differenti EPG groups
Gli EPG di tipo client all’interno della Fabric possono essere collegati a livello 3 ed un contract (policy) deve esistere per mettere in comunicazione questi con gli EPG di tipo EXT alla Fabric stessa
Questo modello prevede l’uso di una stessa VRF per scopi di object model
Il collegamento L3-out external configurato è equivalente agli EPG EXT pertanto è necessario utilizzare questa connessione a livello di services graph

Go-To with PBR : questo modello è impiegato con l’uso di policy-based redirect (PBR); viceversa dal modello precedente non abbiamo bisogno di un L3out per il collegamento con il Firewall e la Fabric ACI può ruotare il traffico verso questo sulla base della rete sorgente EPG, la rete di destinazione EPG ed un relativo contract tra essi.

graph 5

Differenti bridge domain sono necessari configurare per necessità di routing;

Il default gateway dei servers e del Firewall deve essere la Fabric ACI;

Il PBR ha due interfacce di cui una configurata per EPG provider (internal) ed una configurata per EPG client (external) associati a bridge domain specifici differenti da quelli definiti per i rispettivi EPG groups: unicast routing deve essere settato;

Il PBR richiede un service graph e deve essere configurato in go-to mode; il PBR può essere usato anche in “one-arm mode”

Go Throught: il firewall è un Layer 2 devices (transparent mode); la Fabric ACI non prevede nessuna configurazione layer 3 per entrambi i bridge domain, ed anche se configuriamo un hardware proxy, ACI funziona da “ ponte” settando i bridge domain per unknow unicast flooding ed ARP flooding

Questa modalità prevede due differenti funzionalita e precisamente:

Transparent mode with outside Layer 2 bridge domain: questo modello richiede due bridge domain ed il default gateway dei server è l’external router devices;

graph 6

Transparent mode with L3-out: il Firewall è sempre un Layer 2 devices (transparent mode) ed in questo caso il service graph si connette ad un external network domain attraverso un protocollo di routing messo a disposizione dalla Fabric ACI

Poichè IP routing è abilitato nel bridge domain Y (outside), gli IP address degli endpoint appartenenti al BD X sono imparati come se questi fossero nel BD Y ed associati al MAC address del devices L4-7; inoltre è necessario configurare il “ limit IP learning to subnet or subnet check “ e verificare che non più di 1024 IP address siano imparati da quella interfaccia

graph 7

L3 Firewall Manual Stiching: in questo modello possiamo agire attraverso una manuale inserzione di un Firewall Layer 3 dove vengono configurate due separate VRF e Bridge Domain con due separati L3-out connection.

Gli L3-out connection sono utilizzati per creare delle adiacenze tra il Firewall e la Fabric ACI; il Firewall fungerà da router tra le VRF, mentre la Fabric ACI trasmette traffico verso il Firewall attraverso un protocollo di routing statico o dinamico.

Il traffico attraverso opportuni contract (policy) è permesso tra EPG Consumer e l’interfaccia outside del Firewall ed è permesso quello tra EPG Provider e l’interfaccia inside del Firewall

MULTISITE ACI SCENARIO

Multi-Site ACI presenta essenzialmente tre principalu use-case, di cui:

L3 connectivity tra sites con la gestione e configurazione di policies attraverso un sistema centrale (MSO/NDO);

Disaster Recovery active-standby data-center con IP mobility cold VM migration

Business Continuity active-active data center con hot VM migration

Queste opzioni sono di seguito illustrate nei loro specifici design e caratteristiche.

L3 connectivity between sites:

Streching di EPG tra i due sites A-B, di fatto definendo un unico endpoint group espanso in modo geografico e questo use-case permette una comunicazione layer 3 tra i due sites:

streched l3conn

Poiché la VRF è streched tra i due site, vi è anche la possibilità di definire EPG localmente alla Fabric di pertinenza con i rispettivi (e differenti) BD e Subnets; opportuni contratti sono poi configurati per permettere la comunicazione tra EPGs.

Le singole subnets/prefix sono regolarmente ruotate all’interno della stessa fabric come pure tra le i due sites.

Abbiamo solo un layer 2 broadcast domain locale per site; nessuno streching layer 2.

Cold VM migration è permessa, senza però la capacità di preservare l’indirizzo IP dell’end-point migrato.

L’utilizzo di service-graph in questo scenario non è consentito per il pushing di applicazioni condivise tra sites

STRECHED BRIDGE DOMAIN with No BUM traffic Flooding intersite

Questo scenario si sposa bene con il concetto di MultiSite active-passive (DR) dove un tenant, VRF ed i loro EPG/BD/subnets sono streched tra i due sites.

In questo caso comunque il traffico BUM (broadcast, unknow e multicast) non è permesso tra i due sites attraverso tunnel VXLAN

streched no bum 2

Lo use-case quindi prevede:

Un piano di controllo con un overhead ridotto poiché il dominio layer 2 è solo intrasite.

La possibilità di IP mobility per motivi di DR (disaster recovery planning).

Cold VM migraton permessa.

L’utilizzo di service-graph in questo scenario non è consentito per il pushing di applicazioni condivise tra i sites

STRECHED BRIDGE DOMAIN with layer 2 broadcast extension

Questo scenario si sposa bene con il concetto di MultiSite active-active (HA) dove un tenant, VRF ed i loro EPG/BD/subnets sono streched tra i due sites.

Viceversa dal precedente use-case, in questo il layer 2 broadcast domain viene esteso intersite ed il traffico BUM transita tra i due site facendo leva alla funzionalità di Head-End Replication (HER) presente tra i nodi Spine delle due Fabric ACI.

streched with l2 traffic

Lo use-case quindi prevede:

La stessa applicazione è in modo gerarchico rilasciata in entrambi i sites con policies comuni

Layer 2 clustering.

Live VM migraton permessa.

Active-Active high availability tra i due sites (Business Continuity)

L’utilizzo di service-graph in questo scenario non è consentito per il pushing di applicazioni condivise tra i sites