[j-nsp] Junos CoS - ingress hierarchical policer
Saku Ytti
saku at ytti.fi
Thu May 18 06:44:46 EDT 2017
Well you could set shape buffer tiny, then it would similar to policing.
I would argue the IOS-XR config you have is poor config, I don't think
there is platform which accepts that config, which does not accept
shaper. Why would you run policer, if shaper is available.
But yeah recolouring you need to do via FW policy, but I hope that'll
be fairly obvious part, if not, I can provide some example.
On 18 May 2017 at 13:28, Marcin Kurek <md.kurek at gmail.com> wrote:
> Hey Saku,
>
> Thanks for taking time to reply. I need to consult documentation to fully
> understand your examples, but in the meantime I wanted to ask why are you
> skeptical about policing?
>
> I should be able to achieve what I need with below IOS XR syntax:
>
> policy-map parent
> class class-default
> service-policy child
> police rate 2 mbps
> child-conform-aware
> conform-action transmit
> exceed-action drop
>
> policy-map child
> class EF
> police rate 1 mbps
> conform-action set mpls experimental imposition 4
> exceed-action drop
> class AF1
> police rate 1 mbps
> conform-action set mpls experimental imposition 3
> exceed-action set mpls experimental imposition 2
>
> Here we start policing in child policy-map, and result (red/green) is
> presented to parent policer. We need to have our parent policer to be
> color-aware to avoid dropping traffic which is conforming on child level.
>
> Why to recolor AF31/AF21? I'm thinking about scenario where I have
> multi-site IP VPN and many sites start sending traffic to one particular
> site.
> Since ingress traffic can exceed contract and still be conformed, one of the
> sites might send 10/10 Mbps of A31 instead of 3 Mbps.
> If I don't recolor, how can I ensure that rest of the sites which don't
> violate contract won't suffer?
>
> Many thanks
>
>
> W dniu 2017-05-18 o 10:44, Saku Ytti pisze:
>
>> Hey Marcin,
>>
>> I'm skeptical if you can do this with policing at all. But this
>> request aligns really well with scheduler + shaping.
>>
>> So something like this:
>> [edit class-of-service]
>> + traffic-control-profiles {
>> + 10M:30-20-20-30 {
>> + scheduler-map 30-20-20-30;
>> + shaping-rate 10m burst-size 1;
>> + guaranteed-rate 10m burst-size 1;
>> + }
>> + }
>> [edit class-of-service interfaces]
>> + xe-0/1/2 {
>> + unit 34 {
>> + input-traffic-control-profile 10M:30-20-20-30;
>> + }
>> + }
>> [edit class-of-service scheduler-maps]
>> + forwarding-class EF scheduler EF:30;
>> + forwarding-class AF1 scheduler AF1:20;
>> + forwarding-class AF2 scheduler AF2:20;
>> + forwarding-class BE scheduler BE:30;
>> + }
>> [edit class-of-service schedulers]
>> class-default { ... }
>> + EF:30 {
>> + transmit-rate {
>> + percent 30;
>> + exact;
>> + }
>> + buffer-size temporal 25k;
>> + priority high;
>> + }
>> + AF1:20 {
>> + transmit-rate percent 20;
>> + buffer-size temporal 50k
>> + priority medium-high;
>> + }
>> + AF2:20 {
>> + transmit-rate percent 20;
>> + buffer-size temporal 50k;
>> + priority medium-high;
>> + }
>> + BE:30 {
>> + transmit-rate percent 30;
>> + buffer-size temporal 100k;
>> + priority low;
>> + }
>>
>>
>>
>> You in addition need
>> a) classifying the traffic to EF, AF1, AF2, BE (feel free to rename
>> them toi voice, data1, data2, and best-effort)
>> b) rewrite-rules to tell what 802.1p, EXP/TC, DSCP/PREC values to use
>> for each class on egress
>> c) firewall rule to recolour AF1+AF2 to BE when exceeding 20% (why do
>> you want the recolouring, i don't think you need it, if you don't want
>> BE to out-compete AF, then just give BE percent 1, and increase
>> AF1/AF2). Recolouring is fully supported, but I'm not sure I see the
>> point.
>> d) decide how long you wanna buffer the traffic:
>> - know how much demand in each class there _USUALLY_
>> - know how many millisecond, at worst, you're gonna introduce
>> latency before dropping (don't buffer bloat....):
>> Assume we want to have no more than 30ms of latency to
>> BE, but we know that BE is in excess normally, and that normally BE
>> will use 60% of capacity. So you'd want to have10Mbps*0.6*0.03 =
>> 22.5kB of buffer. So then we solve 10Mbps * 0.3 * X = 22.5kB to find
>> what temporal value to use, to get 22.5kB of buffering. I.e. 22.5kB /
>> (100Mbps*0.3) = 0.06s. So we want temporal 60k.
>>
>>
>> On 18 May 2017 at 10:33, Marcin Kurek <md.kurek at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> I'm new to Junos CoS and struggling with creating ingress policer for a
>>> customer so they are allowed to send traffic belonging to 4 different
>>> classes:
>>> - voice (30%)
>>> - data-1 (20%)
>>> - data-2 (20%)
>>> - best effort (30%)
>>>
>>> It should meet following objectives:
>>>
>>> - at parent level police customer traffic to let's say 10 Mbps
>>> - each traffic type goes to its own forwarding-class, which is then
>>> mapped to different queues on egress
>>> - voice traffic should be policed to 30%, excess traffic should be
>>> discarded
>>> - data-1 and data-2 should be policed to 20%, but they can use
>>> additional bandwidth up to parent level (10 Mbps) if it's available.
>>> Once it gets above contract it should get remarked to forwarding-class
>>> BE.
>>>
>>> My idea was to create MF classifier, where I match certain traffic and
>>> assign appropriate forwarding-class. Also, traffic in data-1 and data-2
>>> would be policed here.
>>> Depending if it's in-contract or out-of-contract, it would get assigned
>>> appropriate forwarding-class.
>>> Also, I'd use hierarchical-policer with aggregate set to 10 Mbps and
>>> premium to 3 Mbps.
>>>
>>> Does it sound right, or I got it totally wrong? I'm having some
>>> implementation issues, but before I get into this I wanted to make sure
>>> the idea is right.
>>>
>>> Thanks a lot!
>>>
>>> _______________________________________________
>>> 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
--
++ytti
More information about the juniper-nsp
mailing list