The main conclusions based on testing described in the two VPP blog posts are:
- If sFlow is not enabled on a given interface, there is no regression on other interfaces.
- If sFlow is enabled, copying packets costs 11 CPU cycles on average
- If sFlow takes a sample, it takes only marginally more CPU time to enqueue.
- No sampling gets 9.88Mpps of IPv4 and 14.3Mpps of L2XC throughput,
- 1:1000 sampling reduces to 9.77Mpps of L3 and 14.05Mpps of L2XC throughput,
- and an overly harsh 1:100 reduces to 9.69Mpps and 13.97Mpps only.
The VPP sFlow plugin provides a lightweight method of exporting real-time sFlow telemetry from a VPP based router. Including the plugin with VPP distributions has no impact on performance. Enabling the plugin provides real-time visibility that opens up additional use cases for VPPs programmable dataplane. For example, VPP is well suited to packet filtering use cases where the number of ACL entries would exceed the capabilities of an ASIC. Combined with real-time visibility to identify DDoS attacks, VPP provides an effective means of mitigating the attacks by scrubbing the unwanted traffic.
No comments:
Post a Comment