[j-nsp] SRX650 cluster - ethernet switching issue

[Paulhamus, Jon]

Are you suggesting something aong these lines?

Interfaces for

 ge-2/0/4 {
        description "*** Connected to XXX***";
        gigether-options {
            redundant-parent reth4;

ge-11/0/4 {
        description "*** Connected to XXX***";
        gigether-options {
            redundant-parent reth4;

ge-2/0/5 {
        description "*** Connected to XXX***";
        gigether-options {
             redundant-parent reth5;

ge-11/0/5 {
         description "*** Connected to XXX***";
         gigether-options {
             redundant-parent reth5;


set interfaces reth4 vlan-tagging
set interfaces reth4 description "*** Connected to XXX TRUNK #1 ***";
set interfaces reth4 redundant-ether-options redundancy-group 4
set interfaces reth4 unit 200 vlan-id 200
set interfaces reth4 unit 200 family inet address 192.168.200.0/24
set interfaces reth4 unit 201 vlan-id 201
set interfaces reth4 unit 201 family inet address 192.168.201.0/24
set interfaces reth4 unit 202 vlan-id 202
set interfaces reth4 unit 202 family inet address 192.168.202.0/24

set interfaces reth5 vlan-tagging
set interfaces reth5 description "*** Connected to XXX TRUNK #2  ***";
set interfaces reth5 redundant-ether-options redundancy-group 5
set interfaces reth5 unit 205 vlan-id 205
set interfaces reth5 unit 205 family inet address 192.168.205.0/24
set interfaces reth5 unit 206 vlan-id 206
set interfaces reth5 unit 206 family inet address 192.168.206.0/24
set interfaces reth5 unit 207 vlan-id 207
set interfaces reth5 unit 207 family inet address 192.168.207.0/24

Then, on the EX side - just simple trunk configuration permitting said VLAN's for those ports?


Thank you again.

________________________________
From: Павел Лунин [plunin at senetsy.ru]
Sent: Monday, January 16, 2012 3:58 PM
To: Paulhamus, Jon
Cc: Ben Dale; juniper-nsp at puck.nether.net
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