[j-nsp] Quick Question About HA Setup

Ben Dale bdale at comlinx.com.au
Mon Jul 16 19:33:12 EDT 2012


> I'd say the idea of splitting a firewall cluster into two geographically
> remote parts is itself worth to be revised twice. The chassis
> interconnect pitfalls are not the main caveat in such a design.
> 
> The most important thing about FW clusters (or even any other statefull
> devices, like, say, BRAS) is that it's not just about the firewalls.
> It's even mostly not about firewalls but about integrating them with the
> rest of the network infrastructure. It also involves resilient solutions
> for routing and especially switching.


Exactly!

I get asked by customers about this all the time.  In general, I don't have a problem deploying chassis clusters across geographically dispersed sites, as long as connectivity in between is fast and diverse (eg: dark fibre/lambda).

The functionality/stability has come a LONG way over the years, so when deciding you probably need to weigh up the following:

Pros:
- Single configuration of security policies automatically synchronised across firewalls.  There are other "hacks" to achieve a similar outcome between stand-alone devices, but this is certainly the easiest
- Tighter control over the symmetry of traffic flows into and out of your network (and associated statefullness)
- State preservation of in-flight sessions during fail-over (via reths)

Cons:
- ISSU (or "Low-impact cluster upgrades" as is is known) still isn't quite there yet in 12.1
- Potential issues providing resilient jumbo-frame capable layer 2 interconnects between locations node locations.  Hint: sometimes RSTP is fast enough, and sometimes it isn't.
- No true in-band management (especially painful at remote sites when you're on the outside of the SRX, the fxp0 "OOB" madness is the source of much grief, and the cluster-master command comes with it's own new set of caveats)
- No commit confirmed
- No synced IDP updates (last I looked, again fixable via hacks)
- Number of revenue ports used to achieve clustering (more an issue on the branch boxes/J-Series)

All told though, I think once ISSU/LICU is addressed there'll be very little reason not to cluster them.

One thing I've always wondered, but never bothered asking - why is it that you need to be in the root level of the configuration to commit in a chassis cluster?  

I can't count how many times I've hit this buried 7 stanzas deep in a security policy, and wanting to commit something, then make a change at the same level moments later...

Ben


More information about the juniper-nsp mailing list