All things related to multicast

[Hank Nussbacher <>]

On Fri, 13 Jun 2008, Zenon Mousmoulas wrote:

> On 12 Ιουν 2008, at 10:28 ΜΜ, Hank Nussbacher wrote:
> > On Thu, 12 Jun 2008, 
> >
> >  wrote:
> >
> > > Hi,
> > > > On Thu, 12 Jun 2008, John Watters wrote:
> > > >
> > > > Can I add that to my posting on cisco-nsp about this?
> > >
> > > I can verify that the following command , on an interface,
> > > whilst can be typed and queried, will not work:
> > >
> > > router(config-if)#ip multicast rate-limit in group-list SAP-mcast-group 
> > > 1000
> > > "ip multicast rate-limit" command is not supported
> > >
> > > this is a 6500 with pair of sup720-3B's and Version 12.2(18)SXF12 IOS
> > >
> > > alan
> >
> > http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/release/notes/OL_4164.html
> > where it says:
> > "The ip multicast rate-limit command is not supported on LAN ports. 
> > (CSCds22281)"
> >
> > So perhaps it depends what type of interface it is applied to?  I know it 
> > doesn't work on POS and this bugid says it won't work on LAN interfaces - 
> > so where does that leave us? :-)
>
> I found this:
>
> ftp://ftpeng.cisco.com/ipmulticast/config-notes/multicast-rate-limit.txt
>
> Excerpts of particular interest:
>
> Status
> The "ip multicast rate-limit" command was developed to provide some form of 
> protection against excess traffic for the initial set of ip multicast 
> application, the mbone tools. For current deployments, it is recommended to 
> use the "rate-limit" command instead of "ip multicast rate-limit" for rate 
> limiting on a per-interface basis and to use ip multicast rate-limiting only 
> for per-mroute state rate limiting. Please see the example configuration 
> section below and refer to the following URLs documenting the "rate-limit" 
> command or the "police" command, which replaces "rate-limit" in newer IOS 
> releases:
> [...]
> If you are using "ip multicast rate-limit" for a larger scale deployment, we 
> would like to know about it, because we are evaluating how to continue 
> support for this feature in upcoming IOS releases.
> Platform support
> The simple algorithm allows for "ip multicast rate-limit" to be very fast in 
> Cisco IOS systems that have a CPU switched software forwarding path.
> On these platforms the overhead for "ip multicast rate-limit" is lower than 
> for CAR. This includes all platforms that only have ip multicast 
> fast-switching (MFS) and/or ip multicast distributed fast-switching (MDFS) 
> path, eg: all Cisco IOS platforms up to and including Cisco-7200 and 
> Cisco-7500.
> On the Cisco-12000, "ip multicast rate-limit input" is also supported 
> whenever IP Multicast traffic is CPU switched on the linecards, eg: on Eng0 
> and Eng1, and on Eng2 (currently). It is not supported for Eng4 linecards or 
> for egress ("ip multicast rate-limit output").
> On other platforms with hardware accelerated hardware forwarding paths, "ip 
> multicast rate-limit" may not be supported in the hardware forwarding path 
> but may revert forwarding to CPU fast-switching and should then be avoided 
> (eg: Catalyst-6x00/Cisco-7600).
> On hardware accelerated platforms that do not support "ip multicast 
> rate-limit" in their hardware accelerated multicast forwarding paths, you 
> should instead use CAR (which is more likely available).

Nice find!   Thanks!  Clears things up.

Perhaps at the next Vienna 6500/7600 workshop this matter should be raised 
and Cisco should make a recommendation as to what IOS snippet they 
recommend we use so our routers don't go belly-up.

> I'm sorry to break this to you, but it looks like this is an obsolete feature 
> after all. Perhaps I should have guessed so, since it's been there for a very 
> long time (docs mention IOS 11.0). However it was honestly a works-for-me 
> based suggestion, and indeed it still does work marvelously on these systems 
> I happened to try it on.
> On bigger platforms, such as the 7600, the GSR and the Cat 6500, you have to 
> go with a more sophisticated (and more complicated) CAR or MQC based 
> solution. It does make sense, because this hack is rather limited in 
> comparison and it does not fit the modern policing frameworks where all 
> development has happened in recent years.
>
> So, Hans, apologies for the false alarm... It's not so easy to deal with this 
> issue after all.
>
> Furthermore, as a contribution to the discussion reiterated by Chriss Robb, 
> let me note that the initial reaction of GRNET NOC staff to this incident has 
> been against discriminatory or special handling of SAP traffic in general, 
> i.e. protecting listeners (as well as the announcements) by rate limiting SAP 
> (aggregate traffic or per mroute). This should rather be left up to the local 
> administrators to consider and implement, probably at the campus border. 
> Instead of that, they would favor a SAP anomaly detector mechanism that would 
> monitor such incidents and take measures ranging from e-mail notifications to 
> throttling or isolation of the offending mroute/host through QPPB-based 
> signaling.

My NOC disabled multicast totally when this happened since they couldn't 
pinpoint what was going wrong or from where.

Regards,
Hank


> Best regards,
> Z.