Ken - Aug 4, 2011 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.

*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).

I’m not the greatest at AAA on Cisco’s IOS. I always have to think about how to order things, and to test fallback (which you should do anyway). One of the caveats that I always overlook, no matter how many times I set this up, is that Cisco IOS software attempts authentication with the next listed authentication method only when there is no response from the previous method. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops and no other authentication methods are attempted*.

I have had the opportunity to work pretty extensively on the Juniper SRX firewall/IDS platform over the last few months. In doing so, I’ve found many “gotchas” the hard way. Here are a few that I’ve found so far: Clustering is a beast in and of itself. I think it needs a bit more polishing, but it could be that we just need to refine our design. On the SRX 650 it works, but you must be on the right code version (I got it to work under 9.

In the day and age of SDN, let’s talk about the tried and true CLI. Lets be honest, in a world where there are 10+ year old network devices still in production, it’s not going away any time soon.

I recently had a conversation with Brent Salisbury that re-introduced a bit of a hot button with me. The term “next-generation” is over used and at this point arguably meaningless. So many things are labeled “next-generation” that, while technically true, they may be the next in a line of product, the term has entered marketing typecast.