We have a fwsm (FWSM Firewall Version 3.2(2) with multiple VLANs configured. We have a server on one of the VLANs with the ip say 192.168.1.1. Backup of servers on othre VLANs are taken on this serer and hence we have opened the port range 22000 22009.
The problem we are facing is that for on of the server in one of the VLANs backup fails frequently and this needs to be solved by using the command "clear xlate local 192.168.1.1". Backup of other servers in the same VLAN happens without much problems.
Once cleared the backup works fine. Can anyone provide a solution for this.
It is posiable that xlate table might be full because of a long time out or huge traffic. Do one to one NAT the the same IP address for example if the server IP address is 18.104.22.168 do NAT with the same IP address as NAT is mandotary in PIX.
If your are using the ASA version of IOS in FWSM then use the "no nat-control" to remove the NAT mandatory.
Im having the exact same issue, FWSM (3.1(3)4) Randomly a server will stop responding. Viewing the xlate at the time of impairment seems to always show 3 duplicate xlate entries. I clear the specific xlate and continue for a few more days or weeks. I have provided cisco much detail on this and havent had any luck with the TAC. Im hopeful that the new xlate bypass feature will fix this. After being burned w/ FWSM upgrades in the past Im waiting for the safe harbor release scheduling to begin testing soon.
Thanks for the advice Chris, but the current timout is alread configured for 3 only (timeout xlate 3:00:00). Did a few analysis and was able to find more details:
We have a fwsm (FWSM Firewall Version 3.2(2) with multiple VLANs configured. We have a server (say BACKUPSERVER.DOMAIN.COM) on one of the VLANs with a security level 98. Backup of servers on other VLANs are taken on to this server and hence we have opened the port range 22000 22009.
The problem we are facing is that for one of the server which is in a lower security zone compared to BACKUPSERVER.DOMAIN.COM backup fails frequently. However clearing the xlate table using the command “clear xlate local ipaddress_BACKUPSERVERDOMAINCOM” resolves the issue and the backup initiates and is completed successfully. This shows that the configuration (ie. access-lists and nat statements) in place are correct.
Backup of other servers which are in higher security level is also being taken. But this is completed successfully without any issues.