[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