In order to understand this, we must first realize that the initial route-map simply didn’t match anything. When you create a route map that references an access list, the route map will match anything in the ACL that corresponds to a permit statement. Because the ACL has only deny statements, it simply matches nothing. Now as stated in the lesson:
Our first route-map statement doesn’t match anything
So nothing is matched, not even the 192.168.0.0/24 network. But since nothing is matched, it automatically goes to the next route map statement which is the implicit deny, so everything is denied, so you see nothing in the routing table. As noted in the lesson:
What confuses some people is that they think the “double negative” (deny in route-map and deny in access-list) means that it will match. That’s not how a route-map works.
In actuality, nothing is matched in statement 10, and everything is caught by the implicit deny any at the end of the route mpa.
Now, once the permit statement was added to the route map, everything was permitted. In other words, all four networks were permitted. Since 192.168.0.0/24 was not initially blocked by statement 10, it is matched in statement 20 and is permitted.
Okay, so I hope someone can relieve this confusion for me.
I am having a hard time understanding if ACL’s and Prefix List are treated the same way in relation to match statements for route maps, and I believe that comes down to understanding whether or not the “permit” or “deny” statement have any impact on the “permit” or “deny” of the route map.
I feel like the best way for this to be explained is in a manner similar to how trunking methods are, in a matrix (cross referencable table), with route map on top and ACL/Prefix List on the side. But yet I have never seen anyone do it that way…
Or if someone could say (this is my rough guess, I really do suck at route maps)…
ACL Permit RM Permit = Match criteria is matched and permitted
ACL Permit RM Deny = Match criteria is matched but RM deny statement
ACL Deny RM Permit = etc
ACL Deny RM Deny = etc
Sorry it’s late and I can’t think straight anymore. Any help you can provide to help me better understand what constitutes a matching vs the action taken would be appreciated. It seems like the route map permit or deny ultimately decides if the permit or deny in the ACL/Prefix list actually does what it says it does (permit or deny).
Yes, this is one of the confusing things about ACLs and route maps and how they interact. It’s not as simple as just creating a grid/table that states what will happen. Something that may help however is to remember the role of an ACL when it is used in conjunction with a route map.
An ACL that is called by a route-map does not permit or deny traffic! Because ACLs are fundamentally used to filter traffic on interfaces, by permitting or denying it, it is difficult for us to realize that their role is different when using a route map. Even the terminology of permit/deny doesn’t help us.
When used with a route map, an ACL is used only to match (or not match) traffic. Anything permitted by the ACL is matched, anything that is denied is not matched. Take a look at this NetworkLessons note on Route-maps and ACL matching for a detailed description.
Hi Rene and Laz,
First of all, you’re great! Very good and simple explanation
can you please drop down an example with the set vrf command ?
I’ve tried it in my case believing that once match works it will set automatically in the right VRF routing table.
ip vrf A
ip access-list standard permit_lo10
route-map lo10 permit 10
match ip address permit_lo10
set vrf A
router ospf 10
distribute-list route-map lo10 in
ip address 172.16.10.1 255.255.255.255
router ospf 10
network 172.16.10.1 0.0.0.0 area 0
I tried labbing this one up and I found that the VRF of the learned route 172.16.10.1 does not change. In other words, 172.16.10.1 when learned as an incoming route from R2 remains in the global routing table and not in the VRF A routing table. This occurs even though I do see matches on access list that is referenced by the route map.
Looking a bit deeper into it, it looks like the use of distribute lists will only filter routes, and will not set various attributes such as VRFs. Although this is not explicitly stated in Cisco documentation, it does hint at this in the following document:
Matching options include interface, IP address, IP next hop, IP route-source, metric, route-type, and tag.
The set vrf command used in route maps is typically used for VRF aware PBR. For more information about this and how it is used, take a look at this documentation:
Yes, this is an example where a route map is added to a particular neighbor peering. Any prefixes that are shared with that neighbor are fed through the route map, and the local preference is changed for anything that matches the prefix-list. You can see a similar configuration where a route map is used to change the local preference in this lesson:
A prefix list is not used in the case of the lesson, however, you can apply whatever filtering and match statements you want in the route map to achieve the local pref you want for particular prefixes.
Yes, I understand what you are saying. However, what if you want to deny only a single subnet? For example, let’s say you want to deny 10.10.10.0/24 and permit everything else. In order to achieve this with the implicit deny, you must permit the range of addresses from 0.0.0.0 to 10.10.9.255, and 10.10.11.0 to 255.255.255.255. That is much more difficult than simply denying 10.10.10.0/24 and then permitting all.
The same is true for all constructs that work with these types of sequential statements, such as access lists as well.
I suggest you first take a look at this documentation about NAT and multicast to get a better idea of how the two features function and interact. If you have further questions, feel free to share them with us here and we will help you further.
Thanks for the suggestion and link to study.
And then I tried according to the link, please see the below my config.
> ip nat pool pool-108 220.127.116.11 18.104.22.168 prefix-length 30
ip nat pool pool-118 22.214.171.124 126.96.36.199 prefix-length 30
ip nat inside source route-map MAP-108 pool pool-108
ip nat inside source route-map MAP-118 pool pool-118
access-list 108 permit ip 192.168.1.0 0.0.0.255 188.8.131.52 0.0.0.255
access-list 108 permit ip host 192.168.1.1 host 184.108.40.206
access-list 118 permit ip 192.168.1.0 0.0.0.255 220.127.116.11 0.0.0.7
access-list 118 permit ip host 192.168.1.1 host 18.104.22.168
route-map MAP-108 permit 10
match ip address 108
route-map MAP-118 permit 10
match ip address 118
But still the same error. NAT is working fine in unicast traffic (ping) but NAT is not working in multicast traffic (received multicast traffic with original source ip).
According to customer’s requirement, I must use one to one static NAT.
Before adding the second multicast traffic 22.214.171.124 (NAT to 126.96.36.199), there is only one multicast traffic 188.8.131.52 (NAT to 184.108.40.206). At that time NAT is working fine for both unicast and multicast traffic.