Have you ever wanted to customize how your router works? In some cases, you simply have no alternative. In fact, you may want to modify the Route selection process, the route leaking, or routing itself. Because of that, Cisco created a great technology: the Route Map. Route maps have a great power, that comes with some complexity. Thus, you don’t find route maps in the CCNA, but as part of the CCNP curriculum instead. This article will help you progress with your CCNP, by covering the route map technology in details.

To better understand this article, you should have a CCNA-equivalent knowledge. We will talk about routing protocols and ACLs assuming you know them. If you are unsure about your level, just check out our Free CCNA Course.

Introducing Route Maps

What does a route map do?

You can think of a route map like an advanced ACL. The Access Control List matches an IP address, and performs two action: permit or deny. In fact, an ACL can process any IP address permit or deny it, according to its rules. Because of that, ACLs are a natural choice for blocking or permitting traffic. However, you can use them in other applications as well. For example, you can use them to define which IP addresses the router should NAT.

ACLs can go a step further, as we explained in this article. They can also match on static L3 and L4 information, like protocol or TCP flags.

Route maps also perform a match and apply an action. However, the match many different things, and can perform many different actions. They go far beyond the classic permit and deny of an ACL. In fact, you don’t use them to simply match IP addresses. You use them to match routes. This means they are not an alternative to ACLs, but a more powerful match-and-act statement that you can use in specific circumstances.

A route map doesn’t simply match IP addresses. It matches routes.

A route map can match on metric, on IP addresses, prefix length, routing protocol and more. With all this power, how do we use a route map?

Applications of a route map

As we will see in this article, we use route maps for Policy Based Routing and Route Redistribution.

Policy Based Routing (PBR) is just what the name says. Instead of routing packets according to the best match in the routing table, we route them according to a policy. This means we can direct packets coming from a subnet to a next-hop, and packets coming from another subnet to another next-hop. We can administratively define the policy, and have custom and predictable routing.

Route Redistribution, instead, is the propagation of routing updates between different routing protocols. Even for link-state routing protocols, route redistribution communicates routes (and not link-state updates). Since a route map specifically match routes, we can put it to good use here. Furthermore, it doesn’t simply permit or deny the redistribution of a route. It can alter its parameters, like the metric, or even the next-hop. Route maps are extremely handy when configuring BGP, as it has several parameters that we can alter to satisfy our needs.

Creating a Route Map

The anatomy of a route map

Despite their overall complexity, the structure of a route map is very simple. Just like an ACL, a route map is a set of rules. Each rule has just three items: the action type, the match clause, and the set clause. The action type is just permit or deny, and defines what to do in case we have a match. Instead, the match clause defines what this rule should match. When we have a match inside a permit rule (and not a deny rule), we execute the set clause, which are the action. In the set statements we can alter the parameter, like the metric or next-hop.

Each rule inside a route map has an ID, that you associate with the permit or deny action. Inside of it, we can find multiple match commands and multiple set commands, creating the match and set clauses. To define each rule, we use the route-map command, followed by the route map name, permit or deny and the ID of the statement. Cisco recommends to use IDs in increment of 10: this will leave some space for further growth. You create the route map by simply creating one of its rules. Furthermore, you can completely omit the match clause in a rule. If you do, the rule will match everything.

Match Clauses: AND and OR

This is probably the most important part of the entire article. If you get this right, you will get route maps right. We know that we can use one or more match statements inside a match clause. The way we use them will change the way the match clause works. To create the match clause, we use the match command. In fact, we can say that all the match commands create the match clause.

In a single match command, you can match one or more items. For example, you can match the source routing protocol and the route map in the same command (in the same line). You are matching two things, so you could also use two different match commands. What is the difference?

The router will consider multiple match conditions in the same line as a logical OR. This means that, if at least one of them is true, the line matches. Instead, match conditions on different lines are a logical AND: they must all be true for the rule to match. We can easily combine the two things together in a single match clause. Here we have an example.

match source-protocol ospf 1 eigrp 65535
match tag 20

This means that we are matching routes with tag 20 coming from either OSPF 1 or EIGRP 65535. If the has not 20 as tag, or if it doesn’t come from neither OSPF 1 nor EIGRP 65535, we don’t have a match. Instead, it doesn’t have to be from OSPF 1 and from EIGRP 65535 at the same time (and it would be impossible).

Note that in the same line you can only match on the same item. For example, you can match on multiple routing protocols, because the item of the match is always the routing protocol. You can’t match, for example, routing protocol and tag on the same line.

ACLs inside a match statement

In a route map, you can use ACLs inside match commands to match against IP addresses. How does the permit and deny instructions inside an ACL relates to the ones inside the route map?

If the ACL returns a deny action, for the route-map the IP address didn’t match the ACL. If, instead, the ACL returns a permit action, the route map considers the IP address to match the ACL. Thus, we can summarize in the following four cases.

Of course, you need to give context to this table. In case you are using multiple statements in logical AND, you need to consider them as well.

The set clause

The set clause is much easier. You just have a list of set commands, and you can apply them all. These commands will only make sense if the action of the route map is permit. Otherwise, the router will simply ignore these commands. However, a permit route map can have no set commands as well. If this is the case, we simply allow the route, and do not perform alteration of any kind.

Multiple rules in a route map

A route map is a set of rules, and this means it can have multiple rules of course. How does the router behaves when we have overlapping match statements between different rules? It is simple, and it works exactly like an ACL. The router processes the rules of a route map in a top-down approach, from the lowest ID to the highest. As soon as we have a match to a rule, we execute that rule and exit. The router won’t execute following rules. We can summarize this behaviour as top-down first-match.

An entire route map

Now that we have the tool to understand (and create) a route map, it is time to create our route map. Take a look at the route map below, and try to understand what it does. Then, check the explanation right after the route map.

route-map OSPF-TO-EIGRP deny 10
 match ip route-source BAD-SOURCE
route-map OSPF-TO-EIGRP deny 20
 match ip address OVERLAPPING-SUBNETS
route-map OSPF-TO-EIGRP deny 30
 match tag 6500
route-map OSPF-TO-EIGRP permit 40
 match ip route-source R3 R4
 set metric 4
 set tag 6500
route-map OSPF-TO-EIGRP permit 50
 set metric 12
 set tag 6500

We have the OSPF-TO-EIGRP route map, that contains 5 rules. In the first rule (10), we do not allow any route coming from any IP address matching the BAD-SOURCE ACL. We are matching on the neighboring router. Instead, in the following rule (20) we block any route that matches the OVERLAPPING-SUBNETS ACL. This time we are matching against the routes, not their sources. In the rule 30, we also deny any route tagged as 6500. Then, in the rule 40 we permit routes coming from routers that match ACLs named R3 and R4. We permit them, but also set metric and tag. Finally, in the last rule (50) we permit all routes and set metric and tag for them.

We can easily apply this rule in a redistribution context, while it would make no sense in a PBR context.

All you can match…

In a route map, you can match against a lot of stuff. Some things may be version-dependent, and you can find them only on some IOS routers. However, here are some common items you can check in a match command.

• as-path, a BGP-specific attribute
• clns, an OSI protocol comparable to IP or UDP
• community, another BGP-specific attribute
• extcommunity, this is for BGP as well
• interface, interface the route (or packet, in case of PBR) is received onto
• ip address, match the target subnet of the route itself (available for ipv6 as well)
• ip route-source, the IP of the router that advertised the route to us (available for ipv6 as well)
• ip next-hop for the route (available for ipv6 as well)
• local-preference, yet another BGP-specific attribute
• metric, of the source routing protocol
• mpls-label, in case you are working with MPLS
• nlri, this is for BGP as well
• policy-list, match against a policy map
• route-type, an attribute of the route: internal, external, local, IS-IS level 1 or IS-IS level 2
• source-protocol, the source routing protocol, including static and connected routes
• tag, the route tag

All you can set…

We can say the same about the attributes we can set. In fact, many of them may depend on IOS version. However, below some of the most common ones you should find on almost any router.

• as-path, a BGP-specific attribute
• automatic-tag automatically sets the route tag
• clns, a OSI protocol comparable to IP or UDP
• comm-list, a BGP setting
• community, another BGP-specific attribute
• dampening, BGP route-flap dampening parameters
• default interface as exit interface
• extcommunity, this is for BGP as well
• interface, interface the route (or packet, in case of PBR) is received onto
• ip address, match the target subnet of the route itself (available for ipv6 as well)
• ip default next-hop for the route
• ip df, Don’t Fragment flag for PBR
• ip next-hop for the route (available for ipv6 as well)
• ip precedence, QoS setting for PBR
• ip qos-group, QoS setting for PBR
• ip tos, yet another QoS setting for PBR
• level, a OSPF-specific attribute
• local-preference, yet another BGP-specific attribute
• metric, of the source routing protocol
• metric-type, the type for metric (e.g. E1, E2)
• mpls-label, in case you are working with MPLS
• nlri, this is for BGP as well
• policy-list, match against a policy map
• origin, BGP origin (IGP, EGP, incomplete)
• route-type, an attribute of the route: internal, external, local, IS-IS level 1 or IS-IS level 2
• source-protocol, the source routing protocol, including static and connected routes
• tag, the route tag
• traffic-index, an index for BGP traffic classification
• vrf, exit VRF, useful for inter-VRF route-leaking
• weight, a Cisco-proprietary BGP attribute local to this router

Applying route maps

A route map, in the end, is a complex rule. It doesn’t do anything (literally), unless we apply it somewhere. As we anticipated at the beginning of the article, we can apply them in two cases: route redistribution and PBR. Just read on…

For Route Redistribution

When applying the route map for redistribution, you use it to tell the allowed routes. Using a route map for redistribution is simple. First, you need to enter the configuration of the protocol that will receive the routes. Then, you use the redistribute command to define the protocol that will generate the route to import. Just after that, you use the keyword route-map and specify the route map name. Take a look at the following example.

router ospf 1
 redistribute eigrp 65535 route-map EIGRP-TO-OSPF subnets

Here we are redistributing EIGRP 65535 into OSPF 1, using the route-map EIGRP-TO-OSPF to filter the routes. The subnets keyword is part of the OSPF configuration. This is it, we now have a working redistribution configuration that leverages a route map.

For Policy-Based Routing (PBR)

Applying a route map to PBR differs from using the same route map in route redistribution. In fact, here the set commands will alter the packets or its routing process (e.g. next-hop). Here, you apply the route map to an interface, and all packets the router receives on that interface will be processed according to the route map. In case the route map has no match, it passes the packet to the standard routing table.

To apply the route map to an interface, we use the command ip policy route-map, followed by the name of the route map. On very old routers, doing this meant the router had to do software-switching. In other words, forwarding of packets on that interface would have been very slow. In later releases, Cisco enabled fast-switching for PBR, that you can enable with ip route-cache policy command under the desired interface. However, modern routers are even better. They now support CEF-switched PBR, at wire speed. In other words, applying PBR doesn’t slow down the traffic at all, and you don’t need any additional command. You can apply only one route map for each interface.

interface GigabitEthernet 0/1
 ip policy route-map PRIVILEGED-ON-SECONDARY-LINK

Here we apply the PRIVILEGED-ON-SECONDARY-LINK route map to the interface GigabitEthernet 0/1. This type of configuration comes with a concern that we need to point out. We make PBR for traffic the router receives, not for traffic the router generates on its own (like management traffic). In some circumstances, we may want to do PBR for the traffic the router generates. In that case, we need to use Local PBR. This simply means applying a PBR route map to router’s traffic, and we do it with ip local policy route-map , in global configuration.

Wrapping it up

In this article got you up and running with route maps. Now you can fine-tune route redistribution, and implement PBR the way you want. If you are in a hurry, here are the key takeaways of this article. You can probably get by with ? in configuration if you know these key points.

• A route map is a set of rules, processed on a top-down first-match basis.
• Each rule can be a permit (default) or deny. The first may also alter some parameters of the route or packet being matched.
• To define if a rule inside a route map matches, you use the match command. Matching multiple items on the same line means joining them with a logical OR, using multiple match commands means joining them with a logical AND.
• You can have multiple set commands inside the same rule.
• A rule with no match command will match anything.
• Apply the route map to the redistribute command if you want to use it for route redistribution.
• Use ip policy route-map on an interface if you want to use the route for PBR; if the route map doesn’t match a packet it will be routed with the normal process.
• For additional reference, consult Cisco documentation.

Hopefully, this knowledge will help you in several circumstances! As always, let me know what you think about route maps and how do you see yourself using them.

The post Route Map Cisco Configuration, an easy tutorial appeared first on ICTShore.com.