Path Control: Implementation and Verification.

In this update I will explore how to implement and verify path control.

Topology

Base Config Overview can be downloaded here.

What is Path Control?

Path Control can be used to change a default IP routing decision. You can use Policy Based Routing (PBR) to selectively cause packets to take different paths based on source address, protocol type or application type. Effectively overriding the router’s normal routing behavior.

Configuring PBR involves configuring a route map with match and set commands and then applying the route map to the interface.

I will be implementing the following policies:

  1. All traffic coming from R4 Lo4 to R1 Lo1, must take the path R3 -> R2 -> R1.
  2. All traffic coming from R4 Lo5 to R1 Lo1, must take the path R3 -> R1.

Before we move on, let’s first take a look at the current path selection for this traffic.

R4#traceroute 192.168.1.1 source 192.168.4.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 28 msec 28 msec 16 msec
2 172.16.23.2 32 msec 20 msec 20 msec
3 172.16.12.1 32 msec * 28 msec

R4#traceroute 192.168.1.1 source 192.168.4.129

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 44 msec 36 msec 32 msec
2 172.16.23.2 28 msec 20 msec 20 msec
3 172.16.12.1 32 msec * 32 msec
R4#

We can see both flows go R3 -> R2 -> R1. If you look at the topology above, you can see that this is because these routers are using a faster link, thus it is the preferred path.

You can verify this by looking at  the topology information on R3.

R3#sh ip eigrp topology 192.168.1.0
IP-EIGRP (AS 1): Topology entry for 192.168.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21152000
Routing Descriptor Blocks:
172.16.23.2 (Serial0/2), from 172.16.23.2, Send flag is 0x0
Composite metric is (21152000/20640000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 45000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
172.16.13.1 (Serial0/1), from 172.16.13.1, Send flag is 0x0
Composite metric is (40640000/128256), Route is Internal
Vector metric:
Minimum bandwidth is 64 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

You can see that the route over Serial 0/2 has a lower feasible distance, ergo it will be the preferred route.

So let’s manipulate this routing decision with Policy Based Routing.

First I will configure an Access-list on R3 for the traffic coming from R4 Lo5

R3#sh access-lists
Extended IP access list PBRACL
10 permit ip 192.168.4.128 0.0.0.127 192.168.1.0 0.0.0.255

And then I will create a route-map that will match the access-list and will change the next-hop interface to R1’s instead of R2.

R3#sh route-map
route-map R3->R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBRACL
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 0 packets, 0 bytes

Okay, that is looking good. There have not yet been any matches because it has not yet been assigned to an interface. We’ll do that now:

R3#sh run int se 1/1
Building configuration…

Current configuration : 174 bytes
!
interface Serial1/1
description R3 –> R4
bandwidth 64
ip address 172.16.34.3 255.255.255.248
ip policy route-map R3->R1
serial restart-delay 0
clock rate 64000
end

Okay, now let’s verify the proper operation of our new route-map.
We can use “debug ip policy” on R3 to identify the traffic being matched by our route-map.

First I’ll configure two access-list to match the traffic from Both R4 Lo4 and Lo5.

 R3(config)#access-list 1 permit 192.168.4.0 0.0.0.255

And then enable the debugging.

R3# debug ip policy 1
Policy routing debugging is on for access list 1

Running a trace from Lo4 …

R4#traceroute 192.168.1.1 source 192.168.4.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 16 msec 28 msec 20 msec
2 172.16.23.2 28 msec 20 msec 20 msec
3 172.16.12.1 32 msec * 32 msec

On R3 I can see the packets being forwarded normally:

R3#
*Mar 1 01:26:37.611: IP: s=172.16.12.1 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) – normal forwarding
R3#
*Mar 1 01:26:40.643: IP: s=172.16.12.1 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) – normal forwarding

Now let’s try Lo5:

R4#traceroute 192.168.1.1 source 192.168.4.129

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 36 msec 32 msec 20 msec
2 172.16.13.1 28 msec * 24 msec

Looks like that traffic is taking the intended path! What about our debug output on R3?

*Mar 1 01:44:17.947: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, len 28, FIB policy match
*Mar 1 01:44:17.947: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
*Mar 1 01:44:17.971: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, len 28, FIB policy match
*Mar 1 01:44:17.975: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed

Perfect, we can see the policy being matched and our traffic being rerouted.

R3#show route-map
route-map R3->R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBRACL
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 3 packets, 96 bytes

And the counters on R3’s route-map are going up.
We have successfully implemented and verified Path Control.

References:
Route-maps Configuration.
IP Access-lists.
Cisco Policy Based Routing.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s