[j-nsp] aggregated policing
CHEN Xu
simonchennj at gmail.com
Wed Jul 2 20:12:04 EDT 2008
Emm... it is just me being an idiot then :-)
Thanks guys!
-Simon
On Wed, Jul 2, 2008 at 8:08 PM, Stefan Fouant <sfouant at gmail.com> wrote:
> Yes Harry you are correct... The default behavior for interface
> policers is indeed shared amongst all interfaces which have the
> policer applied. This was discussed in a book called 'JUNOS Enterprise
> Routing'... Ever heard of it? ;)
>
>
>
> On 7/2/08, Harry Reynolds <harry at juniper.net> wrote:
>> I believe the default behavior is a shared policer unless a filter is
>> flagged as being interface-specific.
>>
>> Tested on M40:
>>
>>
>> <<< no filter or term specific
>>
>> [edit firewall]
>> harry at vpn02# show
>> policer test {
>> if-exceeding {
>> bandwidth-limit 1m;
>> burst-size-limit 1500;
>> }
>> then discard;
>> }
>> filter test {
>> term 1 {
>> then policer test;
>> }
>> term 2 {
>> then accept;
>> }
>> }
>>
>> <<< same filter applied to multiple interfaces
>>
>> [edit firewall]
>> harry at vpn02# top show interfaces
>> so-1/2/2 {
>> unit 0 {
>> family inet {
>> filter {
>> output test;
>> }
>> address 10.1.0.2/24;
>> }
>> }
>> }
>> so-1/2/3 {
>> unit 0 {
>> family inet {
>> filter {
>> output test;
>> }
>> address 192.168.1.1/24;
>> }
>> }
>> }
>>
>>
>> <<< On the SCB there is a single policer instance
>>
>>
>> SCB(vpn02 vty)# show filter
>> Filters:
>> Index Dir Cnt Text Bss Name
>> ----- ------ ------ ------ ------ --------
>> 1 96 0 20 0 __default_bpdu_filter__
>> 2 48 0 4 20 test
>> 65279 48 0 4 0 __auto_policer_template__
>> 65280 96 0 16 0 __auto_policer_template_1__
>> 65281 144 0 24 0 __auto_policer_template_2__
>> 65282 192 0 32 0 __auto_policer_template_3__
>> 65283 240 0 40 0 __auto_policer_template_4__
>>
>>
>> SCB(vpn02 vty)# show filter index 2 pro
>> Filters:
>> Index Dir Cnt Text Bss Name
>> ----- ------ ------ ------ ------ --------
>> 2 48 0 4 20 test
>>
>> Firewall program version 2 magic fed2beef
>> Name: "test" Protocol: ip
>> Hash: cfa11b5c171e8e96dd036a8e260b5768
>> Action directory: 1 entry (48 bytes)
>> Policer directory: 1 entry (176 bytes)
>> Text: 1 instruction word (4 bytes)
>> BSS: 5 next hop words (20 bytes)
>> Action directory: 1 entry (48 bytes)
>> 0: accept policer 0
>> -> 0:
>> Policer directory: 1 entry (176 bytes)
>> 0: Policer name "test-1": 1 reference <<<< 1 reference
>> Bandwidth Limit: 125000 bytes/sec.
>> Burst Size: 1500 bytes.
>> discard
>> Program instructions: 1 word
>>
>> 0: terminate -> action index 0
>>
>> <<< Change filter to interface-specific
>>
>> [edit firewall]
>> harry at vpn02# set filter test interface-specific
>>
>> [edit firewall]
>> harry at vpn02# commit
>> commit complete
>>
>>
>> <<< back on scb there are now two policers instances:
>>
>>
>> SCB(vpn02 vty)# show filter
>> Filters:
>> Index Dir Cnt Text Bss Name
>> ----- ------ ------ ------ ------ --------
>> 1 96 0 20 0 __default_bpdu_filter__
>> 3 48 0 4 20 test-so-1/2/2.0-o <<<<
>> 4 48 0 4 20 test-so-1/2/3.0-o <<<<<
>> 65279 48 0 4 0 __auto_policer_template__
>> 65280 96 0 16 0 __auto_policer_template_1__
>> 65281 144 0 24 0 __auto_policer_template_2__
>> 65282 192 0 32 0 __auto_policer_template_3__
>> 65283 240 0 40 0 __auto_policer_template_4__
>>
>>
>> SCB(vpn02 vty)# show filter inde 3 pro
>> Filters:
>> Index Dir Cnt Text Bss Name
>> ----- ------ ------ ------ ------ --------
>> 3 48 0 4 20 test-so-1/2/2.0-o
>>
>> Firewall program version 2 magic fed2beef
>> Name: "test-so-1/2/2.0-o" Protocol: ip Flags: 0x01
>> Hash: 5f72b272c23e8bfb61d6a59495cb0780
>> Action directory: 1 entry (48 bytes)
>> Policer directory: 1 entry (176 bytes)
>> Text: 1 instruction word (4 bytes)
>> BSS: 5 next hop words (20 bytes)
>> Action directory: 1 entry (48 bytes)
>> 0: accept policer 0
>> -> 0:
>> Policer directory: 1 entry (176 bytes)
>> 0: Policer name "test-1-so-1/2/2.0-o": 1 reference
>> Bandwidth Limit: 125000 bytes/sec.
>> Burst Size: 1500 bytes.
>> discard
>> Program instructions: 1 word
>>
>> 0: terminate -> action index 0
>>
>> SCB(vpn02 vty)# show filter inde 4 pro
>> Filters:
>> Index Dir Cnt Text Bss Name
>> ----- ------ ------ ------ ------ --------
>> 4 48 0 4 20 test-so-1/2/3.0-o
>>
>> Firewall program version 2 magic fed2beef
>> Name: "test-so-1/2/3.0-o" Protocol: ip Flags: 0x01
>> Hash: 5f72b272c23e8bfb61d6a59495cb0780
>> Action directory: 1 entry (48 bytes)
>> Policer directory: 1 entry (176 bytes)
>> Text: 1 instruction word (4 bytes)
>> BSS: 5 next hop words (20 bytes)
>> Action directory: 1 entry (48 bytes)
>> 0: accept policer 0
>> -> 0:
>> Policer directory: 1 entry (176 bytes)
>> 0: Policer name "test-1-so-1/2/3.0-o": 1 reference
>> Bandwidth Limit: 125000 bytes/sec.
>> Burst Size: 1500 bytes.
>> discard
>> Program instructions: 1 word
>>
>> 0: terminate -> action index 0
>>
>> SCB(vpn02 vty)#
>>
>> HTHs
>>
>>
>>> -----Original Message-----
>>> From: juniper-nsp-bounces at puck.nether.net
>>> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of CHEN Xu
>>> Sent: Wednesday, July 02, 2008 4:13 PM
>>> To: juniper-nsp at puck.nether.net
>>> Subject: [j-nsp] aggregated policing
>>>
>>> Hi guys,
>>>
>>> I am wondering whether it is doable on Juniper to police the
>>> aggregation of a set of interfaces.
>>>
>>> For example, I have two interfaces, each of them has a
>>> capacity cap of 100K. However, I want to put a further cap,
>>> saying the sum of the two interfaces should not go over 150K.
>>> Is this doable?
>>>
>>> I found an statement of interface-set, which can specify a
>>> set of interfaces, and then set a police policy. But I
>>> suspect that this will apply the same policy to each
>>> individual interface within that set, but not on the aggregated level.
>>>
>>> Thanks.
>>> -Simon
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> --
> Sent from Gmail for mobile | mobile.google.com
>
> Stefan Fouant
> Principal Network Engineer
> NeuStar, Inc. - http://www.neustar.biz
> GPG Key ID: 0xB5E3803D
>
More information about the juniper-nsp
mailing list