Come configurare il routing basato su criteri

Il routing basato su criteri può essere usato per cambiare l’indirizzo IP dell’hop successivo per il traffico che corrisponde a certi criteri. Questo può essere utile per annullare la vostra tabella di routing per certi tipi di traffico. Ti mostrerò come configurare il routing basato su policy.

Configurazione

Ecco la topologia che useremo:

Guarda l’immagine della topologia qui sopra. OSPF è configurato su tutti i router. Poiché stiamo usando interfacce Gigabit ovunque, il traffico da R1 destinato a 4.4.4.4 sarebbe normalmente bilanciato tra R2 e R3. Tuttavia, ho cambiato il costo sull’interfaccia Gigabit Ethernet 0/3 di R1 in modo che tutto il traffico vada da R1 > R2 > R4.

Verifichiamo questo:

Sopra potete vedere il costo aumentato. Proviamo un rapido traceroute da H1:

Ora diciamo che voglio usare il link tra R1 e R3 per raggiungere 4.4.4.4. Potrei influenzare la metrica per OSPF, ma questo vale per tutto il traffico. E se volessi usare questo link solo per un certo traffico?

Potremmo usare il link tra R1/R2 per la maggior parte del nostro traffico e usare il link tra R1/R3 solo per un certo traffico. Questo può essere molto utile. Per esempio, immagina che il link tra R1/R3 sia un link dedicato che offre QoS per il traffico VoIP.

Questo è qualcosa che possiamo ottenere con PBR (Policy Based Routing) Lascia che ti mostri come!

In questo momento, tutto il traffico è inviato verso R2:

R1#show ip route | include 4.4.4.4O 4.4.4.4 via 192.168.12.2, 00:16:48, GigabitEthernet0/2

Ora diciamo che vogliamo che tutto il traffico ICMP da H1 destinato a 4.4.4.4 attraversi il collegamento tra R1/R3. Ecco come farlo:

R1(config)#ip access-list extended ICMP_H1R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4

Prima di tutto, creo una access-list che corrisponde al mio traffico. Ora dobbiamo creare una route-map:

Ogni volta che il traffico corrisponde alla access-list, cambieremo l’hop successivo a 192.168.13.3 (R3).

In ultimo, ma non meno importante, attiviamolo:

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip policy route-map PBR_H1 

Vediamo se funziona, per vederlo in azione abilito un debug su R1:

R1#debug ip policy Policy routing debugging is on

Ora mandiamo un ping da H1:

Il ping funziona, vediamo cosa ne pensa R1:

Sopra potete vedere che è stato instradato verso 192.168.13.3. Possiamo anche verificare questo guardando la route-map:

Proviamo un po’ di traffico che non corrisponde alla nostra access-list. Telnet per esempio:

H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open

H1 è in grado di connettersi ma non è policy routing:

R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy rejected(no match) - normal forwarding

Come potete vedere sopra, questo traffico telnet è instradato usando il percorso normale.

C’è un’altra cosa che vorrei mostrarvi. Con l’instradamento basato su policy, c’è una differenza tra il traffico che passa attraverso il router e il traffico che ha origine dal router.

L’esempio sopra è per il traffico che è passato attraverso il nostro router. Cosa succede se vogliamo impostare un policy route per il traffico originato da R1? Dovremo usare un altro comando per attivarlo. Creiamo un’altra route-map:

La route-map sopra reindirizzerà tutto il traffico da R1 a 4.4.4.4 verso R3. Per attivarla, dobbiamo usare un altro comando:

R1(config)#ip local policy route-map PBR_R1

Questa volta, dobbiamo usare il comando ip local policy. Testiamolo:

Bene, il nostro traffico da R1 è instradato secondo la policy.