At 14:12 13/11/01 -0500, Robert Beverly wrote: Due to Ramen I was forced to rate limit msdp as follows: interface Tunnel2 ip pim bsr-border ip pim sparse-mode rate-limit input access-group 180 32000 8000 8000 conform-action transmit exceed-action drop ip sap listen ! access-list 180 permit tcp any any eq 639 access-list 180 permit udp any any eq 639 and: ip msdp sa-filter in n.n.n.n list 111 access-list 111 deny ip any host 224.0.2.2 access-list 111 deny ip any host 224.0.1.3 access-list 111 deny ip any host 224.0.1.24 access-list 111 deny ip any host 224.0.1.22 access-list 111 deny ip any host 224.0.1.2 access-list 111 deny ip any host 224.0.1.35 access-list 111 deny ip any host 224.0.1.60 access-list 111 deny ip any host 224.0.1.39 access-list 111 deny ip any host 224.0.1.40 access-list 111 deny ip any 239.0.0.0 0.255.255.255 access-list 111 deny ip 10.0.0.0 0.255.255.255 any access-list 111 deny ip 127.0.0.0 0.255.255.255 any access-list 111 deny ip 172.16.0.0 0.15.255.255 any access-list 111 deny ip 192.168.0.0 0.0.255.255 any access-list 111 permit ip any any -Hank
Rate limiting multicast packets would not have prevented state from being instantiated, nor would it have prevented the MSDP SA flooding that ensued from this worm. Some vendors provide facilities to rate limit MSDP SA messages (actually rate limiting traffic to the MSDP port 639).
On Tue, Nov 13, 2001 at 06:37:41PM +0100, Niels Bakker wrote:
I'm sure that the operators of the networks that were massively hindered when some worms started scanning random hosts in 224/4 (that's what you get if you don't understand IP and just use a random number generator to get something resembling an IP address) were rate-limiting packets to multicast addresses pretty quickly. All those new sessions (one UDP packet to a multicast address) created state in lots of routers throughout their networks. Dropping TCP to 224/4 of course also helps in this particular case.