201 lines
5.1 KiB
HTML
201 lines
5.1 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Multicast routing</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Advanced Routing & Traffic Control HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="IPsec: secure IP over the Internet"
|
|
HREF="lartc.ipsec.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Queueing Disciplines for Bandwidth Management"
|
|
HREF="lartc.qdisc.html"></HEAD
|
|
><BODY
|
|
CLASS="CHAPTER"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Advanced Routing & Traffic Control HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="lartc.ipsec.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="lartc.qdisc.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="CHAPTER"
|
|
><H1
|
|
><A
|
|
NAME="LARTC.MULTICAST"
|
|
></A
|
|
>Chapter 8. Multicast routing</H1
|
|
><P
|
|
>FIXME: Editor Vacancy!</P
|
|
><P
|
|
>The Multicast-HOWTO is ancient (relatively-speaking) and may be inaccurate
|
|
or misleading in places, for that reason.</P
|
|
><P
|
|
>Before you can do any multicast routing, you need to configure the Linux
|
|
kernel to support the type of multicast routing you want to do. This, in
|
|
turn, requires you to decide what type of multicast routing you expect to
|
|
be using. There are essentially four "common" types - DVMRP (the Multicast
|
|
version of the RIP unicast protocol), MOSPF (the same, but for OSPF), PIM-SM
|
|
("Protocol Independent Multicasting - Sparse Mode", which assumes that users
|
|
of any multicast group are spread out, rather than clumped) and PIM-DM (the
|
|
same, but "Dense Mode", which assumes that there will be significant clumps
|
|
of users of the same multicast group).</P
|
|
><P
|
|
>In the Linux kernel, you will notice that these options don't appear. This is
|
|
because the protocol itself is handled by a routing application, such as
|
|
Zebra, mrouted, or pimd. However, you still have to have a good idea of which
|
|
you're going to use, to select the right options in the kernel.</P
|
|
><P
|
|
>For all multicast routing, you will definitely need to enable "multicasting"
|
|
and "multicast routing". For DVMRP and MOSPF, this is sufficient. If you are
|
|
going to use PIM, you must also enable PIMv1 or PIMv2, depending on whether
|
|
the network you are connecting to uses version 1 or 2 of the PIM protocol.</P
|
|
><P
|
|
>Once you have all that sorted out, and your new Linux kernel compiled, you
|
|
will see that the IP protocols listed, at boot time, now include IGMP. This
|
|
is a protocol for managing multicast groups. At the time of writing, Linux
|
|
supports IGMP versions 1 and 2 only, although version 3 does exist and has
|
|
been documented. This doesn't really affect us that much, as IGMPv3 is still
|
|
new enough that the extra capabilities of IGMPv3 aren't going to be that
|
|
much use. Because IGMP deals with groups, only the features present in the
|
|
simplest version of IGMP over the entire group are going to be used. For the
|
|
most part, that will be IGMPv2, although IGMPv1 is sill going to be
|
|
encountered.</P
|
|
><P
|
|
>So far, so good. We've enabled multicasting. Now, we have to tell the Linux
|
|
kernel to actually do something with it, so we can start routing. This means
|
|
adding the Multicast virtual network to the router table:</P
|
|
><P
|
|
>ip route add 224.0.0.0/4 dev eth0</P
|
|
><P
|
|
>(Assuming, of course, that you're multicasting over eth0! Substitute the
|
|
device of your choice, for this.)</P
|
|
><P
|
|
>Now, tell Linux to forward packets...</P
|
|
><P
|
|
>echo 1 > /proc/sys/net/ipv4/ip_forward</P
|
|
><P
|
|
>At this point, you may be wondering if this is ever going to do anything. So,
|
|
to test our connection, we ping the default group, 224.0.0.1, to see if anyone
|
|
is alive. All machines on your LAN with multicasting enabled <EM
|
|
>should</EM
|
|
>
|
|
respond, but nothing else. You'll notice that none of the machines that
|
|
respond have an IP address of 224.0.0.1. What a surprise! :) This is a group
|
|
address (a "broadcast" to subscribers), and all members of the group will
|
|
respond with their own address, not the group address.</P
|
|
><P
|
|
>ping -c 2 224.0.0.1</P
|
|
><P
|
|
>At this point, you're ready to do actual multicast routing. Well, assuming
|
|
that you have two networks to route between.</P
|
|
><P
|
|
>(To Be Continued!)</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="lartc.ipsec.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="lartc.qdisc.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>IPsec: secure IP over the Internet</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Queueing Disciplines for Bandwidth Management</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |