High Switch CPU due to Jumbo Frames / Video Streaming - Migrating Physical pfSense/DGuard to Proxmox?

[uolficina]

Hello everyone,

I am working with a client who has an interesting setup. Initially, their entire project was based on VMware ESXi 8.0u2. They run a security monitoring company that handles businesses, homes, security cameras, and related services. They previously had inadequate hardware and network design, so I helped them upgrade their equipment and implement new concepts to solve various operational problems.

Now, we are facing a new challenge:

• The Software: They use DGuard (from Seventh), a streaming aggregation software for thousands of DVRs and security cameras. This software live-streams all client video through VPNs to the central DGuard server on the company's infrastructure.
• The Traffic: DGuard splits the video streaming into small packets over the internet. However, when it reaches the LAN, all the streams are distributed to multiple mosaic screens in their Security Operations Center (SOC).
• The Network: This creates an enormous amount of traffic—essentially a private Netflix on their LAN. After migrating to more robust switches (TP-Link SG3452), we solved the dropped network packets (which pfSense was reporting via netstat -idb).
• The Problem: We noticed a new issue. DGuard is pushing jumbo frames, and the switch responsible for delivering traffic to the mosaic screens is hitting 90% CPU utilization. This is a red alert because the switch is being forced to handle TSO (TCP Segmentation Offload) and MTU fragmentation while distributing the traffic simultaneously (which shouldn't be its job at Layer 2).
• Current Hardware Constraints: DGuard is currently running on a physical bare-metal machine. pfSense (which controls the VLANs and all routing/traffic) is also on a physical machine—a basic desktop PC that is already at risk of hardware failure. I can't force TSO or MTU processing on the pfSense box; enabling this would spike its CPU and temperatures. With over 60 VPN tunnels plus the massive video/audio traffic, putting that load on the desktop could be even more dangerous than the switch running at 90%.

My Proposed Solution:

1. Take our Lenovo ThinkSystem SR630 server (40 threads, 128GB RAM).
2. Install Proxmox VE.
3. Migrate both the DGuard physical machine and the pfSense physical machine into VMs on this host.

By doing this, the traffic will use the Linux bridge (vmbr0) to travel from the DGuard VM directly to the pfSense VM. This should force the default MTU of 1500 on the Proxmox bridge, and the physical output NIC will send "pre-processed" standard MTU frames to the physical switch, finally giving the switch's CPU a break. If the CPU on the SR630 spikes to handle this, it's not a problem since we have enterprise-grade hardware built for this load.

I have never dealt with jumbo frame issues like this before, nor have I needed to force an MTU of 1500 to suppress this behavior—mainly because I've never managed a "private Netflix on a LAN" environment.

What do you guys think? Do you have any suggestions, ideas, or tips for setting up this environment? This is a critical 24/7 operation, and maintenance windows must be strictly scheduled. If anyone has experience with this kind of situation, I would love to hear your thoughts and exchange knowledge.

Thanks!

 

[cwt]

I think you are mixing up several different things here. A switch does not perform TSO. TSO is a host/NIC offload mechanism where the OS can hand a large TCP buffer to the NIC and the NIC segments it into normal Ethernet frames before transmitting them.

Likewise, a normal L2 switch does not fragment oversized IP packets. It either forwards an Ethernet frame if the frame size is supported, or drops it if it is not. IP fragmentation happens at L3, not because an L2 switch somehow converts jumbo frames into 1500-byte frames.

So putting

DGuard VM -> Linux Bridge -> pfSense VM

in between will not magically “pre-process” jumbo frames into standard MTU frames either. A Linux bridge is still a bridge, not an MTU converter. Before redesigning the whole setup, I would first verify the basic assumption: are jumbo frames actually what is causing the high CPU utilization on the SG3452?

Capture the traffic on a mirrored switch port and look at the actual frame sizes, packet rate, broadcast/multicast traffic and destinations. Also check the switch for STP topology changes, multicast/IGMP behavior, flooding, errors/drops and anything that causes traffic to be punted from the switching ASIC to the CPU.

Especially with thousands of video streams and multiple mosaic displays, multicast/flooding/PPS behavior would be much higher on my list of suspects than jumbo frames. In fact, at the same throughput, larger frames normally mean fewer packets/frames per second.

I would therefore not migrate DGuard and pfSense onto one Proxmox host in the hope that the Linux bridge will solve the switch CPU problem. You may just move the topology around without fixing the actual cause, while additionally creating a rather important single point of failure for what you describe as a critical 24/7 environment.

First determine exactly what traffic is hitting the SG3452 CPU and why. Once that is known, you can decide whether MTU, multicast handling, switching capacity, topology or something else actually needs to be changed.

Also keep in mind that the SG3452 is a fairly entry-level managed switch. For a large 24/7 video distribution environment with heavy multicast traffic, I would personally look at switching hardware designed for AV-over-IP workloads, e.g. Netgear AV, before trying to solve this by moving the firewall and application stack into Proxmox.

 

[uolficina]

I think you are mixing up several different things here. A switch does not perform TSO. TSO is a host/NIC offload mechanism where the OS can hand a large TCP buffer to the NIC and the NIC segments it into normal Ethernet frames before transmitting them.

Likewise, a normal L2 switch does not fragment oversized IP packets. It either forwards an Ethernet frame if the frame size is supported, or drops it if it is not. IP fragmentation happens at L3, not because an L2 switch somehow converts jumbo frames into 1500-byte frames.

So putting

DGuard VM -> Linux Bridge -> pfSense VM

in between will not magically “pre-process” jumbo frames into standard MTU frames either. A Linux bridge is still a bridge, not an MTU converter. Before redesigning the whole setup, I would first verify the basic assumption: are jumbo frames actually what is causing the high CPU utilization on the SG3452?

Capture the traffic on a mirrored switch port and look at the actual frame sizes, packet rate, broadcast/multicast traffic and destinations. Also check the switch for STP topology changes, multicast/IGMP behavior, flooding, errors/drops and anything that causes traffic to be punted from the switching ASIC to the CPU.

Especially with thousands of video streams and multiple mosaic displays, multicast/flooding/PPS behavior would be much higher on my list of suspects than jumbo frames. In fact, at the same throughput, larger frames normally mean fewer packets/frames per second.

I would therefore not migrate DGuard and pfSense onto one Proxmox host in the hope that the Linux bridge will solve the switch CPU problem. You may just move the topology around without fixing the actual cause, while additionally creating a rather important single point of failure for what you describe as a critical 24/7 environment.

First determine exactly what traffic is hitting the SG3452 CPU and why. Once that is known, you can decide whether MTU, multicast handling, switching capacity, topology or something else actually needs to be changed.

Also keep in mind that the SG3452 is a fairly entry-level managed switch. For a large 24/7 video distribution environment with heavy multicast traffic, I would personally look at switching hardware designed for AV-over-IP workloads, e.g. Netgear AV, before trying to solve this by moving the firewall and application stack into Proxmox.

This is the frame size received on the switch port thats getting the traffic, this switch sendo the traffic to the Mosaic screens(exactly 10 big Mosaic screens and some more workstations with less use)


48
Port: Gi1/0/48
Tx Collisions: 0
Tx Ucast: 2,810,232
Tx Mcast: 608
Tx Bcast: 426
Tx Jumbo: 320,401
Tx Pkts: 2,811,266
Tx Bytes: 846,346,405
Tx Errors: 0
Tx Discards: 0
Rx Ucast: 7,756,894
Rx Mcast: 2,761
Rx Bcast: 12,634
Rx Jumbo: 6,124,078
Rx Alignment: 0
Rx UnderSize: 0
Rx 64Pkts: 124,153
Rx 65-127Pkts: 370,953
Rx 128-255Pkts: 204,611
Rx 256-511Pkts: 370,229
Rx 512-1023Pkts: 194,172
Rx 1024-1518Pkts: 384,093
Rx Pkts: 7,772,289
Rx Bytes: 10,197,619,132
Rx Errors: 0
Rx Discards: 0

See the size. This Jumbo RX stop when i turn off the DGuard server. And the rest of the traffic Just get Zero Jumbo frames.

So DGuard is sending Jumbo frames to switch 1 (where he is plugged and gets low CPU usage because this switch Just sends the traffic to the uplink to switch 2 in the SOC Room) this switch 2 received this Jumbo frames on port 48 as you can see.

And gets 90% of usage, as my research goes qnd as you Said an switch working on L2 dont does TSO but can have high CPU consuption trying to process those Jumbo frames and send to the destinations, considering that anything in the whole network its even configured to work with Jumbo frames.

So my think is that the default MTU configs of VMS on PROXMOX and Bridges, Will force the MTU 1500 trough the destination, or at least give me the tools to force.

What you think of this port 48 stats?

 

[cwt]

There are two separate assumptions here that I would not make:

First: a Layer-2 switch should not normally need significant CPU just to forward jumbo frames. If the frame size is supported, forwarding is typically handled by the switching ASIC. The fact that nothing else in the network is intentionally configured for jumbo frames does not automatically mean the switch has to "process" or resize them in software.

Second: Proxmox does not solve this simply by using MTU 1500 on the VM interfaces or Linux bridges. An L2 bridge does not take an incoming jumbo Ethernet frame and split it into several 1500-byte frames.

The cleanest way to prove or disprove the jumbo-frame theory would be to reproduce the same traffic with DGuard limited to MTU 1500. However, I would only do that in a maintenance window or test environment, especially if this is a sensitive 24/7 production system.

If changing DGuard itself is not safe, I would first capture the actual frame sizes and compare switch CPU utilization with and without the DGuard traffic. That will give you useful evidence without changing the production path.
One thing I would verify before going further: is DGuard really the only device generating these jumbo frames, and what are the actual frame sizes?

The Rx Jumbo counter tells you that the switch classifies them as oversized/jumbo frames, but not whether we are talking about ~1600 byte frames or actual 9K jumbo frames. Also, if the rest of the network is not configured for jumbo frames, it would be interesting to check whether those same frames actually arrive at the mosaic systems unchanged. Jumbo frames require the complete Layer-2 path to support the corresponding frame size.

But even if DGuard is really sending 9K frames into an otherwise MTU-1500 network, that alone still doesn't explain 90% switch CPU utilization. A switch should not normally use its CPU to resize or fragment those frames.