[c-nsp] ip multicast rate-limit

Arie Vayner (avayner) avayner at cisco.com
Thu Jun 19 05:08:27 EDT 2008


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:zmousm at admin.grnet.gr] 
Sent: Thursday, June 19, 2008 11:52 AM
To: Arie Vayner (avayner)
Cc: Hank Nussbacher; cisco-nsp at puck.nether.net
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:zmousm at admin.grnet.gr]
> Sent: Wednesday, June 18, 2008 20:20 PM
> To: Arie Vayner (avayner)
> Cc: Hank Nussbacher; cisco-nsp at puck.nether.net
> 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:zmousm at admin.grnet.gr]
>> Sent: Sunday, June 15, 2008 23:19 PM
>> To: Arie Vayner (avayner)
>> Cc: Hank Nussbacher; cisco-nsp at puck.nether.net
>> 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:zmousm at admin.grnet.gr]
>>> Sent: Sunday, June 15, 2008 22:48 PM
>>> To: Arie Vayner (avayner)
>>> Cc: Hank Nussbacher; cisco-nsp at puck.nether.net
>>> 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:hank at efes.iucc.ac.il]
>>>> Sent: Saturday, June 14, 2008 21:50 PM
>>>> To: Arie Vayner (avayner)
>>>> Cc: cisco-nsp at puck.nether.net; 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: cisco-nsp-bounces at puck.nether.net 
>>>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hank 
>>>>> Nussbacher
>>>>> Sent: Thursday, June 12, 2008 16:02 PM
>>>>> To: cisco-nsp at puck.nether.net
>>>>> 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  cisco-nsp at puck.nether.net 
>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>
>>>
>>
>



More information about the cisco-nsp mailing list