[KLUG Members] multicast

[Peter Buxton]

http://www.tldp.org/HOWTO/Multicast-HOWTO.html

(Frankly, the whole multicast thing, as an Internet-wide phenomenom,
seems less than half-baked.)

I think I understand that this Linux box is a dedicated firewall
connecting 4 network segments. As such, this box doesn't seem to require
the ability to send its own multicast packets, correct?

Also, are these four segments all internal networks, or do you have
three internal segments and one external Internet gateway? I think
Adam's suggestion, of using transparent bridging, the best. Whereas the
rule for an external firewall is to DROP everything and then punch
necessary holes in it, for an internal network a bridge should ACCEPT
everything by default except for any DROPs you then add.

As an example, a friend was administering a college network connected to
another college's, which had an obnoxiously administered Netware box
broadcasting IPX/SPX everywhere for no good purpose. He then isolated
its broadcasts (I forget how) and blocked them.

On Wed, Sep 03, 2003 at 09:59:34AM -0400, John Pesce was only escaped
   alone to tell thee:

> On Wed, 3 Sep 2003, Bert wrote:
> 
> > Rusty Yonkers wrote:
> > 
> > > I have a system with 4 network segments that are connected with a
> > > single Linux firewall system... I need to get multicast info from
> > > one side of the system to the others.... I have done some research
> > > ... it seems like if the kernel is setup to support it (not sure
> > > if the stock SuSE 8.2 kernel is) then I might only have to put in
> > > a static route.  I read an article that stated that I simply
> > > needed to also put in ....
> > > ....................... section below from article ........
> > > 
> > > 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: ip route add 224.0.0.0/4 dev eth0

Where may I read this article?

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

or 

route add 224.0.0.0/4 dev eth1

(Newer route binaries don't need the -net option.)

You can add two interfaces to the network with route:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
207.89.130.39   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth1
224.0.0.0       0.0.0.0         240.0.0.0       U     0      0        0 eth1
224.0.0.0       0.0.0.0         240.0.0.0       U     0      0        0 eth0
0.0.0.0         207.89.130.39   0.0.0.0         UG    0      0        0 ppp0


Whether you want to is another thing. The kernel may be smart enough to
recognize that you want both network segments to trade multicast
packets, and that 224.0.0.0 is a virtual network address. Or it may not.
You'll have to experiment.

(Frankly, the whole idea of adding a route for a virtual network seems
like a holdover from the 2.0 days. A sysctl flag for turning off
multicasting on a given interface seems more straightforward. The above
table seems to be ready to send ALL multicast packets over the first
interface, eth1. That would be wrong, if indeed that is the behavior.)

I do note that ipmaddr (no man page, :-( ) sees that all interfaces,
even lo which is not listed by ifconfig as a MULTICAST interface, listen
to 224.0.0.1, the IGMP default address, regardless of how route is
configured. Hmmm.
					  
> > It seems to me that it should be 20, giving you addresses from
> > 224.0.0.0 up to 239.255.255.255.

Wrong. See the two examples above. Remember, the netmask works from the
left (most significant bit) and separates the network bits (the four on
the left, above) from the host bits (the 28 on the right).

> > My multicast knowledge seems to be short here, so I don't know if you 
> > have to add lines to your firewall such as:
> > iptables -A FORWARD -i eth0 -s 224.0.0.0/20 -o eth1 -d 224.0.0.0/20
> > and
> > iptables -A FORWARD -i eth1 -s 224.0.0.0/20 -o eth0 -d 224.0.0.0/20

I think the -d 224.0.0.0/4 would be sufficient.

Or:

iptables -A FORWARD -m pkttype --pkt-type multicast -j ACCEPT

If you have that extension enabled. Again, I think Adam's suggestion
best.

-- 
-16
I am not a Pillar, but a Buttress, of the Established
Church. I support it from without. -- Lord Melbourne