Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts

UDP file upload killing other traffic on SonicWall

So we just started using Signiant Media Shuttle to upload media to a remote site. It uses UDP to maximize the upload speeds. The problem is that when Media Shuttle is uploading a file, all other traffic is slowed to a crawl. Media shuttle is capped around 90mbps, but our total upload capacity should be around 500mbps. We should have plenty of bandwidth to do other things, but even accessing web pages becomes very slow. We ran into this with another similar piece of software, but the client allowed me to set limits on bandwidth, and only caused problems when the limit was set to "max", which I assume basically told the software to push the packets regardless of other traffic. Media Shuttle does not have options to control bandwidth on the client side. I've tried setting the priority of traffic on those ports to low, but it does not seem to make a difference. Any ideas?

82% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1

I would confirm Signiant is limited to 90 mbps, not 90 MBps as that would exceed the 500mbps. A google search on the product doesn't seem to show much detail around the UDP flows. My concern for a firewall would be how large each UDP PDU is and the pps rate of the UDP PDUs. Also any fragementation performed by the firewall could impact it, as well as large buffers getting filled with many UDP frames that cause TCP ACKs to go missing and cause browsing traffic to experience retransmissions. How about IPsec is this traffic being tunneled between the sites?

Perhaps the best starting place is pps/bps on the SonicWall "trusted" interface facing the Signiant media endpoint and comparing those numbers against the SonicWall spec sheet during a file transmission. If the interface numbers are close to the limits on the SonicWall it may simply be too much for the unit.

level 2
Original Poster1 point · 4 months ago · edited 4 months ago

Yeah, it caps at around 11MBps. I will run a packet cap when we do another upload to see what sort of PDUs we are looking at. It is very possible the buffer is getting filled. The firewall's UI seems to become slow to respond during an upload, even from a different network than where the traffic is originating. I haven't noticed that the firewall's CPU is overly taxed during the upload, so I don't think it is doing excessive inspection. The firewall is an NSA 4600, which has a pretty decent capacity for most things.

level 1
ACSA | VCP-DCV | VCA-DCV | JNCIA | VCP-DCV | PCNSE | BCNE3 points · 4 months ago

Make sure your model can run a full 500mb of throughput with all the features you have turned on. It's very possible that it's rated above 500 with everything off, but much lower with specific features on.

level 2
Original Poster1 point · 4 months ago

It's an NSA 4600. It should be able to handle much more than we are throwing at it. And for the most part it works without issue. It just gets bogged down by something with this UDP traffic.

level 3
ACSA | VCP-DCV | VCA-DCV | JNCIA | VCP-DCV | PCNSE | BCNE1 point · 4 months ago

Go check those specs again... 800mb full DPI inspection.

level 4
Original Poster1 point · 3 months ago

Right, which should be more than enough. We generally don't go over 100-200 Mbps, even with an upload happening. We pay for up to 500 from our ISP, but rarely hit that.

level 1
School of port knocks2 points · 4 months ago

Run some tests without Media Shuttle running and ensure that you actually can use 500mbps?

level 2
Original Poster1 point · 4 months ago · edited 4 months ago

Yep, everything runs fine when a file is not being uploaded. I've run IPerf across the firewall both while Media Shuttle is running a file upload and not. I get good speeds when Media Shuttle is not running, but as soon as a file upload is started, speeds crash.

*We have a fiber provided by our ISP

level 1
I like graphs2 points · 4 months ago

UDP senders do not limit or increase sending rates based on traffic shaping. There is no congestion-control mechanism for UDP traffic like TCP. If you're limiting the traffic on the Sonicwall, the Signiant is probably doing its best to continue sending at full speed since its sending via UDP. Sonicwall will most likely attempt to either delay or drop non-compliant packets in the UDP stream. If delay, it will probably overflow its own buffers and fail at doing anything productive. If drop, you'll likely see failed uploads unless Signiant has some checksum mechanism on the backend.

What is the Sonicwall's CPU usage like when you're testing this?

level 2
Original Poster1 point · 4 months ago · edited 4 months ago

The Signiant software does handle checksum. All CPU cores indicate about 50% utilization- higher than normal traffic, but not excessive. The UDP traffic seems to get through without an issue. It's all other traffic that suffers. I'm not doing anything to specifically limit bandwidth on the firewall. The bandwidth cap comes from the Signiant portal (server side), and can be changed by the portal owner. We are uploading to a third party who is the owner of the portal. I think buffer overflow may be an issue.

level 1

This is exactly where I usually suggest BitTorrent for moving large files with integrity checking / resume / etc. Setup an internal tracker and let it rip site to site with appropriate bandwidth limits.

That said, I would exclude your endpoints at both sides from any additional inspections (IPS, Anti-virus, etc.) as your firewall might be trying to reassemble the communication stream to assess payload.

level 2
Original Poster1 point · 4 months ago

Unfortunately, we are uploading to a third party, and they require the use of the Signiant software. I have added the remote server addresses to my exclusion list since the last upload, so we will see if it makes a difference. The NSA 4600 should be able to handle that volume of traffic without an issue, even with full DPI.

level 3

I was thinking the inspection could be a memory / buffer issue rather than inspection bandwidth. In that respect I was thinking about it trying to re-assmeble then entire UDP stream, or at least huge chunks of floating windows (overlap) and chewing through RAM in the process. Not sure on SonicWalls though, as much as i worked with them in the past, they aren't really enterprise class, so less about their internal traffic processing tends to be known.

Community Details





###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
Rule #1: No Home Networking.
Rule #2: No Certification Brain Dumps / Cheating.
Rule #3: No BlogSpam / Traffic re-direction.
Rule #4: No Low Quality Posts.
Rule #5: No Early Career Advice.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.