VxLAN factory. Part 3

Ciao, Habr. Sto completando un ciclo di articoli, dedicati al lancio del corso "Ingegnere di rete" di OTUS, sulla tecnologia VxLAN EVPN per la routing all'interno della fabbrica e l'uso del Firewall per limitare l'accesso tra i servizi interni.

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

• 1ª parte del ciclo — connettività L2 tra server
• Parte 2 del ciclo - Routing tra VNI
• Parte 2.5 del ciclo - Digressione teorica

Oggi continueremo a esplorare la logica di routing all'interno della fabbrica VxLAN. Nella parte precedente abbiamo esaminato il routing all'interno della fabbrica nell'ambito di un singolo VRF. Tuttavia, nella rete possono esserci un numero enorme di servizi-clienti e tutti devono essere distribuiti in diversi VRF, per delimitare l'accesso tra di loro. Inoltre, le aziende potrebbero avere la necessità di collegare un Firewall, per limitare l'accesso tra questi servizi. Sì, non si può definire la migliore soluzione, tuttavia le realtà moderne richiedono "soluzioni moderne".

Esaminiamo due opzioni di routing tra VRF:

1. Routing, senza uscire dalla fabbrica VxLAN;
2. Routing su equipaggiamento esterno.

Iniziamo con la logica di instradamento tra VRF. Ci sono un certo numero di VRF. Per instradare tra i VRF, è necessario allocare un dispositivo nella rete che conosca tutti i VRF (o almeno una parte di essi, tra i quali è necessaria l'instradamento). Questo dispositivo può essere, ad esempio, uno degli switch Leaf (o anche tutti contemporaneamente). La topologia apparirà come segue:

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 aumenta il carico sulla rete. Infatti, spesso a ciascun switch Leaf non è necessario conoscere tutto ciò che esiste nella rete.

Tuttavia, esaminiamo questo approccio più in dettaglio, poiché per reti di piccole dimensioni questa opzione è più che adeguata (se non ci sono requisiti specifici dell'azienda).

A questo punto, potresti chiederti come trasferire informazioni da un VRF all'altro, dato che il senso di questa tecnologia è proprio che la diffusione delle informazioni deve essere limitata.

E la risposta risiede in funzioni come export e import delle informazioni di instradamento (abbiamo esaminato la configurazione di questa tecnologia nella il secondo parte del ciclo). Ripeto brevemente:

Quando si imposta un VRF in AF, è necessario specificare route-target per importare ed esportare informazioni sul percorso. Può essere specificato in modo automatico. In tal caso, verranno utilizzati l'ASN BGP e il L3 VNI associato al VRF. Questo è conveniente quando si utilizza un solo ASN in fabbrica:

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 si hanno più di un ASN e si devono trasferire percorsi tra di essi, la configurazione manuale sarà più conveniente e scalabile. route-targetLa raccomandazione per la configurazione manuale è di utilizzare un primo numero a scelta, ad esempio, 9999.
Il secondo dovrebbe essere uguale al VNI per questo VRF.

Configuriamo 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 accessibile tramite L3VNI 99000

Consideriamo la seconda opzione di instradamento tra VRF - attraverso attrezzature esterne, come un firewall.

Si possono ipotizzare diverse modalità operative attraverso un dispositivo esterno:

1. Il dispositivo sa cos'è VxLAN e possiamo integrarlo nella parte della fabbrica;
2. 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 configuriamo l'instradamento tra VRF lì.

Analizziamo la seconda opzione, quando il nostro firewall non sa nulla di VxLAN (attualmente, ovviamente, ci sono attrezzature con supporto per VxLAN. Ad esempio, Checkpoint ha annunciato il supporto nella versione R81. Maggiori informazioni possono essere trovate qui, tuttavia, tutto questo è ancora in fase di test e non c'è certezza sulla stabilità del funzionamento).

Collegando un dispositivo esterno otteniamo il seguente schema:

Come si può vedere dallo schema, emerge un collo di bottiglia al punto di connessione con il firewall. È necessario tenerne conto in futuro nella pianificazione della rete e nell'ottimizzazione del traffico di rete.

Tornando quindi all'obiettivo iniziale della gestione della routing tra VRF. Con l'aggiunta del Firewall, diventa necessario che il Firewall sia a conoscenza di tutti i VRF. Per fare ciò, è fondamentale che tutti i VRF siano configurati anche sui Leaf di confine e il Firewall deve essere collegato a ciascun VRF con un link dedicato.

Di conseguenza, lo schema con il Firewall è il seguente:

Quindi, è necessario configurare un'interfaccia del Firewall in ciascun VRF presente nella rete. In generale, la logica non risulta complicata; l'unico aspetto che potrebbe generare preoccupazione è l'enorme numero di interfacce sul Firewall, ma qui è giunto il momento di considerare l'automazione.

Bene. Abbiamo collegato il Firewall e l'abbiamo aggiunto a tutti i VRF. Ma come possiamo far sì che il traffico di ciascun Leaf passi attraverso questo Firewall?

Sul Leaf collegato al Firewall, non ci saranno problemi, 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 di default attraverso il Firewall

Ma come gestire i Leaf remoti? Come possiamo fornire loro una rotta esterna predefinita?

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

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

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Successivamente, nella configurazione BGP, impostare questa route in AF IPv4:

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

Tuttavia, non è tutto. In questo modo, la route 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 nel tipo di route EVPN 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, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Indirizzo virtuale Leaf (dato che i Leaf funzionano come coppia VPС), a cui è collegato il Firewall

Nella tabella BGP possiamo anche osservare il route-type 5 con il percorso predefinito 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 a EVPN. In futuro cercherò di esaminare il funzionamento di VxLAN in combinazione con Multicast, poiché questo metodo è considerato più scalabile (al momento è un'affermazione discutibile).

Se avete domande o suggerimenti su come esaminare qualche funzionalità di EVPN, scriveteci e ne discuteremo ulteriormente.

Fonte: habr.com