Hi Pavel - I believe that what you are describing is exactly what I'm looking for, but I did not realize this was the proper way to configure. Can you please provide a configuration example?
Thanks again for all of the input. ________________________________ From: Павел Лунин [[email protected]] Sent: Monday, January 16, 2012 3:58 PM To: Paulhamus, Jon Cc: Ben Dale; [email protected] Subject: Re: [j-nsp] SRX650 cluster - ethernet switching issue The case what not that I was connecting end points directly to the SRX, it's that I wanted 2 trunk links between each SRX node and the switch stack (there is only 1 switch stack), each of the 2 links supporting different VLAN's. So - 2 links from the primary node to the switch stack, and 2 links from the secondary node to the switch stack as well... this does not work with STP enabled as 3 of the 4 links get blocked by STP. I needed a setup like this as I'm pushing over 1Gb through each switch link. My favorite design is to connect each SRX to its own (no cross-links) VC-member using several physical links (as many as you need for performance) and to use L3 on top of reth VLAN units, each of which includes two physical links (primary and secondary). You can distribute VLANs across reths manually, just as you would do for STP (if it worked). At the SRX side you have several reth interfaces with units on them, at the VC side you use interface-range for bundling ports connected to primary and secondary SRX into a single config knob, which is really useful. Of course, on SRXes, when you move a VLAN X from, say, reth0 to reth1, you also need to replace reth0.X to reth1.X in the rest of config (zones, etc) but JUNOS allows you to do so with a single command. You can either bound all the reths into a single RG1 (always active/passive) or put each reth into a dedicated RG (partial active/active). You can even easily make different nodes act as master for different RGs, though in most cases it will give nothing except pain in the rear. I love the first approach (one RG1 for all reths) because it's much simpler. RG1/2/3/etc failover is quite fast (sufficient for most applications) so failing over all the reths to backup node in case only one of the primary node links fails is not a very high price for the simplicity. A small drawback of this design is h-shape switching, if you connect downlink devices to the VC with LAGs. Traffic will come to the VC balanced between the switches connected to active and backup SRXes. So the VC will first forward the frames to the switch, connected to the active SRX via internal VC link. But if we consider a VC of 2×EX4200 connected with two VC cables, this is not much of a problem. You can also add cross-links and bound four interfaces into a single LAG/reth (a hybrid of the two) on SRX (two links on master are active, two on backup are down), but JUNOS does not allow to bound two ae interfaces into an interface range on the EX side. So for each reth on SRX you will have two ae's on EX.This is hateful and prone to mistakes. On the other hand this approach will give you the ability to balance traffic across two links (SRX1―EX1 and SRX1―EX2) automatically with hashing (limited to two links only) and additional speed of switching over LAG members in case of a failure. When switches are connected not with 2×32G cables but something else (1G llinks or 10G and it's an SRX High End cluster) this approach will also save some resources because of avoiding interswitch forwarding, as described above. Though in my experience it's not usually worth the 'two on EX ― one on SRX' interface matching headache. -- Regards, Pavel _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
