Web Cache Communication Protocol (WCCP) is a Cisco-developed content-routing

protocol that provides a mechanism to redirect traffic flows in real-time. It has built-in load
balancing, scaling, fault tolerance, and service-assurance (failsafe) mechanisms. Cisco IOS
Release 12.1 and later releases allow the use of either Version 1 (WCCPv1) or Version 2
(WCCPv2) of the protocol.

WCCP allows utilization of Cisco Cache Engines (or other caches running WCCP) to
localize web traffic patterns in the network, enabling content requests to be fulfilled locally.
Traffic localization reduces transmission costs and download time.

Contents
[hide]

 1 Protocol Versions
 2 Primary WCCP functions
o 2.1 Registration
o 2.2 Assignment
o 2.3 Redirect from Router to Cache Engine
o 2.4 Return from Cache Engine to Router
 3 Products that implement WCCP
 4 External links

[edit] Protocol Versions

WCCPv1

 Only a single router services a cluster of systems

 Supports HTTP (TCP port 80) traffic flows only
 Provides generic routing encapsulation (GRE) to prevent packet modification
 Routers and cache engines communicate to each other via a control channel based on
UDP port 2048

WCCPv2

 Allows for use across up to 32 routers (WCCP servers)

 Supports up to 32 engines/accelerators (WCCP clients)
 Supports any IP protocol including any TCP or UDP
 Supports up to 256 service groups (0-255)
 Adds MD5 shared secret security

[edit] Primary WCCP functions

[edit] Registration

 Accelerator or Engine is a WCCP client

 o Registers WCCP services (0-255) with “Here I Am” if application is
operational
o Registration announces WCCP client on service group, provides availability
notification, requests interesting traffic
o Transmits “Here I Am” every 10 seconds
o Lead WCCP client (lowest IP address) instructs routers on protocol/port,
assignment, forwarding, and return methods
 Router is a WCCP server
o Accepts service group registration (0-255)
o Acknowledges “Here I Am” with “I See You”
o Waits 30 (3x10) seconds before declaring engine failed
o Announce engines to other engines
o Router id is highest interface IP or highest loopback IP if one exists
o Redirects traffic to engine

[edit] Assignment

 Selects an engine in the cluster

 Hash 256 buckets
 Mask 128 buckets represented by 7 bit mask of the source or destination IP/Port

[edit] Redirect from Router to Cache Engine

 WCCP GRE redirect creates tunnel from router to local or remote Engine
 WCCP L2 redirect rewrites packet MAC address to that of the local Engine
 Redirect list allows router to permit/deny traffic to intercept

[edit] Return from Cache Engine to Router

 WCCP GRE return

 WCCP L2 return
 Engine can optionally return traffic any other way including routing

[edit] Products that implement WCCP

Whilst originally designed for Cisco's Content Cache appliance they have since added
support to other products, including:

 Application & Content Networking System (ACNS)

 Wide Area Application Servcies (WAAS)
 ASA/PIX Firewalls
 Some IOS versions
 IronPort S-Series Web Security Appliance

Other vendors have also implemented WCCP support into their products, as it allows
clustering and transparent deployment on networks using Cisco routers/switches without
additional hardware. WCCP is of particular use to vendors of web cache/proxy/security
appliances for redirection of web traffic. A list includes:

 ApplianSys CACHEbox
 Barracuda Networks Barracuda Web Filter
 Bluecoat ProxySG
 Fortinet FortiOS4.0
 McAfee McAfee Web Gateway Formerly Webwasher
 NetApp NetCache (no longer available)
 Riverbed Technology Steelhead
 Squid
 Stampede Technologies Stampede Application Acceleration Series
 Trend Micro IWSVA 3.x and 5.x
 Websense Web Security Gateway

[edit] External links

 Configuring Web Cache Services Using WCCP on Cisco's Web site
 Configure WCCP on your Cisco IOS router on TechRepublic
 Web Cache Communication Protocol V2.0 on IETF Web Site
 WCCP Enhancements on Cisco's site
 How to setup WCCP on your Barracuda Web Filter on Barracuda Networks site

Common Address Redundancy Protocol

From Wikipedia, the free encyclopedia

Jump to: navigation, search

The Common Address Redundancy Protocol or CARP is a protocol which allows multiple
hosts on the same local network to share a set of IP addresses. Its primary purpose is to
provide failover redundancy. For example, if there is a single computer running a packet
filter, and it goes down, then either the networks on either side of the packet filter can no
longer communicate with each other, or they communicate without any packet filtering. If,
however, there are two computers running a packet filter, running CARP, then if one fails,
the other will take over, and computers on either side of the packet filter will not be aware of
the failure, so operation will continue as normal. In order to make sure the new master
operates the same as the old one, pfsyncd is used. In some configurations CARP can also
provide load balancing functionality.

Contents
[hide]

 1 Principle of redundancy
 2 History
 o 2.1 No official internet protocol number
 3 See also
 4 External links

[edit] Principle of redundancy

A group of hosts using CARP is called a "group of redundancy". The group of redundancy
allocates itself an IP address which is shared or divided among the members of the group.
Within this group, a host is designated as "Master". The other members are called "slaves".
The main host is that which "takes" the IP address. It answers any traffic or ARP request
brought to the attention of this address. Each host can belong to several groups of
redundancy. It should be noted that each host must have a second unique IP address.

A common use of CARP is the creation of a group of redundant firewalls. The virtual IP
address allotted to the group of redundancy is indicated as the address of the default router on
the computers behind this group of firewalls. If the main firewall breaks down or is
disconnected from the network, the virtual IP address will be taken by one of the firewall
slaves and the service availability will not be interrupted.

[edit] History
In the late 1990s IETF began working on a solution to the problem of shared IPs. In 1997,
Cisco informed them that this was already covered by Cisco patents. In 1998, Cisco told them
it was covered by their patent of HSRP (Hot Standby Router Protocol). Nonetheless, IETF
continued work on VRRP (Virtual Router Redundancy Protocol). After some debate, people
decided it was alright to allow patented material in a standard, as long as it was available
under RAND (Reasonable and Non-Discriminatory) Licensing terms. Because VRRP fixed
problems with the HSRP protocol, Cisco began using VRRP instead, while still claiming it as
its own.[citation needed]

Cisco informed the OpenBSD developers they would enforce their patent of HSRP. This may
have been related to their lawsuit with Alcatel. Thus, a free implementation of VRRP could
not be made. OpenBSD developers started CARP as an alternative to the patented VRRP, as
the licensing terms did not seem reasonable or non-discriminatory. To avoid the HSRP
patent, they ensured their idea for CARP was fundamentally different. Because of
OpenBSD's focus on security, CARP was designed with security in mind, and is designed to
use cryptography. It became available, completely for free, in October 2003. It has since been
integrated into FreeBSD and NetBSD.

[edit] No official internet protocol number

From OpenBSD.org:

As a final note of course, when we petitioned IANA, the IETF body regulating "official"
internet protocol numbers, to give us numbers for CARP and pfsync our request was denied.
Apparently we had failed to go through an official standards organization. Consequently we
were forced to choose a protocol number which would not conflict with anything else of
value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and
unused number. We informed IANA of these decisions, but they declined to reply.

IP protocol numbers at the time when the above request was made were allocated by IANA
according to the rules in RFC 2780, i.e., under the "IESG Approval" or "Standards Action"
process (with "Expert Review" being a third option that was not applicable to this request).
Both of these processes require a textual specification describing the protocol for which a
protocol number is requested, which did not exist for CARP. The OpenBSD implementation
is the closest thing to a formal specification of the protocol, but source code - especially
source code licensed under specific terms - is not the same as a textual technical
specification. No technical specification was submitted for CARP, and IANA declined the
request.

Note that VRRP also uses IP protocol 112, having been assigned it by IANA. It has been
speculated that OpenBSD deliberately chose to pick a protocol number for CARP that would
conflict with VRRP, based on the phrasing of the above statement, which says that the
number for CARP was chosen to "not conflict with anything else of value" whereas the
number for pfsync was placed at "an open and unused number". With roughly half the IP
protocol numbers being unassigned, OpenBSD could have chosen an "open and unused
number" for CARP, had they so desired.

[edit] See also

 OpenBSD
 Gateway Load Balancing Protocol (GLBP)
 HSRP
 pfsync
 VRRP

[edit] External links

 OpenBSD's carp(4) man page
 Firewall Failover with pfsync and CARP
 UCARP: an userland CARP implementation
 NetBSD port of CARP
 FreeBSD port of CARP
 The OpenBSD song 3.5: "CARP License" and "Redundancy must be free"

Hypertext Caching Protocol (abbreviated to HTCP) is used for discovering HTTP caches
and cached data, managing sets of HTTP caches and monitoring cache activity. It permits full
request and response headers to be used in cache management and expands the domain of
cache management to include monitoring a remote cache's additions and deletions, requesting
immediate deletions and sending hints about web objects such as the third party locations of
cacheable objects or unavailability of web objects.

[edit] Features
All multi-octet HTCP protocol elements are transmitted in network byte order. All reserved
fields should be set to binary zero by senders and left unexamined by receivers. Headers must
be presented with the CRLF line termination, as in HTTP.

Any hostnames specified should be compatible between sender and receiver, such that if a
private naming scheme (such as HOSTS.TXT or NIS) is in use, names depending on such
schemes will only be sent to HTCP neighbors who are known to participate in said schemes.
Raw addresses (dotted quad IPv4, or colon-format IPv6) are universal, as are public DNS
names. Use of private names or addresses will require special operational care.

UDP must be supported. HTCP agents must not be isolated from network failures and delays.
An HTCP agent should be prepared to act in useful ways when no response is forthcoming,
or when responses are delayed or reordered or damaged. TCP is optional and is expected to
be used only for protocol debugging. The IANA has assigned port 4827 as the standard TCP
and UDP port number for HTCP.

An HTCP Message has the following general format:

+---------------------+
| HEADER | tells message length and protocol versions
+---------------------+
| DATA | HTCP message (varies per major ver. number)
+---------------------+
| AUTH | optional authentication for transaction
+---------------------+

[edit] External links

 RFC 2756 - the request for comment on HTCP