Subject: Regarding complaints about Solaris having bug in RPF check

From: Sangeeta Mukherjee <[email-masked]>
Date: Wed, 19 Aug 1998 16:51:00 -0700 (PDT)

A while back Bill Fenner reported a Solaris multicast routing bug 
(see below). We have also heard that this bug exacerbates the system 
causing it to either hang or frequently crash.

Although I can recreate the RPF failure bug in our lab setup, I am
unable to recreate a scenario where it leads to crashing or hanging.

Has anyone had this the RPF bug actually causes their Sun mc 
router to hang or crash? If so, could you
kindly send me email? I need sufficient data to verify
that this indeed occurs (a core dump output will be 
useful for instance).

Thanks in advance
Sangeeta

----- Begin Included Message -----

I've had a vague suspicion for a long time that Solaris's RPF check
on tunnels doesn't drop packets that are received on an incorrect
tunnel.  
Now, the owner of broodjeham.surfnet.nl is complaining that his
router is forwarding packets that come in on the wrong tunnel.  Could
you look into this -- make sure that the RPF check happens on packets
arriving on tunnels and that it can differentiate between different
tunnels?
 
Thanks,
  Bill

>(Message inbox:3864)
>Subject:  Re: Multicast packet duplicates
>Date:     Tue, 17 Jun 97 01:57:04 PDT
>From:     Niels den Otter <[email-masked]>
>To:       Bill Fenner <[email-masked]>
>cc:       [email-masked], [email-masked], [email-masked]
>
>
>==> From: Bill Fenner
>
>> Niels den Otter <[email-masked]> wrote:
>> >I have cc:-ed mbone-eu-op because this has also implications for mrouters
>> >that get the feed of these groups from broodjeham.  Broodjeham also sends
>> >the duplicates on these tunnels.
>>
>> Are you positive?  One of the packets should just fail its rpf check
>> and broodjeham will drop it.
>
>That is what I would expect. But looking at the following tcpdump output:
>
>13:50:19.374487 0:60:3e:42:27:61 8:0:20:74:5b:40 0800 535: 192.36.148.206 >
>192.87.106.102: 192.188.104.56.1075 > 224.2.172.238.51482: udp 473 (ttl 120,
>id 12613) (ttl 59, id 10274)
>
>13:50:19.374686 8:0:20:74:5b:40 0:60:3e:42:27:61 0800 535: 192.87.106.102 >
>145.41.1.6: 192.188.104.56.1075 > 224.2.172.238.51482: udp 473 (ttl 119, id
>12613) (DF) (ttl 64, id 35600)
>
>13:50:19.387576 0:60:3e:42:27:61 8:0:20:74:5b:40 0800 535: 193.174.226.254 >
>192.87.106.102: 192.188.104.56.1075 > 224.2.172.238.51482: udp 473 (ttl 120,
>id 12613) (ttl 245, id 17746)
>
>13:50:19.388557 8:0:20:74:5b:40 0:60:3e:42:27:61 0800 535: 192.87.106.102 >
145.41.1.6: 192.188.104.56.1075 > 224.2.172.238.51482: udp 473 (ttl 119, id
>12613) (DF) (ttl 64, id 35605)
>
>I would say that the same packet (id 12613) is received from both
>192.36.148.206 and from 193.174.226.254. Then it is sent twice to
>145.41.1.6. 
>This can also be seen in the RTP stats of certain sessions. The
>dups counter is going up continuously.
----- End Included Message -----