Subject: linux multicast ...

From: Dwight Spencer <[email-masked]>
Date: Thu, 15 May 1997 09:24:43 -0300

I've finally found mrouted for linux, and set it up at home.   I'm running
mrouted and have defined a tunnel over a 33.6 ppp link.
Traffics been going at a steady high rate for  over an hour.

What I'd like to ask is this.  At home, I'm using the class b 
domain of 192.168.* (192.168.0.* actually), and I would like to know
if my tunnel, from 131.202.3.18, over the ppp link to 198.164.125.55,
which is the host on my home lan, 192.168.0.3, will break
multicast routing by my using this domain.  If yes, then I'll shut
down the tunnel immediatly.

assuming no, this is my mrouted.conf on the linux host at home:

==

phyint eth0		# 192.168.0.3
tunnel 198.164.125.55 metric 1 threshold 32 rate_limit 20

==

I assume this is correct, but I'll have to wait til I get home after
work (and after the intial startup flood Bill F. warned me about)
to see if actual sessions are crossing this link, and being advertised
on the ether segment at home.  

a few questions:

- Anyone else on this list using mrouted on a linux host who could
 tell me if this logically should work, ignoring the fact that I'm trying
it over a modem?

- would running mrouted with the debug flag slow it by 
any significant amount?

- do rate_limit specifications have to be on -both- sides of a 
tunnel configuration? .. on the remote (lan) based tunnel
command, I do not have the rate_limit specification.

Does anyone on this list have any warnings to give, other than the
fact that I may be crazy for attempting this over a 33.6 ppp link?  :)

thanks,
dwight s. (who can't get isdn or adsl yet)
==
dwight spencer				phone:  506 444 5389
internet services manager			fax:    506 444 4232
[email-masked]

TeleEducation NB, 500 Beaverbrook Court,
Fredericton, NB, Canada, E3B 5H1

---

From: Bill Fenner <[email-masked]>
Date: Thu, 15 May 1997 08:49:35 PDT

Dwight Spencer <[email-masked]> wrote:
>multicast routing by my using this domain.

Don't expect to be able to source any traffic, since there are probably
others using 192.168.0/24 so routing will be confused.  You should be
able to listen OK, though.

>- would running mrouted with the debug flag slow it by 

It slows it down noticeably, but not so much that it can't do its job.

>command, I do not have the rate_limit specification.

rate_limit applies to traffic that this host sends; if you don't
have a rate_limit on the lan end it won't rate limit traffic towards
the modem.

  Bill

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 15 May 1997 18:55:30 +0200

>>>>> "BF" == Bill Fenner <[email-masked]> writes:

 >> multicast routing by my using this domain.

 BF> Don't expect to be able to source any traffic, since there are probably
 BF> others using 192.168.0/24 so routing will be confused.  You should be
 BF> able to listen OK, though.

I have seen several cases where people have machines in those
homebrewed addresses which be happy if they could receive trafic from
the propper side of a router to the private network side without the
need to confuse routing on the outside. The easy way of achieving this
is by simply forward trafic to private address networks but not
announce them in the non-propper world. However, for larger private
networks there is a need to allow routing of the private addresses so
one needs to be able to make the restriction at the border between
private and global addresses. Now, I don't beleive that this is a hard
thing to implement, but until it is we will continue to see private
addresses being announced on Mbone.

In order to let a machine in the private address space to source
trafic must the multicast router act in a IP Masquerading fasion. This
is not really in mrouteds scope but it can still be done there. This
have ofcourse limits, but it may be a compromise worth considering.

Cheers,
Magnus

---

From: Mark Handley <[email-masked]>
Date: Thu, 15 May 1997 14:09:37 -0400

>able to listen OK, though.

Note though that retransmissions from applications like WB and NTE
require that you be able to transmit, so missing data may not be
filled in.  Audio and Video should be OK.

Mark