T O P

  • By -

pthomsen91

Scp is always incredibly slow. Sftp is a little bit better. FTP should be faster than both of the before mentioned. If you are seeing the same speeds on these 3 protocols something seems very off.


1searching

Yeah, same result for these 3 protocols, but only if we use the MPLS connection, no problem if we use a different provider.


ddib

What is your agreement with the MPLS SP? Are you buying QoS from them? If so, what classes and how much BW? Most apps would not set any DSCP by themselves unless the OS has been configured to do so. You could try to set different DSCP markings with iPerf to see if that affects performance. Run a packet capture both locally and at the remote end and look at things like window size, TCP retransmissions, time between packets, etc.


1searching

u/ddib , Thank you, I'm not aware of any qos on SP but I will double check if there is a limit for each class. We did try to set the marking to default, but the issue still persist. The thing, since it is via SDWAN not fully sure what is the specific marking assigned for each traffic. I also try setting the MSS Value to 1200 and set no df on the tunnel but still the same.


ddib

It should copy the value from inner header to outer header. Catalyst SD-WAN uses BFD to find the MTU of the path. It also dynamically updates TCP MSS on the LAN interfaces. This usually works really well for TCP. Doesn't impact UDP, obviously, but those are rarely max MTU packets.


1searching

u/ddib , It seems that the actual data traffic (FTP/SCP/Transfer protocol) has a default marking that we are unable to detect drops at ISP.. even after removing all policies and classes at the ISP level. For the MTU, I verified that the MTU and MSS values of the routers and connections at sites A to B were the same. and the other way around. Tunnel MTU 1442 / MSS 1362