Politica del firewall in EVPN: gateway centralizzato o IRB distribuito

Due progetti EVPN collocano il gateway del tenant in punti diversi, e il firewall vede traffico diverso in ciascuno. Con un gateway centralizzato, il traffico tra sottoreti raggiunge il firewall perché è lì che avviene l'instradamento. Con l'IRB distribuito, gli switch leaf instradano localmente e il firewall non vede nulla se non lo inserite deliberatamente. Nessuno dei due modelli è sbagliato. Ciò che è sbagliato è collegare un firewall al bordo e presumere che il fabric gli consegni il traffico.

Due modelli, due punti di ispezione diversi

Nominate prima i flussi che richiedono ispezione, perché i due modelli li trattano diversamente.

Il traffico all'interno della stessa sottorete è la riga che si dimentica. Due host su una VLAN comunicano tramite bridging, e su quel percorso non c'è alcun firewall instradato, a meno che un progetto di ispezione di livello 2 separato non lo intercetti. Questo vale in entrambi i modelli, quindi è una lacuna di progettazione e non un confronto tra loro.

Le altre tre righe sono dove i modelli divergono davvero.

Gateway centralizzato: ispezione semplice, costo di transito reale

Mantenete le VLAN del tenant come servizi di livello 2 e collocate i loro gateway di instradamento sul firewall. Il traffico tra sottoreti viaggia quindi verso quel gateway e ritorna, possibilmente anche quando entrambi gli host sono sullo stesso leaf. Il punto di ispezione è inequivocabile, ed è tutto l'argomento a favore del progetto. Il costo è il carico di transito sul firewall più una dipendenza centrale da capacità e disponibilità che ora dovete progettare.

Limitate la modifica ai gateway dei tenant che intendete. Rimuovere ogni indirizzo VLAN è troppo ampio quando gestione, underlay e interfacce della piattaforma hanno compiti separati. Controllate anche un secondo gateway attivo, perché uno che instrada ancora attorno al firewall annulla silenziosamente il progetto.

Questo modello è più facile da spiegare a un revisore. Non è automaticamente più economico da gestire.

IRB distribuito: percorso veloce, nessuna ispezione per impostazione predefinita

Con gateway anycast distribuiti, ogni leaf instrada localmente il traffico del tenant, e RFC 9135 spiega perché questo evita il ritorno attraverso un gateway centralizzato. Il vantaggio è reale e ha una conseguenza diretta: l'ispezione non può essere dedotta da dove è collegato il firewall. Un firewall collegato a un leaf di bordo vede il traffico esterno e tutto ciò che gli redirigete esplicitamente.

Inserite il servizio con un meccanismo che la piattaforma supporta davvero: reindirizzamento basato su policy, un nodo di servizio o instradamento controllato tra VRF attraverso il firewall. Fate corrispondere il traffico previsto al suo punto di ingresso reale. Una policy scritta su un'interfaccia rivolta agli host non copre un pacchetto che arriva dall'overlay.

Leggete le rotte installate e non la rotta predefinita prevista. Un prefisso del tenant più specifico importato direttamente può aggirare la rotta predefinita che punta al firewall, e nulla nella configurazione sembrerà sbagliato.

La simmetria è una proprietà dell'instradamento, non una garanzia di ispezione

L'IRB simmetrico descrive come i nodi provider edge di ingresso e uscita gestiscono instradamento e bridging per un flusso. Non dice nulla sul fatto che entrambe le direzioni raggiungano lo stesso dispositivo stateful. ECMP, anycast e l'alta disponibilità del firewall influenzano quale nodo vede il traffico di ritorno, e il modello di stato supportato dal cluster decide se ciò è accettabile.

Seguite esplicitamente il percorso di ritorno per ogni flusso che vi interessa. NAT non è un sostituto universale di quel lavoro, e i progetti che vi si appoggiano di solito trovano la lacuna durante un failover e non durante la costruzione.

Percorrete un flusso obbligatorio e un flusso deliberatamente escluso, in entrambe le direzioni, prima di approvare il progetto.

Come scegliere, e cosa testare in entrambi i casi

Scegliete il gateway centralizzato quando la copertura dell'ispezione conta più della capacità di transito e potete permettervi la dipendenza centrale. Scegliete l'IRB distribuito quando l'instradamento locale è il punto, e mettete a budget l'inserimento esplicito del servizio invece di darlo per scontato.

Poi testate l'instradamento che avete effettivamente installato, perché è lì che i due progetti differiscono di più:

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Includete nel test il guasto e il ripristino del nodo di servizio. Una rotta di riserva che aggira silenziosamente l'ispezione è una decisione diversa da una policy fail-open pianificata, e di solito se ne intende solo una. Il progetto finito nomina dove instrada ogni classe di traffico, dove viene ispezionata e cosa accade quando quel percorso di ispezione non è disponibile.