cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
419
Views
5
Helpful
4
Replies

Huge amount of phantom UDP connections

gmassen
Level 1
Level 1

Hello,

I noticed a huge amount of connections shown by our PIX (running 6.3(3)). They are all connections apparently due to DNS traffic. From "show conf":

UDP out 65.110.41.70:53 in 158.64.1.14:2656 idle 0:00:05 flags -

(several thousands)

158.64.1.14 is our DNS server. What the DNS server is querying looks like this:

11:31:33.291565 158.64.1.14.kana > 65.110.41.70.domain: 3774 [b2&3=0x10] [1au] A? new.awjicomfort.com. (48) (ttl 64, id 42281)

The DNS Server that is queried is not responding to anything, so it would be normal to have idle UDP connections, but the amount is not anywhere near to what it should be.

A rough count gave me that the DNS server is sending queries to the outside server at a rate of approx. 4 queries per second (different queries to the same server). However the show connections show rather 50 connections whithin one second (based on the displayed idle time).

Does anyone know where this difference comes from? I have ca. 65000 phantom connections, due to the 2 DNS servers querying the same host.

Edit: UDP timeout is set to default (0:02:00)

Gilles

1 Accepted Solution

Accepted Solutions

scoclayton
Level 7
Level 7

Gilles,

Looks like a known issue - CSCec45748 - New DNS conns reset the idle timer of previous DNS conns.

The crux of the problem (as you can see from the title) is that the idle times from existing DNS conns are reset when new DNS conns are established. Suggestion at this point would be to go ahead and open a TAC case and get the latest 6.3(3) build. This problem has been fixed and verified. Sorry for the problems.

Scott

View solution in original post

4 Replies 4

scoclayton
Level 7
Level 7

Gilles,

Looks like a known issue - CSCec45748 - New DNS conns reset the idle timer of previous DNS conns.

The crux of the problem (as you can see from the title) is that the idle times from existing DNS conns are reset when new DNS conns are established. Suggestion at this point would be to go ahead and open a TAC case and get the latest 6.3(3) build. This problem has been fixed and verified. Sorry for the problems.

Scott

Thanks Scott, that looks pretty much like it. And no reason to be sorry: only if it was not fixed you should be :).

One (only slightly related) question: are the latest builds available on CCO or do I have to open a case? (I have access to the software images but can only find the 6.3(3) built from August 2003).

Regards,

Gilles

Gilles,

I guess bugs are a fact of life in software though we certainly try to make our stuff as "bug free" as possible. Thanks for your understanding.

6.3(3) is the latest build available on CCO (as you have seen and is also what you have). PIX development works by fixing bugs as they come in. Every few weeks or so, we roll all of the fixes up and create what we call an "interim build." These look like '6.3(3)110' for instance. The interim releases are minimally tested as a sanity check but are not run through our normal QA hard core testing. Every few months (or more), we generate a new maintenance release that does go through the hard core QA testing. These releases look like '6.3(4)'. We are planning to do a 6.3(4) release sometime in the May/June timeframe. So, if you need a specific fix before the maintenance release is available, you will need to open a TAC case, give them the bug ID, and request the latest interim build.

Hope this helps explain a little.

Scott

Scott,

it explains it fairly well. Thanks again.

Gilles

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: