Il motore di routing di Expressway

In Cisco Expressway ogni chiamata o registrazione genera una ricerca (search) su un alias di destinazione. Il motore confronta l’alias contro un elenco ordinato di search rules: quando una regola produce un match, la ricerca viene inoltrata verso la target zone associata. Capire come i pre-search transforms normalizzano l’alias e come la priority determina l’ordine di valutazione è il cuore del dial plan che l’esame CLCEI verifica.

Pre-search transforms

I pre-search transforms agiscono globalmente su ogni ricerca, prima che qualsiasi search rule venga valutata. Servono a normalizzare gli alias in un formato canonico (per esempio aggiungere il dominio SIP, correggere prefissi legacy, uniformare E.164).

Ogni transform ha:

  • Pattern type: Exact, Prefix, Suffix o Regex.
  • Pattern behaviour: Strip (rimuove la parte matchata) o Replace (la sostituisce con la stringa indicata).
  • Priority: i transform vengono applicati in ordine e si accumulano — l’output di uno diventa l’input del successivo.

Punto critico: il transform modifica in modo permanente l’alias usato da tutte le search rule a valle. Un transform troppo aggressivo altera l’alias prima ancora che le regole possano riconoscerlo.

Search rules

Le search rules decidono dove cercare. I parametri chiave:

Parametro Significato
Priority (1-65534) Ordine di valutazione: valore più basso = valutata prima
Source Any, All zones, Local Zone o una zona/subzone specifica da cui proviene la richiesta
Request must be authenticated Applica la regola solo a richieste autenticate
Mode / Pattern type Any alias, oppure Alias pattern match con Exact / Prefix / Suffix / Regex
Pattern behaviour Leave (invia l’alias immutato), Strip, Replace — trasforma l’alias solo per quella ricerca, non globalmente
On successful match Continue (prova anche le regole a priorità più bassa) o Stop (interrompe la ricerca)
Target La zona (Neighbor, Traversal, DNS, ecc.) o il policy service verso cui inoltrare

Nota importante: il Replace interno alla search rule agisce localmente, senza alterare l’alias per le regole successive. È il modo “sicuro” di adattare un alias a una zona senza effetti collaterali.

Come la priority guida la sequenza

Il motore ordina tutte le search rule attive per priority crescente e le valuta una a una:

  1. Verifica che source e autenticazione corrispondano.
  2. Verifica il match del pattern sull’alias (già passato dai pre-search transforms).
  3. Se c’è match, applica il pattern behaviour e interroga la target zone.
  4. Se la zona risponde con una location, la chiamata è instradata; altrimenti, in base a Continue/Stop, si prosegue o ci si ferma.

Con Continue, più zone possono essere provate in cascata (es. prima Local Zone, poi zona neighbor CUCM, infine DNS zone verso l’esterno). Con Stop, la prima regola che matcha chiude la ricerca anche se la zona non trova la destinazione: la chiamata fallisce senza fallback.

Regole con stessa priority vengono valutate in ordine non deterministico: è una configurazione da evitare quando l’esito dipende dall’ordine.

Trappole tipiche d’esame

  • Transform globale troppo aggressivo → alias irriconoscibile: uno scenario mostra un pre-search transform con Prefix / Replace che riscrive l’alias in un formato che nessuna search rule successiva matcha più, oppure lo fa collidere con un’altra zona. Risposta giusta: restringere il pattern del transform (o usare Regex più specifica), oppure spostare la logica dentro la search rule con behaviour locale invece che nel transform globale.

  • Priority sovrapposte / regola generica prima di quella specifica: una regola Any alias → DNS zone con priority più bassa (es. 10) intercetta chiamate destinate a CUCM. Risposta giusta: dare alla regola specifica (verso il neighbor CUCM) una priority inferiore (valore numerico più piccolo) rispetto alla catch-all.

  • Stop on match che blocca il fallback: la prima regola matcha ma la zona non risolve; con On successful match = Stop non si tenta la zona successiva. Risposta giusta: impostare Continue per consentire il tentativo sulle zone a priorità inferiore.

  • Source errata: una regola non instrada perché il Source è impostato su una zona diversa da quella da cui arriva la richiesta (es. dalla traversal zone MRA). Risposta giusta: allineare il campo Source (spesso Any) alla zona di provenienza reale.

  • Confusione transform globale vs. behaviour di regola: modificare l’alias per una zona non deve avvenire in un pre-search transform globale. Risposta giusta: usare Replace/Strip all’interno della search rule, così l’alias resta intatto per le altre regole.