route-map on svi

[Amafsha1]

Hello I'm a little confused about this route-map on this interface vlan 999.

So if i'm understanding this correctly, anything that wants to come into int vlan 999 with a source address that is in the "force-out-fw" acl which consists of the "permit-out-fw" and "internal-networks" ACLs it will be denied from entering this interface vlan 999. the 2nd part of the route-map is saying that anything with a source address that is in
the "ACL_PERMIT" acl will be have to be redirected to 172.21.5.1? Am I on the right page here?

NexusCore#
interface Vlan999
no shutdown
no ip redirects
ip address 172.27.250.2/24
no ipv6 redirects
ip router eigrp 1
ip passive-interface eigrp 1
ip policy route-map PBR11
hsrp version 2
hsrp 300
priority 105 forwarding-threshold lower 1 upper 105
ip 172.27.250.1

NexusCore# sh route-map PBR11
route-map PBR11, deny, sequence 10
Match clauses:
ip address (access-lists): FORCE-OUT-FW
Set clauses:
route-map PBR11, permit, sequence 20
Match clauses:
ip address (access-lists): ACL_PERMIT
Set clauses:
ip next-hop 172.21.5.1

IP access list FORCE-OUT-FW
10 permit ip addrgroup Permit-Out-FW addrgroup INTERNAL-NETWORKS

object-group ip address Permit-Out-FW
10 host 172.27.250.151
20 host 172.28.24.5
25 host 172.28.24.237
30 host 172.28.24.239

object-group ip address INTERNAL-NETWORKS
10 10.99.0.0/16
20 10.0.0.0/24
30 10.1.0.0/23
40 10.24.0.0/16
50 10.124.0.0/16
60 10.151.0.0/16
70 10.200.0.0/16
80 172.16.0.0/12
90 192.168.0.0/16

ip access-list ACL_PERMIT
10 permit ip 172.27.250.151/32 any
11 permit ip 172.28.24.5/32 any

[paul driver]

Hello

---

@Amafsha1 wrote:

so sequence 10 does absolutely nothing right?  I can just delete it?

---

Looks like seq 10  is doing something, i can see at least one action which is its denying traffic being PBR for between 172.27.250.151 and Internal networks object group 

[Richard Burts · Accepted solution]

If the original poster deletes instance 10 of the route map then things will definitely change. If you look at the acl used in the second instance

ip access-list ACL_PERMIT
10 permit ip 172.27.250.151/32 any
11 permit ip 172.28.24.5/32 any

The 2 host addresses here also appear in the acl for instance 10. The way it works now is that traffic from these two hosts with destination Internal networks gets normal routing and traffic from these hosts to other destinations gets policy routed. If instance 10 is removed then traffic from these hosts to Internet networks will be policy routed. That is a significant change in behavior.

Bottom line: leave the route map the way that it is.

HTH

Rick

[Amafsha1]

Thank you Richard.  Let's say that the host source:172.27.250.151 wants to talk to host destination:172.28.24.209.  So you're saying that this will get policy routed because this address of 172.28.24.209 is not specified in the deny sequence 10 ACLs correct?

so whatever address that is not specified in the deny sequence 10 ACLs, will move down to hit the permit sequence 20 and get policy routed?

[Richard Burts]

Actually if you look carefully you will find that 172.28.24.209 is covered in the deny acl in sequence 10.    In the deny acl there is an entry for

172.16.0.0/12

With a 12 bit mask (255.240.0.0 or 0.0.15.255 if you think of acl wildcard mask) it covers addresses from 172.16.0.0 through 172.31.255.255. Since there is a matching entry in the deny acl in sequence 10 traffic between those two hosts will not be policy routed.

You are correct in your summary of the logic that anything that does not match the acl in sequence 10 will drop down and be evaluated by the logic in sequence 20.

HTH

Rick

[Amafsha1]

oh my goodness, I did not see that 12 there! I thought it was a /16.  Ok so that must be why host 172.28.24.209 cannot talk to 172.27.250.151.  this is what stemmed this tshoot.

Thanks Richard!

[Richard Burts]

I am glad that my response was able to clarify the issue.

I am not clear why the hosts are not able to communicate. But it is clear that policy routing is not the issue.

HTH

Rick