Salve, e per prima cosa un po' di lirica. A volte invidio i colleghi che lavorano da remoto — è fantastico poter lavorare da qualsiasi angolo del mondo connesso a Internet, avere vacanze in qualsiasi momento, responsabilità per progetti e scadenze, invece di trovarsi in ufficio dalle 8 alle 17. La mia posizione e le mie responsabilità lavorative escludono praticamente la possibilità di assenze prolungate nel data center. Tuttavia, periodicamente capitano casi interessanti, simili a quello descritto di seguito — e capisco che ci sono poche posizioni in cui c'è così tanta libertà per esprimere la creatività del proprio troubleshooter interiore.
Un piccolo disclaimer: al momento della scrittura dell'articolo, il caso non è ancora completamente risolto, ma considerando la rapidità di risposta dei fornitori, la soluzione completa potrebbe richiedere ancora mesi e voglio condividere le mie scoperte già ora. Spero, cari lettori, che mi perdoniate questa fretta. Ma basta con le chiacchiere: com'è la situazione con il caso?
Prima di tutto, un'introduzione: c'è un'azienda (dove lavoro come ingegnere di rete) che ospita soluzioni client nel cloud privato VMWare. La maggior parte delle nuove soluzioni si connette a segmenti VXLAN gestiti da NSX-V: non valuterò quanto tempo mi ha regalato questa soluzione, per dirla brevemente, tanto. Sono riuscito persino a formare i colleghi sulla configurazione di NSX ESG e piccole soluzioni client vengono implementate senza il mio intervento. Importante notare: il control plane è con replica unicast. Gli hypervisor sono collegati in modo ridondante con due interfacce a diversi switch fisici Juniper QFX5100 (racchiusi in Virtual Chassis) e con la politica di timing route based on originating virtual port: questo per completezza.
Le soluzioni client sono molto eterogenee: da Windows IIS, dove tutti i componenti del server web sono installati su una sola macchina, a soluzioni piuttosto grandi — ad esempio, front-end Apache bilanciati con load balancing + LB MariaDB in Galera + server condivisi, sincronizzati tramite GlusterFS. Praticamente ogni server deve essere monitorato separatamente, e non tutti i componenti hanno indirizzi pubblici: se ti sei trovato di fronte a questa sfida e hai una soluzione più elegante, sarei felice di ricevere consigli.
La mia soluzione di monitoraggio consiste nel «collegare» il firewall (Fortigate) a ogni rete clienti interna (+SNAT e, naturalmente, severe restrizioni sul tipo di traffico consentito) e monitorare gli indirizzi interni: in questo modo si raggiunge una certa unificazione e semplificazione del monitoraggio. Il monitoraggio avviene da un cluster di server PRTG. Lo schema di monitoraggio è all'incirca il seguente:
Finché abbiamo operato solo con VLAN, tutto era piuttosto normale e funzionava come un orologio. Dopo l'implementazione di NSX-V e VXLAN, ci siamo trovati di fronte alla questione: è ancora possibile continuare a monitorare come prima? Al momento di questa domanda, la soluzione più «rapida» era distribuire NSX ESG e collegare l'interfaccia trunk VXLAN nella rete VTEP. Rapida tra virgolette: poiché utilizzare la GUI per configurare le reti clienti, SNAT e le regole del firewall può anche unificare la gestione in un'unica interfaccia vSphere, ma secondo me è piuttosto ingombrante e, tra l'altro, limita l'insieme di strumenti per il troubleshooting. Chi ha utilizzato NSX ESG come sostituto di un «vero» firewall, credo convenirà. Tuttavia, probabilmente, una tale soluzione sarebbe stata più stabile: poiché tutto avviene nell'ambito di un unico fornitore.
Un'altra soluzione è utilizzare NSX DLR in modalità bridge tra VLAN e VXLAN. Qui penso sia tutto chiaro: si perde banalmente il vantaggio dell'applicazione di VXLAN, poiché in questo caso si deve comunque estendere la VLAN all'installazione di monitoraggio. A proposito, durante l'elaborazione di questa soluzione, ho incontrato un problema quando il bridge DLR non inviava pacchetti alla macchina virtuale con cui era sullo stesso host. Lo so, lo so: nei libri e nelle guide su NSX-V si afferma esplicitamente che per NSX Edge deve essere dedicato un cluster separato, ma questo è nei libri... In ogni caso, dopo un paio di mesi con il supporto non siamo riusciti a risolvere il problema. Fondamentalmente ho capito la logica in atto: il modulo del kernel dell'hypervisor, responsabile per l'incapsulamento di VXLAN, non veniva utilizzato se DLR e il server monitorato si trovavano sullo stesso host, poiché il traffico non lascia l'host e logicamente dovrebbe essere connesso al segmento VXLAN: l'incapsulamento non è necessario. Con il supporto ci siamo concentrati sull'interfaccia virtuale vdrPort, che unisce logicamente gli uplink e svolge anche il bridging/incapsulamento: lì è stata notata una discrepanza nel traffico in entrata, che ho preso in carico per l'elaborazione nel caso attuale. Ma come è stato detto, non ho portato a termine questo caso, poiché sono stato trasferito su un altro progetto e la branca inizialmente era senza uscita, quindi non avevo molta voglia di svilupparla. Se non erro, il problema si è verificato nelle versioni NSX 6.1.4 e 6.2.
E qui - bingo! Fortinet annuncia il supporto nativo . E non solo point-to-point o VXLAN-over-IPSec, né bridging software VLAN-VXLAN: tutto questo è stato iniziato a essere implementato già dalla versione 5.4 (ed è presentato anche da altri ), e un vero supporto per il piano di controllo unicast. Durante l'implementazione della soluzione, mi sono imbattuto in un altro problema — i server controllati a volte “scomparivano” e poi riapparivano nel monitoraggio, anche se la macchina virtuale era attiva. Come si è rivelato, la causa era che avevo dimenticato di abilitare Ping sull'interfaccia VXLAN. Durante il processo di bilanciamento dei cluster, le macchine virtuali venivano spostate, e il vMotion terminava con un Ping, per indicare il nuovo host ESXI a cui era stata trasferita la macchina. È stata una mia svista, ma questo problema ha nuovamente minato la fiducia nel supporto del produttore — in questo caso Fortinet. Non parlo nemmeno del fatto che ogni caso relativo a VXLAN inizia con la domanda “dove si trovano nelle vostre impostazioni il softswitch VLAN-VXLAN?” Questa volta mi hanno consigliato di modificare il MTU — questo per il Ping che è di 32 byte. Poi “gioca” con tcp-send-mss e tcp-receive-mss nella policy — per VXLAN, che è incapsulato in UDP. Uff, scusate — mi sono sfogato. Insomma, ho risolto questo problema da solo.
Dopo aver testato con successo il traffico, è stato deciso di implementare questa soluzione. E in produzione si è scoperto che dopo un giorno o due tutto ciò che veniva monitorato tramite VXLAN smetteva gradualmente di funzionare. La disattivazione/riattivazione dell'interfaccia aiutava, ma solo per un breve periodo. Ricordando la lentezza del supporto del produttore, ho iniziato a fare troubleshooting da parte mia — in fin dei conti, la mia azienda, la mia rete — la mia responsabilità.
Sotto spoiler il corso del troubleshooting. Chi è stanco di lettere e vanterie — salti e passi all'analisi finale.
Corso del troubleshootingGrazie per aver continuato a leggere — procediamo!
Quindi, il monitoraggio funziona per un certo periodo, poi smette di funzionare da solo. Questo significa che nelle politiche del firewall probabilmente non ci sono problemi. Tuttavia, poiché ho già affrontato problemi con processi di sistema bloccati in Fortigate versioni 5.6+, iniziamo con «diagnose debug flow» — come previsto il traffico viene autorizzato e parte dall'interfaccia e, come previsto, non arriva nulla in risposta. Quindi continuiamo ad esaminare il stack. Sfortunatamente, dovrò nascondere gli indirizzi, anche se RFC1918, ma spero di fornire al processo una descrizione sufficiente per comprenderlo. Il server all'interno del VXLAN ha l'indirizzo x.x.x.15, l'interfaccia di Fortigate x.x.x.254, tutti gli altri indirizzi appartengono alla rete VTEP.
Per una corretta trasmissione dei pacchetti incapsulati in VXLAN, è necessaria la presenza di informazioni corrette in diverse tabelle. Per l'overlay sono ARP e OVSDB, per l'underlay sono ARP e CAM. Nel caso di Fortigate, VXLAN FDB è OVSDB. Cominciamo da lì:
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=u.u.u.47 port=4789 vni=5008 ifindex=7
Qui tutto è abbastanza semplice: l'indirizzo MAC della macchina virtuale deve trovarsi sul VTEP con indirizzo u.u.u.47. Controllando il contenuto e le impostazioni del cluster ESXI, scopro che l'indirizzo MAC della macchina virtuale è corretto e anche l'indirizzo del VTEP. Controllo la tabella CAM/ARP sul fortigate: anche qui tutto corrisponde alle impostazioni dell'host ESXI:
fortigate (root) #get sys arp | grep u.u.u.47
u.u.u.47 0 00:50:56:65:f6:2c dmz
Le tabelle sono corrette e il traffico esce — forse il problema non è sul fortigate? Ho volutamente saltato l'analisi della commutazione del traffico su Juniper — logicamente, sarebbe dovuto essere il passo successivo nella risoluzione dei problemi, ma la mia rete è semplice — solo un VLAN per VTEP e tutti i componenti collegati direttamente. Inoltre, ricordo un caso con un bridge DLR, VDR e traffico scomparso — vado a sniffare su host ESXI, nel frattempo creo un caso anche con VMWare. Di seguito, il MAC “97:6e” appartiene a fortinet, vmnic1 — è l'interfaccia che ha VTEP con indirizzo u.u.u.47 sniffando in entrambe le direzioni ", dir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Progresso: nello sniffing vedo la richiesta ARP e la risposta in arrivo. Riporto solo la risposta ARP e lì tutto è corretto. Non ho menzionato che per tutto questo tempo il server di monitoraggio sta pingando l'indirizzo x.x.x.15: dove è finito il traffico ICMP? Ricordo che ho due uplink. Qui si potrebbe discutere e dire che la porta virtuale di origine è la stessa (la mia policy di teaming), cioè per la stessa vNIC deve essere selezionato lo stesso uplink, ma visto che sono sull'host, controllare un altro uplink non è un problema:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Riceviamo richieste dal fortigate, ma non ci sono risposte. Quindi il problema non è nel fortigate. Beh, penso, è di nuovo lo stesso problema del traffico che scompare su VDR, di nuovo un paio di mesi per orientare il caso nel modo giusto. Dopo un paio di giorni, raffreddandomi e non volendo accettare la situazione, ho deciso di raccogliere ancora più sniffer per il supporto, per accelerare il processo. E qui il mio sguardo "casualmente" cade sull'incapsulamento Ethernet underlay. Il re non è reale e l'indirizzo MAC del VTEP non corrisponde al suo IP. Ripristino a zero, sniffo, scavo - è vero che non è vero. Riporterò la tabella ARP accanto per facilitare il confronto. Fate attenzione al primo incapsulamento Ethernet nell'immagine sopra:
fortigate (root) #get sys arp | grep u.u.u.47
u.u.u.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep u.u.u.42
u.u.u.42 0 00:50:56:6a:78:86 dmz
Quindi, cosa abbiamo alla fine - dopo la migrazione della macchina virtuale, il fortigate cerca di inviare traffico al VTEP dalla (corretta) VXLAN FDB, ma utilizza un DST MAC errato e il traffico viene naturalmente scartato dall'interfaccia ricevente del hypervisor. In un caso su quattro, questo MAC apparteneva all'originario hypervisor da cui è iniziata la migrazione della macchina.
Ieri ho ricevuto una mail dal supporto Fortinet - hanno aperto il bug 615586 per il mio caso. Non so se essere felice o triste: da un lato, il problema non è nelle impostazioni, dall'altro, la realtà è che la correzione arriverà solo con l'aggiornamento del firmware, al meglio nel prossimo. La mia autostima è alimentata anche da un altro bug, che ho scoperto il mese scorso, anche se in quel caso nell'HTML5 GUI di vSphere. Insomma, sembra un dipartimento QA locale dei fornitori...
Oserei fare la seguente ipotesi:
1 - è probabile che il piano di controllo multicast non sarà soggetto al problema descritto - poiché gli indirizzi MAC del VTEP vengono derivati dall'indirizzo IP del gruppo a cui è iscritto l'interfaccia.
2 - il problema del fortigate potrebbe risiedere nel caricamento delle sessioni sul Network Processor (approssimativamente analogo al CEF) - se si fa passare ogni pacchetto attraverso la CPU, verranno utilizzate tabelle contenenti informazioni corrette - almeno visivamente. A supporto di questa ipotesi, va detto che è utile chiudere/aprire l'interfaccia o aspettare un certo tempo - più di 5 minuti.
3 - modificare la policy di teaming, ad esempio su failover esplicito, o implementare LAG non risolverà il problema, poiché si è riscontrato un "blocco" del MAC dell'originario hypervisor nei pacchetti incapsulati.
In considerazione di ciò, posso condividere che di recente ho scoperto , dove in uno degli articoli si affermava che i firewall stateful e i metodi di trasferimento dati memorizzabili sono dei palliativi. Beh, non sono così esperto in IT da poter affermare una cosa del genere, inoltre non concordo subito con tutte le affermazioni degli articoli del blog. Tuttavia, qualcosa mi dice che c'è un fondo di verità nelle parole di Ivan.
Grazie per l'attenzione! Sarò felice di rispondere alle domande e di ascoltare critiche costruttive.
Fonte: habr.com
