Everyone knows that the routing table lists the routes to particular network destinations, but is it possible define the next-hop based on source ip, packet size or other criteria? Obviously yes!
Policy-based routing (PBR) provides a tool for forwarding and routing data packets based on policies defined by network administrators. In effect, it is a way to have the policy override routing protocol decisions. Policy-based routing includes a mechanism for selectively applying policies based on access list, packet size or other criteria. The actions taken can include routing packets on user-defined routes, setting the precedence, type of service bits, etc.
Policy-based routing is applied to incoming packets. All packets received on an interface with policy-based routing enabled are considered for policy-based routing. The router passes the packets through enhanced packet filters called route maps. Based on the criteria defined in the route maps, packets are forwarded/routed to the appropriate next hop.
The benefits that can be achieved by implementing policy-based routing in the networks include:
- Source-Based Transit Provider Selection: Internet service providers and other organizations can use policy-based routing to route traffic originating from different sets of users through different Internet connections across the policy routers.
- Quality of Service: Organizations can provide QOS to differentiated traffic by setting the precedence or type of service (TOS) values in the IP packet headers at the periphery of the network and leveraging queuing mechanisms to prioritize traffic in the core or backbone of the network.
- Cost Savings: Organizations can achieve cost savings by distributing interactive and batch traffic among low-bandwidth, low-cost permanent paths and high-bandwidth, high-cost, switched paths.
- Load Sharing: In addition to the dynamic load-sharing capabilities offered by destination-based routing that the Cisco IOS software has always supported, network managers can now implement policies to distribute traffic among multiple paths based on the traffic characteristics.
See you below the example to better understand how PBR works.
Suppose that the Ciscozine router has two different links, one with high performance (red link) and one, the default route, with low performance (blue link). In this example, the network A uses the red link, while the network B uses the blue link.
Step #1: Define the default route (blue link).
ip route 0.0.0.0 0.0.0.0 172.16.255.6
Step #2: Define the access-list used by the PBR.
Ciscozine(config)#ip access-list extended 101 Ciscozine(config-ext-nacl)#permit ip 10.0.0.0 0.0.0.255 any
Step #3: Define the route-map; in this case, when a packet matches the ACL ‘101’, the default route for this ACL will be ‘172.16.255.2’.
Ciscozine(config)#route-map gold Ciscozine(config-route-map)#match ip address 101 Ciscozine(config-route-map)#set ip next-hop 172.16.255.2
Step #4: Apply the route-map to the interface; remember that policy-based routing is applied to incoming packets.
Ciscozine(config)#interface fa0/0 Ciscozine(config-if)#ip policy route-map gold
Step #5: Test the service using the commands “debug ip policy” and “debug ip packet”.
Test #1: Test reachability from 10.0.0.2 (on Network A) to 55.55.55.55 (on headquarter) using ICMP packet.
Ciscozine#debug ip policy Policy routing debugging is on Ciscozine# Apr 22 18:23:48.015: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55, len 100, policy match Apr 22 18:23:48.019: IP: route map gold, item 10, permit Apr 22 18:23:48.023: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet0/1), len 100, policy routed Apr 22 18:23:48.027: IP: FastEthernet0/0 to FastEthernet0/1 172.16.255.2 Apr 22 18:23:48.119: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55, len 100, policy match Apr 22 18:23:48.123: IP: route map gold, item 10, permit Apr 22 18:23:48.123: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet0/1), len 100, policy routed Apr 22 18:23:48.127: IP: FastEthernet0/0 to FastEthernet0/1 172.16.255.2 Ciscozine#
Ciscozine#debug ip packet 101 detail IP packet debugging is on (detailed) for access list 101 Ciscozine# Apr 22 18:25:57.359: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), routed via RIB Apr 22 18:25:57.363: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet0/1), g=172.16.255.2, len 100, forward Apr 22 18:25:57.367: ICMP type=8, code=0 Apr 22 18:25:57.463: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), routed via RIB Apr 22 18:25:57.467: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet0/1), g=172.16.255.2, len 100, forward Apr 22 18:25:57.471: ICMP type=8, code=0 Apr 22 18:25:57.539: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), routed via RIB Apr 22 18:25:57.543: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet0/1), g=172.16.255.2, len 100, forward Apr 22 18:25:57.547: ICMP type=8, code=0 Apr 22 18:25:57.579: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), routed via RIB Apr 22 18:25:57.583: IP: s=10.0.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet0/1), g=172.16.255.2, len 100, forward Apr 22 18:25:57.587: ICMP type=8, code=0 Ciscozine#
As you notice, the policy ‘gold’ is matched (‘policy match’) and the packet is forwarded (‘to FastEthernet0/1 172.16.255.2’).
Test #2: Test reachability from 192.168.0.2 (on Network B) to 55.55.55.55 (on headquarter) using ICMP packet.
Ciscozine#debug ip policy Policy routing debugging is on Ciscozine# Apr 22 18:27:33.815: IP: s=192.168.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), len 100, policy rejected -- normal forwarding Apr 22 18:27:33.863: IP: s=192.168.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), len 100, policy rejected -- normal forwarding Apr 22 18:27:33.903: IP: s=192.168.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0), len 100, policy rejected -- normal forwarding Apr 22 18:27:33.943: IP: s=192.168.0.2 (FastEthernet0/0), d=55.55.55.55 (FastEthernet1/0) Ciscozine#, len 100, policy rejected -- normal forwarding Ciscozine#
Ciscozine#debug ip packet 101 detail IP packet debugging is on (detailed) for access list 101 Ciscozine#
As you notice, the policy ‘gold’ is rejected (‘policy rejected — normal forwarding’) because the access-list 101 is not matched; this is the reason because you don’t see anything when you enable the ‘debug ip packet 101 detail’!
Note1: The ‘set ip next-hop‘ and ‘set ip default next-hop‘ are similar commands but have a different order of operations. Configuring the set ip next-hop command causes the system to use policy routing first and then use the routing table. Configuring the set ip default next-hop command causes the system to use the routing table first and then policy route the specified next hop.
Note2: Remember that PBR can create an asymmetric routing environment!
References:
Does PBR increase the CPU utilization by using a less efficient method of packet forwarding?
Hi, how if Network A and B behind NAT, is the config same?
Very helpful me .. thanks for sharing .. looking for more .. thanks again .
Hi ! awesome article, but how can I have network A and B communicate between them with this method ? next-hop ip seems to prevent my vlan to communicate. thanks !
Could you explain what do you do more in depth ?
It’s okay I got my solution, thanks anyway ! :)
My situation is slightly different.
The ISP is routing all traffic for our public IP CIDR (i.e your 10.0.0.0 in Network A) to the assigned IP address of our outside facing port (i.e. 172.16.255.1 on CiscoZine).
I need the 10.0.0.0 network’s NEXT HOP to be 172.16.255.1
Tried this with a PBR, but receive and warning “the next hop address is our address”
Thoughts?
So if ACL is not matched than PBR isnt applied and normal routing still occurs ? Is that correct?
I’m having trouble setting up PBR on the following configuration.
Source (App servers)
10.149.64.0/24
Router A (Cisco 3560g)
Port 1: 10.149.92.1
Port 2: 192.168.155.1
Both ports are going via seperate wireless links towards Router B which is a Mikrotik CCR
What I need is that all traffic to and from 10.149.64.0/24 for the LINK is being routed via Port 2, the other traffic can go via Port1.
any clue?
Not all the commands work for 9.5.x code.
use policy-route route-map
instead of ip policy route-map
Also, there is no debug ip policy command
its debug policy route-map
Hi Fabio, What will be the order of operation between PBR and CEF ? If I have applied a source based policy route-map on a CEF enabled interface, will CEF updates CEF table based on policy route next-hop ?
Beginning in Cisco IOS Release 12.0, PBR is supported in the Cisco Express Forwarding (CEF) switching path. CEF-switched PBR has better performance than fast-switched PBR and, therefore, is the optimal way to perform PBR on a router.
No special configuration is required to enable CEF-switched PBR. It is on by default as soon as you enable CEF and PBR on the router.
Reference: http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpbr.html#wp1000980
Hi Fabio, How does “sh ip route” behave when PBR is involved? Any way to see what the routing table looks like when PBR is involved? Thanks.
Hello Fabio,
I try to implement a PBR on my Cisco 3750G-12S IOS ver 12.2(55)SE10.
I have some SVI including two to get out on the Internet. This is lab. One exit by my ASA and the second to my Juniper SRX.
My objective is to configure some IP across by the ASA and other by the Juniper.
Schema:
SVI vlan 81 —> Juniper SRX
SVI vlan 100
SVI vlan 80 —> Cisco ASA
I put my route-map on SVI 80
access-list 100 permit ip host 192.168.100.50 any
If I start a debug ip packet 100 detail, I don’t see any trafic and my PBR don’t work. I would like to understand why I don’t see any traffic.
route-map xxxxxx, permit, sequence 10
Match clauses:
ip address (access-lists): 100
Set clauses:
ip next-hop 192.168.81.254
Policy routing matches: 0 packets, 0 bytes
Normally, when traffic passes from vlan 100 to vlan 80, traffic should be intercepted and redirected to vlan 80. This does not seem to work with SVI. Should I switch to L3 (no switchport)? Thank you for your help.
Hi,
actually the only way to verify the types of packets that are policy routed is to use the debug ip policy command.
Cheers
Yes, try to use a router interface (no switchport).