The following topology illustrates a simple OSPF network. Traffic from R1 to R5 is load-balanced across the two equal-cost paths provided by R3 and R4. However, an excessive security policy has been erroneously applied at R3, blocking Telnet traffic through the router.
As a result, Telnet traffic toward R5 is being dropped if sent via R3 but permitted if sent via R4, appearing to users as intermittent connectivity issues. (A note for anyone labbing this out: this example ignores real-world CEF load-sharing behavior, where all traffic to a single destination is sent across only one path by default, by disabling CEF on R2.) As a temporary fix until the administrator of R3 can be contacted, policy routing has been employed on R2 to force all Telnet traffic across R4:
interface FastEthernet1/0 ip policy route-map Send_Telnet_Via_R4 ! ip access-list extended Match_Telnet permit tcp any any eq telnet ! route-map Send_Telnet_Via_R4 permit 10 match ip address Match_Telnet set ip next-hop 10.0.24.4
This works great for Telnet traffic originating from R1, but what about traffic coming from R2 itself? Normal policy routing like that configured above applies only to transit traffic; Telnet traffic originating from R2 is still being load-balanced via the two equal-cost OSPF routes. Fortunately, we can extend our configuration to implement local policy routing with a single command:
R2(config)# ip local policy route-map Send_Telnet_Via_R4
This command applies our policy route-map to the router's control plane in the same manner
ip policy route-map applies it to traffic entering an interface. Now all Telnet traffic originating from R2 itself is forwarded via R4. Note that in a real-world deployment, you would want to employ more granular access lists in the policy route-map so as not to force all Telnet traffic toward R4 (we still want Telnet traffic for R1 to go toward R1, for example).