Introduction to Route-maps

use case of route-map.

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

Thank you so much @lagapidis

1 Like

Hi Rene,

it was a wonderful artical but i have a query.

so if we create a route-map with deny/permit statemet then

permit route-map 10 with deny ACL for 192.168.0.0/24
permit route-map 20 withhout any ACL
Result: we permit everything including 192.168.0.0/24 which we have denied in same route-map statement 10

why it’s like that in case of ACL if we have deny match at the top then rest ACL won’t be evaluated but in this case it’s getting deny on the route-map 10 statement and getting permit at route-map 20 statemet.

i am putting config as well

R2#sh running-config | section eigrp
router eigrp 1
 network 192.168.0.0 0.0.255.255
 distribute-list route-map test_2 in
 no auto-summary
R2#
R2#sh route-m
R2#sh route-map test_2
route-map test_2, permit, sequence 10
  Match clauses:
    ip address (access-lists): 4 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map test_2, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R2#
R2#sh acc
R2#sh acce
R2#sh access-li
R2#sh access-lists 4
Standard IP access list 4
    10 deny   192.168.3.0, wildcard bits 0.0.0.255 (7 matches)
R2#

EIGRP Route Table

R2#sh ip route eigrp 
D EX 200.200.200.0/24 [170/30720] via 192.168.12.1, 00:32:43, FastEthernet0/0
     100.0.0.0/32 is subnetted, 1 subnets
D       100.100.100.100 
           [90/156160] via 192.168.12.1, 00:32:44, FastEthernet0/0
D    192.168.0.0/24 [90/156160] via 192.168.12.1, 00:32:44, FastEthernet0/0
D    192.168.1.0/24 [90/156160] via 192.168.12.1, 00:32:44, FastEthernet0/0
D    192.168.2.0/24 [90/156160] via 192.168.12.1, 00:32:44, FastEthernet0/0
D    192.168.3.0/24 [90/156160] via 192.168.12.1, 00:32:44, FastEthernet0/0

so if you see that packet matches to ACL 4 but when we put n new route-map statement then it’s allowed

as per my understanding if ACL match happned on route-map condition 10
then it should not evaluate map-condition 20

Now after removing route-map 20 statement

R2#sh route-map test_2
route-map test_2, permit, sequence 10
  Match clauses:
    ip address (access-lists): 4 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R2#sh access
R2#sh access-li
R2#sh access-lists 4
Standard IP access list 4
    10 deny   192.168.3.0, wildcard bits 0.0.0.255 (9 matches)
R2#
R2#sh ip rou
R2#sh ip route ei
R2#sh ip route eigrp 

R2#

i am not seeing any route that’s a correct behavioure but as soon as i put one more route-map with seq no 20 it will allow everything

Hello Ankush

This is correct behavior, but you must understand what the role of the access list is and what the role of the route map is in such a configuration.

When using an access list within a route map, the role of the access list is to match traffic. An access list in this scenario will only match traffic if there is a permit statement. So essentially, the access list you have placed in the route map does not match anything. So nothing ever hits that permit route-map 10 statement, not even 192.168.0.0/24 will match!

So everything goes on to be matched in the permit route-map 20 statement since if you have no criteria, everything will be matched. And since it is a permit statement, everything will be permitted.

After you removed the 20 statement, remember that the route map has an explicit deny statement at the end, so without that 20 statement, nothing is matched, and everything is denied.

In order to achieve what you want, you must change your ACL to a permit statement rather than a deny statement. That sounds counterintuitive, I know, but you must remember that the ACL here does not permit or deny traffic, it only matches or doesn’t match. It is the route map permit/denies statements that will affect the permitting or denial of traffic (or prefixes as the case may be…)

So a deny statement within an ACL that is referenced by a route map will never deny traffic, as that is not its role. Only the deny statement within a route map can deny traffic.

I hope this has been helpful!

Laz

Hi Rene and Laz, I dont think i have been more confused in mi life until I came across this lesson,
I dont fully understand the logic of the route-map permit/deny with access-lists permit/deny.

My understanding is that if I use a permit in route-map and a permit in access-lists, than the whole statement will permit the action, if however the route-map permits but the access-list denies, than the whole statement is a deny, am I correct? and If that is the case than why bothering with the deny in the access list if it is going to be denied anyways?
And
If I use a route-map deny and an access list that permits, than the statement will be denied as well yes? if that’s the case than why bothering wit a deny in the access list? this is confusing me jajajaja. Please could you explain this to me, thank you.

Hello Sidney

Yes, it can get confusing. I believe that this will help:

In such a scenario:

  • The role of an access list is to match traffic (not to permit or deny traffic). Traffic will only be matched if there is a permit statement.
  • The role of a route map is to act upon matched traffic. The action taken will only apply to any traffic matched by the ACL that is called by the route map.

Having said that, the following post will also further clarify this point:

I hope this has been helpful!

Laz

Example 1.2.2, how is network 192.168.0.0/24 still showing up after adding the following:

R2(config)#route-map TEST_4 permit 20

Wouldn’t it still be denied and the other 3 routes only would show up?

Hello Brad

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.

I hope this has been helpful!

Laz

I can’t believe I missed that. Appreciate your explanation greatly!

1 Like

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

Hello Adam

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.

I hope this has been helpful!

Laz

Hi Rene and Laz,
First of all, you’re great! Very good and simple explanation :slight_smile:
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.

For example:

R2#
ip vrf A

ip access-list standard permit_lo10
 permit 172.16.10.1

route-map lo10 permit 10
 match ip address permit_lo10
 set vrf A

router ospf 10
distribute-list route-map lo10 in

R1#

interface Loopback10
 ip address 172.16.10.1 255.255.255.255

router ospf 10
 network 172.16.10.1 0.0.0.0 area 0

What should i expect after this configuration ?

Thanks for a reply

Hello Aronne

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:

I hope this has been helpful!

Laz

HI Laz
Thank you very much for the explanation :+1:

Bye
Aronne

1 Like

I have saw a new way to use route-map but I cannot find any examples of this on networklessons.com is this legit?

ip prefix-list BGPTest permit 172.20.56.0/24
!
route-map ApplyTest permit 10
match ip address prefix-list BGPTest
set local-preference 90
!
router bgp 111
neighbor 192.168.10.1 remote-as 100
neighbor 192.168.10.1 route-map ApplyTest in
neighbor 192.168.20.2 remote-as 200

they apply this routemap on the end of the neighbor command in a way to effect path selection and make the path point towards the 192.168.10.1 interface.

This is really cool if it works but I was not able to find very good examples on this all the other examples do not apply it like that.

Any reason why?

Hello Brian

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.

I hope this has been helpful!

Laz

Rene,

I need to deny a specific subnet ( 10.221.1.x to the BGP routing table , and permit remaining all subnets
How can I configure using prefix list and route-map

Hello,
I need to deny a specific subnet ( 10.221.1.x to the BGP routing table , and permit remaining all subnets
How can I configure using prefix list and route-map .please help

Hello Shaji

First, you would create a prefix list that matches that subnet:

R1(config)#ip prefix-list MY_LIST permit 10.221.1.0/8

Next, you must reference this in a route-map:

R1(config)#route-map FILTER_OUT permit 10
R1(config-route-map)#match ip address prefix-list MY_LIST

Then you must apply this route map to the BGP neighbor you want, in an inbound or outbound direction, depending upon which router’s BGP table you want it to be applied to. Let’s say it’s outbound:

R1(config-router)#neighbor 192.168.12.2 route-map FILTER_OUT out

For more information on prefix lists, route maps, and filtering BGP routes, take a look at these lessons:

I hope this has been helpful!

Laz