Policy Based Routing

192.168.10.0/24 .2 200.1.1.0/24 .20

ISP1

Server1

.1

PBR
.21

.1

201.1.1.0/24

Server2

.2

ISP2

Objectives: 1. Server1 surfs the internet all day doing nothing productive. All traffic from this server should route out ISP2, which is a slower internet connection. If ISP2 is down, Server1 should not be able to access the Internet. 2. Server2 handles sophisticated transaction. Both Telnet and HTTPS traffic should route towards ISP1, which is a more reliable connection. All other traffic from Server2 should route out ISP2. 3. Traffic from other clients (not shown in this diagram) should route out ISP2. 4. Traffic originating from PBR should prefer ISP1 but should fail over to ISP2 should ISP1 be unavailable. Verify ISP1 is available using proactive testing techniques. To accomplish these objectives, you must create no more than two route-maps and three access-lists.

ISP1

Server1

PBR

Server2

ISP2

Testing: 1. Telnet from Client1 to ISP2 (201.1.1.2). The telnet session should connect to the ISP router; likewise, you should be able to verify traffic by using the show route-map command on the PolicyRouter. You can also verify by traffic by viewing the logging buffer on ISP2. Performing a telnet session to ISP1 (200.1.1.2) should fail (simply because ISP1 and ISP2 have no knowledge of each other). 2. Telnet from Client2 to ISP1 (200.1.1.2) using TCP port 23 and 443 (telnet 200.1.1.2 443). Both sessions should connect. You can validate the path used through the same process as Client1. Telnet to ISP2 using TCP port 80 (telnet 201.1.1.2) to validate alternate path routing. Telnetting to ISP2 using port 23 or 443 should fail (since traffic will be policy routed to ISP1 who has no knowledge of ISP2). 3. To test traffic originating from the router, issue pings to ISP1 (these should succeed), then ping ISP2 (these should fail). Verify that ISP1 received the packets by viewing the logging buffer. Shut down the interface to ISP1 and then ping ISP2; the pings should succeed.