peer - Manage connected peer web proxies
[1] peer [(share | ha | previous) [add <ip> [<qos>]]]
[2] peer [(share | ha | previous) [raz | del <ip>]]
[3] peer [next [add <ip> [<port-number> [<qos>]] | del <ip> [<port-number>] | raz]]
A peer appliance is a remote web proxy interacting with the local web proxy. There are three types of peer:
• Share peer,
• HA (High Availability) peer
• Chained peers (next and previous)
A share peer is a remote proxy that is requested from the local proxy when it does not have a requested object (by a client) in its cache. Several share peers may be defined to share their caches. In this case, each peer must be configured adequately with regards to the others. Share peers work together to deliver web object to end-users from their caches rather than searching them on the internet and hence optimise the bandwidth usage.
An HA (High Availability) peer is a specific share peer, the difference being that web objects retrieved from a share peer are not cached on the requesting proxy while web objects retrieved from a HA peer are cached. HA peers should be used when peers are configured in a HA mode. In this case, when a master HA node fails, the newly elected master contains all web objects as in the failed system (see the mode and vrrp commands for further information).
Share and HA peers works in parallel to provide caching performances and availability to local clients. It is also possible to serialise (or chain) peers to provide caching performances and high availability to remote end-users. To chain a proxy with a peer, one must be configured as a next peer while the other is configured as a previous peer (to allow the other to query it). A next peer is queried when it receives a request from an end-user. When several peers are chained, each system can participate to secure and optimise the traffic. For instance one can be configured to cache the traffic while a second one performs traffic shaping and a third one filters the traffic.
Note that when chaining peers, client IP addresses are transmitted to next peers using the X-Forwarded-For header. Next peers can then allow web access based on the client IP addresses carried in this header. Refer to the access fweb command usage form for further information.
The first [1] usage form allows you to add a share, ha or previous peer to the system. To add a share peer, use the share add keywords followed by the internal IP address of the remote share peer. To add an HA or previous peer, use the ha or previous keywords instead of the share keyword. The optional <qos> value allows you to customise the shaping of the traffic exchanged with the added peer. The <qos> is a percentage of the total bandwidth allocated to peers by the qos command. It should be an integer between 1 and 100. If no <qos> is given, the value of 100% is used by default. Share (share) and HA (ha) peers communicate using the httppeer and htcppeer ports configured with the port command. Note that all Share and HA peers must be configured to use the same httppeer and htcppeer port values.
A peer always uses its external IP address to query the internet or next peers. This is why a previous peer should be added using its external IP address. The second [2] usage form allows you to delete a share, ha, or previous peer, or to completely erase the list of these peers.
The third [3] usage form allows you to add a next peer. To add a next peer, use the next add keywords followed by the internal IP address and proxy port of the remote next peer. By default, the system connects to the next peer using the httppeer port (see the port command). If the next peer is listening on a different port, the optional <port-number> argument can be used to specify that port. It is also possible to specify a <qos> value to customise the shaping of traffic exchanged with the added next peer. The <qos> value is a percentage of the total bandwidth allocated to web traffic on the external interface by the qos command. The <qos> value must be an integer between 1 and 100. If no <qos> value is specified, a value of 100 is used.
The current OS version does not support SSL mediation between HA and share peers. Therefore, HTTPS traffic uses the HTTP CONNECT method to establish end-to-end tunnels between web users and HTTPS servers, bypassing peer-to-peer processing. In addition, if an upstream appliance on the path to the internet operates in transparent mode, access to some HTTPS websites may become unstable.
access(1), apply(1), mode(1), port(1), qos(1), vrrp(1)
CacheGuard Technologies <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2026 CacheGuard Technologies - All rights reserved