All control plane functions are on the primary node and the secondary node acts 
like a backup RE and linecard.  You can use the cluster active/passive or you 
can use active/active.  You aren't forced to only use active/passive.  There's 
a control link that synchronizes all of the runtime objects and a fabric link 
that will transport the data plane.

-----Original Message-----
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of OBrien, Will
Sent: Thursday, February 03, 2011 10:00 PM
To: Ryan Goldberg
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX advice

I've implemented two pairs of clustered SRX240s for one of my networks. HA is 
fairly simple to set up, and seems to work fairly well. sessions tables are 
replicated between the cluster, but active routing is not, so you're going to 
be using a active/standby scenario with them for now.

I'm actually more concerned with terminating ipsec tunnels within virtual 
routing instances right now. This is supposed to be working in the newer 
release, but we've been short on time for testing and deployment.

My clusters are fairly simple: they run bgp with an upstream and announce 
particular routes they see via ospf. I haven't tried to terminate vpn tunnels 
on them. Based on my testing, I would expect to see the tunnels drop and 
re-establish in a fail over scenario due to the active/standby nature of the 
routing on those boxes.

On Feb 3, 2011, at 11:12 PM, Ryan Goldberg wrote:

> Hi-
> 
> Totally new here, and I mainly lurk on other lists, so be gentle if possible.
> 
> We are in a situation we need to get out of.  I am considering a pair of 
> juniper SRX boxes (240s are in the budget) to do that.
> 
> This is what we have:
> 
> watchguard a) is the outbound nat box for about 70 small offices (we are a 
> small ISP too, these are fiber-connected customers).  it also handles some 
> amount of inbound nat for those customer's various servers, which may be in 
> the customers office, or a virtual host in our racks.  and maybe a half dozen 
> ssl-vpn road-warrior types.  There's also a dozen or so lan-to-lan ipsec 
> tunnels on it.  sustained 2-20 inbound.  light outbound.
> 
> watchguard b) is for internet facing windows boxes.  lotsa inbound nat.  
> sustained 2-20Mbit outbound
> 
> watchguard c) is for our office, 55ish users.  some inbound nat too.  
> 0-50Mbit inbound, widely varying
> 
> watchguard d) is for one particular hosting customer where stability is 
> paramount.  The other firewalls get touched a lot (and as of late, have been 
> puking when they feel like it).  2-15Mbit of sustained web traffic, with the 
> odd spike or lull.
> 
> a 2821) terminates a bunch of lan-to-lan ipsec tunnels (VTI style) to 1841s 
> all over the place.  box is completely VRFed, no global table, all the 
> tunnels land in the INTERNET vrf and pop out in customer vlans, each their 
> own vrf.  10-30Mbit
> 
> So - goal is to collapse all this onto a single pair of boxes running in an 
> HA config.  Watchguard a, b, and c are problematic, and are becoming more 
> problematic.  watchguard d is pretty quiet, but we are contractually 
> obligated to remove all SPOF from that clients setup.  the 2821 is very 
> quiet, no troubles.  
> 
> My main question revolves around number of virtual routers.  We can't afford 
> a big enough box to stuff everything (as in, every customer network) in its 
> own vrf/routing-instance.  I will admit that I've become hooked on using vrfs 
> in cisco land on ISRs (a lot of double-ISP configs, random dirty hacks).  But 
> for our future firewall setup, I don't know what a bunch of routing-instances 
> really buys us, if anything (aside from the psychological aspect).  All we 
> really need is for all the private networks behind this thing to get natted 
> to their corresponding public ip(s), and if something behind the firewall 
> needs to talk to something else behind the firewall, it should go out and 
> back in (getting source nattted, then dest natted).  If the J-boxes can do 
> that without separate routing-instances, then we're good.
> 
> My other question involves HA stability.  I've seen instances with other kit 
> where introducing "HA" actually reduced availability.  SRX boxes like running 
> in HA, or are they fussy?
> 
> I very much thank anyone who takes the time to reply to this.
> 
> Ryan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to