Introduction to Route-maps

Lessons Discussion
#25

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

#26

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

#27

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
#28

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

#29

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
#30

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
#31

Thanks a lot. Now I understand the logic.

1 Like
#33

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.

#34

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

#35

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.

#36

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

#37

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

#38

Hello Robert

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.

I hope this has been helpful!

Laz

1 Like
#39

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.

#40

Hello Eugene

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:

I hope this has been helpful!

Laz

#41

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
!
#42

Hello Shibu

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 hope this has been helpful!

Laz

#43

Hi Lazaro,

Thanks for your reply.

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

Thanks for the reply once again.

Take care : )

1 Like
#44

use case of route-map.

#45

Hello Vijay

One of the primary uses of route maps is policy-based routing. You can find out more about this at the following lesson:

But there are so many other uses including manipulating the way routing protocols share prefixes (especially useful for BGP).

I hope this has been helpful!

Laz