Lab setup:

What we are trying to accomplish:

Configure the interfaces based on the topology table above.
Set up 2 VLANS (12, 13) on our core switch.
VLAN 12 SVI will belong to network 10.0.12.x/24 with x representing the router number.
VLAN 13 (Guest Wireless) SVI will belong to network 10.0.13.x/24 with x representing the router number.
The switch will have .1 for all of these subnets.
VLAN 1 will be an SVI as well with the subnet 10.24.35.x/24.
VLAN '1's' SVI will connect to R4 and R5 respectively.
We will have a default route pointing to R4.
R4 and R5 will have a default route pointing back to the switch.
This simulates a default route that we would have on our core switch out to our ISP (R4). R5 can act as our second ISP.
R3 will be in our Guest Wi-Fi VLAN 13.
Let's say our link on our Core Switch going out to our Primary ISP (R4) has a link speed of 100 Mbps.
And our link to R5 (Secondary ISP) has an old T1 connection with a speed of 1544 Kbps.
We want to have our guest Wi-Fi traffic from VLAN 13 take the T1 link via R5, but our default route is pointing to R4.
Our goal is to take the VLAN 13 traffic and have it go through the secondary circuit (R5) without messing with the routing on our Switch in any way.
We can do this using Policy Based Routing (PBR).
When we first configure SW1, R2, and R3, R2 and R3 will only be able to reach the outer Interface of R4 (10.4.6.4) because of the Default routes on the routers pointing to our core switch and the switch's default route pointing to R4.
But they will not be able to reach R5 at this point, of course.
On R4 and R5, all we need to do is set up a default route going back to the switch.
We will configure R2 and R3's interfaces and give them a default route pointing to the switch.
Before the policy-based routing.
When R2 and R3 try to ping R4, the traffic will go out the regular default route and come right back and succeed.
But when they both try to reach R5's outside interface, it once again goes out to R4 based on the default route and comes right back to the switch and then back to R4, causing a loop as R4 does not know how to reach R5.
We can confirm by pinging 10.4.6.4 (R4's outside interface) from R2 and R3.
From R2

From R3

And when we traceroute 10.5.7.5 (R5's outside interface) from R2 and R5, we can see the continuous loop between the Core Switch and R4.

Setting up PBR:

Before we setup PBR let's checkout the routing table on our core switch We can see the default gateway pointing to R4

Now we need to set up PBR to achieve our goal of having traffic from R3 (Guest Wi-Fi) and override the default route on the switch and go directly to R5.
We will use an extended access-list GUEST-R5 or any name that stands out.
Within extended access-list config mode, we will permit VLAN 13 traffic 10.0.13.0/24 destination of any.
Now we need to create a route-map (which is our PBR), and we will use the same name as the ACL GUEST-R5.
The sequence number tells the route-map in what order to process the policy.
Once we are in the route map, we need to match a criteria, which is our ACL. Match IP address [ACL].
So, when the Core switch sees traffic coming in and the source address is 10.0.13.0/24, it will apply what we say to set.
Now we need to set the IP next-hop address of R5.
So, what we are saying is any traffic that is matched in the route-map, which refers to the ACL, we want to change or override the next-hop address to send the traffic to R5.
The final thing we need to do is to apply the policy to the interface. In this case, we will apply it to the VLAN 13 SVI.
After the policy-based Routing, the ping and trace from R3 to R5 will succeed based on the policy we set up.
On R2, if we do the trace to R5, we will still get an endless loop because we did not create a policy and attach it to VLAN 12, so it goes based on what is in the RIB, which is the default route out to R4.

1 Fundamentals 3 Configs