*IDP signatures need to be updated often. On the SRX platform, there is also the notion of a “detector”. This also meeds to be updated on a regular basis. it seems. Over the past few weeks, we’ve needed to update the IDP signatures and detector on our SRX 5800 cluster several times, and the results have normally been fine.
Updating the IDP signatures has never been that big of a problem (see postings about updating stuff on cluster nodes). But we ran into issues due to the fact that we’d recently disabled application id to troubleshoot another problem. This was basically causing all of our updates to fail on node1 (the secondary node) when using our op script to push the updates over (sorry, I can’t share it).
A few things that I like to make sure to run before and after all of my SRX work are the following:
show chassis cluster status
show ospf neighbor brief
show security idp attack table
If I’m doing work on the IDP engine, I also want to see the status of that:
request security idp security-package download status
request security idp security-package install status
show services application-identification counter*
Anyway, for anyone else running into this odd behavior, to finally update it was a simple matter of deleting app-id before running the updates.
edit
delete services application-id
commit comment “delete services application-id”
request security idp security-package download full-update
request security idp security-package install
op instlll-idp-updates
At that point run the status commands request security idp security-package install status. It should yield something like Done;Attack DB update : successful on both nodes.
*It should be noted that Application ID is now in services, whereas I believe it used to be down in security.
Nick – a question for you regarding SRX IDP signature database updates on a Cluster. The ‘successful’ message you list above indicates both nodes will be updated, however, my understanding is that only the Primary node will be updated,not the Secondary node and that it is necessary to fail over the Primary function and repeat the update procedure in order to update both nodes. The RE is not running on the secondary node, which is the reason for this procedure, as I understand it. I am referring to a srx240 cluster, so it may be different from your 5800 cluster. I believe the workaround is to use the Offline procedure for IDP sgnature database updates… I would appreciate your thoughts and experience. Thank you.
Ken
Ken, that is correct. We have an op script that pushes the updates across the control link on the back end. Failing it over is the supported method, but I find that pretty crummy, so we worked around it.