This section describes how to configure PBR and provides example deployments. This section includes the following topics:

You can use access lists to specify which traffic is redirected to the SteelHead. Traffic that is not specified in the access list is switched normally. If you do not have an access list, or if your access list is not correctly configured in the route map, traffic is not redirected.

For information about access lists, see Configuring Access Control Lists.

Figure 12‑1 shows a SteelHead deployment in which the SteelHead is configured with PBR and is directly connected to the router.

In this example:

Although the primary interface is not included in this example, Riverbed recommends, as a best practice, that you connect the primary interface for management purposes.

You must configure subnet side rules when you use RSP or VSP in a virtual in-path deployment. To configure subnet side rules, select Networking > Networking: Subnet Side Rules. VSP is enabled by default in the SteelHead EX series.

For information about configuring the primary interface, see the SteelHead Management Console User’s Guide.

Figure 12‑2 shows a SteelHead deployment in which the SteelHead is configured with PBR and is directly connected to the router through a switch. This deployment also has a trunk between the switch and the router.

In this example:

Although the primary interface is not included in this example, Riverbed recommends that you connect the primary interface for management purposes.

For information about configuring the primary interface, see the SteelHead Management Console User’s Guide.

Figure 12‑3 shows a SteelHead deployment in which the SteelHead is configured with PBR and is directly connected to a Layer-3 switch.

In this example:

In an object tracking deployment, the SteelHead is connected to the router, and the router tracks whether the SteelHead is reachable using the Object Tracking feature of Cisco IOS. Object Tracking enables you to use methods such as HTTP GET and ping, to determine whether the PBR next-hop IP address is available.

Object Tracking is not available on all Cisco devices. For information about whether your Cisco device supports this feature, refer to your router documentation.

For diagram details, see Figure 12‑1.

In a deployment that uses multiple PBR interfaces, the SteelHead is connected to two routers, each of which is configured to redirect traffic to a separate interface on the SteelHead. Each router is configured similarly to the single router deployment, except that you specify a next-hop IP address that corresponds to the interface to which the SteelHead connects.

For diagram details, see Figure 12‑1.

In a PBR environment, you can deploy multiple SteelHeads for optimization redundancy. Figure 12‑4 shows a SteelHead deployment in which two routers are redirecting packets to two SteelHeads. The SteelHeads are directly connected through multiple interfaces. This deployment provides a high-availability environment—a full-mesh topology between the routers and SteelHeads.

When you deploy multiple SteelHeads, the routers can redirect packets within a TCP connection to different SteelHeads, depending on the router policy. For example, Router A redirects packets to SteelHead A. Following network convergence due to a WAN outage packets for this TCP connection, the packets arrive on Router B. Router B has a policy configured to redirect packets to SteelHead B. In this type of environment, Riverbed recommends that you use connection forwarding to ensure packets within a flow are forwarded to the owning SteelHead for optimization.

For more information about connection forwarding, see Connection Forwarding.

Data store synchronization is not a requirement for SteelHeads in a PBR environment, but it is useful if your design goal is for warm performance after a SteelHead fails. To use data store synchronization, you must meet certain criteria.

For more information about the data store, see RiOS Data Store Synchronization.

The example in Figure 12‑4 shows the following:

You can redirect packets to SteelHead interfaces in any order. Figure 12‑4 shows Router A redirecting packets first to SteelHead A inpath0_0, and then to SteelHead B inpath0_1; and Router B redirecting packets first to SteelHead B inpath0_0 then SteelHead A inpath0_1. Router A and Router B can redirect to SteelHead A inpath0_0 and inpath0_1 respectively.

This example shows two SteelHeads. You can add more SteelHeads using a similar method as for the first SteelHead.

In a network with multiple entry and exit points, you can configure the router and SteelHead to support two goals:

Figure 12‑5 shows all SteelHeads in one subnet. The routers are configured with access control lists (ACLs) to direct traffic from remote peer A to SteelHead A, and traffic for remote peer B to SteelHead B. The failover method is object tracking. An optional all-inclusive rule is added to simplify the addition of a new remote site. To support outbound load balancing, each SteelHead uses a different default gateway.

Optimized traffic from SteelHead A reaches the WAN through Router A, and SteelHead B reaches the WAN through router B. Multiple HSRP (MHSRP) allows the routers to present two default gateways for the WAN optimization subnet, at the same time having redundancy in case a WAN circuit fails. Instead of MHSRP, you could use Gateway Load Balancing Protocol (GLBP) or static routes on the SteelHeads. If you use one of these two methods, the SteelHeads are unaware of a WAN circuit outage.

In this example:

Two SteelHeads are configured in this example. You can add more SteelHeads using the same method as used for one of the SteelHeads ensuring policy route statements, any ACLs, default gateway align with load-balancing and redundancy goals.

You can add a Local PBR configuration in addition to the regular PBR configuration discussed in previous sections. You use a Local PBR configuration in environments where ICMP messages generated by the router need special routing configurations: for example, mixed-size maximum transmission unit (MTU) environment with SteelHead full-transparency in-path rules.

In networks that have a mix of MTU interface configurations, path MTU (PMTU) discovery determines the MTU size on the network path between two IP hosts, to avoid IP fragmentation. Network routers send ICMP Fragment needed but do not fragment bit set messages and packets back to the sending host; the host then decreases the segment size and retransmits the segment.

You must forward ICMP packets to the correct host (the client, server, or SteelHead). In some network scenarios, you need a Local PBR configuration to ensure ICMP messages, generated by a router, are redirected out of the same interface of the inbound IP datagram that triggers the ICMP message. Cisco Local PBR is a local policy route map configuration that can achieve this.

Figure 12‑6 shows an example scenario for which you can configure Local PBR.

In this example, the:

Without a Local PBR configuration on the router, optimized connections on the SteelHead can attempt to send IP datagrams of 1500 bytes across the WAN. Due to PMTU discovery, the router generates an ICMP fragment needed but do not fragment bit set message.

Because the SteelHead is configured with full transparency, the router forwards the ICMP message back to the server instead of the SteelHead. This results in the server reducing its segment size for the connection, when in fact, the SteelHead must be the one to reduce its segment size. This confusion results in transfer failure.

You can use the following Local PBR configuration on the router to ensure that packets received on fastethernet0/1, and trigger any ICMP message on the router, are forwarded to the SteelHead.