[j-nsp] Junos CoS - ingress hierarchical policer
Marcin Kurek
md.kurek at gmail.com
Thu May 18 06:59:42 EDT 2017
Actually problem is that I have MX480 boxes with older MPC2 cards, so I
think there are certain limitations in terms of number of queues,
similar to -TR and -SE in case of ASR9k.
I need to double check that. I will try the config you have provided in
the lab and let you know if it does work for me.
Thanks for help!
W dniu 2017-05-18 o 12:44, Saku Ytti pisze:
> 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
>
>
More information about the juniper-nsp
mailing list