Configuring Route Maps
| Like access lists (see Appendix B,"Tutorial: Access Lists"), route maps by themselves affect nothing; they must be "called" by some command. The command will be either a policy routing command or a redistribution command. Policy routing will send packets to the route map, whereas redistribution will send routes to the route map. The case studies in this section demonstrate the use of route maps for both redistribution and policy routing. Route maps are identified by a name . For example, the following route map is named Hagar:
Each route map statement has a "permit" or "deny" action and a sequence number. This route map shows a permit action and a sequence number of 10. These settings are the defaults ”that is, if no action or sequence number is specified when the route map is configured, the route map will default to a permit and a sequence number of 10. The sequence number allows the identification and editing of multiple statements. Consider the following configuration steps:
Here a second and third set of route map statements, each with their own match and set statements, have been added to route map Hagar. Notice that a sequence number of 20 was configured first and then a sequence number of 15. In the final configuration, the IOS has placed statement 15 before 20 even though it was entered later: [1]
The sequence numbers also allow for the elimination of individual statements. For example, the statement:
deletes statement 15 and leaves the other statements intact:
Caution must be used when editing route maps. In this example, if no route-map Hagar had been typed, without specifying a sequence number, the entire route map would have been deleted. Likewise, if no sequence numbers had been specified when the additional match and set statements were added, they would have simply changed statement 10. A packet or route is passed sequentially through route map statements. If a match is made, any set statements are executed and the permit or deny action is executed. As with access lists, processing stops when a match is made and the specified action is executed; the route or packet is not passed to subsequent statements. Consider the following route map:
If a route does not match statement 10, it will be passed to statement 20. If a match is made at statement 20, the set command will be executed and the route will be permitted. The matched route will not be passed on to statement 30. The behavior of a "deny" action depends on whether the route map is being used for policy routing or for redistribution. If a route map is being used for redistribution and a route matches a statement with a deny action, the route will not be redistributed. If the route map is being used for policy routing and a packet matches a statement with a deny action, the packet is not policy routed, but is passed back to the normal routing process for forwarding. Again as with access lists, there must be a default action for the route map to take in the event that a route or packet passes through every statement without a match. An implicit deny exists at the end of every route map. Routes that pass through a redistribution route map without a match are not redistributed, and packets that pass through a policy route map without a match are sent to the normal routing process. Note Implicit deny If no match statement is configured under a route map statement, the default action is to match everything. Each map statement may have multiple match and set statements, as follows :
In a case such as this, every match statement must be matched for the set statements to be executed. Case Study: Policy RoutingPolicy routing is defined with the command ip policy route-map . The command is configured on an interface and affects incoming packets only. Suppose a policy were to be implemented on Linus in Figure 14.3 such that traffic from subnet 172.16.6.0/24 is forwarded to Lucy and traffic from subnet 172.16.7.0/24 is forwarded to Pigpen. Linus's configuration is:
Figure 14.3. Policy routes can be configured at Linus to route some packets through Lucy and other packets through Pigpen. The policy routing command on S0 sends incoming packets to route map Sally. Statement 10 of route map Sally uses access list 1 to identify source addresses from subnet 172.16.6.0/24. If a match is made, the packet is forwarded to Lucy, whose next-hop interface address is 172.16.4.2. If no match is made, the packet is sent to statement 15. That statement uses access list 2 to match source addresses from subnet 172.16.7.0/24. If a match is made at that statement, the packet is forwarded to Pigpen (172.16.4.3). Any packets that do not match statement 15, such as packets sourced from subnet 172.16.8.0/24, are routed normally. Figure 14.4 shows the results of the policy route. [2]
Figure 14.4. The policy route configured on Linus's S0 interface routes packets from subnet 172.16.6.0/24 to Lucy (172.16.4.2) and routes packets from subnet 172.16.7.0/24 to Pigpen (172.16.4.3). Packets from subnet 172.16.8.0/24, which do not match the policy route, are routed normally (load balancing between Lucy and Pigpen). Standard IP access lists are used when policy routing by source address only. To route by both source and destination, an extended IP access list is used. The following configuration causes packets from any subnet to host 172.16.1.1 to be forwarded to Lucy, whereas packets from host 172.16.7.1 to host 172.16.1.2 are forwarded to Pigpen. All other packets are routed normally:
Route map Sally is again used, except the match statements now reference access lists 101 and 102. Figure 14.5 shows the results. Figure 14.5. Packets from host 172.16.7.1 to host 172.16.1.1 match statement 10 of route map Sally and are forwarded to Lucy. Packets from the same host to host 172.16.1.2 are forwarded to Pigpen. Packets from another address on subnet 172.16.7.0/24 to host 172.16.1.2 are not matched by Sally and are routed normally. Next, suppose your policy states that FTP traffic from the servers on subnet 172.16.1.0/24 should be forwarded to Lucy and that Telnet traffic from the same servers should be forwarded to Pigpen. This plan allows the bulk FTP traffic and the bursty , interactive Telnet traffic to be segregated on the two serial links from Schroeder. Schroeder will have the following configuration:
Access lists 105 and 106 are examining not only the source and destination addresses but also the source port. In Figure 14.6 the detail option is used with debug ip packet to allow observation of the packet types being forwarded by Schroeder. An access list 10 limits the displayed packets to those from 172.16.1.1 to 172.16.6.1. Figure 14.6. FTP packets (TCP ports 20 and 21) are being forwarded to Lucy, whereas Telnet packets (TCP port 23) with the same source and destination addresses are forwarded to Pigpen. Echo Reply packets (ICMP type 0), which do not find a match in the policy route, are routed normally. The purpose of segregating bulk and interactive traffic, as demonstrated in the last example, is so that the small packets characteristic of interactive traffic do not become delayed by the large packets characteristic of bulk traffic. The problem with the approach in this example is that if many types of traffic must be segregated, the access lists identifying the traffic by destination port may become prohibitively large. If the objective is to segregate small packets from large packets, the length of the packet can be matched:
Here the match length statement specifies a minimum and a maximum packet size . Statement 20 of the route map causes all packets between 1000 and 1600 octets in length to be routed across the serial link to Lucy. Statement 30 causes all packets up to 400 octets in length to be routed across the serial link to Pigpen. Packets between 400 and 1000 octets are routed normally. Figure 14.7 shows the results of the new route map. Again there are FTP, Telnet, and Echo Reply packets from 172.16.1.2 to 172.16.6.1, but now the packets are routed according to their size instead of their addresses and ports. Figure 14.7. Packets of 1000 octets or larger are routed to Lucy, whereas packets of 400 octets or less are routed to Pigpen. Any packets between 400 and 1000 octets are routed normally. The policy routes demonstrated so far affect packets entering the router from a particular interface. But what about packets generated by the router itself? These can also be policy routed, with the command ip local policy route-map . Unlike the ip policy route-map command, which is configured on an interface, this command is configured globally on the router. To apply the previously demonstrated policy to packets generated by Schroeder, the configuration is:
Of particular interest is statement 10. This statement does not have a set statement, but merely permits packets that match access list 120. Access list 120, in turn , permits all OSPF packets and all packets destined for subnet 172.16.1.0/24. Without the first line of the access list, some packets originated by Schroeder and destined for subnet 172.16.1.0/24 would be forwarded to the wrong interface by statement 20 or 30.Figure 14.8 shows why the second line of the access list is necessary. The length of Schroeder's OSPF Hellos is 44 octets. If statement 10 were not included, the OSPF Hellos would all match statement 30 and be forwarded to Pigpen, breaking the adjacency between Lucy and Schroeder. By matching statement 10, the OSPF packets are permitted with no changes and are forwarded normally. Figure 14.8. The length of the OSPF Hello packets is seen in this analyzer capture. Case Study: Policy Routing and Quality of Service RoutingAlthough Quality of Service (QoS) routing is outside the scope of this volume, it must be noted here that policy routing can be an integral part of QoS. Policy routing in conjunction with QoS is done by setting the Precedence or the Type of Service (TOS) bits of the TOS field in the IP headers of packets as they enter a router's interface.Figure 14.9 shows the bits of the TOS field. Although the TOS bits are seldom used in modern internetworks, the Precedence bits have found new life in QoS applications. The TOS bits are used to influence the path a router selects for a packet, whereas the Precedence bits are used to prioritize packets within a router. Figure 14.9. The Precedence and TOS bits of the Type of Service field of the IP header. The Precedence bits are set by using the set ip Precedence statement within a route map. The Precedence may be set by specifying the decimal equivalent of the three Precedence bits or by using keywords. Table 14.5 shows the decimal numbers and the keywords that can be used. Table 14.5. Precedence values and keywords used with the set ip precedence command.
Table 14.6. TOS values and keywords used with the set ip tos command.
The TOS bits are set by using the set ip tos statement. Like the Precedence statement, the argument of the statement may be a number or a keyword, as shown in Table 14.6. Unlike Precedence, you may use a combination of TOS values. For example, specifying a TOS value of 12 (1100b) means minimum delay and maximum throughput . Only a single keyword can be used, so to set a combination of TOS values, a number must be specified. Figure 14.10 shows an example of how policy routes can be used for QoS routing. Here, router Pogo is at the "edge" of the internet OkefenokeeNet. By configuring policy routes on Pogo's serial links, the Precedence and/or TOS bits of incoming packets can be changed so that IP traffic is divided into several traffic classes. For instance:
Figure 14.10. Policy routes can be used to set the Precedence or TOS bits of packets entering an internetwork. The routers within the internetwork can then make QoS decisions based on the setting of these bits. Statement 10 says that if packets match both access lists 1 and 110, the Precedence will be set to critical . Notice that statement 20 has no match statement. This statement will match any packets that haven't been matched by statement 10. There are also two set statements under statement 20. These statements will set the TOS bits to minimum delay and maximum reliability and will set the Precedence bits to priority . Figure 14.11 shows a capture of a packet from somewhere inside OkefenokeeNet, which has been modified by the route map at Pogo. Figure 14.11. Pogo's policy route has set the Precedence bits of this packet to priority (001b) and the TOS bits to minimum delay and maximum reliability (1010b). After the Precedence or TOS bits have been set in packets entering the internetwork, the routers within the internet can make QoS decisions based in part or wholly on the class of service these bits define. For example, priority, custom, or weighted fair queuing may be configured to prioritize traffic according to the Precedence or TOS bits. In some implementations , Precedence can be used with congestion avoidance mechanisms such as Weighted Random Early Detection (WRED). Or a crude Class-of-Service routing can be implemented by configuring access lists that permit or deny packets across certain links based on the setting of their Precedence or TOS bits. Case Study: Route Maps and RedistributionA route map can be used with redistribution by adding a call to the route map in the redistribute command. Figure 14.12 shows an internetwork in which IS-IS and OSPF routes are being mutually redistributed at router Zippy. Of the network and subnet addresses listed in the illustration, only the ones whose third octet is odd-numbered are to be redistributed. Zippy's configuration is:
Figure 14.12. The OSPF and IS-IS routes are being mutually redistributed. Route maps can be used with the redistribute command as simple route filters, or they can be used to modify characteristics of the redistributed routes. Route maps Griffy and Toad perform the same functions, but with different logic. Griffy uses negative logic, identifying the routes that should not be redistributed, and Toad uses positive logic, identifying the routes that should be redistributed. Statement 10 of Griffy denies any routes that are permitted by access list 1 (the addresses with an even third octet). Because the addresses with odd-numbered third octets do not find a match at statement 10, they are passed to statement 20. Statement 20 has no match statement, so the default is to match everything. Statement 20 has a permit action, so the odd routes are permitted. The result is shown in Figure 14.13. Figure 14.13. The only destinations within the IS-IS domain that are contained in Shelflife's route table are those with an odd-numbered third octet. Route map Toad has a single statement that permits routes that have been permitted by access list 2 (addresses with an odd third octet). The addresses with an even third octet do not find a match at access list 2. The default route map statement when redistributing is to deny all routes, so the addresses that are not matched by access list 2 are not redistributed. Figure 14.13 shows the results of route map Toad. Figure 14.14. The only destinations within the OSPF domain that are contained in Zerbina's route table are those with an odd-numbered third octet. Other configurations will achieve the same ends. For instance, route map Toad will have the same effect with the following access list:
Although route maps work fine as simple route filters, their strength lies in their ability to change the routes in various ways. Consider the following configuration of Zippy in Figure 14.12:
Statement 10 of route map Griffy permits routes to the addresses in access list 1 and redistributes them into OSPF as type 1 external routes. Statement 20 permits all other routes, which will be redistributed with the default external type 2. Figure 14.15 shows the results. Figure 14.15. The routes to destinations in the IS-IS domain are E1 if the third octet of the address is even and E2 if the third octet is odd. Statement 10 of route map Toad permits routes to addresses in access list 2 and redistributes them into IS-IS as level 1 routes. Their metric is set to 15. Statement 20 permits all other routes, which will be redistributed as level 2 and with a metric of 25, as specified by the redistribute command under the IS-IS configuration (Figure 14.16). Figure 14.16. The routes to destinations in the OSPF domain are L2 if the third octet of the address is even and L1 if the third octet is odd. The "odds" are redistributed with a metric of 15, and the "evens" are redistributed with a metric of 25 (10 is added for the hop from Zippy to Zerbina). Case Study: Route TaggingFigure 14.17 shows a situation in which routes from several routing domains, each running a separate routing protocol, are being redistributed into a single transit domain running OSPF. On the other side of the OSPF cloud, the routes must be redistributed back into their respective domains. Route filters can be used at the egress points from the OSPF cloud into each domain to permit only the routes that belong to that domain. However, if each domain has many routes or if the routes within the domain change frequently, the route filters can become difficult to manage Figure 14.17. Routes from each of the three domains on the left are redistributed into a transit internetwork running OSPF. On the right, the routes for each domain must be redistributed back into their original domains. Another way of handling this problem is to tag the routes at their ingress points to the OSPF transit domain with a tag that is unique to each domain. At the egress points, the routes can be redistributed by their tags instead of by specific addresses. The routing protocol of the transit network does not use the tag, but merely conveys it to and from its external networks. RIPv2, EIGRP, Integrated IS-IS and OSPF all support route tags. BGP also supports route tags. Tags are not supported by RIPv1 or IGRP. A reexamination of the packet formats in Chapters 7, "Routing Information Protocol," 8, "Enhanced Interior Gateway Routing Protocol (EIGRP)," and 9, "Open Shortest Path First," show that RIPv2 messages support 16-bit tags, whereas EIGRP external route TLVs and OSPF type 5 LSAs support 32-bit tags. These tags are expressed as decimal numbers, so tags carried by RIPv2 will be between 0 and 65,535, and tags carried by EIGRP and OSPF will be between 0 and 4,294,967,295. In Figure 14.18, router Dagwood is accepting routes from three different routing domains and redistributing them into a domain running OSPF. The objective here is to tag the routes from each domain so that their source domain may be identified within the OSPF cloud. Routes from domain 1 will have a tag of 1, domain 2 will have a tag of 2, and so on. Dagwood's configuration is:
Figure 14.18. Dagwood is configured to tag the routes from each of the three routing domains as they are redistributed into OSPF. First, notice the redistribute igrp command under OSPF. Dagwood is accepting routes from only one IGRP domain, so the tag can be set to 1 directly on the redistribute command. However, routes are being learned from two RIP domains. Here a route map is needed. Route map Dithers sets the tag of the RIP routes to either 2 or 3, depending on whether the route was learned from Funky (10.1.2.3) or Beetle (10.1.2.4). Figure 14.19 shows an LSA advertising one of the RIP-learned routes, with the route tag set to 2. The route tags can also be observed in the OSPF link state database (Figure 14.20). Figure 14.19. This type 5 LSA is advertising network 192.168.2.0, which is in domain 2, within the OSPF domain. The route tag is shown on the last line. Figure 14.20. The OSPF link state database indicates the tags that were set for each of the external routes by Dagwood's redistribution processes. In Figure 14.21, Blondie must redistribute only domain 2 routes to Alley and only domain 1 routes to Oop. Because the routes were tagged as they entered the OSPF transit domain, this is easily done:
Figure 14.21. Blondie is using route maps to redistribute routes according to their route tag. Figure 14.22 shows the resulting routes at Alley and Oop. One drawback to the use of route tags to filter routes is that there is no way to filter routes by interface. For example, if Blondie had to send routes to both domain 2 and domain 3, which both run RIP, route maps cannot be configured to send some routes to one RIP process and other routes to another RIP process. The routes would have to be filtered by address with distribute-list commands. Figure 14.22. The route tables of Alley and Oop in Figure 14.21 show the results of the redistribution configuration at Blondie. |
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}