FTP kills our STUN

[mgorton]

MMM, we have configured 2 Routers over an HDLC link for IP and SNA traffic. It appears that when a prolonged and sizeable FTP is initiated the controllers on the remote end go screwy and have to be restarted and in some instances the line on the mainframe as well. The controllers are yonks old and will not accept local-ack from the Router. What we think is happening is that the FTP traffic is causing a delay with the Mainframe polling. I have tried traffic prioritisation but to no avail. Has anyone seen this before? or have any idea what could fix this? A sample config would be truly marvellous

[vcjones]

Traffic prioritization should be the solution to this problem. Are you sure that it is set up correctly and actually putting the STUN traffic on the link first?

It is also possible that the HDLC link is slow enought and the SDLC timeouts are short enough that they cannot tolerate the delay imposed by a single maximum length FTP data packet (which would prevent the use of prioritization from saving you). In this case you would need to either speed up the line, sysgen your frontend to increase the T1 timer, or (assuming neither of those is an available option) decrease the size of the FTP data packets.

To decrease the size of the FTP data packets, you could force a smaller MTU on the link (but that could break SDLC if it is configured to use large frames) or use the real time features of multilink PPP to interleave the STUN traffic within the individual FTP packets.

Disclaimer: You need to determine exactly why you are in trouble before picking a way to get out of trouble. Otherwise you could waste a lot of time and effort (and money if upgrades are required) and still find yourself with a broken network.

Good luck and have fun!

Vincent C Jones

www.networkingunlimited.com