%PIM-1-INVALID_RP_REG:
Jeremy George
Recently this message has begun every minute:
Nov 24 19:54:28 bifrost.net.yale.edu 28898: %PIM-1-INVALID_RP_REG: Received Regi
ster from 192.41.177.85 for 224.2.0.1, not willing to be RP
Following the formula from the last episode I added these lines:
ip pim accept-rp 192.41.177.85 99
ip pim accept-rp 239.133.130.34 99
access-list 99 deny any
and issued clear ip mr *
The messages continue. Can anyone help me with a command series that will
get me out of the poison?
- Jeremy
John Hawkinson
> 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
Mobasshar Ahmed
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)
---
Mobasshar Ahmed http://www.on-net.co.uk
Technical Manager mah...@on-net.co.uk
ON-NET Yes we sell to ISPs
Tel: ++44-181-256-9990 FAX: ++44-181-288-0222
Mitch Collinsworth
>> 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
I've been seeing this for quite some time now.
>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.
>
>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.
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
John Hawkinson
> >> 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
>
> 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.
>
> It's a pretty short path from here:
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).
> Mtrace from 192.41.177.85 to 128.84.247.246 via group 239.133.130.34
> 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
If you're bored this holiday weekend, you might consider turning on
NTP on both of these guys...
> -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.
All the rest (except gangway, obviously) are mrouted.
The "boundary" fix was suggested by Bill Fenner in
<96Aug28.1713...@crevenia.parc.xerox.com> 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
Mitch Collinsworth
>> >> Nov 24 19:54:28 bifrost.net.yale.edu 28898: %PIM-1-INVALID_RP_REG: Receiv
>ed
>> >> 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.
>
>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.
>> >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.
>>
>> It's a pretty short path from here:
>
>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).
>
>> Mtrace from 192.41.177.85 to 128.84.247.246 via group 239.133.130.34
>> 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
>
>If you're bored this holiday weekend, you might consider turning on
>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.
OK, thanks, John.
Joy, could you apply the above to mbone.cit? My syslog would love you!
-Mitch
John Hawkinson
> 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.
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.
> >> -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
> >
> NTP, you mean time? It's on on gangway. Don't know about mbone.cit. Not
> my system.
Yes, time. It is rather unlikely that your probe took twenty secnods
to go from gangway to mbone.cit :-)
> >> -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
Of course, mbone.cit is hardly the only guilty party :-)
--jhawk