All things related to multicast

[Zenon Mousmoulas <>]

FYI

Begin forwarded message:

> From: Hank Nussbacher 
> <>
> Date: 19 Ιουνίου 2008 12:36:40 ΜΜ GMT+03:00
> To: Zenon Mousmoulas 
> <>
> Subject: Re: Fwd: [c-nsp] ip multicast rate-limit
>
> At 12:31 PM 19-06-08 +0300, Zenon Mousmoulas wrote:
>
> Perhaps raise the issue at the next Cisco Vienna workshop.
>
> -Hank
>
> > Let's summarize:
> > - On software based routers (as per that Cisco note) you can use ip
> > multicast rate-limit.
> > - On 6500/7600 you can use microflow policers, as Arie Vayner showed.
> > - On other platforms (namely most of 12000 series) you can not do  
> > this
> > sort of thing, but there may be other ways to deal with the problem
> > (aggregate policer, detection and repression of offending sources  
> > i.e.
> > anomaly detector).
> >
> > On Juniper systems there is the approach I mentioned on the wg-  
> > multicast list, but someone should still validate it in practice (at
> > the moment I can't) and we also don't know what platform restrictions
> > there may be.
> >
> > I guess this wraps it up.
> >
> > Z.
> >
> > Begin forwarded message:
> >
> > > From: "Arie Vayner (avayner)" 
> > > <>
> > > Date: 19 Éïõíßïõ 2008 12:08:27 ÌÌ GMT+03:00
> > > To: "Zenon Mousmoulas" 
> > > <>
> > > Cc: "Hank Nussbacher" <>, < 
> > >  >
> > > Subject: RE: [c-nsp] ip multicast rate-limit
> > >
> > > Zenon,
> > >
> > > I am not aware of a way to accomplish this on GSR or other
> > > platforms... The only thing you can do is the aggregate policer for
> > > all the flows...
> > > I guess if you police it to a low rate (100Kbps) you should be able
> > > to effectively block the "attacks"
> > >
> > >
> > > Arie
> > >
> > > -----Original Message-----
> > > From: Zenon Mousmoulas 
> > > [mailto:]
> > > Sent: Thursday, June 19, 2008 11:52 AM
> > > To: Arie Vayner (avayner)
> > > Cc: Hank Nussbacher; 
> > >
> > > Subject: Re: [c-nsp] ip multicast rate-limit
> > >
> > > Hi,
> > >
> > > Alright. Any idea if this will work on GSRs, and on what SPAs and/or
> > > line-cards? Or any other workaround to accomplish the same thing,
> > > for platforms other than 6500/7600?
> > >
> > > Thanks for the info.
> > >
> > > Z.
> > >
> > > On 19 Éïõí 2008, at 10:54 ÐÌ, Arie Vayner (avayner) wrote:
> > >
> > > > Zenon,
> > > >
> > > > In this case you can actually use microflow policers (if you are on
> > > > 6500/7600).
> > > > The link is here:
> > > > http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/  
> > > > 12.2SX/c
> > > > onfiguration/guide/qos.html#wp1571584
> > > >
> > > > Using the following police statement (instead the one I used  
> > > > before)
> > > > would police each source IP to 50Kbps (not Mbps):
> > > >
> > > >   police flow mask src-only 50000 1500 conform-action transmit
> > > > exceed-action drop
> > > >
> > > > You can also police on L4 flows by using:
> > > >   police flow mask full-flow 50000 1500 conform-action transmit
> > > > exceed-action drop
> > > >
> > > > Arie
> > > >
> > > > -----Original Message-----
> > > > From: Zenon Mousmoulas 
> > > > [mailto:]
> > > > Sent: Wednesday, June 18, 2008 20:20 PM
> > > > To: Arie Vayner (avayner)
> > > > Cc: Hank Nussbacher; 
> > > >
> > > > Subject: Re: [c-nsp] ip multicast rate-limit
> > > >
> > > > Hi,
> > > >
> > > > No problem with any delay, I'm glad you answered.
> > > >
> > > > The configuration you suggest is fine but the question is (and has
> > > > been all along) whether this will police individual traffic flows  
> > > > or
> > > > the aggregate traffic matched by the acl? I don't know for sure,
> > > > but I
> > > > believe it is more likely to be the second case.
> > > > If so, I think this could not be a sufficient solution because
> > > > someone
> > > > could still effectively "drown" SAP by sending a lot of traffic to
> > > > the
> > > > group, which would "compete" with the rest of the legitimate SAP
> > > > traffic for the same 100 Mbps. Furthermore, due to the nature of  
> > > > SAP,
> > > > letting such a high speed flow pass through the router and reach  
> > > > the
> > > > end systems (SAP listeners) would still have a detrimental effect  
> > > > on
> > > > them, since they only expect to see and process low bitrate  
> > > > traffic.
> > > > For these reasons we probably need a solution that will rate-limit/
> > > > police each flow individually. The interface configuration command
> > > > "ip
> > > > multicast rate-limit" used to do this, but we need something that
> > > > will
> > > > work on platforms where this is not supported, and also perhaps a
> > > > more
> > > > generic approach. I don't know what that solution could be  
> > > > though...
> > > > I'm afraid that something could be micropolicing, which I think is
> > > > quite "expensive" and only supported on a small number of systems/
> > > > configurations.
> > > >
> > > > I hope you can look into this and verify or falsify these
> > > > assumptions.
> > > > Thanks again for your help.
> > > >
> > > > Best regards,
> > > > Z.
> > > >
> > > > On 18 Éïõí 2008, at 6:54 ÌÌ, Arie Vayner (avayner) wrote:
> > > >
> > > > > Zenon,
> > > > >
> > > > > Sorry for the delay, as I was a bit overloaded.
> > > > >
> > > > > Looking at the following link, I see that SDP/SAP is assigned the
> > > > > range of 224.2.0.0/16:
> > > > > http://www.cisco.com/en/US/tech/tk828/
> > > > > technologies_white_paper09186a00
> > > > > 802d4643.shtml#wp1005088
> > > > >
> > > > > So you can use the configuration example below to rate limit it to
> > > > > 100Kbps:
> > > > >
> > > > > class-map match-all SDP-SAP-MCAST
> > > > > match access-group name SDP-SAP-MCAST !
> > > > > policy-map GENERIC-INGRESS
> > > > > class SDP-SAP-MCAST
> > > > > police 100000
> > > > > !
> > > > > ! Should be applied on any untrusted interface interface
> > > > > GigaEthernet0/1 service-policy input GENERIC-INGRESS !
> > > > > ip access-list extended SDP-SAP-MCAST permit ip any 224.2.0.0
> > > > > 0.0.255.255 !
> > > > >
> > > > > Actually, in your case I would recommend building a more general
> > > > > policy, filtering any unwanted multicast traffic. You could do  
> > > > > it by
> > > > > building a longer ACL with groups which you should not be there.
> > > > > The link above could be a good reference.
> > > > >
> > > > > Thanks
> > > > > Arie
> > > > >
> > > > > -----Original Message-----
> > > > > From: Zenon Mousmoulas 
> > > > > [mailto:]
> > > > > Sent: Sunday, June 15, 2008 23:19 PM
> > > > > To: Arie Vayner (avayner)
> > > > > Cc: Hank Nussbacher; 
> > > > >
> > > > > Subject: Re: [c-nsp] ip multicast rate-limit
> > > > >
> > > > > Last week there was an incident where high-speed video was traffic
> > > > > sent to the well known SAP group, which was noticed across
> > > > > Internet2,
> > > > > GEANT and other academic (multicast-enabled) networks.
> > > > > Many folks expressed interest to rate-limit flows to this group,
> > > > > as a
> > > > > means to protect downstream systems (apart from the standard
> > > > > advisory
> > > > > to disable "ip sap listen" etc. on routers). It so happened that I
> > > > > suggested this command (ip multicast rate-limit), because it
> > > > > (still) works for me (recently tested on a 7300 running 12.4T),  
> > > > > but
> > > > > it turns out it has become obsolete, so we've been looking for
> > > > > functionally equivalent alternatives...
> > > > >
> > > > > Z.
> > > > >
> > > > > On 15 Éïõí 2008, at 10:54 ÌÌ, Arie Vayner (avayner) wrote:
> > > > >
> > > > > > Zenon,
> > > > > >
> > > > > > Can you please explain specifically what you want to rate  
> > > > > > limit...
> > > > > > Maybe a show ip mroute could be helpful...
> > > > > >
> > > > > > Arie
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Zenon Mousmoulas 
> > > > > > [mailto:]
> > > > > > Sent: Sunday, June 15, 2008 22:48 PM
> > > > > > To: Arie Vayner (avayner)
> > > > > > Cc: Hank Nussbacher; 
> > > > > >
> > > > > > Subject: Re: [c-nsp] ip multicast rate-limit
> > > > > >
> > > > > > Hi Arie,
> > > > > >
> > > > > > I would like to ask you something:
> > > > > >
> > > > > > The ip multicast rate-limit command, when used with a group-list
> > > > > > and/ or source-list argument, does policing on a per-mroute  
> > > > > > (S,G or
> > > > > > *,G) basis. This is according to relevant IOS documentation and
> > > > > > this
> > > > > > document:
> > > > > >
> > > > > > ftp://ftpeng.cisco.com/ipmulticast/config-notes/multicast-rate-
> > > > > > limit.t
> > > > > > xt
> > > > > >
> > > > > > The above (perhaps outdated) document suggests (in section
> > > > > > "Status")
> > > > > > to use CAR for per-interface (aggregate) traffic rate-limiting,  
> > > > > > but
> > > > > > to keep using this command for per-mroute applications. Has this
> > > > > > changed since 2001?
> > > > > >
> > > > > > Could you suggest how to build a policy that would apply at per-
> > > > > > mroute (or higher, i.e. per-flow) granularity, instead of being
> > > > > > applied on the aggregate matched traffic?
> > > > > >
> > > > > > Would this sort of granular policing fall within the scope of the
> > > > > > microflow policing feature, which is available on some 7600 and
> > > > > > Catalyst 6500 hardware?
> > > > > >
> > > > > > Best regards,
> > > > > > Zenon Mousmoulas
> > > > > > GRNET
> > > > > >
> > > > > > On 14 Éïõí 2008, at 9:52 ÌÌ, Arie Vayner (avayner) wrote:
> > > > > >
> > > > > > > I suggest you try using a regular policy map, building a class
> > > > > > > with
> > > > > > > the traffic matched in an ACL, and apply a regular police policy
> > > > > > > on
> > > > > > > that class...
> > > > > > > Arie
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hank Nussbacher 
> > > > > > > [mailto:]
> > > > > > > Sent: Saturday, June 14, 2008 21:50 PM
> > > > > > > To: Arie Vayner (avayner)
> > > > > > > Cc: 
> > > > > > > ;
> > > > > > >  Zenon Mousmoulas
> > > > > > > Subject: RE: [c-nsp] ip multicast rate-limit
> > > > > > >
> > > > > > > On Sat, 14 Jun 2008, Arie Vayner (avayner) wrote:
> > > > > > >
> > > > > > > > Hank,
> > > > > > > >
> > > > > > > > What are you trying to achieve?
> > > > > > > > Can you please share "show module"?
> > > > > > >
> > > > > > > Trying to limit SAP storms.
> > > > > > >
> > > > > > > 11    0  4-subslot SPA Interface Processor-400  7600-SIP-400
> > > > > > > JAE12035DJ5
> > > > > > > 11/0 1xOC48 POS/RPR SPA          SPA-1XOC48POS/RPR  JAE11441NKV
> > > > > > > 2.3
> > > > > > > Ok
> > > > > > >
> > > > > > > -Hank
> > > > > > >
> > > > > > > > Thanks
> > > > > > > > Arie
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: 
> > > > > > > >
> > > > > > > > [mailto:]
> > > > > > > >  On Behalf Of Hank
> > > > > > > > Nussbacher
> > > > > > > > Sent: Thursday, June 12, 2008 16:02 PM
> > > > > > > > To: 
> > > > > > > >
> > > > > > > > Cc: Zenon Mousmoulas
> > > > > > > > Subject: [c-nsp] ip multicast rate-limit
> > > > > > > >
> > > > > > > > http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/
> > > > > > > > imc_03.h
> > > > > > > > tm
> > > > > > > > l#wp1016097
> > > > > > > > In 12.2(18)SXF11:
> > > > > > > >
> > > > > > > > petach-tikva-gp(config)#int pos11/0/0 petach-tikva-gp(config-
> > > > > > > > if)#ip multicast rate-limit in group-list SAP-mcast-group 1000
> > > > > > > > "ip multicast rate-limit" command is not supported
> > > > > > > >
> > > > > > > > So I go to:
> > > > > > > > http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/
> > > > > > > > 12.2SXF/
> > > > > > > > na
> > > > > > > > tive/release/notes/OL_4164.html
> > > > > > > > where it says:
> > > > > > > > "The ip multicast rate-limit command is not supported on LAN
> > > > > > > > ports.
> > > > > > > > (CSCds22281)"
> > > > > > > >
> > > > > > > > So what 12.2SX version supports ip multicast rate-limit on a  
> > > > > > > > POS
> > > > > > > > interface?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Hank
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > cisco-nsp mailing list  
> > > > > > > >
> > > > > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/