Among the tools you will use a lot when configuring Cisco devices are route maps. They are similar to access lists in some way but also offer very flexible options, unlike access lists. We see route maps being used for policy routing, redistribution, and even in some NAT configurations. In this article, we will explore the route maps feature, the logic behind them and also see examples of how route maps are used.
CCNA Training – Resources (Intense)
Match and Set Clauses
When dealing with route maps, the two clauses you will mostly make use of are the match and set clauses. These clauses do exactly what they sound like: the match clause matches a specific set of traffic or routes while the set clause allows you to apply actions on traffic or routes.
The match clause
Let’s use something we are familiar with – access lists – to explain the concept of the match clause of route maps. In the configuration below, access list 100 is configured to match ICMP traffic from host 10.10.10.1 destined for host 10.10.20.2. That access list is then applied to the Fa0/0 interface in the inbound direction.
access-list 100 permit icmp host 10.10.10.1 host 10.10.20.2 ! interface FastEthernet0/0 ip access-group 100 in
The same concept as described above can be applied to route maps, except that route maps offer more matching options than access lists. Below, you can see the available match options under route maps:
Some of these options have sub-options. For example, the “ip” option has sub-options like next-hop and address:
When dealing with policy routing, you will more often than not use the “match ip address ” command. When this command is used for this purpose, it means the traffic specified in that access list will be matched. We will see an example of this later in this article. You will also notice that there are a lot of BGP-related options under the match clauses; this is because route maps play a very important role in BGP, especially for configuring routing policies. You can refer to my series on BGP to see how route maps are used extensively.
When using route maps for redistribution, there are many match clauses you can use such as match interface, match metric and match route-type.
The set clause
This clause extends the capability of route maps because it provides the ability to set the conditions to be applied on traffic or routes. When dealing with policy routing, for example, we can use the set clause to specify the interface through which traffic should be forwarded. In the case of route redistribution, we can use the set clause to control the metric of a particular route.
Just like access lists, route maps use the concept of sequence numbers to specify the order in which they are processed. The router will process the route map entries in the order in which they are specified. Therefore, when a match is made, the actions (if any) specified under the matching route map entry are executed and processing stops.
Permit and Deny Clauses
Also, the same way we have permit and deny clauses in access lists, we have the same thing in route maps. However, the effect is slightly different in route maps, depending on what the route map is used for. For example, you can have a route maps that denies certain routes from being redistributed. In another case, you may use a permit clause to suppress routes from being advertised using a suppress map.
A lot of times, you will be using route maps with access lists so you need to understand the logic behind the permit and deny clauses in both the access list and the route map. For example, if you have a route map used for redistribution and it has an entry with the permit clause, then any routes permitted in the ACL matched under that entry will be redistributed.
Note: Route maps don’t necessarily have an implicit deny at the end, the way access lists do. Depending on how they are used, a “deny all” may be implied or not.
Example: Policy Routing
Let’s take an example of how route maps can be used for policy routing. We will be using the network shown below:
I’m running EIGRP on the network, so all routers know about all the routes. If I check the routing table of R1, I will see that it is load balancing between its two links for the destination 192.168.23.0/24.
Remember that normal routing is destination-based so, irrespective of the source of the traffic, R1 will load balance traffic between its two links.
Note: The load balancing method will depend on the switching method being used. CEF will normally do per source-destination pair load sharing but, for this article, I will enable per-packet load sharing using the ip load-sharing per-packet interface configuration command..
Therefore, if I perform a traceroute from R4 to 192.168.23.2, the traffic will be forwarded to R1, which will then send the traffic via both its Fa0/0 and Fa0/1 interfaces.
The same load sharing will occur if I perform a traceroute to 192.168.23.3:
Let me show you another way to confirm that R1 is really doing per packet load sharing. I will use access lists with the logging option enabled for ICMP ECHO traffic so that I can see how packets go through a particular interface. The configuration on R1 is as follows:
ip access-list extended Fa0/0 permit icmp any any echo log permit ip any any ! ip access-list extended Fa0/1 permit icmp any any echo log permit ip any any ! interface Fa0/0 ip access-group Fa0/0 out ! interface Fa0/1 ip access-group Fa0/1 out
Now, if I send four ping packets from R4 to, say, 192.168.23.2 (R2), you will see that two will go through Fa0/0 while the other two will go through Fa0/1.
Hint: The easiest way to see the packet sharing is to enable debugging on R1 and see the packet forwarding through the interfaces but, since CEF is the switching method in use, we will not see any packets in our debug output.
Using policy routing, we can override this behavior. We will configure the following policy on R1:
All traffic from 192.168.14.4 (R4) destined for 192.168.23.2 (R2) should be sent through R1’s Fa0/0 interface
All traffic from 192.168.14.4 (R4) destined for 192.168.23.3 (R3) should be forwarded via R1’s Fa0/1 interface.
All other traffic should follow the default routing on R1
The configuration to achieve this on R1 is as follows:
access-list 101 permit ip host 192.168.14.4 host 192.168.23.2 access-list 102 permit ip host 192.168.14.4 host 192.168.23.3 ! route-map POLICY-ROUTING permit 10 match ip address 101 set interface Fa0/0 route-map POLICY-ROUTING permit 20 match ip address 102 set interface Fa0/1 ! interface FastEthernet1/0 ip policy route-map POLICY-ROUTING
Now, if we traceroute to those addresses again from R4, we see that our policy routing is in force:
To see this using our logging access list, first I will clear the counters of our access list (clear access-list counters) and then I will ping from R4 to one of the addresses. You will see that all the packets go through one interface in this case:
For other source addresses (e.g., 18.104.22.168) that are not matched in our policy route map, the default routing (per packet load sharing) will take place:
Note: Since the traffic from 22.214.171.124 did not match any route map entry, it was routed normally – it was not dropped. This further proves that route maps may or may not have a “deny all” applied.
Example: Route Redistribution
Let’s take another example of using route maps—route redistribution. In the network diagram below, I will be performing mutual redistribution on R1; i.e., from OSPF to EIGRP and from EIGRP to OSPF. However, I want to alter the metrics of some of the routes. This can be easily achieved using route maps.
The configuration on R1 is as shown below:
access-list 1 permit 172.16.22.0 0.0.0.255 access-list 2 permit 10.10.33.0 0.0.0.255 ! route-map EIGRP-TO-OSPF permit 10 match ip address 1 set metric 10 ! route-map EIGRP-TO-OSPF permit 20 ! route-map OSPF-TO-EIGRP permit 10 match ip address 2 set metric 10000 10 1 1 1544 ! route-map OSPF-TO-EIGRP permit 20 ! router eigrp 10 redistribute ospf 1 metric 1000 10 1 1 1544 route-map OSPF-TO-EIGRP ! router ospf 1 redistribute eigrp 10 subnets route-map EIGRP-TO-OSPF
With the configuration above, I expect the 172.16.22.0/24 route to have a metric 10 in the OSPF domain while the other redistributed EIGRP routes have the default metric (20). I can check R3’s routing table to confirm this:
Also, I expect the 10.10.33.0/24 route to have a different metric from other redistributed OSPF routes inside the EIGRP domain. I can confirm this from R2’s routing table:
Notice that my route maps have a blank entry at the end of each of them (e.g. route-map EIGRP-TO-OSPF permit 20). Without this entry, routes that are not matched in the route map will not be redistributed. This shows that route maps when used for redistribution have an implicit “deny all” applied.
As we have explored, route maps offer us very flexible configuration options more than we can do with access lists. We have also covered two examples of the uses of route maps including policy routing and route redistribution.
I hope you have found this article insightful.
References and Further Reading
The Basic Uses of TCP/IP Route Maps: http://www.ciscopress.com/articles/article.asp?p=426637
Route-Maps for IP Routing Protocol Redistribution Configuration: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/49111-route-map-bestp.html