Subject: Re: %PIM-1-INVALID_RP_REG:

From: John Hawkinson <[email-masked]>
Date: Sun, 24 Nov 1996 21:51:31 -0500

>   Recently this message has begun every minute:
> 
> Nov 24 19:54:28 bifrost.net.yale.edu 28898: %PIM-1-INVALID_RP_REG: Received
> Register from 192.41.177.85 for 224.2.0.1, not willing to be RP

This means that 192.41.177.85, aka mae-east.cais.com, is broken and needs
to be fixed. Bill's message alluded to this fact.

>   Following the formula from the last episode I added these lines:
> 
> ip pim accept-rp 192.41.177.85 99

You do not want or need this. You should never be receiving joins for unicast
addresses instead of multicast groups. Cisco's code should not allow this.

> ip pim accept-rp 239.133.130.34 99
> access-list 99 deny   any

This should have been present and should never be removed...

>   The messages continue.  Can anyone help me with a command series
>   that will get me out of the poison?

You are not infected with the poison, the CAIS router is. The messages will not
go away until the either CAIS fixes their router or someone on the path between
your router and you fixes the problem.

You should mtrace to 192.41.177.85 on 239.133.130.34 (most likely the group in
question, though the syslog message does not tell you that) and request the
administrators of the router upstream of you apply boundaries (if they are
mrouted) or accept-filters (if they are PIM routers) to avoid this problem.

--jhawk

---

From: Mobasshar Ahmed <[email-masked]>
Date: Mon, 25 Nov 1996 07:13:50 +0000 (GMT)

On Sun, 24 Nov 1996, John Hawkinson wrote:

Cais arnt on this mail list.
The MultiCast List is for us. But our link to mae-east.cais.com is down. 
Can someone tell me what the problems is (and how to fix it). Its a cisco 
running 11.1 (mrinfo mae-east.cais.com)

> mrouted) or accept-filters (if they are PIM routers) to avoid this problem.

---
Mobasshar Ahmed                                   http://www.on-net.co.uk
Technical Manager                                 [email-masked]
ON-NET                                            Yes we sell to ISPs
Tel:	++44-181-256-9990                         FAX:	++44-181-288-0222

---

From: Mitch Collinsworth <[email-masked]>
Date: Wed, 27 Nov 1996 15:09:51 -0500

>> Register from 192.41.177.85 for 224.2.0.1, not willing to be RP

I've been seeing this for quite some time now.

>mrouted) or accept-filters (if they are PIM routers) to avoid this problem.

It's a pretty short path from here:

gangway>mtrace 192.41.177.85 239.133.130.34
Type escape sequence to abort.
Mtrace from 192.41.177.85 to 128.84.247.246 via group 239.133.130.34
From source (mae-east.cais.com) to destination (GANGWAY.GRAPHICS.CORNELL.EDU)
Querying full reverse path... * switching to hop-by-hop:
 0  GANGWAY.GRAPHICS.CORNELL.EDU (128.84.247.246)
-1  GANGWAY.GRAPHICS.CORNELL.EDU (128.84.247.246) DVMRP  thresh^ 0  7 ms  
-2  MBONE.CIT.CORNELL.EDU (192.35.82.97) DVMRP  thresh^ 4  202796 ms  
-3  pen-mbone-1.sprintlink.net (207.41.200.99) DVMRP  thresh^ 64  109910 ms  
-4  schnell.ebone.net (198.67.134.250) DVMRP  thresh^ 32  -9597 ms  
-5  * * * mae-bone.psi.net (192.41.177.247)

I know MBONE.CIT.CORNELL.EDU is mrouted.  I don't know the rest.  What's
the mrouted boundaries fix?  I only made note of the accept-filters fix.

-Mitch

---

From: John Hawkinson <[email-masked]>
Date: Wed, 27 Nov 1996 15:29:03 -0500 (EST)

> I've been seeing this for quite some time now.

That particular source (192.41.177.85), or something else?

> >You should mtrace to 192.41.177.85 on 239.133.130.34 (most likely
> >the group in question, though the syslog message does not tell you
> >that) and request the administrators of the router upstream of you
> >apply boundaries (if they are mrouted) or accept-filters (if they
> >are PIM routers) to avoid this problem.
> 

Note that paths change, and sometimes it's only paths that are
flapping or available for short periods of time that leak these bogons
through.  So you really ought to look at the statistics output of
mtrace for the group (that is, the second screen in PARC's
implementation, or "mstat" output in cisco's).

> -2  MBONE.CIT.CORNELL.EDU (192.35.82.97) DVMRP  thresh^ 4  202796 ms  

If you're bored this holiday weekend, you might consider turning on
NTP on both of these guys...

> the mrouted boundaries fix?  I only made note of the accept-filters fix.

All the rest (except gangway, obviously) are mrouted.

The "boundary" fix was suggested by Bill Fenner in
<[email-masked]> on Wed, 28 Aug 1996
17:13:43 PDT:

}   By the way, people running transit mrouted's can help slow the spread
} of this "virus" by adding "name mcastrp 239.133.130.34/32" to the top
} of their mrouted.conf, and then "boundary mcastrp" to their tunnel and
} phyint configurations.
} 
} e.g.
} 
} name mcastrp 239.133.130.34/32
} phyint le0 boundary mcastrp
} phyint le1 boundary mcastrp
} phyint le2 boundary mcastrp
} tunnel 13.2.116.239 204.162.228.1 metric 1 threshold 32 boundary mcastrp
} 
} This will cause mrouted's to not forward the register packets destined for
} the bogus group.  Of course, this is only necessary if you have Cisco PIM
} routers on both sides of your mrouter.

The assumption here is that there is no valid traffic headed to
239.133.130.34, and that's pretty good assumption (particularly, now).

--jhawk

---

From: Mitch Collinsworth <[email-masked]>
Date: Wed, 27 Nov 1996 17:17:24 -0500

>That particular source (192.41.177.85), or something else?

Hadn't actually looked closely until now, but it looks like different
sources at different times going back to at least early September.
This one actually stopped about 1930 UTC today.

>NTP on both of these guys...

I wish.  Building a house...
NTP, you mean time?  It's on on gangway.  Don't know about mbone.cit.  Not
my system.

>239.133.130.34, and that's pretty good assumption (particularly, now).

OK, thanks, John.

Joy, could you apply the above to mbone.cit?  My syslog would love you!

-Mitch

---

From: John Hawkinson <[email-masked]>
Date: Wed, 27 Nov 1996 17:32:03 -0500 (EST)

> This one actually stopped about 1930 UTC today.

OK, yes. In addition to getting nothing else done in my life, I'm
usually reasonably successful at sending out nastygrams to the
provider of those guilty of malfeasance, and this usually results in
providers filtering (err, applying boundaries), and hopefully
the sites in question fixing themselves.

Because topologies are different, in general folks should be
encouraged to be Good Netizens and do the same. (This is somewhat
easier to do with IOS because mrouted only syslgos this at -d3).  It
is not necessarily a valid assumption that someone else has noticed
and reported the problem.

> NTP, you mean time?  It's on on gangway.  Don't know about mbone.cit.  Not

Yes, time. It is rather unlikely that your probe took twenty secnods
to go from gangway to mbone.cit :-)

> >> -4  schnell.ebone.net (198.67.134.250) DVMRP  thresh^ 32  -9597 ms  

Of course, mbone.cit is hardly the only guilty party :-)

--jhawk