Introduction to Route-maps

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

Hi Rene,

I used route-map for one to one NAT (same source and two different destinations) but NAT is only working on unicast traffic, not working on multicast traffic. Router is Cisco ISR 4321.

The below is my config,

ip nat inside source static 192.168.1.1 137.1.1.1 route-map C2_H1
ip nat inside source static 192.168.1.1 192.100.46.11 route-map C2_H2
route-map C2_H1 permit 10
match ip address 111
route-map C2_H2 permit 10
match ip address 122
ip access-list extended 111
permit ip host 192.168.1.1 host 224.1.1.1
permit ip 192.102.1.0 0.0.0.255 172.1.1.0 0.0.255
ip access-list extended 122
permit ip host 192.168.1.1 host 225.1.1.1
permit ip 192.168.1.0 0.0.0.255 192.100.46.0 0.0.0.7

Please help me to suggest where do I need to change?

If there is an implicit deny for non matching rules then why bother with deny rules and just put in permit rules for what you want to pass and let the implicit deny drop everything else?

Hello Joshua

Yes, I understand what you are saying. However, what if you want to deny only a single subnet? For example, let’s say you want to deny 10.10.10.0/24 and permit everything else. In order to achieve this with the implicit deny, you must permit the range of addresses from 0.0.0.0 to 10.10.9.255, and 10.10.11.0 to 255.255.255.255. That is much more difficult than simply denying 10.10.10.0/24 and then permitting all.

The same is true for all constructs that work with these types of sequential statements, such as access lists as well.

I hope this has been helpful!

Laz

Hello Than

I suggest you first take a look at this documentation about NAT and multicast to get a better idea of how the two features function and interact. If you have further questions, feel free to share them with us here and we will help you further.

I hope this has been helpful!

Laz

Hi Lagapides,
Thanks for the suggestion and link to study.
And then I tried according to the link, please see the below my config.


> ip nat pool pool-108 137.1.1.1 137.1.1.1 prefix-length 30
ip nat pool pool-118 192.100.46.11 192.100.46.11 prefix-length 30

     ip nat inside source route-map MAP-108 pool pool-108
     ip nat inside source route-map MAP-118 pool pool-118

     access-list 108 permit ip 192.168.1.0 0.0.0.255 172.1.1.0 0.0.0.255
     access-list 108 permit ip host 192.168.1.1 host 224.1.1.1
     access-list 118 permit ip 192.168.1.0 0.0.0.255 192.100.46.0 0.0.0.7
     access-list 118 permit ip host 192.168.1.1 host 225.1.1.1

     route-map MAP-108 permit 10
     match ip address 108
     
     route-map MAP-118 permit 10
     match ip address 118


But still the same error. NAT is working fine in unicast traffic (ping) but NAT is not working in multicast traffic (received multicast traffic with original source ip).
According to customer’s requirement, I must use one to one static NAT.

Before adding the second multicast traffic 225.1.1.1 (NAT to 192.100.46.11), there is only one multicast traffic 224.1.1.1 (NAT to 137.1.1.1). At that time NAT is working fine for both unicast and multicast traffic.

Thank you. That is by far the best explanation and makes perfect sense.

1 Like

But I want to allow all , except oone subnet
How dow i deny one subnet a d low reami ng all to the BGP

Shaji

Hello Shaji

Sorry about that I misunderstood. If you want to use prefix lists and route maps, then you would have to do it this way:

First, you would create a prefix list that matches the subnet you want to filter out:

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

Next, you must reference this in a route-map with which you will deny it:

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

But remember, there is an implicit deny statement at the end, so at this point, everything will be denied. Thus, we must add another route map statement like so:

R1(config)#route-map FILTER_OUT permit 20
R1(config-route-map)#exit

This statement will permit everything.

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

Now this will filter out the 10.221.1.0/24 subnet but will permit everything else.

I hope this has been helpful!

Laz

1 Like