La connettività cloud (IPsec verso un cloud provider, SD-WAN overlay, Direct Connect / ExpressRoute-like private peering) attraversa domini che non controlli: la tua LAN, un ISP di transito, il backbone del provider e infine l’edge del cloud. Quando “il cloud non risponde”, il compito del progettista non è dichiarare un guasto, ma isolare il dominio in cui il percorso si degrada realmente. Serve un metodo a strati e dati di assurance che dimostrino dove cade il traffico.

Un metodo bottom-up ripetibile

Procedi dal basso verso l’alto, escludendo un livello alla volta:

  1. Underlay / raggiungibilità. L’interfaccia WAN è up? Il next-hop pubblico e il peer IPsec sono raggiungibili? Un tunnel non sale se l’endpoint remoto è irraggiungibile o se un firewall blocca UDP 500/4500 e il protocollo ESP.
  2. Tunnel IPsec. Verifica IKE e IPsec separatamente: la SA IKE (fase 1) può essere up mentre la SA IPsec (fase 2) non forma per proposal/PFS mismatch o traffic selector divergenti.
  3. Routing overlay (BGP). Con tunnel su, controlla la sessione BGP dentro il tunnel: stato, prefissi ricevuti/annunciati, policy.
  4. High Availability. Verifica quale nodo/tunnel è attivo e se il failover è avvenuto correttamente (tracking, HSRP/VRRP, tunnel ridondanti attivo-standby o ECMP attivo-attivo).
  5. Path effettivo. Solo ora usa la path visualization per vedere hop-by-hop dove compaiono loss e latenza.

Comandi chiave (IOS-XE)

show crypto ikev2 sa
show crypto ipsec sa
show bgp summary
show sdwan bfd sessions
show sdwan omp peers

show crypto ipsec sa deve mostrare i contatori encaps/decaps crescere: se encapsula ma non decapsula, il ritorno è rotto (spesso routing asimmetrico o SA a senso unico). In Cisco Catalyst SD-WAN le sessioni BFD sono la spia dello stato tunnel data-plane, e OMP distribuisce le rotte overlay al posto di BGP puro.

Isolare il dominio con i dati di assurance

Qui entrano ThousandEyes e la telemetria SD-WAN, che trasformano il “sembra lento” in evidenza misurabile.

Sintomo Sorgente dato Cosa indica
Loss su hop LAN/edge locale Enterprise Agent → Network test Problema on-prem
Loss su hop ISP/transito Path Visualization (hop intermedi) Provider di transito
Loss solo sull’ultimo tratto verso il cloud Cloud Agent nella region Edge/region cloud
Rotta ritirata / AS-path anomalo BGP monitoring ThousandEyes Instabilità/hijack di routing
Jitter/latenza per-tunnel vAnalytics / app-route stats Qualità dell’overlay

ThousandEyes Path Visualization esegue test di rete hop-by-hop tra Enterprise Agent (in sede) e Cloud/endpoint di destinazione, mostrando dove forwarding loss e latenza si accumulano. È esattamente la prova che smonta la conclusione affrettata “il cloud è down”: se il loss appare all’hop dell’ISP e non all’edge cloud, il cloud non c’entra. Il BGP monitoring correla i cambi di annuncio con l’interruzione. La telemetria SD-WAN (loss/latency/jitter per tunnel, stato BFD, allarmi in Catalyst SD-WAN Manager e vAnalytics) mostra se il degrado è su una specifica coppia di tunnel, guidando l’application-aware routing a spostare il traffico sul path sano.

Correlare failover e path

Un failover HA “riuscito” può comunque degradare l’esperienza: se lo standby esce da un ISP con path peggiore verso la region, la path visualization lo evidenzia come aumento di latenza post-switchover. Correlare timestamp del failover (log del tracking/BFD down) con lo scalino nei grafici di assurance è ciò che distingue una diagnosi rigorosa da una supposizione.

Trappole tipiche d’esame

  • Scenario: utenti lamentano lentezza verso il cloud e il team dichiara “il cloud è down”. → Risposta giusta: prima raccogli la path visualization (ThousandEyes Network test) per dimostrare in quale dominio compare il loss; senza evidenza del path non si conclude che il guasto sia nel cloud.
  • Scenario: SA IKEv2 up ma nessun traffico passa. → Risposta giusta: controlla la SA IPsec e i contatori encaps/decaps; probabile mismatch di traffic selector/proposal o routing asimmetrico, non un problema di fase 1.
  • Scenario: tunnel su ma il cloud non annuncia le sue subnet. → Risposta giusta: verifica la sessione BGP dentro il tunnel (prefissi ricevuti e policy), non lo stato del tunnel.
  • Scenario: dopo un failover HA la connettività funziona ma la latenza raddoppia. → Risposta giusta: correla il timestamp del failover con la telemetria/path per capire che lo standby usa un percorso di transito peggiore, non un guasto del cloud.
  • Scenario: loss intermittente e picchi di jitter su un solo tunnel SD-WAN. → Risposta giusta: usa le app-route statistics/BFD e vAnalytics per far entrare in azione l’application-aware routing verso il path sano, invece di riavviare il tunnel alla cieca.