Veeam Backup & Replication DDOSing itself - VeeamTransportSvc Port Exhaustion

Hi,

Has anyone experienced VBR spinning up huge amounts of instances of a process, and consuming all RPC ports?

I suspect it’s AV related due to the customer’s AV change occurring at a similar time, but we’ve got the rules in place to exempt directories and binaries.

I’ve seen VBR have port exhaustion exactly once before, that was a VCC installation and the firewall was half-closing sessions and Veeam wasn’t doing a good job detecting this and freeing up ports subsequently.

This scenario is different however.

VBR server that is only for job orchestration (all backup & repo roles are on physical appliances, proxy & repo roles uninstalled from VBR). Server was up for less than 6 hours yesterday, and it spawned 18,000 threads of VeeamTransportSvc, all looping back to itself. But the server ran out of available ports and/or buffer space and then normal connections such as backup repository availability checks were failing, causing VBR to mark the repositories as offline, then causing even more cascading issues with jobs automatically failing due to repository extents being unavailable.

The physical servers are always okay, and it’s just happening on the VBR instance, which is the latest version of v11a btw. Veeam does eventually close down the threads, I saw it do so over a 30-40 minute period go from 18k threads down to about 2k threads across the entire OS. I’ve been doing netstat -abno outputs and normally the file is around 1k lines long, but when it happens its about 11k lines long.

So yeah, has anyone experienced anything like this before? I've got a P1 in with Veeam support but I’m also trying to explore any events that could be related.

BTW on the backup job front, hardly anything was running, a couple of object offloads, of which the VBR server doesn’t perform any offloading, and a couple of NAS Backup jobs, which again, repo & proxy roles are on the physical servers.

Thanks in advance :)