- Interface Connectivity
- Interception Techniques and Protocols
- Egress Methods for Intercepted Connections
- Network Integration Best Practices
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Egress Methods for Intercepted Connections
Cisco WAAS provides several options for handling egress traffic received on intercepted connections. These options allow for flexibility when determining where to integrate WAAS into the existing network infrastructure, and help preserve the original path selection for traffic flows. These deployment options, referred to as the egress methods for intercepted connections (EMIC), are discussed in detail in this section.
The first EMIC available in Cisco WAAS is IP forwarding. Egress traffic received on intercepted connections is forwarded based on the configuration of the local WAE routing table, which typically means that traffic is forwarded to the configured default gateway. In addition to supporting a single default gateway, WAAS supports up to 1024 static routes. Static routes are configured with a next hop IP address of a directly connected interface; recursive next hop IP addresses are not supported. Although it is possible to configure multiple static routes for the same destination, there is no support for equal-cost multipath (ECMP). Only a single route will be installed in the routing table at a time. It should be noted that traffic originating from the WAE itself will also use IP forwarding, regardless of the EMIC configuration. The IP forwarding EMIC is suited for very basic topologies where only a single egress path for traffic exists, or in situations where other EMICs are not supported.
For more complex topologies, the IP forwarding EMIC can lead to undesirable forwarding of traffic for intercepted connections. Take for example the topology shown in Figure 4-18. This example shows a remote office with multiple WAN routers connecting to diverse circuits. Traffic can enter or leave the site through either router. When multiple paths exist for traffic leaving a site, it is common for either HSRP or the Gateway Load Balancing Protocol (GLBP) to be used for default gateway redundancy. HSRP provides an active/standby configuration based on a virtual IP (VIP) address. At any given point in time, a single VIP address is "active" on one of the routers. Hosts are configured with the HSRP VIP address as their default gateway, causing all traffic from those hosts to be forwarded to one of the two routers. In the case of GLBP, either router can be selected as the outbound path for a host, depending on the specific GLBP configuration. Because GLBP operates based on MAC addresses, a WAE running Cisco WAAS appears as a single host. This means that traffic egressing a WAE will also select one of the two routers to forward outbound traffic to. For deployments that use GLBP for default-gateway redundancy, the issue with IP forwarding is the most pronounced.
)
Figure 4-18 Branch Topology with Multiple Entry and Exit Points
You can see in the previous example how all egress traffic from the WAE is "pinned" to a single router. This can defeat the purpose of deploying GLBP in the first place, which is to distribute outbound traffic across both routers.
There are several options with WAAS for preserving the network path affinity originally chosen by the host system or network elements. The first two options leverage the WCCPv2 return mechanism. You'll recall from earlier in this chapter that the WCCPv2 return mechanism is used by WCCPv2 clients to handle bypass traffic by sending it back to the WCCPv2-enabled router that redirected it. Cisco WAAS has the ability to leverage the return method negotiated between the router and WAE for forwarding egress traffic from the WAE. The following CLI command changes the default EMIC from IP forwarding to negotiated return:
egress-method negotiated-return intercept-method wccp
If GRE is the return method negotiated between the WAE and IOS, traffic received on optimized connections is encapsulated in a GRE header with a destination IP address of the WCCPv2 router ID and a source IP address of the WAE. When the WCCPv2-enabled IOS device receives the GRE-encapsulated packet, it removes the GRE header and forwards the packet normally. Because the GRE header uses a source IP address of the WAE, the IOS WCCPv2 process knows not to re-intercept the packet. This capability to return traffic to the IOS device that redirected it allows for the preservation of the original path selection made by the host or network infrastructure.
Another benefit of the GRE return method is that the WAE can reside on the same IP subnet with clients or servers that it optimizes connections for. This greatly simplifies branch deployments by removing the requirement for a separate subnet dedicated to the WAE. Figure 4-19 shows the same topology as Figure 4-18, except using the negotiated return EMIC instead of IP forwarding.
)
Figure 4-19 Branch Topology Using GRE Return EMIC