Come una fabric EVPN sa dove si trova il vostro server

Una rete switchata classica trova un server gridando: inonda il frame ovunque, vede chi risponde, ricorda la porta. Una fabric BGP EVPN lo trova perché le viene detto. Questa singola differenza spiega perché le fabric EVPN scalano, fanno failover in fretta e possono essere verificate, e vale la pena capirla anche se non ne configurerete mai una.

Il problema del flood and learn

Il Layer 2 tradizionale impara gli indirizzi MAC dal traffico. Quando uno switch non sa dove vive una destinazione, inonda il frame su ogni porta della VLAN. Lo spanning tree blocca poi abbastanza link da impedire che il flood giri in loop per sempre, il che significa che una buona parte del cablaggio che avete pagato resta inattiva. Estendete quella VLAN su molti rack e ottenete grandi domini di guasto, convergenza lenta e una rete che nessuno riesce a descrivere del tutto, perché il suo stato vive in tabelle che si riempiono e scadono da sole.

VXLAN da solo risolve il problema del trasporto: incapsula i frame Ethernet in UDP così che un segmento Layer 2 possa attraversare un underlay instradato con tutti i link attivi. Ma il VXLAN puro inonda ancora per imparare. EVPN sostituisce quell'apprendimento con un control plane.

Cosa annuncia davvero EVPN

EVPN è una address family di BGP. Ogni switch leaf che ospita server agisce da VXLAN tunnel endpoint (VTEP) e dice agli altri leaf ciò che sa, usando un piccolo numero di route type. Tre di essi fanno la maggior parte del lavoro:

• Type 2, MAC and IP advertisement. Quando un server invia il suo primo frame o ARP, il leaf locale impara il suo MAC (e di solito il suo IP) e lo annuncia a ogni altro leaf con il proprio indirizzo VTEP come next hop. Ogni leaf ora sa dove si trova quel server senza un singolo flood.
• Type 3, inclusive multicast. Ogni leaf annuncia a quali segmenti partecipa. Questo costruisce la lista dei VTEP che devono ricevere il traffico broadcast e unknown per ogni segmento. Con l'ingress replication il leaf mittente crea una copia unicast per ciascuno di essi, così l'underlay non ha bisogno di alcun multicast.
• Type 5, IP prefix. Le subnet instradate, per esempio un blocco di indirizzi pubblici dietro il firewall di un cliente, vengono annunciate come prefissi dentro una VRF del tenant.

I route target decidono chi importa cosa. Le route di un segmento portano il suo route target, e solo i leaf configurati con quel target le importano. È qui che l'isolamento dei tenant viene effettivamente imposto, ed è per questo che la numerazione di segmenti e route target merita una vera disciplina (più avanti ne parliamo).

Anycast gateway: lo stesso router ovunque

In una fabric EVPN ogni leaf che porta un segmento può esserne il default gateway, usando lo stesso IP e lo stesso MAC virtuale. Il primo hop di un server è sempre lo switch a cui è collegato. Se quel leaf si guasta, il bond del server fa failover sull'altro leaf della coppia, che risponde già sullo stesso indirizzo di gateway e sullo stesso MAC. Nulla cambia sul server, nessun protocollo di gateway deve eleggere nessuno, e i workload possono spostarsi tra rack mantenendo il loro gateway.

Combinato con coppie di leaf che eseguono virtual port-channel, questo dà a ogni host due switch fisici dietro un unico bond logico. Su NX-OS un anycast gateway minimo appare così:

fabric forwarding anycast-gateway-mac 0000.2222.3333
interface Vlan210
  vrf member TENANT-A
  ip address 192.0.2.1/26
  fabric forwarding mode anycast-gateway

Rintracciare un host: i comandi che contano

Quando qualcosa non arriva dove dovrebbe, questi sono i comandi da cui partiamo su Cisco Nexus, all'incirca in quest'ordine:

show nve peers                         ! are the other VTEPs up?
show nve vni                           ! is the segment up, control plane learning?
show l2route evpn mac all              ! which MACs are local, which are remote, and from which peer
show bgp l2vpn evpn <mac-or-ip>        ! the actual route, its RD, RT and next hop
show ip arp suppression-cache detail   ! is ARP being answered locally?
show vpc consistency-parameters vlans  ! do both leaves of the pair agree?

La storia che raccontano è di solito breve. Un MAC che è locale su un leaf ma non compare mai in BGP sugli altri punta all'apprendimento locale o alla configurazione del segmento. Una route presente ma non importata punta ai route target. Un VTEP assente da show nve peers punta all'underlay. Leggere lo stato della fabric in questo modo è possibile solo perché EVPN tiene quello stato in BGP, dove è visibile e coerente, invece che in tabelle apprese dal flood.

La numerazione è un controllo di sicurezza

Ogni segmento ha bisogno di un VXLAN network identifier (VNI) e di route target, e la fabric accetterà qualunque numero digitiate. Due segmenti che condividono per errore un identificatore vengono messi in bridge insieme, in silenzio, e un VNI digitato male che per caso appartiene a un altro segmento appare perfettamente legittimo su ogni schermo.

La difesa è una regola e una macchina che la controlla. Scegliete una derivazione fissa, per esempio VNI uguale a un offset fisso più il numero di VLAN locale, con i route target derivati dal VNI, e poi verificatela automaticamente:

• Leggete la mappa VLAN verso VNI da ogni leaf con regolarità.
• Confermate che ogni voce rispetta la regola.
• Confermate che ogni leaf che dovrebbe portare gli stessi segmenti porta mappe identiche.
• Confrontate un fingerprint dell'intera mappa con una baseline firmata nel controllo di versione, così una modifica voluta richiede una nuova firma deliberata con un autore, e una non voluta avvisa un ingegnere.

Eseguiamo esattamente questo controllo sulla nostra fabric ogni ora. Costa pochi secondi di accesso in sola lettura e trasforma una classe di errori invisibili in un allarme.

Cosa chiedere della vostra fabric

• I vostri gateway sono anycast su ogni leaf, o una sola coppia di switch li possiede?
• Ogni host è dual-homed su una coppia di leaf, o solo quelli costosi?
• Gli host in bond fanno l'hash su layer 3 e layer 4, con il lato switch allineato, così entrambi i link portano davvero traffico?
• Esiste una regola scritta per la numerazione di VNI e route target, e qualcosa la impone?
• Un ingegnere può mostrarvi, con comandi come quelli qui sopra, esattamente dove vive il vostro server e come il suo traffico lascia il rack?

Se volete i vostri server su una fabric costruita e controllata in questo modo, o volete aiuto per leggere la vostra, siamo lieti di aiutarvi.

cta: Parla con un ingegnere

Related

• /what-we-do/network/datacenter-fabric/
• /what-we-do/network/change-discipline/
• /what-we-do/network/layer-2-extension/