Policy-Based Routing Lab

Objectives:
1. Your organization is implementing a dual ISP setup should be tightly controlled. They have requested the following
parameters:

Client1 surfs the Internet all day doing nothing productive. All traffic from this client should route out ISP2,
which is a slower Internet connection. If ISP2 is down, Client1 should not be able to access the Internet.

Client2 handles sophisticated transactions. Both Telnet and HTTPS traffic should route towards ISP1, which is the
more reliable connection. All other traffic from Client2 should route out ISP2.

Traffic from other clients (not shown in this diagram) should route out ISP2.

Traffic originating from the PolicyRouter 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 may create no more than two route-maps and three access-lists.
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.