SD-WAN: policy centralizzate e application-aware routing

Il modello a due livelli: centralized vs localized policy

In una fabric SD-WAN Cisco Catalyst (ex-Viptela) il piano di controllo è centralizzato sui controller vSmart, che dialogano con i router cEdge/vEdge tramite OMP (Overlay Management Protocol). OMP ridistribuisce prefissi (routes), informazioni TLOC (Transport Locator, cioè il punto di aggancio a un trasporto: MPLS, Internet, LTE) e i service route. Progettare le policy significa decidere dove applicare la logica:

• Centralized policy: definita e “spinta” dal vSmart, agisce sul control plane (control policy) o sul data plane (data policy, incluse app-aware routing e QoS). Non risiede sui router: vive sul controller e viene applicata a un site-list in direzione inbound/outbound rispetto al vSmart.
• Localized policy: configurata sul singolo edge, agisce localmente su ciò che OMP non gestisce: route-map, ACL, marcatura QoS in ingresso, policer, class-map e code hardware sull’interfaccia di uscita.

La regola progettuale ENSLD: la selezione del path overlay è centralized; l’enforcement fisico delle code è localized. Le due devono combaciare.

Application-Aware Routing (AAR)

L’AAR è una data policy centralized che instrada il traffico per classe applicativa in base al rispetto di uno SLA class misurato in tempo reale. Le sonde BFD che corrono su ogni tunnel IPsec dell’overlay misurano continuamente tre metriche:

Si definisce un sla-class (es. VOICE_SLA: loss 1%, latency 150 ms, jitter 30 ms) e lo si associa a una sequenza che matcha il traffico voce/video, elencando i preferred-color (i trasporti preferiti, es. mpls poi biz-internet).

Comportamento chiave: BFD valuta i tunnel; se il preferred-color rispetta lo SLA, il traffico ci resta. Se lo viola, AAR sposta il flusso su un altro path che soddisfa lo SLA. Il parametro backup-sla-preferred-color definisce dove convogliare il traffico quando nessun path rispetta lo SLA, evitando il blackhole.

policy sla-class VOICE_SLA
 loss 1
 latency 150
 jitter 30

Integrazione con la QoS

AAR sceglie quale tunnel attraversare; la QoS localized decide come il traffico viene accodato su quel tunnel. Il flusso corretto in design:

1. Classificazione e marcatura DSCP all’ingresso (localized data policy / class-map).
2. AAR seleziona il path overlay in base allo SLA.
3. Localized policy applica LLQ/CBWFQ, shaping e scheduling sull’interfaccia WAN di uscita.

Punto d’esame: la marcatura DSCP deve essere preservata/ricopiata sull’header esterno IPsec perché il provider MPLS onori le code. Senza tunnel QoS coerente, l’AAR sposta correttamente il flusso ma il provider tratta tutto come best-effort.

Interazione OMP ↔ control policy

Le control policy sul vSmart filtrano e manipolano ciò che OMP annuncia agli edge: possono nascondere TLOC/route, alterare preferenze, forzare service insertion (firewall, IPS) o costruire topologie hub-and-spoke vs full-mesh. Concetto critico: un edge conosce solo i path che il vSmart gli fa vedere via OMP. Se una control policy rimuove un TLOC o una route dalla omp-route, quel path non esiste per l’AAR — indipendentemente dallo SLA misurato.

Da qui il rischio di policy troppo restrittive: filtrando aggressivamente TLOC o forzando un solo color, si riduce l’insieme di path disponibili. Quando quel path viola lo SLA, AAR non ha alternative e il traffico degrada o cade. Il design robusto lascia almeno un path di backup annunciato e coerente tra control policy (visibilità) e AAR (SLA).

Trappole tipiche d’esame

• Scenario: la voce degrada ma i tunnel sono “up”. → Risposta: verificare l’sla-class e i preferred-color dell’AAR; BFD segnala violazione loss/latency/jitter anche con tunnel operativo. Non è un problema di routing OMP.
• Scenario: nessun path rispetta lo SLA e il traffico viene scartato. → Risposta: configurare backup-sla-preferred-color per garantire un fallback deterministico.
• Scenario: un edge non usa il path MPLS previsto pur avendo SLA valido. → Risposta: una control policy sul vSmart sta filtrando quel TLOC/route in OMP; il path non è visibile all’AAR.
• Scenario: AAR sposta bene il traffico ma la voce resta jitterata sul MPLS. → Risposta: manca la QoS localized coerente e la copia DSCP sull’header IPsec esterno; l’overlay non basta senza scheduling.
• Scenario: dopo un tuning di control policy, spariscono i path ridondanti. → Risposta: policy troppo restrittiva; ripristinare l’annuncio di almeno un TLOC/color di backup per non azzerare le alternative dell’AAR.