Introduction to Route-maps

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 route-map C2_H1
ip nat inside source static 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 host
permit ip 0.0.255
ip access-list extended 122
permit ip host host
permit ip

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 and permit everything else. In order to achieve this with the implicit deny, you must permit the range of addresses from to, and to That is much more difficult than simply denying 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!


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!


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 prefix-length 30
ip nat pool pool-118 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
     access-list 108 permit ip host host
     access-list 118 permit ip
     access-list 118 permit ip host host

     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 (NAT to, there is only one multicast traffic (NAT to 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


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

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

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 route-map FILTER_OUT out

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

I hope this has been helpful!


1 Like

Thank you for explaining clearly .
Important thing i noticed here is the route map name should be same for permi and deny .

Hello Shaji

Yes, that’s because the same route map will have multiple statements that are examined in order. If you were to look at the completed route map as configured in the previous post, you would see something like this:

R1#show route-map FILTER_OUT
route-map FILTER_OUT, deny, sequence 10
  Match clauses:
    ip address prefix-lists: MY_LIST 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map FILTER_OUT, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

Notice that because we used the same route-map name, all the commands are applied to the same route map. And because we used specific sequence numbers, the sequence with which the statements will be executed is specific.

I hope this has been helpful!


Hello Rene & Lazaros,

In cisco Nexus 9000 can you please point me to some official cisco documentation that confirms the following -
“Route-maps permit X applied inbound to a BGP neighbor with no match condition is technically a permit all”

route-map xxxx, permit, sequence 10
  Match clauses:
  Set clauses:
    community 1:123

IF I applies this route as inbound policy on my BGP neighbor, any route learned from that neighbor would simply set the community to “1:123” right?

Hello Than Tun Aung

When using multicast with NAT, there are sometimes some strange behaviors that take place. I went over this with @ReneMolenaar, and he did a bit of labbing, and he came up with the following strange behavior. He set up a lab that was similar to your setup and your route maps and access lists.

When there are two NAT pools, and the first pool is used initially by a multicast stream, communication and NATting takes place as expected. In this case, the first route-map is matched and the appropriate NAT translations take place. Once that first communication takes place, the NAT translation table gets an entry, again as expected, with the proper source IP, translation, and destination multicast address.

Now when you ping a multicast address that will match the second route map, you would expect the NAT translation to appropriately translate the source address according to the second route map and the second access list. But if you look at a packet capture, you will see that the correct destination multicast address is used, but the source address being used is from the first NAT pool.

If you then look at the NAT translation table, you will see that the first translation from the first pool is still in use in the table. So it’s using the source address of the translation already in the pool, while using the multicast destination address corresponding to the second pool. Additionally, you’ll see that the correct route map is being matched because you see increasing matches on the corresponding access list.

Now if you clear the NAT address translations from the translation table, and then begin transmission to the multicast address of the second route map, then you will see the correct source address.

This is a strange behavior that seems to take place under these circumstances. Can you elaborate on your requirements so that we may be able to suggest an alternative solution to achieve what you need?

I hope this has been helpful!


Hi Lagapides,

Thank you and Rene so much for putting extra effort to help me.
I already solved the issue by upgrading the IOS from 17.03.03 to 17.06.04 for Cisco ISR 4321 router.
Multicast traffic fail with route-map

Hello Nicolas

You probably won’t find Cisco Nexus 9000 documentation where this statement is made because it has to do with route-maps in general. As stated in this NetworkLessons note, all route maps, if there is no match clause, then everything will be matched.

So to answer your question, yes, if this route map is applied on an inbound policy on your BGP neighbor, all routes learned from that neighbor would set the community to 1:123.

I hope this has been helpful!


1 Like

Hello Than Tun Aung

Thanks for sharing the results of your research and your solution with us! I have created a NetworkLessons note on this topic and have referenced your post here as well.

Thanks again!


Fantastic thanks alot

1 Like

I am a little hazy on the deny statements on the route-map vs the ACL.
Do they both perform the same action, just a different way of performing the action?
IE: Permit the Route-Map to match the ACL that denies the traffic?
Conversely, you can Deny the Route-Map to match the ACL that allows the traffic?

Same result, just different flavor? Or is there something basic that is escaping me about this topic?

Hello Pietro

Take a look at this NetworkLessons note on Route-Map and ACL matching for clarification. Once you go over it, if you have further questions, feel free to let us know!

I hope this has been helpful!


Hi Lagapides,

I also thank you and Rene for help and support!!!

1 Like

I have one small confusion, after creating route-maps example -

Route-map isp permit 10
Set weight 32869

Router bgp 100
Neighbour route-map isp IN

In neighbour we call the route map as IN
This will be incoming traffic ?
How do we consider incoming and outgoing traffic and also how can we check this… Please someone clear this