Ping del router o host VLAN: quale policy PBR si applica?

VLAN 10 dovrebbe usare la VPN e VLAN 20 la WAN, quindi il primo test è un ping dal router con l’indirizzo dell’interfaccia di VLAN 10 come origine. Riesce, i contatori della route-map aumentano e tutti concludono che il progetto funziona. Non è così. Quel ping è stato generato localmente, e il traffico generato localmente raggiunge un punto di aggancio della policy diverso da un pacchetto che arriva sull’interfaccia VLAN.

Tre condizioni decidono quale policy stai davvero testando: dove viene creato il pacchetto, dove entra e a cosa corrisponde.

Dove entra il pacchetto decide quale policy viene eseguita

Una route-map di interfaccia agganciata con ip policy route-map si applica ai pacchetti che arrivano su quell’interfaccia, come descrive la guida PBR di IOS XE. Un host in VLAN 10 invia la sua richiesta, il frame arriva sulla sottointerfaccia VLAN e il router valuta la policy lì. Il pacchetto del router non arriva mai su quell’interfaccia, perché è nato nel router.

Scegliere l’indirizzo VLAN come origine cambia l’intestazione. Non cambia l’origine.

Perché il ping con origine non è ancora l’host

L’indirizzo di origine conta per una corrispondenza ACL, ed è proprio questo che rende il test così convincente. Il pacchetto corrisponde a una clausola di origine, i contatori aumentano e l’output sembra corretto. Ciò che il test non può mostrare è l’interfaccia di ingresso, il contesto di arrivo o se un pacchetto dell’host prenderebbe lo stesso ramo.

Un test che riproduce la corrispondenza ma non il contesto prova metà del progetto, e con mezza prova i progetti vengono rilasciati con la policy sbagliata agganciata.

Quando una policy locale è la risposta giusta

Cisco documenta ip local policy route-map per il traffico che il router genera da sé. È un ambito separato, ed è lo strumento corretto quando il requisito riguarda davvero il traffico del router. Non è un passaggio mancante che ogni progetto di instradamento VLAN richiede. Una corrispondenza ampia lì può anche influenzare le connessioni di gestione e di supporto, che è un cambiamento molto più grande di quanto sembri.

Il TCP generato localmente ha un prerequisito aggiuntivo: richiede una voce di destinazione applicabile nella tabella di routing anche quando la policy seleziona un altro percorso. Un risultato ICMP non dimostra lo stesso comportamento per TCP.

Cosa testare invece sull’host

Esegui il test da un host autorizzato in VLAN 10, con il suo indirizzo di origine, destinazione, protocollo e porta reali. Registra l’interfaccia di ingresso e la corrispondenza della route-map accanto al risultato, così l’evidenza nomina la policy eseguita. Poi ripeti per un host in VLAN 20 e conferma che prende l’altro percorso.

Entrambi i percorsi richiedono next hop funzionanti, raggiungibilità di ritorno e, dove applicabile, copertura VPN. PBR sceglie una decisione di inoltro; non crea il servizio remoto né concede all’applicazione l’autorizzazione.

Cosa può e non può provare il risultato

Un flusso host riuscito prova che la policy corrispondeva e che il percorso scelto funzionava in quel momento. Non prova che il traffico del router sia instradato, e non prova che l’applicazione fosse autorizzata, perché sono domande diverse con prove diverse.

Conserva il ping nel registro come evidenza di un pacchetto locale. Poi vai a prendere l’evidenza del flusso host, invece di allargare l’ambito della policy finché i due test non sembrano uguali.