Salve, e iniziamo con un po' di poesia. A volte invidio i colleghi che lavorano da remoto — è fantastico poter lavorare da qualsiasi angolo del mondo connesso a Internet, prendersi una pausa quando si vuole, con responsabilità per i progetti e le scadenze, piuttosto che stare 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, occasionalmente si presentano casi interessanti, come quello descritto di seguito — e mi rendo conto che ci sono poche posizioni che offrono così tanta libertà per esprimere il proprio talento da troubleshooter.
Una piccola nota — al momento della scrittura dell'articolo, il caso non è completamente risolto, ma considerando la velocità di risposta dei fornitori, una soluzione completa potrebbe richiedere ancora mesi, e desidero condividere le mie scoperte già ora. Spero che, cari lettori, mi perdonerete questa fretta. Ma basta con le chiacchiere — qual è la situazione con il caso?
Iniziamo con una panoramica: c'è un'azienda (dove lavoro come ingegnere di rete) che ospita soluzioni per clienti in un cloud privato VMWare. La maggior parte delle nuove soluzioni si collega a segmenti VXLAN gestiti da NSX-V — non giudico quanto tempo mi abbia risparmiato questa soluzione, in sintesi — molto. Sono riuscito perfino a formare i colleghi nella configurazione di NSX ESG e piccole soluzioni per i clienti vengono implementate senza il mio intervento. Nota importante — il nostro piano di controllo utilizza la replica unicast. Gli ipervisori sono collegati in modo ridondante tramite due interfacce a diversi switch fisici Juniper QFX5100 (assemblati in Virtual Chassis) e seguono la politica di temporizzazione route based on originating virtual port — questo per completezza.
Le soluzioni per i clienti sono molto eterogenee: da Windows IIS, dove tutti i componenti del web server sono installati su una sola macchina, a configurazioni più complesse — ad esempio, front-end web Apache bilanciati con LB MariaDB in Galera + server di condivisione sincronizzati tramite GlusterFS. Praticamente ogni server deve essere monitorato separatamente, e non tutti i componenti hanno indirizzi pubblici — se ti sei trovato ad affrontare questo compito e hai una soluzione più elegantr, sarei felice di ricevere consigli.
La mia soluzione per il monitoraggio consiste nel «collegare» il firewall (Fortigate) a ciascuna rete interna dei clienti (+SNAT e, naturalmente, rigide limitazioni sul tipo di traffico consentito) e nel monitorare gli indirizzi interni — in questo modo si ottiene una certa uniformità e semplificazione del monitoraggio. Il monitoraggio avviene da un cluster di server PRTG. Lo schema di monitoraggio è più o meno il seguente:
Finora, quando operavamo solo con VLAN, tutto andava piuttosto bene e funzionava come un orologio. Dopo l'implementazione di NSX-V e VXLAN, ci siamo trovati di fronte a una domanda: posso continuare a monitorare come prima? Al momento di questa domanda, la soluzione "più veloce" era implementare NSX ESG e collegare l'interfaccia trunk VXLAN nella rete VTEP. "Veloce" tra virgolette, poiché usare l'interfaccia grafica per configurare reti client, SNAT e regole del firewall può semplificare la gestione all'interno di un'unica interfaccia vSphere, ma a mio avviso è piuttosto ingombrante e, tra l'altro, limita l'insieme di strumenti per il troubleshooting. Chi ha usato NSX ESG come sostituto di un "vero" firewall, probabilmente sarà d'accordo. Anche se, forse, tale soluzione sarebbe stata più stabile — poiché tutto avviene all'interno di un unico fornitore.
Un'altra soluzione consiste nell'utilizzare NSX DLR in modalità bridge tra VLAN e VXLAN. Qui credo sia tutto chiaro: si perde la convenienza dell'utilizzo di VXLAN, dato che in questo caso è comunque necessario portare la VLAN all'installazione di monitoraggio. A proposito, nel corso dell'implementazione di questa soluzione, mi sono imbattuto in un problema in cui il bridge DLR non inviava pacchetti alla macchina virtuale con cui si trovava sulla stessa host. So, so — nei libri e nelle guide su NSX-V si afferma chiaramente che per NSX Edge deve essere dedicato un cluster separato, ma questo è scritto nei libri... In ogni caso, dopo un paio di mesi con il supporto, non siamo riusciti a risolvere il problema. Fondamentalmente, ho compreso la logica: il modulo del kernel dell'iperamano responsabile dell'incapsulamento VXLAN non veniva attivato se DLR e il server monitorato si trovavano sulla stessa 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 funge anche da bridge/incapsulamento — lì è stata notata una discrepanza nel traffico in ingresso, che ho assunto per la lavorazione nel caso attuale. Ma come già detto, non ho portato a termine questo caso, poiché sono stato trasferito a un altro progetto e questa diramazione era inizialmente senza uscita e non avevo particolare voglia di svilupparla. Se non erro, il problema si è manifestato nelle versioni NSX 6.1.4 e 6.2.
E qui — bingo! Fortinet annuncia il supporto nativo per . E non semplicemente point-to-point o VXLAN-over-IPSec, né bridging software VLAN-VXLAN — tutto ciò è stato introdotto già dalla versione 5.4 (ed è presente anche in altri ), ma un reale supporto per il piano di controllo unicast. Durante l'implementazione della soluzione, ho incontrato un altro problema: i server monitorati sparivano e riapparivano, anche se la macchina virtuale era attiva. La causa, come si è scoperto, era che avevo dimenticato di abilitare il Ping sull'interfaccia VXLAN. Nel processo di bilanciamento del cluster, le macchine virtuali venivano spostate, e il vMotion veniva completato tramite Ping per segnalare il nuovo host ESXI su cui la macchina era stata trasferita. È stata una mia svista, ma questo problema ha ulteriormente minato la fiducia nel supporto del produttore — in questo caso Fortinet. Non parlo nemmeno del fatto che ogni caso legato a VXLAN inizia con la domanda «dove avete nelle impostazioni il software switch VLAN-VXLAN?» Questa volta mi è stato consigliato di modificare l'MTU — per il Ping, che è di 32 byte. Poi «gioca» con tcp-send-mss e tcp-receive-mss nelle politiche — per VXLAN, che è incapsulato in UDP. Uff, scusate — mi sono sfogato. Comunque questa problematica l'ho risolta da solo.
Dopo aver testato con successo il traffico, è stato deciso di implementare questa soluzione. In produzione, però, dopo uno o due giorni, tutto ciò che veniva monitorato tramite VXLAN ha cominciato a disconnettersi gradualmente. Disattivare e riattivare l'interfaccia aiutava, ma solo temporaneamente. Conoscendo la lentezza del supporto del fornitore, mi sono occupato del troubleshooting dalla mia parte — dopotutto, la mia azienda, la mia rete — la mia responsabilità.
Sotto il spoiler, il processo di troubleshooting. Chi è stanco di parole e vanti — salti e passi all'analisi posteriore.
Processo di troubleshootingGrazie per aver continuato a leggere — proseguiamo!
Il monitoraggio funziona per un certo periodo, poi si disconnette da solo. Quindi, probabilmente non ci sono problemi nelle politiche del firewall. Tuttavia, avendo già affrontato il problema dei processi di sistema bloccati nelle versioni 5.6+ di Fortigate, iniziamo con "diagnose debug flow" — ci aspettiamo che il traffico venga autorizzato e parta dall'interfaccia, con niente che arrivi come risposta. Dobbiamo quindi approfondire il problema. Purtroppo, dovremo nascondere gli indirizzi, anche se sono RFC1918, ma spero di fornire al processo una descrizione sufficiente per la comprensione. Il server all'interno di 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 la corretta trasmissione dei pacchetti incapsulati in VXLAN è necessario avere informazioni corrette in diverse tabelle. Per l'overlay si tratta di ARP e OVSDB, mentre per l'underlay è ARP e CAM. Nel caso di Fortigate, VXLAN FDB è OVSDB. Qui inizieremo:
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=y.y.y.47 port=4789 vni=5008 ifindex=7
Qui tutto è piuttosto semplice: l'indirizzo MAC della macchina virtuale deve trovarsi sul VTEP con l'indirizzo u.u.u.47. Controllando il contenuto e le impostazioni del cluster ESXi, confermo che l'indirizzo MAC della macchina virtuale è corretto e che anche l'indirizzo VTEP lo è. Controllo la tabella CAM/ARP sul Fortigate e di nuovo 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 sta passando. Potrebbe essere che il problema non sia sul Fortigate? Ho deliberatamente saltato l'analisi del traffico di commutazione su Juniper: logicamente, è lì che deve avvenire il prossimo passaggio del troubleshooting, ma la mia rete è semplice: c'è solo un VLAN per il VTEP e tutti i componenti sono connessi direttamente. Inoltre, mi ricordo di un caso con un bridge DLR, VDR e traffico scomparso: vado a sniffare sull'host ESXi, nel frattempo creo già un caso per VMware. Di seguito, l'indirizzo MAC "97:6e" appartiene al Fortigate, vmnic1 è l'interfaccia che ha il VTEP con l'indirizzo u.u.u.47 e snifferò 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
Ho visto il progresso: nel sniffing vedo la richiesta ARP e la risposta che arriva. Riporto solo la risposta ARP, ed è tutto corretto. Non l'ho menzionato, ma per tutto questo tempo il server di monitoraggio ha pingato l'indirizzo x.x.x.15: dove si trova il traffico ICMP? Ricordo che ho due uplink. Qui si può discutere e dire che la porta virtuale di origine è la stessa (la mia politica di teaming), quindi per la stessa vNIC dovrebbe essere scelto lo stesso uplink, ma dal momento 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
Ricevo richieste dal FortiGate, ma non ci sono risposte. Quindi il problema non è nel FortiGate. Bene, penso: di nuovo la stessa questione con il traffico che scompare su VDR, di nuovo un paio di mesi a indirizzare il caso nel giusto verso. Dopo un paio di giorni, calmandomi e non volendo rassegnarmi a questo stallo, ho deciso di scavare ancora di più negli sniffing per il supporto, per accelerare il processo. E qui, il mio sguardo ‘casualmente’ cade sull'incapsulamento Ethernet dell'underlay. Il re non è reale e l'indirizzo MAC VTEP non coincide con il suo IP. Ripristino tutto a zero, faccio sniffing, scavo: esatto che non è corretto. Riporterò la tabella ARP accanto, per facilitare il confronto. Presta attenzione al primo incapsulamento Ethernet nell'immagine in alto:
fortigate (root) #get sys arp | grep x.x.x.47
x.x.x.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep x.x.x.42
x.x.x.42 0 00:50:56:6a:78:86 dmz
Quindi, cosa abbiamo alla fine? Dopo la migrazione della macchina virtuale, Fortigate prova a inviare traffico al VTEP dalla corretta VXLAN FDB, ma utilizza un DST MAC errato e il traffico viene prevedibilmente scartato dall'interfaccia del hypervisor che lo riceve. In un caso su quattro, questo MAC apparteneva all'originale hypervisor da cui è iniziata la migrazione della macchina.
Ieri ho ricevuto un'email dal supporto tecnico di Fortinet: è stato aperto un bug 615586 per il mio caso. Non so se rallegrarmi o rattristarmi: da un lato, il problema non riguarda le impostazioni, dall'altro, la correzione arriverà solo con l'aggiornamento del firmware, nella migliore delle ipotesi, il prossimo. Inoltre, la mia autostima è alimentata da un altro bug che ho scoperto il mese scorso, peraltro questa volta nell'HTML5 GUI di vSphere. È proprio un mini dipartimento QA dei fornitori...
Mi permetto di azzardare la seguente ipotesi:
1 — il piano di controllo multicast probabilmente non sarà soggetto al problema descritto, poiché gli indirizzi MAC del VTEP sono derivati dall'indirizzo IP del gruppo a cui è iscritta l'interfaccia.
2 — probabilmente il problema è legato all'overflow delle sessioni sul Network Processor (simile a CEF) — se si fa passare ciascun pacchetto attraverso la CPU, verranno utilizzate tabelle contenenti le informazioni corrette — almeno visivamente. A favore di questa ipotesi c'è il fatto che aiuta a chiudere/aprire l'interfaccia o a attendere un po' di tempo — più di 5 minuti.
3 — cambiare la policy di teaming, ad esempio in explicit failover, o implementare LAG non risolverà il problema, poiché è stato osservato un 'blocco' del MAC dell'ipervisore originale nei pacchetti incapsulati.
In questo contesto posso condividere che recentemente ho scoperto , dove in uno degli articoli si sostiene che i firewall stateful e i metodi di trasmissione dei dati memorizzabili sono degli espedienti. Bene, non ho abbastanza esperienza in IT per affermare ciò, e per di più non concordo subito con tutte le affermazioni degli articoli del blog. Tuttavia, qualcosa mi dice che c'è del vero nelle parole di Ivan.
Grazie per l'attenzione! Sarò felice di rispondere alle domande e di ascoltare critiche costruttive.
Fonte: habr.com
