One more query referring to the first row of table with combination of permit/deny.
When i am doing Labs i see if permit statement have a match it still checks for the next route-map. So I am confused with the 3rd column where it says if a match is there it will not look further route-map statements.
Example:
R2#show ip access-lists
Standard IP access list permit_L0
10 deny any (6 matches)
Standard IP access list permit_L1
10 permit 192.168.1.0, wildcard bits 0.0.0.255 (3 matches)
R2#show route-map
route-map permit_L0_L1, permit, sequence 10
Match clauses:
ip address (access-lists): permit_L0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map permit_L0_L1, permit, sequence 20
Match clauses:
ip address (access-lists): permit_L1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R2#show runn | sec eigrp
router eigrp 10
distribute-list route-map permit_L0_L1 in
network 0.0.0.0
A route-map will indeed stop processing route-map statements whenever a match is achieved. Now a route map has a particular behaviour when applied to redistribution. First of all, as stated in this Cisco documentation:
If you use an ACL in a route-map permit or deny clause, and the ACL denies a route, then the route-map clause match is not found and the next route-map clause is evaluated.
So a match of your permit_L0 ACL will not result in a match for sequence 10 of your route map.
The second thing you should know is that when a route map is used for redistribution, as is the case here, the show route-map command will not show matches of the route map statements. Only policy routing matches will be displayed.
So. is this because my permit_L0 ACL does not have permit statement that matches?
But, i have noticed even if i add a permit statement in my ACL with a match, it still checks the next route-map statement.
I have two routers R1 and R2, R1 is advertising everything via EIGRP
and on R2 using distribute list in to filter routes.
Example:
R2#show ip access-lists
Standard IP access list permit_L0
10 permit 192.168.0.0, wildcard bits 0.0.0.255 (1 match)
Standard IP access list permit_L1
10 permit 192.168.1.0, wildcard bits 0.0.0.255 (2 matches)
R2#show route-map
route-map permit_L0_L1, permit, sequence 10
Match clauses:
ip address (access-lists): permit_L0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map permit_L0_L1, permit, sequence 20
Match clauses:
ip address (access-lists): permit_L1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R1#show ip int brief | i up
Ethernet0/0 192.168.12.1 YES NVRAM up up
Loopback0 192.168.0.1 YES NVRAM up up
Loopback1 192.168.1.1 YES NVRAM up up
Loopback2 192.168.2.1 YES NVRAM up up
Loopback3 192.168.3.1 YES NVRAM up up
R1#show runn | sec eigrp
router eigrp 10
network 0.0.0.0
Output:
Permitting 2 subnets: 192.168.0.0 0.0.0.255 and 192.168.1.0 0.0.0.255
From this I see the EIGRP in R2 only accepted L0 and L1 routes from R1.
R2#show ip route eigrp
D 192.168.0.0/24 [90/409600] via 192.168.12.1, 00:00:16, Ethernet0/0
D 192.168.1.0/24 [90/409600] via 192.168.12.1, 00:14:26, Ethernet0/0
So just to review, you have R1 and R2 connected, and are EIGRP neighbors. You have networks 192.168.0.0/24 and 192.168.1.0/24 that appear on R1, and are being advertised to R2 via EIGRP. You have created two access lists that match these networks, and a route map that references these networks and matches them. Finally, a distribute-list references the route map in an inward direction but doesnāt seem to filter out the routes.
I went into the lab and reproduced your config and I finally saw what I was missing:
You need a deny statement in the route map for every prefix you want to block, so your first route map statement should be deny, to deny the permit_L0 access list.
If you want to deny the prefixes in the permit_L2 access list, then you must make that statement in the route map deny as well.
You must have an empty permit statement at the end of the route map otherwise, all your prefixes will be denied.
So in the above configuration you shared, you are permitting both subnets, and denying everything else. This is why you see the subnets being advertised.
Take a look at this lesson which includes similar examples to what you have been doing.
Thanks again for your response. I am advertising 4 networks from R1 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 and with the shared configuration R2 is accepting first 2 networks and denying other two. So, I still donāt fully understand below statement
my understanding tells me it should not go to the next route-map statement but I see it is going to the next route-map statement and also allowing the second network and denying the 3rd and 4th network via the implicit deny route-map statement.
I also tried with first deny statement I still see all the route-map statement where executed.
Apologies if I a missing something basic.
R2#show ip access-lists
Standard IP access list permit_L0
10 permit 192.168.0.0, wildcard bits 0.0.0.255 (6 matches)
Standard IP access list permit_L1
10 permit 192.168.1.0, wildcard bits 0.0.0.255 (1 match)
R2#show route-map
route-map permit_L0_L1, deny, sequence 10
Match clauses:
ip address (access-lists): permit_L0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map permit_L0_L1, permit, sequence 20
Match clauses:
ip address (access-lists): permit_L1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R2#show ip route eigrp
Gateway of last resort is not set
D 192.168.1.0/24 [90/409600] via 192.168.12.1, 00:11:35, Ethernet0/0
No problem, this is an opportunity to clarify things for both you and all our readers.
When we say that the route map will stop processing whenever a match is achieved, for your particular scenario, this is the case for each individual prefix.
So you have 192.168.0.0/24. It goes through the route map statements and matches sequence number 10. It is denied, but it was a match, so no more statements are checked.
Next, we have 192.168.1.0/24. It goes through the route map statements and matches sequence number 20, and is permitted, so this appears in the routing table of R2. This was a match, so no more statements are checked.
Next, we have 192.168.2.0/24. It goes through the route map statements and doesnāt match anything, but is caught by the deny all at the end, so it doesnāt go through.
192.168.3.0/24 does the same thing as the previous one.
So you see, for each prefix, the route map does stop processing statements once a match is made.
I just subscribed. simple and straight forward, Great site!
I was going through filtering routes using route-map. I noticed after creating route-map TEST_4 as an example to break the implicit deny at the end of a route map, you forgot to apply the router map to EIGRP 1.
R2(config)#router eigrp 1
R2(config-router)#distribute-list route-map TEST_4 in
Welcome to the site! Glad to hear that you find the content helpful.
Thanks for pointing this out. It seems that Rene has applied the route-map but has used an incorrect name. He used DENY_4 instead of TEST_4. I will let him know to make the correction. If that was done correctly in the first place, itās unnecessary to reapply it in the EIGRP distribute-list command, as this command will already have been implemented.
In the example with the Route-map Deny and the access-list Deny ā If 192.168.0.0 MATCHES the deny statement in the access list, why is it getting processed by the second route-map permit all statement? Once someone hits a match it should not be processed any further.
please explain in as much detail as possible why a route-map deny with an access-list that specifies a subnet, can be undermined by a permit statement at the end.
Having access lists with deny statements that are being used in match statements for route maps using deny statements again can get confusing. Iāll try to clarify for you.
Here we have an access list named R1_L0_DENY that denies 192.18.0.0/24. It also denies everything else because of the explicit deny at the end.
Now the route map called TEST_4 tries to match IP addresses within the R1_L0_DENY access list. But a route map will match only whatever is permitted by the called ACL. Since the R1_L0_DENY ACL in essence denies everything, this will never result in a match for the route map. Thus, it goes on to the next statement, which in this case is the implicit deny at the end of the route map. Thus the route map matches nothing, thus everything is denied, rather than just denying the single route that we wanted.
This is a particular behaviour of ACL/route map interaction that is further described in this post, with appropriate links to Cisco documentation:
Hopefully this makes sense below, basically Iām running the below configuration on a CSRv, but the route map āmatch interfaceā isnāt working, is there a good way to troubleshoot what the device is doing in regards to apply and processing of the route map?
When using a route map for redistribution, the show route-map command will not show any matches of the route-map statements, as stated in this post. The matches appear only when route maps are applied to policy routing. So the fact that you have zero matches to your route-map in the first case is not an indication that the feature is not working.
Secondly, you should take a look and see if the redistribution is actually taking place. Take a look at the routing tables of the local and remote OSPF routers to see if the connected routes are being redistributed with the appropriate metrics.
Finally, you can use various debug commands for OSPF about which you can learn more at this Cisco CLI reference:
Using debug, you can examine to see what prefixes are actually being sent by OSPF and with what metricā¦
Hopefully, these ideas will get you started on your next steps for troubleshooting the issue.
Hello Rene,
If the route-map has the deny statement, does it really matter to have a permit or deny statement in the IP Access-list? What I have observed is, even though the match has a permit statement, if the route map has deny statement, the whole thing will be denied ? kindly correct me if am wrong.
Yes, the permit and deny statements within route maps and within ACLs that are called by route maps can get confusing. Take a look at this post, and hopefully that will clear it up for you:
Hi,
Iām working on cisco 7600 and 6800 right now. My problem is that when I try to create a route map with a continue statement as shown below it is not working as expected. That means it is advertising only to the first sequences( sequence 10) community, not to the next sequence (sequence 20) which i have pointed through the continue statement.
could you please help me to fix this. Note: This is working perfectly fine on the Nexus device.
route-map TEST permit 10
match ip address TEST
continue 20
set extcommunity rt 65500:352001 65500:355001 65500:356001 additive
set extcommunity rt 65500:357001 65500:358001 65500:359001 additive
set extcommunity rt 65500:360001 65500:361001 65500:362001 additive
set extcommunity rt 65500:363001 65500:364001 65500:365001 additive
set extcommunity rt 65500:366001 65500:367001 65500:368001 additive
set extcommunity rt 65500:369001 65500:370001 65500:371001 additive
set extcommunity rt 65500:372001 65500:373001 65500:374001 additive
set extcommunity rt 65500:375001 65500:376001 65500:377001 additive
set extcommunity rt 65500:378001 65500:379001 65500:380001 additive
set extcommunity rt 65500:381001 65500:382001 65500:383001 additive
set extcommunity rt 65500:384001 65500:385001 additive
!
route-map TEST permit 20
match ip address TEST
set extcommunity rt 65500:353001 65500:618001 additive
!
Take a look at this Cisco documentation, that details how the continue clause is used in route maps for BGP applications.
Now reviewing this document and looking at your config, I have the following suggestions for you to continue your troubleshooting:
The document states that āContinue clauses in outbound route maps are supported in Cisco IOS XE Release 2.1 and later releases.ā so check your IOS version.
In the examples in the document, the continue clause comes after the set statements so that they can be executed before going on to the sequence number indicated by the command.
Using the show route-mapcommand, you can see the sequence to be followed by the route map in detail, and you may find the reason for this behaviour.
Keep in mind that NX-OS devices have different syntax, and commands applied to a Nexus device donāt necessary mean that they will work for IOS.
Let us know how you get along with your troubleshooting procedures!
Iām trying this on the ios platform, not on ios XE. So probably that could be the reason.
2.Even if I put the continue clause after the set statement it is still showing before set statement in output.
