Squid_ The Definitive Guide - Duane Wessels [177]
mcast_groups
Synopsis
As discussed in Section 10.6.3, Squid supports receiving ICP queries via multicast. This option specifies a list of multicast addresses Squid should join to receive these ICP queries.
* * *
Tip
IP multicast is a very tricky and often fragile feature of the Internet. I strongly recommend you avoid using multicast for ICP unless you are already familiar with it. Don't try to guess appropriate values for these directives, and don't expect it to work the first time.
* * *
Syntax
mcast_groups multicast-address [multicast-address] ...
Default
No default
Example
mcast_groups 239.128.16.128
Related
cache_peer, mcast_icp_query_timeout
Name
udp_incoming_address
Synopsis
This directive causes Squid to bind all UDP sockets to a specific interface address. The IP address must correspond to one of the system's network interfaces. This directive affects the DNS (when using the internal implementation), ICP, HTCP, and SNMP sockets.
If your system has just one IP address, you probably shouldn't use this directive.
If you set udp_outgoing_address to one of your other network interface addresses, Squid can receive UDP datagrams on that interface as well.
Syntax
udp_incoming_address ip-address
Default
udp_incoming_address 0.0.0.0
Example
udp_incoming_address 192.168.4.5
Related
udp_outgoing_address, icp_port, htcp_port, snmp_port
Name
udp_outgoing_address
Synopsis
This directive specifies the source address for UDP messages that Squid sends. It affects DNS (when using the internal implementation), ICP, HTCP, and SNMP messages. The specified address must correspond to one of the system's network interfaces. You should use this directive only if your system has multiple IP addresses.
The default value of 255.255.255.255 causes Squid to use the incoming address for sending, as well as receiving. In other words, rather than creating a separate UDP socket for sending, Squid sends and receives messages through a single socket.
If you use this directive, it must have a different value than udp_incoming_address. Squid can't create two UDP sockets bound to the same IP address and port number.
Syntax
udp_outgoing_address ip-address
Default
udp_outgoing_address 255.255.255.255
Example
udp_outgoing_address 192.168.5.6
Related
udp_outgoing_address, icp_port, htcp_port, snmp_port
Name
cache_peer
Synopsis
Okay, this one's long, so hang on...
This directive defines your neighbor caches and tells Squid how to communicate with them. See Chapter 10 for the lowdown on neighbor caches.
The first argument is the neighbor cache's hostname, or IP address. You can safely use hostnames here because Squid doesn't block while resolving them. In fact, Squid periodically re-resolves the hostname so that if the address changes, you won't need to restart. Neighbor hostnames must be unique; you can't have two neighbors with the same name, even if they have different ports.
The second argument specifies the type of neighbor cache. The choices are parent, sibling, or multicast. Recall from Section 10.6.3 that for a multicast neighbor, Squid sends ICP queries only to the neighbor's IP address, which must be a valid multicast address. Squid makes HTTP requests to parents and siblings but never to a multicast neighbor.
The third and fourth arguments are HTTP and ICP/HTCP port numbers. The HTTP port number corresponds to the neighbor cache's http_port (or equivalent) setting. A value of 0 for the ICP/HTCP port disables those protocols for the neighbor. If you add the htcp option (described in the subsequent paragraphs), Squid sends HTCP queries to the neighbor. Otherwise, Squid sends ICP queries. If you choose not to use ICP or HTCP, you must specify the neighbor as a parent cache.
This brings us to the options field. The cache_peer directive has numerous options, which can be very confusing:
proxy-only
Instructs Squid to not store any responses received from the neighbor. This is often useful when you have a cluster and don't want a resource to be