Subject: No US multicast sessions.

From: Niels den Otter <[email-masked]>
Date: Tue, 20 May 1997 08:36:53 +0200

Hello,

I do not receive SDR sessions from the US anymore (here in the Netherlands).
Only European sessions pop-up in my SDR window.

A quick conclusion from some mtraces would be that no European multicast
routes arrive in the US:

  surver[root]% mtrace 192.87.110.4 140.142.10.227
  Mtrace from 192.87.110.4 to 140.142.10.227 via group 224.2.0.1
  Querying full reverse path... * switching to hop-by-hop:
    0  www-s1.cac.washington.edu (140.142.10.227)
   -1  * * * Timed out receiving responses
  Perhaps receiver 140.142.10.227 is not a member of group 224.2.0.1,
  or no router local to it has a route for source 192.87.110.4,
  or multicast at ttl 64 doesn't reach its last-hop router for that source

Since I don't have time at this moment to examine this problem further I
would like to ask on the list if anyone knows why this is happening. 

Regards,

Niels den Otter
SURFnet - Network Services

---

From: Petri Helenius <[email-masked]>
Date: Tue, 20 May 1997 10:05:06 +0300 (EEST)

> Only European sessions pop-up in my SDR window.
Here (*.sms.fi) I see many sessions from the US and the shuttle
transmission is also ok, so I guess your problem is of local or
semi-local nature.

Pete

---

From: Niels den Otter <[email-masked]>
Date: Tue, 20 May 1997 09:27:26 +0200

Petri,

> transmission is also ok, so I guess your problem is of local or

Thanks for your quick respond. It was a local problem.

What we tried to do (last friday) was to block incoming DVMRP routes on a
Cisco router and then distribute a static default instead to the rest of our
testnetwork (according to the document 'How to run with a minimal DVMRP
table using IOS'). This doesn't seem to work completely. We still distribute
the default-only from this Cisco, but I removed the incoming DVMRP filter on
the first Cisco and now it works.

I find it very strange that we did see european sessions and that it did
work last Friday. Well, this is for further study.

Thanks again,

Niels

---

From: Bill Fenner <[email-masked]>
Date: Tue, 20 May 1997 10:02:39 PDT

>work last Friday. Well, this is for further study.

mrouted 3.8 can fail to time out subordinateness when a neighbor stops
advertising poison-reverse routes.  This could explain why you saw some
traffic and not other.  If mrouted timed out properly then you would have
seen no traffic at all.

  Bill