[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