3

Our network is currently going through a certification, and we're seeing some odd issues with the policer.

We have 2 MX240 routers set up with MPLS/RSVP/IS-IS with a Martini-Draft l2circuit configured over these. The interfaces are configured to receive double-tagged frames; pop on ingress and push on egress. There are linux probes attached to the physical interface on each MX sending the test traffic.

The certification tests consist of 3 frame-sizes, and that the MXs police the traffic at the given value (700M here).

PE-1

set interfaces ae0 unit 300 encapsulation vlan-ccc
set interfaces ae0 unit 300 vlan-id 300
set interfaces ae0 unit 300 input-vlan-map pop
set interfaces ae0 unit 300 output-vlan-map push
set interfaces ae0 unit 300 layer2-policer output-policer 700m-policer

set firewall policer 700m-policer logical-interface-policer
set firewall policer 700m-policer if-exceeding bandwidth-limit 700m
set firewall policer 700m-policer if-exceeding burst-size-limit 72k
set firewall policer 700m-policer then discard

set protocols l2circuit neighbor 1.1.1.2 interface ae0.300 virtual-circuit-id 1234
set protocols l2circuit neighbor 1.1.1.2 interface ae0.300 ignore-mtu-mismatch
set protocols l2circuit neighbor 1.1.1.2 interface ae0.300 pseudowire-status-tlv


PE-2

set interfaces ae0 unit 300 encapsulation vlan-ccc
set interfaces ae0 unit 300 vlan-id 300
set interfaces ae0 unit 300 input-vlan-map pop
set interfaces ae0 unit 300 output-vlan-map push
set interfaces ae0 unit 300 layer2-policer output-policer 700m-policer
set interfaces ae0 unit 300 family ccc

set firewall policer 700m-policer logical-interface-policer
set firewall policer 700m-policer if-exceeding bandwidth-limit 700m
set firewall policer 700m-policer if-exceeding burst-size-limit 72k
set firewall policer 700m-policer then discard

set protocols l2circuit neighbor 1.1.1.1 interface ae0.300 virtual-circuit-id 1234
set protocols l2circuit neighbor 1.1.1.1 interface ae0.300 ignore-mtu-mismatch
set protocols l2circuit neighbor 1.1.1.1 interface ae0.300 pseudowire-status-tlv

The main issue is that the 80-byte frames are being policed over the 700M limit (i.e. too many frames are being dropped), whereas the 600-byte and 1500-byte tests are dropping the correct amount.

Can anyone point me as to why more of the 80-byte frames and the larger frames aren't, and how I can fix this?

Thanks in advance!

EDIT 1

The testing mechanism is that the A-end sends n frames which amounts to a certain bitrate. The B-end has a min- & max-frame count, which the test should fall in between.

2
  • You aren't trying to send the same amount of L4 data with the small frames, are you? That would cause a significant amount of additional overhead and easily explain a much higher amount of frame drops. Otherwise, please add an explanation of the test cycle to your answer.
    – Zac67
    Feb 22, 2022 at 13:10
  • 1
    As above, the testing is being done on amount of frames being sent, not actual recv. bandwidth.
    – TheCaptain
    Feb 22, 2022 at 14:17

1 Answer 1

3

Actually found the answer to this today:

https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/task/configuring-the-accounting-of-policer-overhead.html

In order to address the MEF CE 2.0 stringent requirements to the bandwidth profile, policer-overhead adjustment is defined on a per IFL or direction granularity. The policer-overhead adjustment is in the range of -16 bytes to +16 bytes and is applied for all the policers that take into account Layer 1/ Layer 2 (L1/L2) packet length in the specified IFL or direction, including corresponding logical interface family (IFF) feature policers.

I added a -4 byte adjustment to the policer, and the tests completed successfully

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.