Subject: More Multicast, Multi-Interface Sparc-5 Woes

From: Chris Jepeway <[email-masked]>
Date: Tue, 02 Jan 1996 14:19:53 -0500

I've got a Sparc-5 running SunOS-4.1.3_U1 with 2
"ethernet" interfaces: it has its onboard le0 and
one of the 100Mbps be0 Sbus cards.  I added the
kernel support for multicast IP for both interfaces
using the mcast_install script in the ipmulticast-3.5
package.  I can build and boot a kernel that can
squirt packets out either interface, and the kernel
can see multicast packets through the le0 interface
just fine.

I get the strangest behavior when using the be0
interface, though.  That interface is connected
to a switching hub which links the Sparc-5 in
question with some more Sparc-5's running stock
SunOS.  When I try to communicate with one of the
other Sparc-5's, I see a wild fluctuation in
bandwidth: using spray, I get anywhere from
40Mb/s (the max you can get out of SunOS) down to
8Kb/s.  Worse, the be0 interface eventually locks
up entirely.  be0 can often, however, be resurrected
by doing an 'ifconfig be0 up' even though it's
not marked down.  Note that I get this behavior
when sending/recving *unicast* packets.  I can't
seem to send any multicast packets out the be0
interface at all.

Help?

Chris <[email-masked]>
Lab Engineer, Computer Science Department
University of TN, Knoxville

---

From: Matt Crawford <[email-masked]>
Date: Tue, 02 Jan 1996 14:38:28 -0600

> [...] one of the 100Mbps be0 Sbus cards.  I added the
> kernel support for multicast IP for both interfaces [...]
> interface, though.

I don't get the fluctuating throughput or the complete lockup that
you report, but I do have another strange symptom.  Whenever I join
or leave a multicast group on the be0 interface, the interface seems
to do a complete reset.  Attempts to communicate with the author of
the multicast version of the driver have not succeeded.
_________________________________________________________
Matt Crawford          [email-masked]          Fermilab
  PGP: D5 27 83 7A 25 25 7D FB  09 3C BA 33 71 C4 DA 6A

---

From: Paul Stewart <[email-masked]>
Date: Tue, 2 Jan 1996 14:14:24 PST

In message <[email-masked]>you write:
>SunOS.
>[...]  I can't

Are you sure the multicast packets are not leaving the interface, as opposed 
to the ethernet switch swallowing those packets?  The ethernet switch designer 
has potentially at least three policies as far as multicast packets go: do not 
send multicast packets to any port, because it doesn't match the ethernet 
address of any endpoint (this could be the policy if the designer hadn't even 
considered multicast), treat them as broadcast (i.e., resend on all ports), 
and thirdly it could perform some sort of "IGMP snooping", which some switches 
perform nowadays.  The first method would cause the problems you describe, the 
second is inefficient, and the third isn't quite optimal and breaks in some 
situations.  

In either case, check your switch documentation and whatever status tools are 
at your disposal before you assume that the interface isn't originating 
multicast packets.

--
Paul

---

From: William Armitage <[email-masked]>
Date: Wed, 03 Jan 1996 09:21:19 +0000

> seem to send any multicast packets out the be0

I gave up on the "be" card under 4.1.3.
If you search through the online sunsolve for fast_enet you will find
some rather horendous problem reports. The Solaris driver is upto
rev 9. (102001-09    SunOS 5.4: jumbo patch for be, qe, le drivers)
I've not found any SunOS 4 patches.

Also note that a second generation fast ethernet card has been announced
based on the HME ASIC rather than Big Mac. This is also used in the
Wide SCSI/Fast Ethernet combo and on the Ultra motherboard.
I have this feeling of my 6 "be" cards are orphaned.

Cheers,
William.

---

From: [email-masked]
Date: Wed, 3 Jan 1996 12:20:25 +0000 (GMT)

>second is inefficient, and the third isn't quite optimal and breaks in some 

A further problem with the `treat as broadcast' policy (which is
probably the simplest `correct' behaviour to implement for a switch)
is that some switches do `broadcast rate limiting' to reduce the
problems of broadcast storms. Your multicast traffic might be getting
dropped because the switch thinks it is a storm!

I prefer the idea of a switch that actually takes part in IGMP on each
port. They already have to do spanning tree that way, so the hardware
should be able to support it. I believe the Catalyst 5000 can do this,
but I have not heard of any others.

Andrew

----------------------------------------------------------------------------
|      From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK     |
| [email-masked]     +44 1895 203066 or +44 1895 274000 x2512 |
----------------------------------------------------------------------------

---

From: Petri Helenius <[email-masked]>
Date: Wed, 3 Jan 1996 16:16:20 +0200

> but I have not heard of any others.
That's Catalyst 1200. The 5000 does not (yet?) do it.

Pete

---

From: Chris Jepeway <[email-masked]>
Date: Fri, 05 Jan 1996 21:32:32 -0500

>to the ethernet switch swallowing those packets?
No, I'm not.  Thanks for the suggestion, I'll be
trying to dredge some technical specs out of the
folk involved w/ installing this switch.  Oh,
for what it's worth, the switch is a Synoptics 28115.

So, I still have the unicast problem to deal with.
(Doesn't it seem odd that folk on the mbone list would
overlook that one?).  On my dually-homed Sparc-5 that has
the ipmulticast-3.5 patches applied to it, I get wildly
varying throughput (as measured by spray) when stuffing
unicast packets through the 100Mbps interface.  I don't
have this problem when using a "stock" Sun kernel that
understands the be interface.  Any suggestions as to how I
might begin to solve this problem?  Anybody familiar w/ the
Sun FastEthernet code in the 3.5 release of Multicast IP?

>>Me
>Paul Stewart <[email-masked]>
Chris <[email-masked]>.