Policy based routing issue

[hfakoor222]

Doing a lab ~

When applying an ACL to policy based routing it is working as intended. When applying a prefix-list that is supposed to be matching the same subnet it is not.  R3 is applying PBR.

R4 has two loopback:

L4:  192.168.4.1/25

L5: 192.168.4.128/25

interface Loopback4
description R4 LAN A
ip address 192.168.4.1 255.255.255.128
!
interface Loopback5
description R4 LAN B
ip address 192.168.4.129 255.255.255.128

With prefix list it seems to be matching everything and everything is routed to next hop, where I am only wanting to set next hop for Loopback 5:

Router R3

interface Serial0/2
description R3 --> R4
bandwidth 64
ip address 172.16.34.3 255.255.255.248
ip policy route-map ROUTE_LAN2
serial restart-delay 0

ip prefix-list R4_LAN2 seq 15 permit 192.168.4.128/25 le 32

route-map ROUTE_LAN2 permit 5
match ip address prefix-list R4_LAN2
set ip next-hop 172.16.13.1
!

With this configuration both L4 and L5 get next hop applied in PBR:

Now I try ACL and it does what I want:

interface Serial0/2
description R3 --> R4
bandwidth 64
ip address 172.16.34.3 255.255.255.248
ip policy route-map R3-to-R1
serial restart-delay 0

route-map R3-to-R1 permit 10
match ip address PBR-ACL
set ip next-hop 172.16.13.1

R3#show access-lists
Standard IP access list PBR-ACL
10 permit 192.168.4.128, wildcard bits 0.0.0.127 (12 matches)

Here is the result I get what I want:

I revert to prefix-list PBR:

interface Serial0/2
description R3 --> R4
bandwidth 64
ip address 172.16.34.3 255.255.255.248
ip policy route-map ROUTE_LAN2
serial restart-delay 0

R3#show ip prefix-list
ip prefix-list R4_LAN2: 1 entries
seq 15 permit 192.168.4.128/25 le 32

Result is not what I want:

I seem to be misapplying the prefix list., at least this is my opinion.

Any suggestions on what i may be doingt wrong with the prefix list and how to fix it?

[David Ruess]

Hello,

PBR uses the functionality of Standard/Extended ACLs. I don't believe there is support for a prefix list. My best guess is if you match on a standard ACL you matching on the source (since that all you can supply) and if you use an extended ACL you're matching on source/destination. With a prefix list you're just identifying a network, not a source or destination. The router wont know how to handle that. Prefix lists are usually meant to identify network for filtering in routing protocols and not match on a source/destination of anything.

Hope that helps.

-David

[balaji.bandi]

In addition to @David Ruess 

Generally prefix-list used to match most cases in Routing protocols where it required to match conditions to ge or le conditions.

PBR you can use prefix list but its not that as effective compare to ACL standard and extended where you need to match the subnets

if you looking only to match the traffic of loopback you can use /32 subnet instead of le 32  or just match the host entry - you can try and test it.

Also we use PBR to match some time based on the destination we use next hop, not always source only.

[MHM Cisco World]

https://www.ciscopress.com/articles/article.asp?p=1613547&seqNum=4

According to ciscopress you can use both, this time pbr not prefix filter and we common use acl not prefix for pbr but anyway

Let me check it

MHM

[MHM Cisco World]

show route-map  <pbr name>

Debug ip policy 

Share the output of both command in both case using acl and using prefix list

MHM

[MHM Cisco World]

I receive error when try apply pbr under the interface, 
so I seem that not all Cisco IOS support prefix list as match in PBR 
MHM

[Giuseppe Larosa]

Hello @hfakoor222 ,

>> With prefix list it seems to be matching everything and everything is routed to next hop, where I am only wanting to set next hop for Loopback 5:

The prefix-list matches a prefix in the IP routing table regardless of user traffic flows, for this reason the IP ACL is the right match tool for PBR applications.

With ACL the user traffic is checked against the ACL permit statement permitted traffic is redirected.

Hope to help

Giuseppe

[hfakoor222]

For anyone wondering

I tried changing the prefix-list to ip prefix-list to

ip prefix-list R4_LAN2 seq 15 permit 192.168.4.129/25

erased it and then

ip prefix-list R4_LAN2 seq 15 permit 192.168.4.129/32

same result

then added a seq 10to deny Loop 4:

ip prefix-list R4_LAN2 seq 10 deny 192.168.4.1/32

p prefix-list R4_LAN2 seq 15 permit 192.168.4.129/32

All the same results

then

clear route-map counters ROUTE_LAN2

and erased the prefix list so all it had was implicit deny all same behavior:

R4#trace 192.168.1.1 source L5
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.34.3 25 msec 31 msec 30 msec
2 172.16.13.1 62 msec 59 msec 61 msec
R4#
R4#trace 192.168.1.1 source L4
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.34.3 24 msec 29 msec 28 msec
2 172.16.13.1 62 msec 77 msec 80 msec

R3#show route-map
route-map R3-to-R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBR-ACL
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 0 packets, 0 bytes
route-map ROUTE_LAN2, permit, sequence 5
Match clauses:
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 12 packets, 384 bytes

It seeming like in all cases it wasn't matching my prefix lists. Strange to me.

[MHM Cisco World]

Use prefix-list in route-map

The  remove ip policy route-map and add it again do you see any error message?

I think you add pbr under interface then config pbr wit match prefix-list 

It seem accpet by router but in real it not.

MHM

[Giuseppe Larosa · Accepted solution]

Hello @hfakoor222 ,

prefix-lists have been introduced to perfom route filtering they act on the control plane and not on the data plane.

PBR works on the data plane so you should use ACLs not prefix-lists  for the match condition

Hope to help

Giuseppe

[MHM Cisco World]

@hfakoor222 did you get error when you add PBR under interface ?
MHM

[hfakoor222]

No error, it just did not work right. What Mr. larosa mentioned with prefix list being in control plane may be the issue.   

No error, the PBR just wasn't working right.