Guida alla risoluzione dei problemi di rete

Questa guida illustra i passaggi collaborativi necessari per diagnosticare e risolvere i problemi relativi alle prestazioni di rete. È strutturata come un diagramma di flusso con ordine di priorità, che parte dai problemi più semplici e comuni per passare poi ad analisi più complesse.

Prerequisito: esaminare le best practice relative alle applicazioni

Prima di procedere con un’analisi approfondita della rete, è essenziale assicurarsi che l’applicazione sia progettata per garantire prestazioni ottimali. Molti problemi di prestazioni possono essere risolti intervenendo sulla progettazione dell’applicazione, ad esempio in caso di chiamate API ad alta frequenza o trigger inefficienti.

Consulta qui la guida sulla progettazione delle applicazioni.

Se la propria app segue già queste linee guida, procedere con le seguenti fasi di analisi della rete e i passaggi successivi:

Fase 1: Controlli di base

Escludere rapidamente, con il minimo sforzo, eventuali problemi a livello locale, lato client e a livello fisico.

1. Esegui la diagnostica corrente dalla postazione interessata

• Azione: esegui i seguenti comandi SIA verso il servizio di destinazione SIA verso un endpoint pubblico stabile e ad alta larghezza di banda (ad es. google.com o cloudflare.com) a scopo di confronto.
• Ping esteso (50-100 ping o più) per visualizzare la latenza minima/media/massima e la perdita di pacchetti.
• ping 1.1.1.1 (Cloudflare)
• ping 8.8.8.8 (Google)
• pathping (se su Windows)
• Ricerca DNS: nslookup, dig, drill
• Motivo della priorità: si tratta dei dati più veloci da raccogliere. Il test comparativo è fondamentale e indica immediatamente se il problema è specifico del percorso del servizio o se si tratta di un problema generale di connessione a Internet da quella postazione.
• Azione - Utilizzare il "Network Check" di Tulip
  • Opzione 1 - In una finestra del browser, vai su https://{Il tuo Tulip Instance}.tulip.co/networkCheck
  • Opzione 2: da Tulip Player, fare clic sul menu “Strumenti” e selezionare “Network Check”.
  • Esamina i risultati
    • Verifica se tutti i test hanno esito positivo. In caso contrario, acquisisci uno screenshot di questa schermata e premi "Scarica dati diagnostici". Invia lo screenshot e il file diagnostico a support.tulip.co: un rappresentante Tulip sarà in grado di fornirti assistenza.
    • Puoi anche condividere questi file con il tuo team IT interno affinché possa aiutarti a risolvere il problema.

2. Eseguire un’ispezione fisica dell’hardware

• Azione: Esegui un'ispezione fisica approfondita dell'hardware per le stazioni interessate. Verifica la presenza di cavi Ethernet difettosi, schede di rete inserite in modo errato o problemi con la porta fisica dello switch.Motivo di priorità: I problemi a livello fisico sono fondamentali e possono simulare problemi di rete più complessi. Escluderli per primi evita di perdere tempo con diagnosi a livello software.

3. Verificare la configurazione della postazione locale

• Azione: controllare le impostazioni DNS della postazione, le configurazioni del proxy locale (per eventuali reindirizzamenti), il software di sicurezza/firewall locale ed esaminare i log del server DHCP per confermare che la postazione non stia subendo frequenti rinegoziazioni DHCP.
• Motivo della priorità: si tratta di impostazioni specifiche del client che possono causare problemi a un singolo utente senza influire sulla rete in generale. È il passo logico successivo da compiere dopo aver escluso problemi fisici e generali relativi a Internet.

4. Esaminare i log di sistema locali alla ricerca di eventi recenti

• Azione: dalla postazione interessata, controllare i log degli eventi di sistema (ad esempio, Visualizzatore eventi di Windows, Console di macOS o journalctl/dmesg di Linux) alla ricerca di eventuali errori recenti relativi alla rete, avvisi o cambiamenti significativi che coincidano con l’insorgere del problema di prestazioni. Cercare eventi relativi a cambiamenti di stato della scheda di rete, errori di lease DHCP, problemi di risoluzione DNS o avvisi del firewall o del software di sicurezza.
• Motivo della priorità: ciò aiuta a identificare se il problema è un evento nuovo o se è collegato a una recente modifica di configurazione o a un precedente problema di rete localizzato che potrebbe aver lasciato tracce sul computer client.

Fase 2: Analisi correlata dell’infrastruttura

Utilizzare dati specifici sugli eventi per esaminare l’infrastruttura di rete condivisa. Questa fase richiede l’accesso e la collaborazione del reparto IT.

5. Individuare i timestamp ed esaminare i log interni

• Azione: correlare i tempi di rallentamento segnalati dagli utenti con i log interni dei dispositivi di rete. Cercare:
• Elevato jitter di rete
• Perdita di pacchetti o elevati tassi di ritrasmissione
• Esaminare lo schema della rete e fornire i log
• Log di rete relativi al periodo in cui si è verificato il problema (compreso il proxy, se pertinente)
• Eventi di congestione della rete locale o di saturazione della larghezza di banda
• Motivo di priorità: ciò consente di concentrare l’indagine su momenti precisi, rendendola di gran lunga più efficiente rispetto alla ricerca tra giorni di log. Ciò deve essere fatto prima di coinvolgere soggetti esterni.

6. Esaminare le prestazioni del firewall e dei dispositivi di sicurezza

• Azione: durante gli intervalli di tempo in cui si è verificato il problema, esaminare i log del firewall/proxy alla ricerca di connessioni TCP/UDP bloccate e controllare le risorse dei dispositivi (CPU, RAM, connessioni). Inoltre, si prega di confermare che tutti gli indirizzi IP e i domini Tulip richiesti siano attualmente inseriti nella whitelist e non siano soggetti a ispezioni eccessivamente aggressive che potrebbero aumentare la latenza. Prestare attenzione alle metriche specifiche del proxy, quali i limiti di connessione, le sessioni simultanee e la latenza introdotta dall’ispezione approfondita dei pacchetti.
• Motivo della priorità: i dispositivi di sicurezza rappresentano un comune collo di bottiglia. Questa verifica riguarda sia le regole di blocco esplicite sia il degrado delle prestazioni dovuto a hardware sovraccarico o a politiche di ispezione invasive.

7. Esaminare la configurazione della Qualità del Servizio (QoS)

• Azione: se sono state implementate politiche QoS, verificare come viene classificato il traffico da e verso i servizi dell’applicazione. Assicurarsi che non venga accidentalmente declassato in termini di priorità.
• Motivo della priorità: una configurazione errata della QoS è una causa specifica e spesso trascurata dei problemi di prestazioni delle applicazioni, specialmente durante i periodi di elevata attività di rete.

8. Analizzare la larghezza di banda complessiva e i dati SNMP

• Azione: esaminare l’utilizzo di picco della larghezza di banda a livello di sito e controllare i dati SNMP provenienti da router/switch per individuare un elevato utilizzo o errori durante i periodi in cui si è verificato il problema.
• Motivo della priorità: ciò determina se il problema è correlato alla capacità complessiva della rete o alla contesa.

9. Analizzare il percorso di rete dell’ISP

• Azione: contattare il proprio ISP, fornendo i timestamp specifici relativi agli episodi di elevata latenza.
• Dettagli per l’ISP: chiedere loro di verificare la presenza di instradamenti non ottimali, congestione dei punti di peering, perdita di pacchetti o aumento della latenza sui propri segmenti o percorsi di transito, oppure eventuali politiche di rete rilevanti attive in quei momenti specifici.
• Motivo della priorità: ciò coinvolge una parte esterna ed è più efficace quando è possibile fornire dati precisi e timestamp derivanti dall’indagine interna.

Fase 3: Analisi approfondita avanzata

Utilizzare metodi altamente tecnici e che richiedono molte risorse per individuare i problemi più sfuggenti.

10. Analisi approfondita avanzata a livello di pacchetto

• Azione: Eseguire una cattura completa dei pacchetti (pcap) su una macchina interessata durante un evento di rallentamento. La chiave sta nel concentrarsi specificamente sulla correlazione dei timestamp attraverso tutti i livelli di analisi. Analizzare la cattura alla ricerca di manipolazioni dei pacchetti (ad es. modifiche del TTL), errori di protocollo (ritrasmissioni TCP) o messaggi di errore ICMP specifici.
• Motivo della priorità: questa è la fase più complessa. Fornisce la verità oggettiva definitiva, ma è riservata ai casi in cui tutte le altre indagini non siano riuscite a individuare la causa.