The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

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.

local_policy_routing.png

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).

Posted in Design, Routing

Comments


Colby
November 30, 2009 at 1:47 p.m. UTC

Nice.


irom
November 30, 2009 at 2:07 p.m. UTC

very often forgotten, nice


shivlu
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


alvarezp
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.


aconaway
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.


fach
December 1, 2009 at 6:38 a.m. UTC

@alvarezp "ip telnet source-interface loopback 0" in global config will accomplish that.


Bxperts
December 1, 2009 at 9:00 a.m. UTC

Fach,

Yes you are right.

The command will accomplish policy base routing even traffic originating from Loopack Int.

Regards,


MCL.Nicolas
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 ?

Thanks


stretch
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.


shankar
February 8, 2011 at 8:49 p.m. UTC

very informative and usefull.


vgshan
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.


A guest
February 27, 2013 at 10:14 a.m. UTC

Nice explanation.. Very easy to understand..

Comments have closed for this article due to its age.