[j-nsp] Junos CoS - ingress hierarchical policer

[Marcin Kurek]

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
>
>