diff --git a/content/articles/2026-02-14-vpp-policers.md b/content/articles/2026-02-14-vpp-policers.md index 910dae2..1121def 100644 --- a/content/articles/2026-02-14-vpp-policers.md +++ b/content/articles/2026-02-14-vpp-policers.md @@ -12,8 +12,8 @@ performance and versatility. For those of us who have used Cisco IOS/XR devices, _ASR_ (aggregation service router), VPP will look and feel quite familiar as many of the approaches are shared between the two. -There's some really fantastic features in VPP, some of which are lesser well known, and not always -very well documented. In this article, I will describe a unique usecase in which I think VPP will +There are some really fantastic features in VPP, some of which are less well known, and not always +very well documented. In this article, I will describe a unique use case in which I think VPP will excel, notably acting as a gateway for Internet Exchange Points. A few years ago, I toyed with the idea to use VPP as an _IXP Reseller_ concentrator, allowing @@ -49,7 +49,7 @@ Back in October of 2023, I reached the conclusion that the policer works in the ## VPP Infra: L2 Feature Maps -The benefit in using the `device-input` input arc is it's efficient: every packet that comes from the +The benefit of using the `device-input` arc is that it's efficient: every packet that comes from the device (`Gi10/0/1`) regardless of tagging or not, will be handed off to the policer plugin. It means any traffic (L2, L3, sub-interface, tagged, untagged) will all go through the same policer. @@ -61,7 +61,7 @@ highest set bit, and then dispatch the packet to a pre-configured graph node. Up pre-configured graph node. This continues until all the bits are checked and packets have been handed to their respective graph node if any given bit is set. -To show what I can do with these nodes, let me dive in to an example. When a packet arrives on an +To show what I can do with these nodes, let me dive into an example. When a packet arrives on an interface configured in L2 mode, either because it's a bridge-domain or an L2XC, `ethernet-input` will send it to `l2-input`. This node does three things: @@ -204,7 +204,7 @@ I think writing unit- and integration tests is a great idea. I add a new file 1. **L2 Output**: on a bridge-domain sub-interface The existing `test/test_policer.py` should also cover existing cases, and of course it's important -that my work does not impact these changes. Lucky me, the existing tests all still pass :) +that my work does not break existing functionality. Lucky me, the existing tests all still pass :) ### Test: L3 in/output @@ -288,7 +288,7 @@ pim@summer:~/src/vpp$ make test-debug TEST=test_policer_subif V=2 {{< image width="5em" float="left" src="/assets/shared/warning.png" alt="Warning" >}} **Whoops!** So much for predicting the outcome! I see that 7 packets (896 bytes) make it through on input -while 6 packets (876 bytes) made it through on output. In the input case, the packet size is +while 6 packets (876 bytes) make it through on output. In the input case, the packet size is `896/7 = 128` bytes, which is 18 bytes short. What's going on? ### Side Quest: Policer Accounting @@ -304,8 +304,8 @@ Ben also points out that when applying the policer to the interface, I can detec it's a PHY, a single-tagged or a double-tagged interface, and store some information to help correct the accounting. We discuss a little bit on the mailinglist, and agree that it's best for all four cases (L2 input/output and L3 input/output) to use the full L2 frame bytes in the accounting, which -as an added benefit also that it remains backwards compatible with the `device-input` accounting. -Chapeau, Ben you're so clever! +as an added benefit, also remains backwards compatible with the `device-input` accounting. +Chapeau, Ben, you're so clever! I add a little helper function: @@ -351,7 +351,7 @@ pim@summer:~/src/vpp$ make test-debug TEST=test_policer_subif V=2 | grep 'police 'exceed_packets': 0, 'exceed_bytes': 0, 'violate_packets': 61, 'violate_bytes': 8906} ``` -Yaay, great success! +Yay, great success! ### Test: L2 in/output @@ -418,7 +418,7 @@ ethernet-input I've sent the change, which was only about ~300 LOC, off for review. You can follow along on the gerrit on [[44654](https://gerrit.fd.io/r/c/vpp/+/44654)]. I don't think the policer got much slower after adding the l2 path, and one might argue it doesn't matter because policing didn't work on -sub-interfaces and L2 output at all, before this change. However, for the L3 input/output case, and +sub-interfaces or L2 output at all before this change. However, for the L3 input/output case, and for the PHY input case, there are a few CPU cycles added now to address the L2 and sub-int use cases. Perhaps I should do a side by side comparison of packets/sec throughput on the bench some time. @@ -428,5 +428,5 @@ and packet scheduler designed to eliminate bufferbloat, which is high latency ca buffering in network equipment, while ensuring fair bandwidth distribution among competing traffic flows. I know that Dave Täht - may he rest in peace - always wanted that. -For me, I've set my sights on eVPN VxLAN, and I started toying with SRv6 L2 transport also. I hope +For me, I've set my sights on eVPN VxLAN, and I also started toying with SRv6 L2 transport. I hope that in the spring I'll have a bit more time to contribute to VPP and write about it. Stay tuned!