Policy Based Routing kan worden gebruikt om het volgende hop IP-adres te wijzigen voor verkeer dat aan bepaalde criteria voldoet. Dit kan handig zijn om de routeringstabel te overrulen voor bepaalde soorten verkeer. Ik zal u laten zien hoe u policy-based routing configureert.
Configuratie
hier is de topologie die we zullen gebruiken:
Kijk eens naar de topologie-afbeelding hierboven. OSPF is op alle routers geconfigureerd. Aangezien we overal Gigabit interfaces gebruiken, zou verkeer van R1 bestemd voor 4.4.4.4 normaal gesproken load balanced zijn tussen R2 en R3. Ik heb echter de kosten op de Gigabit Ethernet 0/3 interface van R1 veranderd, zodat al het verkeer van R1 > R2 > R4.
Laten we dit verifiëren:
Hierboven kunt u de verhoogde kosten zien. Laten we een snelle traceroute proberen vanaf H1:
Nu, laten we zeggen dat ik de link tussen R1 en R3 wil gebruiken om 4.4.4.4 te bereiken. Ik zou de metric voor OSPF kunnen beïnvloeden, maar dit geldt voor alle verkeer. Wat als ik deze link alleen voor bepaald verkeer wil gebruiken?
We zouden de link tussen R1/R2 voor het grootste deel van ons verkeer kunnen gebruiken en de link tussen R1/R3 alleen voor bepaald verkeer. Dit kan zeer nuttig zijn. Stel je bijvoorbeeld voor dat de link tussen R1/R3 een dedicated link is die QoS biedt voor VoIP verkeer.
Dit is iets wat we kunnen bereiken met PBR (Policy Based Routing) Ik zal je laten zien hoe!
Op dit moment wordt al het verkeer richting R2 gestuurd:
R1#show ip route | include 4.4.4.4O 4.4.4.4 via 192.168.12.2, 00:16:48, GigabitEthernet0/2
Nu zeggen we dat we willen dat al het ICMP verkeer van H1 bestemd voor 4.4.4.4 de link tussen R1/R3 kruist. Hier is hoe we dit moeten doen:
R1(config)#ip access-list extended ICMP_H1R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4
Eerst maak ik een access-list aan die overeenkomt met mijn verkeer. Nu moeten we een route-map maken:
Wanneer het verkeer overeenkomt met de access-list, zullen we de volgende hop veranderen naar 192.168.13.3 (R3).
Late but not least, laten we het activeren:
R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip policy route-map PBR_H1
Laten we eens kijken of het werkt, om het in actie te zien zal ik een debug op R1 aanzetten:
R1#debug ip policy Policy routing debugging is on
Nu sturen we een ping van H1:
De ping werkt, laten we eens kijken wat R1 ervan vindt:
Hierboven kun je zien dat het beleid is gerouteerd naar 192.168.13.3. We kunnen dit ook verifiëren door naar de route-map te kijken:
Laten we eens wat verkeer proberen dat niet overeenkomt met onze access-list. Telnet bijvoorbeeld:
H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open
H1 is in staat om verbinding te maken, maar het is niet met beleid gerouteerd:
R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy rejected(no match) - normal forwarding
Zoals je hierboven kunt zien, wordt dit telnet verkeer gerouteerd via het normale pad.
Er is nog een ding dat ik je wil laten zien. Met policy-based routing is er een verschil tussen verkeer dat door de router gaat en verkeer dat afkomstig is van de router.
Het voorbeeld hierboven is voor verkeer dat door onze router ging. Wat als we policy route verkeer willen dat afkomstig is van R1? We zullen een ander commando moeten gebruiken om het te activeren. Laten we een andere route-map maken:
De bovenstaande route-map zal al het verkeer van R1 omleiden naar 4.4.4.4 richting R3. Om dit te activeren, moeten we een ander commando gebruiken:
R1(config)#ip local policy route-map PBR_R1
Deze keer moeten we het ip local policy commando gebruiken. Laten we dit testen:
Geweldig, ons verkeer van R1 wordt met beleid gerouteerd.