Local policy routing
By stretch | Monday, November 30, 2009 at 1:30 p.m. UTC
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).
November 30, 2009 at 1:47 p.m. UTC
November 30, 2009 at 2:07 p.m. UTC
very often forgotten, nice
November 30, 2009 at 2:47 p.m. UTC
If we want to take loopback as outgoing interface for telnet session, in that case will this work?
regards shivlu jain
November 30, 2009 at 5:35 p.m. UTC
@shivlu, if you mean as the source interface, then the /source-interface parameter should work.
I don't know if there is a way to leave that as a default, though.
November 30, 2009 at 10:02 p.m. UTC
I always forget about the local policy and then complain when it doesn't work. Thanks for this one, Stretch.
December 1, 2009 at 6:38 a.m. UTC
@alvarezp "ip telnet source-interface loopback 0" in global config will accomplish that.
December 1, 2009 at 9:00 a.m. UTC
Yes you are right.
The command will accomplish policy base routing even traffic originating from Loopack Int.
December 3, 2009 at 4:31 p.m. UTC
Not sure why telnet traffic originated from R2 would not Match the ACL.
Can someone enlight me ?
December 3, 2009 at 4:34 p.m. UTC
@MCL.Nicolas: It would, but locally-originated traffic is never examined by the ACL since it never enters that (or any) interface; it is generated by the router itself.
February 8, 2011 at 8:49 p.m. UTC
very informative and usefull.
May 6, 2011 at 7:35 a.m. UTC
hi..i have same setup in my lab.R1 - R2 - R3 - R4 are connected like ur setup.
i want to block telnet traffic from R4, via R2 to R1.Pls guide me how to configure.
and also i want to allow internet traffic from R4 via R2 to R1.
February 27, 2013 at 10:14 a.m. UTC
Nice explanation.. Very easy to understand..