Subject: Re: Today's MBone disaster

From: "Jeffrey S. Curtis" <[email-masked]>
Date: Wed, 28 Aug 1996 01:35:49 -0500

}You can check if your router is affected by the bug by checking the
}output of "show ip mroute" and see if you have the bogus RP address
}associated with any groups.  "show ip pim rp" might also tell you.

The former on my PIM/DVMRP border mrouter shows no signs of the
multicast RP address.  The latter shows quite a few groups with the
bogus address as one of the RPs, and, in fact, the number of such
groups seems to have increased quite a bit relative to the first time
I checked a few hours ago.  This router is at 10.3(11), only because
it's a 7513 and so I can't run 10.2 on it.  I very nearly "upgraded"
to 10.3(13) yesterday and am quite glad that I didn't.

My PIM/DVMRP border router runs dense-mode PIM toward my interior
networks, and at one point, there's a dense-mode/sparse-mode PIM border
router which heads off toward the rest of my networks.  That router is
at 10.2(11) and has been running about 10-20% higher CPU load than
usual since noon Central time today, which coincides with when this
problem began.  That could just be a coincidence.  This router also
sees the bogus RP entries in the sh ip pim rp display.

To get back to my original question - in the absence of the per-RP
filtering offered by the newer IOS releases, is there any action which
the rest of us can/should be taking? Will regular IP filtering against
the bogus address be sufficient to drop the traffic, or does cisco's
regular IP filtering not grok multicast addresses?

Jeff
-- 
Jeffrey S. Curtis                      | Internetwork Manager
Argonne National Laboratory            | Email: [email-masked]
9700 South Cass Avenue, ECT-221        | Voice: 630/252-1789
Argonne, IL 60439                      | Fax:   630/252-9689

---

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

>> regular IP filtering not grok multicast addresses?

    Yes, you may use input access-lists. Do the following:

	access-list 1 deny 239.133.130.34 0.0.0.0
	access-list 1 permit 0.0.0.0 255.255.255.255

    and for each multicast enabled interface do:

	ip access-group 1 in

    IP will discard packets addressed to 239.133.130.34 and prevent PIM from
    processing the the Registers addressed to a bogus RP address. This 
    workaround only helps for this exact problem. If anyone else makes the 
    same misconfiguration, this workaround may not work.

Dino