cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4652
Views
15
Helpful
15
Replies

FTP very slow from remote site

CiscoPurpleBelt
Level 6
Level 6

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?

3 Accepted Solutions

Accepted Solutions

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

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

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

15 Replies 15

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. <<

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.

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
Hall of Fame
Hall of Fame
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?

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.

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.

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

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?

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.

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!

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))...

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.

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 ?

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!
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: