Cum se configurează direcționarea bazată pe politici

Direcționarea bazată pe politici poate fi utilizată pentru a schimba adresa IP a următorului hop pentru traficul care corespunde anumitor criterii. Acest lucru poate fi util pentru a suprascrie tabelul de rutare pentru anumite tipuri de trafic. Vă voi arăta cum să configurați rutarea bazată pe politici.

Configurare

Iată topologia pe care o vom folosi:

Aruncați o privire la imaginea topologică de mai sus. OSPF este configurat pe toate routerele. Deoarece folosim interfețe Gigabit peste tot, traficul de la R1 destinat 4.4.4.4.4.4 va fi în mod normal echilibrat în sarcină între R2 și R3. Cu toate acestea, am modificat costul pe interfața Gigabit Ethernet 0/3 a lui R1, astfel încât tot traficul să meargă de la R1 > R2 > R4.

Să verificăm acest lucru:

Deasupra puteți vedea costul crescut. Să încercăm un traceroute rapid din H1:

Acum să spunem că vreau să folosesc legătura dintre R1 și R3 pentru a ajunge la 4.4.4.4.4. Aș putea influența metrica pentru OSPF, dar acest lucru este valabil pentru tot traficul. Ce se întâmplă dacă aș vrea să folosesc această legătură doar pentru un anumit trafic?

Am putea folosi legătura dintre R1/R2 pentru majoritatea traficului nostru și să folosim legătura dintre R1/R3 doar pentru un anumit trafic. Acest lucru poate fi foarte util. De exemplu, imaginați-vă că legătura dintre R1/R3 este o legătură dedicată care oferă QoS pentru traficul VoIP.

Acesta este un lucru pe care îl putem realiza cu PBR (Policy Based Routing) Lăsați-mă să vă arăt cum!

În acest moment, tot traficul este trimis către R2:

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

Acum să spunem că dorim ca tot traficul ICMP din H1 destinat 4.4.4.4.4 să traverseze legătura dintre R1/R3. Iată cum să facem acest lucru:

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

În primul rând, creez o listă de acces care se potrivește cu traficul meu. Acum trebuie să creăm un route-map:

De fiecare dată când traficul se potrivește cu lista de acces, vom schimba următorul salt la 192.168.13.3 (R3).

În cele din urmă, dar nu în ultimul rând, să o activăm:

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

Să vedem dacă funcționează, pentru a o vedea în acțiune voi activa un debug pe R1:

R1#debug ip policy Policy routing debugging is on

Acum să trimitem un ping de pe H1:

Pingul funcționează, să vedem ce părere are R1 despre el:

Deasupra puteți vedea că a fost direcționat prin politică spre 192.168.13.3. De asemenea, putem verifica acest lucru uitându-ne la route-map:

Să încercăm un trafic care nu se potrivește cu lista noastră de acces. Telnet, de exemplu:

H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open

H1 este capabil să se conecteze, dar nu este direcționat prin politica de rutare:

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

După cum puteți vedea mai sus, acest trafic telnet este direcționat folosind calea normală.

Am mai vrea să vă arăt un lucru. Cu rutarea bazată pe politici, există o diferență între traficul care trece prin router și traficul care provine din router.

Exemplul de mai sus este pentru traficul care a trecut prin routerul nostru. Ce se întâmplă dacă dorim să direcționăm prin politici traficul care este originat de pe R1? Va trebui să folosim o altă comandă pentru a-l activa. Să creăm un alt route-map:

Route-map-ul de mai sus va redirecționa tot traficul de la R1 către 4.4.4.4.4 spre R3. Pentru a o activa, trebuie să folosim o altă comandă:

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

De data aceasta, trebuie să folosim comanda ip local policy. Să testăm acest lucru:

Genial, traficul nostru din R1 este direcționat prin politică.

.