Policy-Based Routing and IP Service Level Agreement

标签：

Topics

• Policy-Based Routing(PBR): IOS PBR Feature
• IP Service Level Agreement: 

Policy-Based Routing (PBR), also sometimes called simply Policy Routing, influences the IP data plane, changing the forwarding decision a router makes,but without first changing the IP routing table.

IP Service-Level Agreement(SLA), monitors network health and reachability. The router can then choose when to use routes, and when to ignore routes, based on the status determined by IP SLA.

Part 1: Policy-Based Routing

When a packet arrives at the incoming interface of a router, the router’s data plane processing logic takes several steps to process the packet.

• The incoming packet actually arrives encapsulated inside a data link layer frame, so the router must check the incoming frame’s Frame Check Sequence (FCS) and discard the frame if errors occurred in transmission.
• If the FCS check passes, the router discards the incoming frame’s data link header and trailer, leaving the Layer 3 packet.
• Finally, the router does the equivalent of comparing the destination IP address of the packet with the IP routing table, matching the longest-prefix route that matches the destination IP address.

Note: Most routers today default to use Cisco Express Forwarding (CEF), which causes the router to match the destination of IP packets with the CEF table, instead of the IP routing table. IOS derives the CEF table from the information in the IP routing table, with much faster table lookup as compared with using the routing table directly.

Policy-Based Routing (PBR) overrides the router’s natural destination-based forwarding logic. PBR intercepts the packet after de-encapsulation on the incoming interface, before the router performs the CEF table lookup. PBR then chooses how to forward the packet using criteria other than the usual matching of the packet’s destination address with the CEF table.

PBR chooses how to forward the packet by using matching logic defined through a route map, which in turn typically refers to an IP ACL. That same route map also defines the forwarding instructions–the next-hop IP address or outgoing interface–for packets matched by the route map. Figure shows the general concept, with PBR on interface F0/0 overriding the usual routing logic, forwarding packets out three different outgoing interfaces.

To perform the actions shown in Figure, the engineer configures two general steps:

• Step 1. Create a route map with the logic to match packets, and choose the route, as shown on the left side of the figure.
• Step 2. Enable the route map for use with PBR, on an interface, for packets entering the interface.

1. Matching the Packet and Setting the Route

match ip address
match length min max

• The match ip address command can reference standard and extended ACLs. Any item matchable by an ACL can be matched in the route map.
• The match length command allows you to specify a range of lengths, in bytes.

When a route map clause (with a permit action) matches a packet, the set command defines the action to take regarding how to forward the packet. The four set command options define either the outgoing interface or the next-hop IP address, just like routes in the IP routing table.

After the route map has been configured with all the clauses to match packets, and set their outgoing interface or next-hop address, the only remaining step requires the ip policy route-map name command to enable PBR for packets entering an interface.

2. PBR Configuration Example

In this case, EIGRP on R1 chooses the upper route to reach the subnets on the right, because of the higher bandwidth on the upper link (T1) as compared with the lower link (64 Kbps).

For this example, the PBR configuration matches packets sent from PC2 on the left to server S1 in subnet 10.1.3.0/24 on the right. PBR on R1 routes these packets out S0/0/1 to R4. These packets will be routed over the lower path–out R1’s S0/0/1 to R4–instead of through the current through R2, as listed in R1’s IP routing table.

R1 PBR Configuration

interface Fastethernet 0/0
ip address 10.1.1.9 255.255.255.0
ip policy route-map PC2-over-low-route
!
route-map PC2-over-low-route permit
match ip address 101
set ip next-hop 10.1.14.4
!
access-list 101 permit ip host 10.1.1.2 10.1.3.0 0.0.0.255

Note that for each packet entering F0/0, PBR either matches the packet with a route map permit clause, or matches the packet with a route map deny clause. All route maps have an
implicit deny clause at the end that matches all packets not already matched by the route map. PBR processes packets that match a permit clause using the defined set command.
For packets matched by a deny clause, PBR lets the packet go through to the normal IP routing process.

The show ip policy command just shows the interfaces on which PBR is enabled and the route map used.

The show ip route-map command shows overall statistics for the number of packets matching the route map for PBR purposes.

The only way to verify the types of packets that are policy routed is to use the debug ip policy command, which can be dangerous on production routers, given its multiple lines of output per packet, or to use traceroute.

R1# show ip policy
Interface 　　Route map
Fa0/0 　　　　PC2-over-low-route

R1# show route-map
route-map 　　PC2-over-low-route, 　　permit, 　　sequence 10
　　Match clauses:
　　　　ip address (access-lists): 101
　　Set clauses:
　　　　ip next-hop 10.1.14.4
　　Policy routing matches: 12 packets, 720 bytes

R1# debug ip policy
*Sep 14 16:57:51.675: IP: s=10.1.1.2 (FastEthernet0/0), d=10.1.3.99, len 28, policy match
*Sep 14 16:57:51.675: IP: route map PC2-over-low-route, item 10, permit
*Sep 14 16:57:51.675: IP: s=10.1.1.2 (FastEthernet0/0), d=10.1.3.99 (Serial0/0/1), len 28, policy routed
*Sep 14 16:57:51.675: IP: FastEthernet0/0 to Serial0/0/1 10.1.14.4

3. How the default Keyword Impacts PBR Logic Odering

The example in the previous section showed a set command that did not use the default keyword. However, the inclusion or omission of this keyword significantly impacts how PBR works.

This parameter in effect tells IOS whether to apply PBR logic before trying to use normal destination-based routing,

　　or whether to first try to use the normal destination-based routing, relying on PBR’s logic only if the destination-based routing logic fails to match a nondefault route.

First, consider the case in which the set command omits the default parameter. When IOS matches the associated PBR route map permit clause, IOS applies the PBR logic first. If
the set command identifies an outgoing interface that is up, or a next-hop router that is reachable, IOS uses the PBR-defined route. However, if the PBR route (as defined in the
set command) is not working–because the outgoing interface is down or the next hop is unreachable using a connected route–then IOS next tries to route the packet using the normal destination-based IP routing process.

Next, consider the case in which the set command includes the default parameter. When IOS matches the associated PBR route map permit clause, IOS applies the normal destination- based routing logic first, with one small exception: it ignores any default routes. So, the router first tries to route the packet as normal, but if no nondefault route matches the packet’s destination address, then the router forwards the packet as directed in the set command.

For example, for the configuration shown in Example, by changing the set command to set ip default next-hop 10.1.14.4, R1 would have first looked for (and found) a working route through R2, and forwarded packets sent by PC2 over the link to R2. Summarizing:

• Omitting the default parameter gives you logic like this: “Try PBR first, and if PBR’s route does not work, try to route as usual.”
• Including the default parameter gives you logic like this: “Try to route as usual while ignoring any default routes, but if normal routing fails, use PBR.”

4. Additional PBR Functions

Applying PBR to Locally Created Packets

In some cases, it may be useful to use PBR to process packets generated by the router itself. However, PBR normally processes packets that enter the interface(s) on which the ip
policy route-map command has been configured, and packets generated by the router itself do not actually enter the router through some interface. To make IOS process locally
created packets using PBR logic, configure the ip local policy route-map name global command, referring to the PBR route map at the end of the command.

Setting IP Precedence

Quality of service (QoS) refers to the entire process of how the network infrastructure can choose to apply different levels of service to different packets. For example, a router may need to keep delay and jitter (delay variation) low for VoIP and Video over IP packets, because these interactive voice and video calls only work well when the delay and jitter are held very low. So, the router might let VoIP packets bypass a long queue of data packets that might be waiting to exit an interface, giving the voice packet better (lower) delay and jitter.

Most QoS designs mark each packet with a different value inside the IP header, for the purpose of identifying groups of packets–a service class–that should get a particular QoS treatment. For instance, all VoIP packets could be marked with a particular value so that the router can then find those marked bits, know that the packet is a VoIP packet due to that marking, and apply QoS accordingly. Although the most commonly used QoS marking tool today is Class-Based Marking, in the past, PBR was one of the few tools that could be used for this important QoS function of marking packets. PBR still supports marking; however, most modern QoS designs ignore PBR’s marking capabilities.

Before discussing PBR’s marking features, a little background about the historical view of the IP header’s type of service (ToS) byte is needed. The IP header originally defined a ToS byte whose individual bits have been defined in a couple of ways over the years. One such definition used the first three bits in the ToS byte as a three-bit IP Precedence (IPP) field, which could be used for generic QoS marking, with the higher values generally implying a better QoS treatment. Back in the 1990s, the ToS byte was redefined as the Differentiated Services (DS) byte, with the first six bits defined as the Differentiated Service Code Point (DSCP). Most QoS implementations today revolve around setting the DSCP field.

PBR supports setting the older QoS marking fields—the IP Precedence (IPP) and the entire ToS byte—using commands set ip precedence value and set ip tos value, respectively, in the route map. To configure packet marking, configure PBR as normal, but add a set command that defines the field to be marked and the value.

PBR with IP SLA

Besides matching a packet’s length, or matching a packet with an ACL, PBR can also react to some dynamic measurements of the health of the IP network. To do so, PBR relies on the IP Service-Level Agreement (IP SLA) tool. In short, if the IP SLA tool measures the network’s current performance, and the performance does not meet the defined threshold, PBR chooses to not use a particular route.

Part 2: IP Service-Level Agreement

The IOS IP Service-Level Agreement (IP SLA) feature measures the ongoing behavior of the network. The measurement can be as simple as using the equivalent of a ping to determine
if an IP address responds, or as sophisticated as measuring the jitter (delay variation) of VoIP packets that flow over a particular path. To use IP SLA, an engineer configures IP SLA operations on various routers, and the routers will then send packets, receive responses, and gather data about whether a response was received, and the specific characteristics of the results, such as delay and jitter measurements.

IP SLA primarily acts as a tool to test and gather data about the network. Network management tools can then collect that data and report whether the network reached SLAs for
the network. Many network management tools support the ability to configure IP SLA from the management tools’ graphical interfaces. When configured, the routers gather the results of the operations, storing the statistics in the IOS RTTMON MIB. Management applications can later gather the statistics from this MIB on various routers and report on whether the business SLAs were met based on the gathered statistics. For example, you can use the Cisco Works Internetwork Performance Monitor (IPM) feature to configure and monitor the data collected using IP SLA operations.

So, why bother with a pure network management feature in this book focused on IP routing?
Well, you can configure static routes and PBR to use IP SLA operations, so that if the operation shows a failure of a particular measurement or reduced performance of the measurement below a configured threshold, the router stops using either the static route or PBR logic. This combination of features provides a means to control when the static and PBR paths are used and when they are ignored.

1. Understanding IP SLA Concepts

IP SLA uses the concept of an operation. Each operation defines a type of packet that the router will generate, the destination and source address, and other characteristics of
the packet. The configuration includes settings about the time-of-day when the router should be sending the packets in a particular operation, the types of statistics that should
be gathered, and how often the router should send the packets. Also, you can configure a router with multiple operations of different types.

For example, a single IP SLA operation could define the following:

• Use ICMP echo packets.
• Measure the end-to-end round trip response time (ICMP echo).
• Send the packets every 5 minutes, all day long.

All the SLA operations rely on the router sending packets and some other device sending packets back.

A wide range of IP SLA operations exist. The following list summarizes the majority of the available operation types, just for perspective:

• ICMP (echo, jitter)
• RTP (VoIP)
• TCP connection (establishes TCP connections)
• UDP (echo, jitter)
• DNS
• DHCP
• HTTP
• FTP

2. Configuring and Verifying IP SLA

influence static routes and policy routing. To that end, this section examines the use of an ICMP echo operation, which requires configuration only on one router, with no IP SLA responder. The remote host, router, or other device replies to the ICMP Echo Requests just like any other ICMP echo requests.

The general steps to configure an ICMP-based IP SLA operation are as follows:

Step 1. Create the IP SLA Operation, and assign it an integer operation number, using Key the ip sla sla-ops-number global configuration command.

Step 2. Define the operation type and the parameters for that operation type. For ICMP echo, you define the destination IP address or hostname, and optionally, the source IP address or hostname, using the icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name] SLA operation subcommand.

Step 3. (Optional) Define a (nondefault) frequency that the operation should send the packets, in seconds, using the frequency seconds IP SLA subcommand.

Step 4. Schedule when the SLA will run, using the ip sla schedule sla-ops-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring] global command.

The purpose of the operation is to test the PBR route through R4. In this case, the operation will be configured as shown in Figure, with the following criteria:

• Send ICMP Echo Requests to server S1 (10.1.3.99).
• Use source address 10.1.1.9 (R1’s F0/0 IP address).
• Send these packets every 60 seconds.
• Start the operation immediately, and run it forever.
• Enable PBR for locally generated packets, matching the IP SLA operation with the PBR configuration so that the SLA operation’s packets flow over the lower route.

R1(config)# ip sla 11　　// Create IP SLA Operation
R1(config-ip-sla)#icmp?
icmp-echo icmp-jitter
R1(config-ip-sla)# icmp-echo 10.1.3.99 source-ip 10.1.1.9
R1(config-ip-sla)# frequency 60
R1(config-ip-sla)# exit
R1(config)# ip sla schedule 11 start-time now life forever
! Changes to the PBR configuration below
R1(config)# access-list 101 permit ip host 10.1.1.9 host 10.1.3.99
R1(config)# ip local policy PC2-over-low-route
R1(config)# end

First, focus on the pure IP SLA configuration, located from the beginning of the example
up through command ip sla schedule. The configuration creates IP SLA operation 11. The
parameters on the icmp-echo command act as if you used an extended ping from the command
line, specifying both the source and destination IP address. The last command directly
related to IP SLA, the ip sla schedule command, enables the operation now, and
runs the operation until the network engineer takes some action to disable it, in some
cases by removing the operation with the no ip sla sla-ops-number command.
The last two commands in the example show a change to the earlier PBR configuration so
that the SLA operation’s packets flow over the lower route. The ip local policy PC2-overlow-
route global command tells R1 to process packets generated by R1, including the IP
SLA operation packets, using PBR. The addition of the access-list 101 command to the
configuration shown earlier in Example 11-1 makes the route map match the source and
destination address of the SLA operation. That former route map’s set command sent the
packets over the link to R4.

IP SLA supports a couple of particularly useful verification commands: show ip sla configuration and show ip sla statistics.

The first command confirms all the configuration settings for the operation, and the second lists the current statistics for the operation.

R1# show ip sla configuration
IP SLAs Infrastructure Engine-II
Entry number: 11
Owner:
Tag:
Type of operation to perform: echo
Target address/Source address: 10.1.3.99/10.1.1.9
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000 (not considered if react RTT is configured)
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:

R1# show ip sla statistics 11
IPSLAs Latest Operation Statistics
IPSLA operation id: 11
Latest RTT: 8 milliseconds
Latest operation start time: *19:58:08.395 UTC Mon Sep 14 2009
Latest operation return code: OK
Number of successes: 22
Number of failures: 0
Operation time to live: Forever

3. Tracking SLA Operation to Influence Routing

As previously mentioned, you can configure both static routes and PBR to be used only when an SLA operation remains successful. The configuration to achieve this logic requires
the configuration of a tracking object and cross references between the static route, PBR, and IP SLA.

The tracking object looks at the IP SLA operation’s most recent return code to then determine the tracking state as either “up” or “down.” Depending on the type of SLA operation,
the return code may be a simple toggle, with “OK” meaning that the last operation worked. The tracking object would then result in an “up” state if the SLA operation resulting in an “OK” return code. Other SLA operations that define thresholds have more possible return codes. The tracking operation results in an “up” state if the IP SLA operation is
within the configured threshold.

One of the main reasons that IOS requires the use of this tracking object is so that the routes do not flap. Route flapping occurs when a router adds a route to the routing table, then quickly removes it; conditions change, so the router soon adds the route to the table again; and so on. If a static route tracked the IP SLA object directly, the SLA object’s return code could change each time the operation ran, causing a route flap. The tracking object concept provides the ability to set a delay of how soon after a tracking state change the tracking object should change state. This feature gives the engineer a tool to control route flaps.

4. Configuring a Static Route to Track an IP SLA Operation

To configure a static route to track an IP SLA, you need to configure the tracking object and then configure the static route with the track keyword. To do so, use these steps:
Step 1. Use the track object-number ip sla sla-ops-number [state | reachability] global command.

Step 2. (Optional) Configure the delay to regulate flapping of the tracking state by using the delay {down seconds | up seconds} command in tracking configuration mode.
Step 3. Configure the static route with the ip route destination mask {interface | next-hop} track object-number global command.

Example shows the configuration of tracking object 2, In this case, the configuration adds a static route for subnet 10.1.234.0/24, the LAN subnet to which R2, R3, and R4 all connect. EIGRP chooses a route over R1’s S0/0/0 as its best route, but this static route uses S0/0/1 as the outgoing interface.

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# track 2 ip sla 11 state
R1(config-track)# delay up 90 down 90
R1(config-track)# exit
R1(config)# ip route 10.1.234.0 255.255.255.0 s0/0/1 track 2
R1(config)# end

The configuration begins with the creation of the tracking object number 2. As with IP SLA operation numbers, the number itself is unimportant, other than that the ip route
command refers to this same number with the track 2 option at the end of the command. The tracking object’s delay settings have been made at 90 seconds.

The show track command lists the tracking object’s configuration plus many other details. It lists the current tracking state, the time in this state, the number of state transitions, and
the other entities that track the object (in this case, a static route).

Example shows what happens when the IP SLA operation fails, causing the static route to be removed. The following list details the current operation and what happens sequentially in the example:
Step 1. Before the text seen in Example, the current IP SLA operation already sends packets using PBR, over R1’s link to R4, using source IP address 10.1.1.9 and destination 10.1.3.99 (server S1).

Step 2. At the beginning of the next example, because the IP SLA operation is working, the static route is in R1’s IP routing table.

Step 3. An ACL is configured on R4 (not shown) so that the IP SLA operation fails.

Step 4. A few minutes later, R1 issues a log message stating that the tracking object changed state from up to down.

Step 5. The example ends with several commands that confirm the change in state for the tracking object, and confirmation that R1 now uses the EIGRP learned route through R2.

5. Configuring PBR to Track an IP SLA

To configure PBR to use object tracking, use a modified version of the set command in the route map. For instance, the earlier PBR configuration used the following set command:

set ip next-hop 10.1.14.4

Instead, use the verify-availability keyword, as shown in this command:

set ip next-hop verify-availability 10.1.14.4 1 track 2

When the tracking object is up, PBR works as configured. When the tracking object is down, PBR acts as if the set command does not exist. That means that the router will still
attempt to route the packet per the normal destination-based routing process.

The output of the related verification commands does not differ significantly when comparing the configuration of tracking for static routes versus PBR. The show track command
lists “ROUTE-MAP” instead of “STATIC-IP-ROUTING,” but the details of the show track, show ip sla statistics, and object tracking log message seen in Example, remain the same.

Policy-Based Routing and IP Service Level Agreement

标签：

原文地址：http://www.cnblogs.com/elewei/p/4915415.html