Subject: [[email-masked]: Today's MBone disaster]

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Aug 1996 15:14:48 -0700

I have a fix for this problem. You can get the image from

        ftp://ftpeng.cisco.com/ftp/dino/bogus-rp/c4500-i-mz

    If you don't use this image, you must use the workaround Jhawk describes
    below so you are not infected. This need go into your multicast routers 
    only.

    If you are doing sparse-mode PIM already and have "ip pim accept-rp"
    commands configured for RPs at your site, you probably were not infected
    and need not do anything.

    If you want other image types, please let me know what you need. However,
    before asking, please check the bogus-rp directory first to see if I
    already have made the one you need available.

    This fix will be integrated into the next 11.0, 11.1, and 11.2 releases.
    When I know the exact release numbers, I will tell you.

Dino

------------------------------------------------------------------------

Date: Tue, 27 Aug 1996 17:33:33 -0400 (EDT)
To: [email-masked], [email-masked]
Subject: Today's MBone disaster
From: John Hawkinson <[email-masked]>

The MBone is currently experiencing a loop of PIM Register packets and
Register-Stop messages.

This is caused by bogus PIM join packets that cause routers to believe
that a multicast RP is valid (239.133.130.34).

This problem is resulting in a large number of data packets sent to
the multicast address 239.133.130.34, and a lot of duplicate packets
on various groups and sessions.

Unfortunately, the nature of this problem is such that any affected
PIM routers will re-infect each other.

The solutions are as follows, and we need everyone with a PIM-capable
router to implement them:

1. Don't accept any RP information for this bogus group.

In cisco-speak this is:

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

You can of course use any access list other than 1.

2. Clear multicast forwarding state for all groups:

clear ip mr *

Cisco is actively working on fixing a number of bugs that have allowed
this condition to occur.

In the meantime, we will also need to track down the source of the
bogus RP information. After all PIM-capable routers have been configured
with the above, then it will be possible to determine the source by checking
log messages from routers. Eg:

%PIM-1-INVALID_RP_JOIN: Received (*, 224.2.153.62) Join from
131.119.0.196 for invalid RP 239.133.130.34

These messages will only be meaningful when all routers are "innoculated",
however.

Thanks very much to Bill Fenner, Dino Farinacci, Liming Wei, and kim
claffy, for working hard to track this problem down, and also to
Tamara Munzner for lending us her office to attack this.

--jhawk
  John Hawkinson

---

From: Tech Support <[email-masked]>
Date: Thu, 29 Aug 1996 08:54:05 +0100 (BST)

Before I impliment this, can anyone one tell me what set its is ie IP 
only or other and what revision 11.1 ? 

On Wed, 28 Aug 1996, Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 29 Aug 1996 09:41:32 -0700

>> only or other and what revision 11.1 ? 

    The -i images are IP-only which means the image is capable of IP 
    unicast and multicast forwarding and all the associated IP routing
    protocols. There are no other protocols in this image.

    I appended the release number to each file in the bogus-rp directory
    so you know what release your going to load. I am building 11.1 mostly
    but have made exception for AGS+ with low memory/flash requirements.
    A compressed 11.0 is 1.6 megabytes which can make it into typical 4 meg
    flashes and can run in 4 meg RAM.

Dino