In a typical network, routing is done on a hop by hop basis with each router making a forwarding decision based on the destination address of a packet. However, certain scenarios can occur that require routing based on something other than the destination. Policy based routing (PBR) can be used to modify how packets are handled by a router. This blog post will demonstrate how to perform policy based routing on Cisco IOS devices using the source address as the policy to route by.
The topology consists of four routers and simulates the connection between the HQ site and a branch site. The HQ-RTR connects to the Internet-RTR and MPLS-RTR routers to simulate an Internet connection and a private WAN connection. The branch router Branch-RTR also connects to Internet-RTR and MPLS-RTR. The branch site also contains a switch and two VPCS machines representing two VLANs at the branch site. The 10.x.x.x private address range is used for the backside networks at the branch and HQ sites.
I used the 172.16.x.x private address range for the Internet-RTR connections, and 192.168.x.x for the MPLS-RTR connections. This will make it easier to see the different paths taken when policy based routing is configured.
Each router is configured with an IP address on each interface and a simple OSPF configuration to allow all routers to talk to each other. I used the “network 0.0.0.0 255.255.255.255 area 0” to tell OSPF to use any interface configured with an IP address.
interface Loopback1 ip address 10.0.0.1 255.255.255.0 ip ospf network point-to-point no shut interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.252 no shut interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.252 no shut router ospf 1 router-id 126.96.36.199 network 0.0.0.0 255.255.255.255 area 0
interface FastEthernet0/0 ip address 172.16.1.2 255.255.255.252 no shut interface FastEthernet0/1 ip address 172.16.1.5 255.255.255.252 no shut router ospf 1 router-id 188.8.131.52 network 0.0.0.0 255.255.255.255 area 0
interface FastEthernet0/0 ip address 192.168.1.2 255.255.255.252 no shut interface FastEthernet0/1 ip address 192.168.1.5 255.255.255.252 no shut router ospf 1 router-id 184.108.40.206 network 0.0.0.0 255.255.255.255 area 0
interface FastEthernet0/0 ip address 172.16.1.6 255.255.255.252 no shut interface FastEthernet0/1 ip address 192.168.1.6 255.255.255.252 no shut interface FastEthernet 1/0.10 encapsulation dot1q 10 ip address 10.10.10.1 255.255.255.0 interface FastEthernet 1/0.20 encapsulation dot1q 20 ip address 10.10.20.1 255.255.255.0 router ospf 1 router-id 220.127.116.11 network 0.0.0.0 255.255.255.255 area 0
The switch simply gets one port assigned as a dot1q trunk (the connection to the router), one port gets VLAN 10, and the other VLAN 20. VLANs 10 and 20 match the encapsulation set on Branch-RTR for router on a stick.
All that needs to be configured on the VPCS hosts is the IP address and default gateway. This can all be done with a single command. For the VPCS on VLAN 10 I used “ip address 10.0.10.100 255.255.255.0 gateway 10.0.10.1” and for the VPCS on VLAN 20 I used “ip address 10.0.20.100 255.255.255.0 gateway 10.0.20.1”.
Branch-RTR Routing Table
After configuring all routers, the Branch-RTR router should learn about the 10.0.0.0/24 from both 192.168.1.5 (MPLS-RTR) and 172.16.1.5 (Internet-RTR).
To simulate one path being prefered over the other, I set the bandwidth on the link between Branch-RTR and MPLS-RTR to 10Kb on each side.
interface FastEthernet0/1 bandwidth 10
interface FastEthernet0/1 bandwidth 10
After doing this, Branch-RTR only puts the route from 172.16.1.5 into the routing table.
Also, when looking at the HQ-RTR router, only the path through 172.16.1.2 is in the routing table for networks 10.0.10.0/24 and 10.0.20.0/24.
Verifying The Connection Path With Traceroute
To verify that the VPCS machines are following the correct path to 10.0.0.1, we can use the trace command, which will run a traceroute. VPCS uses UDP by default for traceroute. To ensure we don’t get any error messages about ports being unreachable, we will specify ICMP as the protocol by adding “-P 1” to our trace command.
trace 10.0.0.1 -P 1
Creating The Route Map
While being an advanced topic and being able to quickly grow in complexity, route maps are a fairly simple concept. Route maps can be used for things such as route redistribution, NAT, and policy based routing to name a few. A route map consists of one or more “match” criteria, followed by “set” criteria. You can think of “match” and “set” as “if” and “then” statements. Essentially we are telling the router to parse this list of “match” criteria, and when a match is found something is “set”. Below are screenshots of the possibilities of “match” and “set”, showing how in-depth it can get.
Our objective is to route by the source address of a packet. To do this, we need to match the source IP address and set the next hop to MPLS-RTR rather than Internet-RTR. To match the source address of a packet, we can use “match ip” to match an extended access-list that allows us to specify source and destination addresses. To set the new next hop we can use “set ip next-hop” and specify a new next hop for the packet.
Policy based routing affects packets inbound. This means that we will have to configure policy based routing on the Branch-RTR router. First lets make the access list that will match traffic. We will use VLAN10 as the source network.
ip access-list extended VLAN10 permit ip 10.0.10.0 0.0.0.255 any
Our ACL is simple and allows any IP packet to be routed by source address. You can modify this for specific ports/protocols and source/destination combos. It quickly becomes apparent how strong route maps can be for manipulating traffic.
After the ACL is created we can create the route map. We will use the use the VLAN10 ACL as part of the match criteria, and the IP of the MPLS-RTR (192.168.1.5) since that currently is not the connection path for traffic to our test 10.0.0.0 network.
route-map SRC-ROUTE match ip address VLAN10 set ip next-hop 192.168.1.5
The interface that packets from 10.0.10.0/24 will enter the Branch-RTR inbound is interface f1/0.10.
interface f1/0.10 ip policy route-map SRC-ROUTE
The policy will take effect once it is applied to the interface. To test, we can traceroute from both VPCS machines, and see if VLAN10 takes a different path.
Success! We can see that packets from VLAN10 (10.0.10.0/24) take a different path than VLAN20 (10.0.20.0/24) when trying to get to the same destination.
Note that in our scenario, the packets coming back from 10.0.0.1 would take the connection through Internet-RTR (asymmetric routing) since HQ-RTR has no policy based routing configured and it’s routing table only has the next hop of 172.16.1.2 for network 10.0.10.0/24. If you wanted to making the return traffic take the same path, you would want to configure policy based routing on HQ-RTR as well. Here is a snippet of a packet capture between Internet-RTR and HQ-RTR to show that only the ICMP reply packets are seen and that the ICMP request packets (the ones sourced from 10.0.10.100) take the different path thanks to the policy based routing. Take this into consideration when you want to use policy based routing for setting the next hop IP.
While forwarding based on destination is how routing normally functions, it is possible to manipulate the process. Policy based routing with route maps can be used to manipulate packets as they enter a router. In this example, we had the router look at the source address of incoming packets and change the next hop IP if coming from a specific source network. Remember that policy based routing can create asymmetric routing, so care must be taken to ensure it is the best solution for the problem you are trying to solve.
Configurations from this post can be found on my GitHub page.