Policybaseret routing kan bruges til at ændre næste hop-IP-adressen for trafik, der opfylder visse kriterier. Dette kan være nyttigt til at tilsidesætte din routingtabel for visse trafiktyper. Jeg vil vise dig, hvordan du konfigurerer politikbaseret routing.
Konfiguration
Her er den topologi, som vi vil bruge:
Se på topologibilledet ovenfor. OSPF er konfigureret på alle routere. Da vi bruger Gigabit-grænseflader overalt, vil trafik fra R1, der er bestemt til 4.4.4.4.4, normalt blive belastningsbalanceret mellem R2 og R3. Jeg har dog ændret omkostningerne på Gigabit Ethernet 0/3-interfacet på R1, så al trafik vil gå fra R1 > R2 > R4.
Lad os verificere dette:
Ovenfor kan du se de øgede omkostninger. Lad os prøve en hurtig traceroute fra H1:
Lad os nu sige, at jeg ønsker at bruge linket mellem R1 og R3 for at nå 4.4.4.4.4. Jeg kan påvirke metricen for OSPF, men dette gælder for al trafik. Hvad nu hvis jeg kun vil bruge dette link til bestemt trafik?
Vi kunne bruge linket mellem R1/R2 til størstedelen af vores trafik og kun bruge linket mellem R1/R3 til bestemt trafik. Dette kan være meget nyttigt. Forestil dig for eksempel, at linket mellem R1/R3 er et dedikeret link, der tilbyder QoS til VoIP-trafik.
Dette er noget, vi kan opnå med PBR (Policy Based Routing) Lad mig vise dig hvordan!
Ret nu sendes al trafik mod R2:
R1#show ip route | include 4.4.4.4O 4.4.4.4 via 192.168.12.2, 00:16:48, GigabitEthernet0/2Lad os nu sige, at vi ønsker, at al ICMP-trafik fra H1, der er bestemt for 4.4.4.4.4, skal krydse linket mellem R1/R3. Her er hvordan vi gør dette:
R1(config)#ip access-list extended ICMP_H1R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4Først opretter jeg en access-list, der matcher min trafik. Nu skal vi oprette et route-map:
Når trafikken matcher access-listen, ændrer vi næste hop til 192.168.13.3 (R3).
Sidst men ikke mindst, lad os aktivere det:
R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip policy route-map PBR_H1 Lad os se, om det virker, for at se det i aktion vil jeg aktivere en debug på R1:
R1#debug ip policy Policy routing debugging is onLad os nu sende en ping fra H1:
Ping’en virker, lad os se hvad R1 synes om den:
Overfor kan du se, at den er blevet policy routed mod 192.168.13.3. Vi kan også verificere dette ved at kigge på route-map:
Lad os prøve noget trafik, der ikke passer til vores access-list. Telnet for eksempel:
H1#telnet 4.4.4.4Trying 4.4.4.4 ... OpenH1 kan oprette forbindelse, men den er ikke policy-routed:
R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy rejected(no match) - normal forwardingSom du kan se ovenfor, bliver denne telnet-trafik dirigeret via den normale vej.
Der er en ting mere, som jeg gerne vil vise dig. Med politikbaseret routing er der en forskel mellem trafik, der går gennem routeren, og trafik, der stammer fra routeren.
Eksemplet ovenfor er for trafik, der gik gennem vores router. Hvad hvis vi ønsker at foretage policy-routing af trafik, der stammer fra R1? Vi bliver nødt til at bruge en anden kommando for at aktivere den. Lad os oprette et andet rute-map:
Rute-map’et ovenfor vil omdirigere al trafik fra R1 til 4.4.4.4.4.4 mod R3. For at aktivere dette skal vi bruge en anden kommando:
R1(config)#ip local policy route-map PBR_R1Denne gang skal vi bruge kommandoen ip local policy. Lad os teste dette:
Glimrende, vores trafik fra R1 er policy-routeret.