🥇 VxLAN factory. Parte 3

Ciao, Habr. Sto concludendo il ciclo di articoli, dedicati al lancio del corso "Ingegnere di rete" da OTUS, sulla tecnologia VxLAN EVPN per il routing all'interno del data center e sull'uso del Firewall per limitare l'accesso tra i servizi interni

Le parti precedenti del ciclo possono essere trovate ai seguenti link:

Oggi continueremo a studiare la logica di routing all'interno del data center VxLAN. Nella parte precedente abbiamo esaminato il routing all'interno del data center nell'ambito di un singolo VRF. Tuttavia, nella rete possono esserci numerosi servizi-clienti e tutti devono essere distribuiti in diversi VRF, per limitare l'accesso tra di loro. Inoltre, l'azienda potrebbe avere la necessità di collegare un Firewall per limitare l'accesso tra questi servizi. Sì, non possiamo considerarlo la soluzione migliore, tuttavia le moderne realtà richiedono "soluzioni moderne".

Consideriamo due opzioni di routing tra VRF:

Routing, senza uscire dal data center VxLAN;
Routing su hardware esterno.

Iniziamo con la logica di routing tra VRF. Esiste un numero definito di VRF. Per effettuare il routing tra VRF, è necessario designare un dispositivo nella rete che conosca tutti i VRF (o parte di essi, tra cui è necessario il routing). Questo dispositivo può, ad esempio, essere uno degli switch Leaf (o tutti contemporaneamente). Questa topologia apparirà nel seguente modo:

Quali sono gli svantaggi di tale topologia?

Esatto, ogni Leaf deve conoscere tutti i VRF (e tutte le informazioni in essi) nella rete, il che porta a una perdita di memoria e un aumento del carico sulla rete. Infatti, molto spesso ogni switch Leaf non ha bisogno conoscere tutto ciò che esiste nella rete.

Tuttavia, esaminiamo questo approccio più nel dettaglio, poiché per reti piccole può essere una soluzione adeguata (se non ci sono particolari requisiti aziendali).

A questo punto potresti avere una domanda su come trasmettere informazioni da un VRF a un altro, poiché il senso di questa tecnologia è proprio che la diffusione delle informazioni dovrebbe essere limitata.

E la risposta risiede in funzioni come export e import delle informazioni di routing (la configurazione di questa tecnologia è stata trattata nella secondo parte del ciclo). In breve, ripeterò:

Quando si definisce un VRF in AF, è necessario specificare route-target per importare ed esportare informazioni di percorso. Può essere specificato in modalità automatica. In tal caso, il valore sarà ASN BGP e L3 VNI, associato a VRF. Questo è conveniente quando in fabbrica viene utilizzato solo un ASN:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! In modalità automatica viene esportato RT-65001:99000
    route-target import auto

Tuttavia, se avete più di un ASN e avete bisogno di trasmettere percorsi tra di essi, un'opzione più comoda e scalabile sarebbe la configurazione manuale. route-target. La raccomandazione per la configurazione manuale è di utilizzare un primo numero a voi conveniente, per esempio, 9999.
Il secondo dovrebbe essere uguale al VNI per questo VRF.

Impostiamo nel seguente modo:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Esempio 1 import da un altro VRF
    route-target import 9999:88000         ! Esempio 2 import da un altro VRF

Come appare nella tabella di routing:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, interno, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefisso disponibile tramite L3VNI 99000

Esaminiamo la seconda opzione di routing tra VRF — tramite apparecchiature esterne, come un Firewall.

Si possono ipotizzare diverse modalità di funzionamento tramite un dispositivo esterno:

Il dispositivo sa cos'è VxLAN e possiamo aggiungerlo a una parte della fabbrica;
Il dispositivo non sa nulla di VxLAN.

Non ci soffermeremo sulla prima opzione, poiché la logica sarà praticamente la stessa di quanto mostrato sopra — portiamo tutti i VRF al Firewall e impostiamo il routing tra VRF su di esso.

Esaminiamo la seconda opzione, quando il nostro Firewall non sa nulla di VxLAN (attualmente, naturalmente, ci sono apparecchiature con supporto VxLAN. Ad esempio, Checkpoint ha annunciato il suo supporto nella versione R81. È possibile leggere a riguardo qui, ma è tutto in fase di test e non ci sono certezze sulla stabilità di funzionamento).

Collegando un dispositivo esterno otteniamo il seguente schema:

Come si può vedere dallo schema — appare un collo di bottiglia all'interfaccia con il Firewall. È necessario tenerne conto in seguito nella pianificazione della rete e nell'ottimizzazione del traffico di rete.

Tuttavia, torniamo all'obiettivo iniziale del routing tra VRF. A seguito dell'aggiunta del Firewall, ci rendiamo conto che il Firewall deve conoscere tutti i VRF. Per questo, sui Leaf di confine devono essere configurati anche tutti i VRF, e il Firewall viene collegato a ogni VRF tramite un collegamento separato.

Di conseguenza, lo schema con il Firewall:

Cioè, è necessario configurare un'interfaccia su ogni VRF presente nella rete sul Firewall. In generale, la logica non appare complicata, e l'unica cosa che potrebbe non piacere è l'enorme numero di interfacce sul Firewall; ma è tempo di pensare all'automazione.

Va bene. Abbiamo collegato il Firewall, aggiunto a tutti i VRF. Ma come possiamo ora fare in modo che il traffico di ogni Leaf passi attraverso questo Firewall?

Non ci saranno problemi sul Leaf collegato al Firewall, poiché tutte le rotte sono locali:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! rotta predefinita attraverso il Firewall

Tuttavia, come gestire i Leaf remoti? Come trasmettere loro la rotta esterna predefinita?

Corretto, tramite l'EVPN route-type 5, come qualsiasi altro prefisso nella rete VxLAN. Tuttavia, non è tutto così semplice (se parliamo di Cisco, non ho verificato con altri fornitori)

È necessario annunciare la rotta predefinita dal Leaf a cui è collegato il Firewall. Tuttavia, per trasmettere la rotta, il Leaf deve conoscerla. Qui nasce un certo problema (forse solo io), la rotta deve essere configurata staticamente nel VRF in cui si desidera annunciare tale rotta:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Successivamente, nella configurazione BGP, definire questa rotta nell'AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Tuttavia, non è tutto. In questo modo, la rotta predefinita non entrerà nella famiglia l2vpn evpn. Inoltre, è necessario configurare la ridistribuzione:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Specifichiamo quali prefissi entreranno in BGP tramite ridistribuzione

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Ora il prefisso 0.0.0.0/0 entra nell'EVPN route-type 5 e viene trasmesso agli altri Leaf:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5w6d, bgp-65001, interno, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Indirizzo virtuale Leaf (dato che i Leaf fungono da coppia VPS), a cui è collegato il Firewall

Nella tabella BGP possiamo anche osservare il route-type 5 ricevuto con la rotta predefinita attraverso 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Concludiamo qui il ciclo di articoli dedicati all'EVPN. In futuro cercherò di esaminare il funzionamento di VxLAN in combinazione con il Multicast, poiché questo metodo è considerato più scalabile (attualmente un'affermazione controversa).

Se avete ancora domande/proposte su come esaminare qualche funzionalità dell'EVPN, scrivetemi e ne discuteremo ulteriormente.

Fonte: habr.com