Have just recently rebuilt our Dude - V7.4 - and have noticed an issue that has actually plagued us for a long time, but we misdiagnosed it.
Just to pre qualify - Dude on CHR - P1 License, 4 Xeon Silver vCPU @ 2.1ghz, 2Gb Ram (generally 1gb free). 64GB hdd, 59.2GB free (now actually removing data - last version delete error filled hdd, ruined the DB) - Total DB Size - 760MB running
So, the Last server we had had a direct route to LAN. It was on our old dmz and our office core was also on the dmz.
We would get reported Client RX to Dude Client of 30+mbps - opening in seconds. When we were out of the office, using vpn - getting up to 10mbps, quickly dropping to 1-2mbps. taking about 45+ seconds to open. We just chalked this up to vpn.
This was the Misdiagnosis
New Dude however - is on our New DMZ - still in deveolpement. New DMZ is fully routed to the internet (no NAT) - as is New Dude. Our Core is yet to be moved to go via this connection. It will be on the DMZ, but direct PPP to our Routing stack - neither here nor there.
With New Dude in - we are now getting (in the office) 8-9mbps to dude, with the petering off to 1-2mbps. The link goes :
Dude Client (NAT) - Office - Access (PPP) - DMZ - Dude Server.
Access Router in a different City.
DMZ is BGP to Access.
BTests are as follows
DMZ - 990+ (direct gigabit)
Border (other side of access) can Btest 500+/500+ to dude (Limit of the Particular Fibre)
Office Core - 330+/100+ (limit of the particular fibre)
Dude Client on PC - 320+/95+ (limit of the Fiber minus Office Core overhead I guess)
BTest obviously used different ports - but these is no know limits in place in the stack. Apart from Office, No NAT - No Queues. DMZ is not yet firewalling (Dude does have it's own) - Only real NAT and Forwarding F/W is Office - but it has not chnaged that nat or firewall (in saying that - it is a different segment now so there are likely discrepancies)
Plugging direct to new DMZ returns the performance back to previous, 30+mbps burst reported, and loaded within seconds.
Unfortunately testing next hop at this stage means going well over 1600km's away - so I will be reserving that for lab or next visit - but I see no reason that anything should slow it down to that level.
If anyone has any info on how the "off premise" speed of Dude can be improved - I'd love to hear it. We will soon move to the DMZ, so office will improve - but we have other office and Site techs that although have lived with poopy performance, would love to get some better performance.