Subject: MBONE address

From: THeresa Held x3959 <[email-masked]>
Date: Tue, 19 May 1998 11:41:38 -0400 (EDT)

TWIMC,

We have started monitoring the traffic throught our switch and noticed 
a large amount of traffic (33% of total traffic) is from various
sources to destinations which have 224.2.xx.xx addresses.  I was 
wondering if the 224.2 is a mbone participants address.  

example r2u1.hpomo.hpc.mil => 224.2.242.210

picasso 30# nslookup 224.2.242.210
Server:  dns2.gsfc.nasa.gov
Address:  128.183.50.17

*** dns2.gsfc.nasa.gov can't find 224.2.242.210: Non-existent host/domain

traceroutes time out to all the 224.2.xx.xx  addresses.

I'm just trying to understand how we are ending up with so much
traffic through our rib which has neither source nor destination
on our rib or in our domain  128.183.33.xxx.

Thanks for any assistance you can provide.

THeresa

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 19 May 1998 13:09:38 -0400 (EDT)

Hello,

It appears your switch has found its way onto the mbone.  The 224.2.x.x
addresses are called group addresses.  These addresses are special in that
if one sends a packet to these addresses, the packet is delivered to other
members of the "group"

This allows one person to send to many people with the same stream of
packets. They are replicated in the routing equipment that does multicast
routing.  The group 224.2.242.210 is not currently in my tables, so it is
possible they have stopped sending.  In any rate, if a person inside your
organization has joined one of these groups, it is possible you will see
traffic from a source which is outside your organization to one of these
groups.  The group addresses range from 224.0.0.0 to 239.255.255.255.  The
239.0.0.0 through 239.255.255.255 are supposidly scoped, meaning they
should be kept within some administrative boundary.  In practice, this
isn't well enforced, so if you want to use it, you need to bound it
yourself.

Hope this helps.

_J

---

From: Bill Fink <[email-masked]>
Date: Tue, 19 May 1998 19:21:47 -0400 (EDT)

What happened is as follows.  The Ethernet segment (128.183.33) that
was seeing all the IP multicast traffic had been converted to using
PIM dense-mode off a cisco router (which then had a PIM/DVMRP
connection to an mrouted serving NASA Goddard).  However, due
to an oversight, the mrouted (on an SGI system) that had previously
serviced the Ethernet segment (via a DVMRP tunnel to the Goddard
mrouted) had not been turned off, although the tunnel had been
removed on the Goddard mrouted side.

Somehow, this combination caused the cisco to treat the Ethernet segment
as a non-leaf segment (which I can understand), and also to forward all
IP multicast traffic onto the the Ethernet segment without pruning,
even though the mrouted on the SGI didn't have anywhere to forward
the IP multicast traffic (only the Ethernet segment was enabled and
the old DVMRP tunnel was down since the other end had been removed).

In any event, I killed the mrouted on the SGI.  After a few minutes,
the Ethernet segment became a leaf segment, and after a few more minutes,
once pruning occurred, the unwanted IP multicast traffic ceased.  Now,
only the expected IP multicast traffic is seen on the Ethernet segment.

						-Bill

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 19 May 1998 23:41:40 -0400 (EDT)

yes, I have seen this before.  What is the reasons ciscos won't prune when
dvmrp neighbors are present? I forgot now.  They even ignore prunes.

---

From: Petri Helenius <[email-masked]>
Date: Wed, 20 May 1998 07:12:53 +0300 (EEST)

> dvmrp neighbors are present? I forgot now.  They even ignore prunes.

They don't process prunes from multi access networks because it "would 
take too much state".

Pete

---

From: [email-masked] (Jeremy Hall)
Date: Wed, 20 May 1998 05:37:06 -0400 (EDT)

well ain't that just dandy.

I'll bet BGMP or other new inventions will take more state than this.

---

From: Petri Helenius <[email-masked]>
Date: Wed, 20 May 1998 21:55:30 +0300 (EEST)

> I'll bet BGMP or other new inventions will take more state than this.
I didn't say I believed the explanation or the reasoning behind it :-)

Pete

---

From: Bill Fenner <[email-masked]>
Date: Sat, 23 May 1998 16:23:50 PDT

>dvmrp neighbors are present? I forgot now.  They even ignore prunes.

Because they don't want to keep the extra state (per route and per
route,group pair) that DVMRP requires.

  Bill