Jak skonfigurować Policy Based Routing

Policy-based routing może być użyty do zmiany adresu IP następnego skoku dla ruchu spełniającego pewne kryteria. To może być użyteczne, aby unieważnić tabelę routingu dla pewnych typów ruchu. Pokażę Ci jak skonfigurować routing oparty na politykach.

Konfiguracja

Oto topologia, której będziemy używać:

Spójrz na powyższy rysunek topologii. OSPF jest skonfigurowany na wszystkich routerach. Ponieważ wszędzie używamy interfejsów gigabitowych, ruch z R1 kierowany do 4.4.4.4 normalnie byłby równoważony pomiędzy R2 i R3. Jednakże, zmieniłem koszt na interfejsie Gigabit Ethernet 0/3 w R1 tak, że cały ruch będzie szedł z R1 > R2 > R4.

Sprawdźmy to:

Powyżej możesz zobaczyć zwiększony koszt. Spróbujmy szybkiego traceroute z H1:

Teraz powiedzmy, że chcę użyć łącza pomiędzy R1 i R3 aby dotrzeć do 4.4.4.4. Mógłbym wpłynąć na metrykę dla OSPF, ale to dotyczy całego ruchu. Co jeśli chciałbym użyć tego łącza tylko dla określonego ruchu?

Możemy użyć łącza pomiędzy R1/R2 dla większości naszego ruchu i użyć łącza pomiędzy R1/R3 tylko dla określonego ruchu. To może być bardzo przydatne. Na przykład, wyobraź sobie, że łącze pomiędzy R1/R3 jest dedykowanym łączem, które oferuje QoS dla ruchu VoIP.

To jest coś, co możemy osiągnąć z PBR (Policy Based Routing) Pokażę ci jak!

W tej chwili cały ruch jest wysyłany w kierunku R2:

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

Teraz powiedzmy, że chcemy, aby cały ruch ICMP z H1 przeznaczony dla 4.4.4.4 przekroczył łącze pomiędzy R1/R3. Oto jak to zrobić:

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

Po pierwsze, tworzę listę dostępu, która pasuje do mojego ruchu. Teraz musimy utworzyć route-map:

Gdy ruch będzie pasował do access-listy, zmienimy next hop na 192.168.13.3 (R3).

Ostatnio, ale nie mniej ważne, aktywujmy to:

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

Zobaczmy czy to działa, aby zobaczyć to w akcji włączę debug na R1:

R1#debug ip policy Policy routing debugging is on

Teraz wyślijmy ping z H1:

Ping działa, zobaczmy co R1 o tym myśli:

Powyżej widać, że został on policy routing w kierunku 192.168.13.3. Możemy to również zweryfikować patrząc na route-map:

Spróbujmy ruchu, który nie pasuje do naszej listy dostępu. Na przykład Telnet:

H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open

H1 jest w stanie się połączyć, ale nie jest kierowany zgodnie z polityką:

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

Jak widać powyżej, ten ruch telnetowy jest kierowany normalną ścieżką.

Jest jeszcze jedna rzecz, którą chciałbym pokazać. Z routingiem opartym na polityce, jest różnica między ruchem, który przechodzi przez router i ruchem, który pochodzi z routera.

Powyższy przykład jest dla ruchu, który przeszedł przez nasz router. Co zrobić, jeśli chcemy, aby polityka routingu ruchu, który pochodzi z R1? Będziemy musieli użyć innej komendy aby to aktywować. Stwórzmy kolejną route-map:

Powyższa route-mapa przekieruje cały ruch z R1 na 4.4.4.4 w kierunku R3. Aby to aktywować, musimy użyć kolejnej komendy:

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

Tym razem musimy użyć komendy ip local policy. Przetestujmy to:

Świetnie, nasz ruch z R1 jest kierowany zgodnie z polityką.