Subject: Solaris Mcast router ignoring requests

From: kbrown@helius (Kevin Brown)
Date: Fri, 14 Nov 1997 16:31:11 -0800 (PST)

Hi,

I'm trying to set up a Solaris 2.5.1 machine as a multicast router,
but I'm having some trouble getting it to listen to multicast
clients on its subnet.  While I can join, view, and initiate mcast
sessions from the Solaris machine itself, it ignores attempts by
other machines (a WinNT 4.0 Server specifically) to join groups. 

Helius (134.154.36.12) and Telcot (134.154.36.9) are connected via
a twisted pair hub, which also provides a connection to the
outside world.

When I use snoop from helius (the Solaris machine), I can see the
mcast packets from telcot (the WinNT machine) showing up as sent
to SAP.MCAST.NET when telcot starts up sdr.  However, helius does
not pass the SAP announcements onto that subnet.

The one thing I find odd about the setup is that the netmask on
helius is 255.255.0.0 while the netmask for telcot is 255.255.255.0.
I believe this is because the router for helius is set to
134.154.151.254 (seems odd to me).  
Because of this, I added a couple of altnet fields to mrouted.conf.
(It worked the same without them).

Am I missing something obvious here?  I've set up a NetBSD mcast
router before but never Solaris, and I just don't see why it's
ignoring telcot's requests. 

Any advice or pointers would be appreciated.  (I've already looked
through everything I could find at www.mbone.com).  I've included
supporting documentation below.

Kevin Brown
(Please respond to [email-masked] if possible)
------------------------------------------------------------------- 

I installed the Solaris_mc35+.2.5.1-patch and set up my mrouted.conf
file as follows:

# $Id: mrouted.conf,v 3.6 1995/06/25 19:11:55 fenner Exp $
#
phyint le0 metric 1 threshold 1 rate_limit 0 altnet 134.154.0.0/16 altnet 134.154.36.0/24
#
tunnel 134.154.36.12 198.189.211.105 metric 1 threshold 32 rate_limit 500
#
# New tunnel to SGI at UCSF (temporary until better tunnel is set up)
tunnel 134.154.36.12 128.218.60.69 metric 1 threshold 32 rate_limit 500

>ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
	inet 127.0.0.1 netmask ff000000 
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
	inet 134.154.36.12 netmask ffff0000 broadcast 134.154.255.255

>more /usr/tmp/mrouted.dump
vifs_with_neighbors = 1
[This host is a leaf]

Virtual Interface Table
Vif  Name  Local-Address                               M  Thr  Rate   Flags
 0    le0  134.154.36.12   subnet: 134.154/16          1  32      0   querier leaf
                alternate subnets: 134.154.36/24
                           groups: 224.0.1.2      
                                   224.2.127.254  
                                   239.255.255.255
                                   224.2.127.253  
                                   224.0.0.4      
                                   224.1.127.255  
                         pkts in : 0
                         pkts out: 6

 1    le0  134.154.36.12   tunnel: 198.189.211.105     1  32    500   leaf
                            peers: 198.189.211.105 (3.255) (0xe)
                         pkts in : 31836
                         pkts out: 0

 2    le0  134.154.36.12   tunnel: 128.218.60.69       1  32    500   leaf
                         pkts in : 0
                         pkts out: 0

--
Kevin Brown				[email-masked]
Department of Acct/CIS			www.mcs.csuhayward.edu/~kbrown
Department of Math/CS			(510) 885-4007
California State University Hayward	Warren Hall 493

---

From: Bill Fenner <[email-masked]>
Date: Sat, 15 Nov 1997 12:19:10 PST

You need to look at /usr/tmp/mrouted.cache (kill -USR2 `cat /etc/mrouted.pid`)
to find out why traffic isn't getting forwarded here.  The mrouted.dump
section that you posted showed that the router is aware of the group
member of 224.2.127.254 (the sdr multicast group), so it should be passing
traffic from the tunnel to the ethernet.

If you have more than one multicast router on your network, you're going
to have trouble with that netmask.  Each multicast router's netmask needs
to cover where multicasts it sends will reach; if the netmasks are
incorrect you can get black holes or loops.

  Bill