All things related to multicast

[Matthew Davy <>]

We're not rate-limiting the storms (since our Engine 2 GSR cards can't do 
this).  But we disabled SA caching which has protected us from the storms.   
This is obviously not our preferred option, but it was our only option until 
we can get the new IOS with SA limits installed everywhere.

- Matt



On Wed, Jan 24, 2001 at 06:56:00AM -0500, Marshall Eubanks wrote:
> Hank;
> 
>    Al told me that he was using 24 kbps rate limit with good results.
> You are using 8 & 4 kbps ?
> Is anyone else rate limiting the MSDP storms ?
> 
>                                  Marshall
> 
> Hank Nussbacher wrote:
> > 
> > At 08:32 21/01/01 -0500, Marshall Eubanks wrote:
> <just to make it clear - this is Hank's text, not mine...>
> > 
> > Last night was better:
> > 
> > mcast#sho int rate
> > Tunnel1 Mbone tunnel to Dante
> >    Input
> >      matches: access-group 180
> >        params:  8000 bps, 4000 limit, 4000 extended limit
> >        conformed 162818 packets, 16453070 bytes; action: transmit
> >        exceeded 159 packets, 209800 bytes; action: drop
> >        last packet: 280ms ago, current burst: 0 bytes
> >        last cleared 21:00:15 ago, conformed 1000 bps, exceeded 0 bps
> > Tunnel2 Mbone tunnel to Startap
> >    Input
> >      matches: access-group 180
> >        params:  8000 bps, 4000 limit, 4000 extended limit
> >        conformed 166978 packets, 20171087 bytes; action: transmit
> >        exceeded 1239 packets, 703743 bytes; action: drop
> >        last packet: 216ms ago, current burst: 0 bytes
> >        last cleared 21:00:11 ago, conformed 2000 bps, exceeded 0 bps
> > mcast#sho access-l 180
> > Extended IP access list 180
> >      permit tcp any any eq 639 (332635 matches)
> >      permit udp any any eq 639
> >      deny ip any any (3055159 matches)
> > 
> > What did happen was the following:
> > Jan 23 16:16:03: %MSDP-5-PEER_UPDOWN: Session to peer 206.220.240.101 
> > going
> > down
> > Jan 23 16:16:33: %MSDP-5-PEER_UPDOWN: Session to peer 206.220.240.101 
> > going up
> > Jan 23 16:18:00: %MSDP-5-PEER_UPDOWN: Session to peer 206.220.240.101 
> > going
> > down
> > 
> > mcast#sho ip msdp sum
> > MSDP Peer Status Summary
> > Peer Address     AS    State    Uptime/  Reset Peer Name
> >                                  Downtime Count
> > 212.1.196.37     8933  Up       3d11h    146   uk-iucc.mcast.ten-155.net
> > 206.220.240.101  10764 Up       16:32:16 340   ?
> > 
> > Interesting that only the MSDP peer to Abilene goes up and down and not 
> > the
> > one to Quantum.  More MSDP packets dropped from Abilene.  Larger sized 
> > MSDP
> > packets from Abilene (120 vs 101 bytes).
> > 
> > I will stay with the 8000/4000/4000 rate limiting for now.  It seems to be
> > controlling the MSDP storms.
> > 
> > -Hank
> > 
> > >Any comments on this ? 5000 SA messages per minute (the peak "normal" 
> > >usage)
> > >should be ~ 100 per second ~ 6 kilobytes per second ~ 48 kbits per
> > >second, so
> > >this might work.
> > >
> > >Hank - let us know if this succeeds in keeping the storms limited on
> > >your end.
> > >
> > >I believe that MSDP is only TCP, BTW.
> > >
> > >Marshall
> > >
> > >-------- Original Message --------
> > >Subject: Re: Second day of rolling blackouts starts
> > >Date: Sun, 21 Jan 2001 15:16:37 +0200
> > >From: Hank Nussbacher 
> > ><>
> > >To: 
> > >,
> > > 
> > >
> > >CC: 
> > >
> > >References: 
> > ><>
> > >
> > >At 09:43 19/01/01 -0500, Marshall Eubanks wrote:
> > >
> > > >Two people have asked me off list about the RAMEN worm,
> > > >which affects Linux Redhat distro's. Here is brief description of the
> > > >worm, and a link to more,
> > > >from Lucy Lynch at Internet2 / UOregon.
> > > >
> > > >The multicast implications :
> > > >
> > > >This worm scans a portion of the multicast address space. These scans
> > > >(packets)
> > > >are viewed as new multicast sources by a PIM multicast enabled router,
> > > >which encapsulates
> > > >them and sends them to its RP. The RP creates MSDP Session 
> > > >Announcements
> > > >FOR EACH SCAN
> > > >and floods them to every RP neighbor it has in "nearby" AS's, and those
> > > >repeat the process.
> > > >The result is a MSDP packet storm. We have gotten 15,000 SA's a minute.
> > > >Dealing with these
> > > >can melt down routers. (We had to reboot a Cisco 7204, for example,
> > > >which apparently either filled
> > > >up or fragmented its memory beyond usability.)
> > > >
> > > >I think it is fair to say that the question of rate limiting and other
> > > >DOS filtering in
> > > >PIM/SSM/MSDP multicast is getting serious attention now.
> > >
> > >I have installed on my multicast tunnels (one to StarTap and the other
> > >to
> > >Dante/Quantum):
> > >
> > >rate-limit input access-group 180 128000 30000 30000 conform-action
> > >transmit exceed-action drop
> > >!
> > >access-list 180 permit tcp any any eq 639
> > >access-list 180 permit udp any any eq 639
> > >access-list 180 deny   ip any any
> > >
> > >IANA has MSDP listed as port 639 - tcp+udp.  It appears MSDP is only
> > >really
> > >TCP:
> > >mcast#sho access-l 180
> > >Extended IP access list 180
> > >      permit tcp any any eq 639 (1555 matches)
> > >      permit udp any any eq 639
> > >      deny ip any any (37888 matches)
> > >
> > >and
> > >
> > >mcast#sho in rate
> > >Tunnel1 Mbone tunnel to Dante
> > >    Input
> > >      matches: access-group 180
> > >        params:  128000 bps, 30000 limit, 30000 extended limit
> > >        conformed 755 packets, 60044 bytes; action: transmit
> > >        exceeded 0 packets, 0 bytes; action: drop
> > >        last packet: 388ms ago, current burst: 0 bytes
> > >        last cleared 00:07:26 ago, conformed 1000 bps, exceeded 0 bps
> > >Tunnel2 Mbone tunnel to Startap
> > >    Input
> > >      matches: access-group 180
> > >        params:  128000 bps, 30000 limit, 30000 extended limit
> > >        conformed 909 packets, 148937 bytes; action: transmit
> > >        exceeded 0 packets, 0 bytes; action: drop
> > >        last packet: 1048ms ago, current burst: 0 bytes
> > >        last cleared 00:08:48 ago, conformed 2000 bps, exceeded 0 bps
> > >
> > >I'll only know tomorrow if I stop getting the constant:
> > >Jan 21 14:00:03: %SYS-3-CPUHOG: Task ran for 6300 msec (123/75), process
> > >=
> > >MSDP Process, PC = 60790390. -Traceback= 60790398 604146B4 604146A0
> > >error messages.  I don't know whether 128kb/sec of MSDP is too much or
> > >too
> > >little.
> > >
> > >-Hank
> 
> -- 
> 
> 
>                                    Regards
>                                    Marshall Eubanks
> 
>    This e-mail may contain confidential and proprietary information of 
>    Multicast Technologies, Inc, subject to Non-Disclosure Agreements
> 
>    Multicast Technologies, Inc.
>    10301 Democracy Lane, Suite 201
>    Fairfax, Virginia 22030
>    Phone : 703-293-9624          Fax     : 703-293-9609     
>    e-mail : 
> 
>      http://www.on-the-i.com
> 

-- 
--------------------
Matthew Davy                  

                     
812-855-7728
Network Engineer
Indiana University 
Abilene NOC
--------------------