PBR: Configuring policy-based routing using route-map and ip sla monitor

I am using two routers to emulate client 1 and 2.

Client1#sh run | s int
interface FastEthernet0/0
ip address 192.168.1.10 255.255.255.0
no ip route-cache
duplex auto
speed auto

Client1#sh run | i no ip
no ip routing
no ip cef
no ip domain lookup

Client2#sh run | i no ip
no ip routing
no ip cef

Client2#sh run | s interface
interface FastEthernet0/0
ip address 192.168.1.20 255.255.255.0
no ip route-cache
duplex auto
speed auto

For 2651-1 the basic set up as follow:

2651-1#sh run | s inter
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
interface Serial0/0
bandwidth 1000
ip address 218.186.20.2 255.255.255.0
no fair-queue
interface Serial0/1
bandwidth 56
ip address 50.20.20.2 255.255.255.0

For 2651-2 ISP1

2651-2#sh run | i ip route
ip route 192.168.1.0 255.255.255.0 218.186.20.2

2651-2#sh run | s inter
interface Serial0/0
bandwidth 1000
ip address 218.186.20.1 255.255.255.0
no fair-queue
clock rate 1000000

For 2651-3 ISP2:

2651-3#sh run | i ip route
ip route 192.168.1.0 255.255.255.0 50.20.20.2

2651-3#sh run | s inter
interface Serial0/1
bandwidth 56
ip address 50.20.20.1 255.255.255.0
clock rate 56000

For simplicity you may want to copy and paste the above config into your routers.

To achieve the first objective: Client1 should only use ISP2 and if ISP2 is down, client1 should not be able to access the net. ISP2 is using a 56kbps link, so this link is not mission critical.

To manipulate the route, we can use route-map, and apply the route map using the interface based command: ip policy route-map this command only takes care of inbound traffic

Before applying route-map to interface fa0/0:

Client1#ping 50.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
Client1#ping 218.186.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 218.186.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Client1#

After applying the route-map to interface fa0/0:

Client1#ping 50.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Client1#ping 218.186.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 218.186.20.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

The path control is done at 2651-1, here’s the configuration

2651-1#sh run | s route-map
route-map policy-routing1 permit 10
match ip address client1-list
set ip next-hop 50.20.20.1

2651-1#sh run | s access-list
ip access-list standard client1-list
permit 192.168.1.10

2651-1#sh run | s int
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip policy route-map policy-routing1
duplex auto
speed auto

To verify:

2651-1#sh route-map
route-map policy-routing1, permit, sequence 10
Match clauses:
ip address (access-lists): client1-list
Set clauses:
ip next-hop 50.20.20.1
Policy routing matches: 10 packets, 1140 bytes

The second objective: client2 when using ssh and https, the traffic will be routed to ISP1. Otherwise ISP2 shall be used instead.

Testing from client5:

Client2#telnet 218.186.20.1 22
Trying 218.186.20.1, 22 …
% Connection refused by remote host

Connection refused was because 2651-2 did not set any vty login. But this shows the traffic has reached ISP1.

 

Client2#telnet 50.20.20.1 80
Trying 50.20.20.1, 80 … Open
^^^^

HTTP/1.1 400 Bad Request
Date: Sun, 19 Sep 2010 14:54:53 GMT
Server: cisco-IOS
Accept-Ranges: none

400 Bad Request

[Connection to 50.20.20.1 closed by foreign host]

This is because no ip http service has been set on ISP2, but it showed that it reached but because http service was not turned on on ISP2 hence dropped.

2651-1#sh route-map policy-routing1
route-map policy-routing1, permit, sequence 10
Match clauses:
ip address (access-lists): client1-list
Set clauses:
ip next-hop 50.20.20.1
Policy routing matches: 10 packets, 1140 bytes
route-map policy-routing1, permit, sequence 20
Match clauses:
ip address (access-lists): service-list
Set clauses:
ip next-hop 218.186.20.1
Policy routing matches: 14 packets, 1110 bytes
route-map policy-routing1, permit, sequence 30
Match clauses:
Set clauses:
ip next-hop 50.20.20.1
Policy routing matches: 10 packets, 600 bytes

Showed that there’s 10 packets on the third route-map sequence.

Client2#telnet 218.186.20.1 80
Trying 218.186.20.1, 80 …
% Destination unreachable; gateway or host down

Unreachable to ISP1 via port 80, because the route map has filtered away.

Client2#telnet 218.186.20.1 22
Trying 218.186.20.1, 22 …
% Connection refused by remote host

Because ssh was not turned on for ISP1, but it has reached ISP1.

2651-1#sh route-map
route-map policy-routing1, permit, sequence 10
Match clauses:
ip address (access-lists): client1-list
Set clauses:
ip next-hop 50.20.20.1
Policy routing matches: 10 packets, 1140 bytes
route-map policy-routing1, permit, sequence 20
Match clauses:
ip address (access-lists): service-list
Set clauses:
ip next-hop 218.186.20.1
Policy routing matches: 15 packets, 1170 bytes
route-map policy-routing1, permit, sequence 30
Match clauses:
Set clauses:
ip next-hop 50.20.20.1
Policy routing matches: 11 packets, 660 bytes

The sequence 20 clause showed that 1 more packet was increased.

Here’s the route-map commands in 2651-1:

2651-1#sh run | s route-map
route-map policy-routing1 permit 10
match ip address client1-list
set ip next-hop 50.20.20.1
route-map policy-routing1 permit 20
match ip address service-list
set ip next-hop 218.186.20.1
route-map policy-routing1 permit 30
set ip next-hop 50.20.20.1

2651-1#sh run | s inter
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip policy route-map policy-routing1
duplex auto
speed auto

We have achieved the first 3 objectives of the lab.

Let’s look at the last objective.

There’s a command that can affect path decision for traffic generated by the router, that is the global configuration command: ip local policy route-map, this command takes care of packet generated by the router itself, the command ip policy route-map is the command that only takes care of incoming packet to the interface.

Let’s review the last objective:

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.

Traffic originating from policy router which is 2651-1 should use ISP1 first, if ISP1 failed ISP2 will take over. Also verification is needed. For this to work we can use ip sla together with object tracking to check if isp is alive or not.

Step1: Set up IP SLA monitor, the command line is a bit different from Catalyst 3550. Then schedule IP sla probe.

2651-1#sh run | s ip sla
ip sla monitor 1
type echo protocol ipIcmpEcho 218.186.20.1
timeout 2000
frequency 5
ip sla monitor schedule 1 life forever start-time now

Step 2: Create a track object, using IP SLA probe to keep track.

2651-1#sh run | s track
track 1 rtr 1 reachability

The key word rtr is actually referring to IP SLA probe.

Step3: use the track object created and put into the route-map statement, I have created a different route-map to be used by the policy router only.

2651-1#sh run | s route-map
route-map policy-routing2 permit 10
set ip next-hop verify-availability 218.186.20.1 10 track 1
set ip next-hop 50.20.20.1

The number 10 is a sequence number inserted for the next hop address should the 218.186.20.1 is unavailable.

Step 4: Apply the route map to the router’s policy using ip local policy route-map command in global configuration mode.

2651-1(config)#ip local policy route-map policy-routing2

2651-1#sh route-map policy-routing2
route-map policy-routing2, permit, sequence 10
Match clauses:
Set clauses:
ip next-hop verify-availability 218.186.20.1 10 track 1  [up]
ip next-hop 50.20.20.1
Policy routing matches: 0 packets, 0 bytes

To test it, shut down serial 0/0 which is connected to ISP1:

2651-1(config)#int se0/0
2651-1(config-if)#shut
2651-1(config-if)#exit

*Mar  2 17:16:07.610: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down

2651-1#sh route-map policy-routing2
route-map policy-routing2, permit, sequence 10
Match clauses:
Set clauses:
ip next-hop verify-availability 218.186.20.1 10 track 1  [down]
ip next-hop 50.20.20.1
Policy routing matches: 0 packets, 0 bytes

2651-1#
*Mar  2 17:27:32.637: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down
2651-1#ping 50.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms

Only when ISP1 is unreachable will the path to ISP2 be used.

Bring up the serial0/0 interface again.

2651-1(config)#int se0/0
2651-1(config-if)#no shut
2651-1(config-if)#end

*Mar  2 17:17:18.466: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up

2651-1#ping 218.186.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 218.186.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
2651-1#ping 50.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.20.20.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
2651-1#

When the link to ISP1 is up, router will only use ISP1 hence the traffic to ISP2 are dropped.

Advertisements
This entry was posted in Path Control and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s