800 series xDSL causing FTP re-transmissions

[gurner]

I have a very strange situation with an 800 series, which i have been trying to diagnose on the TCP/IP forum as it appears to be an MTU issue.

I have managed to prove that it sems to be being caused by the 800 series and not the workstations

the following is what i have been trying

http://www.tek-tips.com/viewthread.cfm?qid=1059287&page=1

but in summary

------------------------
Have a strange situation where a user can download from any FTP server, but when they try to upload it used to take ages, now it just fails.

I've tried 'hash' to display progress and it does about 5-10% of a 20K file, for example and then sticks, and eventually disconnects.

I have checked the routers and Proxy and there are no access lists blocking FTP, as you can FTP in and then do Dir, which covers port 21 and 20. although, downloading is fine as well.

and the Proxy is in caching mode only, so is not performing and packet filtering

However, running Ethereal reveals shortly after the put command, and a short burst of transfer, Ethereal logs continuous re-transmissions

I have tried changing the MTU on a workstation but to no joy

fortunately there is a failover situation in place where each site within the organisation has an ADSL router and a WAN router.

Using HSRP the WAN router holds the Access-Lists and priority routes traffic over either the WAN or ADSL dependant on its destination.

0.0.0.0 is routed out via ADSL to the t'internet and anything on the internal subnet 10.0.0.0 255.0.0.0 is routed via the WAN to other sites.

Changing the MTU several times made no difference, but i noted it was going out via the ADSL everytime (as it should)

but i added a static route to the WAN router to forward packets destined for the IP of the FTP server via the Frame

did an FTP and it worked everytime, so something about the ADSL router is changing the packets for the worse.

---------------

cheers

Gurner

http://www.divineparadox.co.uk

 

[gurner]

Turns out the WAN router was the cause, it was down to the Duplex speed, the WAN router was running at full and the ADSL was running at half.

alright now.

anyone now in easier to understand language than i can figure why this would be an issue?

ADSL is running PPoA, WAN is over Learning Stream, both are 1500MTU (which explains why the MTU changes on the workstations made no difference)

cheers

Gurner

http://www.divineparadox.co.uk

 

[Cluebird]

ADSL was following CSMA/CD rules and WAN was full-duplex which disables collision circuitry. When one is talking full-duplex and the other is half-duplex, the half-duplex side sees lots of collisions while the full-duplex side is unable to detect collisions. The half-duplex side keeps trying to get frames on the wire, detects a collision, goes through back-off, and has to try to retransmit up to 16 times and finally drops frames trying to service buffers. Meanwhile the FTP program is trying to reassemble the data stream and can't so uses the control channel to constantly request the lost UDP packets which eventually overwhelms the transmission and appears to "lock-up". Since FTP uses UDP for the file transmission, reliability for the transmission occurs at the application level. If you could use TCP, the file transfer would eventually take place, but it would be extremely slow and possibly time-out from the server side.

Half-duplex and full-duplex (duplex mismatch) gets very ugly especially with UDP.

 

[gurner]

kinda suspected that but couldn't really put it across verbally as couldn't be sure it was the exact cause, certain it is now, cheers

definatley helps

Gurner

http://www.divineparadox.co.uk