As we know WAAS relies on network interception to be integrated into network as well as to receive packet from flows that should be optimized . WCCP gives a transparent redirection of packets towards the WAAS devices(WAE) for application acceleration and WAN optimization .
The Packet Return Method is the method by which packets not selected for optimization (i.e. packets which satisfy a static bypass rule or packets which do not satisfy any policy classifier) are returned to a router/switch for normal forwarding. The Packet Return Method is not required to match the Forwarding method. The return method is negotiated between a router and all WAAS devices on a per Service Group basis. While the WCCPv2 protocol allows different cache engines to use different packet return methods, Cisco WAAS and IOS-WCCP prevent this from happening. A router will advertise the supported packet return methods for a Service Group using the optional Capabilities Info component of the WCCP2_I_SEE_YOU message. The absence of such an advertisement implies the router supports the default GRE packet return method only.
This section will provide you the basic understanding of how WCCP works and how to configure and manage a WCCP deployment for WAAS.
WCCPv2 is a protocol that allow WAE devices to join a service group with network devices (like switches routers or firewalls) so that they will inject itself in the path of traffic to optimize or otherwise manipulate flows. Once we configure WCCP properly , the network device will identify the traffic which matches the criteria defined in configured service groups. When the traffic is identified the network devices will then redirect the traffic to one of the registered service devices such as Cisco WAE in our case , using either a Generic Route Encapsulation tunnel (GRE) or
through frame header rewriting, called Layer 2 redirection (L2-redirect). Once the WAE intercept the packets it can apply its function or polices on that flow.
WCCP Protocol Basics
WCCPv2 defines mechanisms to allow one or more routers enabled for transparent redirection to discover, verify, and advertise connectivity to one or more WAAS devices. Having established connectivity, the routers and WAAS devices form Service Groups to handle the redirection of traffic whose characteristics are part of the Service Group definition.
The protocol provides the means to negotiate the specific method used for load distribution among WAAS devices and also the method used to transport traffic between router and cache. A single WAAS device within a Service Group is elected as the designated WAE. It is the responsibility of the designated WAE to provide routers in the Service Group with the data which determines how redirected traffic is distributed between the WAAS devices in the Service Group
Joining a Service Group
A Service Group is a group of one or more routers plus one or more WAAS devices working together in the redirection of traffic whose characteristics are part of the Service Group definition. A WAAS device joins and maintains its membership in a Service Group by transmitting a WCCP2_HERE_I_AM (HIA) message to each router in the Group at 2 second intervals. This may be by unicast to each router or multicast to the configured Service Group multicast address. The Web Cache Info component in the WCCP2_HERE_I_AM message identifies the WAAS device by IP address and the Service Info component identifies and describes the Service Group in which the WAAS device wishes to participate.
A router responds to a WCCP2_HERE_I_AM message with a WCCP2_I_SEE_YOU (ISU) message. If the WCCP2_HERE_I_AM message was unicast then the router will respond immediately with a unicast WCCP2_I_SEE_YOU message. If the WCCP2_HERE_I_AM message was multicast, the router will respond via the scheduled multicast WCCP2_I_SEE_YOU message for the Service Group.
A router responds to multicast cache engine members of a Service Group using a multicast WCCP2_I_SEE_YOU message transmitted at 9 second intervals with a 10% jitter. The Router Identity component in a WCCP2_I_SEE_YOU message includes a list of the WAAS devices to which the packet is addressed.
A router responds to a WCCP2_HERE_I_AM message with a WCCP2_I_SEE_YOU (ISU) message. If the WCCP2_HERE_I_AM message was unicast then the router will respond immediately with a unicast WCCP2_I_SEE_YOU message. If the WCCP2_HERE_I_AM message was multicast, the router will respond via the scheduled multicast WCCP2_I_SEE_YOU message for the Service Group.
A router responds to multicast cache engine members of a Service Group using a multicast WCCP2_I_SEE_YOU message transmitted at 9 second intervals with a 10% jitter. The Router Identity component in a WCCP2_I_SEE_YOU message includes a list of the WAAS devices to which the packet is addressed.
Cisco WCCP Service Groups
Service Name
|
Service Number
|
Protocol
|
Port
|
Priority
|
web-cache
|
0
|
tcp
|
80
|
240
|
Dns
|
53
|
udp
|
53
|
202
|
ftp-native
|
60
|
tcp
|
200
|
|
tcp-promiscuous
|
61
|
tcp
|
*
|
34
|
tcp-promiscuous
|
62
|
tcp
|
*
|
34
|
https-cache
|
70
|
tcp
|
443
|
231
|
Rtsp
|
80
|
tcp
|
554
|
200
|
Wmt
|
81
|
tcp
|
1755
|
201
|
Mmsu
|
82
|
udp
|
1755
|
201
|
Rtspu
|
83
|
udp
|
5005
|
201
|
cifs-cache
|
89
|
tcp
|
139, 445
|
224
|
Custom
|
90-97
|
220-227
|
||
custom-web-cache
|
98
|
tcp
|
80
|
230
|
reverse-proxy
|
99
|
tcp
|
80
|
235
|
Describing a Service Group
The Service Info component of a WCCP2_HERE_I_AM message describes the Service Group in which a WAAS device wishes to participate. A Service Group is identified by Service Type and Service ID. There are two types of Service Group: · Well Known Services · Dynamic Services. Well Known Services are known by both routers and cache engines and do not require a description other than a Service ID. Service IDs can range from 0 to 255 with the 0-50 range reserved for Well Know Services. Currently, web-cache is the only defined Well Known Service. In contrast Dynamic Services must be fully described to a router. A router may be configured to participate in a particular Dynamic Service Group, identified by Service ID, without any knowledge of the characteristics of the traffic associated with the Service Group. The traffic description is communicated to the router in the WCCP2_HERE_I_AM message of the first cache engine to join the Service Group. A cache engine describes a Dynamic Service using the Protocol, Service Flags and Port fields of the Service Info component. Once a Dynamic Service has been defined a router will discard any subsequent WCCP2_HERE_I_AM message which contains a conflicting description. A router will also discard a WCCP2_HERE_I_AM message which describes a Service Group for which the router has not been configured.
Lets see how the packet format looks , we will not going to see every details we will only see which is of our concern here.
'Here I Am' Message
+--------------------------------------+
| WCCP Message Header |
+--------------------------------------+
| Security Info Component |
+--------------------------------------+
| Service Info Component |
+--------------------------------------+
| Web-Cache Identity Info Component |
+--------------------------------------+
| Web-Cache View Info Component |
+--------------------------------------+
| Capability Info Component (optional) |
+--------------------------------------+
|Command Extension Component (optional)|
+--------------------------------------+
Service Info Component
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type | Service ID | Priority | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 0 | Port 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 6 | Port 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
WCCP2_SERVICE_INFO (1)
Length
Length of the remainder of the component.
Service Type
WCCP2_SERVICE_STANDARD (0).
Service is a well known service and is described by the Service ID.
All fields other than Service ID must be zero.
WCCP2_SERVICE_DYNAMIC (1).
Service is defined by the Protocol, Service Flags and Port fields.
Service ID
Service number. A number in the range 0-255. For well known services
numbers in the range 0-50 are reserved. The numbers currently defined
for well known services are:
0x00 HTTP
Priority
Service priority. The lowest priority is 0, the highest is
255. Packets for redirection are matched against Services in priority
order, highest first. Well known services have a priority of 240.
Protocol
IP protocol identifier
Service Flags
0x0001 Source IP Hash
0x0002 Destination IP Hash
0x0004 Source Port Hash
0x0008 Destination Port Hash
0x0010 Ports Defined.
0x0020 Ports Source.
0x0100 Source IP Alternative Hash
0x0200 Destination IP Alternative Hash
0x0400 Source Port Alternative Hash
0x0800 Destination Port Alternative Hash
Port 0-7
Zero terminated list of UDP or TCP port identifiers. Packets will be
matched against this set of ports if the Ports Defined flag is set. If
the Ports Source flag is set the port information refers to a source
port, if clear the port information refers to a destination port.
Establishing Two-Way Connectivity
Priority
Service priority. The lowest priority is 0, the highest is
255. Packets for redirection are matched against Services in priority
order, highest first. Well known services have a priority of 240.
Protocol
IP protocol identifier
Service Flags
0x0001 Source IP Hash
0x0002 Destination IP Hash
0x0004 Source Port Hash
0x0008 Destination Port Hash
0x0010 Ports Defined.
0x0020 Ports Source.
0x0100 Source IP Alternative Hash
0x0200 Destination IP Alternative Hash
0x0400 Source Port Alternative Hash
0x0800 Destination Port Alternative Hash
WCCP V2.0 uses a "Receive ID" to verify two-way connectivity between a router and a web-cache. The Router Identity Info component of a WCCP2_I_SEE_YOU message contains a "Receive ID" field. This field is maintained separately for each Service Group and its value is incremented each time the router sends a WCCP2_I_SEE_YOU message to the Service Group. The "Receive ID" sent by a router is reflected back by a web-cache in the Web-Cache View Info component of a WCCP2_HERE_I_AM message. A router checks the value of the "Receive ID" in each WCCP2_HERE_I_AM message received from a Service Group member. If the value does not match the "Receive ID" in the last WCCP2_I_SEE_YOU message sent to that member the message is discarded. A router considers a web-cache to be a usable member of a Service Group only after it has sent that web-cache a WCCP2_I_SEE_YOU message and received a WCCP2_HERE_I_AM message with a valid "Receive ID" in response.
Lets see how the packet format looks , we will not going to see every details we will only see which is of our concern here.
'I See You' Message
+--------------------------------------+
| WCCP Message Header |
+--------------------------------------+
| Security Info Component |
+--------------------------------------+
| Service Info Component |
+--------------------------------------+
| Router Identity Info Component |
+--------------------------------------+
| Router View Info Component |
+--------------------------------------+
| Assignment Info Component |
| OR |
| Assignment Map Component |
+--------------------------------------+
| Capability Info Component (optional) |
+--------------------------------------+
|Command Extension Component (optional)|
+--------------------------------------+
Router Identity Info Component
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Element |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sent To Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Received From |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received From Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received From Address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID Element
Element containing the router's identifying IP address and Receive
ID. The IP address must be a valid, reachable address for the router.
Web Cache View Info Component
This represents a web-cache's view of the Service Group.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Change Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Routers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Element 0 |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Element n |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Web-Caches |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Web Cache address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Web Cache address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router ID Element 0-n
List of elements containing the identifying IP address for each router
in the Service Group and the last "Received ID" from each.
Web Cache View Info Component
This represents a web-cache's view of the Service Group.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Change Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Routers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Element 0 |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Element n |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Web-Caches |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Web Cache address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Web Cache address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect Method
The Redirect Method, also known as the Forwarding Method, is the method by which redirected packets are transported from router to WAAS device. This method is negotiated between the router and the WAAS device. While the WCCPv2 protocol allows different cache engines to use different redirect methods.Each Cisco WAAS device belonging to a service group will use the same redirect method.
Cisco WAAS supports two different Forwarding Methods:
WCCP GRE
WCCP GRE, also known as
Layer 3 Generic Routing Encapsulation (GRE), allows packets to reach the WAAS device
even if there are other routers in the path between the forwarding router and
the WAAS device. The connection between the router and the WAAS device is also
known as a GRE Tunnel. Packet
redirection is handled entirely by the router software. GRE encapsulates the selected datagram with
the GRE header containing the routing information to the selected WAAS device.
The WAAS device de-encapsulates the datagram, evaluates the payload using the static
bypass rules and WAAS Policy specification, and either accepts or rejects the
packet. If the packet is accepted for optimization, standard TCP connection
setup occurs between the client and the WAAS device and between the WAAS device
and the destination server. If the packet is rejected because of a static
bypass rule, it is re-encapsulated and returned to the router. The router
understands that the WAE is not interested in this connection and forwards the
packet to its original destination. All
other packets, pass-through or optimized, are returned to the router using the
configured packet egress method.
IP
|
Port
|
|||||
Source
|
1.1.1.1
|
5432
|
Payload
|
|||
Destination
|
5.5.5.5
|
80
|
||||
Original Packet sent from IP
1.1.1.1 to IP 5.5.5.5
|
||||||
IP
|
IP
|
Port
|
||||
Source
|
2.2.2.2
|
1.1.1.1
|
5432
|
Payload
|
Destination
|
3.3.3.3
|
5.5.5.5
|
80
|
|
GRE Encapsulated Packet redirected
from router at IP 2.2.2.2 to WAAS device at 3.3.3.3. Original packet persevered.
|
||||
When using GRE encapsulation for WCCP redirection, the router
uses the router ID IP address as its source IP address. The router ID IP
address is the highest loopback address on the router, or if the loopback
interface is not configured, the router ID IP address is the highest address of
the physical interfaces. The router ID IP address is used as the source address
for packets redirected from the router to the Cisco WAAS device, and as a
result it is also used as the destination address for traffic from the Cisco
WAE to the router.
WCCP L2 (Layer-2 ) redirection
takes advantage of internal switching
hardware that either partially or fully implements the WCCP traffic
interception and redirection functions at Layer 2. Redirection occurs by overwriting the original
MAC header of the IP packet with the MAC header of one of the WAAS devices in
the Service Group. With L2 Redirection, the first redirected traffic packet is
handled by either the router software or router hardware, depending on the
platform and/or software version. The rest of the traffic may be handled by the
router hardware on supported routers and switches making L2 redirection more
efficient than Layer 3 GRE. Using
L2 Redirection as a forwarding method allows direct forwarding to the WAAS
device without further lookup. Layer-2 redirection requires that WAAS devices
be directly connected to an interface on each WCCP router. Unless multicast IP
addresses are used, WCCP configuration of the WAAS device must reference the
directly connected interface IP address of the WCCP router and not a loopback
IP address or any other IP address configured on the WCCP router.
MAC
|
IP
|
Port
|
||
Source
|
01.01.01.01.01.01
|
1.1.1.1
|
5432
|
Payload
|
Destination
|
05.05.05.05.05.05
|
5.5.5.5
|
80
|
Original Packet sent from IP 1.1.1.1 to IP 5.5.5.5
| |||
MAC
|
IP
|
Port
| |
02.02.02.02.02.02
|
1.1.1.1
|
5432
|
Payload
|
03.03.03.03.03.03
|
5.5.5.5
|
80
| |
L2 Rewrite redirects packet from router at MAC 02.02.02.02.02.02 to WAAS device at MAC 03.03.03.03.03.03. Original packet persevered.
| |||
Assignment Method
The Assignment Method
is the method by which redirected packets are distributed between the WAAS
devices in a Service Group effectively providing load balancing among the WAAS
devices. This method is negotiated between a router and all cache engines on a
per Service Group basis. Cache engines participating in multiple Service Group
may have different assignment methods for each Service Group but all cache
engines within a single Service Group will use the same Assignment Method. A
router may advertise the supported assignment methods for a Service Group using
the optional Capabilities Info component of the WCCP2_I_SEE_YOU message. The
absence of such an advertisement implies the router supports the default Hash
assignment method only.
There are two types of assignment methods:
1. Hash
Table Assignment
2. Mask/Value
Sets Assignment
The default Assignment Method uses Hash Tables to load balance
and select a particular WAAS device from those registered in the Service Group.
With Hash Assignment, each router in the Service Group uses a 256-bucket
Redirection Hash Table to distribute traffic for a Service Group across the
member WAAS devices. The hash key may be based on any combination of the source
and destination IP and port of the packet. For WAAS, load-balancing hashing is
based on a source IP address (default), a destination IP address, or both.
When
using mask assignment, each router uses masks and a table of values to
distribute traffic for a Service Group across the member WAAS devices. It is
the responsibility of the Service Group's designated cache engine to assign
each router's mask/value sets. For WAAS, the default mask value is 0x1741 and
is applied to the source IP address for service 61 and the destination IP
address for service 62. The Mask Value can be specified with a maximum of 7
bits and like the hash key, can be configured to cover both the source as well
as the destination address space. The Packet Return Method is the method by which packets not selected for optimization (i.e. packets which satisfy a static bypass rule or packets which do not satisfy any policy classifier) are returned to a router/switch for normal forwarding. The Packet Return Method is not required to match the Forwarding method. The return method is negotiated between a router and all WAAS devices on a per Service Group basis. While the WCCPv2 protocol allows different cache engines to use different packet return methods, Cisco WAAS and IOS-WCCP prevent this from happening. A router will advertise the supported packet return methods for a Service Group using the optional Capabilities Info component of the WCCP2_I_SEE_YOU message. The absence of such an advertisement implies the router supports the default GRE packet return method only.
Cisco WAAS supports two different Packet Return Methods:
1.
WCCP GRE (default)
Packet Egress Method
Beginning with Cisco WAAS Release 4.0.13, WAAS provides an
alternate packet return method for packets satisfying a policy classifier
including both optimized packets and packets specified by policy action as
pass-through. This method is called the Packet
Egress Method and can be defined separately from the Packet Return Method
used for bypassed packets.
Cisco WAAS supports three different Packet Egress Methods:
1.
IP Forwarding (default)
2.
WCCP Negotiated Return
3.
Generic GRE Return
IP Forwarding is the default Packet Egress Method and sends
optimized packets to the configured default gateway of the WAAS device. With
the IP forwarding egress method WAAS devices cannot be placed on the same VLAN
or subnet as the clients and servers, and it does not ensure that packets are
returned to the original intercepting router.
WCCP Negotiated Return
WCCPv2 is capable of negotiating the redirect method and the return method for intercepted connections. Cisco WAAS supports both WCCP L2 Rewrite and WCCP GRE as negotiated Packet Return Methods. If WCCP negotiates a WCCP Layer 2 Rewrite return, as Cisco WAAS does not support L2 Rewrite return as a Packet Egress method, the WAAS device defaults to using IP forwarding as the egress method.
Like WCCP GRE Return, generic GRE Return also performs the
reverse of GRE Encapsulation. The generic GRE egress method is supported only
when the WCCP GRE is specified as the Redirect Method. If the interception
method is set to WCCP Layer 2 and you configure generic GRE return as the
egress method, the WAAS device will default to IP forwarding as the egress
method as WCCP L2 Redirect method and generic GRE return are not compatible.
With generic GRE return, after optimization is performed, the
packet will be returned to the same router from which it was originally
redirected, preserving the original packet flow path. The generic GRE egress
method returns packets to the intercepting router by using a GRE tunnel that
must be manually configured on the router[1]. Unlike the WCCP
GRE Return method, generic GRE Return was designed specifically to allow packets
to be processed in hardware on platforms like the Cisco 7600 series router or
the Catalyst 6000 series router with Sup32 or Sup720, increasing the overall
performance on the router and eliminating the risk of CPU overload.
This is great information, thanks
ReplyDeleteThis is
ReplyDeleteThis is great information, thanks.
ReplyDelete