Solved: Re: FTP very slow from remote site

CiscoBrownBelt · ‎10-17-2017

We have a remote site in which is connected via GRE tunnel through 1 gig connections. Customer reported very slow transferring of gig files. Pings all transmit fast. Not sure whether to start looking into transport provider as the cause. Any ideas?

Joseph W. Doherty · ‎10-17-2017

Ok, if an EPL, it's possible your CIR could be gig, but something you want to confirm.

If gig, a 3925 (the non E model) might be a tad undersized as Cisco only recommends it for up to 100 Mbps WAN circuits (the 3925E is recommended for up to 250 Mbps). I.e. too much load might result in the router dropping packets.

If not gig, sending gig into an EPL with a lower CIR could result in drops.

Enough drops from either of the above may considerably slow a TCP flow, such as FTP transfer.

Also, as I see jumbo MTUs being used, if that's not done right, it too can create problems.

View solution in original post

Georg Pauwen · ‎10-17-2017

Is only FTP slow, or anything else as well ? If it is only FTP, it might be worth looking at the FTP clients and server. Which clients are your customers using, and which FTP server ?

View solution in original post

Joseph W. Doherty · ‎10-20-2017

Insufficient TCP RWIN on the receiver - it should support BDP.

Dropped packets.

If both of the above are okay, FTP should be able to transfer at line rate.

View solution in original post

Julio E. Moisa · ‎10-17-2017

Hi

Do you have any QoS applied? Is possible to know the GRE config?

>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

CiscoBrownBelt · ‎10-17-2017

My apologies looks like there is no tunnel. It is an EPL connection through the ISP. Netflow commands on the interface itself but yes there are QOS configs on the main hub device 6509.
It is a port-channel EPL to the other site:
on the 6509
mtu 9192
ip address X.X.X.X X.X.X.252
ip nbar protocol-discovery
ip flow ingress
ip flow egress
speed nonegotiate

On the remote edge 3925 router:
int g0/0
mtu 9192
ip address X.X.X.X X.X.X.X
ip flow ingress
ip flow egress
media-type sfp

I don't have much in depth knowledge about the devices the ISP uses in which there are about 2 more hops between these two devices.

CiscoBrownBelt · ‎10-17-2017

The interfaces the Port-channel is applied to isL
mtu9192
no ip address
speed nonegotiate
lacp rate fast
channel-protocol lacp
channel-group 1 mode active

that is it.

Joseph W. Doherty · ‎10-17-2017

Assuming a standard MTU of 1500, are you configured to avoid fragmentation across the GRE tunnel?

Is the actual available bandwidth (via the tunnel) also gig?

CiscoBrownBelt · ‎10-17-2017

My apologies looks like there is no tunnel. It is an EPL connection through the ISP. Netflow commands on the interface itself but yes there are QOS configs on the main hub device 6509.
It is a port-channel EPL to the other site:
on the 6509
mtu 9192
ip address X.X.X.X X.X.X.252
ip nbar protocol-discovery
ip flow ingress
ip flow egress
speed nonegotiate

On the remote edge 3925 router:
int g0/0
mtu 9192
ip address X.X.X.X X.X.X.X
ip flow ingress
ip flow egress
media-type sfp

I don't have much in depth knowledge about the devices the ISP uses in which there are about 2 more hops between these two devices.

Joseph W. Doherty · ‎10-17-2017

Ok, if an EPL, it's possible your CIR could be gig, but something you want to confirm.

If gig, a 3925 (the non E model) might be a tad undersized as Cisco only recommends it for up to 100 Mbps WAN circuits (the 3925E is recommended for up to 250 Mbps). I.e. too much load might result in the router dropping packets.

If not gig, sending gig into an EPL with a lower CIR could result in drops.

Enough drops from either of the above may considerably slow a TCP flow, such as FTP transfer.

Also, as I see jumbo MTUs being used, if that's not done right, it too can create problems.

CiscoBrownBelt · ‎10-20-2017

Awsome! Yes I have to take a look at the interfaces to see what is going on more with the traffic.

CiscoBrownBelt · ‎10-20-2017

Let's say router and the entire patch through the WAN is good in regards to MTU/Jumbo framing and we still are experiencing slow or dropped FTP transfers, what may be the problem you think?

Joseph W. Doherty · ‎10-20-2017

Insufficient TCP RWIN on the receiver - it should support BDP.

Dropped packets.

If both of the above are okay, FTP should be able to transfer at line rate.

CiscoBrownBelt · ‎10-20-2017

Yes the router is just too old and this has to have been a long time problem (I'm new and short-handed :)). I am preparing replacement. Thanks guys!

Georg Pauwen · ‎10-17-2017

Hello,

in addition to Joseph's and Julio's post, for pure GRE tunnels, the recommended MTU setting is 1476 (ip mtu 1476).

You could also try and configure PMTUD (configure 'tunnel path-mtu-discovery' on the tunnel interface(s))...

CiscoBrownBelt · ‎10-17-2017

My apologies looks like there is no tunnel. It is an EPL connection through the ISP. Netflow commands on the interface itself but yes there are QOS configs on the main hub device 6509.
It is a port-channel EPL to the other site:
on the 6509
mtu 9192
ip address X.X.X.X X.X.X.252
ip nbar protocol-discovery
ip flow ingress
ip flow egress
speed nonegotiate

On the remote edge 3925 router:
int g0/0
mtu 9192
ip address X.X.X.X X.X.X.X
ip flow ingress
ip flow egress
media-type sfp

I don't have much in depth knowledge about the devices the ISP uses in which there are about 2 more hops between these two devices.

Georg Pauwen · ‎10-17-2017

Is only FTP slow, or anything else as well ? If it is only FTP, it might be worth looking at the FTP clients and server. Which clients are your customers using, and which FTP server ?

CiscoBrownBelt · ‎10-20-2017

Sorry I have been out in the field past two day. I am not sure I have to do more testing and verify the sources. I will get back to you. Thanks!