> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
