Subject: Multicasting between different subnets.

From: Diego Daniel Sosa <[email-masked]>
Date: Tue, 12 May 1998 11:26:27 -0500

Dear Srs,

I'm a developer for educational applications on the web.  I've just
finished developing an app. for multicasting on a virtual classroom,
but:

I send data (via Sockets)  to an IP-multicast (class D) address and
effectively it resends info to the participants in the multicast
session, but only to the ones in the same subnet addresses, (i.e.
157.15.15.xxx); and when I tried connecting from another subnet (i.e.
157.15.16.xxx) to the same multicast address,  my app. could not receive
data sent from different subnet users.

Does anyone know how to transmit data via different subnets and even
different gateways without using tunneling in the process??

Sincerely yours,
------------------------
Diego Daniel Sosa
ITEC - Telecom, Col
------------------------

---

From: Steve Deering <[email-masked]>
Date: Tue, 12 May 1998 09:53:41 -0700

> data sent from different subnet users.

(a) are there multicast routers (i.e., either "real" routers with IP
multicast routing turned on, or Unix boxes running a multicast routing
demon such as mrouted) connected to each of the subnets between which
you want multicast to work, and if so, are those routers connected to
each other by some combination of direct links, other multicast routers,
and/or tunnels?

(b) did you set the IP multicast time-to-live (TTL) socket option in the
sending app to specify an initial TTL greater than 1?

Steve

---

From: D E PRICE <[email-masked]>
Date: Tue, 12 May 1998 18:04:37 +0100

Dear Diego,

	In your email, you use the phrase "subnets"
and quote addresses of 157.15.15.xxx
157.15.16.xxx. These addresses are however two completely
different class B network numbers, rather than subnets
of a single network.

	In any case, I presume from your email that
the two networks have an IP router of some
form between them. For the multicast traffic to move
between the networks, you require that either
the IP router has native multicast support, or that another
machine is introduced,  with two interfaces, one in each network (thus
in effect in parallel with your existing router)
which is capable of being a multicast router.

	The other solution, which you effectively rule
out by saying "without using tunneling", is to introduce
two multicast routers, one in each network, which chat
to each other over a unicast tunnel.

	If you announce what brand/model IP routers currently connect
your networks, perhaps someone else on the list can comment
on whether or not they are inherently multicast capable.

-- 
Dave Price, Technical Director, Telematics Group
Email: [email-masked] PHONE: +44 1970 622428 FAX: +44 1970 622455
Post: Computer Science, University of Wales,
      Penglais, Aberystwyth, WALES, UK, SY23 3DB.

---

From: "Alan J. Flavell" <[email-masked]>
Date: Tue, 12 May 1998 21:23:49 +0100 (BST)

> data sent from different subnet users.

You ordinarily need multicast router functionality between different
subnets, just as you need them between different network numbers. 
This would be achieved in the traditional way by setting up tunnels
between multicast route daemons ("mrouted"s) running on each
participating (sub)network.  Some modern routers have this
functionality built in.

> different gateways without using tunneling in the process??

Some time ago, we found to our surprise that we had multicast service
on a (sub)network that didn't have a multicast route daemon.  What was
happening was this: the router knew how to route unicast packets, but
it did not know how to route multicast packets.  However, as the
"bridge unrouteable protocols" option was turned on in the router, it
was bridging the multicast packets between the two networks.  I asked
around at the time whether this might be harmful, but no-one seemed to
think that it was.  The experts here might want to comment, though?

---

From: Andy McConnell <[email-masked]>
Date: Tue, 12 May 1998 15:16:32 -0700 (PDT)

On Tue, 12 May 1998, D E PRICE wrote:

dap> Dear Diego,
dap> 
dap> 	In your email, you use the phrase "subnets"
dap> and quote addresses of 157.15.15.xxx
dap> 157.15.16.xxx. These addresses are however two completely
dap> different class B network numbers, rather than subnets
dap> of a single network.

Dave -

Check your subnet masks/lengths again... 255.255.0.0 = /16 = class B.
Diego is correct in assuming these are subnets OF a class B (157.15.0.0).

-Andy
--
Andy McConnell       アンディ マッコネル
Network Architect, NTT Multimedia Communications Laboratories

With every passing hour our solar system comes forty-three
thousand miles closer to globular cluster 13 in the
constellation Hercules, and still there are some misfits who
continue to insist that there is no such thing as progress.
                               -- Ransom K. Ferm

---

From: D E PRICE <[email-masked]>
Date: Wed, 13 May 1998 11:03:25 +0100

Dear Andy and Friends,

	Andy is of course quite correct in commenting
that my remark about "different networks" rather than
different "subnets" was rubbish.....

	I think my eyes focussed on the wrong pair of digits... 
else I really am going bonkers....  :-)

	The rest of my email was of course still valid......
Dave

---

From: D E PRICE <[email-masked]>
Date: Wed, 13 May 1998 11:33:32 +0100

Dear Alan and Friends,

	I was just reading your (Alan's) email to Diego. I noticed
your remarks at the bottom re: "bridge unrouteable protocols".

My opinions on this are somewhat mixed and uncertain...

(and in any case no one will give any credibility
to my views after my "error" on classifying IP networks :-) )

Obviously, this ( "bridge unrouteable protocols" )
now implies that any multicast one side
of that node is shipped to the other. If this router
had multiple interfaces, then there is the potential
surely for (at least) two types of problem.

1/. All multicast being received on sections would
be forwarded, thus potentially straining the forwarding
capacity of the router and potentially providing
heavy load on your sections....

2/. There is surely also a risk of multiple delivery
of traffic. Imagine you had separately enabled
multicast into two segments, would the "router as a bridge"
now not forward this across into each segment, thus having each segment
seeing the traffic twice??

Oh, and 3/.   Even if only two interfaces, what might be trying
to deliberately tunnel multicast into one section but
kept the other multicast clean. This would break that too...

Dave Price

---

From: "Alan J. Flavell" <[email-masked]>
Date: Wed, 13 May 1998 11:58:17 +0100 (BST)

> My opinions on this are somewhat mixed and uncertain...

Well, I made an observation, and reported what we had seen.  In the
(unlikely?) event that Diego wanted to copy what I was reporting,
naturally the considerations you mentioned would have to be taken into
account.

> of that node is shipped to the other.

Indeed.  The whole intention of turning on this option was to provide
connectivity for protocols which the router did not know how to route.
As far as I recall, it was Appletalk and LAT that were of particular
interest for us at that time, but we simply turned on the option
globally.

> capacity of the router ...

Sure.  That hadn't been an issue for us at that time - the DECNIS
router had massively more processing capacity than we needed, and the
two (sub)networks were relatively lightly loaded at the time. 

> seeing the traffic twice??

Of course, and now that we are running mrouted processes on both
(sub)networks, we have disabled bridging of this protocol in the
router.

> kept the other multicast clean. This would break that too...

Sure.  See above.  I only found out by chance that the multicast was
"leaking" onto the other subnet as a side-effect of the router
configuration, but it did appear to work, and I'm reporting what we
saw.  What you do with that piece of information is entirely up to
you. 

But more seriously, my concern was that some discrepancy in TTLs
between (routed) unicast and (bridged) multicast packets might be
having more global consequences, such as upsetting pruning mechanisms
etc. elsewhere in the MBone.  Which is why I had raised the question
before, but no-one seemed to feel that there was a problem with it. 

all the best

---

From: Steve Deering <[email-masked]>
Date: Wed, 13 May 1998 07:59:51 -0700

> think that it was.  The experts here might want to comment, though?

A few potential problems that spring to mind:

If someone should later install or enable an IP multicast router on the
second subnetwork without disabling the multicast bridging function, you
might get into trouble.  I recall the occurrence of a multicast packet loop
in DVMRP at one time, caused by someone putting a bridge between two
previously unbridged ethernets, each of which had an active DVMRP router
attached.  We talked about ways of making DVMRP detect and correct such
surprises, but I'm not sure if any remedy ever made it into the distributed
code.

Hosts on the second subnetwork would be able to receive IP multicast
originating anywhere, but multicasts *sent* from hosts on the second
subnetwork would probably not get forwarded beyond the bridged segments,
since the subnet prefix of the second subnetwork would not be known by
the IP multicast routing as a valid source prefix.

As you mentioned in a follow-up message, this configuration violates
the assumption that a multicast packet sent with TTL=1 can only go to
neighbors on the same IP subnet, which would "break" any apps that depend
on that assumption being true.

Steve

---

From: Diego Daniel Sosa <[email-masked]>
Date: Thu, 14 May 1998 10:25:01 -0500

As far as  I am concerned, from the appreciations you have made I understand
the convenience of not changing options on the routers to make IP Multicast
work (am I right?), it should be handled by altering the software in order to
send the datagrams to the hardware, directly, which must be capable of
resending them to the multicast group.

I did what Bob Quinn and Steve Deering told me to do (increase the TTL socket
option to bypass the local net) but it is not working yet, so I am going to
explain my situation clearly for anyone who could help me again:

I have two subnets (200.21.27.xxx and 200.21.28.xxx) which are connected by a
Power Hub by Fore Systems.  I am sending datagrams from one subnet to another
(since computers inside the same subnet receive and send datagrams from and
to an IP multicast direction: 233.1.1.1), and I have set the TTL at 3 (should
it be higher?, I don't think so..).  The software was implemented in Visual
C++, using winsock32 library and, in the program, the following two lines are
set to change the options of the socket:

setsockopt (sockRx, IPPROTO_IP, IP_MULTICAST_TTL, &TimeToLive,sizeof(int))
setsockopt (sockRx, IPPROTO_IP,
P_ADD_MEMBERSHIP,&inAddstruct,sizeof(inAddstruct))
WSAAsyncSelect (sockRx, m_hWnd, WSA_READ, FD_READ)

and, as I was saying, it is not working yet.

Thank you all, for your comments and clariffications,

------------------------
Diego Daniel Sosa
ITEC - Telecom, Col
------------------------

---

From: Diego Daniel Sosa <[email-masked]>
Date: Fri, 15 May 1998 09:56:01 -0500

setsockopt (sockRx, IPPROTO_IP, IP_MULTICAST_TTL, &TimeToLive,sizeof(int))
setsockopt (sockRx, IPPROTO_IP,
IP_ADD_MEMBERSHIP,&inAddstruct,sizeof(inAddstruct))
WSAAsyncSelect (sockRx, m_hWnd, WSA_READ, FD_READ)

------------------------
Diego Daniel Sosa
ITEC - Telecom, Col
------------------------

P.S.  "I am sending this message again cause we are having troubles with our
E-mail server".

---

From: ORLHAC Christophe <[email-masked]>
Date: Sat, 18 Apr 1998 09:17:22 +0200

Hi,

I had had the same problem with a PowerHub 6000, I had to update the
version of its driver. I think you have the same problem.

What is your current version of PowerHub ?

A+.
Christophe.

Diego Daniel Sosa wrote:

>  As far as  I am concerned, from the appreciations you have made I
> understand the convenience of not changing options on the routers to
> make IP Multicast work (am I right?), it should be handled by altering
> the software in order to send the datagrams to the hardware, directly,
> which must be capable of resending them to the multicast group.
>
> I did what Bob Quinn and Steve Deering told me to do (increase the TTL
> socket option to bypass the local net) but it is not working yet, so I
> am going to explain my situation clearly for anyone who could help me
> again:
>
> I have two subnets (200.21.27.xxx and 200.21.28.xxx) which are
> connected by a Power Hub by Fore Systems.  I am sending datagrams from
> one subnet to another (since computers inside the same subnet receive
> and send datagrams from and to an IP multicast direction: 233.1.1.1),
> and I have set the TTL at 3 (should it be higher?, I don't think
> so..).  The software was implemented in Visual C++, using winsock32
> library and, in the program, the following two lines are set to change
> the options of the socket:
>
> P.S.  "I am sending this message again cause we are having troubles
> with our E-mail server".
>
>
> Alan J. Flavell wrote:
>

---

From: Diego Daniel Sosa <[email-masked]>
Date: Mon, 18 May 1998 09:03:06 -0500

Christophe,

Our PowerHub is a Fore 7000 series.  What do you mean with 'driver'?  Is
it the operating system of the PowerHub, or an specific application on
the local host?; and, Where can I find that driver?

I have a final question, did you do an IP-Multicast application which
works without tunneling between mrouters (multicast routers)?  I have
made an application for sending directly to an mrouter which must be
capable of resending datagrams to other mrouters by detecting locally
(via an IGMP protocol) the IP-Multicast or class D address.

Thanks a lot,

------------------------
  Diego Daniel Sosa
  ITEC - Telecom, Col.
------------------------

ORLHAC Christophe wrote:

>> make IP Multicast work (am I right?), it should be handled by
>> altering the software in order to send the datagrams to the
>> hardware, directly, which must be capable of resending them to the
>> multicast group.
>>
>> I did what Bob Quinn and Steve Deering told me to do (increase the
>> TTL socket option to bypass the local net) but it is not working
>> yet, so I am going to explain my situation clearly for anyone who
>> could help me again:
>>
>> connected by a Power Hub by Fore Systems.  I am sending datagrams
>> from one subnet to another (since computers inside the same subnet
>> receive and send datagrams from and to an IP multicast direction:
>> 233.1.1.1), and I have set the TTL at 3 (should it be higher?, I
>> don't think so..).  The software was implemented in Visual C++,
>> using winsock32 library and, in the program, the following two lines
>> are set to change the options of the socket:
>>

---

From: ORLHAC Christophe <[email-masked]>
Date: Mon, 18 May 1998 16:59:06 +0200

Hi,

> Our PowerHub is a Fore 7000 series.

Mine is a powerhub 6000, I think your operating system is Ok because
mine must be older.Have you enable IPmulticast forwardind on all
interface that have to forward IP multicast ?
Have you set the " multicast aware bridging" command ?
Have you enabled the correct port ?

> works without tunneling between mrouters (multicast routers)?

Why a tunnel if there is only mrouters ? I don't understand what do you
mean ?

> I have made an application for sending directly to an mrouter which
> must be capable of resending datagrams to other mrouters by detecting
> locally  (via an IGMP protocol) the IP-Multicast or class D address.
>

I have made a multicast application using the JDK 1.1.6. There is a
server which send a meter and there are listeners which show this meter.
You need a JRE to run them (http://www.sunfoft.com). I am running these
applications between to multicast networks interconnected by a tunnel. I
am running them between to networks interconnected by a powerhub 6000
too.
You can use VIC or VAT or all the "classical" Mbone tools, they are able
to be forwarded by mrouters.

A+.
Christophe.

---

From: ORLHAC Christophe <[email-masked]>
Date: Mon, 18 May 1998 17:10:38 +0200

Another thing,

> works without tunneling between mrouters (multicast routers)?

Mrouters like Cisco or mrouted are ok to forward ip multicast. But I
have some problems with the powerhub (I have checked it) and I had to
use a tunnel to forward multicast.

I think you have only the problem with your powerhub. I didn't
understand your problem at the first time you've exposed it. Sorry...

Christophe.