HTTP / FTP download timeout

[sames4239]

I was wondering if anyone had any ideas on what is wrong here:

I have noticed that when I start a download (HTTP or FTP) on any PC connected to the network, the download will timeout after about 2-3 minutes at about 3-5 meg downloaded. The download will either stop or will stop with the following error: The connection with the server was reset. I believe this is a problem with the router because it will not happen when the PC is directly connected to the DSL line.

The config:
I have a Cisco 1605 dual Ethernet router connected to a 768k DSL line and a Catalyst 2940 switch.

Troubleshooting steps:
I have this problem on all PC's and servers regardless of OS.

The problem goes away when the router is removed.

The problem only happens after about 2-3 minutes have passed and about 3-5 Meg downloaded.

The problem seems to be load sensitive. I have had a download go longer when there is no other load on the network. Introduction of any load will cause the original download to fail.

No errors show up when I do a sh int while doing a test.

It affects HTTP and FTP traffic only. SMTP and other don't appear to be affected.

The best way I can characterize the problem is that my router can't seem to adjust the connection to handle fluctuations in bandwidth or is preventing "control data" from making it back to the remote server to maintain the connection.

Any ideas would be appreciated.

Thanks,

Steve

 

[bierhunter]

Well, I haven't read anything yet about http (still looking into it though). Also, they don't recommend removing them, just not using reflexive. With nat in place, you should still be able to send ftp requests out, just not in.

If anything, you could change the ACL and see if anything changes, then change it back just for a test.

This is an interesting problem. I think we're all going to learn something when we find a solution.

BierHunter
CNE, MCSE, CCNP

 

[Nettekkie1010]

So really... what's going on here is:
1. Remote says send me SEQ 563 next
2. Local sends SEQ 563
3. Remote again asks for SEQ 563
4. Local sends SEQ 563
5. Remote again asks for SEQ 563
6. Local sends SEQ 563
7. Eventually the remote sends an RST.

Well, the remote is sending a RST because he never sees SEQ 563 from your machine. This means the issue is on the outbound side (from your PC) and only occurs after a certain amount of data has already been transferred.

Is it possible you're introducing the error when you install the router?
1. When you connect the DSL directly to the switch you are using a rollover cable correct?
2. When you connect the DSL to the router you must be using two straight-through cables, correct?

If you are using seperate cables you may have a bad one.

You should also verify that the switch port and router port agree on speed/duplex and that the router and DSL modem also agree on speed/duplex. You may try setting the switch port connected to the router for 10/H if it's currently AUTONEGOTIATE becuause that 1605 only does 10/H. I would try this first.

 

[sames4239]

I agree with the assesment.

1. This happens from all inside machines running Windows, Linux, etc.

2. The router was in for a long time before the problem arrived.

3. The DSL hits the outside VLAN of the switch, then another cable takes it to the router. Cables, duplex, etc. all have been checked.

Initially, I changed switches to eliminate the switch as a source of the problem. It was only after I removed the router, that the problem went away, after that I started looking at ACL's. The problem persists even with no ACL's. That's when I turned to Tek-Tips.

Thanks,

Steve

 

[Nettekkie1010]

When you eliminate the router how is the connectivity? Do you move the DSL to the inside VLAN on the switch so all PC's still have access?

When you conduct the test with the router removed are you generating the same amount of traffic as with the router in?

I expect you are but I don't like to assume anything.

 

[sames4239]

Yes and Yes.

Thanks,

Steve

 

[sames4239]

Issue resolved -- Lessons learned:

I finally have this issue resolved and the solution comes from an unexpected source. This router was connected to a used Cisco Catalyst 2924XL. I have noticed errors on the switch and it appears that the switch engine was failing. I changed out the switch and the download timeout problem also went away.

I want to take a moment and thank the folks that have spent time helping me work on the problem.

Thanks,

Steve

PS I have a used Cisco Catalyst switch in "As - Is" condition for sale.

 

[sames4239]

Well I spoke too soon. The problem persists on the new switch. I have another router (Cisco 2161 dual Ethernet router with 64/16MB RAM) on the way. I'll get it up and running soon and I will see if the problem persists.

Thanks,

Steve

 

[Nettekkie1010]

On the switch port the router is connected to issue sh int <switchport> and look for operational speed and duplex. My guess is they don't match the router!

You have a duplex mis-match most likely!

 

[sames4239]

I checked that. The switch is connected to a Cisco 1605 and is set to 10-Half.

 

[fynx]

Reflexive access lists are notoriously bad news for FTP.

They should only be used for applications that use a single data stream, like telnet.

A reflexive access list creates a dynamic permit entry when a session is initiated from the internal network - during that session the r-acl checks many features of each packet header in that session to ensure they are indeed part of the same session. If ANYTHING is amiss IOS will drop the packet.

I suggest logging the relexive access list entries (just add logg to the end of the access list config lines) and see if you can spot the packets being dropped by IOS when you have the problem. If this is the case you may want to consider changing the reflexive access list for FTP to a static acl.

Good luck,
Phil.

If everything is coming your way then you're in the wrong lane.

 

[Nettekkie1010]

What about this?

Some applications change port numbers within a session. They may initially transmit to a well-known port and then shift ports. This will not work with RACL's. Active FTP is an example of such an application. You'll need passive FTP if you plan on using reflexive access lists.

 

[sames4239]

Both are good points and I will look at both. One additional point here -- it happens on HTTP downloads as well. It is not limited to FTP.

Thanks,

Steve