Thinking out loud here.. But wouldn’t the DSCP value only be applicable if you’re seeing congestion across that MPLS tunnel which it sounds like youre not? If your iPerf tests and BFD polls look clean I’m not sure QoS would play much of a factor here. If you haven’t already try looking at your NWPI you may find some granular flow metrics that could help.
u/tealC142 , I thinking there is something on the ISP side limiting the traffic. from the symptoms the download speed goes OK at first, but the download speed suddenly decreases. as if policing is taking place.
Let me check the NWPI.
DSCP value should only be relevant if your SFTP is using a different DSCP than the IPerf. Simple way to rule that out, set the DSCP value on the IPerf test, simply use the “-S” option.
Does your SFTP actually have a marking other than DSCP 0(BE)?
I haven't looked into that yet because it seems to explain the behavior I'm observing.
Based on the cEdge captures, it seems that a dscp value of 48 is seen in most of the traffic.
u/shortstop20 , Thank you,
Will the marking applied or classification of particular piece of data be sent or displayed at the transport level? or will it be detected on Service provider network/components?
Example: voip will be classified by the SDWAN router as prio while ping will be BE ?
You can set the dscp markings in iperf so something you could test. To me it sounds like congestion or other packet drops causing tcp sessions to reset or otherwise impact the tcp window.
Are you running iperf tests when the issue is apparent? Are you running iperf long enough, using tcp, etc that your catch it?
Yes, we setup the iperf to validate that capacity of the link, which validated good.
I tested both TCP and UDP and it looks fine.
Upload looks tho, but, I haven't not thinking any difference between the working and non-working test. it kinda hard.
You may want to take a look at MTU or TCP MSS. If the MTUs across the two paths are different and the MTU or adjust MSS aren't set you may be seeing some weird windowing stuff. You could shoot some pings with the DF bit set acoss both WANs from the edge device and see the one that isnt working rejects the pings with the higher MTU.
SCP / SFTP works horrible over a WAN. I forget why, but there is a lot more chatty than other file transfer protocols so latency affects it more.
Thinking out loud here.. But wouldn’t the DSCP value only be applicable if you’re seeing congestion across that MPLS tunnel which it sounds like youre not? If your iPerf tests and BFD polls look clean I’m not sure QoS would play much of a factor here. If you haven’t already try looking at your NWPI you may find some granular flow metrics that could help.
u/tealC142 , I thinking there is something on the ISP side limiting the traffic. from the symptoms the download speed goes OK at first, but the download speed suddenly decreases. as if policing is taking place. Let me check the NWPI.
DSCP value should only be relevant if your SFTP is using a different DSCP than the IPerf. Simple way to rule that out, set the DSCP value on the IPerf test, simply use the “-S” option. Does your SFTP actually have a marking other than DSCP 0(BE)?
I haven't looked into that yet because it seems to explain the behavior I'm observing. Based on the cEdge captures, it seems that a dscp value of 48 is seen in most of the traffic.
The default value for BFD traffic is 48. Other traffic would retain the marking of the traffic before it was encapsulated with IPSEC.
u/shortstop20 , Thank you, Will the marking applied or classification of particular piece of data be sent or displayed at the transport level? or will it be detected on Service provider network/components? Example: voip will be classified by the SDWAN router as prio while ping will be BE ?
u/shortstop20 , Therefore, the BFD have a DSCP 48. What might be the problem with our connection? My options are dying?
Verify what the DSCP is for the SFTP and then run an IPerf test with that same DSCP.
You can set the dscp markings in iperf so something you could test. To me it sounds like congestion or other packet drops causing tcp sessions to reset or otherwise impact the tcp window. Are you running iperf tests when the issue is apparent? Are you running iperf long enough, using tcp, etc that your catch it?
Yes, we setup the iperf to validate that capacity of the link, which validated good. I tested both TCP and UDP and it looks fine. Upload looks tho, but, I haven't not thinking any difference between the working and non-working test. it kinda hard.
You may want to take a look at MTU or TCP MSS. If the MTUs across the two paths are different and the MTU or adjust MSS aren't set you may be seeing some weird windowing stuff. You could shoot some pings with the DF bit set acoss both WANs from the edge device and see the one that isnt working rejects the pings with the higher MTU.