PIX all of a sudden can't handle dns traffic

PIX all of a sudden can't handle dns traffic

NewsGroups | Search | Tools
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
PIX all of a sudden can't handle dns traffic jlm33990 01-30-2006
Posted by jlm33990 on January 30, 2006, 3:16 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Brand new to PIX. Here's the story...
pix 515e running 6.3(5)
Box will freeze from time to time and won't pass/handle new dns
requests. IP traffic is still ok if you use ip# only. Host names will
not resolve. Clear local will fix the problem. I don't have any rules
or statics for dns.
Inside clients point to an internal solaris named box for resolution
who will pass request to isp if he doesn't have answer. Another fix to
the problem is if I change my pc's resolver from the solaris box to the
isp's dns.
I've been running a solaris based firewall for years in the same
environment and never had such a problem.(if I put the solaris firewall
back in place the problem goes away)
One minute I think there is something wrong with the pix because a
reboot or clear local will fix the problem and the next minute I wonder
if there could be something wrong with my named server because, as I
said, if I point to the isp's dns servers the problem goes away. No
changes have been made to the internal named server.
I can see from syslog that the dns udp teardowns that normally take 1
second all of a sudden take 2 minutes when the problem happens. I've
looked throught the log around the time that happens and see nothing
suspicious.
Any ideas - I'm going insane
thanks...jim


Posted by lfnetworking on January 30, 2006, 6:05 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
try messing with this command

fixup protocol dns maximum-length <bytes>
512 is the default

jlm33990 wrote:
> Brand new to PIX. Here's the story...
> pix 515e running 6.3(5)
> Box will freeze from time to time and won't pass/handle new dns
> requests. IP traffic is still ok if you use ip# only. Host names will
> not resolve. Clear local will fix the problem. I don't have any rules
> or statics for dns.
> Inside clients point to an internal solaris named box for resolution
> who will pass request to isp if he doesn't have answer. Another fix to
> the problem is if I change my pc's resolver from the solaris box to the
> isp's dns.
> I've been running a solaris based firewall for years in the same
> environment and never had such a problem.(if I put the solaris firewall
> back in place the problem goes away)
> One minute I think there is something wrong with the pix because a
> reboot or clear local will fix the problem and the next minute I wonder
> if there could be something wrong with my named server because, as I
> said, if I point to the isp's dns servers the problem goes away. No
> changes have been made to the internal named server.
> I can see from syslog that the dns udp teardowns that normally take 1
> second all of a sudden take 2 minutes when the problem happens. I've
> looked throught the log around the time that happens and see nothing
> suspicious.
> Any ideas - I'm going insane
> thanks...jim
>

Posted by jlm33990 on January 30, 2006, 6:32 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
I thought of that but dismissed it thinking how could a simple dns
request be more than 512 bytes - plus all dns stops - not just large
requests.
But it's worth a shot - I'll try messing with it and see what happens -
i"m desperate. Thanks for the input....


Posted by Dom Wilkinson on February 15, 2006, 10:47 am
If you were  Registered and logged in, you could reply and use other advanced thread options
This sounds like the symptoms of a known bug:

CSCsc61300 CPU increases with high volume of DNS requests using same
four-tuple.Here is list of all bugs recognised since the release of 6.3(5)
and there associated 'patch' versions:Note there is no 102 6.3.5.100/
30-Aug-2005 05:59 - CSCsb53549 VAC+ may cause interface to stop
passing all trafficCSCsb53760 Port redirection for DNS traffic does not work
correctly. 6.3.5.101/ 07-Sep-2005 02:23 - CSCsb71315 URL
Filtering with long URLs could cause memory corruptionCSCsb75773 Malformed
HTTP GET request causes URL filtering module to cause a crash. 6.3.5.103/
11-Oct-2005 22:59 - CSCei63244 Traceback with lu_rx thread name in
failover mode.CSCsb48916 Manual ipsec fail when esp-aes-256 specified with
authCSCsb68431 names can turn off on startup, possible configuration
lossCSCsb79761 Backspace sent in cut-through proxy authenticationCSCsb91253
SIP: PIX does not parse the expire value in Register 6.3.5.104/
09-Nov-2005 03:19 - CSCef19560 PIX - show uauth doesnt display users
with space in usernameCSCsb79609 SIP: PIX does not update BYE embryonic's
timestamp.CSCsb87382 SIP: Stanby PIX show the wrong value of xlate timeout
for sip media.CSCsb91279 SIP: Standby PIX set unusual value of conn idle
time.CSCsc23638 duplicate xlates on stateful standby due to static
misconfigurationCSCsc25386 Higher metric OSPF external route is
selectedCSCsc39368 PDM with Command Authorization requires the write command
for Read-Only 6.3.5.105/ 01-Dec-2005 00:08 - CSCsc36311
OpenSSL lib can be forced to negotiate the SSL 2.0 protocolCSCsc44193 ftp
fixup drops ftp server response packetsCSCsc49665 SIP : Large number of
static PAT cause delaying of RTP packetsCSCsc53472 PIX not following SNMP
packet size standard in RFC3417CSCsc53491 Pix does not support SNMP variable
ipForwardingCSCsc60930 PIX 6.3 Hitless Upgrade supportCSCsc61300 CPU
increases with high volume of DNS requests using same four-tuple. 6.3.5.106/
14-Jan-2006 00:09 - ? CSCdv54885 downloadable ACLs not deleted after
cl uauth when telnet to PIXCSCsc14915 PIX 6.3 Spoofed TCP SYN packets can
block legitimate TCP connectionsCSCsc66215 PIX reload with Thread Name:
https_proxyCSCsc68744 PIX - Syslog PIX-6-110001: No route to IP generated
incorrectlyCSCsc91098 SIP: PIX does not create media conns if first m= has
port 0 in sdp. 6.3.5.107/ 23-Jan-2006 20:28 - CSCsc82346
tftp fixup does not allow error message from clientCSCsc92911 PIX 6.3
crashing at mgcp_show_sessionsCSCsc95334 PIX does not recognize RADIUS
access-accept and access-reject packets.CSCsd08448 downloaded acl is not
removed after a virtual telnet login 6.3.5.108/ 07-Feb-2006
23:59 - CSCsb34758 connection to DMZ fails after PIX authentication
sessionCSCsc60975 PIX crashes after removing Packet capture
configuration...ver 6.3.5CSCsd14589 PIX reload with Thread Name:
tcp_slowCSCsd26109 High CPU, delayed traffic, block depletion for 2 sec when
> try messing with this command
>
> fixup protocol dns maximum-length <bytes>
> 512 is the default
>
> jlm33990 wrote:
> > Brand new to PIX. Here's the story...
> > pix 515e running 6.3(5)
> > Box will freeze from time to time and won't pass/handle new dns
> > requests. IP traffic is still ok if you use ip# only. Host names will
> > not resolve. Clear local will fix the problem. I don't have any rules
> > or statics for dns.
> > Inside clients point to an internal solaris named box for resolution
> > who will pass request to isp if he doesn't have answer. Another fix to
> > the problem is if I change my pc's resolver from the solaris box to the
> > isp's dns.
> > I've been running a solaris based firewall for years in the same
> > environment and never had such a problem.(if I put the solaris firewall
> > back in place the problem goes away)
> > One minute I think there is something wrong with the pix because a
> > reboot or clear local will fix the problem and the next minute I wonder
> > if there could be something wrong with my named server because, as I
> > said, if I point to the isp's dns servers the problem goes away. No
> > changes have been made to the internal named server.
> > I can see from syslog that the dns udp teardowns that normally take 1
> > second all of a sudden take 2 minutes when the problem happens. I've
> > looked throught the log around the time that happens and see nothing
> > suspicious.
> > Any ideas - I'm going insane
> > thanks...jim
> >



Similar ThreadsPosted
Protect yourself against Operation Sudden Fall May 9, 2008, 8:51 pm
how to handle loggings? February 16, 2005, 7:28 pm
Can a 2610 handle this? September 19, 2006, 4:23 pm
How many T1's can a 2621 handle? February 21, 2005, 10:39 am
How do I forward/handle this routing change? January 25, 2007, 9:54 am
Can SN 5428 handle bi-directional multi-protocol mapping? September 21, 2006, 4:48 pm
Cisco Security Manager, how does the policy manager handle precedence? September 18, 2007, 12:34 pm
How does typical ISP traffic shaping/bandwidth limiting work ? Do ISP's allow bursty traffic per second ? January 19, 2006, 3:50 pm
traffic-shaping limit ftp traffic October 7, 2005, 8:51 am
Traffic-shaping traffic with precedence 2 June 12, 2008, 5:05 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map