Subject: Re: Today's MBone disaster

From: Sean Doran <[email-masked]>
Date: Wed, 28 Aug 1996 02:16:47 +0100

Well, killing off 10.x IOS is a good goal.  This is certainly a novel
forum in which to push for that, though. :-)

	Sean.
- --
| (I suppose I could rant here
| about how annoyed I am with the "you'd better run 11.0(9.3) or more
| recent or we're going to kick you off the Mbone" movement, for these
| exact sorts of reasons, but that's a different argument for a different
| day.)

---

From: "Jeffrey S. Curtis" <[email-masked]>
Date: Wed, 28 Aug 1996 19:03:07 -0500

Dino writes:
}I wrote:
}>> Shouldn't this be:
}>> 
}>> 	access-list 100 deny 0.0.0.0 255.255.255.255 239.133.130.34 0.0.0.0
}>> 	access-list 100 perm 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
}>> 	ip access-group 100 in
}>> 
}>> To block the register packets destined for the bogus RP address?

}    Yes, thank you Jeff. My suggestion filters on source address only. You
}    want to filter on destination address so you need an extended access-list.
}    Your syntax is correct.

Actually, it isn't - I left out the "ip" keyword after the perm/deny.

In any case, I've applied the appropriate access-list to every IP
multicast-speaking interface of my PIM/DVMRP border router, including
the DVMRP tunnel interface toward the Mbone, but the sh ip pim rp
output implies that the bogus packets are still being processed (because
the "expires" timer stays at or near two minutes for the bogus RP entries).
The access-list is certainly racking up the packets, though:

Extended IP access list 100
    deny   ip any host 239.133.130.34 (38592 matches)
    permit ip any any (190465 matches)

Any idea why it's not working? This box is at 10.3(11).  Perhaps I'll
give it a shot on a purely PIM-speaking router next and see if the
results are any different.

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: Bill Fenner <[email-masked]>
Date: Wed, 28 Aug 1996 17:13:43 PDT

Jeff,

  Did you "clear ip mr" on the router after "inoculating" it?  The state
will stick around unless you clear it, and the IP filtering only keeps
you from being "re-infected" after clearing state.

  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.

  Bill

---

From: "Jeffrey S. Curtis" <[email-masked]>
Date: Wed, 28 Aug 1996 19:24:42 -0500

Bill Fenner writes:
}  Did you "clear ip mr" on the router after "inoculating" it?  The state
}will stick around unless you clear it, and the IP filtering only keeps
}you from being "re-infected" after clearing state.  [...]

Good call, Bill - I did indeed forget to clear the routes.  I guess
I expected them to time out after the access-lists were applied.  The
bogus RPs are now gone.  I guess now it's a matter of going hop by hop
to each of my interior PIM-speakers and making them drink the cleansing
Kool-Aid...

Jeff

---

From: Bill Fenner <[email-masked]>
Date: Wed, 28 Aug 1996 17:13:43 PDT

Jeff,

e.g.

  Bill

---

From: "Jeffrey S. Curtis" <[email-masked]>
Date: Wed, 28 Aug 1996 19:24:42 -0500

Bill Fenner writes:

Jeff

---

From: Bill Fenner <[email-masked]>
Date: Wed, 28 Aug 1996 17:13:43 PDT

Jeff,

e.g.

  Bill