• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Cisco 1811 - FTP PAT stops working at random

bobdole369

Diamond Member
I'm no CCNA, not even a CCNP, just have read a few books, replaced a few, and configured a few and am familiar enough to cause trouble with IOS.

Is there some sort of limit on the number of PAT's I can set up? I've got about 30 or so in this device (an 1811). Most of the traffic is ftp - its primary purpose is to route in small data packets that come in from clients from around the world (not ftp). The actual amount of traffic is very small, its like 10k every 15 minutes from about 30 different sites. So I've set up FTP through it for a couple users in my office. Now I've added another site, and this time the FTP just randomly stops working. It's not the server, its not bandwidth, the router is still functioning, its just ftp that stops. In fact I RDC through it to log in to it and reload. Once reloaded everything works perfectly again, until ftp randomly stops.

Any debugging that someone could suggest? As of now I've concatenated a few things and whaddaya know - been up all night.
 
My guess is you're running out of translations, especially if you're PATing a single IP address to the FTP server. You can run the command "show ip nat statistics" and look for incrementing misses.
 
As of now I've concatenated a few things and whaddaya know - been up all night.

Failed. It was up about 8 hours before stopping. I have nagios logging in every so often so I can get within a minute or two of when it drops off.

I'm not running out of addresses, it's PAT. I'm not overloading these, its a straight 1-1 translation. I DO however have a couple overloads on those same IP's, but they are for client PC's, and they are not affected when it happens.
 
Last edited:
Here ya go:



Drawing1-2.png
 
Now I've added another site, and this time the FTP just randomly stops working.
Did the problem exist prior to adding the site?

It's not the server, its not bandwidth, the router is still functioning, its just ftp that stops. In fact I RDC through it to log in to it and reload.
When it "stops functioning", have you tried logging into the FTP server from the LAN side?

Once reloaded everything works perfectly again, until ftp randomly stops.
Are you reloading just the 1811 or the 1811 and the FTP server?

I've had a problem with the Internet just dying on me after a while on a PIX 501 but that was due to a license issue where you could only have so many clients behind the PIX.
 
When it "stops functioning", have you tried logging into the FTP server from the LAN side?

Yes. The ftp server never goes down.

Are you reloading just the 1811 or the 1811 and the FTP server?

Just the 1811. ssh into either side, issue command "reload", wait one minute, then I receive the email from nagios telling me its back up. Or I just keep hammering the ftp site until it connects. Either way as soon as the router reloads, it starts working again.

Did the problem exist prior to adding the site?

This is actually something I've been fighting for some time now. Note that the 3389-3390 mapping on the same host works just fine when the "issue" occurs. Its only ftp that is affected. FTP was quite stable for a number of weeks, then I added the 111.190 -> 244.174:3389 translation. Within 4 hours it was back to its old tricks.

So good troubleshooting sense says to take out that newest 3389 mapping right?

I think my short question is answered (by lack of response from everyone) that there is no hard and fast "you can only have xxx translations" rule that I've broken.
 
You're running out of translations. Seen this many times. When you reboot you're clearing the translation table. If you want to test do a "clear ip nat trans *" instead of rebooting.

A workaround would be to lower the translation timeout with "ip nat translation tcp-timeout"
 
Google is my friend:

• Configuring translation timeouts
ip nat translation timeout <seconds>
Dynamic translations time out after a period of non-use. When port translation is not configured, translation entries time out after 24 hours. This time can be adjusted with the above command or the following variations:
ip nat translation udp-timeout <seconds>
ip nat translation dns-timeout <seconds>
ip nat translation tcp-timeout <seconds>
ip nat translation finrst-timeout <seconds>
When port translation is configured, there is finer control over translation entry timeouts, because each entry contains more context about the traffic using it. Non-DNS UDP translations time out after 5 minutes; DNS times out in 1 minute. TCP translations time out after 24 hours, unless a RST or FIN is seen on the stream, in which case it times out in 1 minute.



This makes sense. The app the 3 specific machines with similar mappings are on are from ocean-going yachts, typically with sat connections. Not at all unheard of to have >50&#37; packet loss from them. Missing a FIN or RST is not at all uncommon.

Also the ftp is used most often by folks verifying a folder full of small files. So if I miss a RST its stuck there for a whole day. Hmmm, next time it happens I'm running: sh ip nat translations first and finding the offender, if this is indeed the case.

Thanks a TON AT!

Also
 
Last edited:
Unfortunately this did not resolve the problem. This morning at 5:38a the ftp stopped responding. I sshed to the router and ran sh ip nat trans which showed me a total of 26 UDP port 53 dynamic translations (dns server), and 5 tcp's and 4 udps from a PC running skype. I have a single port 80 translation from the ftp server which is an update check.

SO a total of 35 dynamic translations. I ran clear ip nat trans *, which cleared all the dynamic ones out, within a few minutes I had another 48 dns entries (the DNS for my office of 50 or so folks runs out of here so no surprise there). But the ftp server remains down. Connecting to it yields a timeout through the router, and locally it works fine of course.

Normally when connecting I would see the translation come up, but more than anything it looks like the packets are being dropped on the wan side of the router.


Now that I have time to actually look at it while its down I'm noticing that none of the PAT's in place are working. It's not just ftp, but anything defined via: ip nat inside source static yada yada yada.
 
Last edited:
It could be an IOS bug. Unfortunately the 1811 is one of those routers that is still stuck on bleeding-edge IOS trains. I'm not sure what you are running now but I'd recommend trying 12.4(15)T11 for stability.
 
I agree, it does sound like the Cisco router is misbehaving. If possibly, try to swap the Cisco router out with a known-good router, just to make sure that it's not the FTP server itself having a problem. If swapping it out resolves the problem, contact Cisco tech support and have them help you.
 
Update:

Upped IOS to 12.4(24)T advipservices

Issue recurred.

Heres the really really funky part.

I added 2 more remote desktop PAT's - now the problem happens to them, but not the ftp anymore. In fact I now have over a week of uptime on the ftp.

W.T.F.
 
I have 2 Cisco 2811 routers on one data circuit and both are losing their static NATs to FTP servers. I have ICMP open too and when FTP drops the external IPs are no longer pingable.

We just changed data circuits and oddly this never happend with the exact same config on the other ISP.

If I find a solution, I'll be sure to update the thread.
 
Back
Top