Multicast Sockets - A note on group addresses and nee167

Date: Tue, 16 Nov 1999 17:42:55 -0500 (EST)
From: David Ott 
To: COMP 249 -- Anand Srinivasan ,
     Sanjoy Baruah , Alex Blate ,
     Steven Boles , Wei Chao Chen ,
     Deepak Bandyopadhyay , Felix Hernandez ,
     Kevin Jeffay , Abdelkarim Mardini ,
     David Ott , Praveen Patnala ,
     Ramkumar Parameswaran , Ruigang Yang ,
     Vibhor Jain , Zhiwei Xiao 
Subject: mcast addresses and nee167


What you need to know:
--------------------- 

When choosing a multicast address for use with nee167, you'll need to use
a group address within the following ranges:

       224.59.10.0 - 224.59.10.255
       224.59.11.0 - 224.59.11.255

For any other multicast address, you'll find that nee can receive
multicast packets from that group address okay, but is unable to send to
that mulitcast group address.


Background on the problem (FYI):
-------------------------------

Summary: Turns out static routes needed to be set on nee to enable the
sending of multicast packets on its non-default (152.19.167) interface.

To explain a little, nee is configured to check the destination address
when a sendto call is made.  If that address is on the 152.19.167.*
network, then it will send it out on the comp249 interface (xl1). If,
however, it does not match, then it will send it out the department
interface (xl0).  The latter represents the default case.

The problem we've seen is that after using setsockopt to tell nee which
interface to listen to multicast packets on, the socket can receive
multicast packets from that multicast group just fine, but is unable to
send any. It appears that the network configuration of nee doesn't support
sending to multicast addresses on the comp249 network since they do not
match the 152.19.167.* prefix.

The solution is to configure nee to forward packets with specific
multicast destination addresses to the comp249 interface--despite the fact
that these addresses do not match the 152.19.167 prefix. I have done this
for the following multicast address ranges:

        224.59.10.0 - 224.59.10.255
        224.59.11.0 - 224.59.11.255

This seems to fix the problem.

Hope this makes sense.  If not, no worry.  Just follow the guidelines in
the first section above.

-d