Cisco Policy Based Routing on L3 Switch

In this guide, I will show how to implement basic Policy Based Routing on a Layer 3 Switch.

Here is the topology we will work on:

In this scenario, we have two routers connected to a core switch. We then have some clients in Vlan 30 attached to the switch.

We will manipulate the Core Switch in order to route traffic from 10.0.101.60 (PC1) to R2 instead of following the default route to R1.

Configuration

Lets have a look at the current routing table on the Core Switch:

Core-SW#sh ip route | beg Gateway
Gateway of last resort is 10.0.1.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.0.1.2
      10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
C        10.0.1.0/30 is directly connected, Vlan10
L        10.0.1.1/32 is directly connected, Vlan10
C        10.0.2.0/30 is directly connected, Vlan20
L        10.0.2.1/32 is directly connected, Vlan20
C        10.0.101.0/24 is directly connected, Vlan30
L        10.0.101.254/32 is directly connected, Vlan30

As we can see above, any traffic not matching a more specific route in the table, will be routed towards 10.0.1.2 which is the IP address of R1's G0/0 interface as per the default route.

In order to force traffic from PC1 to take the alternate path via R2, we need to configure an access-list to match and then a route map to set.

We can use a standard access-list as we only need to match on the source IP. However, you can use an extended ACL to match on more specific destination information if required.

Core-SW(config)#access-list 20 permit 10.1.101.60

Core-SW(config)#route-map PC1_PBR_R2
Core-SW(config-route-map)#match ip address 20
Core-SW(config-route-map)#set ip default next-hop 10.0.2.2

In the above we have created the ACL and the route-map. The route map is matching the IP address within the ACL and then setting the default next-hop. There is a similar command that doesn't include the word 'default'. In this scenario we have used 'default next-hop' so that traffic is only routed to the specified next hop when it doesn't match another specific route. Doing this ensures that the client can still communicate with other subnets and Vlans that may be connected to the Core Switch. Using the other method would route ALL traffic to that next hop, including traffic destined for other Vlans on the local switch. This would result in issues and most likely cause loss of connectivity.

Now we need to apply the route-map to an interface. In this topology, the route-map wants to be added to the Vlan 30 SVI because this is where the traffic will ingress:

Core-SW(config)#int vlan 30
Core-SW(config-if)#ip policy route-map PC1_PBR_R2

The configuration has now been done for the PBR setup. Time to test it!

Testing

First, we can enable debugging for PBR on the core switch:

Core-SW#debug ip policy 
Policy routing debugging is on

Now, lets come onto PC1 and try pings to 10.0.1.2 (R1), 10.0.2.2 (R2) and then 8.8.8.8 to match the default route:

PC1> ping 10.0.1.2 -c 1

84 bytes from 10.0.1.2 icmp_seq=1 ttl=254 time=20.956 ms

PC1> ping 10.0.2.2 -c 1

84 bytes from 10.0.2.2 icmp_seq=1 ttl=254 time=22.419 ms

PC1> ping 8.8.8.8 -c 1 

*10.0.2.2 icmp_seq=1 ttl=254 time=16.609 ms (ICMP type:3, code:1, Destination host unreachable)

As we can see, the pings to the two internal routers succeed, this is expected and means that the PBR is only taking effect when the default route is used. We can see when pinging 8.8.8.8 (which isn't in the routing table aside from the default route) we get a ICMP destination unreachable from 10.0.2.2. This is a good sign as it came from R2. Lets see what the switch has to say:

*Mar 30 20:46:18.818: IP: s=10.0.101.60 (Vlan30), d=10.0.1.2, len 84, FIB policy match
*Mar 30 20:46:18.818: IP: s=10.0.101.60 (Vlan30), d=10.0.1.2, len 84, PBR Counted
*Mar 30 20:46:18.818: IP: s=10.0.101.60 (Vlan30), d=10.0.1.2, len 84, FIB policy rejected(explicit route) - normal forwarding

*Mar 30 20:46:23.336: IP: s=10.0.101.60 (Vlan30), d=10.0.2.2, len 84, FIB policy match
*Mar 30 20:46:23.336: IP: s=10.0.101.60 (Vlan30), d=10.0.2.2, len 84, PBR Counted
*Mar 30 20:46:23.336: IP: s=10.0.101.60 (Vlan30), d=10.0.2.2, len 84, FIB policy rejected(explicit route) - normal forwarding

*Mar 30 20:46:34.997: IP: s=10.0.101.60 (Vlan30), d=8.8.8.8, len 84, FIB policy match
*Mar 30 20:46:34.997: IP: s=10.0.101.60 (Vlan30), d=8.8.8.8, len 84, PBR Counted
*Mar 30 20:46:34.997: IP: s=10.0.101.60 (Vlan30), d=8.8.8.8, g=10.0.2.2, len 84, FIB policy routed

From the above output, we can see the pings to R1 and R2 matched the PBR route-map but were rejected because a more explicit route was found. As for the ping to 8.8.8.8, this was policy routed.

If we try the same pings from PC2, we should see them succeed for R1 and R2 and this time the ping to 8.8.8.8 will follow the default route as normal to R1 as PC2 will not be caught by the ACL:

PC2> ping 10.0.1.2 -c 1

84 bytes from 10.0.1.2 icmp_seq=1 ttl=254 time=13.930 ms

PC2> ping 10.0.2.2 -c 1

84 bytes from 10.0.2.2 icmp_seq=1 ttl=254 time=14.105 ms

PC2> ping 8.8.8.8 -c 1 

*10.0.1.2 icmp_seq=1 ttl=254 time=10.273 ms (ICMP type:3, code:1, Destination host unreachable)

Looking on the Core Switch:

*Mar 30 20:53:55.150: IP: s=10.0.101.61 (Vlan30), d=10.0.1.2, len 84, FIB policy rejected(no match) - normal forwarding
*Mar 30 20:53:59.677: IP: s=10.0.101.61 (Vlan30), d=10.0.2.2, len 84, FIB policy rejected(no match) - normal forwarding
*Mar 30 20:54:05.419: IP: s=10.0.101.61 (Vlan30), d=8.8.8.8, len 84, FIB policy rejected(no match) - normal forwarding

As we can see, these have all been rejected as they didn't match and normal forwarding has occurred as expected!

Make sure to turn off the debugs!

Note: This may cause asymmetric routing if you don't control traffic coming back into the network!