Introduction to Route-maps

Lessons Discussion
65

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?

66

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?

69

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

70

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

71

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.

72

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

1 Like
73

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

74

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
75

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

76

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

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!

Laz

77

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”
e.g

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?

78

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!

Laz

80

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

82

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!

Laz

1 Like
83

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!

Laz

84

Fantastic thanks alot

1 Like
85

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?

86

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!

Laz

87

Hi Lagapides,

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

1 Like
88

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


Route-map isp permit 10
Set weight 32869

Router bgp 100
Neighbour 1.1.1.1 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