Introduction to Route-maps

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

1 Like

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

1 Like

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.0

Hello 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/0

Hello 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:

  1. 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.
  2. 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.
  3. 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.

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. :mask: :thinking:

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

Hello 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

1 Like

Thanks a lot. Now I understand the logic.

1 Like

Hello ReneMolenaar,

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

Regards,
Degaulle M.

Hello Degualle

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.

Thanks for pointing this out!

Laz

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.

Hello Austin

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:

I hope this has been helpful!

Laz

Hi,

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?

Let me know if you need any other output?

! ##########
! Configuration for for route map
! 
interface Loopback100
 ip address 160.1.9.100 255.255.255.255
!
interface Loopback200
 ip address 160.1.9.200 255.255.255.255
!
route-map CONNECTED->OSPF permit 10
 match interface Loopback100 Loopback200
!
router ospf 1
 redistribute connected metric 50 subnets route-map CONNECTED->OSPF
 summary-address 160.1.9.0 255.255.255.0

! ###########
!
R9#show route-map
route-map CONNECTED->OSPF, permit, sequence 10
  Match clauses:
    interface Loopback100 Loopback200
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R9#
! ######

My current work around is this on top of the existing route map;

!
!
access-list 9 permit host 160.1.9.100
access-list 9 permit host 160.1.9.200
!
route-map CONNECTED->OSPF permit 20
 match ip address 9
!
R9#show route-map
!
route-map CONNECTED->OSPF, permit, sequence 10
  Match clauses:
    interface Loopback100 Loopback200
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map CONNECTED->OSPF, permit, sequence 20
  Match clauses:
    ip address (access-lists): 9
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
!
R9#sh access-lists
Standard IP access list 9
    20 permit 160.1.9.200 (1 match)
    10 permit 160.1.9.100 (1 match)
R9#

Cheers,
Rob