In this section, we are going to learn about Policy Based Routing (PBR) and the application of this tool Cisco IOS software. However, before delving into the specifics of PBR, it is important to have a fundamental understanding of the forwarding process in Cisco IOS routers.
Routing or Forwarding Packets through Cisco Routers
To route or forward the packets that it has received, the router must perform the following:
- The router must make a routing decision using routing
- The router must forward packets to the next hop destination using switching
The router makes a routing decision by determining if the packet’s destination is reachable by checking for a valid entry for the destination address in the routing table. There are two processes that are involved in the building and maintenance of the routing table in a router. These two processes are comprised of the routing processes and the routing table.
The various routing processes are those processes that actually run a network routing protocol, such as EIGRP, and OSPF. The routing table accepts information from the routing processes.
In order to forward packets to the next hop destination, en route to the destination network, the router uses switching. While the routing process is used to determine the best path to use for moving the traffic to the destination, it is the switching process that actually moves traffic from an input interface to one or more output interfaces. The switching process is sued because it is faster and has lower latency than the routing process. The router can used the switching process can be used to move packets or frames.
Using the switching process, the router must first determine the next hop address toward that destination, and the interface through which that next hop is reachable. Next, the router must rewrite the Media Access Control (MAC) header on the packet so the packet will be able to successfully reach the next hop. It is important to remember that the routing table replies to requests for information from the switching or forwarding process, which requests this information from the routing table to make a packet forwarding or switching decision. In other words, the packet forwarding process relies on the information that is provided by the routing process to make packet forwarding decisions.
Cisco IOS software supports multiple switching paths, which include the following:
- Process Switching
- Fast Switching
- CEF Switching
Process switching is supported in all the Cisco IOS software versions and on all Cisco routing platforms. With process switching, the router first copies the received packet to the system buffer. Next, the router performs a routing lookup for the destination. This is performed to determine the next hop and the output interface. The router then checks the ARP cache to determine the correct Layer 2 address for the next hop. Once the address has been determined, the frame is rewritten with the destination address and sent to the outgoing interface that is connected to that destination. The same switching path is then used for any other subsequent packets for that same destination.
Unlike process switching, fast switching stores the forwarding information and MAC header rewrite string using a binary tree. This allows for faster lookups and references than is with process switching. When packets are fast switched, the first packet is copied to packet memory and the destination network is found in the fast-switching cache which is derived from the binary tree structure. This negates the need to check the ARP cache to determine the correct Layer 2 address for the next hop. The frame is then rewritten and sent to the outgoing interface that services the destination. The same switching path is then used for any other subsequent packets for that same destination.
Cisco Express Forwarding (CEF) switching uses a trie instead of a binary tree. This means the actual information being searched for is not in the data structure; instead, the data is stored in a separate data structure, and the trie simply points to it. In other words, rather than storing the outbound interface and MAC header rewrite within the tree itself, CEF stores this information in a separate data structure. This separate data structure is called the Adjacency Table.
In addition to the Adjacency Table which is created to contain all connected next hops, CEF also uses another data structure referred to as the Forwarding Information Base (FIB). The FIB is used to make IP destination prefix-based switching decisions. The FIB is conceptually similar to a routing table or information base in that it maintains a mirror image of the forwarding information contained in the IP routing table.
NOTE: Both fast switching and CEF are classified as interrupt context switching processes. CEF is described in detail in the SWITCH guide in the chapter on Multilayer Switching
Now that we have a solid understanding of how traditional routing and forwarding works, we can delve into the specifics of Policy Based Routing so as to understand how it differs from traditional forwarding as described in the previous sections.
Understanding Policy Based Routing
Regardless of the routing or switching process implemented on the router, traditional routers forward traffic based on the destination address. While different path control techniques and configurations can be applied by the administrator to influence the path taken to a specific destination network, it is almost possible to configure the path a single routing protocol will take to route traffic from a particular source network to a specific destination network. To accomplish such objectives, Policy Based Routing (PBR) must be implemented.
PBR provides a flexible mechanism for network administrators to customize the operation of the routing table and the flow of traffic within their networks. When configured, PBR takes precedence over the traditional router forwarding process. In other words, all packets received on an interface with PBR routing enabled are considered for PBR routing before the normal routing process is considered. In other words, if PBR is configured on the router, after the router receives a packet, it first looks at the PBR configuration to determine how to forward the packet based on the criteria specified in this configuration. If the packet does not match any of the configured PBR policies, then the packet will be routed using the normal forwarding process.
When implemented, PBR routing is applied to either incoming packets or for packets that are originated by the router itself depending on the manner in which the configuration is applied to the router. Within Cisco IOS software, PBR is implemented using route maps, which are described in detail in the previous chapter. Leveraging the match and set capabilities of route maps, PBR can be implemented to influence the path taken to a destination based on:
- The identity of a particular host
- An application
- A specific protocol
- The packet size
- The source network
Route Map Match Clauses for Policy Based Routing
Within the route map, PBR is configured to match on the specified criteria using match clauses which are configured by using the match subcommand. When configuring match clauses for PBR, Cisco IOS software supports matches against standard or extended named or numbered ACLs. Using extended ACLs provides greater granularity in that they can match based on application, protocol type, as well as on Quality of Service parameters, such as Type of Service (TOS), IP Precedence and the Differentiated Services Code Point (DSCP) value.
NOTE: Advanced QoS knowledge is beyond the scope of the ROUTE. However, QoS is a core requirement of the SWITCH exam and is included in the chapter on LAN QoS. Refer to that guide for more information on TOS, IP Precedence and DSCP.
The second match criteria that can be specified when configuring the route maps for PBR is the packet length. Cisco IOS software allows you to specify a minimum and maximum packet length, which can be used to distinguish between interactive and bulk traffic. Interactive traffic typically has smaller packet sizes whereas bulk traffic usually has larger packet sizes.
In most cases, a single match clause is used, for example, to reference an ACL that matches a particular source network. However, when configuring PBR, multiple match clauses may be used within the same route map statement. If multiple match clauses are used, the packet must meet all specified criteria before a positive match is made. When PBR is implemented, the policy routing process proceeds through the route map until a match is found. By default, there is an implicit deny at the end of the list of match statements. Therefore, if no match is found in the route map, or the route map entry is a deny statement instead of a permit statement, then normal destination based routing of the traffic ensues.
When configuring matching against ACLs, the match ip address [<1-199> | <1300-2699> | <name>]subcommand is used within the route map to match against a named or numbered ACL. When matching against the packet length, the match length <minimum length> <maximum length> subcommand is used within the route map to match packets within the specified packet size range.
Route Map Set Clauses for Policy Based Routing
If the packet or packets satisfy the match clause(s) defined within the route map, the next action is to apply one or more set clauses before the packet is forwarded to the destination. Set clause configuration is specified using the set subcommand in route map configuration mode. Although more than one set clause can be specified, set clauses specifying a next hop IP address or egress interface are always evaluated in a specific order. These setstatements are evaluated in the following order:
- The list of next hop IP addresses
- The list of specified interfaces
- The list of default next hop IP addresses
- The list of default interfaces
The list of next hop IP addresses is specified using the set ip next-hop [<address> | verify-availability <address> <sequence> track <object number>] route map mode subcommand.
The <address> specifies the next hop IP address. If this address is reachable, the router will send the packets that satisfy the match clause to this IP address. If the address is not reachable, the router will use the path to the destination network that is stored in the routing table. If the address is not reachable and there is no entry in the routing table for the destination network, then the packet is simply dropped.
The verify-vailability <address> <sequence> track <object number>] keywords are used when PBR is configured in conjunction with IP SLA operations. This configuration allows PBR to verify that the specified next hop address is reachable based on IP SLA operations reporting for the tracked object. This will be described later in this chapter.
The list of specified interfaces is configured using the set interface [name] subcommand. This command is used to indicate the egress interface for packets that pass a match clause of route map for policy routing. When more than one interface is specified, the router will forward packets using out the first interface that is in an up state. The operation of PBR when the set interface command is specified is not as simple as it may appear. First, this command should be used for point-to-point interfaces unless a route-cache entry, e.g. in the Cisco Express Forwarding table which was described earlier in this section, exists using the same interface. If no cache entry exists and a FastEthernet interface is specified, for example, the command is ignored and the normal forwarding process is used.
Additionally, when this command is specified, the router will also validate that it has an explicit route to the specified destination network in the routing table before it forwards the packets. If no there is no explicit, or if only a default route is present in the routing table, the command will also be ignored. It is important to ensure these conditions are met prior to using this command.
The list of default next hop IP addresses is specified using the set ip default next-hop [<address> | verify-availability] subcommand. When this command is specified, if the router has an explicit route to the specified destination network, i.e. via a routing protocol, it will use that route first and ignore the PBR configuration. However, if only a default route exists in the routing table, the router will execute this command instead of using the default route to forward packets to the specified destination network.
The verify-availability keyword is used to force the router to check the Cisco Discovery Protocol (CDP) database to determine if an entry is available for the next hop that is specified by the set ip default next-hop command. This command prevents traffic from being black holed in situations where the specified next hop IP address is not directly connected to the router, for example. In such cases, if the specified next hop IP address does become unreachable, the router would never know and will continue sending packets to it, resulting in a black holing of traffic. This keyword is applied using a separate line in the route map.
The list of default interfaces is specified using the set default interface [name] subcommand. As is the case with the set ip default next-hop command, if an explicit route entry for the destination is present in the routing table, this command is ignored. However, if no explicit route entry for the destination network exists, or the router only has a default route, this command is applied.
Applying the Policy Based Routing Configuration
Following the configuration of the desired route map permit and deny statements, along with the relevant match and set clauses, the PBR configuration can be applied to an interface for ingress traffic using the ip policy route-map [name] interface configuration command. Only one instance of this command can be specified per interface. If you configure another instance of this command, the previous entry will be removed and replaced with the new entry.
By default, PBR configuration applied to the interface does not affect traffic originated by the router itself. To apply the PBR configuration to traffic originated by the router, local policy routing must be configured by using the ip local policy route-map [name] global configuration command. The following section contains several PBR configuration examples to reinforce the concepts described in the sections above.
Configuring and Verifying Policy Based Routing in Cisco IOS Software
The PBR configuration examples in this section are based on the topology shown in Figure 4-4:
Fig. 4-4. Configuring and Verifying Policy Based Routing
Figure 4-4 shows a basic network. R2 is connected to R1, R3, and R5. R1 and R3 are advertising the 10.80.80.0/24 subnet via EIGRP as an external route. Based on the redistribution configuration implemented on these routers, R2 prefers the path via R1 to this network as it has the better metric. R2 is also receiving internal EIGRP routes from R5. Based on this implementation, the routing table on router R5 shows the following network entries:
| R2#show ip route eigrp 10.0.0.0/24 is subnetted, 6 subnets D EX 10.80.80.0 [170/2172416] via 10.0.1.1, 00:08:14, Serial0/0 D 10.20.20.0 [90/156160] via 10.0.0.5, 00:01:20, FastEthernet0/0 D 10.10.10.0 [90/156160] via 10.0.0.5, 00:01:20, FastEthernet0/0 |
Management has requested that all traffic sourced from the 10.10.10.0/24 subnet use the path via R2 to reach only server 10.80.80.254, while all traffic sourced from the 10.20.20.0/24 subnet continue to use the primary path via R1. The current path taken by the 10.10.10.0/24 subnet to the 10.80.80.254 server is via R1 as illustrated in the following Traceroute issued from R5:
| R5#traceroute ipTarget IP address: 10.80.80.254 Source address: 10.10.10.5 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.80.80.2541 R2-Fa0-Interface (10.0.0.2) 4 msec 4 msec 4 msec 2 R1-Se0-Interface (10.0.1.1) 4 msec * 4 msec |
To satisfy this requirement, the following PBR configuration would be implemented on R2:
| R2(config)#ip access-list extended Net-10-To-Server-Only R2(config-ext-nacl)#permit ip 10.10.10.0 0.0.0.255 host 10.80.80.254 R2(config-ext-nacl)#exit R2(config)#route-map Policy-Route-Net-10-To-Server R2(config-route-map)#match ip address Net-10-To-Server-Only R2(config-route-map)#set ip next-hop 10.0.3.3 R2(config-route-map)#exit R2(config)#interface fastethernet 0/0 R2(config-if)#ip policy route-map Policy-Route-Net-10-To-Server R2(config-if)#exit |
In the configuration above, an extended ACL is configured to match only traffic sourced from the 10.10.10.0/24 subnet destined to host 10.80.80.254 is matched. This ensures that all other traffic from the 10.10.10.0/24 to any other destination is not policy routed. Next, the route map is configured to match the extended ACL. The set ip next-hop command is then used to forward packets that match this statement to 10.0.3.3, which is R3s Serial0/0 interface. Finally, the PBR configuration is applied to FastEthernet0/0 on R2. This is the ingress interface for packets sourced from the 10.10.10.0/24 subnet. Following this configuration, the Traceroute from R5 to the 10.80.80.254 address now shows the following:
| R5#traceroute ipTarget IP address: 10.80.80.254 Source address: 10.10.10.5 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.80.80.2541 R2-Fa0-Interface (10.0.0.2) 4 msec 4 msec 4 msec 2 R3-Se0-Interface (10.0.3.3) 4 msec 4 msec 4 msec |
However, any other traffic sourced from the 10.10.10.0/24 subnet to any other address other than 10.80.80.254 will not be policy routed as it will not satisfy the match clause in the route map and because there is an implicit deny at the end of the route map. This is validated by tracing the route from the 10.10.10.0/24 to any other address as illustrated below:
| R5#traceroute ipTarget IP address: 10.80.80.100 Source address: 10.10.10.5 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.80.80.1001 R2-Fa0-Interface (10.0.0.2) 4 msec 4 msec 0 msec 2 R1-Se0-Interface (10.0.1.1) 4 msec 4 msec 4 msec |
The show route-map [name] command can be used on the router on which the Policy Based Routing configuration has been implemented to view matches against the configured policy. The output of this command is shown below:
| R2#show route-map Policy-Route-Net-10-To-Server route-map Policy-Route-Net-10-To-Server, permit, sequence 10 Match clauses: ip address (access-lists): Net-10-To-Server-Only Set clauses: ip next-hop 10.0.3.3 Policy routing matches: 6 packets, 360 bytes |
To view real-time (debugging) information on policy routing decisions, you can use the debug ip policy command. When debugging PBR, keep in mind that as with any other debugging commands, you should exercise caution when enabling them in production networks. In the following output, PBR debugging is enabled on R2 to view real-time policy routing operation:
| R2#debug ip policy Policy routing debugging is on |
Next, a simple ping is initiated from R5, sourced from the 10.10.10.5 address, to the server with the address 10.80.80.254. This is performed as follows:
| R5#ping 10.80.80.254 source 10.10.10.5Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.80.80.254, timeout is 2 seconds: Packet sent with a source address of 10.10.10.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms |
Going back to R2, the debug output shows the following:
| *Mar 2 00:08:36.635: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.254, len 100, FIB policy match *Mar 2 00:08:36.635: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.254, g=10.0.3.3, len 100,FIB policy routed[Truncated Output] |
NOTE: The FIB is the Forwarding Information Base used with Cisco Express Forwarding. If CEF is not enabled on the router, the debug output would show the following instead:
| *Mar 2 00:15:17.332: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.254, len 100, policy match *Mar 2 00:15:17.332: IP: route map Policy-Route-Net-10-To-Server, item 10, permit *Mar 2 00:15:17.332: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.254 (Serial0/1), len 100,policy routed *Mar 2 00:15:17.336: IP: FastEthernet0/0 to Serial0/1 10.0.3.3[Truncated Output] |
If, for example, a ping was sourced from the 10.10.10.0/24 subnet to any other address, these packets would not satisfy the PBR match clause and would not be policy routed. The packets would be forwarded using the normal forwarding process. In that case, the debug output would show the following:
| *Mar 2 00:08:04.911: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.100, len 100, FIB policy rejected(no match) – normal forwarding *Mar 2 00:08:04.915: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.100, len 100, FIB policy rejected(no match) – normal forwarding[Truncated Output] |
If CEF is not enabled, the debugging output shows the following instead:
| *Mar 2 00:20:59.741: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.100 (Serial0/0), len 100,policy rejected — normal forwarding *Mar 2 00:21:01.744: IP: s=10.10.10.5 (FastEthernet0/0), d=10.80.80.100 (Serial0/0), len 100,policy rejected — normal forwarding[Truncated Output] |
Continuing with the PBR configuration examples, assume that management has now requested that all packets between 219 bytes and 1500 bytes from any subnet destined to the 10.80.80.254 address should be forwarded out the Serial0/1 interface. All other packets to this host, or any other destination, should be forwarded using the normal forwarding process. The configuration would be implemented as follows on router R2:
| R2(config)#ip access-list extended To-Match-Large-Packets-To-Host R2(config-ext-nacl)#permit ip any host 10.80.80.254 R2(config-ext-nacl)#exit R2(config)#route-map To-Policy-Route-Large-Packets R2(config-route-map)#match ip address To-Match-Large-Packets-To-Host R2(config-route-map)#match length 219 1500 R2(config-route-map)#set interface serial 0/1 R2(config-route-map)#exit R2(config)#interface fastethernet 0/0 R2(config-if)#ip policy route-map To-Policy-Route-Large-Packets R2(config-if)#exit |
To validate this configuration, an 800 byte ping is sourced from the 10.20.20.0/25 subnet to host 10.80.80.254 host address. This ping is sourced from R5 as illustrated in the following output:
| R5#ping 10.80.80.254 source 10.20.20.5 size 800Type escape sequence to abort. Sending 5, 800-byte ICMP Echos to 10.80.80.254, timeout is 2 seconds: Packet sent with a source address of 10.20.20.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/16 ms |
We can then use the show route-map command to validate the policy routing configuration:
| R2#show route-map To-Policy-Route-Large-Packets route-map Policy-Route-Large-Packets, permit, sequence 10 Match clauses: ip address (access-lists): To-Match-Large-Packets-To-Host length 219 1500 Set clauses: interface Serial0/1 Policy routing matches: 5 packets, 4070 bytes |
The output of the debug ip policy command confirms the same as illustrated below:
| *Mar 2 01:57:00.376: IP: s=10.20.20.5 (FastEthernet0/0), d=10.80.80.254, len 800, FIB policy match *Mar 2 01:57:00.376: fibidb->namestring: Serial0/1 *Mar 2 01:57:00.380: ipfib_policy_set_interface_lookup: tag_ptr: 0x0 *Mar 2 01:57:00.380: adj 0x0, NULL *Mar 2 01:57:00.380: IP: s=10.20.20.5 (FastEthernet0/0), d=10.80.80.254 (Serial0/1), len 800, FIB policy routed[Truncated Output] |
If Cisco Express Forwarding was not enabled, the debug output would show the following:
| *Mar 2 01:59:23.227: IP: s=10.20.20.5 (FastEthernet0/0), d=10.80.80.254, len 800, policy match *Mar 2 01:59:23.227: IP: route map To-Policy-Route-Large-Packets, item 10, permit *Mar 2 01:59:23.227: IP: s=10.20.20.5 (FastEthernet0/0), d=10.80.80.254 (Serial0/1), len 800, policy routed |
As a final configuration example, assume that you have been requested to ensure that all Telnet traffic from R2 to the 10.80.80.0/24 subnet is policy routed out of the Serial0/1 interface with an IP precedence value of 3. This configuration would be implemented as follows:
| R2(config)#access-list 100 permit icmp any 10.80.80.0 0.0.0.255 echo R2(config)#route-map Policy-Route-Locally-Originated-PINGs R2(config-route-map)#match ip address 100 R2(config-route-map)#set interface serial 0/1 R2(config-route-map)#set ip precedence 3 R2(config-route-map)#exit R2(config)#ip local policy route-map Policy-Route-Locally-Originated-PINGs R2(config)#exit |
This configuration can be validated by pinging from R2 to either R3 or R1 as shown below:
| R2#ping 10.80.80.1 repeat 20Type escape sequence to abort. Sending 20, 100-byte ICMP Echos to 10.80.80.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (20/20), round-trip min/avg/max = 4/4/4 ms |
The output of the show route-map command shows that the traffic has been policy routed:
| R2#show route-map Policy-Route-Locally-Originated-PINGs route-map Policy-Route-Local-Telnet, permit, sequence 10 Match clauses: ip address (access-lists): 100 Set clauses: ip precedence flash interface Serial0/1 Policy routing matches: 20 packets, 2000 bytes |
The output of the debug ip policy command also confirms the same:
| *Mar 2 02:10:42.192: IP: s=10.0.1.2 (local), d=10.80.80.1, len 100, policy match *Mar 2 02:10:42.192: IP: route map Policy-Route-Locally-Originated-PINGs, item 10, permit *Mar 2 02:10:42.192: IP: s=10.0.1.2 (local), d=10.80.80.1 (Serial0/1), len 100, policy routed *Mar 2 02:10:42.196: IP: local to Serial0/1 10.80.80.1[Truncated Output] |
While the debug output will not show the QoS implementation configured using the set ip precedence operation, this can be validated by checking configured QoS policies on the outbound router interface. For example, assuming that the Modula QoS CLI has been used to configure an outbound QoS policy for Serial0/1 that matches packets with an IP Precedence value of 5, 4, or 3, following the ping sourced from R1 to 10.80.80.1, the QoS policy would show the following matches:
| R2#show policy-map interface serial 0/1 output Serial0/1Service-policy output: QoS-Outbound-PolicyClass-map: Match-IP-Precedence-5 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 5 Traffic Shaping Target/Average Byte Sustain Excess Interval Increment Rate Limit bits/int bits/int (ms) (bytes) 512000/512000 3200 12800 12800 25 1600 Adapt Queue Packets Bytes Packets Bytes Shaping Class-map: Match-IP-Precedence-4 (match-all) Adapt Queue Packets Bytes Packets Bytes Shaping Class-map: Match-IP-Precedence-3 (match-all) Adapt Queue Packets Bytes Packets Bytes Shaping |
PBR Tracking with IP SLA Operations
As was stated earlier in this section, the verify-vailability <address> <sequence> track <object number>]keywords are used when PBR is configured in conjunction with IP SLA operations. This configuration allows PBR to verify that the specified next hop address is reachable based on IP SLA operations reporting for the tracked object. The following sequence of steps is required to configure PBR tracking with Cisco IOS IP SLA Operations:
- Configure the Cisco IOS IP SLA Operation
- Configure Enhanced Object Tracking
- Configure PBR to verify next-hop-reachability
NOTE: You will not be expected to implement any such advanced configurations in the current ROUTE exam; however, ensure that you are familiar with this capability when using PBR.
Referencing Figure 4-4, which was used in the previous PBR configuration examples, R2 is now configured for to policy route all traffic via R2 if the IP SLA Operation being tracked is reported as reachable. If not, R2 will policy route all traffic via R1:
NOTE: The following configuration is based on pre-12.4(4)T Cisco IOS software versions.
| R2(config)#ip sla monitor 1 R2(config-sla-monitor)#type echo protocol ipIcmpEcho 10.0.3.3 R2(config-sla-monitor-echo)#frequency 5 R2(config-sla-monitor-echo)#exit R2(config)#ip sla monitor 2 R2(config-sla-monitor)#type echo protocol ipIcmpEcho 10.0.1.1 R2(config-sla-monitor-echo)#frequency 5 R2(config-sla-monitor-echo)#exit R2(config)#ip sla monitor schedule 1 life forever start-time now R2(config)#ip sla monitor schedule 2 life forever start-time now R2(config)#track 1 rtr 1 reachability R2(config-track)#exit R2(config)#track 2 rtr 2 reachability R2(config-track)#exit R2(config)#ip access-list extended Match-All-Traffic R2(config-ext-nacl)#permit ip any any R2(config-ext-nacl)#exit R2(config)#route-map Policy-Route-All-Traffic permit 10 R2(config-route-map)#match ip address Match-All-Traffic R2(config-route-map)#set ip next-hop verify-availability 10.0.3.3 1 track 1 R2(config-route-map)#set ip next-hop verify-availability 10.0.1.1 2 track 2 R2(config-route-map)#exit R2(config)#interface fastethernet 0/0 R2(config-if)#ip policy route-map Policy-Route-All-Traffic R2(config-if)#exit |
The show track command can be used to verify the configuration by listing the IP SLA Operation and the process that is tracking it as illustrated in the following output:
| R2#show track Track 1 Response Time Reporter 1 reachability Reachability is Up 4 changes, last change 00:11:18 Latest operation return code: OK Latest RTT (millisecs) 1 Tracked by: ROUTE-MAP 0 Track 2 Response Time Reporter 2 reachability Reachability is Up 4 changes, last change 00:11:18 Latest operation return code: OK Latest RTT (millisecs) 1 Tracked by: ROUTE-MAP 0 |
To validate this configuration, a simple ping is initiated from R5 to server 10.80.80.254:
| R5#ping 10.80.80.1 repeat 20Type escape sequence to abort. Sending 20, 100-byte ICMP Echos to 10.80.80.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (20/20), round-trip min/avg/max = 4/4/4 ms |
The output of the show route-map command shows that the traffic is policy routed:
| R2#show route-map Policy-Route-All-Traffic route-map Policy-Route-All-Traffic, permit, sequence 10 Match clauses: ip address (access-lists): Match-All-Traffic Set clauses: ip next-hop verify-availability 10.0.3.3 1 track 1 [up] ip next-hop verify-availability 10.0.1.1 2 track 2 [up] Policy routing matches: 20 packets, 2280 bytes |
NOTE: In 12.4(4)T and above, the same configuration would be implemented as follows:
| R2(config)#ip sla 1 R2(config-sla-monitor)#icmp-echo 10.0.3.3 R2(config-sla-monitor-echo)#frequency 5 R2(config-sla-monitor-echo)#exit R2(config)#ip sla 2 R2(config-sla-monitor)#icmp-echo 10.0.1.1 R2(config-sla-monitor-echo)#frequency 5 R2(config-sla-monitor-echo)#exit R2(config)#ip sla schedule 1 life forever start-time now R2(config)#ip sla schedule 2 life forever start-time now R2(config)#track 1 ip sla 1 reachability R2(config-track)#exit R2(config)#track 2 ip sla 2 reachability R2(config-track)#exit R2(config)#ip access-list extended Match-All-Traffic R2(config-ext-nacl)#permit ip any any R2(config-ext-nacl)#exit R2(config)#route-map Policy-Route-All-Traffic permit 10 R2(config-route-map)#match ip address Match-All-Traffic R2(config-route-map)#set ip next-hop verify-availability 10.0.3.3 1 track 1 R2(config-route-map)#set ip next-hop verify-availability 10.0.1.1 2 track 2 R2(config-route-map)#exit R2(config)#interface fastethernet 0/0 R2(config-if)#ip policy route-map Policy-Route-All-Traffic R2(config-if)#exit |
The Advantages of Using Policy Based Routing
We will conclude this section, and chapter, by discussing the advantages of using Policy Based Routing. These advantages are as follows:
- Source-Based Transit Provider Selection
- Quality of Service (QoS)
- Cost Savings via load sharing
Source-based transit provider selection means that PBR can be used to selectively route traffic from different source networks or hosts to different egress interfaces on the router. As was illustrated in the previous configuration examples, PBR can be used to route the traffic from a specific source network or host to a specific destination network or host. This is not possible using a routing protocol alone.
In addition to forwarding packets, PBR can also be used to apply QoS settings to packets. The QoS settings may be the Type of Service, IP Precedence or a DSCP value. Setting the QoS bits allows traffic flows to be differentiated from one another. This allows certain classes of traffic to be prioritized over other classes of traffic.
And finally, PBR can be used to load share traffic between different paths based on the traffic type. For example, PBR can be used to load share interactive and bulk traffic between low-cost permanent paths and high-bandwidth, high-cost, switched paths. Routing protocols cannot load balance depending on traffic types, so PBR offers added flexibility within the Cisco IOS. This provides cost savings because the paths are utilized rather than sitting idle.