File: FAQ-12.html

package info (click to toggle)
squid 1.1.21-1
  • links: PTS
  • area: main
  • in suites: hamm
  • size: 2,828 kB
  • ctags: 3,705
  • sloc: ansic: 34,400; sh: 1,975; perl: 899; makefile: 559
file content (212 lines) | stat: -rw-r--r-- 9,149 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
<HTML>
<HEAD>
<TITLE>SQUID Frequently Asked Questions: Multicast</TITLE>
</HEAD>
<BODY>
<A HREF="FAQ-11.html">Previous</A>
<A HREF="FAQ-13.html">Next</A>
<A HREF="FAQ.html#toc12">Table of Contents</A>
<HR>
<H2><A NAME="s12">12. Multicast</A></H2>

<H2><A NAME="ss12.1">12.1 What is Multicast?</A></H2>

<P>Multicast is essentially the ability to send one IP packet to multiple
receivers.  Multicast is often used for audio and video conferencing systems.</P>

<P>You often hear about 
<A HREF="http://www.mbone.com/">the Mbone</A> in
reference to Multicast.  The Mbone is essentially a ``virtual backbone''
which exists in the Internet itself.  If you want to send and/or receive
Multicast, you need to be ``on the Mbone.''</P>


<H2><A NAME="ss12.2">12.2 How do I know if I'm on the Mbone?</A></H2>

<P>One way is to ask someone who manages your network.  If your network manager 
doesn't know, or looks at you funny, then you are very likely NOT on the Mbone</P>

<P>Another way is to use the <EM>mtrace</EM> program, which can be found
on the 
<A HREF="ftp://parcftp.xerox.com/pub/net-research/ipmulti/">Xerox PARC FTP site</A>.  Mtrace is similar to traceroute.  It will
tell you about the multicast path between your site and another.  For example:
<PRE>
        &gt; mtrace mbone.ucar.edu
        mtrace: WARNING: no multicast group specified, so no statistics printed
        Mtrace from 128.117.64.29 to 192.172.226.25 via group 224.2.0.1
        Querying full reverse path... * switching to hop-by-hop:
        0  oceana-ether.nlanr.net (192.172.226.25)
        -1  avidya-ether.nlanr.net (192.172.226.57)  DVMRP  thresh^ 1  
        -2  mbone.sdsc.edu (198.17.46.39)  DVMRP  thresh^ 1  
        -3  * nccosc-mbone.dren.net (138.18.5.224)  DVMRP  thresh^ 48  
        -4  * * FIXW-MBONE.NSN.NASA.GOV (192.203.230.243)  PIM/Special  thresh^ 64  
        -5  dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61)  DVMRP  thresh^ 64  
        -6  dec3800-2-fddi-0.Denver.mci.net (204.70.152.61)  DVMRP  thresh^ 1  
        -7  mbone.ucar.edu (192.52.106.7)  DVMRP  thresh^ 64  
        -8  mbone.ucar.edu (128.117.64.29)
        Round trip time 196 ms; total ttl of 68 required.
</PRE>
</P>

<P>If you think you need to be on the Mbone, this is 
<A HREF="http://www.mbone.com/mbone/how-to-join.html">how you can join</A>.</P>


<H2><A NAME="ss12.3">12.3 Should I be using Multicast ICP?</A></H2>

<P>Short answer: No, probably not.</P>

<P>Reasons why you SHOULD use Multicast:
<OL>
<LI>It reduces the number of times Squid calls <EM>sendto()</EM> to put a UDP
packet onto the network.</LI>
<LI>Its trendy and cool to use Multicast.</LI>
</OL>
</P>

<P>Reasons why you SHOULD NOT use Multicast:
<OL>
<LI>Multicast tunnels/configurations/infrastructure are often unstable.
You may lose multicast connectivity but still have unicast connectivity.</LI>
<LI>Multicast does not simplify your Squid configuration file.  Every trusted
neighbor cache must still be specified.</LI>
<LI>Multicast does not reduce the number of ICP replies being sent around.
It does reduce the number of ICP queries sent, but not the number of replies.</LI>
<LI>Multicast exposes your cache to some privacy issues.  There are no special
ermissions required to join a multicast group.  Anyone may join your
group and eavesdrop on ICP query messages.  However, the scope of your
multicast traffic can be controlled such that it does not exceed certain
boundaries.</LI>
</OL>
</P>

<P>We only recommend people to use Multicast ICP over network
infrastructure which they have close control over.  In other words, only
use Multicast over your local area network, or maybe your wide area
network if you are an ISP.  We think it is probably a bad idea to use
Multicast ICP over congested links or commodity backbones.</P>


<H2><A NAME="ss12.4">12.4 How do I configure Squid to send Multicast ICP queries?</A></H2>

<P>To configure Squid to send ICP queries to a Multicast address, you
need to create another neighbour cache entry specified as <EM>multicast</EM>.
For example:
<PRE>
        cache_host 224.9.9.9 multicast 3128 3130 ttl=64
</PRE>

224.9.9.9 is a sample multicast group address.
<EM>multicast</EM> indicates that this
is a special type of neighbour.  The HTTP-port argument (3128)
is ignored for multicast peers, but the ICP-port (3130) is 
very important.  The final argument, <EM>ttl=64</EM>
specifies the multicast TTL value for queries sent to this
address.
It is probably a good
idea to increment the minimum TTL by a few to provide a margin
for error and changing conditions.</P>

<P>You must also specify which of your neighbours will respond
to your multicast queries, since it would
be a bad idea to implicitly trust any ICP reply from an unknown
address.  Note that ICP replies are sent back to <EM>unicast</EM> 
addresses; they are NOT multicast, so Squid has no indication 
whether a reply is from a regular query or a multicast
query.  To configure your multicast group neighbours, use the
<EM>cache_host</EM> directive and the <EM>multicast-responder</EM>
option:
<PRE>
        cache_host cache1 sibling 3128 3130 multicast-responder
        cache_host cache2 sibling 3128 3130 multicast-responder
</PRE>

Here all fields are relevant.  The ICP port number (3130)
must be the same as in the <EM>cache_host</EM> line defining the
multicast peer above.  The third field must either be
<EM>parent</EM> or <EM>sibling</EM> to indicate how Squid should treat replies.
With the <EM>multicast-responder</EM> flag set for a peer, 
Squid will NOT send ICP queries to it directly (i.e. unicast).</P>


<H2><A NAME="ss12.5">12.5 How do I know what Multicast TTL to use?</A></H2>

<P>The Multicast TTL (which is specified on the <EM>cache_host</EM> line
of your multicast group) determines how ``far'' your ICP queries
will go.  In the Mbone, there is a certain TTL threshold defined 
for each network interface or tunnel.  A multicast packet's TTL must
be larger than the defined TTL for that packet to be forwarded across
that link.  For example, the <EM>mrouted</EM> manual page recommends:
<PRE>
        32   for links that separate sites within an organization.
        64   for links that separate communities or organizations, and are
             attached to the Internet MBONE.
        128  for links that separate continents on the MBONE.
</PRE>
</P>

<P>A good way to determine the TTL you need is to run <EM>mtrace</EM> as shown above
and look at the last line.  It will show you the minimum TTL required to
reach the other host.</P>

<P>If you set you TTL too high, then your ICP messages may travel ``too far''
and will be subject to eavesdropping by others.
If you're only using multicast on your LAN, as we suggest, then your TTL will
be quite small, for example <EM>ttl=4</EM>.</P>


<H2><A NAME="ss12.6">12.6 How do I configure Squid to receive and respond to Multicast ICP?</A></H2>

<P>You must tell Squid to join a multicast group address with the
<EM>mcast_groups</EM> directive.  For example:
<PRE>
        mcast_groups  224.9.9.9
</PRE>

Of course, all members of your Multicast ICP group will need to use the
exact same multicast group address.</P>

<P><B>NOTE:</B> Choose a multicast group address with care!  If two organizations
happen to choose the same multicast address, then they may find that their
groups ``overlap'' at some point.  This will be especially true if one of the
querying caches uses a large TTL value.  There are two ways to reduce the risk
of group overlap:
<OL>
<LI>Use a unique group address</LI>
<LI>Limit the scope of multicast messages with TTLs or administrative scoping.</LI>
</OL>
</P>

<P>Using a unique address is a good idea, but not without some potential
problems.  If you choose an address randomly, how do you know that
someone else will not also randomly choose the same address?  NLANR
has been assigned a block of multicast addresses by the IANA for use
in situations such as this.  If you would like to be assigned one
of these addresses, please 
<A HREF="mailto:nlanr-cache@nlanr.net">write to us</A>.  However, note that NLANR or IANA have no
authority to prevent anyone from using an address assigned to you.</P>

<P>Limiting the scope of your multicast messages is probably a better
solution.  They can be limited with the TTL value discussed above, or
with some newer techniques known as administratively scoped
addresses.  Here you can configure well-defined boundaries for the
traffic to a specific address.  There are some Internet Draft documents
describing this:
<UL>
<LI>
<A HREF="http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-mboned-admin-ip-space-03.txt">Administratively Scoped IP Multicast</A></LI>
<LI>
<A HREF="http://info.internet.isi.edu:80/in-drafts/files/draft-finlayson-ttl-admin-scope-00.txt">Using TTLs with Administratively Scoped IP Multicast Addresses</A></LI>
</UL>

Because these are Internet Drafts, they will expire eventually and become
out of date.  If you notice these links are bad, please let us know.</P>



<HR>
<A HREF="FAQ-11.html">Previous</A>
<A HREF="FAQ-13.html">Next</A>
<A HREF="FAQ.html#toc12">Table of Contents</A>
</BODY>
</HTML>