Subject: Friday AM: mrouters still sending bogus registers

From: John Hawkinson <[email-masked]>
Date: Fri, 30 Aug 1996 10:57:02 -0400 (EDT)

From both coasts of the US:

199.103.128.254 (boston.terra.net)
144.212.100.1   (?)
139.130.204.6	(mbone-act.gw.au)
145.41.6.71     (Amsterdam6.router.surfnet.nl)
128.141.211.65	(r31-s-rci25-2-gb0.cern.ch)
133.246.10.65	(KEIO-SFC-cisco-e01.expo96.ad.jp)

I sent mail regarding the least to mbone-eu-op and associated
contacts, it seems to have stopped.

Since rest of these folks haven't done anything, their transit
providers ought to filter them (dec2.hay.mci.net, dec2.wtn.mci.net,
mbone3.uu.net, pen-mbone-1.sprintlink.net, and mbone.cern.ch). Per
Bill's mail, you need a boundary statement on phyints and tunnels:

name mcastrp 239.133.130.34/32
phyint le0 boundary mcastrp
tunnel ... boundary mcastrp

[replace le0 with the appropriate name of your phyint, and list all
phyints if you have more than one]

For folks with direct access to these boxes -- if you're running code
that supports "ip pim accept-rp", please use:

	ip pim accept-rp 239.133.130.34 99
	access-list 99 deny 0.0.0.0 255.255.255.255

If your code-base doesn't support that, please disable your MBONE tunnel
and upgrade, preferrably to the images in ftpeng.cisco.com:/dino/bogus-rp,
or otherwise, to a recent (post-February) 11.1 supporting the above workaround.

Thanks!

--jhawk

[all-purpose-gunk!jhawk] ~> mtrace -s 139.130.204.6
Mtrace from 139.130.204.6 to 199.94.220.184 via group 224.2.0.1
Querying full reverse path... * switching to hop-by-hop:
  0  all-purpose-gunk.near.net (199.94.220.184)
 -1  all-purpose-gunk.near.net (199.94.220.184)  DVMRP  thresh^ 1  
 -2  cambridge1-mbone1.bbnplanet.net (199.94.207.2)  DVMRP  thresh^ 16  
 -3  collegepk-mbone1.bbnplanet.net (128.167.252.196)  DVMRP  thresh^ 32  
 -4  paloalto-mbone1.bbnplanet.net (131.119.0.197)  DVMRP  thresh^ 64  
 -5  * * dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61)  DVMRP  thresh^ 32  
 -6  savoy.aarnet.edu.au (139.130.47.2)  DVMRP  thresh^ 64  
 -7  mbone-act.gw.au (139.130.204.6)  PIM  thresh^ 0  
 -8  * * * * dickson.gw.au (139.130.204.1) didn't respond
 -9  * * * 
-10  * * * 
-11  ^C

[all-purpose-gunk!jhawk] ~> mtrace -s 144.212.100.1
Mtrace from 144.212.100.1 to 199.94.220.184 via group 224.2.0.1
Querying full reverse path... 
  0  all-purpose-gunk.near.net (199.94.220.184)
 -1  all-purpose-gunk.near.net (199.94.220.184)  DVMRP  thresh^ 1  
 -2  cambridge1-mbone1.bbnplanet.net (199.94.207.2)  DVMRP  thresh^ 16  
 -3  MBONE3.UU.NET (137.39.229.98)  DVMRP  thresh^ 64  
 -4  gate.mathworks.com (144.212.4.10)  DVMRP  thresh^ 64  
 -5  ? (144.212.100.1)
Round trip time 45 ms

[all-purpose-gunk!jhawk] ~> mtrace -s 199.103.128.25
Mtrace from 199.103.128.25 to 199.94.220.184 via group 224.2.0.1
Querying full reverse path... 
  0  all-purpose-gunk.near.net (199.94.220.184)
 -1  all-purpose-gunk.near.net (199.94.220.184)  DVMRP  thresh^ 1  
 -2  cambridge1-mbone1.bbnplanet.net (199.94.207.2)  DVMRP  thresh^ 16  
 -3  schnell.ebone.net (198.67.134.250)  DVMRP  thresh^ 32  
 -4  pen-mbone-1.sprintlink.net (207.41.200.99)  DVMRP  thresh^ 32  
 -5  boston.terra.net (199.103.128.254)  PIM  thresh^ 0  No route [default]
Round trip time 85 ms

[all-purpose-gunk!jhawk] ~> mtrace -s 133.246.10.65
Mtrace from 133.246.10.65 to 199.94.220.184 via group 224.2.0.1
Querying full reverse path... 
  0  all-purpose-gunk.near.net (199.94.220.184)
 -1  all-purpose-gunk.near.net (199.94.220.184)  DVMRP  thresh^ 1  
 -2  cambridge1-mbone1.bbnplanet.net (199.94.207.2)  DVMRP  thresh^ 16  
 -3  dec3800-2-fddi-0.WestOrange.mci.net (204.70.64.61)  DVMRP  thresh^ 32  
 -4  dec3800-2-fddi-1.Washington.mci.net (204.70.74.77)  DVMRP  thresh^ 1  
 -5  uof.expo96.ad.jp (133.246.10.80)  DVMRP  thresh^ 64  
 -6  KEIO-SFC-cisco-e01.expo96.ad.jp (133.246.10.65)
Round trip time 279 ms

[all-purpose-gunk!jhawk] ~> mtrace -s 128.141.211.65
Mtrace from 128.141.211.65 to 199.94.220.184 via group 224.2.0.1
Querying full reverse path... 
  0  all-purpose-gunk.near.net (199.94.220.184)
 -1  all-purpose-gunk.near.net (199.94.220.184)  DVMRP  thresh^ 1  
 -2  cambridge1-mbone1.bbnplanet.net (199.94.207.2)  DVMRP  thresh^ 16  
 -3  schnell.ebone.net (198.67.134.250)  DVMRP  thresh^ 32  
 -4  stockholm.mbone.ebone.net (192.36.148.206)  DVMRP  thresh^ 64  
 -5  broodjeham.surfnet.nl (193.148.15.2)  DVMRP  thresh^ 48  
 -6  mbone.cern.ch (192.65.185.20)  DVMRP  thresh^ 48  
 -7  b513-b-rsuix-2.cern.ch (128.141.211.1)  DVMRP  thresh^ 10  
 -8  r31-s-rci25-2-gb0.cern.ch (128.141.211.65)
Round trip time 335 ms

---

From: Robert Elz <[email-masked]>
Date: Sat, 31 Aug 1996 01:26:51 +1000

Date:        Fri, 30 Aug 1996 10:57:02 -0400 (EDT)
    From:        John Hawkinson <[email-masked]>
    Message-ID:  <[email-masked]>

I have killed the tunnel to that cisco, it is off the mbone for
now.

If someone (who can) wants to put it back with adequate filtering,
and check with someone who knows how that it is actually no longer
polluting the universe, then fine, but better to have the ACT
off the mbone for the weekend (or forever if needed) than the whole
of AU.

kre

---

From: JR Oldroyd <[email-masked]>
Date: Fri, 30 Aug 1996 17:50:23 -0400 (EDT)

Folks,

I am replying to email from John Hawkinson, sent Thursday evening and
also again Friday morning.

John, the person at TerraNet that you needed to reach is myself.  I have
been dealing with a number of other issues and have not been near email
for about 18 hours.  I realize that you did send your message to a
couple of other people here, but one was out with me, and the other had
no idea of the significance of your message, and only now let me know
that I needed to look at the email.  Perhaps you could have tried
calling us before escalating to sending email to Sprint and UUNET?  Or,
you could have tried addresses such as [email-masked] or [email-masked]
which would have reached someone more appropriate.

I have taken a look at the mbone config here.  The group that you have
complaint about no longer exists (239.133.130.34/32), as you said in
this morning's message.  I cannot see the problem, and so I am not able,
at this time, to determine the source of the offending transmission.
I'm afraid that it is not clear to me from your message whether you feel
that terra.net was the problem, or whether we were distributing someone
else's feed, or even if you have discovered a bug in the Cisco software.
I am not on the MBONE mailing list and have no idea what discussion may
have been going on.  Perhaps you can clarify?

Given that I can see nothing of the problem here any longer, at this
time I can only do the following.  I will shut off a number of MBONE
redistributions from here.  I will also send email to the
administratiors of those connections that must remain asking them to
check what they are doing.  I will remain in touch with them over the
weekend.

Our customers do use the MBONE service, and I believe that at least one
of them is expecting that service to be usable over this weekend.  I
would ask that those other parties CC'd in John's email do not take any
action that may jeopardize our customers' use of the service.  Instead,
if you need to reach me over the weekend, here is my direct pager
number:  (617) 362-7524.  Please page me and I will investigate and
repair whatever new problems arise.

Here at TerraNet we keep reasonably current with Cisco software releases.
However, we do not upgrade to every new version every time one is released.
We do perform periodic updates and we will certainly upgrade if current
software is determinied to have a bug.  However, until your email,
no information of a bug has come to our attention.  If the problem
is a bug, please let me know and I will shedule time for an upgrade
this weekend.

Thank you,
	-jr

---

From: John Hawkinson <[email-masked]>
Date: Fri, 30 Aug 1996 18:09:56 -0400 (EDT)

> also again Friday morning.

Thanks. I've pruned the cc list.

> calling us before escalating to sending email to Sprint and UUNET?

I don't think so. If you're a part of the MBone community, you need
to keep track of issues that relate to it. That means you need to
read [email-masked] and deal with operational issues discussed on
and sent to that mailing list in a timely fashion.

I would have no hesitation removing your service were I in a position
to do so, should it be necesary; see below, it is not necessary.

Frankly speaking, I went out of my way to send emailto you and a lot
of other folks who were causing this problem. I think it's important
that that happen, and I am kind of disappointed that others hadn't done
so.

> Or, you could have tried addresses such as [email-masked] or
> [email-masked] which would have reached someone more appropriate.

I used the addresses listed in the RADB and the WHOIS contact, as well
as the contact addresses we (BBN) have for you [though this problem
does not relate to connectivity you receive from us]. If you think other
contact addresses are appropriate you ought to list them...

> at this time, to determine the source of the offending transmission.

The problem continues to be present. 

# ./tcpdump host 239.133.130.34
tcpdump: listening on le0
18:00:47.786290 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:48.157379 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:49.293535 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:51.092375 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:52.933036 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:53.239992 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:53.971441 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:54.545359 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:54.669388 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:55.902463 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:00:58.093258 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:01:00.191328 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]
18:01:01.708720 boston.terra.net > 239.133.130.34: igmp-4 [b1=0x1]

> have been going on.  Perhaps you can clarify?

Ah. EXECUTIVE SUMMARY: There is a bug affecting ALL CISCO ROUTERS
RUNNING PIM CONNECTED TO THE MBONE that causes them to send bogus PIM
Register packets to this multicast group. This is a serious problem,
and from my perspective, most everyone has fixed it except for you
guys (other people at other places in the topology may see things
differently).

[ Hmm; after writing this message, it turns out that there are still
a number of other sources. In particular:

	cisco2503.CRLABS.COM				NEW!
	sw-192.12.88.0.rutgers.edu 			NEW!
	KEIO-SFC-cisco-e01.expo96.ad.jp

]

You can see that this is a problem with "show ip pim rp", or "show ip mr"
and look for RPs that are multicast addresses (239.133.130.34).

I take it that you are not running a version of software that
permits the "ip pim accept-rp" command? That is unfortunate.

> action that may jeopardize our customers' use of the service.

The filtering I requested Sprintlink implement only affects traffic
to this bogus group; it does not reflect traffic to any valid
multicast group. As such, they should feel free (encouraged!) to do this.

It is disturbing to think that there are folks who are offering MBone
as a production service but aren't paying attention to what goes on in
the Mbone community. Perhaps this is a larger problem than just you,
and it may mean that we (the MBone community) need to do some work here.

Certainly I have not been quite as diligent as I ought to in ensuring
that all of my multicast customers are paying attention.

Hopefully this clarifies issues.

--jhawk
  John Hawkinson

---

From: Petri Helenius <[email-masked]>
Date: Sat, 31 Aug 1996 17:59:19 +0300 (EET DST)

> 	KEIO-SFC-cisco-e01.expo96.ad.jp

The only one left visible to Finland is:
Name: cisco4000gateway.cc.gettysburg.edu
Address: 138.234.4.7

However, there might be quite a lot of broken ones still around
because of there are quite many filters now in place.

Pete