[j-nsp] Quick Question About HA Setup

Pavel Lunin plunin at senetsy.ru
Tue Jul 17 06:06:02 EDT 2012


Ben Dale worte:
> All told though, I think once ISSU/LICU is addressed there'll be very little reason not to cluster them.
In general I disagree. What you describe is basically about firewalls.
But the main issue with a multi-site cluster is the need to pool all
your VLANs to both devices. So you need to use some inter-site L2
switching solution instead of routing. When there is nothing technically
impossible these days, building a resilient L2 network is quite a
difficult task for customers, most of whom have no idea of what all
those VPLS-SHMEEPLS multihoming and L2 OAM things are. And usually such
solutions are much more expensive, which consequently leads to throwing
out important things, lack of redundancy, relying on ISPs, etc.

These cons usually outweigh the pros, IMHO. Say, if you count money, two
clusters, one for each site, with L3 between them is almost always
cheaper and easier than a resilient and scalable inter-site L2. Yes,
policy synchronization can be an issue, but let me use the word 'Junos
Space' to address this (yes, I know… :). Well, seriously, what if you
have three or more sites and want to synchronize your policies and
address objects? This anyway should be managed by some external NMS.
> 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?  
This is because of private config used for clusters. But I also don't
understand why it's like this, when all the other mutli-RE platforms use
normal config mode.
> 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...
What annoys me even more is the absence of 'commit confirmed' for SRX
cluster.


More information about the juniper-nsp mailing list