04-22-2010 07:23 AM
@BenR - please re-open or re-engage on your JTAC case - either the fix doesn't work, or this is a similar symptom with different root cause.
@Everone else - if 10.0R3 resolves the issue for you please post back.
I have asked a member of my team to run an analysis on the release-note contents for SRX to see if we can make some process improvements in what's reported in the known-issues and resolved-isses areas.
05-04-2010 12:12 PM
versello (OP) said something about disabling all IDP features. I'm having what looks like the same problem with my SRX240 HM and was wondering how you go about doing that. I can post my config if it helps.
05-04-2010 02:30 PM - edited 05-04-2010 02:31 PM
One of the J-TAC engineers working on my case also said some indications point to IDP (I just have UTM disabled)... perhaps I'll disable it. This will mean my device isn't any better than my replaced PIX 515e.
05-05-2010 04:57 AM
My SRX has been running for two weeks without issues on 10.0R3.10. It doesn't have any IDP features enabled which may be part of the equation. It's dissapointing that Juniper hasn't ironed out those problems yet though.
05-09-2010 12:56 PM
I tried the suggestion from oldtimer to restrict port switching, but it didn't seem to help. I'm installing the 10.0R3 right now, so I'll post back with results in a few days.
05-12-2010 10:52 AM - edited 05-12-2010 10:53 AM
My SRX240 HA Cluster on 10.1R1.8 just crumbled when I downloaded the IDP database and templates. I set the Recommended template to Active but hadn't apllied the IDP to any policies yet. I have been running for 2 weeks with Web-Filtering turned on with no issue. When I kicked off the download of the IDP database, I saw that one of my Zones stoped passing data to and from the other Zones. Just like that, no change of policies or anything. Just ran the command "request security idp security-package download" During this outage, the Firewall could ping the affected zone, just no one else could. Then one by one, the other zones stopped responding. I could stay on the telnet session to the firewall, but all traffic between all zones just stopped.
I am leaning towards
1) JUNIPER NEEDS TO GET THEIR CODE FIXED, this is major release 10 of your software and it still doesn't work?!?!?!?!
2) IDP is the culprit in these cases.
05-18-2010 06:13 AM
After upgrading to 10.0R3 and applying the fix for PR#521684, my device would only core flowd about once a week. I have upgraded to 10.1R2.8 now, because I was told by JTAC that my last crash cause was fixed in it. So far so good with ExpressAV, Web filtering and IDP enabled. Only problem with this release so far has been the DNS alg, which has been blocking DNS replys with CNAME pointing to the base domain address (IE www.asp.net CNAME asp.net, etc.) so I disabled the DNS alg.
05-19-2010 07:21 AM
BenR - Can you let me know if your system becomes unresponsive? JTAC told me 10.1R2.8 doesn't have the fix to my core-dump IDP issue, so I probably won't even bother with it.
05-21-2010 12:10 PM
"Only problem with this release so far has been the DNS alg, which has been blocking DNS replys with CNAME pointing to the base domain address (IE www.asp.net CNAME asp.net, etc.) so I disabled the DNS alg."
I think we give you a nerd-knob in 10.1R2 to tweak the default DNS response packet size.
10.1R2 release notes includes the following:
DNS doctoring support—This feature is supported on all SRX Series and J Series devices.
Domain Name System (DNS) ALG functionality has been extended to support static NAT. You should configure static NAT for the DNS server first. Then if the DNS ALG is enabled, public-to-private and private-to-public static address translation can occur for A-records in DNS replies.
The DNS ALG also now includes a maximum-message-length command option with a value range of 512 to 8192 bytes and a default value of 512 bytes. The DNS ALG will now drop traffic if the DNS message length exceeds the configured maximum, if the domain name is more than 255 bytes, or if the label length is more than 63 bytes. The ALG will also decompress domain name compression pointers and retrieve their related full domain names, and check for the existence of compression pointer loops and drop the traffic if one exists.
Note that the DNS ALG can translate the first 32 A-records in a single DNS reply. A-records after the first 32 will not be handled. Also note that the DNS ALG supports only IPv4 addresses and does not support VPN tunnels.
05-24-2010 09:01 PM
As a followup to my previous post, our SRX 240 has been running fine since I did two things:
1) Upgraded to 10.0R3
2) Added a firewall rule to block incoming multicast traffic (because of what Oldtimer mentioned about multicast traffic traversing multiple interfaces)
It's been chugging along since the 9th. Unfortunately I can't say whether the multicast block or the upgrade fixed the problem, and I am loathe to disturb a 'stable' system to find out...
05-25-2010 05:28 AM
@KB_Fan, The DNS issue is PR #527294, where the DNS alg does not parse a compressed DNS response properly. The workaround is to disable the DNS alg and wait for 10.1R3 which will have the fix or get a special build from JTAC. In this case I will be waiting for the tested build.
@versello, so far so good. It hasn't locked up yet or cored flowd. I will post back if it happens again.
05-25-2010 06:26 PM
JTAC informed me 10.0S5.2 is out. URL: https://download.juniper.net/software/junos/regres
My IDP issues may be fixed in this release, but JTAC can't confirm it. I may upgrade my SRX650 later this week. I just applied it to my SRX210 without any problems.
05-31-2010 01:14 PM
SRX650 cluster running 10.0R3 + Webfiltering
Spent the weekended migrating our ISG to the SRX650s, they STOPPED this morning once some real load was put on them..
We have a ticket open with JTEC but rolled back to our ISG in the in term. Lets just say no one is very happy here today.