We need more than one link to have redundancy on link level for single box and in case of traffic increase in the future as the cluster is in active/passive mode.
BR, -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Lunin Sent: Wednesday, March 09, 2011 11:18 PM To: [email protected] Subject: Re: [j-nsp] SRX650 Clustering Issue On 09.03.2011 21:47, Stefan Fouant wrote: > What Ben is saying is that you it is simply not necessary to configure > the AE interface when doing this on a Clustered device. Basically, > when you are doing clustering, you simply add multiple ports from the > same node to a RETH interface and this bonds them together to create > your Link Aggregation Group. To answer your question, load-balancing > should happen by default amongst all the ports in the RETH on the > Active node. BTW, I've only done this on the High End SRX > platforms... I'm not sure if this support exists on the SRX 650. So > you may want to check with your account rep or do some digging to determine if this support is provided on the Branch SRX devices. > No, LAGs are not supported in cluster mode for branch SRX. http://www.juniper.net/techpubs/software/junos-security/junos-security10 .4/junos-srx-jseries-support-reference/jd0e3251.html Though, to be honest, I don't really believe it's much needed for the low-end. At least I am sure it is not in most cases. SRX650's preformance is 2,5Gig for IMIX. In case you don't use a router-on-a-stick topology, two 1-gig reths is something close to this. I bet most deployments of such a box allow splitting VLANs into several physical reths. In case you really have all the 2,5 gigs coming, say, from the Inet to one internal VLAN and you have no way to split this load somehow using more interfaces in the routing scheme, well... 10GE card, which is available for SRX650, is your friend. However it's more likely, that you need more powerful gear for this. This is not the case for most of the deployments of SRX branch, at lease of those I've seen. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
