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: Павел Лунин [[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
