Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

xlate entries don't timeout

We have a fairly simple config on a PIX 515, using the following timeout values:

timeout xlate 0:45:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

I'm finding that xlate entries never timeout, leading to a continual increase in the xlate table (last seen at 14K entries - for only 300 or so clients). We use NAT for most connections, with only a couple of static values, but have a single address put aside for PAT - which is getting hammered. What am I missing?

4 REPLIES
Gold

Re: xlate entries don't timeout

Hi Pete,

Have you done a clear xlate and see what happens? do the xlate still not time out?

Jay

New Member

Re: xlate entries don't timeout

Yep, clear xlate is a regular entry from command line here, and it does work. It was last run around 4 hours ago, and we're already back up to over 760 xlate values, mainly on the PAT address. I also have documented xlate entries that persist (although idle) well past the theoretical 1 hour 45 min limit set by the conn + xlate timeouts

Pete

Gold

Re: xlate entries don't timeout

Hi again Pete,

okay, clear xlate works.. just a thought can you change the xlate timeouts to the pix default (or have you already tried this) i.e.

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si

p 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

and re-boot the pix to see if this helps.. also if you can post the config (excluding pass word + IP etc).

TIA - Jay

New Member

Re: xlate entries don't timeout

Jay:-

We started with the defaults, and I've been trying to reduce it down. At the moment, a reboot would not go down well - delivery schedules etc are looming rather heavily. And internal policy prevents me from releasing the config.

However, rather than looking at the symptoms, I've been addressing the cause - it seems that many of our nice new WinXP boxes have been confgured to ask for NTP synchronization from outside of the building, so I've been going round amending this and then run a clear xlate. Things are not getting any worse, so that may be all that is necessary to prevent the overload. This means that the NAT addresses won't be over-stretched for what should be an internal function, leaving space for the real connections to take their place. We ought to have more than enough NAT addresses for the necessary functions (web proxy, SMTP, DNS servers etc).

If this works, the problem won't exist any longer, although I'd like to understand why the slots weren't being released. In any case, thanks for the help and suggestions - if/when the opportunity arises, I will reload with default setting again and see how it goes.

Thanks

Pete

168
Views
0
Helpful
4
Replies
CreatePlease login to create content