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

PIX doesn't drop connections, CLEAR XLATE is temporary fix

I am new to the forum, looking for some help on several problems. First, my toughy...

We recently replaced a PIX Classic (ver 4.4(7) with a PIX-520 (ver 6.1(1), and also changed ISPs at the same time. One of our internal servers pulls weather web pages from a local TV station's website. Our server always initiates the connection, and it is always against port 80 on the external site. The strange thing is that the PIX builds a connection (which shows up as expected with the SH CONN command, but doesn't always drop it. Further, when the internal server goes to get the page again (each user request triggers this), the PIX will sometimes create a new connection instead of re-using the one it already has open. This can go on until there is 15 or more connections going, and SH CONN shows all of them destined for port 80 on the external server.

Now, this is the strange part. Each connection STAYS ACTIVE, and shows an extraordinary amount of data transferred, with none of them idle for more than 20 seconds. It almost seems that these concurrent connections are transmitting the same request, and getting their own response from the external server. The end result is that every 2 business days, these connections "run away" to the point where they are flooding the internet connection to the point where no other traffic can pass. The internal server doesn't appear to be overly taxed (it is a simple Pentium II clone) when this is happening.

All I do to cure the symptom is to do a CLEAR XLATE LOCAL X.X.X.X (where x.x.x.x is the internal server). This closes the connections, and traffic drops immediately to expected levels. One connection reopens almost immediately, but others don't start for awhile (could be 1 hour, could be 10 hours). Again, it increments upward through the next two business days until the same thing happens.

I thought that a static translation would help, so I installed one this week. It doesn't. Same thing happens in the same timeframe. I reduced the connection timeout from 1 hour to 15 minutes (timeout conn 00:15:00). We have the XLATE and UAUTH timers set at 8 hours so users don't get prompted more than once a day. I ruled this out as a cause when I set up the static xlate mapping.

I feel certain that it's a config issue, although I am using the latest greatest software (which normally isn't a good idea). I'd sure look forward to some feedback. Thanks in advance!

2 REPLIES
Silver

Re: PIX doesn't drop connections, CLEAR XLATE is temporary fix

Well your comment about the latest and greatest not being a good idea is certainly good advice. Maybe you’ve found a bug.

Keep in mind, it’s not uncommon for a web browser to open 15-20 connections through a PIX. Browsers nowadays thread their http gets primarily to handle multiple browser windows. I’d be interested in a sniffer trace on the wire to see what is really happening or at the very least a debugging level log file. Maybe the server outside is so busy, it doesn’t reply until the PIX closes the first connection state and so the inside host sends another request (or repeated attempts) each building a new connection through the PIX.

Are there any strange inbound denies happening during these events showing up in the PIX debugging logs? There’s some places for you and the TAC to look over.

New Member

Re: PIX doesn't drop connections, CLEAR XLATE is temporary fix

Actually, I opened a case with TAC and they helped me work through some things to find out more of what is going on...

So, I've got an *updated* question for everyone now!!

I found out that it is one NT intranet server that is the culprit. The PIX was actually doing exactly what it was supposed to do. The trouble is that the server is opening these connections, then transmitting requests across all of them. The funny thing is that it is requesting the data from one external server, and the same port.

It's obvious now that we have a misconfigured web server causing this. I guess my question turns to more of an NT/web question (which I know os outside of this forum's scope, but anyway...

I need to get with the server admin of this server (who inhereted the server 6 months ago, after the specific page was set up) to solve the problem. Does anyone know of hints, on pitfalls that may occur when configuring a web server to not properly build and close connections?

So you're aware of my workaround, I set up a scheduled job on one of our Unix machines to log in and do a CLEAR XLATE LOCAL x.x.x.x (where x.x.x.x is the internal server's address) at 7pm each night. This clears the conections, and then the traffic immediately falls to expected levels. By the end of the next day, the server is yapping away again.

I also went ahead and set up another job to log off users, with the CLEAR UAUTH command, at 8pm each night. We have our UAUTH timeouts set high at 12 hours (due to political pressures, moreso than technical wisdom).

Anyway, if anyone has insight on the new twist of my problem, I'd sure appreciate you jumping in!

467
Views
0
Helpful
2
Replies
CreatePlease to create content