Hello Willy
Can you give us a more detailed example of the problem you are facing? What happens when a statement is matched? Do you find that both “set” statements are applied? Also, you have shared two route maps, one called “xxx” and the other called “CO_TEL_OUT”. Can you clarify where you see your problem and how it takes place? An example would be very helpful.
Laz
Hello Lazaros,
About my exemple, don’t take about the route map name XXX. All the routes in this exemple have the same name. I wrote this route map, to filter the prefixes announced to a peer.
So this is my route-map 
route-map CO_TEL_OUT permit 5
match ip address prefix-list CO_TEL_PRIORITY
route-map CO_TEL_OUT permit 10
match ip address prefix-list LB_CO_TEL
set community 174:70
route-map CO_TEL_OUT permit 15
match community 1
set community 174:3003
In the Seq 5 i use a different prefix-list from seq 10. And in the last seq, the statement must match prefix different from seq 5 and 10. So the problem is when im going in the facing router i see all prefix included in the match route-map seq (5, 10 and 15).This is strange because in the lesson, when a route-map find a match, the router execute the statement and exit the route-map. the only way where the router can process several route-map statement is when we use the Key CONTINUE. In my case i don’t use it, but my router process all the seq n the route-map.
Hello Willy
Thanks for the clarification. Looking at this statement:
Can you give us the output of what you see in this case as well as what your prefixes are and what your prefix lists are as well? That way we can be more specific in responding to you.
Thanks!
Laz
In fact this behavior occur in a production router. To resume, this is the situation : I have a router connected to 2 public upstream (Cogent) and i use this public looking glass to validate (https://www.cogentco.com/fr/network/looking-glass) my configuration.
I use two route-map to advertise my prefixes to upstream 2 and 3. With these routes, the same prefixes are announced with some differences:
List item : The prefix announced with the route-map seq 5 used for upstream 2 is used in the route-map seq 10 for the upstream 3.
List item : The prefix announced with the route-map seq 5 used for upstream 3 is used in the route-map seq 10 for the upstream 2.
With this configuration upstream 2 can load-balance some prefixes it uses with upstream 3 and vice versa.
The seq 15 of the 2 route-map allow me to prioritize one link and use the next link as backup.
So this is one of my route-map :
route-map CO_PA_OUT permit 5
description Selection des routes annoncees en PRIORITAIRE
match ip address prefix-list CO_PA_PRIORITY
route-map CO_PA_OUT permit 10
description Selection des routes annoncees en LOADBALANCING
match ip address prefix-list LB_CO_PA
set community 174:70
route-map CO_PA_OUT permit 15
description Selection des routes SIPR + IGPP + STR pour utiliser Cogent Paris
match community 1
set community 174:3002
In the prefix-list CO_PA_PRIORITY, you can find 197.231.70.0/24 and in the seq 15, the route-map must match this prefix 197.231.74.0/24 (prepend twice). How do I know that my router processes everything from the route-map ? When i use looking glass, i discover prefixes from the seq 5 and the prefix from the seq 15.
I hope, my explanation can help you to explain me why when my router matches the prefix of seq 5, it doesn’t exit from the route-map.
Hello Willy
Thanks for the clarification. Now it seems that you are using the looking glass server to verify your route maps. Although it makes sense, it is not an accurate way of determining what prefixes you are actually advertising. This is because the looking glass server may receive prefixes from you, but you don’t know what it does with them. So seeing them in the server doesn’t give you an accurate view of what is actually being advertised.
Route maps will indeed stop once a match is found. This is how they function, and it is inherent in their operation. So something else must be going on with your configuration.
Since a looking glass server is not a reliable way of checking this, you must check from your side that the prefixes have the correct communities when they are advertised. But this is not that easy. The show ip bgp neighbors peer-ip advertised-routes command doesn’t show communities in IOS or IOS XE. IOS XR on the other may actually display this info. Even BGP update debug commands will not include communities. So there are some ways to do this:
I hope this has been helpful!
Laz
Hi Rene i would like to find out what Cisco IOS you are running in your lab examples for the ENARSI training as i am not able to run the same commands using my Cisco routers in GNS3 i am using C7200 and C3745. And how do i access the that IOS you are running in your Labs .
Looking forward to hearing from you.
Regards,Pius
Hello Pius
Rene uses VIRL and the devices in the topology use IOSv (revision 1.0) with a system image file vios-adventerprisek9-m.
Can you tell me which particular commands you are having trouble with? It could be that the IOS version you are using does not support them. You can use the Cisco Feature Navigator to see what features are included in the IOS you are using.
I hope this has been helpful!
Laz
Hi Rene
please see screen shot, why did you call the distribute list in eigrp 1 ‘‘test 1’’ and not according to the name of the access list nor route-map?,
Hello Walter
You’ll notice above this text, Rene has created a route map on R2 called TEST_1. Within this route map, he is matching an access list called R1_L0_PERMIT. He then creates this access list, as shown in your screenshot as well.
So when he applies the distribute-list he uses the route map with the name TEST_1 that he created previously.
I hope this has been helpful!
Laz
Hi Rene,
Regarding the match condition deny example. why adding another route-map permit statement allowed other 3 subnets. Please explain this, as i thought the other routes will also be filtered by the implicit deny in the end of access list: R1_L0_PERMIT. and we should not see any routes.
Also what happens if the match condition does not match any address?
P.S: One typo there:
route-map TEST_3 deny 10
match ip address R1_L0_PERMIT
route-map TEST_MATCH_DENY permit 20
Hello Justin
Rene created the R1_L0_PERMIT access list with a permit statement for the 192.168.0.0/24 subnet. This was then referenced by the TEST_3 route map with a deny statement for matches to this access list.
So this route map is applied to the distribute-list of EIGRP. Now a router sends the following four subnets via EIGRP and they are “filtered” through this distribute list:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
When they go through, the first is matched by the access list, and the route map says “deny” for this, so it is not allowed. The second is not matched by the access list, but is matched by the implicit deny statement at the end of the route map, and is therefore denied. The same happens to the other two subnets.
Now if we add a permit statement to the end of the route map to match everything, the result will be that the route map will allow everything except for whatever the first statement denies. So with this permit statement, the distribution list will deny the 192.168.0.0/24 subnet, but will allow everything else, thus the other three subnets are sent through.
The final route map and access list that @ReneMolenaar displays at the end (without the typo) is the following:
route-map TEST_3 deny 10
match ip address R1_L0_PERMIT
route-map TEST_3 permit 20
It depends on how the route map is configured. Remember that there is an implicit deny at the end of all route maps. If there is a permit statement at the end like we configured above, and the match condition doesn’t match anything, then it is as if the route map does not exist. If the match condition does not match any address and there is no permit statement at the end of the route map, then the implicit deny will cause deny everything.
Thanks for pointing the typo out, I will let Rene know to fix that.
I hope this has been helpful!
Laz
Thanks for the reply.
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.0Hello Justin
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.
I hope this has been helpful!
Laz
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
Hello Justin
It seems that you have not included the distribute list configuration in EIGRP in the above configuration. Could that be the reason why?
I hope this has been helpful!
Laz
Sorry missed to share that information earlier. But I have configured distribute list in R2 router inbound
Config below:
R2#show runn | sec eigrp
router eigrp 10
distribute-list route-map permit_L0_L1 in
network 0.0.0.0
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/0Hello Justin
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:
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.
I hope this has been helpful!
Laz
Hi Laz,
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/0Hello Justin
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 hope this has been helpful!
Laz
Thanks a lot. Now I understand the logic.